Two IHE Profiles for MeaningfulUse Stage2

It's another IHE week for me.  Patient Care Coordination and two other IHE domains are meeting just outside Chicago to prepare profiles for public comment.  One of the profiles that I'm working on this week, and another one that I was working on this time last year are especially relevant as we transition from commenting on Meaningful Use to actually implementing it in products.

InfoButton
The profile I'm working on mostly this week was almost prescient with respect to relevance for EHR systems in the US.  It's called Retrieve Clinical Knowledge and its an update of the HITSP T81 transaction that I've been playing around with for a couple of years.   Former HITSP-ites know it as a thin wrapper over the HL7 InfoButton URL Implementation Guide.

There are some problems that I discovered when I actually went to use this transaction in a prototype.  It's getting past time to move beyond the prototype stage, and I'd very much prefer to fix some of these issues:

1. It leaves the implementation of the request as either a GET an/or POST.
2. It doesn't specify what the response content format should be.
3. It doesn't specify error behavior.
4. It doesn't tell you how to authenticate with a clinical knowledge source (many sources are pay to use, and even ones that aren't often require a user name and password to access).
5. It doesn't address how to deal with multiple responses.
6. It didn't anticipate some innovative uses (e.g., to support retrieval of dynamic information, such as public health alerts based on symptoms and patient location).

The new profile addresses all of these issues.  Rather than immediately returning the content as some sort of document matching the search criteria, it returns a list of resources in Atom format (see RFC 4287) containing an entry for each resource which matches the query.

As I mentioned previously, I was completely surprised by the inclusion of InfoButton in the Meaningful Use rule, but had started a work item in IHE on InfoButton in which I could address the Meaningful Use requirements.  Unfortunately, the IHE profile will only be in Public Comment form, or I would have suggested it as the Implementation Guide for Stage 2 (and I still might in any case, given that most of my work on it will be done before the comment period closes). 

We added a couple of extension elements (using Dublin Core terms) to support bibliographic citations and provenance information to support two of the meaningful use requirements (§170.314(8)(v)(A) Bibliographic Citation  and §170.314(8)(v)(C) Funding Source respectively).  The other two: Developer and Release/Revision date were already supported in the Atom format (using the author and published/updated elements).  One of the technical co-chairs of PCC is from Canada, and she reminded me that the profile should be International in scope.  So while I was struggling with a way to handle the US requirements, I found a nice international way to address them using the Dublin Core. 

Reconciliation

The next profile I want to mention is the Reconciliation of Diagnoses, Medications and Allergies profile that PCC developed for Trial Implementation last year.  I've mentioned the profile several times on this blog.  The profile becomes even more relevant after you look at the proposed rule text from §170.314(b)(4) on Clinical information reconciliation in the 2014 Certification Criteria:

(4) Clinical information reconciliation. Enable a user to electronically reconcile the data elements that represent a patient's active medication, problem, and medication allergy list as follows. For each list type:
(i) Electronically display the data elements from two or more sources in a manner that allows a user to view the data elements and their attributes, which must include, at a minimum, the source and last modification date.
(ii) Enable a user to merge and remove individual data elements.
(iii) Enable a user to review and validate the accuracy of a final set of data elements and, upon a user's confirmation, automatically update the list. 

Medication reconciliation was already a requirement of Meaningful Use stage 1, but IHE had determined the reconciliation needed to address more than just medications when we were editing the profile.  As it turns out, it was a happy thing we did, because it appears that the folks at ONC agreed, at least in their proposed rule (and yet again, I really had no idea that was coming when I was the editor).    

  

I will be providing an overview of this IHE profile to the S&I Framework TOC Initiative later this week (which is another really good reason to write this blog post, because it counts as preparation for that call).  

The Reconciliation profile does two things:

1. It explains how the data appearing in a CDA document can be used to facilitate reconciliation,
2. It indicates what information must be recorded in subsequent documents with respect to the completed reconciliation,

Reconciliation, as described in the profile is a three step process:

1. Gather the data to be reconciled.
2. Identify information that is new, duplicated, overlapping, conflicting or superseded based on the (CDA) data elements present.
3. Interact with a healthcare provider who confirms corrects and updates the reconciled list.

The profile doesn't actually tell you how to do step 2 (except in one very important case).  But it does give you about 10 pages of really good hints as to what to look for.  For the most part, what it does do is tell you in those 10 pages is which data elements might help you synchronize the different sources. Synchronization is a vital term.  I think of reconciliation from a software perspective as a variant of what I do when I "synchronize" my smart phone with my personal organizer.  In fact, the one very important case mentioned above comes from how these synchronization applications handle some of the issues of identifying changed records on different systems (they use the same unique identifier for the item on both systems to detect matching records).

Unlike most IHE profiles which have multiple actors, the IHE Reconciliation profile has only one significant actor: The Reconciliation Agent (which is likely the end-user's EHR system).  This actor has several ways in which it can obtain data to be reconciled.  It could come from the EHR directly or via an exchange using one of many IHE profiles (XDM, XDR, XDS, or XCA).  It could also come through NwHIN DIRECT or Exchange.

The reconciliation actor has several requirements:

1. It SHALL present the demographics used identify the patient provided by each separate source of clinical information to the end user.
2. It SHALL highlight inconsistencies found during the automated reconciliation process and provide the clinician with mechanisms to adjust or correct the input.
3. It SHALL provide a mechanism for a clinician to add new information to the reconciled results.
4. It SHALL authenticate the clinician prior to storage of the reconciled data (this step may be combined with other authentication steps used to finalize the record).
5. It SHALL store the resulting data for future use by other actors as described below
6. It SHALL maintain the identities of recorded data items as specified in the profile details.
7. It SHALL generate appropriate entries on the reconciliation performed in subsequent CDA documents created by the system.

There's an interesting feature to the reconciliation agent.  The more systems that implement the "agent" in a sharing environment, the less work they actually need to do, because the reconciliation process becomes less of an effort as providers maintain the records.  When you first synchronized your phone with your laptop, it took a while didn't it?  That's because all of the linkages needed to be made between the two systems.  Each subsequent sync was much quicker (especially if you synchronize often).  The same is expected when more systems in an exchange environment implement the Reconciliation Agent.  In fact, when a Reconciliation Agent retrieves clinical information that has already been reconciled by another Reconciliation Agent, the result should go even faster, because of the additional information provided about previous synchronizations.  This is an example of a self-adjusting system using feedback, and it's the kind of architecture that should work well with ultra-large-scale systems (at least I hope that is the case).

A CDA document created by a system implementing the Reconciliation profile will be marked with a specific template id.  The presence of that template ID tells the receiver that the document contains reconciled data (it may also contain unreconciled data).  

Problems, Medications and Allergies sections in a CDA document produced by a system implementing the profile will mark the content that has been reconciled both in narrative and machine readable form.  The narrative tells the reader that someone did reconciliation at some point (including the who and when).  Putting this in the narrative makes it part of the legally attested content (according to the CDA standard) when the document has a legal authenticator.

The machine readable version of  the narrative provides a who and when in machine readable form, as well as pointers to the clinical data that was reconciled against, and the result of the reconciliation.  When Consolidated CDA was being balloted, I was still working on this profile.  We tried to make sure that this profile could also be used with that guide in HL7.

The IHE Reconciliation profile is presently in Trial Implementation.  That means it needs to be tested by several vendors at several connectathons before it goes to Final Text. I urge you to consider implementation of it in your EHR, especially if you have to meet the 2014 Certification Criteria here in the US.

-- Keith

P.S.  I promise to get back to Standards 101.  Just as soon as I ...