SHARED HEALTH RECORD(SHR)

Transcription

1 Health Information Data and Messaging Specification HEALTH INFORMATION STANDARDS COMMITTEE FOR ALBERTA SHARED HEALTH RECORD(SHR) MESSAGE AND DATA STANDARD SUMMARY Status: Accepted in Draft Version: 1.10 Status Date: Nov 23, 2012

2 Revision History Version Revision Date Summary of Changes Jun-14 Accepted in Draft Nov-23 Amendment, Accepted in Draft Contact Information Documents may be requested from by sending the title and filename requested as listed in the Specification Documents section. Large files or requests may be sent as multiple archive files to the requestor Government of Alberta 2 of 12

3 Table of Contents I. Background... 4 II. Objectives... 4 III. Scope... 4 A. Functional Scope... 5 B. Technical Scope... 5 C. External Dependency... 5 D. Constraints... 5 E. Out-of-Scope items... 5 IV. Business Context... 6 A. Transcribed Reports Exchange... 6 B. Encounter Exchange... 7 V. Standards Alignment... 8 A. HL7 v3 Alberta to pan-canadian Alignment Issues... 8 VI. Stakeholder Engagement... 9 VII. Implementing Systems... 9 VIII. Conceptual Data Model... 9 IX. Specification Documents A. Specification Structure B. Specification Documents List Government of Alberta 3 of 12

4 I. Background SHR is a concept that was developed by Canada Health Infoway as a mechanism for sharing personspecific clinically-relevant data not held in other Electronic Health Record (EHR) domain repositories (e.g. DI, Lab, and Drug). SHR is intended to include a copy of subsets of clinical information captured in point of service (POS) applications and should focus only on clinically relevant data appropriate for sharing such as basic encounter information, referrals, encounter summaries, clinical observations, problems/conditions/diagnosis, care plans, care protocols, and health status indicators. The success of the Alberta Netcare EHR has been enabling access to demographic information, drug information, lab test result data, diagnostic imaging and other report information to physicians, pharmacists, hospitals, home care, and other health care professionals across the province. The primary mandate of the SHR initiative is to share relevant clinical information in addition to the information domains presently available within the Alberta Netcare EHR. The capture of information in physician office settings is a critical element of a patient s longitudinal health record as it is well acknowledged that 70 to 80% of health services are delivered in community settings outside the traditional focus of the AHS health programs. The SHR Release 1 will enable bi-direction system-to-system (S2S) integration between physician office electronic medical records (EMRs) and the Alberta Netcare EHR starting with encounters and transcribed clinical reports. Future SHR releases are expected to include immunizations, alerts, screening, care compositions, EMR to EMR referrals, support for chronic disease management and the Alberta personal health portal. II. Objectives The goal of SHR is to support continuity of care and clinical decision making by further developing the completeness of the information within the provincial Netcare EHR and enabling access to that information through point of service (POS) systems. The key business objectives of the SHR Release 1 project are: To enable clinicians using physician office EMRs to download (on-demand) encounters and transcribed clinical documents currently available within the EHR repositories. To automatically propagate report updates to providers who had downloaded and replicated copies of reports in their EMR (or paper chart) or requested receiving updates. To establish a foundation for further sharing of clinical information between physician office EMRS with the EHR. To establish the architecture inclusive of Qualified Service Provider (QSP) EMRs; provincial Health Information Exchange (phie); and Netcare for delivery of future SHR Releases. Implement with a Limited Production Rollout (LPR) of clinics using the three QSP EMRs (Wolf, MedAccess, and Practice Solutions) prior to handoff for continued rollout and maintenance. Complete the plan for Release 2 and on-going development of SHR integration. III. Scope The scope of the project includes implementation with a limited production rollout (LPR) of clinics that use the three Alberta Qualified Services Provider (QSP) vendors. The SHR interface specifications have been proposed as an Alberta HISCA standard and are available for implementation with non-qsp EMR vendors or other applications (e.g. Personal Health Portal). The components to be developed and implemented include extensions to Provincial Health Information Exchange (phie) services and development of a new Netcare Applications Services (NAS) layer that will enable integration with the Netcare repositories. Two types of scope and out-of-scope items have been identified Government of Alberta 4 of 12

5 A. Functional Scope Integration to enable searching for, viewing, and downloading copies of clinical reports on-demand from the EHR (sourced from AHS and private data sources) to physician EMRs via system-to-system messaging (e.g. discharge summaries, consult reports, DI Text reports). The reports are stored in four repositories managed by AHS. Integration to enable searching for and viewing encounters from the Encounter/Event repository managed by AHS and containing ADT encounters from AHS facilities throughout Alberta. Functionality to automatically propagate report updates to providers who had downloaded and replicated copies of reports in their EMR (or paper chart) or requested receiving updates. The propagation of updates is to eliminate potential impact to patient safety of using incorrect or out-ofdate information for clinical decision making. This functionality includes extensions to the edelivery service currently offered by AHS. Functionality to enforce EHR global person-level masks (GPLM) when accessing records via systemto-system messaging. This includes: 1) a warning message returned when a user requests data that is masked; and 2) the ability to unmask (aka break the glass ) and access the record via messaging. B. Technical Scope Introduction of the Netcare Application Services (NAS) infrastructure to allow message-based access to Netcare repositories. These services will be published and used by phie. Updates to the phie infrastructure including: AHS client validation, audit logging, web services interfaces, EMR security/authentication, and edelivery updates. EMR software updates to fulfill the SHR requirements as outlined in the SHR Business Requirements and SHR HL7 Specification. These updates are specified in the Business Requirements Document (BRD), the HL7 Messaging Specifications and corresponding Implementation Guides. This development is funded and managed by Alberta Health under their Master Standing Agreements with the 3 QSP vendors. C. External Dependency SHR Release 1 is dependent on: EMR Security Authentication (phie) Provincial Client Registry Integration (PCR) integration for client/patient identity management POSP and the QSP EMR vendors D. Constraints All integration with EMR systems will be via system to-system messaging using HL7 v3 o Based on the pan-canadian Infoway standards The EMR upgrades will be completed using the QSP Change Order Process under the Master Standing Agreements The project timelines must align with POSP and Netcare Change windows E. Out-of-Scope items The SHR Release 1 project placed the following items out-of-scope: Implementation with AHS s EMRs (EPIC and SCM) and legacy (non-qsp) EMRs are out of scope. The ability to create or rescind a GPLM from the EMRs has been referred to the Provincial Client Registry Project for consideration and is out of scope for SHR. Ability to download data from the EHR other than encounters and transcribed documents. In some cases, laboratory results are stored in the report repositories. These are out of scope. Encounter uploads to the EHR from physician office EMRs or any other systems. Support for grouping of encounters into Episodes of Care and/or Care Compositions Government of Alberta 5 of 12

6 Upgrading the existing edelivery solution to Cloverleaf Secure Courier (CSC) is out of scope and not a dependency for this project to propagate the report updates. Note: This integration does not replace edelivery of reports delivered to physicians who are named on the report. IV. Business Context A. Transcribed Reports Exchange The primary goal of this SHR Release 1 is to establish a foundation for sharing clinical information between physician office EMRs and the Alberta Netcare EHR. The purpose of this integration is to support clinical decision-making but also provide efficiencies in the community clinics by avoiding the need for printing and scanning to move the information from the EHR into the local EMR. SHR Release 1 will enable sharing information currently held in the EHR with Point of Service (POS) systems to enable community providers to view and download on-demand transcribed clinical documents (e.g. discharge summaries, consult reports) and to view encounters currently present within the Netcare EHR repositories directly from their POS also via system-to-system messaging via the phie. The primary reports-related functions the SHR secured system-to-system integration will provide are the: Ability for POS users to view and download on-demand transcribed clinical reports from the Netcare EHR (e.g. discharge summaries, consult reports); Ability for POS users to be notified if a client has a Global Person Level Mask (GPLM) on their EHR; and Ability for POS users to be able to unmask (aka break the glass) and view the client s data from the EHR as required. While the use cases described below in the following sections illustrate the full exchange life cycle from the placing of the a transcribed clinical report into the Reports Repository to retrieval of transcribed clinical reports (including report metadata) by a Report Consumer the use cases relating to the creation, update and removal of transcribed reports are not in scope for SHR Release 1. The use cases have been collated to produce an overarching business model (diagrammed below). Preconditions for the SHR Integration include: 1) Patient/client is registered in the Provincial and AHS Client Registries and has a valid Unique Lifetime Identifier (ULI) that can be used to resolve the identity of the client. 2) The POS has been authenticated with the AHS network security and is able to access the Netcare EHR via the Provincial Health Information Exchange (phie) 3) The POS security has authenticated the POS users and applied role-based permissions to access these functions Government of Alberta 6 of 12

7 uc SHR Reports Use Cases Not in SHR Release 1 scope Put Report Into Repository Search for Reports and Return Summary List Reports Distributor «precedes» «precedes» Subscribe to Updates Distribute Report Updates Replace Existing Report in Repository Retrieve Identified Report Report Creator Reports Repository Remov e Report from Repository Report Consumer Figure 1 Shared Health Record Transcribed Reports Exchange Business Model B. Encounter Exchange The primary goal of the SHR Release 1 Project was to establish a foundation for sharing clinical information between physician office EMRs and the Alberta Netcare EHR. The purpose of this integration is to support clinical decision-making by extending the information available in the Netcare EHR with information from physician office EMRs. In addition, the EMRs would be able to integrate with the EHR directly via system-to-system messaging to access data currently available only via the Netcare Portal. The encounter-related functions this integration will provide are the: Ability to collect basic encounter information, captured in POS applications (e.g. EMRs), in the encounter/event repository within the Alberta Netcare EHR 1 ; Ability for POS users to view encounter/events held in the Netcare repository directly from their POS; Ability for POS users to be notified if a client has a Global Person Level Mask (GPLM) on their EHR; and Ability for POS users to be able to unmask (aka break the glass) and view the client s data from the EHR as required. The use cases described in this document we established with the focus integrating with physician office EMRs. The following sections illustrate the full encounter exchange life cycle from the placing of the encounter into the Encounter Repository to retrieval of encounter information by an Encounter Querying System. The use cases have been collated to produce an overarching business model (diagrammed below). Preconditions for the Encounter Integration include: 4) Patient/client is registered in the Provincial and AHS Client Registries and has a valid Unique Lifetime Identifier (ULI) that can be used to resolve the identity of the client. 5) The Physician, or other licensed provider, is registered in the Provincial Provider Registry (PPR). 6) The Clinic is registered in the provincial Delivery Site Registry (DSR). 7) The POS has been authenticated with the AHS network security and is able to access the Netcare EHR via the Provincial Health Information Exchange (phie) 1 The ability to create, update and remove encounter information is not expected to be part of SHR Release 1 scope 2012 Government of Alberta 7 of 12

8 8) The POS security has authenticated the POS users and applied role-based permissions to access these functions. uc SHR Encounter Use Cases Put Encounter into Repository Search for Encounters and Return Summary List «precedes» «precedes» «precedes» Update Encounter in Repository Retrieve Identified Encounter Details Encounter Entry System Encounter Repository Encounter Querying System Remov e Encounter from Repository Figure 2 Shared Health Record Encounter Exchange Business Model V. Standards Alignment The HL7 v3 specification is based on infrastructure contained in the pan-canadian HL7 v3 messaging specifications (PCS) version R aka MR2009; but the HL7 v3 interactions described in the documents are net-new extensions to the PCS. A. HL7 v3 Alberta to pan-canadian Alignment Issues Misalignment of Attribute Conformance Some conformance expectations of the pan-canadian specifications did not meet the Issue Alberta business requirements. Approach Where needed, custom CMETs and models were created or adjusted to meet Alberta requirements. These are denoted with an AB suffix (e.g. COCT_MT050205AB is the Alberta version of COCT_MT050205CA). Missing Concepts for Certain Coded Attributes Issue Approach A number of terminology concepts were not available in the HL7 v3 Standard. Where appropriate, concepts were adopted from the pan-canadian standards; other concepts were identified as potential additions to the HL7 v3 standard Government of Alberta 8 of 12

9 VI. Stakeholder Engagement The Shared Health Record release 1 project would like to acknowledge the following organizations who were engaged during the development of this document and contributed to the content and/or provided feedback Alberta Health Services (AHS) Alberta Health and Wellness (AHW) College of Physicians & Surgeons of Alberta University of Calgary Department of Family Medicine VII. Implementing Systems The SHR Data and Messaging Standards have not been deployed yet. VIII. Conceptual Data Model Not available 2012 Government of Alberta 9 of 12

10 IX. Specification Documents A. Specification Structure These specifications have been layered into multiple documents and technical artifacts which, together, provide implementation direction and establish conformance requirements Figure 3 Specification Structure 2012 Government of Alberta 10 of of 12

11 Readers are advised to start their review with the SHR Release 1 Business Requirements Document and then to consider the rest of the specification set. The specification set has been stratified and it is recommended that readers approach these layers in order as follows: Implementation Guide: The guide is intended to provide clear direction to implementers about the in-scope interoperability transactions and provides both guidance and normative direction about how to implement the specifications. Conformance Profile: Each Conformance Profile document outlines the in-scope transactions which conformant systems are expected to support as well as specific business rules and data obligations for each transaction. Transcribed Reports CDA Implementation Guide: The guide will describe the constraints to the HL7 Clinical Document Architecture Release 2 (CDA R2) standard for communicating transcribed reports in Alberta. Technical Artifacts. Each specification includes appropriate technical artifacts. This consists of the normative Model Interchange Format (MIF) files as well as non-normative extensible Markup Language (XML) Schema files (XSD) files. Terminology Specification: The specification is intended to consolidate terminology used in the Alberta SHR HL7 v3 Messaging Specifications. B. Specification Documents List This section summarizes the various files that are part of the specification. Title Filename Description HL7 v3 Implementation Guide AB Encounter HL7 Spec v3 Implementation Guide - v doc AB Transcribed Reports HL7 Spec v3 Implementation Guide - v doc CDA Implementation Guide AB Transcribed Reports CDA Implementation Guide - v doc HL7 v3 Conformance Profile AB Encounter HL7 Spec v3 Conformance Profile - v doc AB Transcribed Reports HL7 Spec v3 Conformance Profile - v AB SHR HL7 Terminology Specification AB SHR HL7 Terminology Specification - v doc The Implementation Guide provides an overview, context and scope of the Specification. The Implementation Guide also documents key design considerations that have been used to guide the form and structure of the Clinical Document Specification. This guide presents the constraints to the normative CDA R2 standard in narrative form. The Conformance Profile document outlines the inscope transactions which conformant systems are expected to support as well as specific business rules and data obligations for each transaction. The Terminology Specification presents the terminology to be used for systems that conform to the Alberta Shared Health Record HL7 v Government of Alberta 11 of of 12

12 Title Filename Description Specification. MIF2 view of message models AB SHR MIF2 - v zip MIF (Message Interchange Format) View: Describes the model in HL7 v3 internal form. Schema view of message models AB SHR XSD - v zip Provides a schema perspective on the model after generation through HL7 v3 tooling. Excel view of message models AB SHR XLS - v zip Provides a tabular view of the message model accessible through Excel. Visio view of message models AB SHR VISIO - v zip The base HL7 v3 message payload models in Visio form. Message Instance Examples AB SHR Message Instance Examples - v zip Sample messages for each transaction set intended to illustrate message structure. Data Dictionary AB SHR Data Dictionary v xls Business level descriptions for data elements included in the specification. Background Business Documentation AB SHR Business Documentation.zip Provides background business context for the specification. SHR Release 1 Business Requirements Document included Pan-Canadian Data Type Specification SC-3002-EN - Data Type Specification - R zip Pan-Canadian Master Terminology Worksheet SC-3004-EN - Terminology Worksheet - R zip These files are listed solely for convenience. Copies should be obtained from Canada Infoway Documents may be requested from HISCA@gov.ab.ca by sending the title and filename requested as listed above. Large files or requests may be sent as multiple archive files to the requestor Government of Alberta 12 of of 12