Every day I experience life in the world of healthcare IT, supporting 3000 doctors, 18000 faculty, and 3 million patients. In this blog I record my experiences with infrastructure, applications, policies, management, and governance as well as muse on such topics such as reducing our carbon footprint, standardizing data in healthcare, and living life to its fullest.

Monday, February 14, 2011

Detailed Clinical Models

As the PCAST Workgroup ponders the meaning of a Universal Exchange Language and Data Element Access Services (DEAS), it is exploring what it means to exchange data at the "atomic", "molecular", and document level. See Wes Rishel's excellent blog defining these terms. For a sample of my medical record using one definition of an atomic form, see this Microsoft Healthvault screenshot. It's clear to me that if we want to exchange structured data at a level of granularity less than an inpatient/outpatient/ED encounter, we need to think about detailed clinical models to specify the atoms.

As I've discussed previously, it would be great if EHRs and PHRs with different internal data models could use middleware to exchange a reasonably consistent representation of a concept like "allergy" over the wire. I think of an allergy as a substance, a precise reaction description, an onset date, a level of certainty, and an observer (a clinician saw you have a severe reaction verses your mother thought you were itchy). PHRs often have two fields - substance and a severe/minor indicator. Any EHR/PHR data exchange without an agreed upon detailed clinical model will lose information.

HL7's Reference Information Model (RIM) provides one approach to modeling the data captured in healthcare workflows. However, many clinicians do not find the RIM easily understandable, since it is an abstraction (Act, ActRelationship, Participation, Roles, Entities) rather than a reflection of the way a clinician thinks about clinical documentation. Alternatively, a detailed clinical model provides an archetype or template to define the aspects of the data we should exchange.

To illustrate the way a detailed clinical model can enhance data exchange, here's a description of an allergy template based on collaborative work between Intermountain, Mayo and GE.

The Australian work on OpenEHR is another interesting approach to detailed clinical models. It creates a clear expression of a clinical concept in a manner that can be understood both by clinical subject matter experts and technologists. For a given concept, OpenEHR specifies a SNOMED code and then builds the appropriate information structure around it.

3 comments:

Thanks for flagging up the openEHR archetype approach, which is better known outside of the US.It is closely related to the ISO and EU standard en13606 archetype standard.

As we know that interplay between clinical process and IT is a key challenge...I was drawn to archetypes several years ago as they have the potential to fit well with the complexity and diversity of clinical process.

Given the complexity of the challenge, thanks also for highlighting the diversity of approaches in this space. Over time, as there is much work on detailed clinical models/archetypes to do, greater international collaboration in this challenging space is in all our interests..

John I would like to hear more from you regarding the hl7 3.0 standards. Have you personally taken a close look at it and it's critiques? My own experience with it, to be blunt, is that it is a disaster and has the potential to be a major setback in enabling the sharing of electronic health records. One could probably argue that it has already been costly Here are my reasons in brief:1. It overly complex and not easily understandable! It's not just clinicians who cannot understand it. For example I have a Phd in computer science2. The documentation is not free. But the documentation I have been able to obtain is poorly organized

I agree with Barry Smith who says it is time to start over. Let's nip this problem in the bud.