shutterstock_145681514Achieving a satisfactory level of integration between different electronic health record (EHR) systems and related products (such as PACS systems) is difficult. In practice, a level of integration we might call syntactic interoperability is achievable through the use of standards such as HL7 v2, CDA, FHIR, or DICOM. But on one level, these are standards for data representation and interchange. It is true that these standards define logical models such as HL7 v2 messages and segments, the RIM in HL7 v3, or resources in FHIR, and these models do help in creating a common vocabulary. But experience has shown that every system interface requires a lot of development effort, and can involve conundrums that are hard to solve (if not downright impossible). Why is this?

One reason is that different systems  are often developed with different goals in mind. Functional goals for an EHR include (but are not limited to):

  1. Direct provider support (CPOE)
  2. e-Prescribing
  3. Practice management
  4. Billing and reimbursement

Of course, any real system will include most (or all) of these features. But the design of the system is strongly influenced by the objectives the designers were trying to achieve. To make this a bit more concrete, let’s think about billing and reimbursement or a moment. In the United States, encounters need to be billable if the physician is to be paid. So, naturally enough, an outpatient encounter is likely to be represented in a form resembling the Medicaire form CMS-1500. This has to do with recording data required for claims, not recording information needed to support patient care. So, what is a system designer to do? One option is to try and graft billing related data onto a system designed with a differentt purpose in mind (resulting in a lot of accidental complexity). The other is to build two or more separate systems that need to interact with one another. The problem is that these different systems don’t speak the same language! One system iw concerned with procedures and diagnoses, the other with health factors, vitals, and progress notes.

Getting the systems to talk to one another is hard. On the surface, it’s not that difficult to get one system to feed data to another in some predefined format. but problems often arise when it comes to interpreting the data and acting on it appropriately. Is a physician’s subjective assessment the same as a patient reported problem? Obviously not, but if you’re not careful they can end up being confused. Of course, the term “persistent cough” does not exist in isolation, it belongs to a controlled vocabulary (in most contexts), and what a physician means may not be what a patien has in mind when using this phrase.

That brings us to the next level of data integration. Terms used on one system may belong to a controlled vocabulary (such as ICD-10-CM), but that may not b enough to capture their full significance. We need to be able to record context, and need to work within the context of an ontology, both of which serve to establish shared meaning. This levele of integration is semantic interoperability. Unfortunately, it can be hard to achieve.

In healthcare SNOMED CT often serves as the basis of a common ontology. In other domains, Resource Description Framework (RDF) and Web Ontology Language (OWL) work together to provide a mechanism for building, sharing, and even merging ontologies. In an excitingg development, RDF is being explored as a representation of FHIR resources.This opns up the possibility of leveraging semantic web technology to identify and address “data friction” that continues to exist between dfferent systems, or even components of the same system.