EHR Interoperability

Why, what and how

SB Bhattacharyya,  Head, Health Informatics, TCS Member, National EHR Standardisation Committee, MoH&FW, Govt. of India Member IMA Standing Committee for IT, IMA Headquarters

The ability to merge data from clinical documents like Electronic Medical Records (EMR), investigation results and reports, medical reconciliation, nursing records, operative notes, etc. authored by different persons at various times at diverse locations using disparate electronic systems from many manufacturers is critical to the creation and maintenance of lifelong electronic health records of an individual. For this, both the structure and contents need to be available in formats that can be properly processed by electronic systems to ensure that the right contents are matched and merged into a single life-long record. Interoperability is what makes this possible. This article discusses the why, what and how it can be achieved.

Electronic Health Record (EHR) is a life-long record of all the clinical encounters, investigation results and reports, etc., that a particular person has throughout life. All of these clinical documents need to be lined up and merged together into a single continuous document to help provide that person’s health-related life journey. Thus, there is a need to ensure that the consolidation of the related clinical documents of that person is made possible in a seamless manner. This requires that all electronic systems that generate the various clinical documents of a uniquely identifiable person be interoperable.

If merely displaying contents from other systems was the requirement, the need for extensive interoperability would have been superfluous since the external records could have been made into something like a scanned document in the form of JPEG image or PDF file and having it displayed would have been sufficient.

Such use, however, is severely limited in scope and does not justify the use of valuable computing resources as the needs are much more. These include the ability to analyse contents, help trigger important actions that could potentially be life-saving and automating routine repetitive tasks are some of the more meaningful use of electronic medical records, all of which are possible only through interoperability.

What is Interoperability?


Interoperability is defined as the ability of two or more systems or components to exchange information and to subsequently use it. This is made possible by taking advantage of both the structuring of the data exchange (syntactic interoperability) and the codification of the exchanged data itself including vocabulary (semantic interoperability) so that the receiving information technology systems are able to properly interpret the data for further action.

Syntactic Interoperability

Syntactic interoperability defines the syntax of the data exchange and ensures that such exchanges between information technology systems can be interpreted at the data item level and is achieved through the use of a common information exchange reference model. Consequently, these standards specify either the record structure or the data exchange (messaging) formats.

Semantic Interoperability

Semantic interoperability is the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end-users of the respective systems. This is achieved using a clinical code system, whose contents are unambiguously defined and coded, to ensure that the meaning of the information, as present in the sending system, is identical to that interpreted by the receiving system.

Why is Interoperability required for EHR?

Persons have many encounters with different care providers throughout his life for the various illnesses they happen to suffer from or for receiving help in prevention and/or monitoring them. Each encounter leads to the creation of a single medical record. To help maintain a life-long record of the progression of one’s health, it is necessary to firstly uniquely identify all records belonging to the same person, then arranging them from the very first to the very latest, and thereafter understanding their contents that have been created by many authors using a wide-variety of systems from different manufacturers before consolidating them all together into a single record.

Further complicating matters is the fact that these records are usually made by different persons who work in various speciality areas like paediatrics, medicine, ENT, ophthalmology, skin, surgery, obstetrics and gynaecology, etc. Due to the specific demands of the various medical sub-domains, all of these require different types of information to be recorded in a particular way. Topping all this is the inescapable reality that each of the authors usually has a very unique style of record writing as a result of their medical training.

How can this be made possible?

Fundamentally, any type of record consists of two parts: (1) the structure, containing the individual data items along with their corresponding data types, data lengths and data formats, and (2) the content filled in by the authors.

Since the record contents created and maintained in one system needs to be exchanged with and ‘interpreted’ by another system, a way needs to be found whereby the other system is able to correctly perform these tasks. This is done by aligning the structure of the records in the two systems and then ‘interpreting’ the exchanged contents.

There are two ways of aligning the record structures. One would be to use a common information framework for exchanging data. The other would be to use a common messaging framework that can be mapped to by the systems participating in the data exchange to correctly identify the exchanged data items.

Solving the structural issues is simpler when compared to solving the content issues. Not only do these need to be accurately exchanged, but their meaning too needs to be preserved and subsequently ‘interpreted’ by the system for further action. This translates into the requirement that the content needs to be in the form of some machine-processable ‘code’. This ‘content coding’ is carried out through concept modelling using principles of linguistics, computer and information science.

These two types of models, namely the information model and the concept model, are based on the model of meaning of the data item in context. Both of them need to be considered together for precisely deriving what the author meant when making the record entry.

Model of meaning

The ‘model of meaning’ is a human conceptualisation of the world and its contents. This is done using an information model (model of the information) and a concept model (model of the concept) in order to ensure that a data/record item, is clearly understood by both humans and machines alike, so that further action may be undertaken as necessary by either.

Information Model

An information model provides a sharable, stable, and organised structure of the information requirements or knowledge for the domain context. At a very basic level, it is a structure that serves the syntactic aspects of interoperability. This can be used for designing records or data exchange messages.

Concept Model

A concept model provides a way in which information knowledge can be represented and subsequently codified, thereby serving the semantic aspects of interoperability.

Example – Handing “Title” of a Person’s Name

[NB, the following discussion related to the data item ‘Title’ is purely imaginary and has been provided here to help illustrate modelling concepts.]

It is important to recognise that when writing a record, one enters the thought that one has about the item in context. In the case of ‘Title’, this would be ‘Mr’ if the person is a male, ‘Ms’ if the person is not a male,’Miss’ if the person is an unmarried female or ‘Mrs’ if the person is a married female.

This concept or thought or idea (all synonyms), is modelled by making a knowledge representation of the human-readable term ‘Title’, which is then transformed into machine-processable code. This could result in the following.

• Title is a part of Person Name

• Title is

Mr, when the person’s gender is male

Ms, when the person’s gender is not male

Mrs, when the person’s gender is female and marital status is married

Miss, when the person’s gender is female and marital status is unmarried

The above is what can be termed as ontology. By applying Description Logic to it machine-processable codes can be generated, which the systems can use to interpret what the data item actually means.

The ‘title’ data item in a record can be structured by using the followinginformation model.

Title: string 0..1

This means that ‘Title’ is of the data type ‘string’ and can be used either never (0) or once (1), i.e., it is optional.

The above could be exchanged as a message as structured below. The user has chosen the title as ‘Mr’ in this instance. [The structure is shown in two different styles – JSON and XML, currently the most commonly favoured formats.]


“Title”: “Title”,

“Type”: “String”,

“Value”: Mr






In the above, the section enclosed by curly brackets ‘{}’ or tags “<>” is the structural (syntactic) part and the ‘Mr’ is the content (semantic) part.

If both the sending and receiving systems use the same structure for storing/exchanging data, there will be no problem in achieving interoperability as the data item will be correctly matched up (both the data items are named exactly the same, have the same data type (text in this case) and convey the meaning about the same thing (person’s title in this case).

Using the above, a computer system would be able to interpret the term ‘Mr’. Supposing the system is programmed to execute the rule that “if the title is ‘Mr’ then automatically fill in the person’s gender and ask the user to enter the marital status else if the title is ‘Mrs’ or if the title is ‘Miss’ then automatically fill in the person’s gender as well as the marital status” then the system can accurately carry them out.

Although this example demonstrates how a simple concept like the title part of a person can be handled, by adopting the same principle to handle complex concepts like complaints of productive cough-green sputum, on examination-grossly enlarged liver, diagnosis of recurrent appendicitis, procedure of laparoscopic emergency appendicectomy using flexible fiberoptic laparoscope, assessment of eating and drinking behaviour, family history of chronic obstructive lung disease, etc., presents immense possibilities for very detailed rules to be put in place to automate ordering, prompt for additional information, etc.

How does SNOMED CT,ISO 13606, Open EHR, HL7, etc. Help?

ISO 13606, open EHR or HL7 are basically information models that can be used for designing clinical records (all three) and messages (HL7 only) there by facilitating syntactic interoperability.

Handling the clinical record contents is a little trickier. Ideally, an EMR has four broad sections (SOAP)–Subjective (things that the patient states like chief complaints, history, etc.), Objective (things that the provider observes like vital signs, physical findings, etc.), Assessment (things that the provider concludes like clinical summary, diagnosis, etc.) and Plan (things that the provider decides will prove most effective in alleviating the patient's condition like medications, diet, etc.).

SNOMED CT is the most comprehensive clinical code system currently available that permits unambiguously coding of all parts of clinical documents. It ensures the maintenance of semantic integrity through its Machine Readable Concept Model (MRCM), which is a representation of the rules that comprise the SNOMED CT Concept Model in a machine-processable form.

The other clinical code systems happen to be WHO Family of International Classifications (ICD, ICF, ICHI, ICD-O), LOINC, CPT, CDT, DRG, NANDA, RxNorm, ATC, etc. that address parts of clinical document like diagnoses, investigation observations (results), procedures, diagnostic group, medication, etc.


A medical doctor is as effective as the body of information about the patient's health condition is available to him. While neither everything is required nor is necessary (mostly due to lack of relevance of the information to the patient's current clinical status), more and detailed than less and sketchy is always preferable in providing optimal care – both from diagnostic and prognostic points of view.

Interoperability is a serious issue and is neither easy to understand nor easy to implement. However, it cannot be avoided either since without it no EHR can be generated and/or maintained in any shape, manner or form.

Using well-proven and widely-available standards, interoperability is no more the maze that it was once considered to be. By following good systems design practices and using standards, truly interoperable EHR systems can be made available to help achieve universal health coverage.


1. IEEE definition
2. CEN/ISO 13606 []
3. Models of use and Model of Meaning towards a Model Driven Architecture for Data Entry & decision support, Alan Rector, Tom Marley, and Rahil Qamar, University of Manchester
5. This is due to the fact that a person can have many genders, not just male or female, and represents what the person thinks himself (or herself) to be identified as

-- Issue 37 --

Author Bio

SB Bhattacharyya

Suman Bhusan Bhattacharyya is a practising family physician and a business solution architect for medical devices and healthcare IT applications with nearly twenty nine years of experience. He has worked for several IT MNCs in India and is currently Head of Health Informatics in TCS based out of Delhi-NCR region.

Currently, he is a member of EMR Standards Committee, Ministry of Health and Family Welfare, Government of India and is also member of Healthcare Informatics Standards Committee, Bureau of Indian Standards. His main areas of interest include clinical data analytics particularly treatment protocol planning using predictive analytics, EHR& EMR, mobility applications and application of machine learning techniques in healthcare.