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 ...

HL7 Offers Free Ambassador Webinar on MeaningfulUse Stage2 and HL7 Standards

Because We Can

I've been having and reading discussions about standardizing Advance Directives with a number of different groups.  There is a suggestion out there that it is time to create a standard format for conveying information about an Advance Directive, perhaps using CDA.  Others, coming from the US HIT Standards Committee Power Team seem to suggest that current mechanisms for recording Advance Directives in the Consolidated CDA need to be extended (see page 7).

The point made in the latter document is that it isn't enough to know that one exists, but that one must also know where to get it and how to access it easily, that it should (in stage 2) have information about CPR and Intubation, and in stage 3, it contain more detailed information and support versioning.

I don't support an effort to standardize the format of Advance Directives at this time.  While standardizing the information is necessary, the US policy environment is such that much more is needed before that can even be useful.  I'd rather not expend effort on it from a pool of limited resources without first ensuring that the end result will be useful.

One of the suggestions is that the document record information about whether a patient should be intubated or resuscitated.  This is challenged by the fact that orders for DNR and/or Intubation are Physician written orders, and have different standings in different states.  They may also be conditional based on a particular hospital stay or procedure, may be time limited, et cetera.  The first step, before "standardizing" such information would be to first understand the policy environment, and to make sure that all policy variations that need to be encoded are understood.  We don't yet have that information readily available in the US, and until we do, deciding how to "standardize" the format is kind of beside the point.  We can tell you how to transmit the information, but we cannot tell you how to interpret it.  How useful is that?

Some work has been done by Aging with Dignity to develop a "standard form", known as Five Wishes.  Even that widely accessible and broadly funded activity has run into policy challenges in developing a form that could be readily used in all 50 states of this country (right now, it only works by itself in 42 states, 8 others require "workarounds").

The next challenge is deep.  An advance directive can be subsequently overridden by a later version (as noted in the first link).  How would you ensure that you had the latest version?  To do so would require policy with regard to registration of such documents, combined with a technical infrastructure to support it.

Don't get me wrong.  I believe that it will be useful at some point to support standardizing the format of an advance directive, but there are certainly bigger fish to fry right now.  I'd rather see the limited resources we have applied to more critical issues.  We need more than "because we can do it" as a reason to create a standard.  The environment has to be right as well.  If the standard exists, but nobody can use it because the policy environment won't support it, we're just wasting time.

Footballs, Star Wars, and Dr. Doolittle

What do Footballs, Star Wars, and Dr. Doolittle have in common?  While normally unrelated, they come together in a post from Dirk Stanley over at his Free CMIO Perspecive blog.

Dirk starts out with a discussion of Push and Pull (remember the push-me-pull-you from Dr. Doolittle).  He notes that the lack of a national patient identifier prevents adequate use of pull.  However, push and pull are two sides of the same animal. Even with a national patient identifier, it is still necessary to send enough patient demographics to ensure patient identity when communicating, regardless of whether you are pushing or pulling. And while NwHIN Direct is dealing with the push side, NwHIN Exchange includes specifications for push and pull (see Query for Documents).

The remainder of his discussion is one what one would pull, which he describes as a football.  Dirk suggests that a single summary format be provided for all to use.

There's been some efforts from a few professional societies to move towards a single medical summary format. In fact, most of the documents providers use contain quite similar information:  Problems, Medications and Allergies top the list and are present in just about all of them.  I spent a good bit of time harmonizing the various definitions of the Summary of Care Record specified in the Meaningful Use Stage 2 rules.

Dirk describes his Hand-off note, which he calls the "Football".

It contains:

• Patient Name and DOB
• Emergency Contact Information
• Code Status
• Handoff Date
• Handoff From
• Expected Handoff To
• Author (who is pushing the football today)
• Co-authors (who pushed the football in the past)
• Allergies
• PMhx/PSurgHX (History including Problems and Surgeries)
• Significant Studies
• What I Did
• Active Medications (at time of Handoff)
• To Do List

The simplicity of most of his section titles (with the exception of PMhx/PSurgHX) is appealing , especially from a patient perspective.  All of this content is already available in the CCR and CCD and can also be included in any Consolidated CDA document (in other words, "been there, done that").  In fact, those documents include more detail.

So, what other stuff is missing?

• What about family and social history?  Patients keep getting asked for it, why not provide a record of what each provider knew?
• What about vaccination history?  This is important for ongoing health maintenance.
• What about a section on "What I decided or recommended?" to show the clinical judgments made during the encounter? 
• What about a section on "What I discovered?" that describes what information went into decisions or recommendations (e.g., significant physical examination findings). 

Those would make for a more interesting and complete football, but we are still back to what CCR and CCD already provided.

Clinical documentation serves several purposes.  It provides a legal and medical record of what was done during an encounter.  It communicates to other providers, or acts a reminder to the same provider in the future.  It acts as evidence that appropriate procedures were followed (e.g., for accreditation or billing purposes).  Healthcare providers in different settings need to record different information because the documentation serves these different purposes.

I think Dirk's idea that we can create a summary document that serves one purpose is laudible, but, I'm also certain that providers will never agree to adopt any one particular format that doesn't address their workflows.

At one point in time I knew of a site where two providers each had their own documentation format for what they did in a visit, duplicated with slight variations to deal with different state rules.  Neither would agree to use the other's format, nor did they desire to consolidate that two different state variants, even though the documented the same things even in the same order.  Unbeknownst to them, it was possible to encode the headings they used identically to a particular vocabulary (LOINC), and that is what the software I was deploying at the time did. So as far as the software was concerned, the data was similarly encoded and could be compared in meaningful ways in the application, even though the providers saw it differently.  This becomes very important.

Healthcare providers are very jealous of their processes.  I'm not sure I'd go so far as to introduce a new process, or a new document format to them.  Instead, I'd develop a better way to classify the information they already provide.  LOINC provides a great list of codes for document sections, but doesn't connect it well into an ontology.  Consider the following different ways that one can represent a reason for care:

• Admission Diagnosis
• Reason for Visit
• Chief Complaint
• Reason for Referral
• Pre-operative Diagnosis
• Pre-procedure Diagnosis

Each of these is used in different contexts, and some contexts even use several of the above.  Yet I see little in medical ontology that describe these different data points as describing reasons for care.  I don't see a need to harmonize the different contexts to say "Reason for Care", but I do see a great deal of utility in developing an ontology that links these different kinds of "reasons for care" to a single code so that systems can reason across these contexts.

While Dirk asserts that we need a new document to harmonize care, I think a better way to handle the challenge would be to codify and relate the contextual knowledge across the different kinds of clinical documents.  That way, we could enhance existing processes and workflows, rather than replacing them.

Harmonizing Value Sets in MeaningfulUse Stage2

Recently in discussions about Meaningful Use Stage 2 Certification criteria and in subsequent discussions on quality measures, someone pointed out inconsistencies in value sets used for smoking and/or tobacco use.  The other day, I posted a list that Cecil Lynch had provided that maps the Meaningful Use terms to SNOMED CT codes.

I took a look at quality measures that CMS proposes for 2014.  I didn't see any references to tobacco or smoking in the Hospital measures, but two measures do reference tobacco or smoking in the EP measures:

One measure: NQF 28, clarifies that screening for tobacco use includes "any kind of tobacco".
Another measure on Preventive Care and Screening from Quality Insights of Pennsylvania/Centers for Medicare & Medicaid Service explicitly references cigarette smoking only in one of the denominators:

Denominator 2: All patients aged 20 through 79 years who have Multiple Risk Factors (2+) of the following: Cigarette Smoking, Hypertension, Low High Density Lipoprotein (HDL), Family History of Premature CHD, or Age (men ≥ 55; women ≥ 65)

The challenge with either of these measures is that they cannot be computed from the Meaningful Use standard for smoking status:

(l) Smoking status. Standard. Smoking status types must include: Current every day smoker; current some day smoker; former smoker; never smoker; smoker, current status unknown; and unknown if ever smoked.

Many clinicians have suggested that the vocabulary standard for smoking status be broadened to include any tobacco use.  That still wouldn't solve the problems across these two measures.  Other clinicians will point out that any kind of smoking should probably be included in the second measure I described.

The real point here is that these and many other terms need to be harmonized across Meaningful Use and the proposed quality measures.  This problem is not isolated to smoking status, it has been reported to be present in a variety of other quality measures.

My hope is that current efforts towards development of a publicly accessible value set registry will go a long way towards making this possible.   But until that is done, and CQM developers take advantage of it, we'll continue to be asked to record one thing, and compute on something else.

IHE Cardiology Technical Framework Supplement Published for Public Comment

A CDA Implementation Guide for Cardiac Catheterization reporting...

IHE Cardiology Technical Framework Supplement Published for Public Comment The IHE Cardiology Technical Committee has published the following supplement to the IHE Cardiology Technical Framework for Public Comment in the period from April 20 to May 20, 2012: Cath Report Content (CRC) Comments received by May 20, 2012 will be considered by the Cardiology Technical Committee in developing the trial implementation version of the supplement. The document is available for download at http://www.ihe.net/Technical_Framework/index.cfm. Comments can be submitted at http://www.ihe.net/cardiology/cardiologycomments.cfm.

Forward Compatibility and the use of Templates with HL7 CDA

I had an interesting conversation with Wes Rishel this afternoon regarding his post on "Frozen Interface Syndrome" in which he talks about bilateral asynchronous cut-over.  He brings up an excellent point, which is that there need to be principles in the development and revision of standards in which we enable compatibility at the same time as we allow for advancement, to avoid freezing interfaces.

There's a phrase used in standards development that talks about backwards compatibility.  A standard is said to be backwards compatible when it enables all features of the previous version to be represented in the new version.  This ensured that there would be a smooth transition from one version of the standard to the next because it ensures that functionality is maintained across versions.  But it is insufficient to allow for bilateral asynchronous cut-over.  To do that, we need to design for foward compatibility.

Templated CDA goes a step further because there are ways to develop standards that ensure that:

1. Systems expecting content formatted according to a new version of the standard can layer functionality to downgrade gracefully upon receipt of content formatted according to the old version. 
2. Systems expecting content formatted according to the old version of the standard can understand what to do upon receipt of content formatted according to the new version.

Each template identifier asserted by a component of a CDA document is immutable with respect to compatibility breaking changes, by agreement of HL7 Workgroups.  I expect this principal will be formalized in the next version of the HL7 Templates standard.  It is one that has been followed routinely for the past half-decade by HL7, IHE, HITSP, epSOS and other organizations developing templates for CDA and HL7 Version 3 messages.

This has some challenges, because if you make a compatibility breaking change in template X producing X.1, and template Y requires X, and template Z requires Y, then you must also change the identifiers of templates Y and Z to enforce the use of X.1 instead of X.

To give a concrete example, CCDA presently says that an Allergy template may contain a severity template.  Let us suppose that healthcare has advanced to the point that we are ready to say that severity SHALL be provided with all allergies.  At that point, we want to say that the Allergy section requires the new allergy template with the required severity, and so this becomes a "compatibility-breaking" requirement on the old section, and so must also be assigned a new identifier.  And any document that wants to require that new section also breaks backward compatibilty, and so requires a new identifier.

But a system that understands the old allergy template should also be able to understand the new one.  And it will also be able to understand the new section and the new document template. The problem is that it was never designed to know about these new templates.  And so we must tell it that the content it receives also conforms to the older template structure.   We would do that by asserting conformance to both the old and the new templates.

One would hope that we could take advantage of this notion of forward compatibility as much as possible in all future development of CDA templates, as it provides a mechanism to allow for bilateral asynchronous cutover that Wes and I would both find desirable.  You'll note that these principles are already enabled via the incremental interoperability that HITSP and IHE used by layering new templates over existing HL7 templates providing varying degrees of interoperability.   

I'll note that this mechanism does not address is the situation we are in today with regard to HITSP C32 Version 2.5 and its use of CCD 1.0, vs. the Consolidated CDA description of CCD 1.1.  In that case, we can apply forwards compatibility in most, but not all cases.  Due to limitations in existing care provision models at the time that CCD 1.0 was created, and their current state when CCD 1.1 was created, there are some templates that just aren't compatible between versions.  There are transforms that can be applied to enable compatibility for many of the exception cases (I won't say all yet, because I haven't finished my analysis).  I'll address how to do that when I get more time to focus on my Changing from HITSP C32 Version 2.5 to Consolidated CDA post.

In future versions of the Consolidated CDA guide, I expect similar situations to be quite rarely encountered, and so HL7 should be able to ensure forward compatibility in subsequent editions with little challenges.

On a final note, at the very least, when receiving a CDA, even one which an application doesn't know to interpret, every application should be able to display it.  That provides at least a base level of interoperability between systems that should be present with just about every CDA implementation.

  -- Keith

P.S.  You'll note that I have yet to catch on to using the acronym CCDA for Consolidated CDA, but I recently noted that it does put the CCD back together with CDA, and so maybe I will adopt it.  I just don't know how I feel about that yet.  What do you think?