ALBERTA ADVERSE EVENT FOLLOWING IMMUNIZATION(AEFI) HL7 MESSAGING SPECIFICATION

Transcription

1 Health Information Messaging Specification HEALTH INFORMATION STANDARDS COMMITTEE FOR ALBERTA ALBERTA ADVERSE EVENT FOLLOWING IMMUNIZATION(AEFI) HL7 MESSAGING SPECIFICATION MESSAGE STANDARD SUMMARY Status: Accepted in Draft Version: v1.5 Status Date: June 5, 2018

2 Revision History Version Revision Date Summary of Changes 1.0 AUG 17, MAY 31, MAY 24,2018 Baseline outlined based on Alberta Immunization HL7 Messaging Specification. Developed all sections up to and including section 4.3. Made other smaller edits to further sections. Updates to various sections. Updates regarding final discussion and approval of States. Version alignment, final review and publication Iterate based on internal team review comments, internal QA Finalization and draft publication Final publication with updates from reviewer comments. Updated Appendix B Object Identifiers section. Maintenance project updates Released on 9/8/2017 Align conformance strength with v3 models and simplify conformance concepts. OID updates. Add support for the ImmARI Severe Flag Version alignment with changes in technical artifacts. HISCA status: Accepted in Draft on June 5, 2018 Contact Information Documents may be requested from HISCA@gov.ab.ca 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. Announcement: HL7 V2 message contents are not included in this summary 2018 Government of Alberta Page 1 of 11

3 Table of Contents 1 Background Objectives Scope Business Context Standards Alignment HL7 Version and Infrastructure Selection HL7 v3 Baseline Version Interoperability between HL7 V3 and HL7 V Object Identifiers Coding vs. Identifier Based Elements Data Type Variations for Infrastructure Elements HL7 v3 Alberta to pan-canadian Alignment Issues Misalignment of Attribute Conformance Missing Concepts for Certain Coded Attributes Other Design Decisions Updates Stakeholder Engagement Implementing Systems Conceptual Data Model Specification Documents Specification Structure Specification Documents List Government of Alberta Page 2 of 11

4 1 Background The Adverse Reaction to Immunization (ARI) Data Set, now referred to as Adverse Events Following Immunization (AEFI) Data Set was approved as a provincial data standard by the Health Information Standards Committee for Alberta (HISCA) in June of Currently both public health and non-public health stakeholders within the provinces report AEFI events in varying degrees of compliance using a provincially standard form (currently undergoing review) that is sent to Alberta Health before being reported to the Public Health Agency of Canada (PHAC). The Alberta AEFI HL7 Messaging Specification (AB AEFI HL7) project focuses on the development of provincial AEFI HL7 message specifications, including the appropriate terminology, mapping, and appropriate documentation to support the electronic reporting and exchange of AEFI data within Alberta. The Alberta AEFI HL7 Messaging Specification also utilizes the Alberta Immunization HL7 Messaging Specification. The immunization events are then linked to the appropriate AEFI event, therefore avoiding any need to duplicate immunization event data within the AEFI message. It should be noted that although this specification concerns itself with the submission of AEFI events to an AEFI / IMMS Repository, this would ideally be the same repository where the immunization events are stored. For this reason the repository will often be referred to as the AEFI / IMMS Repository. Community Pharmacy and Physician Office systems will utilize the HL7 v3 interface to communicate with Alberta Health AEFI Repositor(ies) while Alberta Health Services (AHS) will likely utilize the v2.x interface. However, the HL7 V2 portion has not been maintained since 2014, and is no longer synchronized with HL7 V3 portion. Only the HL7 V3 portion is released in AEFI Messaging Specification V Objectives The primary objective of AEFI project is to develop provincial Adverse Events Following Immunization (AEFI) HL7 Message Specifications to enable a patient's adverse event and immunization data to be stored in the health record available to clinicians within Netcare. 3 Scope The target scope of these messaging specifications include messaging to support the following business events: Querying a central AEFI / IMMS Repository for a patient s AEFI and/or temporally relevant immunization history; Communicating the creation of an AEFI Event within a POS system; Communicating the update of an AEFI Event within a POS system; Communicating the deletion of an AEFI Event within a POS system; Effecting the de-duplication of reported AEFI events; The scope of these specifications explicitly excludes: The management and reporting of AEFI events to PHAC Government of Alberta Page 3 of 11

5 4 Business Context 2018 Government of Alberta Page 4 of 11

6 5 Standards Alignment This section highlights key design decisions that were made during the development of these specifications. 5.1 HL7 Version and Infrastructure Selection HL7 v3 Baseline Version The HL7 v3 specification is based on the HL7 Universal Standard for the Individual Case Safety Report (ICSR) currently under ballot at HL7 International; but models for this specification were customized to reflect the exact conformance requirements as specified in these documents. In addition, wrappers, Common Message Element Types (CMETs), Data Types, and design patterns from the pan-canadian Maintenance Release 2009 (MR2009), aka R , were adopted with the exception of two CMETs; which were adapted and one Common Message (COMT). The adapted ICSR models as well as the models adapted from the pan-canadian Specifications (one COMT and two CMETs) are specifically named with an AB extension to indicate their specific definition relative to the AB AEFI HL7 Specifications. 5.2 Interoperability between HL7 V3 and HL7 V2 A number of HL7 v2.3 to HL7 v3 bi-directional interoperability issues needed to be resolved. These are outlined below together with the selected approach Object Identifiers Issue Approach HL7 v2.3 uses namespaces to provide uniqueness to identifier fields while HL7 v3 uses a more resilient global unique identifier scheme through prescribed Object Identifiers (OIDs). Since both approaches are assumed to require the insertion of constants (i.e. designated namespace identifier or an OID) by participating systems or an adjacent integration layer, this specification uses OIDs for both HL7 v2.3 and HL7 v3 interfaces. This eliminates the maintenance and management of a cross-reference map but does place the burden on systems using the HL7 v2.3 specification to manage the larger OID field Coding vs. Identifier Based Elements Issue Approach HL7 v2.3 uses coded data for certain attributes / data elements which have more recently - including within the HL7 v3 specification - been modeled as identifiers. An applicable mapping has been documented for the affected data elements Data Type Variations for Infrastructure Elements There are certain infrastructure focused data elements in the respective HL7 v2.3 and v3 specifications that address equivalent technical objectives but for which the applicable HL7 standard prescribes different, non-compatible data types. An example of this is MSH-10 Message Control ID (from the v Government of Alberta Page 5 of 11

7 spec) and MCCI_MT002100CA.Message.id (from the v3 spec). These data elements use distinct data types (String, in v2.3, and II.TOKEN, in v3, respectively) which do not support round tripping. Implementers are advised that the associated data is only relevant to support the technical flow of interactions between a Point of Service (POS) system and an AEFI / IMMS Repository and is not part of the business data interchange (i.e. it does not appear on any queries nor other transactional flows that cross interface types). Therefore this data is neither required nor intended to be round tripped between v2.3 and v3 interfaced Point of Service systems. Although the apparent format/structure divergence between these elements is benign, a consequence for an AEFI / IMMS Repository that claims to be conformant to both interfaces is that this registry will need to accommodate both structures in its data base and apply the correct structure in the interactions with Point of Service systems according to the applicable HL7 interface used. The table below summarizes these requirements for the two key infrastructure elements: Table 1: v2.3 / v3 Infrastructure Element Data Type Variations Fields: Message Identifier Query Identifier v2.3 Segment Data Type MSH-10 Message Control Id String - 20 characters QAK-1 Query Tag QRD-4 Query ID String - 32 characters String - 10 characters v3 Attribute Data Type MCCI_MT002100CA.Message.id MCCI_MT002300CA.Message.id MCCI_MT002300CA.TargetMessage.id II.TOKEN - 36 character UUID (unique universal identifier) [32significant characters and 4 spacers] QUQI_MT020000CA.QueryByParameter.queryId QUQI_MT120006CA.QueryByParameter.queryId QUQI_MT120006CA.QueryAck.queryId II.TOKEN - 36 character UUID (unique universal identifier) [32significant characters and 4 spacers] 5.3 HL7 v3 Alberta to pan-canadian Alignment Issues Misalignment of Attribute Conformance Issue Some conformance expectations of the pan-canadian specifications did not meet the Alberta business requirements. Approach Where needed, custom CMETs were created or models adjusted to meet Alberta requirements Missing Concepts for Certain Coded Attributes Issue A number of terminology concepts were not available in the HL7 v3 Standard. Approach Where appropriate, concepts were adopted from the pan-canadian standards; other concepts were identified as potential additions to the HL7 v3 standard. For further details please consult the AB AEFI HL7 Spec- DSG-v2x-v3 Mapping Summary workbook Government of Alberta Page 6 of 11

8 5.4 Other Design Decisions Updates Issue In distributed computing there are two primary modes for the communication of updates to a particular record or object. Either a system can send a current image of the information, also known as snapshot mode, or the system can send changes to individual elements (e.g. attributes) of the record or object. Approach These specifications utilize snapshot mode, that is to say the current full copy of the record is sent with each modifying transaction (whether a delete, update or merge). This is typically easier to implement for the point of service systems (i.e. the senders of events and event updates) and also aligns with the pan-canadian standards, since these utilize snapshot mode exclusively. 6 Stakeholder Engagement These specifications were developed in collaboration with the Adverse Event Following Immunization (AEFI) HL7 Working Group (AB AEFI HL7 WG): Organization Alberta Health Services (AHS) Accountability AHS Public Health AHS ICC Chair HL7 Standards and Conformance Standards Alberta Health (AH) Physician Office System Program (POSP) Contracted team from Gordon Point Informatics Ltd. and Global Village Consulting Ltd Health Information Standards Architecture Standards Immunization Standards Immunization Program EHR Physician and EMR Community I. Project Manager II. Senior Business Analyst III. Systems Analyst / HL7 Analyst IV. Public Health SME V. Public Health pan-canadian HL7 v3 SME 7 Implementing Systems No information on current production status is available Government of Alberta Page 7 of 11

9 8 Conceptual Data Model Stakeholder In A Role Stakeholder Group Recipient Organization is a Provider Delivery Organization of Service performs Stakeholder Role Person Manufacturer can be contacted using Communication Access participates in Address located at Event Stakeholder Event Service Event Resource Supply Antigen Location takes place at Adverse Reaction to Immunization Event utilizes contains contains Vaccine Boundary relates to takes place at Delivery Site Legend Entity Defines a collection of stored data Zero or More One Only One or More Zero or One This data model is based on AHEAD main detailed view from December 22, 1999 Conceptual Data Model from data standard v Government of Alberta Page 8 of 11

10 9 Specification Documents 9.1 Specification Structure These specifications have been layered into multiple documents and technical artifacts which, together, provide implementation direction and establish conformance requirements. Figure 1: Specification Structure These documents have been structured to minimize duplication and to streamline access to information for prospective implementers. Moreover, recognizing that certain implementers (in this case an implementer of an AEFI / IMMS Repository) will likely need to support both V2 and v3 based interoperability, these specification documents aim to offer an integrated view for both specifications. Readers are advised to start their review with the Business Overview document (as well as the companion Business Use Cases document) and then to consider the desired specification set, i.e. the V2 or v3 Specification respectively. Each of these specification sets has been stratified and it is recommended that readers approach these layers in order as follows: I. Implementation Guide: Each 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. II. 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. Where applicable a formal conformance profile (e.g. HL7 Message Profile) is referenced Government of Alberta Page 9 of 11

11 III. Technical Artifacts. Each specification includes appropriate technical artifacts. For V2 this consists of the applicable HL7 Message Workbench files while for v3 this consists of the normative Model Interchange Format (MIF) files as well as non-normative extensible Markup Language (XML) Schema files (.XSD) files. For further information please consult Appendix A of the Business Overview document. Finally, these specifications are published with a set of common artefacts including a normative Vocabulary Workbook. This is intended to consolidate valid vocabulary in a convenient, machine processable manner Government of Alberta Page 10 of 11

12 9.2 Specification Documents List This section summarizes the various files that are part of the specification. Group Title File Name Comments Interoperability Standard Messaging Specification & Clinical Documents Deliverables Business Overview AB AEFI HL7 Spec - Business Overview v1.5 Business Use Case AB AEFI HL7 Spec - Business Use Cases v1.5 Business Processes AB AEFI HL7 Spec - Business Process v1.5 HL7 v3 Implementation Guide AB AEFI HL7 Spec - v3 Implementation Guide v1.5 HL7 v3 Conformance Profile AB AEFI HL7 Spec - v3 Conformance Profile v1.5 HL7 v3 Technical Artifacts AB AEFI HL7v3 Specification - v3 Technical Artifacts v1.5 Vocabulary Workbook AB AEFI HL7 Spec - Vocabulary v1.5 The HL7 V2 content review is deferred and to be determined The HL7 V2 content review is deferred and to be determined The HL7 V2 content review is deferred and to be determined The HL7 V2 content review is deferred and to be determined The HL7 V2 content review is deferred and to be determined Contains various formats (MWB, XML and HTM) of Message Workbench output files. DSG to Message Spec Mapping Sheet AB AEFI HL7 Spec - DSG-v2-v3 Mapping Summary v1.4 Note that the extra version code (x2.11) is to correspond with a prior versioning scheme. This has been dropped with publications v1.1. Replace "Minimum Data Set" with "Data Submission and Response Guidelines" Rename workbook to reflect DSG mapping Supplemental Files HL7 v3.0 Sample Message Instances AB AEFI HL7 v3 Spec - v3 - Example Instances v1.5 Documents may be requested from HISCA@gov.ab.ca by sending the title and filename requested. Large files or requests may be sent as multiple archive files to the requestor Government of Alberta Page 11 of 11