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
16 August 2007
CEO & Chief Information
Architect,
Shafarman Consulting, Inc.
mark.shafarman@earthlink.net
+1 510 593 3483
1
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
2
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
3
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
4
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
5
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
6
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
16 August 2007
N
N*(N-1)/2
3
6/2=3
90/2=45
380/2=190
2450=1225
10
20
50
7
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
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
Why HL7 V3: Design Tools
• V3 Templates (under development)
– There are several projects creating varieties of HL7 v3 templates
(equivalent to the CEN 13606 archetypes)
– These include:
• CDA r-2 CCD (clinical care document: see
http://www.hl7.org/ctl.cfm?action=ballots.home
• Also CDA templates being created by IHE, see:
http://www.ihe.net/Technical_Framework/index.cfm (Patient
Care Coordination Technical Framework)
• Further “Across the world” CDA r-2 examples:
http://www.hl7.org/Library/Committees/structure/20070111_C
DA_R2_examples.zip
• The NHS CfH CDA project experimenting with templates.
(contact Ian Townend <ian.townend@nhs.net>)
– Other current work with templates archetypes in various
paradigms
• Detailed Clinical Models group (DCM):
http://www.detailedclinicalmodels.org/wiki/index.php?title=M
ain_Page
• Wikihit (www.wikihit.org): clinical data definitions.
16 August 2007 – Also see HL7/ISO/CEN discussion below
20
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
21
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
22
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
23
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
28
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
30
1. Perception: The UML based RIM requires reengineering “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.
16 August 2007
31
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
32
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
33
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
34
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
35
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 reengineering 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
36
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
37
7. Perception: There is no Incremental Path towards
the "local"/regional EHR Interface
•
•
Possible Origin: Inadequate education & marketing. Lack of realworld 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, subsection 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
38
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 v3mappable persistent storage is possible with off-the-shelf Intel servers.
See http://www.oracle.com/industries/healthcare/htb-intel-datasheet.pdf
which includes email contacts and URL’s for further information.
16 August 2007
39
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
40
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
41
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
42
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
43
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
44
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
45
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
46
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
47
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
48
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
49
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 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.
• 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
50
E.g. The Infoway Standards Community – Nov. 2006
16 August 2007
51
E.g.: Standards Collaborative Governance Model
16 August 2007
52
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
53
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
54
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
55
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
56
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
60
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 documentbased
– Canada vs Finland for CDA.
• International SDO collaboration and harmonization
16 August 2007
61
Questions/discussion?
&
Thank you for your attention and
participation!
16 August 2007
62