In terms of EHR design/architecture, data exchange using APIs provides one possible path for extending an EHR system’s functionality.   Using data exchange makes it possible to build EHR platforms in which a core system provides basic functions (med list, problem list, demographics, etc.) and external systems provide on-demand services  (e.g. data analysis) or complement the core system (e.g. disease registry).   My interest in API development  led me initially to XML and,  more recently, to JSON.

JavaScript Object Notation (JSON)  is a messaging format that shares a few key features with XML.  Both messaging formats are plain-text, human readable,  and  hierarchal.   JSON originated in 2001 as a lighter weight alternative to XML.  XML has a lot going for it. It is very expressive  and can be used to create documents of arbitrary complexity.   JSON is not an XML  replacement; it solves different problems.  For one, JSON is easier to read (at least to me and some others) because it lacks the tags found in XML.  This makes debugging easier, and makes it easier to grasp the content of a JSON file.  In addition, for web-based applications that use AJAX, JSON is easier to manipulate and is said to be faster than XML (I haven’t confirmed this personally).

JSON uses JavaScript notation, but it is not tied to JavaScript—there is support JSON in every major programming language.  JSON supports the following data types: object, array, numeric, string, number, and Boolean. Data elements are represented simply using name: value pairs (e.g., {“chief complaint”: “cough”}).  One significant difference between JSON and XML is the formers support for arrays, which can aid readability.   Objects are contained within braces {}, while arrays are bracketed [].     The best way to get a feel for JSON is by seeing how it might be used.

Here is the data example used for the post XML: Designated messenger.  Compare the XML to its JSON equivalent.

There is a clinical research project that is registering patients with type-2 diabetes for an observational study.  The research team has decided to collect the following information from all of the organization’s associated clinics: ID, name, date of initial diagnosis, comorbid conditions, initial HgbA1c, LDL cholesterol level and result date, serum creatinine level and result date, and care location.  Below is an XML document designed to hold this information.

               <CreatinineLevel>1.4</ CreatinineLevel >
          <FacilityName>East Side Clinic</FacilityName>

Here is the JSON version:

  "Patient": {
    "UniqueID": "WH555444",
    "Name": {
      "LastName": "Doe",
      "FirstName": "John",
      "Middle": "Frank"
    "IntakeCriteria": {
      "DmDxDate": "2012/03/12",
      "InitialHgbA1c": "6.5",
      "CoMorbid": [ "Hypertension", "CAD" ]
    "Labs": {
      "LDLCholestrol": {
        "LDLLevel": "122.5",
        "LDLResultDate": "2012/07/06"
      "SerumCreatinine": {
        "CreatinineLevel": "1.4",
        "CreatinineResultDate": "12/07/08"
    "CareLocation": {
      "FacilityName": "East Side Clinic",
      "ContactEmail": ""

Do you see any significant difference in readability between the two representations?   If not, don’t sweat it.   Unless you’ve spent a lot of time reading one or the other, readability differences may not be obvious.   A more obvious and useful difference is the data-oriented nature of JSON. It is closer to data formats/types found in programming languages, which is why many are choosing it as a data exchange format.   Notice, for example, that the CoMorbid conditions in JSON are an [array].

XML has features JSON does not, such as extensibility and support for multimedia data types. So why choose one over the other?  Having experimented with both, I am increasingly favoring XML for creating and storing complex documents.  JSON will be used for data exchanged between components in software I design.

While I like JSON for data exchange, and using it for this need is helpful, I’ve recently discovered much more interesting uses for it.  A large number of NoSQL databases have JSON- based APIs. Many   document-oriented databases  store JSON  objects easily.  Since JSON objects may be heterogeneous in terms of number and types of fields, this allows for tremendous flexibility in storing and retrieving objects as compared to relational databases.  This is one of the many factors that account for the growing popularity of NoSQL data stores.   I will explore NoSQL database use for clinical systems in a series of posts later this spring.

Should you like to know more about JSON, here is a very simple interactive tutorial. Give it a try.


Leave a Reply

Your email address will not be published. Required fields are marked *