Template Identifiers, Business Rules and Degrees of Interoperability

One of the concerns that many have raised about HITSP, IHE and HL7 specifications on the HL7 Clinical Document Architecture is the number of different template identifiers that are needed.  Here's an example from a conforming HITSP C32 document illustrating the issue:

‹cda:ClinicalDocument xmlns:cda="urn:hl7-org:v3"›
 ‹cda:realmCode code="US"/›
 ‹cda:typeId extension="POCD_HD000040"
  root="2.16.840.1.113883.1.3"/›
 ‹cda:templateId root="2.16.840.1.113883.10.20.1"/›
 ‹cda:templateId root="2.16.840.1.113883.10.20.3"/›
 ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.1"/›
 ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.2"/›
 ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.5"/›
 ‹cda:templateId root="2.16.840.1.113883.3.88.11.32.1"/›
                           ∶

There are six different template identifiers in this document.  Each of these template identifiers asserts conformance to a collection of business rules which provide various levels of interoperability.  Let's talk about each one of the separately first:

CCD: ‹cda:templateId root="2.16.840.1.113883.10.20.1"/›

This template identifier indicates that the content of the document conforms to the rules of the HL7 Continutity of Care Document.  These rules indicate that when certain sections appear within the document they will conform to additional rules about what these sections contain, and may contain machine readable entries regarding patient problems, medications, allergies, immunizations, laboratory results, et cetera.

CDA Headers: ‹cda:templateId root="2.16.840.1.113883.10.20.3"/›

This template identifier indicates that the CDA Header will conform to certain rules regarding the inclusion of contact information for each of the individuals or organizations referenced by the document.  These rules are established by the HL7 History and Physical Note implementation guide.

IHE Medical Document: ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.1"/›

This set of rules identifies the document as being a medical document according to the IHE PCC Technical Framework.  Medical documents under that technical framework are required to conform to the previous requirements for CDA Headers (and state that they are conformant), should include a display stylesheet accessible via a mechanism appropriate to topology of the exchange, and must clearly explain any abscence of information in any section.

IHE Medical Summary: ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.2"/›
This set of rules identifies the document as a medical summary.  Medical summaries must conform to the IHE Medical Document rules (and state that they are conformant), and must also contain machine readable lists of problems, medications and allergies for a given patient.

IHE XPHR Extract: ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.5"/›
This set of rules indicates that the document conforms to the IHE rules for an XPHR Extract.  The XPHR Extract defines the minumum set of information that should be present in an exchange between an EHR and PHR system (Note that the less restrictive XPHR Update template is also permissible in a HITSP C32 document).  This requires the problems, medications, allergies, personal information about the patient, healthcare providers, and if known, information about payers, patient support (emergency contacts, next of kin, et cetera), advanced directives, sugical history and immunizations.  If other information is present (e.g., vital signs, family history, hospitalizations, et cetera) it must be provided in according to other rules.

HITSP C32: ‹cda:templateId root="2.16.840.1.113883.3.88.11.32.1"/›
This set of rules requires the use of certain vocabularies when conveying the information (e.g., SNOMED CT for problems, RxNORM for medications, et cetera), according to what appears in the HITSP C80 specification.  It provides further guidance on the use of the internationally oriented IHE specification on the US.  For example, in the international realm, conveyance of race and ethnicity is subject to regional restrictions (some regions require it, other prohibit it, and others such as the US make it optional but recommended).

Now, having gone through all of these different templates and explained (at a high level) why they are there, this question often arises: "Why can't C32 just say that it conforms to all of these without requiring the additional template identifiers?"

It could, but what would that mean?
1.  We would need to duplicate conformance statements from these various specifications in the C32 specification.
2.  Software that was aware of how to process a CCD (or CDA documents conforming to any of these other rule sets) but not aware of the C32 specification wouldn't know what to do with it.
3.  Test tools for C32 would need to duplicate content found in test tools for these other rule sets.
4.  Recievers of a HITSP 32 that didn't understand C32 but did understand IHE XPHR wouldn't be able to use them (really this is the same as #2 above).

The figure below shows how various trading partners (A through F below) will have some degree of understood interoperability based upon the various business rules asserted within the document.

What this diagram shows is that any of these two trading partners will have SOME degree of interoperability, and that the two partners at the top (E and F) would have the highest level of interoperability.  This would not be possible without the inclusion of assertions of all of the business rules that the document conformed to.

Demystifying SAEAF...maybe (SAIF)

The HL7 ARB and its CIO have mandated that we will use the (Services Aware) Enterprise Architecture Framework within HL7 to improve processes within the organization and to make our specifications the widest implemented.in the industry.  As a Cochair of the HL7 Structured Documents TC, it was pretty clear to me in Kyoto that we (SDWG in HL7) would need to make the next release of the HL7 Clinical Document Architecture project one of the Alpha projects for this new framework.  Nobody yet knows what this entails, but Austin Kreisler and I dug into this last night over dinner.  As I read through one of the presentations made by the ARB to several workgroups in HL7, I began to understand what it is.  We prepared a presentation based on that understanding for HL7 Structured Documents that was presented this morning, and spend a good bit of time talking about the SAEAF goals for CDAR3. 

I am now sharing some of my understanding here.  My sole purpose in leading the charge for this in HL7 is that I know that the blow was coming, and it is far easier to deflect it or redirect it if I lead into it.  Having worked through the example, I think one of the key problems that we've had in understanding this is a problem in how the information has been communicating.  I'm hoping to address some of those issues here.
Here's what I've learned thus far:

The key to implementing SAEAF in HL7 is in understaning the matrix which describes the different content that needs to appear (or not appear) within an HL7 standard.  The matrix appears below:

Now of course, it has to show up using all of these terms that only Enterprise Architects understand, and I don't have twenty years of enterprise architectural experience to understand it, and neither does most of the existing audience in HL7, never mind the audience we left behind.

However, after about an hour of reading (a lost art in this world of powerpoint), I began to understand what they (the ARB) were getting at.  It doesn't require an understanding of RM-ODP (although it helps), enterprise architecture, or all the current buzzwords around Service Oriented Architectures, or Architectural Frameworks.

What it does require is to answer twelve key questions about what you are developing as a specification.  Those twelve (3 x 4) key questions revolve around what I call the dot product of seven key concepts (3 + 4).  Ed Note: The dot product of two vectors (column and row heads) is the sum of the products of all terms in each vector.

The first three concepts deal with levels of abstraction:  Conceptual (20,000 feet), platform independent (conceptual after the first level of analysis), and platform dependent (realization of the analysis).  The next four concepts look at different viewpoints (areas of concern or perspectives).  These are the business perspective (which should need no further explaination), the information or semantic viewpoint (the specialist perspective, in this case, healthcare), the computational viewpoint (in this case, what we used to call the systems analysis perspective), and the engineering viewpoint (or programmer's perspective).  I may be somewhat off-base in my own analysis of what these particular viewpoints are, but that is because I'm not someone whose up on all the latest terminology here, however, this is close enough to start with.

So, an HL7 specification needs to indicate what it provides (or doesn't provide) for this dot product of the abstraction levels and the perspectives.  This needs to be explicit for each product of HL7, so that we are clear upon the product boundaries.  Asking the question is important, even if the answer is "no, we provide nothing here".  It gets the workgroup to think about that component, to see if there is something we should provide, and if not, who might actually be providing it for us (for example, one workgroup might not have an implementation if all they are providing is a functional model and requirements, whereas another workgroup might implement functional models produced by the first).

The next step is to ensure that the specification clearly has done the appropriate analysis to define the scope of work to be peformed.  This then needs to be reviewed (e.g., by a review board that checks that the results make sense architecturally) and verified.  The next step is to start developing the various artifacts.  Now, the results of each of these tasks is going to be targeted at individuals with specific skill sets.  The conceptual business level artifacts are going to be targeted at project sponsors, those responsible for understanding high level requirements and making funding decisions (C-levels, product managers, et cetera), whereas the engineering and implementation level artifacts are going to be targeted at application developers.

This results in a second matrix, which I show below.  I think this matrix will be much more comprehensible for many,  because it is buzzword free, and uses terms that should be comprehensible to most of the HL7 audience.  If I didn't get it right, please let me know.  The basic concept of this diagram is to identify the target audience for each of the different components of the dot product.  The importance of understanding who the target audience for each of these components is that it helps us establish whether we've hit or missed the mark with the different parts of an HL7 specification when it is evaluated.

Now, I'll provide a caveat.  I have no clue how close I've hit the mark with my own analysis of the SAEAF matrix that the HL7 ARB has produced.  I'm more than happy to hear your feedback.

Another realization that I had two nights ago while discussing SAEAF with some ARB members is that we need some way to measure our success or lack thereof with this work.  I think it would be very helpful for the ARB to pick a few key past projects from HL7 and, using the project scope statements, identify the architectural artifacts that they expected the project to produce, and THEN evaluate the results of the project.  It might be useful to look at three together as a group initially to identify objective criteria that could be used in a real evaluation.  Then the reviews should be undertaken by people (more than one) unfamiliar with the projects doing the first and second evaluations (it might be interesting to see how those who are familiar with the projects do compared against those that aren't).

   Keith

IHE Profile Review

On Tuesday of this week, the IHE Patient Care Coordination planning committee met for two hours to review five IHE Profile proposals in more detail. The presentations we reviewed can be found for each one below:

1. Discharge Summary
2. eHealth Summary
3. Perioperative
4. Document Templates
5. Chronic Care Coordination

The first three of these clearly have a nursing focus, and there are overlaps in the first two.  The Periperative proposal also has some overlaps with existing standards work in HL7 and we will be making sure that we aren't trying to duplicate existing work.

I've already blogged several times about the Document Templates proposal, and so won't go into much more detail.  We also woke up some friends in Australia at a nearly unforgivable hour to talk to us about Chronic Care Coordination.  What I find most interesting about their proposal is how the same technology they are currently using looks very much like some visions of medical home I've heard.  We'll be reviewing another half dozen proposals tommorrow.

Who is the Audience for HL7?

When I implemented my first HL7 interface, I printed out about 50 pages from the Version 2 specification, read it, and wrote, in about 4 hours, a working (but not fully functional) ADT feed for my application. That was six years ago, and I had been involved with HL7 for about 2 months. If I hadn’t needed it quickly, I could have handed the task off to the most junior of engineers on my team, and gotten something back in a few weeks that met the very minimal requirements that I had.


I’m very glad that I at that time I didn’t need a Version 3 interface, because there is no way it could have been completed in the same time frame. There are a number of reasons why it takes longer. Here are a few of the bad ones (there are also some good ones, but that isn’t the focus of this posting):

1. HL7 doesn’t provide any WSDL with its V3 specifications, but that’s the first thing my engineers ask for.
2. HL7 schemas often need manual tweaking for some of the more complicated models, but there are no instructions anywhere on what those changes are or why they are needed.
3. The XML has needless variation across different domain models.
4. What HL7 uses for modeling is only used in and by HL7.
5. Examples are notably absent from many of the specifications.

All of these are barriers to implementation of HL7 Version 3. Many of them completely stymie the engineers I’ve worked with across the healthcare landscape. I get to work with some pretty bright people. Many of them are the more senior staff associated with numerous different implementers of healthcare IT. If they cannot figure it out, then the problem is not with them, the problem is with us.

 

In order for HL7 Version 3 to be not just the best, but also the most widely used standard in healthcare we need to consider who our audiences are. Ten years ago that audience included junior and senior engineers as well as application architects. These days HL7 Version 3 seems to mean something only to application architects. We need to figure out how to enable the other consumers our work products, or we’ll never get there.

 

 

HL7 Working Group Meeting

Yesterday was the plenary session for the HL7 Working Group meeting in Atlanta.  I missed the first two hours of keynoe presentations due to transit delays.  Atlanta is having quite the rainstorm this week.  I did arrive in time for presentations by Dr.  Janet Corrigan, CEO of the National Qualify Forum, and from Dr. David Blumenthal, the National Coordinator for HIT (the US HIT Czar).

I enjoyed Janet's presentation, mostly because I agreed with what she presented.  We need to get quality measurement worked into the processes (guidelines) used for care (see what I had to say on the topic earlier this year) .  We are still in the opening stages of that effort, and at least we have folks who are working on Quality Measures now talking to folks developing HIT Standards.  I give Janet high marks, an A for her efforts.

Dr. Blumenthal's presentation was dissappointing.  I think part of the problem was that he didn't understand how well his audience understands what is going on in the US evironment.  Looking at the HIT Standards committee workgroups, anywhere between 25 - 40% of the members of each workgroup are HL7 members, and about 30% of the HIT Standards committee are also HL7 members.  Also in the room were about half of the ANSI/HITSP Staff and Leadership.  What I had hoped for was a vision of how Healthcare IT would benfit the population of this country, or some notion of how ONC was organizing to effect that change.  Unfortunately, almost all of what Dr. Blumenthal had to say about what is happening at ONC has been in my inbox for the past 6 months, and in the inboxes of more than half of the people in the room.  On the flip side there was very little that he presented that would have made the US National initiatives comprehensible to the international members in the room.  Overall, I would have to give him a D, but the fact that he came to talk to us is worth some credit, so I'm changing it to a C.

I'll be tweeting occasionally about the working group meeting, if you want to follow the discussion, search for #HL7WGM on twitter.

The Answer to Life the Universe and Everything

The answer to life the universe and everything is no longer 42, it is now 119.  At least that was the concensus of the HITSP Provider Perspective TC and the Care Management and Health Records TC as we reviewed what needed to be done to update HITSP Interoperability Specification 09 Consults and Transfers of Care for the next round of work.

Looking at the requirements for this specification, I've identified the cases where Capability 119 applies.

Capability	IER	Description
119	1	Provide authorization and consent
119	11	Identify provider based on patient preference
119	13	Send/receive notification of document availability
	14	Send/Receive health plan eligibility
	15	Send/Receive health plan authorization
119	16	Send/Receive clinical summary
119	17	Send/Receive transfer of care data
119	22	Send/Receive additional patient information
119	25	Send/Receive decision support data
119	28	Download historical health data
119	37	Update medication information
	43	Send/Receive accept patient
119	45	Send/Receive consult results report
	57	Identify provider based on health plan
119	60	Send/Receive discharge summary
119	62	Send/Receive encounter or full episode of care record
119	63	Request additional patient data
119	64	Send/Receive consult request/data

As you can see from the table above, capability 119 is quite a useful tool (in this case, it's not a hammer, but a leatherman).

The Care Management and Health Records committee recently updated this Capabilty in response to the Clinical Notes Extension delivered to HITSP by ONC.

I won't go into all the gory details, but in short, what Capability 119 requires is the exchange of clinical documents conforming the HL7 CDA Specification, using sections and entries conforming to the HITSP C83 CDA Modules specification (which relies heavily on C32 and the HL7 Continutity of Care Document).  ThC83 specification will be updated in the next public comment cycle following the one that is about to start.

We leave it up to the Interoperability specifications to further constrain the capability to a specific type of clinical document if need be (e.g., to allow the Consumer Empowerment IS to specify the use of the HITSP C32 Summary Documents using CCD).

I have to say that this capability stuff, as difficult as it wasis to put together, is certainly making my life easier.

     Keith

P.S.  Thanks to the Bean for keeping me sane as we worked all this out in committee.

IHE PCC Profile Submissions

Last night the deadline for proposal submissions to IHE Patient Care Coordination passed.  We recieved 10 Profile submissions detailed below:

1. Discharge Summary -- Supporting the Nursing Plan of Care in Discharge Summaries
2. eHealth Summary -- Supporting the Nursing Plan of Care in medical summaries
3. Perioperative Plan of Care -- Supporting the Nursing Plan of Care for Perioperative workflows
4. Document Templates -- Supporting the exchange of CDA Document Templates reported yesterday on this blog.
5. Chronic Care Coordination -- A workflow profile incorporating IHE profiles from several domains to support care coordination.
6. Completion and enhancement of the APR and LDR Profiles (two separate submissions)
7. Postpartum Visit Profile -- Supporting the exchange of information about post-partum care
8. Newborn Discharge Summary -- Supporting the exchange of details of birth and hospital care provided to a newborn.
9. Workflows -- Generalized IHE PCC and other Domain profiles into workflows for Emergency Care, Obstetric Care, and General Referrals

I see three common themes emerging from the above list:

1. Profiles incorporating the Nursing plan of care into the healthcare workflow.
2. Coordination of IHE profiles into workflows.
3. Completion of the obstetric cycle of patient care and emergence into the pediatric cycle.

These proposals will be discussed on IHE PCC Teleconferences September 22 and 24th.  On September 29th we will be a discussion profiles that affect PCC and the Quality, Public Health and Research domains.

Thanks to all who submitted profile proposals.  I look forward to your presentations and discussions on these in the coming weeks.  I'll report high level outcomes of the review meetings here in the coming weeks and be following the IHE PCC Domain for the next cycle.