Loading in 2 Seconds...
Loading in 2 Seconds...
Trends in Practical Deployment of HL7 Standards: supporting regional electronic healthcare records. Mark Shafarman Past Chair HL7 with additional HL7 “roles” of past co-chair International Committee past co-chair Control/Query TC ex-officio member Architectural
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Past Chair HL7
with additional HL7 “roles” of
past co-chair International Committee
past co-chair Control/Query TC
ex-officio member Architectural
member Early Adopters Forum
co-chair Templates Sig
CEO & Chief Information Architect,
Shafarman Consulting, Inc.
+1 510 593 3483
In healthcare information systems, CSI is the ability to share information without loss of computable meaning, across multiple applications concerned with clinical (primary use) and related administrative, financial, and research domains (secondary uses).
The N*(N-1)/2 problem. This formula provides the number of interface specifications needed for integrating N systems without standards.
The stakeholders commonly include:
HL7 V3 is based on an object-oriented (“OO”) design paradigm. This means that it can be extended incrementally when new clinical information domains need to be added, in a way that doesn’t require changing what has already been created.
HL7 V3 is based on an ‘object information model’, called the Reference Information Model, (usually called just ‘the RIM’). This model is “abstract,” that is, it is defined without regard to how it is represented in a message “on the wire” or in a “service architecture” method or in a “clinical document.” In fact, each of these representations can contain the same “instance” of information. (Recall the lab test example.)
An important design goal for the V3 methodology has been: the computable semantics of the V3 models shall be explicit:
I.e. the models are self-defining: an application system receiving an instance of a specific V3 model, can, by referencing the explicit semantics of that model, use (in a computational sense) the information from that instance, without needing to know anything about the application that created the instance, and with the same level of functionality/meaning of the information that was available to the application that created the instance.
Also needed for jurisdictional level CSI: V3 has built-in support for
A bit of history –
HL7 V2 is designed for tightly coupled systems implementations where critical interoperability details may be negotiated directly between the sender/receiver.
AND, because …
… HL7 V 2.x messages are not explicitly self-defining.
Lack of “built-in” support for regional/jurisdictional CSI
The adoption of HL7 v3 has been slowed by a number of “market-place myths”
HL7 V3 is only used to specify a local system’s interface with the regional EHR. It does not specify anything about the internals of the local system.
The V3 data types are in fact small models in themselves, and thus inherently distinct from computer language or operating system data types.
However, like any part of an ‘interoperability standard’, they need to be mapped to/from each local system. If they were directly implementable in one system, they would not automatically be implementable in any other system.
Also, COTS UML tools do not (yet) support “specialization by constraint.”
This type of specialization, along with the use of “structural variables” (also legal and also not supported by COTS tools), allows the “small” V3 RIM to “fit on a single page” and still support the great diversity of current and future clinical information.
And: If there is an interoperability requirement not supported by the RIM, there is a formal methodology (RIM harmonization) to extend the RIM to accommodate the new requirements in a way that guarantees CSI.
This supports incremental extensions to the standard to meet business drivers while maintaining full existing interoperability as systems migrate to the new functionality.
Additionally, the history of RIM harmonization has shown these incremental, object-paradigm extensions to be pragmatic from both information modelling and stakeholder process viewpoints.
In other words, the regional EHR interface specification is “just another interface.” If the "local" system has been able to meet local interoperability requirements via creating new interfaces, this is “just more of the same.”
Note that we are not saying that no changes will be required by the "local" systems meeting the regional EHR specifications.
But we are saying that the changes are not different ‘in kind’ or ‘in complexity’ from the types of interface specifications the "local" vendors are already supporting.
And most importantly, the "local" system changes needed to support the regional EHR standards would be the same whether the regional EHR standards were specified in HL7 V2.x or HL7 V3; and that with an adequate V3 IG (see below), the needed changes are easier to understand and implement.
CDA r-2 also provides a 3-level incremental path to the regional EHR/"local system" interface. The 3 levels (and/or paths) are:
Level 1: document header is v3 mappable, the section, sub-section headers and section content are human readable text.
Level 2: document header and the section, sub-section headers are v3 mappable, but the section content is human readable text.
Level 3: document header and the section, sub-section headers, and section content are v3 mappable.
Note: levels 2 and 3 may be present in the same CDA document. I.e. some of the sections may contain only human readable text, while others may be fully v3-mappable.
V2/V3 mappings are also possible in some cases.
HL7 v3 message parsing resources are approximately 25% of the total cycles needed to process a v 3 message into a RIM-map-able persistent data store, so that cutting down on message size will not resolve this problem.
Adequate throughput for moving large volumes of v3 messages into v3-mappable persistent storage is possible with off-the-shelf Intel servers. See http://www.oracle.com/industries/healthcare/htb-intel-datasheet.pdf which includes email contactsand URL’s for further information.
Recall that the HL7 v 2.x standards do not ‘natively’ have the explicit semantics to support the regional EHR requirements for CSI. Thus, there is no guarantee that a certain type of information (e.g. observation results and/or client registry information) will be equally computable across the various HL7 v 2.x standards, and thus no guarantee that it will be equally computable among the various types of local systems. The same goes for coded vocabulary usage and jurisdictionally unique identifiers (patient, practitioner, provider, location).
For example, in Canada the initial development of Client Registry standards pre-dated the development of a full understanding of the requirements of a regional EHR. The initial Infoway Client Registry efforts with HL7 2.4 required making various technical changes to the standard needed for CSI including adding support for globally unique identifiers, precise vocabulary bindings, and more precise definitions of clients (providers, patients, practitioners, organizations).
These CSI requirements are more completely and computably expressed in the HL7 V3 methodology, and thus HL7 V3 was used to create the final Stable for Use HL7 V3 Infoway specifications.
Possible Origin: “local” vendors are having difficulties finding resources who understand HL7 V3.
The IT staff that is experienced competent at designing and implementing HL7 V 2.x messages cannot design and implement V3 interfaces: this means that there is something wrong with HL7 V3.
Implementation Guides: An Implementation Guide (IG) is a ‘Document’ that describes exactly how the Standard should be implemented in a specific business environment. For example, in Canada the pan-Canadian standards are supported by comprehensive IGs that describe the implementation of the standard in the Canadian regional “interoperable” EHR environment.
Implementation Guide Developers
Implementation Guide Users:
Infoway functions as a strategic investor. Although the jurisdictions must choose the projects, Infoway can participate in a several ways. If the analysis of project goals and requirements fits the published criteria for regional EHR standards, Infoway may cover from 50-100% of the cost as an investment towards creating the pan-Canadian regional EHR. The amount varies depending on the strategic importance of the project as per the Infoway mandate.
By taking part in HL7 through HL7 Canada, Infoway helps to create standards that meet its requirements. The fact that the HL7 standards have an increasing amount of international participation also means that the Infoway requirements find their way into international standards, which is an additional incentive for vendors to adopt them.
This same type of participation in all of the above SDOs, continues the process of Collaborationand Participation
It ensures that Infoway’s PCS interests are reflected in the work products of these groups (via working towards specific standards and influencing others).
It ensures that Infoway has a pro-active involvement in the developments in health information standards, developments that are or will be useful to the regional EHR.
A recent very positive step was the joint press release between HL7, CEN TC 251 and ISO TC 215, issued at the Geneva joint meeting last October, pledging the 3 organizations to work together, and which has since been finalized by all 3 organizations.
Current joint ISO/HL7/CEN projects status, as discussed by representatives from all three groups, at the January 2007 HL7 WG meeting in San Diego, the Montreal ISO meeting in March 2007, the recent May 2007 HL7 WG meeting in Koln, and the June 2007 CEN TC 251 meeting in London.
Items include Heathcare Datatypes, 13606/v3 harmonization and ICH (see below).
This will continue at the ISO TC 215 meeting being held just after MedInfo in Brisbane, Australia, later this month.
We have briefly reviewed:
Thank you for your attention and participation!