Health Information Exchange Clinical Data Repository Utility Services Architecture Building Block HISO

Transcription

1 Health Information Exchange Clinical Data Repository Utility Services Architecture Building Block HISO To be used in conjunction with HISO Health Information Exchange Overview and Glossary HISO Health Information Exchange Content Model HISO Health Information Exchange Structured Documents

2 Copyright Information This document is covered by the standard Ministry of Health Crown Copyright statement, which can be viewed at Published in April 2012 by the Ministry of Health PO Box 5013, Wellington, New Zealand (online) This document is currently available on the HISO website: Glossary A glossary of all the terms used throughout this suite of draft standards is located in the Health Information Exchange Introduction and Overview document. The glossary also refers to relevant websites. Table of Contents 1 Introduction Purpose Context Scope Related Documents Architectural Requirements Utility Services Registry-Repository Model Regional CDRs Forms Transport Services Identity Services Security Document and Image Management Network Requirements Terminology Services Health Information Exchange Clinical Data Repository Utility Services v1 2

3 Table of Figures and Tables Figure 1: Health Information Exchange... 7 Figure 2: XDS Registry-Repository Model... 8 Figure 3: XDS-Enabled R-CDR... 9 Figure 4: Patient Identity Transactions Figure 5: Document and Image Retrieval Table 1: HIE Utility Services Scope Health Information Exchange Clinical Data Repository Utility Services v1 3

4 1 INTRODUCTION This document describes the Health Information Exchange (HIE) Clinical Data Repository (CDR) Utility Services architecture building block of the Interoperability Reference Architecture for the New Zealand health and disability sector. 1.1 Purpose The purpose of this suite of documents is to be an authoritative reference in stating how systems interoperability is to be achieved in the sector. The document is in direct support of the National Health IT Plan and its model of health information sharing based on regional CDRs (R-CDRs), national patient and provider indexes, and Connected Health networks. 1.2 Context Figure 2 in the HIE Overview and Glossary document shows the place of the building blocks in the Interoperability Reference Architecture and its relationship to the other key building blocks. An overview and the glossary of terms relating to the Health Information Exchange Architecture Building Blocks accompanies the building block documents: HIE Overview and Glossary The building blocks are: HIE CDR Utility Services (the subject of this document) HIE Content Model, a framework for the creation of a common set of logical data definitions HIE Structured Documents, a framework for structured documents as the currency of the HIE 1.3 Scope The scope of the building blocks is interoperability as it pertains to information exchange at regional and national level in support of the National Health IT Plan. The building block described in this document relates to transport mechanisms in and around HIEs and R- CDRs. It defines how R-CDRs and other participating systems interface to HIEs and the nature of transactions between interface points. It defines required functionality in terms of a set of utility services that HIEs and R-CDRs must provide. Table 1 further characterises the scope of information exchange addressed by this building block. In Scope Transport mechanisms Patient information Point-of-care use cases Transactional use cases Clinical applications Inter-system interfaces Utility services Out of Scope Content model, structured documents Information that is not patient related Back office use cases Data extracts, analytical use cases Non-clinical applications User interfaces Entity and task level services Table 1: HIE Utility Services Scope Health Information Exchange Clinical Data Repository Utility Services v1 4

5 1.4 Related Documents Related documents and websites are: National Health IT Plan Health Information Standards Organisation Interoperability Reference Architecture International Standards Organization ISO Parts 1 5: Health informatics - Electronic health record communication ISO Parts 1 6: Information technology - Metadata registries (MDR) ISO 21090: Health informatics - Harmonized data types for information interchange CCR OpenEHR HL or Other relevant websites are listed in the HIE Overview and Glossary document Health Information Exchange Clinical Data Repository Utility Services v1 5

6 2 ARCHITECTURAL REQUIREMENTS This section states the principles, directives and architectural requirements generally that make up this building block. Architectural requirements are presented under these headings: Utility Services Registry-Repository Model Regional CDRs Transport Services Identity Services Security Document and Image Management Network Requirements Terminology Services 2.1 Utility Services Figure 1 shows the HIE as a standards-based fabric across which participant systems exchange information via services. R-CDRs and certain other national and regional systems produce services while point-of-care or point of service systems consume them. An example of this is a service that enables a General Practitioner (GP) Practice Management System (PMS) to update a medication list in an R-CDR. Each system can individually and directly access services via the HIE. The diagram shows the three service layers: utility services (that provide basic information sharing functions), entity services (that compose multiple utility services for operations on business entities such as complete patient records), task services (that operate on entity services and implement workflow tasks). This building block addresses the utility services layer. It states requirements for a particular set of document sharing services based on the Integrating the Healthcare Enterprise (IHE) Cross Enterprise Document Sharing (XDS) integration profile and associated profiles. The utility services shown in Figure 1 include: PIXV3 and PDQV3 identity services XDS registry-repository services Audit Trail and Node Authentication (ATNA) security services Additional utility services may be defined as the requirements arise Health Information Exchange Clinical Data Repository Utility Services v1 6

7 Figure 1: Health Information Exchange Health Information Exchange Clinical Data Repository Utility Services v1 7

8 2.2 Registry-Repository Model Figure 2 depicts the XDS registry-repository model of information exchange, showing the various actors and their interactions HIE transport shall follow the XDS registry-repository model HIE transport is required to follow the registry-repository model specified by the XDS integration profile. Specifically, the requirement is for the XDS.b version (with the earlier XDS.a now deprecated internationally). XDS is a standards-based specification for document-oriented information that defines methods to store, locate and retrieve patient information distributed across multiple sources or repositories. The central mechanism used to achieve this is a registry providing a consolidated index to all distributed content. In the context of the National Health IT Plan, the XDS model lends itself to a strategy of regional implementations, while enabling an inter-regional view of patient information at point-of-service. XDS is based on standards ebxml, SOAP, MTOM/XOP, WS-I Basic Profile and HTTP 1.1. Refer to the HIE Overview and Glossary document for definitions. Document Registry National Patient Identity Source (NHI) Document Repositories National Specialty National Gateway O th e r Regional PoC Document Source or Image Source Document Registry R-CDR Orders & Results Continuity of Care PoC Document Consumer Regional Gateway G at e w ay s Example Document Repositories Medicines Imaging & Other Figure 2: XDS Registry-Repository Model Figure 2 shows XDS actors and transactions, centred on multiple repositories and a registry. Two implementations are shown, one at regional level and another at national level. CDRs positioned at national level will be associated with national specialty systems such as for oncology and renal. Document sources and document consumers are point-of-service systems that produce and consume repository content, respectively. A single system will typically act in both roles. Using XDS, stored patient information can include textual documents, coded documents and image files. Typical document consumers are clinical portals and PMS instances. Document sources and image sources include PMS instances, Health Information Exchange Clinical Data Repository Utility Services v1 8

9 laboratory and radiology information systems and Picture Archiving and Communication System (PACS) instances. Gateway components enable inter-regional access to repository content. 2.3 Regional CDRs Figure 3 shows an R-CDR and the XDS actors and transactions involved. Figure 3: XDS-Enabled R-CDR R-CDRs shall be XDS-enabled R-CDRs are required to be XDS-enabled. R-CDRs may comprise multiple component CDRs, each of which is required to implement the XDS repository actor and to register content in a common XDS registry for that region Health Information Exchange Clinical Data Repository Utility Services v1 9

10 2.3.2 Each R-CDRs shall include a single XDS.b registry Every R-CDR is required to include a single system implementing the XDS registry actor. The registry provides a record locator service over all the content of the component CDRs There shall be one XDS affinity domain per R-CDR There shall be one XDS affinity domain per R-CDR. The affinity domain is a key concept of XDS. In general terms, an XDS affinity domain is a group of healthcare enterprises that have agreed to work together common rules and to share a common infrastructure. In New Zealand there will be several affinity domains, each being the user group of one or other R-CDR R-CDRs shall interconnect in accord with IHE XCA R-CDRs are required to interconnect in accord with the IHE Cross Community Access (XCA) integration profile. XCA creates a network of communities by supporting the means to query and retrieve patient information held in other regions or XDS affinity domains. This enables an umbrella view of patient information regardless of its distribution. XCA s pivotal mechanisms are gateways initiating gateways and responding gateways that provide the necessary points of interconnection between R-CDRs R-CDRs shall operate under a common XDS affinity domain policy R-CDRs shall be operated under a common, nationally agreed XDS affinity domain policy. The community of participants in the use of an R-CDR will form a regional XDS affinity domain. This community will be required to adhere to a common, nationally agreed affinity domain policy in configuring and using the R-CDR. This policy will apply equally in all regions individually and at national level. The policy will describe a set of rules and agreements, including formatting, naming conventions, working policies, document attributes and how to store data in R-CDRs. There will be appropriate governance over the content and application of the policy HIE participant systems may have service adapters Participant systems are permitted to use adapters in order to produce and consume services on the HIE. That is, applications are not required to have native support for HIE protocols, but may instead use adapters that do implement those protocols. 2.4 Forms The HIE does not depend on or require the use of the Online Forms standard, nor does it prevent its use the two concepts are essentially independent and complementary. The HISO Online Forms Architecture Technical Specification concerns operations within a single user s session, while the HIE is about information exchange between separate participant systems. 2.5 Transport Services HIE transport shall be based on web services HIE transport is required to be based on web services and use the standard web services protocol stack. Either SOAP over HTTP web services or REST web services are acceptable. Both styles of web services are compatible with XDS Health Information Exchange Clinical Data Repository Utility Services v1 10

11 2.5.2 Use of HL7 v2 for transport is in containment Use of HL7 v2 for transport is in containment. This means HL7 v2.x may only be used when constraints on a particular solution make the use of web services impractical. 2.6 Identity Services See Figure The authoritative source of patient identity information shall be the NHI The authoritative source of patient identity information shall be the National Health Index (NHI). This requires R-CDRs and participant systems to receive patient identity information directly from the NHI and not from a Patient Administration System (PAS) or any other local patient index R-CDRs shall have patient identity and demographics services conforming to IHE PIXV3 and IHE PDQV3 R-CDRs shall offer patient identity and demographics services conforming to the IHE Patient Identity Feed HL7 v3 (PIXV3) and Patient Demographics Query HL7 v3 (PDQV3) integration profiles. PIXV3 enables patient identifier cross-referencing (although NHI numbers make this unnecessary in New Zealand) and patient identity feeds. Patient Identity Feed HL7 V3 [ITI-44] is the required transaction type. PDQV3 lets applications query a central source in order to retrieve patient demographics. In New Zealand this is the NHI. Patient Demographic Query HL7v3 [ITI-47] is the required transaction type Health Information Exchange Clinical Data Repository Utility Services v1 11

12 Figure 4: Patient Identity Transactions The authoritative source of health provider identity information shall be the HPI The authoritative source of health provider identity information shall be the Health Provider Index (HPI). This rule applies in all regions and XDS affinity domains. It requires HIE participants to use provider identity information directly from the HPI (or any replacement to the HPI) rather than from local alternatives Provider identity services should conform to IHE HPD Provider identity services should conform to the IHE Health Provider Directory (HPD) integration profile. HPD specifies interactions between the source and consumers of provider identity and demographic information. 2.7 Security Authentication, access control and audit around document sharing shall conform to IHE ATNA Authentication, access control and audit requirements around document sharing shall be those defined by the IHE Audit Trail and Node Authentication (ATNA) integration profile. XDS depends upon the existence of ATNA actors to provide necessary security controls around its own actors Health Information Exchange Clinical Data Repository Utility Services v1 12

13 ATNA incorporates Transport Layer Security (TLS), WS-I Basic Security Profile and Advanced Encryption Standard (AES) Digital signatures shall conform to IHE Document Digital Signature (DSG) Digital signatures (where used) shall accord to the IHE Document Digital Signature (DSG) integration profile. W3C XML Signature is the underlying standard. 2.8 Document and Image Management Figure 5 shows document and image management transactions around an XDS-enabled R-CDR. XDS requires that documents and document sets have metadata in the form of a defined set of document attributes. These document attributes are populated by the document source system and repository upon submission. National Patient Identity Source (NHI) PDQ Patient Demographic Query [ITI-47] PoC Document Source or Image Source Document Registry Orders & Results Example Document Repositories Medicines R-CDR Continuity of Care Imaging & Other Query Registry [ITI-16] and Registry Stored Query [ITI-18] Retrieve Document Set [ITI-43] WADO Retrieve [RAD-55] PoC Document Consumer PoC Image Consumer Figure 5: Document and Image Retrieval Medical image management shall conform to IHE XDS-I Medical images shall be managed in accord with the IHE Cross-Enterprise Document Sharing for Imaging (XDS-I) integration profile. XDS-I enables DICOM Key Object Selection (KOS) image manifest files to be stored and registered in XDS repositories as pointers to DICOM images stored in PACS instances Health Information Exchange Clinical Data Repository Utility Services v1 13

14 XDS-I also supports medical images in non-dicom formats, such images can be PDF-embedded or hyperlinked. XDS-I also supports DICOM Structured Reports. Medical images can be retrieved over HTTP using the DICOM Web Access to DICOM Objects (WADO) protocol. 2.9 Network Requirements Telecommunications networks shall adhere to IHE Consistent Time (CT) The telecommunications network upon which an HIE runs is required to implement the IHE Consistent Time (CT) integration profile for time synchronisation. This requires the network to have Network Time Protocol (NTP) services Terminology Services Terminology services shall conform to HL7/OMG CTS2 Where provided, terminology services are required to conform to the HL7/OMG Common Terminology Services (CTS2) specification. However, it is not mandatory that HIEs have terminology services Health Information Exchange Clinical Data Repository Utility Services v1 14