通过

Update From The HL7 Working Group Meeting

  • 项目

On Monday I had the privilege of representing the Connecting for Health NHIN prototype consortium in a panel discussion moderated by Dr.Loonsk.

The panel title was "HL7 and International, National and Regional Interoperability" and was formed by 8 people, each one of us had 9 minutes to spill the beans on the collaboration projects that we were representing.

On the panel:

  • Roberto Ruggeri, Senior Healthcare Technical Strategist, Healthcare and Life Sciences, Microsoft Corporation (Representing the CSC Connecting for Health team)
  • John Quinn, Technical Committee Chair, HL7; Senior Executive, Accenture
  • Dave “Casey” Webster, Chief Architect, NHIN, IBM
  • Wendell Ocasio, MD, Principal Clinical Systems Architect, Northrop Grumman
  • Robert A. Stegwee, PhD, Chair, HL7 The Netherlands
  • Ken Lunn, Head of Comms and Messaging, NHS National Program for IT
  • Dennis Giokas, CTO, Canada Health Infoway
  • François Macary, Chair, HL7 France; Co-Chair, IHE Laboratory Committee

Other than having the longest title :-) I also had to go first.

I thought I'd share with you some of the thoughts I shared with the over 400 people attending the HL7 WGM.

The CfH consortium is formed by three health markets: the Mendocino HRE in California, the Indiana Health Information Exchange and the MA-SHARE RHIO in Massachusetts. Many technology and industry partners participate in the consortium in various capacities and contributing to different parts of the process of building the NHIN: architecture, governance and business model and so forth.

The key word to describe the CfH approach to the NHIN is “federation”.

The different organizations that are part of the prototype come together in what we call a “network of sub-networks”. This describes the hierarchical structure of the health information network. The three health markets present themselves with very different architectures for their regional health information networks. They differ mostly in how they deal with clinical data and its level of aggregation. In the case of Mendocino HRE, the data is mirrored at the regional level to provide for better availability for those organizations like rural communities that cannot provide 24x7 access to it. Clinical data is still partitioned based on where it came from.

In Indiana the situation is slightly different and the clinical data coming from the different enterprises is aggregated in a clinical data repository based on HL7 v2.

The architecture for the MA-SHARE RHIO is very different in how it deals with clinical data. In this case, the information is stored in clinical data repositories within each organization. Access to data is controlled by the Clinical Data Exchange gateway in each organization. The architecture for the MA-SHARE RHIO is detailed in the Common Framework that CfH publish a while ago on the Connecting for Health web site. I strongly encourage all of you to have a look at it if you have not already done so.

Each RHIO presents several regional services that are necessary for the NHIN to work, but as you can see there are no “central” NHIN services or data repository.

The focus of the group has been on the interfaces and contracts that need to exist in order to make the RHIOs participate in the network without imposing changes in whatever architecture the RHIO has chosen to implement: centralized, peer-to-peer or hybrid.

When selecting the standards, we had a key strategic goal to have them all fit on one slide. We were successful, even though we had to use a very small font.

The approach in selecting standards has been to have a clear separation between what is transmitted or communicated and how that communication happens. Achieving independence between the two is critical in allowing them to evolve independently and preserve investments in each area as well as allowing for innovation in both the healthcare standards as well as application architectures and communication standards.

For the specific clinical data standards it was hard to get down to a single one. This is especially true when you look at the legacy of existing systems and the type of organizations involved in the information exchange. The choice came down to HL7 v2 for clinical data, NCPDP for medication and prescription data and ASC X12N for administrative and financial data.

We looked at HL7 v3 for infrastructure components such as the Record Locator Service for registering the location of clinical data for any given patient. Unfortunately the selection of HL7 v3 for clinical data was made difficult by the vast legacy and investments in v2 and the lack of consistent guidance on how to unequivocally transform between the two.

Again, this was done to facilitate the integration of several different organizations.

The selection of standards for the messaging infrastructure was much easier and we settled on Web Services standards such as the W3C SOAP and WSDL. These standards are today well established and available in a number of implementation on both commercial and open source platforms and they are also at the basis of modern Service Oriented Architecture or SOA.

The prototype is very much a work in progress and as we get closer to the end of the project I’m sure we’ll learn more.

Let’s talk about what we learned so far:

  • HL7 v2.xml has proven to be a good way to get from the existing HL7 v2 message format to more modern XML processing techniques without taking on the full HL7 v3 conversion.
  • We wish we had a more prescriptive guidance on how to convert from HL7 v2 to v3 and vice versa. This would have eased the adoption of v3 and the inclusion of the existing assets. We hope that we will still be able to do that for a normalized subset of the HL7 v2 messages that we select for the NHIN.
  • The other difficulty we had with HL7 v3 was with the existing XML toolsets and the extent by which v3 pushes they abilities. We think that better implementation testing with existing tools would simplify this aspect and reconcile the needs of HL7 and the practical implementation.
  • We identified HL7 CDA as a very good way to ease into HL7 v3 for document-based clinical data. We still need to integrate with the existing, so we will be looking at way to map some HL7 v2 messages to a CDA document such as the Continuity of Care Document.
  • In the process of selecting standards we quickly came to the conclusion that we could not select any single one of them. The list came down to a normalized subset of several standards such as HL7 v2, v3, NCPDP and X12. As implementers we have to deal with the variety of options out there and although we see some convergence between standards, it is unlikely that there will be a single one anytime soon. Even though a lot of work goes into the development of HL7, we think that the breakthrough will happen as we start working around the edges and how these standards work together. This is especially true when it comes down to adopting an architecture for the application. We cannot have one way of doing things for HL7 v2, one for HL7 v3  and another one for NCPDP.

As I said this list is only partial and I’m sure we will learn much more from the process as we go on and we look forward to sharing those lessons with you and the community at large.

Sorry for the long post, the slides will be available on the HL7 web site probably next week.

Comments