AG: Tell me about your main initiatives.
CJ: A crucial one was this October when we restructured the process for developing specifications. HL7 had been a volunteer organization in which any one of the 55 technical committees and workgroups percolate up activities as they saw fit. This process led to confusion on deliverables, conflicts among workgroups and concern around timelines. So one of first things I did was to begin a restructuring in which we formed a technical steering committee (TSC) with representation from logical groupings of the technical committees into steering divisions which added a top-down approach to complement, track and manage the activities of the volunteer organization. This way, all development activities initiate at the TSC level. The steering division members represent typically six-12 technical committees each and were elected by membership. There was a staff-level management component from the CTO whom I appointed, John Quinn. (See HCI’s interview with Quinn)
That was the most crucial first management step — the development of a new process for the program office and management hierarchy. Out of that, I promised development of a roadmap. We are in the process of completing a roadmap that integrates technical, business, policy and organizational timelines so that our stakeholders have a reasonable expectation about what will come in the next one, three and five years. This will also let them know what the policy changes look like so they can implement different specifications, and with whom we will nurture relationships, who we will build resources for, and what new income opportunities we will develop to fund the specific activities.
These have all been laid out in a roadmap and presented to the board in April. After that, we will certainly have a better story to tell our stakeholders, and they will be able to make development decisions based on these deliverables, in terms of content and time. Part of the project management office’s objective will be managing to those business requirements, not least of which is if we commit that we are going to do it that we have resources to meet the timelines. So I think there will be a new look and feel for the organization. I think there have been several initiatives to help support that.
One of those is the development of the joint working group which originally included HL7, ISO and CEN (the European Union’s standards body). Part of the EU directive has been that if you are an EU member you will abide by this standard agreement from CEN. This is important because many of our most cutting-edge affiliate countries, such as the U.K. and the Netherlands, are committed to HL7 standards. So we not only want to harmonize with any CEN requirement, but also deal with gaps which exist between CEN and HL7.
Short of that, we have been looking at other issues, and we continue to have a superb working relationship with HITSP but also just as IHE has joined HL7, we’ve become a founding member of the new IHE corporate structure, and we are working on a memorandum of understanding for implementation guides and joint initiative projects at that level of clinical research where new members have evolved. This is true particularly for pharma, but also like the NIH and CDC, it is a cooperative effort to model the research domain in reference to the information model. This is rather than the painful mapping that has to take place between CDISC – Clinical Data Interchange Standards Consortium Inc. — and the FDA and other relating agencies that are authorized to receive information electronically.
I am the original acronym hater. At Intel, people could tell I had created a particular PowerPoint because there were no acronyms. In any event, NIH funded a good deal of work for the Clinical Data Interchange Standards Consortium so the FDA has guidance on receiving all submissions through the CDISC standard. Recently, they have begun a project for putting all of this CDISC information in an HL7 wrapper, and rest of world has gone along with it. HL7 and CDISC are really the model of how SDOs can achieve common goals. Through the efforts of the National Cancer Institute, we both modeled clinical research within the Reference Information Model so that no mapping is necessary.
I think the biggest leap forward is in the area of Clinical Document Architecture (CDA) with increasing adoption of Release 2 CDA and ISO standards. For the last few years, there have also been solutions for attaining a higher level of interoperability that is achievable through Version 3 and CDA which use the same Version 3 artifacts. This can be done while not having the business requirement of changing all systems and solutions, because you can use the CDA to send any document within the HL7 V2 framework — text, lab, EKG, but also images and other kinds of information that could reasonably be called a document. Release 2 of CDA and Version 3 of HL7 (Version 3 of HL7 includes CDA, the RIM and Version 3 messaging) enable users of V2 messaging solutions to have some of the same interoperability that Version 3 offers, and still have the framework that exists in their systems for a decade or more. It’s a remarkable solution, while part of the Version 3 family is accessible by systems and healthcare institutions that use Version 2.
The principal value here is the sharing of documents. At a fundamental practice level, the EHR vendors all deliver their solutions in an HL7-compliant manner, the same way DICOM is shared amongst healthcare providers and diagnostic imaging centers that pass information between the two of them. We now can get much closer to reaching our goal of true semantic interoperability as each release of 2.x progresses, and as 2.6 has been introduced looking to 2.7 to achieve higher degrees of interoperability, less interface development and more time and resources spent on the solutions themselves. Many have spent millions of dollars maintaining their interfaces, and as Version 2 becomes more capable, interoperability goes up, and need to develop new interfaces lessens.
The goal of Version 3 was to achieve that interoperability without engineering each and every interface. Now, we will see that Canada and the U.K. are able to achieve that in the coming year or two. They have already made progress along those lines. One point of reference is the single payer healthcare system and looking at their somewhat simpler delivery requirements. If we all had business models like Kaiser or the VA, there would be no discussion about multiple competing electronic record-keeping systems with widely varying functionality and abilities to interact with other vendors. As it is, we have CCHIT to help set the bar for minimum requirements of these solutions. While doing remarkable job — and I think most people would say we are far better off now — we still have not achieved the level of interoperability that HL7 envisioned. As we move to new releases of HL7 Standards and applications that support more standard functionality, interactions and data, that comes closer to reality.
Part of the problem in promoting EHR adoption is the providers make all the investments and the third-party payers reap most of reward. The P4P that CMS and others have implemented or are piloting will drive to combat that. But we can work to ensure the practices and small groups that they will be able to share data so they can make these investments with greater confidence. So I think part of our goal is to make that barrier lower.
AG: When do you expect to make your roadmap public?
CJ: We expect to have the 2008 roadmap at our May user group meeting. Then we will put it on our Web site.
AG: How do you stay in touch with events on the ground? How do you stay connected to real-world problems?
CJ: One of things we are trying to do is bring stakeholders closer to the development process, In fact, we held first stakeholder meetings at the Cleveland Clinic this fall, and we plan to do them annually or biannually if demand can be met. While we are developing a roadmap, it’s important to remember that it’s a living document, so we expect input. For example, if people see an unanticipated impact, we are sensitive to that. If they find a contradiction in our plans, we would like to hear about that.
AG: What is the role of each constituency in moving things forward?
CJ: The vendors are not going to pave the way unless the CIOs and the individual providers demand it. When communities of interest develop and they are not vocal about their requirements, nothing happens. So we would like to bring this forward. We have developed a clinical interoperability council whereby the individual clinical domains are able to voice their workflow and business requirements and help shape the development of 2.7 and various elements of Version 3, including the CDA, as we try to understand what the domain requirements are in areas like cardiology and pediatrics. How do we compare if we see overlap in use requirements, how can we fill in the gaps? We are looking for feedback from the CIO community to help drive development, and we will be adjusting the roadmap accordingly. It’s not set in stone. As soon as we release the roadmap for 2008, we are moving on to 2009. As part of our accountability maturation process, we expect some minor adjustment and substantial refocus.
AG: Some say HL7 standards are too loose to be very helpful. I’ve heard the quote, ‘I have 11 versions of HL7 running in my shop.’ What are you doing to make is easier for CIOs to integrate?
CJ: The more flexible you are, the more opportunity we gave for a wide range of adoption when HL7 was still quite new and lacked many of the detailed capabilities for structured data that it now has. Without getting too technical, I could teach you how to read a Version 2 message in two minutes, including blood type, etc. We call that the Z segment and that’s all you have to know it allowed to you used basic HL7 message constructs while “adding” pieces that didn’t exist in HL7 at the time you developed your interface. That gave users enormous capability to personalize their flavor of HL7, while at the same time it giving anyone else that wanted to send data back and forth even though they didn’t have the same notion of what is at the other end of that Version 2. An important way of achieving interoperability is by writing interfaces between your Z segments and mine and hence the harmony. Of course all of this accelerated adoption of HL7 and enabled interfaces, but also made each implementation that had a Z segment unique to the institution that wrote a specific Z segment.
Also, many early adopting hospitals use some version of HL7 Version 2.3 and in many cases we still find interfaces using Version 2.1 and 2.2. As we go to 2.4 and 2.5 and 2.6 that customization is can be exchanged for higher-level of interoperability inherent in the richer data content of the higher-level versions so the cost of creating interoperability can go down, and the number of interfaces that need to be ultimately maintained decreases, and whole level of data sharing improves.
In our five-year roadmap we are not abandoning 2.x, we are committed as we move ahead to make versions of 2 a whole lot more interoperable. We believe there are some tooling needs and inherent XML messaging overhead requirements of Version 3 that will slow adoption. Are vendors being pressured? What is the business case for you to send information electronically from any New York hospital to Columbia Presbyterian? You first need to have a supportable business case as to why you need to routinely send patient clinical information electronically across Manhattan. I know it is hard to imagine a need for sending information from the Partners RHIO in Boston to the Regenstrief Institute RHIO in Indianapolis. You first have to make a business commitment about that interoperability.
HL7 is trying to reduce that complexity and at the same time improve interoperability. As each release of Version 2.x comes out, you will see higher levels of interoperability. There is also no doubt that by implementing CDA and its implementation guides such as the joint HL7 – ASTM Continuity of Care Document (CCD), we are even more likely to achieve that.
