Presentation on theme: "16 August 20071 Trends in Practical Deployment of HL7 Standards: supporting regional electronic healthcare records Mark Shafarman Past Chair HL7 with additional."— Presentation transcript:
16 August 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 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 Agenda IntroductionIntroduction Supporting regional electronic healthcare recordsSupporting 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 (SMEs) to create detailed Implementation guides Vs –Interface implementers local sites
16 August Agenda, continued Regional use cases requirements and processes: Infoway examples –Technical –Stakeholder involvements –Consensus processes Participation/Collaboration with other SDOs 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 HL7 v3 and the use case for regional/jurisdictional integration Supporting regional electronic healthcare records requires iSupporting 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 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 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 NN*(N-1)/2 3 6/2= /2= /2= =1225
16 August Technical note: Where did this formula come from? The formula, N*(N-1)/2, is the standard mathematical formula for n C 2, 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 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 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 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 (SMEs) Researchers/scientists Payors (governmental and non-governmental) And, of course, the citizens/patients
16 August 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 doesnt 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 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 doesnt invalidate the previously created models. This again is a feature of object-oriented (OO) paradigms.
16 August Why HL7 V3: Design Tools The RIMs 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 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 Why HL7 V3: Design Tools Technical note: the MIF and the ITSs –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 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 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 UKs 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 Why HL7 V3: Design Tools The Design tools are being extended to support/create: Conformance testing applications –See Infoways 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 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: CDA_R2_examples.zip CDA_R2_examples.zip 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): Main_Page Main_Page Wikihit (www.wikihit.org): clinical data definitions. –Also see HL7/ISO/CEN discussion below
16 August 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 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 institutions 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 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 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 doesnt 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 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 OBXs) Time series results (1 OBR followed by many OBXs, 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 OBXs. Narrative reports: (1 OBR followed by many OBXs) Waveform reports: (1 OBR followed by many OBXs) 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 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
16 August 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 is being ordered to treat this causes this this is supporting evidence for this continue until becomes less than.
16 August 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 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 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 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 APIs) that can be used to transfer information between disparate (or identical) application systems. HL7s scope does not specify the design internals of any specific application(s). HL7 V3 is only used to specify a local systems interface with the regional EHR. It does not specify anything about the internals of the local system.
16 August 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 Perception; HL7s 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 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 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 IGs 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 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 Ive 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 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 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 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 UKs 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 URLs for further information.http://www.oracle.com/industries/healthcare/htb-intel-datasheet.pdf
16 August 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 Perception: HL7 V3 is Not Ready, continued It is important to note that Canada Health Infoways 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 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. Shouldnt 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 wont 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 Perception: Governments have mandated HL7 V2. Possible Origin: why would HL7 V 2.x standards be mandated if theyre 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 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 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 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 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 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 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 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 E.g. The Infoway Standards Community – Nov. 2006
16 August E.g.: Standards Collaborative Governance Model
16 August 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 Infoways 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 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 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 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 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 –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 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 CENs 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 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 Summary We have briefly reviewed: Supporting regional electronic healthcare recordsSupporting 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 (SMEs) to create detailed Implementation guides Vs –Interface implementers local sites
16 August Summary, continued Regional use cases requirements and processes: Infoway examples –Technical –Stakeholder involvements –Consensus processes Participation/Collaboration with other SDOs 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 Questions/discussion? & Thank you for your attention and participation!