1. 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
Review Board
member Early Adopters Forum
co-chair Templates Sig
CEO & Chief Information Architect,
Shafarman Consulting, Inc.
16 August 2007

2. Acknowledgments
The research for this presentation was funded by Canada Health Infoway.
Many members of HL7 Global contributed their thoughts and experience to this presentation.
16 August 2007

3. Agenda Introduction Supporting regional electronic healthcare records
Computable semantic interoperability
Stakeholder consensus process
HL7 v3 and the use case for regional/jurisdictional integration
Why v3 and not v2
Marketplace myths about v3
A critical difference:
Health Informaticians working with subject matter experts (SME’s) to create detailed Implementation guides Vs
Interface implementers “local sites”
16 August 2007

4. Agenda, continued
Regional use cases requirements and processes: Infoway examples
Technical
Stakeholder involvements
Consensus processes
Participation/Collaboration with other SDO’s
Regional Approaches:
“switchpoint” vs. “respository(ies)” (Canadian/UK vs.Netherlands example)
Message-based and/or service-based and/or document-based
Canada vs Finland for CDA.
International SDO collaboration and harmonization
Summary
16 August 2007

5. HL7 v3 and the use case for regional/jurisdictional integration
Supporting regional electronic healthcare records requires integrating healthcare information among various sites and/or organizations:
Regional integration requires two major efforts
“how”: creating CSI ( Computable Semantic Interoperability)
“what” is decided by a stakeholder consensus process to define the details of the patient information that will populate a regional EHR.
16 August 2007

6. What is CSI?
CSI requires that the information can be transmitted reliably between heterogeneous applications: this is known as functional interoperability,
and
CSI requires that this transmission can occur without loss of meaning, and thus without loss of computability: this is known as semantic interoperability.
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).
16 August 2007

7. Drivers for CSI: the “combinatorial explosion”
The N*(N-1)/2 problem. This formula provides the number of interface specifications needed for integrating N systems without standards.
For N distinct systems, the use of standards brings the number of interface specifications down to “just N”.
If the N systems have fewer than N separate “information domains” (i.e. they have common domains), the number of specifications will be less than N N
N*(N-1)/2 3
6/2=3 10
90/2=45 20
380/2=190 50
2450=1225
16 August 2007

8. Technical note: Where did this formula come from?
The formula, N*(N-1)/2, is the “standard” mathematical formula for nC2, “the number of combinations of N items, taken two at a time.”
Without using standards, this calculation gives us the number of point-to-point interface specifications needed to completely interconnect N systems.
Since each point-to-point specification will require coding work on each of the two systems, the total number of software projects required is actually double the above number, and thus is sometimes calculated as just N*(N-1).
16 August 2007

9. Drivers for CSI
The second driver is enabling re-use of information without loss of meaning. It is fundamental to the regional EHR that information may be reused for multiple purposes. Thus a lab result ordered in an outpatient clinic and obtained from the local laboratory may also need to be part of a patient summary document, or a reason to order a specific medicine using a computerized physician order entry system (CPOE), or an indication of a particular disease for any decision support system, or relevant to a public health surveillance system or clinical research system.
Each application needing to make use of the specific lab result should be able to base its computations on a single unambiguous representation of the lab result, and should not be expected to make any inferences or assumptions about the meaning of actual result.
16 August 2007

10. Stakeholder consensus process
This second driver, semantic interoperability, is the one that requires the stakeholder consensus process.
The stakeholder consensus process defines the details of the shared information that populates the regional EHR. It will define:
both the primary and secondary healthcare information use case requirements
policy requirements including jurisdictional policies on privacy, security, authentication
technical issues such as “identification” and vocabulary (coding systems).
16 August 2007

11. Stakeholder consensus process
The stakeholders commonly include:
the governmental health authorities (e.g. ministry of health or equivalent, public health authorities)
Clinicians and allied health professionals
Vendors and health information professionals
Subject matter experts (SME’s)
Researchers/scientists
Payors (governmental and non-governmental)
And, of course, the citizens/patients
16 August 2007

12. Why HL7 V3: “OO”
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.
(technical point) The recent history of changes to the RIM validate this claim. The “structural changes” have decreased almost to nil, while the “structural vocabulary” changes have increased to accommodate new domains. An example is the recent addition of the “clinical genomics” domain.
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.)
16 August 2007

13. HL7 Development Framework
The HL7 Development Framework is a formal methodology for mapping any “local”, domain specific system, such as a “laboratory system” in the v3 Reference model.
The basic concept is that any system can be mapped into a “neutral” and formal UML-based Domain Analysis Model (DAM) with the help of domain experts.
The DAM can then be mapped into the equivalent v3-RIM model.
This mapping is bi-directional, and highlights any changes needed by either the “local” system or the RIM to create a semantically complete mapping that will support CSI.
There is a formal RIM Harmonization process which supports a standard way to add new domain requirements from a DAM to the RIM in a way that doesn’t invalidate the previously created models. This again is a feature of object-oriented (“OO”) paradigms.
16 August 2007

14. Why HL7 V3: Design Tools
The RIM’s UML basis also supports a formal design methodology, the “HL7 Development Framework” (HDF) for the V3 models (including business use cases, interactions, etc.)
Because the RIM is defined in an “OO” language (Universal Modeling Language), UML, software can be created to enable models that are used for V3 messages, documents and services.
The UML basis also supports formal vocabulary bindings to the models.
Technical note: this is important both for the “structural vocabulary”, and the “clinical vocabularies.”
The “structural vocabulary” is a key part of the semantics of the V3 models. It defines the relationships between the model elements. E.g. the ‘mood’ codes define whether a particular model is an order or a result.
16 August 2007

15. Why HL7 V3: Design Tools
Technical note, continued:
The “clinical vocabulary” defines the clinical meaning that a given model structure can support. E.g. the LOINC code defines the clinical content of a particular lab information model (white blood count, red blood count), used in a lab message.
A suite of visual design tools has been created to aid V3 designers create models that are derived from the RIM, and to create the actual message (or document or service) instances of these models.
16 August 2007

16. Why HL7 V3: Design Tools Technical note: the MIF and the ITS’s
a sharable XML-based format is used to express the abstract specifications for V3 models. It is called the MIF (the HL7 V3 “Model Interchange Format”). The MIF expressions of the V3 models are the basis for the V3 design and implementation software tools.
The ‘on the wire’ V3 message (or service or document) instances are created by using the MIF specifications to define the ‘on the wire’ format, which is then used to create a specific ‘instance’.
These ‘on the wire’ formats are called ‘implementable technology specifications (ITS)’.
More than a single ITS is possible.
For example, there is standard XML-based ITS, commonly called the “XML-ITS”. In this case, an XML schema is generated from a specific MIF specification of the ‘lab message model’. This schema is then ‘filled in’ with the specific values for a specific lab test (i.e. what test, what value, what status, when, etc.) and that XML instance of the XML schema derived from the abstract model (MIF) is what is transmitted ‘on the wire.’
16 August 2007

17. Why V3: Self-defining explicit semantics
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.
Thus V3 message instances are “self-defining”
Also needed for jurisdictional level CSI: V3 has built-in support for
globally unique identifiers
Precise non-ambiguous vocabulary bindings
Cross-domain consistency (recall lab result example)
16 August 2007

18. Why HL7 V3: Design Tools
Some new XML ITS variants are being developed, along with tools to use them
One is a an XML ITS that has closer alignment with UML, and should allow the use of COTS UML tools in V3 message processing. (Currently being balloted)
A second new XML-based ITS is being tested in which the schemas are closer to the ‘application view’ of the clinical domains. (Being tested by the UK’s NHS CfH)
These may make V3 implementation easier.
Both of these new ITS variants will be based on the MIF and thus will express the same semantics as the current XML ITS, and be completely map-able into the current XML ITS.
16 August 2007

19. Why HL7 V3: Design Tools
The Design tools are being extended to support/create:
Conformance testing applications
See Infoway’s sponsorship of the e-Health Collaboratory
See NIST (US: National Institute of Standards and Technology) work with HL7 v3
Implementation Guides that support more automated message instance generation and validation
See NLM/EHR IG project using HL7 Canada tools extensions (URL available and final report available soon)
See NHS CfH MIM (“Message Implementation Manual”)
See HL7 Implementation/Conformance Technical Committee discussion list and website for other current projects
16 August 2007

20. Why HL7 V3: Design Tools V3 Templates (under development)
There are several projects creating varieties of HL7 v3 templates (equivalent to the CEN archetypes)
These include:
CDA r-2 CCD (clinical care document: see
Also CDA templates being created by IHE, see: (Patient Care Coordination Technical Framework)
Further “Across the world” CDA r-2 examples:
The NHS CfH CDA project experimenting with templates. (contact Ian Townend
Other current work with templates archetypes in various paradigms
Detailed Clinical Models group (DCM):
Wikihit ( clinical data definitions.
Also see HL7/ISO/CEN discussion below
16 August 2007

21. HL7 V3 Summary
HL7 V3 has “built-in” support for CSI: the models and the messages, using those models are explicitly self-defining.
The clinical documents and services (SOA paradigm) using these models are also explicitly self-defining.
The OO basis of the HL7 V3 methodology (the HDF) is used to design the abstract V3 models, as well as the messages (and services and documents) expressing the instances of those models.
The OO basis of HL7 V3 supports the creation of design and implementation software tools.
The pattern of adoption of HL7 V3: it is being adopted where regional/jurisdictional CSI is required. This is also compelling evidence that it supports regional/jurisdictional CSI (More on this later…)
Normative Status: The HL7 V3 RIM is a recognized and accepted ISO standard, and normative editions of HL7 V3 messaging standards are being released yearly starting with 2005.
16 August 2007

22. What about HL7 v 2.x? A bit of history –
HL7 v 2.x was created to integrate a small number of varied healthcare application systems within a single hospital or organization.
HL7 v 2.x supported the “best of breed” strategy. I.e. if I can create a local interface specification for my institution’s lab system, that local interface specification allows me to upgrade or replace my existing lab system with a better one without having to upgrade or replace all the other systems. Hence the name: ”best of breed strategy” (for systems replacement and update).
HL7 v 2.x also evolved during the time of transition from paper-based systems.
HL7 v 2.x has been very successful in these settings.
16 August 2007

23. What about HL7 v 2.x?
HL7 V2 is designed for tightly coupled systems implementations where critical interoperability details may be negotiated directly between the sender/receiver.
It supports a number of ‘local variants’ and ‘locally created optionality’, which makes it straight-forward to integrate a small number of systems.
AND, because …
It is not based on a formal object-oriented methodology
and
It has an implicit information model rather than an explicit, formal information model
… HL7 V 2.x messages are not explicitly self-defining.
16 August 2007

24. What about HL7 v 2.x?
It does not have generic support for CSI on a regional/jurisdictional basis.
and
Design and implementation software tooling can not be created based on the semantics of V2 message specifications using modern OO paradigms and software design principles.
code generation based on an explicit information model is not possible.
V 2.x message structures can have multiple, incompatible meanings, defined only via human readable text.
Non-support for regional/jurisdictional CSI:
V 2.x doesn’t require:
Globally unique identifiers for clinicians, patients, locations, orders, accessions, results, etc.
Uniform vocabulary bindings: a single v 2.x coded field may have a ‘table’ of codes that may reference several distinct concepts, and/or may be totally locally defined.
16 August 2007

25. Non-explicit semantics: V 2.x examples
The ORU message (observation result unsolicited) uses a common structure consisting of a single OBR segment followed by one to many OBX segments. This single structure is used to support a wide variety of semantics including:
Single result observations (1 OBR followed by 1 OBX)
Batteries/panels (1 OBR followed by many OBX’s)
Time series results (1 OBR followed by many OBX’s, where each OBX carries a value for the same test/observation obtained at a different time)
Microbiology: a linked tree-series of 1 OBR followed by many OBX’s.
Narrative reports: (1 OBR followed by many OBX’s)
Waveform reports: (1 OBR followed by many OBX’s)
There are no limits on the patterns of interpretation which can be applied to this same structure on a site-specific basis in HL7 V2. This is a major impediment to creating CSI.
16 August 2007

26. Non-explicit semantics: V 2.x examples
Another example of non-explicit semantics can be found in the patient administration messages where there are several ways to interpret the meaning (semantics) and the relationships between an “account”, an “encounter” and a “visit”.
Some of these meanings and relationships are supported by explicit trigger events, others are not. In some sections of HL7 V2 the semantics of these distinct concepts are not clear: they are allowed to be understood as either the same or distinct. For an example, refer to their HL7 V2.5 definitions in the PID and PV1 segments and the use of the PV1-51 field, Visit Indicator.
Z-segments and Z-fields
Site-specific segments and local site-defined fields extending “standard” segments are allowed.
Local site-specific trigger events and interaction patterns
Business drivers: for v2…; history from paper based… local systems…Heterogeneous systems, best of breed w/in a ‘hospital/local’ setting…; OK w/in that ‘ring of negotiation’…
16 August 2007

27. Incomplete semantics: V 2.x
The semantics of HL7 V 2.x are incomplete for many types of “clinical statements”
For example, an equivalent to the V3 “actRelationship” is lacking
Thus, many types of “clinical statements” needed in an regional EHR are not possible to express explicitly in HL7 V2 because there are a number of ‘structural and causal’ relationships that cannot be expressed explicitly.
Some examples include:
“this <medication> is being ordered to treat <this disease>”
“this <disease> causes this <symptom>”
“this <observation value> is supporting evidence for this <disease>”
“continue <this medication> until <this particular observation’s value> becomes less than <this value>.”
Note that the proposed v 2.6 REL segment for v 2.6 (see chapter 12, Patient Care) incompletely represents the semantics of the v3 ActRelationship class. For example, the field REL:2, Relationship Type, is a CWE datatype, which allows local extensions to the concept. There are also several key attributes of the RIM class, actRelationship, that have no equivalents in the REL segment.
16 August 2007

28. HL7 V 2.x summary
Lack of “built-in” support for regional/jurisdictional CSI
Implicit semantics in interactions, message structures, and vocabulary bindings does not support formal software development methodology or software tools development
Implicit semantics requires human-readable text to describe the semantics of each message and interaction: V 2.x messages are not “self-defining”.
Incomplete semantics: basic ‘causal’ and ‘structural’ elements needed for clinical information are lacking.
Local variants (Z-segments, site-specific non-standard coded vocabularies, identifiers, Z-trigger events, Z-fields) exacerbate the N*(N-1)/2 combinatorial explosion of interface specifications.
Globally unique identifiers are not required.
16 August 2007

29. HL7 V 2.x summary
Normative status: HL7 V2.5 is the only comprehensive, currently recognized V2.x standard. HL , which has just passed ballot, is constrained to only include changes required for US regulatory requirements. HL7 2.6 is the next full release and is undergoing final ballot reconciliation at the time of this writing.
16 August 2007

30. HL7 V3: myths in the marketplace
The adoption of HL7 v3 has been slowed by a number of “market-place myths”
This section will discuss each of the main market-place misperceptions regarding HL7 V3.
Each slide will discuss the mis-perception, what may have given rise to it, and the “real” facts that are not clearly understood or appreciated.
16 August 2007

31. 1. Perception: The UML based RIM requires re-engineering “local” systems.
Possible origin: the increasingly common practice of using UML models as a basis for system design. It is now common to use UML specifications as input into a code generation engine (for one or more computer languages), which then produces code for the application.
Fact: HL7 specifies only interoperability standards (whether messages, documents, or API’s) that can be used to transfer information between disparate (or identical) application systems. HL7’s scope does not specify the design internals of any specific application(s).
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.
Do this w/animation w/animation…;
16 August 2007

32. 2. Perception: HL7 V3 Data Types are not “implementable.”
Possible origin: Some implementers have assumed that, since their computer language or operating system already has a set of data types, which are different from the V3 data types, their system cannot implement V3 data types, and hence cannot implement V3 messages.
Fact: The V3 data types, like any elements of the RIM or its artefacts, are defined abstractly, without reference to a particular implementation, but to support the use cases needed for CSI of clinical information. Hence they are defined abstractly, and serve only to support CSI of clinical information between systems.
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.
16 August 2007

33. 3. Perception; HL7’s use of Specialization by Constraint is not “legal” UML (“technical”)
Possible Origin: The common type of UML specialization consists of adding elements to a “base” class, thereby creating a new “specialized” class that inherits all the behaviour and attributes of the base class, but has the added attributes and behaviours.
Also, COTS UML tools do not (yet) support “specialization by constraint.”
Fact: OMG experts have pointed out that the formal definition of “specialization” consists of “the addition of information to a class”. Since removing (or formally “not using”) elements is formally adding information to the class definition, “specialization by constraint” is formally allowed in UML.
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.
16 August 2007

34. 4. Perception: HL7 V3 cannot support the variability needed by the regional EHR
Possible Origin: HL7 v3 messages cannot model all the variability that exists in the current HL7 V2 installed base and/or HL7 v3 does not have the equivalent of z-segments, therefore it cannot support all the interoperability variations currently supported by V2.
Fact: HL7 v3 can support more interoperability than is required by current V2 variations, but in an explicit, computable manner. (see V 2.x, incomplete semantics above)
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.
16 August 2007

35. 5. Perception: HL7 V3 Conformance Testing is difficult and problematic
Possible Origin: See the discussion below on the differing requirements and background knowledge needed by V3 message and Implementation Guide creators, and V3 implementers. If the implementers do not have detailed, comprehensive IG’s they will perceive (and have) difficulties testing conformance.
Fact: because the V3 models are self-defining, and their UML-basis encourages tools creation based on modern software design practices, the processes of creating conformance testing “harnesses” is more amenable to automation than with the V2.x messages.
Two examples:
Canada Health Infoway has invested in the e-Health Collaboratory to build conformance testing capabilities.
NIST (US: National Institute of Standards & Technology) is experimenting with v3 conformance tools.
16 August 2007

36. 6. Perception: HL7 V3 requires (major) changes to “local” systems
Possible Origin: This issue is similar to the UML-issue described in Myth #1. There is a continuing perception that adding the new regional EHR interfaces requires major re-engineering of “local” systems.
Fact: “The regional EHR is just another system needing an interface with my system,” and “I’ve been provided with a very detailed implementation guide(s) for this new interface.”
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.
16 August 2007

37. 6. Perception: HL7 V3 requires (major) changes to “local” systems (continued)
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.
16 August 2007

38. 7. Perception: There is no Incremental Path towards the "local"/regional EHR Interface
Possible Origin: Inadequate education & marketing. Lack of real-world demonstrations.
Fact:
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.
16 August 2007

39. 8. Perception: HL7 V3 Messages are too large
Possible Origin: V3 messages are in fact larger than V2 messages
Fact: This issue has arisen in some v3 implementations, such as those being tested in the UK’s Connecting for Health (CfH) program. However, recent studies by Intel with the Oracle Healthcare Transaction Base (HTB – a v3-enabled clinical applications development platform) have shown that:
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 which includes contacts and URL’s for further information.
16 August 2007

40. 9. Perception: HL7 V3 is Not Ready
Possible Origin: Since all the necessary HL7 v 3 standards are not normative HL7, HL7 v3 is not ready to meet the regional EHR requirements.
Fact: An example of a pragmatic way of dealing with this question. Canada Health Infoway has established a process of stakeholder and expert review of HL7 specifications for stability, adequacy, and consistency. When a particular HL7 specification meets those requirements, Canada Health Infoway can certify it as Stable for Use (SFU) even if it has not passed HL7 membership ballot and become a normative, global standard. The SFU certification also includes the expectation that the SFU Standard will be upgraded to the final HL7 global standard (status FA: Final Approval) without significant impact on either the regional EHR system or the “local” systems.
16 August 2007

41. 9. Perception: HL7 V3 is Not Ready, continued
It is important to note that Canada Health Infoway’s process in implementing SFU HL7 v3 specifications has been successful, and that the implementation experience with these specifications has had a positive impact on moving HL7 standards forward to the “global standard” level.
16 August 2007

42. 10. Perception: HL7 V2 is sufficient for regional EHR
Possible Origin: In certain jurisdictions, HL7 v 2x standards with HL7 V 2.x implementations have achieved ‘market-dominance’. Shouldn’t these be sufficient for meeting regional EHR requirements?
Fact: These V 2.x implementations have not been created to meet regional EHR interoperability requirements, and thus won’t necessarily support these requirements.
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).
16 August 2007

43. 11. Perception: Governments have mandated HL7 V2.
Possible Origin: why would HL7 V 2.x standards be mandated if they’re not sufficient to support a regional EHR?
Fact: HL7 V 2.x does not explicitly support CSI (see previous), and existing V 2.x standards will not automatically support regional/jurisdictional CSI .
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.
16 August 2007

44. 12. Perception: Incentives for Vendors do not exist
Possible Origin: Inadequate education & marketing. Lack of real-world demonstrations.
Fact: It is important to note that if a given vendor has local systems in more than one jurisdiction, that vendor only has to meet a single set of regional EHR interface specifications to support the regional EHR interface for all jurisdictions in the region. Since other suppliers with different local information domains will be meeting the same regional EHR specifications, interfacing with other suppliers (at least for the transactions supported by the regional EHR), will be trivial.
16 August 2007

45. 13. Perception: HL7 V3 is difficult to implement
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.
Fact: As is explained detail below, there is a very different knowledge and education background that is needed to design a V3 interface and/or to create a V3 Implementation Guide from that needed to implement a V3 interface (given an adequate V3 Implementation Guide). This is due to the fact that V3 interfaces are primarily used in situations requiring CSI among varied institutions and jurisdictions.
16 August 2007

46. 13. Perception: HL7 V3 is difficult to implement, cont.
This difference creates a very different set of knowledge and educational background requirements from those needed to design and implement interfaces to integrate a single institution, which is the historical use case for HL7 V2.x interfaces.
The problem is not with HL7 V3, but with the lack of understanding concerning the difference in the skill-sets and prior knowledge needed.
Experience shows that with a detailed V3 implementation guide, such as those produced by Canada Health Infoway or those produced by NCTIZ in the Netherlands, a programmer knowledgeable in XML, and a person who is familiar with the local system, the cost of implementing an HL7 V3 regional EHR interface specification is actually less than the cost of implementing the equivalent V 2.x interface.
16 August 2007

47. HL7 V3 implementation drivers
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.
In HL7 V3, the implementation guide for the normative message model (with the vocabulary bindings) carries explicit computable meaning, and thus a there is no need to research the implicit meaning patterns not carried by the model, and no need to implement variant message semantics for each site/institution.
The equivalent HL7 V2 implementation guide requires supporting the same concepts as the HL7 V3 implementation guide (e.g.: globally unique identifiers, client registry support, support for the same interactions/use cases). However, the various HL7 V2.x segment patterns, vocabulary bindings, and identifier strategy will need to be identified and described in text, since in HL7 V2 these elements will not explicitly support CSI. This will, in general, make the HL7 V2 Implementation Guide more complex and prone to error.
16 August 2007

48. HL7 V3 implementation drivers
Implementation Guide Developers
Technical understanding of the many aspects of the Standard is necessary to create the artefacts contained within an HL7 V3 IG. The HL7 V3 implementation guide designer must have enough knowledge of clinical informatics, information modeling, and UML to understand the HL7 V3 design process. This level of knowledge usually requires training in the V3 essentials, including the RIM, vocabulary bindings, globally unique identifiers, HL7 V3 tools, and creating and understanding V3 specifications. For example, this level of expertise is core to all Canada Health Infoway and NCTIZ Implementation Guide projects.
Stakeholder engagement is critical to ensure that the business representations in the IG accurately reflect the business requirements of the jurisdiction. For example, the Infoway and NCTIZ processes provides the organizational framework for achieving the needed consensus.
16 August 2007

49. HL7 V3 implementation drivers
Implementation Guide Users:
Experience has shown that, with a detailed explicit V3 message implementation guide and a solid knowledge of XML, a local site interface programmer working with at least one local system expert, can implement a V3 interface faster and more accurately than a V2 interface.
In the Netherlands, where HL7 V3 has widespread adoption and usage of Implementation Guides, experience has shown that for a single interface specification, the implementation time is on the order of one week or less.
This difference in effort exists not only when comparing the implementation of HL7 v3 to v2 messaging interfaces, but also exists when comparing the effort needed to implement a CDA release 2 document interface with a complete implementation guide (such as the CCD: continuity of care document) versus implementing the less completely specified CCR standard (which like V2, was not designed with CSI as a main requirement).
16 August 2007

50. An example: Infoway Incentives for HL7 v3 Adoption
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 % 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.
The Infoway investment is focussed on creating CSI for the regional interoperability infrastructure needed for the regional EHR, rather than hardware for networks, servers, or desktops.
Since the regional EHR interface specifications apply in the pan-Canadian context, Infoway, in effect, amortizes its contributions/costs over the entire country.
16 August 2007

51. E.g. The Infoway Standards Community – Nov. 2006
16 August 2007

52. E.g.: Standards Collaborative Governance Model
16 August 2007

53. Collaboration/Participation
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 Collaboration and 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).
And also
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.
16 August 2007

54. Two important regional variations
“National (regional) switchpoint”
E.g. Netherlands, Greece
Requires central client (patient), provider, and organizational registries
Query/response paradigm used to retrieve discrete data
versus
Central respository(ies)
E.g. (Canadian/UK)
Requires central registries as above
Discrete results uploaded to central/regional registries
16 August 2007

55. Infrastructure variants
Message-based and/or document-based
Experiences:
Canada: HL7 v3 message based paradigm, will support CDA also
At “repository layer” interfaces, messages will be transformed into services that ‘talk to’ the repositories.
Finland, Greece: CDA-based information storage and retrievals
Japan: extensive use of CDA
Planned:
Australia: will use CDA for EHR interoperability
UK: NHS use of CDA with v3 “templates” is being studied
16 August 2007

56. Some other trends: SDO collaboration and harmonization
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.
16 August 2007

57. HL7, CEN TC 251 and ISO TC 215 Current status:
Organizational processes for collaboration were on the agenda at the ISO TC 215 meeting in Montréal, Quebec, in March 2007.
Including the creation of a “joint initiative council” to coordinate such projects.
Including one new project, ICH harmonization between ICH, CEN and HL7 with coordination under the ISO “joint initiative council.”
ICH is the International Conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use, and the EU commission has asked CEN TC 251 to create standards meeting the EU ICH requirements.
HL7 already has v3 standards in two of the important ICH areas: ICSR (Individual Case Safety Report) and SPL (Structured Product Labeling)
16 August 2007

58. HL7, CEN TC 251 and ISO TC 215
A harmonized version of healthcare data types will be submitted to ISO TC 215. This will be based on the work that Grahame Grieve of HL7 Australia. The second ballot will appear in the August 2007 HL7 V3 ballot.
An HL7 v3 implementation guide for CEN is being planned (but this has not yet been finalized). This may be associated with Part 5 of CEN (Exchange Models), which is the last part of the CEN standard, and which has not proceeded far enough in its ballot cycle to be submitted to ISO.
Since the openEHR archetype model has been added to CEN (parts 2 and 3), archetypes will be another item that will need to be harmonized between HL7 and CEN at the ISO level. Formal work on this project has not yet started.
Work has also begun on a harmonization between CEN’s HISA (Health Information System Architecture) and the v3 RIM; this will also include harmonization work on the SOA level with the HL7 SOA SIG.
16 August 2007

59. HL7, CEN TC 251 and ISO TC 215
As with the CEN standards mentioned above, the CEN and HL7 standards supporting ICH must be harmonized at the ISO level with the comparable HL7 v3 standards. Otherwise countries that mandate ISO standards will have the same political issues that EU countries have in dealing with the tension between mandated CEN standards and global HL7 standards.
16 August 2007

60. Summary We have briefly reviewed:
Supporting regional electronic healthcare records
Computable semantic interoperability
Stakeholder consensus process
HL7 v3 and the use case for regional/jurisdictional integration
Why v3 and not v2
Marketplace myths about v3
A critical difference:
Informaticians working with subject matter experts (SME’s) to create detailed Implementation guides Vs
Interface implementers “local sites”
16 August 2007

61. Summary, continued
Regional use cases requirements and processes: Infoway examples
Technical
Stakeholder involvements
Consensus processes
Participation/Collaboration with other SDO’s
Regional Approaches:
“switchpoint” vs. “respository(ies)” (Canadian/UK vs.Netherlands example)
Message-based and/or service-based and/or document-based
Canada vs Finland for CDA.
International SDO collaboration and harmonization
16 August 2007

62. Questions/discussion?
&
Thank you for your attention and participation!
16 August 2007