IPS implementationguide 1

Document Information

This document contains: Implementation Guide International Patient Summary (0.10). The text materials belong to category cdaips.

{{{Topright}}}

HL7 International Patient Summary
based on Clinical Document Architecture Release 2

International Patient Summary

Implementation Guide

© 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.
The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

Important Notes

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.

If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material.

A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.

INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.

B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement.

C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Materials. Licensee shall take no action contrary to, or inconsistent with, the foregoing.

Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”). Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability.

Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology	Owner/Contact
Current Procedures Terminology (CPT) code set	American Medical Association https://www.ama-assn.org/practice-management/cpt-licensing
SNOMED CT©	SNOMED CT® International http://www.snomed.org/snomed-ct/get-snomed-ct or info@ihtsdo.org
Logical Observation Identifiers Names & Codes (LOINC©)	Regenstrief Institute, Inc.
International Classification of Diseases (ICD) codes	World Health Organization (WHO)
NUCC Health Care Provider Taxonomy code set	American Medical Association. Please see www.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services)

Obtaining a CPT Sublicense from HL7

Contact hq@hl7.org about how to obtain a sublicense from HL7 for non-production use of CPT for (i) the development and publication of value sets, profiles, and other artifacts as part of the HL7 Implementation Guides, (ii) as part of defined VSAC value sets, and (iii) to support HL7's terminology services within the Territory.

Flow Down Clauses for CPT Sublicense from HL7

CPT content is copyrighted by the American Medical Association and CPT is a registered trademark of the AMA.

HL7, as a party to a license agreement with the AMA, is authorized to grant user a limited, non-exclusive, non-transferable, non-sublicensable license for user to use CPT content for (i) the development and publication of value sets, profiles, and other artifacts as part of the HL7 Implementation Guides, (ii) as part of defined VSAC value sets, and (iii) to support HL7's terminology services within the Territory, each of which shall be considered a non-production use. The sublicense granted hereunder shall automatically terminate upon termination of the agreement between HL7 and AMA, unless prior written consent of AMA is obtained.

The provision of updated CPT content is dependent on a continuing contractual relationship between HL7 and the AMA.

User acknowledge a separate license agreement shall be required, and shall govern any proposed use, including any distribution of CPT content for any other purposes not expressly permitted under this Agreement, and the terms of such agreement will govern such use (e.g., a separate license agreement shall govern production use and commercial purposes). AMA reserves the right to accept or reject licenses based on AMA's evaluation of the proposed use of the CPT content.

User acknowledge that User's development and commercialization of CPT-informed works developed with reference to Licensed Products may only be implemented in the Territory.

User is prohibited from making CPT content publicly available, creating derivative works (including translating), transferring, selling, leasing, licensing, or otherwise making available to any unauthorized party the CPT content, or a copy or portion of CPT content to any unauthorized party, including a subsidiary, affiliate, or other legal entity, however designated, for any purpose whatsoever except as expressly permitted under a separate agreement.

User expressly acknowledges and agrees to the extent permitted by applicable law, use of CPT content is at User's sole risk and CPT content is provided "as is" without warranty of any kind. The AMA does not directly or indirectly practice medicine or dispense medical services. Fee schedules, relative value units, conversion factors and/or related components are not assigned by the AMA, are not part of CPT, and the AMA is not recommending their use. CPT content herein does not replace the AMA's Current Procedural Terminology book or other appropriate coding authority. The coding information contained in CPT content should be used only as a guide.

U.S. Government End Users. CPT is commercial technical data, which was developed exclusively at private expense by the American Medical Association (AMA), 330 North Wabash Avenue, Chicago, Illinois 60611. This agreement does not grant the Federal Government a direct license to use CPT based on FAR 52.227- 14 (Data Rights - General) and DFARS 252.227-7015 (Technical Data - Commercial Items).

User expressly consents to the release of its name to the AMA.

Authors and Contributors

Introduction

Responsible: Philip Scott

In Review

The international patient summary is a minimal and non-exhaustive patient summary, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient.

Purpose

The goal of this Implementation Guide is to identify the required clinical data, vocabulary and value sets for an international patient summary. The primary use case is to provide support for cross-border emergency and unplanned care.

The international patient summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR STU3 represents equivalent concepts and in some cases has followed a FHIR style of representation rather than a conventional CDA style. The variations from CDA R2 are explained in the relevant detail sections. The mechanism for negation, unknown data and known absent data does not follow the CDA conventions and is explained here.

This specification aims to support:

• Cross-jurisdictional patient summaries (through adaptation/extension for multi-language and realm scenarios, including translation).
• Emergency and unplanned care in any country, regardless of language.
• Where possible, value sets based on international vocabularies that are usable and understandable in any country.
• Data and metadata for document-level provenance.

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is explained in a later section) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

Background

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC, Trillium Bridge, eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents. In particular, the white paper on Comparative Analysis Between HL7 C-CDA R1.1 CCD and epSoS PS v1.4 informed the development of this specification.

In 2010 a MoU was signed between the European Union (EU) and the United States (US) to strengthen global cooperation in eHealth/Health. As a result, the ONC S&I Interoperability of EHR work group was launched in the US in 2013 (http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative) and the Trillium Bridge Project (www.trilliumbridge.eu) was initiated in the EU. The aim was to compare the CDA templates then specified in the EU (epSOS PS V1.4) and in the US (MU – C-CDA CCD v1.1) for patient summaries and to build a transatlantic exchange proof of concept. These initiatives identified the need for common templates and vocabularies for the patient summary. The following recommendation was endorsed by the Joint Initiative Council and by the HL7 International Council: “to advance an International Patient Summary (IPS) standard and enable people to access and share their health information for emergency or unplanned care anywhere and as needed. At minimum the IPS should include immunizations, allergies, medications, clinical problems, past operations and implants.” The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot.

The EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders services was launched in 2016. ART-DECOR® and the HL7 STU template exchange format are increasingly used by European countries, including for the European patient summary (epSOS) templates, so has been adopted as the specification platform for this Implementation Guide.

Scope

to be written

Responsible: Kai Heitmann

...a minimal and non-exhaustive patient summary, which is specialty-agnostic and condition-independent, but still clinically relevant. ...global use

Ballot Status of the Document

This Implementation Guide is STU with the intention to go normative.

Audience

The audience for this Implementation Guide includes:

Public

• Citizens who want to carry or access their healthcare data for emergency care purposes.

Regulatory

• Policy makers such as healthcare payers or government agencies.
• Healthcare information governance authorities and regulatory bodies.

Clinical

• Healthcare providers that offer unscheduled and emergency care.
• Healthcare providers that populate regional and national patient summaries.

Technical

• Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
• System integrators.
• Organizations that manage regional and national patient summaries.

Relationships with other projects and guidelines

• CEN/TC 251 Project International Patient Summary
• epSOS/EXPAND/eHDSI
• Consolidated CDA (C-CDA)
• IHE-PCC
• Input from the EHR work group about how to define the source(s) of the IPS content, described in the provenance section .

How to read this document

• Kai to write a paragraph
• Balloter instructions

Responsible: Kai Heitmann

Principles and background

Responsible: Kai Heitmann, Giorgio Cangioli

IPS Principles

HL7 International and CEN/TC 251 have agreed the following vision and scope for the international patient summary:

Vision: a single, common International Patient Summary (IPS) specification that is readily usable by all clinicians for the (cross-border) unscheduled care of a patient.

Scope: a minimal and non-exhaustive patient summary, which is specialty-agnostic and condition-independent, but still clinically relevant.

The HL7/CEN agreement identified the following principles for the IPS:

A. The standards specification for the IPS will be implementable

• Promote (the evolution and convergence of) existing standards
• Rely on solutions that are already implemented or ready for implementation
• Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use

• Strive for global accessibility of standards for free
• Strive for a core set of globally accessible and usable terminologies and value sets
• Include free text in addition to the structured codes as needed
• Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions

• The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
• The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:

• A robust maintenance and update process for the IPS
• A process to ensure clinical validity of the IPS, meeting:
  • clinical requirements (including workflow)
  • clinical documentation requirements
  • information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by

• stipulating the role of the IPS as a foundation for others to extend
• justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

What is a CDA

from famous sources like C-CDA

Responsible: Kai Heitmann

Templated CDA

from famous sources like C-CDA, Templates Standard

Responsible: Kai Heitmann

Open and Closed Templates

from famous sources like C-CDA, Templates Standard

Responsible: Kai Heitmann

Template versioning

from famous sources like Templates Standard

Responsible: Kai Heitmann

Identifiers for Templates and Value Sets

Some hints

• OIDs for Templates and Value Sets
• coming fro the HL7 OID Registry, mention the branches

Responsible: Giorgio Cangioli

Terminologies

Some hints

Responsible: Rob Hausam

• Focus on Value Sets, as they are the main artefacts used for validation
• General Info about Terminology Binding

How to extend Value Sets

•  ? Coded with Extensibility / no Extensions ? or other topics ?
• If needed: Example binding

Datatypes used in this guide

Responsible: Kai Heitmann

(This will be a list from ART-DECOR)

Design conventions and principles

Responsible: Rob Hausam

Principle on negations, data known absent and data unknown

In Review

Responsible: Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary

This specification represents negations, known absent data and unknown data by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than negation indicators or null flavours. In some cases this requires the creation of new SNOMED CT concepts. For example, a known absent Allergy/Intolerance would be represented by "716186003 |No known allergy (situation)|" (or any combination of its descendants), whereas no information about Allergy/Intolerance would be represented by a code with the meaning "Allergic disposition not known (situation)".

• See Paris slides
• Usage of negations
• The choice for negation it is not that of using negation indicator @negationInd but rely on the terminologies to do this
• @negationInd in CDA has been superseded in V3 later by two other negation indicators: actNegationInd valueNegationInd
• Alignment with FHIR

The representation of “condition/activity unknown” and of “condition/activity known absent”is normalized for the IPS by leveraging the expressiveness of SNOMED CT as opposed to relying on specific mechanisms of the underlying syntactical standard (such as nullFlavor and negationInd for CDA). The main rationale for this choice is to provide one single method to express either the presence or absence of a particular condition (e.g., an allergy) or activity (e.g., an immunization), or the lack of knowledge regarding this kind of condition or activity, resulting in a more robust and easily implementable specification. The other rationale is to have a representation of the clinical content of the patient summary which is less dependent on a particular format or syntax, enabling a more practical path to transforming and exchanging data from one standard format (e.g., CDA R2) to another (e.g., FHIR).

Provenance

Responsible: Philip Scott; Gary Dickinson

In Review

In the development of this Implementation Guide, consideration was given to the HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 - US Realm Draft Standard for Trial Use (December 2015). That guide provides a matrix offering a thorough and systematic analysis of provenance characteristics of electronic health records. Given the agreed scope principle that the IPS be minimal and implementable, and the variable maturity and operational methods of existing national patient summaries, the proposal is that this first version should not attempt to require the full detail of that provenance specification.

The approach proposed for this version of the IPS is to:

• Require document-level, not section level, provenance.
• Define IPS document provenance as one of two types: human-curated or software-assembled.
  • The classification is based on whether the IPS document is constructed by a human or an automated process, regardless of whether the IPS contains some content of both kinds.
• Require the IPS source system to identify the IPS document provenance type and "author".
  • The "author" shall be a human, if the IPS provenance type is "human-curated", or a device or system if the IPS provenance type is "software-assembled".
  • In the case of a "software-assembled" IPS that is then verified by a human, the document provenance type shall be "software-assembled" and the author shall be the device or system that constructed the IPS document, but an additional "verifier" identity shall name the human who performed this check. For the avoidance of doubt, this is not the same as legalAuthenticator. However, in cases where the verifying person intentionally wishes to sign the document, this shall be recorded as a legalAuthenticator.
• Allow optional section level author, provenance type, verifier and informant identification, for IPS source systems that can support this.
• Not attempt to implement the US Realm CDA data provenance templates.

The discussions with the EHR work group suggest that a possible future project should be an IPS functional profile, once there is greater clarity and operational experience of using the IPS.

General Implementation Guidance

Responsible: Kai Heitmann

• How to populates IDs in an CDA XML instance, e.g. ClinicalDocument.id, setId
• Where I can get IDs
• Relevant times for a patient summary
• Description of the different status definitions (condition, concern, observation) --> Giorgio
• (Authorship is probably a part to go to Provenance)

Standards used

SNOMED-CT, ... ? Remove ? This should not be a list only, it should reflect the rationale or go away

Reading Guide

Responsible: Kai Heitmann

Description of formalisms used, symbols, icons, how to read ART-DECOR tables

Conformance clause

Responsible: Steven Chu

Different conformance levels (to be explored)

Functional requirements and high-level use cases

Responsible: Giorgio Cangioli

• Add a reference to the CEN prEN. (to be analyzed)
• PSS
• Add a reference to the data set included in the html package
• Include in the functional area that no assumption on transport has been made…
• PS comes from one source, and covers different cases.
• Specify, how the provenance could be managed without going into details) to be included in next versions.
• To be further discussed, in any case add a paragraph in which explain the problem and how it might be faced.

Information

Here comes the Template Rendition of all Templates

Appendix

Responsible: NN

Integrated examples, links to instances

Responsible: Kai Heitmann

Validation artifacts (xsd, schematrons)

Responsible: Kai Heitmann

List of all artifacts used in this guide

Responsible: Autogenerated, assisted by Kai Heitmann

Examples (in progress)

Responsible: Stephen Chu, Giorgio Cangioli (Translation), Kai Heitmann (Translation)

Plan:

• Create one or more storyboards (Stephen?)
• Turn the storyboards into real IPS example CDA instances
• Allow for multilingual CDA (Italian, German)
• Offer all XSD in the publication package
• include schematrons (generated by ART-DECOR)