Mark Shafarman Past Chair HL7 with additional HL7 “roles” of

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. mark.shafarman@earthlink.net +1 510 593 3483

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.

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”

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

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.

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).

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

8. 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.

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).

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

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.)

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.

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.

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.

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 schemaderived from the abstract model (MIF) is what is transmitted ‘on the wire.’

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)

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_CDA_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=Main_Page • Wikihit (www.wikihit.org): clinical data definitions. • Also see HL7/ISO/CEN discussion below

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. 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 http://www.oracle.com/industries/healthcare/htb-intel-datasheet.pdf which includes email contactsand URL’s for further information.

32. 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.

33. 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.

34. 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).

35. 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.

36. 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.

37. 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.

38. 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.

39. 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.

40. 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.

41. 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).

42. 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.

43. E.g. The Infoway Standards Community – Nov. 2006

44. E.g.: Standards Collaborative Governance Model

45. 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 Collaborationand Participation It ensures that Infoway’s PCS interests are reflected in the work products of these groups (via working towards specific standards and influencing others). 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.

46. 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

47. 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

48. 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.

49. 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”

50. 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