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.

An IHE Profile Proposal for Document Templates

As promised last week, attached is the copy of a profile proposal that I just submitted to the IHE Patient Care Coordination Domain of Integrating the Healthcare Enterprise.

Proposed Profile:	Document Templates
Editor:	Keith W. Boone
Date:	September 15th, 2009
Domain:	Patient Care Coordination
The Problem
Presently, HL7, IHE, ANSI/HITSP, ePSOS and other organizations worldwide are defining templates for the HL7 Clinical Document Architecture that allow for validation of the document content. However, these templates do not allow for easy creation of documents within an Electronic Medical Record system. Providers want to be able to use templates to support reuse of data already contained within the EMR. The problem is that there is no defined interchange format for document templates that allows an EMR to import a document, section or entry template and use it.
Key Use Case
A professional society develops a document template to gather the appropriate information to provide care for a specific condition. Providers want to use that document template in their own EMR systems. They connect to the professional societies registry of document templates and locate the appropriate template by the condition. Next they download the template to their Electronic Medical Record System. The EMR imports the template, and makes it available to the provider to use inside the electronic medical record system. The provider can now create documents using that template, and reuse section or entry templates found in that template in other documents.
Standards and Systems
Electronic Medical Record systems Template Registries IS0 15000 Electronic Business Extensible Markup provides a schema (ebRIM) to describe information stored in document registries. This schema could be used to describe information about the template. ISO/IEC 11179 describes the framework for metadata registries which could house template metadata. HL7 CDA Release 2.0 describes the structure of clinical documents. ISO 19757-3 Rule-based validation — Schematron describes a rule based language for verifying that implementations are producing correct XML. HL7 Version 3 Standard: Specification and Use of Reusable Constraint Templates, Release 1 (DSTU) describes a mechanism by which templates can be defined for use with HL7 Version 3 (e.g., CDA) standards. HL7 Version 3 Standard: Context-aware Information Retrieval (Infobutton), Release 1 defines a mechanism by which information can be retrieved based on a specific context. Context-aware information retrieval (Infobutton) URL-based implementation guide describes a URL-based implementation which could provide a REST service to locate templates.
Discussion
IHE has already developed a large template library and has the necessary experience developing and using document templates. IHE should develop the necessary profiles to house clinical templates within a template registry, and to provide access to those templates to an EMR system.

A Scheduling Use Case

Tomorrow morning begins the HITSP Panel Meeting. At the same time, the HIT Standards committee is meeting. If you know a little something about these organizations, you know that a good deal of cross membership exists, and that the chair of the HITSP Panel is also the Vice-chair of the HIT Standards committee, and that many of the HITSP TC cochairs are also on the HITSP Standards committee or one of the workgroups.

I might recommend something like this as a standard for communicating calendar information: http://xml.coverpages.org/newsletter/news2009-09-10.html#cite4

Interestingly enough, one of the use case extensions for this year is Scheduling, for which HITSP will recommend a harmonized standard to support scheduling of patient appointments. We've already identified iCal and the various related IETF standards like the link above for review and analysis to see if they could meet the requirements. And you know what, they even work pretty well with applications deployed on Microsoft, Apple and Linux platforms. Aren't standards wonderful. Now if we could just get ....

Oh never mind.

Job Titles

I'm trying to write something every day. Today I don't have that much urgent to share, so I thought I'd share a little bit of personal introspection on job titles.

Recently I had to order new business cards because I've used mine all up (500 in 40 months), that's about 3 a week, which doesn't seem like many. I get to pick the title I put on my card, and changed what had been there to Standards Architect. It seems to be the simplest title to put on there without going overboard. Here are some of the different titles I've used or been given over the past few years:

• Lead Interoperability Systems Designer -- I design systems so that they are interoperable.
• Interoperability Architect -- I make systems talk to each other.
• Standards Architect -- I design and build healthcare standards.
• Standards Geek -- This is the title I use verbally to describe what I do. It seems to connect with people, but wasn't quite what I want to put on a business card (well OK, it was, but...)

But my favorite job title of all is the one my oldest daughter assigned to me about three years ago when she had to tell her classmates what I do for a living:

He's an International Healthcare Standards Agent --- Dah, ta da! Complete with a little dance at the end, and with all the letters clearly capitalized, and the word "Agent" emphasised!

That got me to thinking this morning about how what I and others like me do is similar and different from what a "Secret Agent" like 007 does. With regard to similarities:

• We work on projects involving national governments and international organizations.
• We deal with a small group of people internationally who know each other fairly well
• We are treated as regulars at restaurants thousands of miles from home.
• We have highly evolved palates (see Sushi).
• We have a very congenial discussions with the "opposition" in a variety of interesting settings (see below)
• We show up in exotic places like Rio, Kyoto, New York, London, New Orleans, Cologne, or Amsterdam.
• We have a collection of highly sophisticated technological gadgetry to help us do our work (see below for an example).
• We have special pens (at least I do) that perform multiple functions, and have built in lasers.

The one thing that is very different is that nothing that we do is secret. In fact, the very principal of the standards development process is to be open and collaborative with all involved.

It's so not secret that I'll be publishing an IHE Profile submission that I'm working on in a few days on this blog. If you have one, there's still time to submit it, see this post. If you need help, drop me a line or post a comment here, and I'll see what I can do to help you put it together.

Keith

Healthcare Reform

Thus far I've stayed out of the debate on healthcare reform, mostly because I'm a technology geek. But I'm also a taxpayer and a consumer, and therefore entitled to some opinions on the topic of reform. I'm not very well versed in all the issues, which makes this even harder to write about.

Thinking about healthcare interoperability, if I do my job right, the time needed for tasks that are currently performed manually will be greatly reduced. That means that effective interoperability will either put people out of work, or what I hope is more likely, allow them to spend their time on other tasks that don't get enough attention.

When I think about effective health reform, I see some of the same dynamics and this introduces some fairly large problems because the people that might be put out of work, or compensated at a reduced amount have some very strong lobbies. An effective health reform program will hopefully reduce both the need for and cost of services. My hope is that the costs and services it reduces are those dealing with the later stages of disease (because we don't need as many as a result of better care, not due to rationing), and non-essential administrative services.

A classic way to reduce non-essential administrative services is to deal with them at a large scale. We see this all the time in mergers and aquisitions, where most often, the hardest hit jobs are those that are non-revenue producing (HR, Administration, Finance). Our current system of payment is overripe for that sort of reduction in force.

One of the chief complaints about the public option is that it puts payers on an unfair footing, since the government can operate at an economy of scale that payers are not able to. If the Federal government can manage it and compete with the payers, I'm all for it. It may be an unfair footing, but from my perspective as a patient, I'm not terribly interested in being fair to anyone but patients and to some degree doctors. Frankly, I really don't understand what payers have done for me that couldn't be done better some other way.

Another aspect to look at is that payers should be able deal with those same economies of scale that the government does. Perhaps if they had the same opportunities that the Federal government had, they wouldn't complain so much.

This leads into the next issue, which involves the rights of the States. What makes for acceptable healthcare coverage, and who should define it? It's a national issue, but the States want their own say. If we were able to define an acceptable level of healthcare for all citizens of the US, and insurers were able offer the same level of service across the states, that would allow them to reduce there own costs. Unfortunately, unlike other countries, we don't have one national government that is really in charge of the problem, we have to deal with the states as well.

The scariest think about all of this is how complex this topic appears. The text of the current bills according to NPR this AM exceeded 1000 pages. I know healthcare is complicated, but do we really need 1000 pages to reform it. Makes me think I want to hire Jorge X. McKie to take away their word processors and give them a quill pen and two pieces of parchment. Even the ARRA was less than 500 pages, and the HITECH portion, a mere 50. A fount of brevity by comparison.

Quite honestly, I don't think the problem is that complex. The reality is that the real solutions are simply to harsh for our current system to accept. It's going to mean that we need to change over time, and what cannot be changed in this generation, will have to wait for the next one. That's why I like some of the discussions around setting a deadline. If we cannot resolve the problem under the current system by 2015, then we take more "drastic action". It's like in healthcare, where we look at different options for treatment, we go with the less invasive first, and if that fails, then we consider surgery.

Of course, in any plan of care, getting the patient to acknowledge that they have a disease is critical. Our current system of paying for care is diseased, and needs treatment.

The Making of an IHE Profile Part 2

Yesterday, several members of IHE, HITSP and HL7 spent several hours describing the IHE process to people at the PHIN Conference. Then we developed several IHE Profile proposals and selected one that will be passed on to the appropriate IHE Committee for review for the 2010-2011 development cycle (see IHE Patient Care Coordination Accepting Profile Proposals last month).

The first step of our process was to brainstorm ideas. Here are just some of the ideas that we came up with (there were a few more, but I failed to copy all of them down in my exhaustion after 10 days of travel, so I'm working from memory) :

• Case Reporting Workflow
  Reporting Public Health Cases from an EMR or possibly a PHR using existing clinical data, gathering additional case reporting data. This could also be expanded to further support case investigation.
• Cancer Treatment Data Gathering and Summarization
  Gathering cancer treatment data in a Cancer Registry from numerous data sources, and providing (possibly on demand) a summary of cancer treatment.
• Clinical Terminology Services/Vocabulary Exchange
  Supporting the exchange of terminology information for use within clinical decision support, Electronic Medical Record Systems and quality reporting systems.
• Alerting Dissemination
  Disseminating alerts and providing them at the point of care.
• Elligibility Workflow
  Obtaining information about a patient's elligibility to participate in a particular program, making a determination about their elligibility, obtaining consent to participate in a program, and to share information with the program, and enrolling the patient in the program.
• Emergency Department Surveillance
  Gathering data from emergency department visits.
• Forms Exchange
  Exchanging and deploying data collection forms from State public health to local public health.
• Electronic Laboratory Reporting
  Gathering laboratory data for surveillance.
• Electronic Master Patient Indexing for Public Health
  Supporting the use of a single EMPI for public health programs.
• Exchanging Disease Treatment Data with Surveillance Programs (e.g., Immunization and Influenza)
  Connecting different information systems used for public health with each other to see how treatment impacts the spread of disease. This could include passing a summarized data set between registries containing treatment data (e.g., Immunizations) with systems that monitor the spread of disease (e.g., Surveillance).
• Message Validation Services
  Supporting the validation of messages at runtime based on specifications.
• Gathering and Reporting Vital Statistics
  Reporting the details of birth or death to a vital statistics registry.
• Exchange of information about Healthcare Associated Infections
  Reporting Healthcare Associated Infections to public health officials.

Then we reviewed the different ideas and talked about what IHE has to offer already in these areas. In many cases IHE had a profile to meet the needs, possibly more than one. Many of these ideas involved:

1. Managing patient identity, for which the IHE Patient Identity Cross Referencing (PIX) and Patient Demographics Query (PDQ)profiles apply (also available for HL7 Version 3).
2. Gathering information from providers treating a given patient, for which the IHE Cross Enterprise Document Sharing (XDS.b) profile, and the Document Metadata Subscription (DSUB) profiles apply, as do the various content profiles from the IHE Technical Frameworks (e.g., the PCC domain's Emergency Department Encounter Summary (EDES), the Lab domain's Sharing Laboratory Reports (XD-LAB) and Laboratory Testing Workflow (LTW).
3. Exchanging dynamic requests for additional information, for which the IHE Retrieve Form for Data Capture profile applies.

There were several places where there are still gaps in the standards. On the alerting side and in a few other places, the ability to exchange rules that could be used for clinical decision support, or specific guidelines for treatment, or alerts, is still missing some critical standards. Another place where standards are missing or incomplete are document templates or messaging guides for reporting vital statistics information. In all of these cases, IHE members are involved in other standards organizations and are engaged in moving these activities forward.

Next we divided up into three groups, and each group selected one or two of the ideas that appeal to them to develop a brief profile proposal. The proposal needed to include:

1. Statement of the Problem
2. A Key Use case describing the problem
3. Identification of the Systems involved
4. Identification of Standards Available
5. Further Discussion

After developing the proposals, each team was given time to present them and answer questions. I asked the same question of each team, which was for them to somehow quantify the value or impact of that proposal on the existing situation in terms of patients served, workload reduced, et cetera. This is such a useful question that I've proposed adding it to the brief proposal template, and will be quizzing profile proposers for these details.

As a result of this tutorial at PHIN, we produced three different proposals, which are in bold above. The top vote getter is at the top of the list, and we will be moving that forward to the Quality, Research Public Health domain. However, there were no losers here, because the other two are also being persued by the groups who were involved. The Clinical Terminologies proposal will be passed along to IT Infrastructure, and the Cancer treatment data gathering and summarization will be passed along to either PCC or QRPH.

We were thrilled with the results of this effort, and I will be following these proposals as they move forward in the process. In addition, IHE PCC will be reviewing a second round of proposals earlier in 2010. This is in expectation that there will be additional demands for new work in early 2010 coming from various international groups, and to better balance our workload for the coming year.

I hope that we will be able to provide a similar tutorial session at HIMSS in February of this year, and I will also update you on the progress there.

HITSP ANNOUNCES Call for Participation on Consumer Preferences

Call for Participation
Healthcare Information Technology Standards Panel
HITSP Consumer Preferences Tiger Team

The HITSP Tiger Teams and Technical Committees will soon begin to address the standards harmonization process for Consumer Preferences. HITSP is seeking to add subject matter experts to assist with this task.

Requirements for participation:
Your organization registers to be or is a member of HITSP. Your area of expertise can be in any of the following areas:

• Overall, standards for classifying and categorizing a wide range of consumer preferences related to privacy, security, care delivery and associated service needs


• Privacy and security standards for categorizing and coding consumer privacy preferences


• Privacy and security standards for controlling access to health information


• Standards for identifying/selecting specific consumer preferences including advance directives, DNR, proxies, surrogates, family member access, and others


• Standards for consumer preferences related to care or associated service needs, including communication needs (appointment reminders, lab results, others), conform measures, and others

The Process:

• HITSP is establishing a Consumer Preferences Tiger Team, which will operate under the joint guidance and direction of the HITSP Security, Privacy and Infrastructure Technical Committee and the HITSP Consumer Perspective Technical Committee. Co-chairs of the Tiger Team are Walter Suarez, MD and Mureen Allen MD.


• The Consumer Preferences Tiger Team will meet periodically via conference calls and F2F meetings to perform all the HITSP tasks related to the harmonization and interoperability standards review and selection to address the needs identified in the ONC Consumer Preference Requirements Document.


• The Consumer Preferences Tiger Team will:


• Participate, review and comment on the ONC Requirements Document development, as appropriate


• Develop a HITSP requirements analysis and standards selection document (or equivalent)


• Identify, evaluate and select recommended harmonized, interoperable standards, including reuse of existing standards using HITSP Tier 2 criteria


• Identify gaps and develop a roadmap process to address those gaps


• Develop a HITSP interoperability specification, Capabilities, Service Collaborations, or any other appropriate HITSP harmonization construct to address the information exchange interoperability requirements.


• The Consumer Preferences Tiger Team will develop a more detailed Statement of Work, work plan and timeline, consistent with the overall ONC timeline set for this topic.

Meeting Logistics:
Typically HITSP will conduct a standing weekly conference call with web collaboration. The workload may necessitate additional conference calls. Additionally, there will also be one “Face-to-Face” meeting planned in conjunction with HITSP Tiger Team and Technical Committee activities during the remainder of 2009.

To Volunteer:
If you would like to volunteer to participate in this groundbreaking activity of the HITSP Tiger Team and Technical Committees please contact Allyn Clemons, HIMSS/HITSP Standards Harmonization Coordinator at aclemons@himss.org.

For more information please contact:
Johnathan Coleman, Facilitator: jc@securityrs.com

For background information regarding recent postings, meeting activities, and new member participation go to the HITSP web site at http://www.hitsp.org/

CONNECT Code-a-thon

One of my collegues was recently at the CONNECT Code-a-thon held last week. CONNECT is an open-source initiative being developed through the Federal Health Architecture to connect communities through the NHIN using HITSP developed specifications. What follows is a brief summary of his observations. Note that I personally was not present (due to HITSP meetings the same week in Chicago).

He observed that the tools are good, and include a complete open source HIE package, including the Mirth Interface Tool, the Sun/Mural EMPI Solution, NIST's XDS Registry, the GlassFish ESB and more. One of his concerns was that implementation still requires sophisticated domain knowledge and persistence to make them work for an implementation. While the tools are open source and platform independant, they have so many parts (an Enterprise Service Bus, a Database, an application server, a JDK and more) than many developers at the conference spent the entire day trying to figure out how to host it.

He complements the archicture as being very modern. However, much of the implementation still passes through the GlassFish ESB. Much of the documentation speaks of two modes of operation, with and without the ESB. There is also mention of avoiding being tied to any particular component (ESB, application server, database, et cetera). Some redesign efforts in release 2.0 and 2.1 and the upcomming 2.2 around the messaging seem to be targeted around addressing performance issues. Experiences of my own and reports from others with architectures that rely heavily on an ESB leads me to believe that they are encountering similar issues, but that is only a guess. So, it appears that the architecture is still in flux, but that they are also addressing the right issues.

The FHA approach with CONNECT appears to be gathering steam, but significantly sized pilots are still needed. As best we can tell, the pilots with the Social Security Administration, Beth Israel Deaconess and MedVirginia have processed transactions on the order of 1000's. This isn't surprising given the SSA use case is for reporting on disability claims, but I know also from prior experience that a medium sized community hospital can product millions of documents a year. A pilot with the Veterans Administration and Kaiser Permanente may result in more data being exchanged. However, it too only addresses about 1500 patients.

Another concern heard over data exchange with the Federal Government are the federal security and privacy requirements specified in FISMA. FIPS publication 800-53 from NIST describes what is required, and a quick reading of this 188 page document should make it clear that these requirements are much stronger than those for compliance to the HIPAA privacy and security rule, or regulations that are required under ARRA.

FHA, NHIN and the CONNECT open source project are certainly aligned with initiatives in HITSP and IHE. They have developed what seems to be a fairly complex layer addressing Security and Patient Preferences that is much more involved than support for the HITSP TP20 and TP30 specifications or the base standards recommended by the HIT Standards committee. The requirements for exchange of patient preferences are still being developed by ANSI/HITSP in conjunction with NHIN and ONC, and so the work here may not be fully aligned with the outputs expected from HITSP later this year. I expect due to the fact that these groups are all working together now (see I need a new Joke) that future releases of CONNECT will be better aligned.

CONNECT has engaged some very bright people in this effort, including several who have been involved in previous projects such as AHALTA (The DOD's effort similar to the VA VISTA effort), and members of the Federal Health Architecture. Having worked with a few of them, I can tell you that this is a very bright group. Unfortunately, only two EMR vendors were represented at the Code-a-thon, my collegue from GE and another that I know well from Epic. Due to the timing, many people involved in HITSP activities were in Chicago at the HITSP face to face, which certainly could have had an impact on their attendance.


It will certainly be interesting to see how CONNECT evolves. They seem to have made a good start, and there is certainly more to be done.

The Making of an IHE Profile

Tommorrow is the last major day for the PHIN confernce and interoperability showcase, but I'll be in Atlanta for one more day. Thursday morning, Lisa Spellman, myself and several others involved in the IHE Quality, Research and Public Health domain will be leading a workshop with members of the public health community.

The workshop will cover standards activities and IHE profiling relevant to public health in the first half. The second half is one of the coolest training sessions I've ever done. The first and last time I gave it was at an IHE Canada meeting. Basically we take the participants through a mini-planning meeting. The way that it works is this:

1. We describe the IHE profile process, and the content of a brief profile proposal.
2. We break the room up into small groups, that brainstorm real problems that they thing standards could solve.
3. We list the results of the brainstorming on a white board, with brief descriptions from each group.
4. We discuss the ideas, and may merge or split ideas based on their size.
5. We then vote on the ideas, and select the top three or four to look into in more detail.
6. We break up into larger groups, and assign one of the top vote getters to each group.
7. The groups develop the brief profile proposal (a one page document).
8. They present the proposals to the entire group.
9. We discuss them some more.
10. We vote on the top vote getter.
11. We assign one or more editors, and we bring it to the right committee in IHE.

If you are at PHIN this week and staying through Thursday, I heartily reccommend this session. It's a lot of fun, and a very easy way to learn about how IHE works.

If you aren't at PHIN, but would like to run a similar workshop at another Healthcare event, please contact me and I'll pass the request along. E-mail me (find it on the HL7 Structured Documents Workgroup Page), leave a comment below, or DM me on Twitter for details.

We've been Dilberted

Scott Adams takes on the Standards organizations

How does he do it?

One of my collegues is the father of two very successful standards worldwide. Besides having an endless dedication to making sure his babies are successful, many have often wondered how he does it. I think today I just figured it out, and it mirrors an approach that I've started taking at a somewhat smaller scale. He has his ears out for every single activitity that is remotely related to the work. As soon as he hears something interesting, he adds a bit of sage advice (probably more than a bit), to point people in the direction he would like to see them go.

Now if you do this enough times, eventually one of these interactions will end up with a positive result. Also, you will gain experience figuring out how much of your time you should invest in each one. It's like building a venture portfolio. You fund 10 ideas, and if 1 of those succeeds you at least break even or better, and if two of them do, you make a killing.

One of the things that I realize being at PHIN is how many different projects there are going on where I can make a small difference in direction to get people pointing in the same direction. One of the things that I can do is be a connector (read The Tipping Point by Malcolm Gladwell) of people and projects. By investing just a little of my time to get the right people talking to each other, I can get more people moving in the same direction (usually). More and more I find myself using one of my collegues favorite phrases "You need to talk to ...".

Sometimes I'm on the recieving end of these communications (and not just from my collegue, although he accounts for many of these). I ignore these introductions at my own peril. Too many times, the person telling me this is right, I need to be talking to more people and getting more opinions and buy-in from diverse groups.

The power of having two or more diverse groups moving in the same direction is best understood by looking what happened with CCR and CDA, which produced CCD. CCD is now the basis for our national standards, and basically means that CCR has permanently influenced CDA. This is a good thing.

The same thing happened recently with IHE and The Continua Health Alliance. These two organizations were moving in nearly the same direction, but hadn't converged on the same solutions. Last week they announced that after working together for several months, they have converged on the same solution, which is now being looked at by ANSI/HITSP to resolve gaps for device connectivity.

So, who do you need to talk to, and who should I be talking to. Let's talk.