The Search for Use in HL7

Yesterday I met with 5 developers at MITRE in their Burlington, MA office.  In addition to giving the CDA and CCD ambassador talk, we spent some time reviewing and discussing the hData Implementation Technology Specification.  Gerald Buechelt is leading this effort in the HL7 ITS Workgroup.

During the review, several interesting ideas cropped up (as they usually do when brainstorming).  One of the interesting questions is how to organize the "resource space" of the healthcare information systems using the hData ITS.  Since hData is a RESTful approach, access to services is governed by resources identified using a URL.  In the HTTP world, URLs have a hostname, zero or more path components, and then a resource name component.  Each of the path components in the URL further refines what kind of content could appear in the resource.  There are a number of common ways to represent these paths.  One example is:
http://www.examplehealthrecord.org/patients/patientId/problems.xml.  In this example, the "patients" path component describes a particular kind object (a patient) that is being referenced.  The patientId component identifies (by a key) which of the patients is being referenced, and finally, the problems.xml resource identifies which of the resources associated with the given patient are being accessed.  The URL is effectively a "search" criteria or pattern matching criteria that is being accessed.  Another URL that could have been used to produce the same information might be: http://examplehealthrecord.org/problems/patients/patientId.xml. 

This "structured search pattern" is something that is familiar to users of XSLT, XPath and XQuery.  In fact, the structure and organization of the XPath searches has been extensively analysed.  The math is even quite pretty (perhaps I'll write a post on in someday).  I'd be interested in seeing a similar representation for REST based URLs be developed to deal with patient records.  But before we can get there, we need to have a better understanding of what it is we are organizing using these URLs.

"Water, water, everywhere, nor any drop to drink"
- Samuel Taylor Coleridge; The Rime of the Ancient Mariner

This leads into the main theme of this posting, which is the search for a model of how health information is used.  HL7 has done great work on developing the Reference Information Model which provides the model of meaning, and the various HL7 Version 3 standards which have computationally well defined exchange semantics.  Part of what makes it difficult to find the model of use is that while meaning is in general static, use is part of the dynamic model.  Several different workgroups in HL7 are starting projects that are focused on how information is used.  The Services Aware Interoperability Framework (SAIF) includes a Behavioral Framework currently being developed by the HL7 Architecture Review Board.  The HL7 Clinical Decision Support Workgroup is working on the Virtual Medical Record, which is a data model that can be used for clinical decision support.  The Micro-ITS and hData project is exploring how to deal with domain specific languages more oriented towards the model of use in an exchange.  The EHR Workgroup has proposed a project called the EHR System Computationally-Independent Information-Model (EHR-S CI-IM) to develop constrained information models or "data profiles" that can be associated with an EHR-S Functional profile.  The superset of these data profiles would effectively become an overarching Computationally-Independent Information-Model supporting the HL7 development process.  Many other workgroups are now deep into development of Domain Analysis Models, which are again, models of work processes and information oriented around how it is used.

With everyone now searching for generalized models, two questions arise.  What is objective evidence that something belongs in a model of use? Related to that is how will the process of developing an overall model will be governed?  We've already seen the need to coordinate the VMR and micro-ITS/hData work, and I also suspect that we'll need to coordinate with the EHR workgroup as well.  At the same time, we need to be certain that it all fits within the SAIF and Behavioral Framework activities.  Given that everyone is now headed towards the same stuff, what is the next step? 

From a business perspective, there needs to be internal coordination (governance) within HL7 on much of this work that is so similar in scope.  The TSC needs to step in and help organize these overlapping activities.

From an information viewpoint, we need take a look at existing models to see which may be have something to contribute.  As the quote above alludes, there is no lack for models in HL7.  We have the Clinical Statement model, the CCR data set that is the underlying model of the CCD, the Care Provision Model, the Pharmacy and Medications Model, et cetera.  We also have external work like that of the US Federal Health Architecture initiative. 

There is also a hidden resource we discovered yesterday that contains within in it the collective wisdom of the HL7 Community as expressed in how different information systems collaborate using V3 standards. The HL7 development process includes identification of Application Roles which participate in Interactions with other Application Roles.  These Interactions involve the communication of V3 messages.  The high level entry points of these V3 messages represent the key objects that make up a model of healthcare information use, at least as defined by HL7 Version 3 standards efforts.  The application roles define a set of service roles.  Let's look at a couple of examples embodied in HL7 V3 Standards:

The HL7 Version 3 Patient Administration Domain includes about 13 different topic areas including: Persons, Identity Documents, Patients, Service Locations, and Encounters of various types.  Each of these belong in a model of use.  The HL7 Care Provision Domain includes about 10 different topic areas including: Care Records, Care Plans, Transfers of Care, Allergies and Intolerances, Adverse Reactions, Professional Services, Encounters and Episodes of Care, Health Concerns (Problem Lists), and Assessments.  The CCD contains all the elements of the CCR data set, which includes: Payers, Advance Directives, Support (Persons), Functional Status, Problems, Family History, Social History, Alerts, Medications, Medical Equipment, Immunizations, Vital Signs, Results, Procedures, Encounters, Plan of Care, Healthcare Providers.  And so on.

We need to figure out how to expose this underlying model of healthcare information that is embedded in the HL7 Version 3 standards. 

After that, we need to makes this information simple and easy for implementors to find and understand. The engineers implementing the HL7 standards are probably our largest audience of these standards.  They need simplicity.  Simplicity is a theme that I've been persuing for a number of years (actually, it was the central theme of my comments on the HL7 CDA Release 2.0 standard six years ago), and one that I will continue to persue more agressively in the coming years.

Attacks on HL7 Version 3 as being too complicated are certainly based on the experiences of many of these implementers.  They didn't appear just because one SDO doesn't like another, or one vendor or another didn't like HL7.  My own learning curve is pretty steep, and yet my understanding of how to use HL7 Version 3 came very slowly.  But you shouldn't need to understand how something is built in order to use it.  What you need to understand is how to "operate" it.  I don't fully understand how a motorcycle, a microwave or a computer works.  I certainly understand the controls and the general maintainance procedures, but I don't have to know how to manufacture these objects in order to use them.  The same should be true of HL7 Version 3 standards.

P.S.  After the meeting was over, and I was headed out, I picked up the phone and called a former collegue who is now also working on uses of NLP in healthcare at MITRE and connected her up to the group working on hData.  Score another connection for the O3C.