Democracy In Action

I listened today to the HIT Standards Committee discussion on Electronic Document Standards for Discharge Summary & Other Encounter Summaries presented by Dr. Jamie Ferguson, leader of the Clinical Operations Workgroup.

The slides Jamie used are embedded below.  You can find the official deck on the HIT Standards FACA website when they get past their technical problems.

Clinical Operations Workgroup Report to HIT Standards Committee 06/30/2010

As Jamie and these slides point out (see slide 2), users of CCD and CCR also need to provide other kinds of documentation, for example, Discharge Summaries (required in meaningful use).  What the workgroup found (no surprises here, especially if you read my second ever blog post), is that CCD and CCR don't support the kinds of information needed for other kinds of documents.

As John Halamka stated in the meeting:  "The last thing we wanted was a CCD that has been modified for every hospital, because it is a standard document."   Nancy Orvus pointed out later that the CCD was never intended to be the future of all clinical documents.  She's absolutely correct, and I should know, having been one of the editors and a cochair of the workgroup that created it.

Jamie Ferguson points out that there is a pretty well-recognized group of content templates that can be used.  I'll add that HITSP already did a lot of review of those templates over the last four years, and you can find a pretty good collection of them in the HITSP C83 CDA Content Modules specification.  HITSP Care Management and Health Records modified Capability 119 Communicate Structured Document to support the use case that addressed this very same problem.  The following quote is from that document:

1.1 CAPABILITY OVERVIEW

HITSP/CAP119 Communicate Structured Document addresses interoperability requirements that support the communication of structured health data related to a patient in a context determined by the author of the document. This Capability supports the exchange of a broad range of CDA documents related to clinical patient care. The following are examples of the type of CDA structured data that are supported:

• Continuity of Care Document (CCD)
• Emergency Department Encounter Summary
• Discharge Summary (In-patient encounter and/or episodes of care)
• Referral Summary Ambulatory encounter and/or episodes of care
• Consultation Notes
• History and Physical
• Personal Health Device Monitoring Document
• Healthcare Associated Infection (HAI) Report Document
• Labor and Delivery Record
• Antepartum Record
• Operative Notes
• Procedure Notes

Senders and recievers of clinical documents using the HITSP Capability 119 were REQUIRED to use sections and entries defined in the HITSP C83 Content Modules specification.  This document collected templates from more than half a dozen clinical document implementation guides, and harmonized the section and entry definitions so that problems, medications, allergies, et cetera, would appear IN THE SAME WAY in every clinical document used.

One of the problems identified by one of the HIT Standards Committee members (I believe it was Janet Corrigan) is the potentially infinite number of possible combinations of data and thus documents that could be produced.  I have to agree, if you focus on "documents", the number of different types of documents being used in the world is indeed quite variable. 

However, the number of different kinds of document sections is not, and there is a large body of work already done in this area.  Jamie Ferguson speaks later on in the meeting to this point, and indicates that the work in the area seems to be tailing off.  As someone whose been engaged in HL7, HITSP and IHE activities in this area, I have to agree.  The last few CDA implementation guides that I've worked on have required fewer and fewer new templates, and at least one was built wholey from existing work.

One of the interesting things that's happened to the IHE PCC Technical Framework and the CCD Implemention Guide is that it isn't the documents described by those publications that are being reused globally, it is the sections and entries.  These sections and entries appear in international specifications published in the French DMP Project, in Europe through the European Patient Smart Open Services (EPSOS) project, and as a work in progress through a group led by the Ministry of Health in China.  These are some of the very same sections and entries found in the HITSP C83 specification.

So, the question isn't really about how many different types of documents we need, but the number of different sections.  One of the HIT Standards Committee members put it forth in a way that was very succinct for me, but probably not for others.  His thought was that the best way to describe a complex space is with a basis of reusable modules.  He's clearly had some mathematical training (a basis is a way to represet a "vector space"), and that just tickled my funny bone.  That's the whole point of C83 and the templates that have been subsequently developed by HITSP, IHE and HL7.

Wes Rishel points out that there needs to be a way to continue rather than update existing standards work.  I would happen to agree.  HITSP delivered results on this request, and while HITSP is no longer active, I strongly reccommend that work to whatever organization takes this specific problem forward.  I'm also hoping that we learn soon what the direction will be for the new Harmonization framework, and how these pieces all fit together.

These were the "working" recommendations of the Clinical Operations Workgroup:

• The process should standardize templated CDA sections to build upon and extend what was done in CCR and CCD
• They note that this is consistent with the NIST direction for testing (I would also note that NIST already has tests for many of the C83 sections already).
• We must enable more documents and reuse of existing work.
• We may also recommend this direction for attachments (as I suggested in January)

There's more discussion to be had, since they were running out of time for this meeting.  This topic was suggested to be continued in the next HIT Standards Committee meeting.

As an observer of the FACA process, I am happy to find that the Clinical Operations Workgroup has come to the same conclusions that HITSP and others have.  I am a little annoyed with the rehashing of these topics, but as one speaker pointed out at the start of the afternoon: this is democracy in action, and "democracy is the worst form of government ... except for all the others."

As long as the results of this democracy produce what is best for patients, and remains in action, rather than inaction, I continue to live in hope.

Are we lost?

For the last four years, the healthcare standards imperatives in the US have largely been driven by AHIC, ONC, CCHIT and use cases delivered to ANSI/HITSP.  Now that the HITSP and CCHIT contracts have ended, and meaningful use is in the process of being enacted those drivers no longer exist.  This has to some degree caused a shift in what we are working on in healthcare standards.

So what is happening in the meantime?

HL7 is working on an overall model of healthcare in at least five different initiatives:

• hData
• Micro-ITS
• VMR
• A framework based on the EHR Functional Model
• Green CDA

There's progress on some of these, yet not a lot convergence, and quite a good deal of overlap.  I'd say we are still in the "Research" phase of this R&D effort on standardization.  When we get there, I think this will be a pretty disruptive innovation (see my previous post reviewing the Innovator's Dilemma where this term is described).

IHE is focusing on refining HIE oriented profiles in the IT Infrastructure Committee, Patient Care Coordination is focused on meaningful use in perinatal and post-natal care, and Cardiology is working on the Image enabled office.  IHE Radiology is examining Web services.  There are few breakthrough activities going on here; most of what I see is sustaining innovation.

NHIN Direct is the one US government initiative that is getting some attention, although it is behind by about a month after delays in obtaining consensus (now nearly achieved). 

The HITSP Harmonization process is due to be replaced by an NIEM oriented process, but while submissions were due back in March, nothing has been announced.

The industry is still waiting for various details of the "Meaningful Use" regulations to be completed, some of which are expected "REAL SOON NOW".

The abscense of a strong "requirements" driver in the US is clearly having an impact on standards initiatives here.  Collaboration among the various standards bodies is reduced due to the lack of deadline driven projects.  Most of us are waiting for the other shoe to drop, mostly on several regulatory fronts, including standards, meaningful use incentives, and long term certification, but also on standards and harmonization contracts due to be announced by ONC.

Does that mean the standards community is lost?  I don't think so.  But I do welcome the opportunity to "catch my breath".  The last four years have been very intense.  While I would do it all over again in a heartbeat, I'm glad I'm not at that level of intensity right now.  I expect that to change any day now.

I appreciate the struggle that HL7 is going through right now.  They've latched onto an old problem (models of healthcare information) and are seeing it in a very new light (simplicity in use and access) and at a higher level of abstraction that the RIM.  Given that many workgroups are currently struggling with the same issues, I expect that there will be some divergence for a few more months, followed by a convergence and reinvigoration of HL7 Version 3 activities focused on making it more readily used.  My hope is that a reemergence of a strong driver in US government activities will not distract HL7 from engaging in this work.

IHE PCC has started some work in a new paradigm in Patient Care Coordination that addresses workflows crossing various healthcare settings.  That space will probably produce a profile a year for the next three or four years.  This too is sustaining work, and I believe will continue regardless of what happens here in the US.

Stewardship

Can you name the six key features of the Clinical Document Architecture?

• Context
• Human Readability
• Persistence
• Potential for Legal Authentication
• Stewardship
• Wholeness

Of these six features, Human Readablility is the most important, and Stewardship is perhaps the next most important.  I can derive almost all of the other features from these two, and most from Stewardship.  In being a steward of a document, it is incumbent on an organization to ensure that:

1. It is stored and related to other records with respect to context.  You can think of most context information as "search keys" into a repository of clinical documents.  It is the context of the CDA document that drove the development of the XDS Metadata.
2. The document is accessible (accessible implies: readable by humans) over long periods of time, which implies persistence.
3. It is authoritative in its content, which implies a need for verification and authentication of its contents.
4. The entire content is available.

In September of last year, the US National Committee on Vital and Health Statistics put together a primer on this topic titled: Health Data Stewardship: What, Why, Who, How.  This document what it is, why it is necessary, who is responsible for it, and how to find out more about it.  It includes an appendix describing some key resources on Health Data Stewardship published over the last decade.  It's a useful read for people who are just being introduced to the topic of stewardship.

Digital Paper

Paper has been a way of doing business in healthcare for centuries.  Fax improved this over the last few decades.  Now it seems that some folks in our governement have discovered that computer files can be a replacement for Fax as a method to exchange paper.

Is this idea worthwhile?  Maybe a decade ago.
Is this idea distracting? Yes, but only moderately so.
Do I find it amusing that they don't use any of the meaningful use formats to encode semantically interoperable content in the examples?  Yes, because otherwise I would cry.

That same blue button, using standard formats could enable VA hospitals and CMS to support meaningful use using the standards identified in the Interim Final Rule.  I hope they realize how easy it would be to get there.  If not, I suppose I'll have to post the transform myself.

Verizon USB760 Touring Fail

I'm getting ready to do some touring across the country by RV with my family.  During the weeks that we are on the road I'll work during the day while they vacation.  I will be taking a few days off here and there.  In order for me to be able to do that, I need some wireless broadband.  I researched all the various options, looked at the coverage areas, and decided to purchase a Verizon USB760 Wireless modem.  Verizon seemed to have the best coverage (much better than AT&T or Virgin Mobile), and having a separate wireless connection than my cell-phone means that I can talk and webex at the same time.  They also seem to have some coverage in Canada where I'll be headed for part of the trip.

The modem has been sitting in the box for about 10 days.  Since the prepaid account has a 30 day limit on the bandwidth I purchase, I wanted to wait as long as possible before activating it.  I installed the device today.  The device didn't want to go through the automatic activation process.  So, I called the support number given in the software.  The first person I talked to couldn't help me; he insisted that I must already have an account with them or a phone number (which I didn't yet...).  After a while he got it, and so he transferred me to someone else in their Mobile wireless account division.  That guy couldn't help me either, but he knew it right away, and gave me the phone number of someone who could.

Now for the next bit of fun.  That guy couldn't help me without a number either, and the only way he knew to get it was from the software.  So he was made to wait 5 minutes while my computer was rebooting (yeah, I got to put tech support on hold).  Then we get the application loaded (which I have more gripes about later), and he has me dig up the device serial number (that is clearly printed on the bottom of the device).  Then we set up an account so that it can be activated (because I still wasn't spending a dime until I could verify that it worked).  After the activation, walla!  I have another phone number.  Just what I needed, right.  Not really, but it was what he needed to complete the task.

Finally, the device activates.  Then the software tries to "reconfigure the device".  The tech guy tells me that sometimes it gets locked into a loop and after a while you have to kill it (via task manager).  I kill it and restart the app, only to learn from him that the proper order is:  A) start the app, and then B) insert the device.  So I kill again, do it right, and still nothing.  I then unplug device and plug into another USB port, and finally, it is recognized.  So, now I can verify that everything works, and seemingly it does.  The real test will be on the road next week.  So far, it hasn't been very promising.  About half the time I start the software I have to reinsert the device a couple of times before it works

This same bogus application itself ALSO wants to manage my Wi-Fi card.  No thank you!  Keep your stinking hand's off my WiFi card.  I have specialized software that manages that for me installed by corporate IT demons with scary visages and even scarier policies that secures my WiFi access.  Fortunately, the application doesn't seem to mess that up (I turned off the WiFi radio and it couldn't find it when it installed).

So, if you are looking for a pay as you go wireless service in North America, I can tell you that as best I know

• Verizon has the best coverage (but don't try to use it in my basement),
• the software stinks,
• the support people are good, but
• the support processes need a lot of work (e.g., The phone number they give in the software you should direct you right away to people who know about the device associated with the sofware, I mean, come on, this is networking, right!) 
• the rates kinda stink, but given the coverage area I need, $50 for 30 days of e-mail and web access doesn't seem terrible.

I'll let you know how the rest works out.

So, where am I headed?  Toronto, Indianopolis, Milwaukee, Portland, Oregon, parts of Arizona, Salt Lake City, Oklahoma and I'm not sure where else, and not necessarily in that order.  I'll be diverted along the way to the IHE meeting in Oakbrook from July 12 to 15th to deal with public comment, and then catch up with my family in the Milwaukee area on the 16th after a day in Waukesha.  I'll be stopping along the way at different company offices to give CDA/CCD Ambassador Presentations and catch others up on meaningful use (and mabe to borrow some real bandwidth).

This also started because I told my wife that the next time the family was in Phoenix, there was a place I needed to take them for Sushi.

Turing Fail

A Turing Test is used to determine whether a computer can sufficiently mimic a human being in a conversation. The test has a judge conversing with two partners, one a computer and the other a human. If the judge cannot accurately distinguish the human from the computer, then the computer is said to have passed the test.

About 18 months ago (give or take), I read a letter that presents a modified version of the Turing Test. The letter bears the signature of a physician. I didn't examine the signature with a magnifying glass, but if I had, I would not have been surprised to see signs that it was a digital copy. The question this test raised is "Did a human actually write and/or sign this letter?"

The answer, I fear, is not good in either case, as you might conclude yourself. Here is the content, with PHI redacted inside [brackets]:

Dear [patient]:

At the [institution], we are committed to providing the highest
quality of care and to ensuring that our patients are kept informed of all
aspects of their care.

As the Hospital’s Infection Control Director, I oversee our Hospital’s
efforts to prevent, detect, and control infections. Despite our best efforts,
some times infections do occur in the hospital. During your current
hospitalization, you experienced a [infectious disease] which was managed
in accordance with standard practice. We regret any discomfort or inconvenience
you may have experienced as a result of this infection.

Although you already may have discussed the infection with your physician,
we wanted to ensure that you were aware. If you have any questions about your
infection or the treatment you received, please contact your physician
directly.

Sincerely,

/S/

[physician], MD
Director, [Infection Control Department]

Most of the letter reads as if it were boiler-plate text. The purpose of the letter seems a little strange at first. Why not tell the patient that they've aquired an infection during their stay? In this particular case it was not feasible, as the patient not aware. That might also explain why no letter was recieved after their first infection, when they were.

This appears to be a letter sent out by the institution to all patients who encounter a healthcare associated infection (HAI) during a hospital stay. It isn't clear to me whether this is institutional policy or some sort of effort to comply with a local law or regulation. However, in this particilar case, the patient died a couple of days before the letter was mailed. Unfortunate timing does occur, but it made me think about the details of this case and others that must be like it. I'm told by collegues anecdotally that this situation is not rare. I am aware of more than a few similar situations personally. I find myself wondering how many family members of patients who die shortly after an HAI recieve such a letter from this institution.

My prediction in this case, is that the letter was crafted by a computer system. The impersonal style, lack of awareness of the patient condition or prognosis demonstrated, and other tell-tales from years of doing computer automation all seem to point in that direction. I also lean towards the signature being a digital copy based on two assumptions:

1. I find it hard to believe that a provider who reviewed the patient's chart would have sent this letter.
2. I expect that a provider signing such a letter would look at the chart.

Whether my predictions are correct or not, this process should be examined in more detail, as it can certainly be improved.

For my own part: This letter makes me even more aware that computer automation requires a great deal of thought. It may not be a pleasant reminder, but a necessary one nonetheless.

The Temporary Certification Rule

On Friday, ONC posted the final rule on the Temporary Certification program.  The final rule provides a temporary certification program for health information technology until December 31, 2011 or if the permanent certification program is not ready, until such time as specified by the National Coordinator.  The rule's anticipated publication date in the Federal Register is Thursday, June 24th.

There were several changes to the final rule based on comments.

1. The National Coordinator is responsible for approving the test tools and procedures (the proposed rule specified the use of NIST tests and procedures or equivalent).
2. Refunds would be issued should testing not be able to be completed due to the conduct of the temporary certification body, including those cases where the EHR would need recertification.
3. Temporary certification bodies are required to report which quality measures a product was tested and certified with, and what additional tools were needed to perform those measures.
4. The rule is effective IMMEDIATELY upon publication in the Federal register.  ONC will begin accepting applications July 1st.
5. Even if your EHR was already certified under CCHIT, it would still need to certify under this program.
6. The temporary certification bodies created under this rule will become "recognized certifiers" by HHS with respect to relaxation of the Stark and Anit-Kickback rules.  Preexisting CCHIT certifications would still be "deeming" if the EHR product was certified in the time frame specified under those rules, but certifications after this regulation goes into effect would need to come from certifying bodies recognized by ONC under this new regulation.

White smoke?

We've gotten a lot closer in another week.  It appears that the Convergence Proposal put written up by Rich Elmore and David McCallie has been able to get general agreement from just about all parties.  It includes many of the capabilities that I talked about yesterday in "A way forward", and we also looked at some really good pictures developed by Janet Campbell.

There are some clarifications needed before we make a general call for consensus on the project, and a team has been put together to make those clarifications (I'm on it along with Rich, David and a few other people who have also be "working hard" this week).

My last comments on this are that we need to address requirements of Source HISP and Destination HISP, not just "requirements of the HISP", and that we also need to determine what the existence of an NHIN Direct address implies.  Some e-mail addresses in the real world are send-only and don't recieve, and others are recieve only and never send.  Is that allowed in NHIN Direct?  It seems like it should be.

In any case, I think we are very close, and we'll be able to announce what the NHIN Direct protocol is next week.

Working Hard on NHIN Direct

A lot of my focus this week is on NHIN Direct and trying to work towards consensus.  That means that I haven't been focused on other topics ... and so some would have it that I'm hardly working.  Is NHIN Direct undermining meaningful use?  Only meaningful use of incentive payment kind, not real world meaningful use, so I continue to participate.

Wes Rishel reports on his opinions of where Vendors are in NHIN Direct: Response to Comment on Vendor Positions.  What I find amusing about this is that I know of several cases where "we" are still deciding where "we" are, and if you talk to two different individuals at the same employer, you will get two somewhat different answers on what that "we" thinks.  Some of this is readily apparent if you look at the e-mail threads of the workgroups.  I also find myself clearly in all three groups that Wes identifies, and can put others clearly in at least two, depending on the definition of "big" and "substantial", and other similarly imprecise terms.  Wes, please do me a favor identify companies or don't, but don't take half measures that can be confusing.

It's fair to say that vendors (I won't speak for any specific segment) haven't yet coallesced around a single solution yet for NHIN Direct; that's still a work in progress, though we may get more progress later today.

On Andy's specific comments:
...HIE Vendors should be fairly neutral...
I'm not sure about that.   Whatever gets done, if there's two protocols established, there will be two to support, and given where consensus has been driving us, I expect there will be two protocols.  Yes, whatever the second protocol is, it will be pretty easy to develop (and likely support), but that won't make it "free".  I'd like to have it be supported based what is already in the installed base, because that will reduce implementation costs.

...pushback might be coming from the EMR vendors...Their core competency is clinical EMR development, not interoperability...
Wow!  My autoclassifier marks that last statement with [citation needed], especially given that the source is someone who works for a vendor of "interoperability solutions".  Look at my responses above with respect to "HIE Vendors".  The same principle applies.

...NHIN Direct sets too low a bar...
NHIN Direct sets a very low bar conciously.  As time marched onwards, that bar became MUCH lower than the bar set for meaningful use.  This occured even though the original project description states that it: "... will expand the standards and service descriptions available to the NHIN to address the key Stage 1 requirements for meaningful use, and provide an easy "on-ramp" for a wide set of providers and organizations ...". 

Yes, I'm a little bit concerned that the bar is too low, but that is more of a market opportunity than a problem for me.  It's easy enough to raise that bar to provide better services.  Going from CDA/CCD or CCR to XDM is very simple, and I've written stylesheets in a day or two that support that several times over.

In the interest of full disclosure, I work for GE Healthcare, which is a vendor of Healthcare products that includes EMR and HIE solutions.  Also, and as always, the opinions expressed on this blog are my own and not necessarily those of my employer.

A way forward for NHIN Direct

There are two communities of interest that NHIN addresses, those already engaged in the NHIN Exchange who want to be able to capitalize on their existing technology investment, and those providers who do not have access to technology that is capable of integrating with the current NHIN Exchange specifications and policies.  NHIN Direct is focused on meeting the needs of that latter group, but we need to remember that group will need to communicate with the group already invested in NHIN Exchange.

This is, I believe, the real impasse in the current NHIN Direct work.

What we need to remember is that there is one National Health Information Network, and that the purpose of NHIN Direct is to enable providers who cannot communicate via NHIN Exchange to participate in NHIN.

The current NHIN Exchange also includes several other components that may also be problematic for these providers, because the current set of policies (including the DURSA) may also be too complex.  I won't bother to address issues of policy other than to point out that there is an HIT Policy committee that will be advising on those.

Let us just take it as a given that NHIN needs to support both communities:

We have two "backbone" proposals (SOAP with IHE XDR or SMTP) that are more or less desirable between one community or the other.  Movement of one community or another towards the "backbone" that meets the needs of the other has implementation costs that neither community really wants to be responsible for.

Whether we call SMTP the backbone or SOAP+XDR the backbone really doesn't matter (at least to me).  We will want to bridge between these two communities of interest.

Let us name three protocols:
Protocol A uses IHE XDR with SOAP
Protocol B uses SMTP and includes an XDM content package in the content.
Protocol C just uses SMTP and any sort of attachment desired.

So, we have providers with the following sets of cababilities:

1. XDR and/or XDS.b capabities through NHIN Exchange.  These are users of protocol A.
2. SMTP + some level of services to produce an XDM package. These are users of protocol B.
3. SMTP.  These are users of protocol C.

We need to enable exchanges between all three sets of providers as much as possible.  In order to do that, each NHIN Exchange participant will need to have an NHIN Direct address that they can use to communicate with parties that are not in the NHIN Exchange.  That same address can also be used to when routing communications between NHIN Exchange participants.

If a party in group 1 wants to communicate to another party in group 1, here is the overall process:

1. The Source System communicates to the Source HISP via XDR.
2. The Source HISP forwards that communication to the Destination HISP
3. The Destination HISP delivers the pushed content to the Destination System using XDR

If a party in group 1 wants to communicate to a party in group 2 or 3, here is the overall process that could take place:

1. The Source System communicates to the Source HISP via XDR.
2. The Source HITSP S/MIME encrypts the content
3. The Source HISP converts the XDR metadata and content to an XDM Zip file an attaches it to the communication.
4. The Source HISP locates the destination HISP via the destination address in the XDR informationRecipient metadata.
5. The Source HISP sends it via SMTP+TLS to the destination HISP.
6. The Destination HISP stores the encrypted content until requested by the Destination System.
7. The Destination System requests the content.
8. The Destination HISP descrypts the S/MIME encrypted content and sends it to Destination System (via POP or IMAP).

If a party in group 2 or 3 wants to communciate to a party in group 2 or 3, here is the overall process that could take place:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP stores the encrypted content until requested by the Destinatio Edge System
6. The Destination System requests the content.
7. The Destination HISP descrypts the S/MIME encrypted content
8. The Destination HISP sends it to Destination System (via POP or IMAP).

Now, a distinction appears in the protocol when we want to go from B to A or C to A.  Let's look at B to A first:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP decrypts the S/MIME encrypted content.
6. The Destination HISP sends the XDM content via XDR through a simple transform that requires no manipulation of PHI, and only deals with protocol bridging.

Now let's look at C to A:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP decrypts the S/MIME encrypted content.
6. * The Destination HISP fails to locate an XDM package and sends a message back to the source HISP indicating that the content could not be transmitted.

Step 6 is a problem, but not an insurmountable one, and we've already covered almost all cases.  There are a couple of ways that a software component could eliminate the rejection in step 6, depending on the content and communication intent:

1. The message is simply a "text e-mail" with no attachments directed to the destination address.  For example: "I'm sending John Doe to you to have an EKG because he has a history of hypertension.  Could you send the results back to me when you are done.  Thank you.  Dr. Smith"
2. The message includes an attachment in a non-healthcare format (e.g., PDF) or a proprietary format (e.g., RTF).
3. The message also includes an attachment in a healthcare standard format (e.g., CCD or CCR) and that attachment is from the medical record of the patient who the communication is about. (Add "P.S., I've added John's CCD to this e-mail" to the previous case).
4. The message includes an attachment in a healthcare standard format, and that attachment is not from the medical record of the patient who the communication is about.  "I'm sending you the information about the delivery of Jane Doe's baby John as she tells me that you will be John's pediatrician.  Attached please find her delivery summary.  Thank you.  Dr. Smith."
5. The message includes multiple attachments for different patients.  "Here are my records for the paitents I immunized today.", and/or "Here is Jane's delivery summary and Baby Doe's discharge summary".
6. The message includes an attachment that is not specific to any single patient.  "Here is my quality report."

Cases 1, 2, 3 and 4 can be made to fit an XDR model by generating a unique random identifier to identify the patient and including minimal metadata in the XDR communication.  What will be lost is any way to have the patient be matched in the NHIN Exchange side.  As we've seen in the media, ensuring that patients are correctly identified during information exchange is important for patient safety.  Users on the NHIN Exchange side will need to deal with cases where patient information comes in where they have to ensure that the patient is correctly identified.  We've also seen examples where content in case 3 can be bridged using a "better" set of metadata, but it is difficult to distinguish those in case 3 from those in case 4.  That could be addressed by including an additional header in the communication that indicated that the Attachments in the communication are related to the patient that the communication is about.

That leaves the last two cases.  Batching and quality reporting is NOT a requirement for phase 1 of NHIN direct, although they could be requirements of future phases.  The two documents from different medical records pertinent to one patient is arguably a rare case that we can better work the details out for later.

Frankly, I could spend another page proposing solutions to these two cases, and knowing that I could do that is enough to stop here.

I believe there is a way forward.  I believe that way forward will need to include some sort of bridging technology, and I'm very much in favor of recommending XDM content in whatever is selected to support that bridge.  Whether the backbone of NHIN Direct is SMTP or XDR, what we need to realize is that the backbone of NHIN needs to support both.

All of the examples I gave assumed that the Source and Destination HISP's were trusted with the responsibility to encrypt/decrypt the S/MIME package. This is to address certificate deployment issues.

In the examples I gave above, I showed that it was the Destination HISP that was responsible for bridging the content.  Arguably, that bridging step could also be done by the Source HISP, and I see no reason to prevent or discourage that.  Bridging is in fact an additional service that should be offered to enable the existing NHIN Exchange infrastructure to support NHIN Direct.  The examples I just described could actually treat the "bridging component" as the Source or Destination System, which would be a purer way to describe it.  From my perspective, I just see that additional component as fitting best with a software application that performs the HISP role.

P.S.  Actually, group 1 to group 1 is already addressed by current NHIN protocols using a query model and an XDR push model, this exchange group really doesn't need to be addressed by NHIN Direct.

Black smoke on NHIN Direct again

The black smoke continues to billow over NHIN Direct.  On today's Implementation Workgroup call, two basic proposals were made:

1. Continue to develop 2-3 implementation approaches by forming communities of interest around each one (as suggested by Wes Rishel)
• Communities will likely form around SMTP and IHE/SOAP
2. Seek common ground and Unify the Group with a single approach
• SOAP with an e-mail bridge model
• REST with SMTP

There was a lot of discussion, with some of it divisive and some of it trying to work towards consensus.

I believe in general that the group is moving towards trying to seek common ground, and that sentiment was strongly supported by many EHR vendors. 

One of the problems on today's call was that these one line descriptions of the proposals did not present enough information about what was included in them.  We did not come to a decision today, but Vassil Peychev proposed that the remaining proposals be written up and a call be held on Friday to review again. David McCallie and others are working on write-ups now. Given that suggestion occured near then end of the NHIN Direct call, Ariensuggested that be the go forward plan.

Let me briefly summarize how I think these proposals work out:

1. The "go your own road" proposal around communities of interest seemed to be a non-starter.  Two people really supported it, but I heard strong support (including my own) on trying to come to consensus, even though it may be hard.
2. There seem to be two "grand unification theories" going around:
• Use the IHE XDR protocol as the backbone and provide a bridge to the SMTP model.
• Use SMTP as a backbone, with REST as an interface layer, and IHE XDM as recommended content.  This would enable step up/down to/from current NHIN and IHE protocols (XDR and XDS). [I strongly support this theory].

Note that I'd be happy with XDR as the backbone, as the IHE model already demonstrated that capability, and I'm much more comfortable with the security of that model.  That really speaks though to my own comfort level with TLS and SOAP, and clearly, doesn't address the complexity issues that others have raised, nor will it, I believe, be able to move forward as a consensus position, given the fact that two parties are very strongly against that option.  Given that the XDR as a backbone position doesn't seem to be in a position to generate a consensus viewpoint, I very strongly support the next choice.

There was still a great deal of discussion / dissent over the lack of representation from the smaller providers who this is being built for.  The next time this process comes around, there ought to be some sort of provision to provide for them to be directly represented (EHR vendors do have these providers as customers, but representation by proxy is not seen as valid representation; at least in some of this group).

There are also a few who have expressed concerns that large vendors are still dominating the process.  However, I would also note that it seemed to be those same vendors strongly expressing desire to reach consensus, rather than divide up around preferred approaches.  

I also heard some concerns raised that a very small but strong minority opinion was blocking a majority viewpoint, and also that the majority was trying to work with them. 

This was another hot-button topic, and I think that the words minority and/or majority, and large/small vendors are keywords that should be used very carefully in any NHIN Direct call that wants to make progress (I'm just sayin').

There were a number of comments about scalabity of solution A vs. solution B.  In a community of experts however, an expert opinion carries little weight when two or more the experts disagree.  There was one attempt to shift grounds from "technical scalability" to "social scalability" of the two alternatives.  It was an interesting discussion, but I didn't quite get it. 

All in all, it was a pretty intense and wide ranging (perhaps too wide ranging at some points), discussion.

We are all very frustrated, and that comes from a number of places.  The ability of a small group to hold up a larger group, the struggle by under-represented but important stakeholders to have their viewpoints heard, the desire by some (including me) to move things forward.  The newness of this process, our lack of experience with it, and our inability to reach some of our timelines contributes to all of this frustration.

Even with all the frustration, we've gone from four possible outsomes to somewhere around two in a matter of a week, and that is indeed progress.  I have to give Arien Malec a lot of credit (worry not, I'll give him grief like I did a few weeks ago when it is deserved).

The Search for Use in HL7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Black Smoke over Redmond

Last week develpopers met face-to-face in Redmond to declare a victor among the four protocols proposed for NHIN Direct:

• XMPP
• SMTP
• REST
• IHE+Adapter

If you get the "black smoke" reference, you already understand that no choice was made, and discussion is still occuring.  You may have also read commentators on the Web:

Arien Malec
Wes Rishel
Sean Nolan
John Halamka

I was not able to attend the meeting, but what I'm hearing in general are that:

1. There was a "general consensus" led by EMR vendors for the IHE solution on the backbone.
2. A couple of naysayers against the IHE solution wouldn't come to consensus at all.
3. SMTP seems to be strongly supported for the edge.

To say that I look forward to continued discussion would be disingenuous.  I'd love to be moving on to the next stage, BUT, discussion still needs to occur, so I'll be patient and let it work itself out.  I am thankful that Arien chose the path of trying to obtain agreement, rather than hitting arbitrary deadlines.  As Wes has said in this past, if this project succeeds in twice the time allocated, it will still be a big win.

Book Review: The Innovator's Dilemma

On the advice of a collegue I picked up a copy of The Innovator's Dilemma by Clayton M. Christensen yesterday.  I'm more than two thirds of the way through it and heartily recommend it to anyone involved in Healthcare IT.  It includes case studies of several industries, including a couple that will be familiar to IT folks:

• Hard Disk Drives
• Microcomputers
• Discount Retailers
• Steel Mills
• Excavators 

The case studies are more than just anecdotal narrative.  The author puts together some very compelling evidence based on detailed research about how disruptive innovation causes well managed companies to fail.  While the book was written more than 10 years ago, the advice given is still very sound.  Even as the author describes events from a decade ago, I found myself identifying more recent events (the rise of solid state storage and the USB memory stick, the laptop computer, the PDA and the smart phone), which follow similar patterns.

In almost all cases of innovation that Christensen describes, the disruptive innovation starts downmarket, and eventually creaps upmarket to displace prior market leaders.  The importance of this work in Healthcare IT comes from couple of sources of disruptive innovation:

• The Health Information Exchange as a platform for electronic health records.
• The emergence of lightweight EMR products and Software as a Service (SaaS).
• The interest in easier to use standards with a lower point of entry (e.g., NHIN Direct vs. NHIN CONNECT, Green CDA and CCR vs. CDA and CCD, REST vs. SOAP)

The HIE space is arguably not "downmarket" from the EHR space but it is definately a new market.

Christensen has two other books that follow up on The Innovator's Dilemma, one titled The Innovator's Solution, and a third titled The Innovator's Prescription which is specific to healthcare.  Based on what I've read so far, I'll be purchasing the next two shortly.

IHE Profiles Support Meaningful Use

An alum at Florida State University asked for this one.  Essentially, he wanted to know if it was possible to map the Meaningful use requirements into specific IHE profiles.  I had developed four slides on this which were presented at the HIMSS 2010 Annual Conference during the IHE PCC Domain update in the IHE Interoperability Showcase booth.  These were based on an evaluation of the IHE PCC Perinatal Workflow profile that I discussed earlier this year.  Here is a map from the meaningful use requirements from the Interim Final Rule on Standards (§170) and the Notice of Proposed Rulemaking on Incentives (§495) to various IHE profiles.


Standards

• §170.202(a) Transport – XDS.b uses SOAP 1.2
• §170.205(a) Patient Summary Record – CCD and SNOMED CT®
• §170.205(f) Laboratory Orders and Results – HL7 2.5.1 and LOINC®
• §170.210(a) Encryption – ATNA uses AES and TLS

Certification Criteria

• §170.302(a) Drug checks – Request for Clinical Guidance
• §170.302(b-d) Maintain Problem, Medication and Allergy Lists
• §170.302(r) Audit Logs – ATNA requires Audit
• §170.302(s) Integrity – ATNA and XDS.b use SHA-1
• §170.302(t) Authentication – ATNA requires authentication
• §170.304(a) CPOE – Order Placer/Order Fillers for Imaging and Labs
• §170.304(c) Demographics – PIX and PDQ Support Required Data
• §170.304(d) Clinical Decision Support – Request for Clinical Guidance
• §170.304(f-i) Electronic Access – XPHR/CCD, XDS-MS, XDS.b and XDM

§495.6(c) Stage 1 Criteria

• (1) Drug Checks – Request for Clinical Guidance (RCG)
• (2) Problem List – XPHR Requires Problems, Supports SNOMED CT® or ICD-9-CM
• (3) Medication List – XPHR Requires Medications, Supports RxNORM and other vocabularies
• (4) Allergy List – XPHR requires Allergies
• (5) Patient Demographics – PIX/PDQ
• (6) Vital Signs – XPHR requires Vital Signs
• (8) Clinical Lab Tests – XD-LAB and HL7 V2.5.1
• (10) Decision Support – Request for Clinical Guidance
• (12) Medication Reconciliation – Built in all PCC Discharge Summaries
• (14) Summary Record – XPHR

§495.6(d) Stage 1 Criteria for Eligible Providers

• (1) CPOE – Order Placer/Order Fillers for Imaging (SWF) and Labs (LTW)
• XPHR, XDS-MS, XDS.b and XDM support:
• (5) Electronic Copies
• (6) Timely Access
• (7) Clinical Summaries
• (8) Exchange of Key Clinical Information

§495.6(e) Stage 1 Criteria for Hospitals

• (1) CPOE – Order Placer/Order Fillers for Imaging and Labs
• XPHR, XDS-MS, XDS.b and XDM support:
• (3) Electronic Copies
• (4) Discharge Summaries including Procedures and Instructions
• (5) Exchange of Key Clinical Information

The Perinatal Workflow Profile developed by the Patient Care Coordination domain brings all of these profiles together into a collection of actors and transactions that support many of the meaningful use requirements.  This profile is currently available for public comment.

IHE QRPH Announcement

---

IHE Community,

The IHE Quality, Research and Public Health (QRPH) Technical Committee has published the following supplements to the QRPH Technical Framework for Public Comment:

• Early Hearing Detection and Intervention: Screening, Short-Term Care, and Clinical Surveillance for Hearing Loss (EHDI)
• Mother and Child Health (MCH)
• Provider Reporting to a Public Health Repository - Cancer Registry (PRPH)
• Redaction Services (RSP)
• Retrieve Process for Execution (RPE)

The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments should be submitted by July 6 to the online forums at http://forums.rsna.org/forumdisplay.php?f=371.

A Short List of CDA Implementation Guides with Links

The embedded PDF below traces the intellectual history of several CDA implementation guides over the years.  Time in general runs from top to bottom.  Dotted lines trace dependencies or sources of innovation and solid lines generally trace "inheritance" or ISA relationships.  Images at the top of each group indicate the organizations behind the development of each of these guides. 

NOTE: Links with a * beside it are to the balloted works instead of the finished guide as these are not yet formally published by HL7.  Access to HL7 DSTU material is available to all, access other HL7 material requires an HL7 member login.  Access to the Vancouver Island Health Authority specification and the IHE and HITSP implementation guides is free to all.



This diagram DOES not include at least 10 more guides developed in HITSP and IHE that use the HL7 CDA, and also does not include guides from France, Germany, Finland, Japan and China and other locations where CDA is used.

IHE PCC Profiles for Public Comment

---

IHE Community,

The IHE Patient Care Coordination (PCC) Technical Committee has published the following supplements to the PCC Technical Framework for Public Comment:

• Antepartum Profiles
• CDA Content Modules
• eNursing Summary (ENS)
• Labor and Delivery Profiles
• Newborn Discharge Summary (NDS)
• Perinatal Workflow (PW)
• Postpartum Visit Summary (PPVS)

The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments should be submitted by July 1 to the online forums at http://www.ihe.net/Technical_Framework/public_comment.cfm.

The title of this post is not so secret...

The Harmonization RFP that I tallked about in "The title of this post is a secret..."  was posted publically on John Halamka's blog today.  After reading through this RFP, what I find interesting is that HITSP already did some very similar work which I discussed in Data Mapping and HITSP TN903.  I hope we aren't paying for a redevelopment of this effort, and that the selected contractor takes advantage of what is already done.

The low point in the RFP (on page 15) is this sentence:  The harmonization process shall include the function of reviewing, reconciling, developing, setting and maintaining standards.  These latter functions are of course the function of consensus standards development organizations, not government contractors or contracts.

National Technology Transfer and Advancement Act (NTTAA) directs government (or so I'm told) to use standards that are adopted by voluntary consensus standards bodies.  OMB Circular A119 clarifies that here.  Should contractors under this RFP be responsible for developing, setting or maintaining standards, I will be interested in seeing the ONC/HHS report to NIST on the standards they do that for, and why.

One high point did appear in the first full paragraph on page 16:  ...to include relevant COIs [ed. note: COI = communities of intererest] ... The contractor shall also establish domain governance for the healthcare domain with participation from all relevant stakeholders...

Well, at least I know what it says, now we'll see how the contractors respond.  It is still entirely possible that the selected response could wind up looking very much like the Candadian model, but I'm not going to hold my breath on that idea.

I have just one final question.  What was there in this RFP that prevented the public from being able to view it three months ago.  I may never know the answer to that question, but at least another veil has been lifted.

Top Search Keywords

Since today is a holiday, this post is more for fun than anything else.  If you've been following this blog, you probably already know that I track my readership using Google Analytics.  I spent a little bit of time looking at the keyword hits that drive traffic to this blog site.

Rank	Keyword	Search Phrases Using It	Page Hits	Comments
1	saeaf	8	504	A popular topic, usuallying including HL7 in the search phrase.
2	hl7	36	463	Another poplar topic
3	boone	15	417	Looking for this blog.
4	standards	16	381	Looking for this blog, accompanied by "healthcare"
5	hitsp	25	346	Looking for topics on this blog, or for C32.
6	healthcare	16	343	Looking for this blog, and usually accompanied by "standards"
7	blog	11	342	Looking for this blog.
8	keith	15	323	Looking for this blog.
9	motorcycle	8	208	Looking for this blog.
10	clinical	5	203	Decision support, genomics or document repository.
11	guy	6	197	Looking for this blog.
12	cda	10	186	Um, that would be one of the other names I answer to and green CDA is one of the popular search topics.
13	ihe	11	168	Looking for general information about IHE, profiles, and relationship to standards including HL7
14	c32	6	142	Almost all looking for the HITSP C32 specification or commentary.
15	xds	8	137	Looking for information about XDS
16	version	3	125	Version 2 is much more popular than version 3.
17	guide	2	122	Both searches for implementation guides for genomics.
18	implementation	2	122	Both searches for implementation guides for genomics.
19	repository	2	114	XDS and clincial documents.
20	rdss58	1	111	Some HITSP thing I announced.

Many of the top search keywords are looking specifically for this blog, and a number of other search phrases use titles of posts I've written, and five hits came through for "Vancouver", where I just got back from.

I still haven't figured out what any of this is trying to tell me.