IPS implementationguide 2

Continuous Build

This is the Continuous Build of the HL7 CDA® R2 Implementation Guide International Patient Summary (will be incorrect/inconsistent at times).

See the Directory of the published standard.

Document Information

This document contains: Standard for Trial Use International Patient Summary (2.00). The text materials belong to category cdaips.

CDAR2_INTLPATSUMMARY_STU_R2_2024OSEP

HL7 CDA® R2 Implementation Guide
International Patient Summary
STU Release 2 (Universal Realm)

International Patient Summary

Standard for Trial Use

© 2024 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.
Use of this material is governed by HL7's IP Compliance Policy.

Role	Name	Organization	Contact
Primary Editor	Giorgio Cangioli	Consultant, HL7 Italy	giorgio.cangioli@gmail.com
Primary Editor	Rob Hausam	Hausam Consulting LLC	rob@hausamconsulting.com
Primary Editor	Dr Kai U. Heitmann	Heitmann Consulting and Services, ART-DECOR Open Tools GmbH, HL7 Germany	info@kheitmann.de
Primary Editor	François Macary	Phast	francois.macary@phast.fr
Contributor	Dr Philip Scott	HL7 UK	philip.scott@uwtsd.ac.uk
Contributor	Dr Christof Geßner	HL7 Germany	christof.gessner@mxdx.de
Contributor	Dr Stefan Sabutsch	ELGA, HL7 Austria	stefan.sabutsch@elga.gv.at
Contributor	Gary Dickinson	CentriHealth	gary.dickinson@ehr-standards.com
Contributor	Catherine Chronaki	HL7 International Foundation	chronaki@gmail.com
Contributor	Dr Stephen Chu	HL7 Australia	chuscmi88@gmail.com
Contributor	Didi Davis	The Sequoia Project	ddavis@sequoiaproject.org
Contributor	George Dixon	Allscripts LLC	george.dixon@allscripts.com
Contributor	Kenneth Sinn	Ontario Health Digital Services	ken.sinn@ontariohealth.ca
Contributor	John D'Amore	More Informatics	johnd@moreinformatics.com

Thanks to Alexander Berler (a.berler@gnomon.com.gr); Carina Seerainer (carina.seerainer@elga.gv.at); John Roberts (John.A.Roberts@tn.gov); Julie James (julie_james@bluewaveinformatics.co.uk); Mark Shafarman (mark.shafarman@earthlink.net); Fernando Portilla (fportila@gmail.com); Ed Hammond (william.hammond@duke.edu); Steve Kay (s.kay@histandards.net).

Introduction

An International Patient Summary (IPS) document is an electronic health record extract containing essential healthcare information about a subject of care. As specified in EN ISO 27269, it is designed for supporting the use case scenario for ‘unplanned, cross border care’, but it is not limited to it. It is intended to be international, i.e., to provide generic solutions for global application beyond a particular region or country.

The IPS dataset is minimal and non-exhaustive; specialty-agnostic and condition-independent; but still clinically relevant.

The IPS document is composed by a set of robust, well-defined and potentially reusable sets of core data items (indicated as IPS library in the figure below). The tight focus of the IPS on unplanned care is in this case not a limitation, but, on the contrary, facilitates their potential re-use beyond the IPS scope.

Figure 1: The IPS product and by-products

Purpose

The goal of this Implementation Guide is to specify how to represent in HL7 CDA the International Patient Summary (IPS). An alternative representation as templated HL7 FHIR R2 is also provided ( see the hl7.org site ). The initial focus of the International Patient Summary (IPS) was the unplanned care across national borders. This specification can be used and be useful also in local applications and be supportive of planned care.

Scope

As specified in EN ISO 27269, the IPS dataset is a “minimal, non-exhaustive set of data elements required for the international patient summary”. A Patient Summary is defined by ISO/TR 12773-1:2009 as a “Health record extract comprising a standardized collection of clinical and contextual information (retrospective, concurrent, prospective) that provides a snapshot in time of a subject of care’s health information and healthcare.”

‘Minimal’ reflects the ideas of ‘summary’ and the need to be concise, but also alludes to the existence of a core set of data elements that all health care professionals can use; it is intended to be a specialty agnostic and condition independent set. It does not imply that all the items in the data set will be used in every summary. It is also possible to refine the extract from a record such that the content of the summary is more relevant to a particular condition (e.g. asthma) but no asthma-specific elements will be specified in this standard. The IPS Document or IPS can be extended by non-IPS standard condition-specific data. ‘Non-exhaustive’ recognizes that the ideal data set is not closed, and is likely to be extended, not just in terms of requirement evolution, but also pragmatically in instances of use. [EN ISO 27269].

Furthermore the scope of the IPS is global. Although this is a major challenge, this implementation guide takes various experiences and newer developments into account to address, as far as possible, global feasibility.

The following picture provides an overview of the current IPS content.

Figure 2: The IPS composition

Project Background and relationships with other projects

Details on the project background and relationships with other projects are available in the IPS Website.

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 or unplanned 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 EHR systems for unplanned care management, personal health records and mobile health data applications.
• System integrators.
• Organizations that manage regional and national patient summaries.

Reading Publication Artifacts

A reading guide is available that explains the formalism used to express the publication artifacts, i.e. template meta data and template design. For convenience the guide is included in the appendix. (see section "How to read the table view for templates")

Technical Background

What is a CDA

CDA R2 is

… a document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange.
[CDA R2 Standard http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7, Section 1.1]

Clinical documents, according to CDA, have the following characteristics:

• Persistence
• Stewardship
• Potential for authentication
• Context
• Wholeness
• Human readability

CDA defines a header for classification and management and a document body that carries the clinical record. While the header metadata are prescriptive and designed for consistency across all instances, the body is highly generic, leaving the designation of semantic requirements to implementation.

Templated CDA

CDA R2 can be constrained by mechanisms defined in the “Refinement and Localization” section of the HL7 Version 3 Interoperability Standards. The mechanism most commonly used to constrain CDA is referred to as “templated CDA”. This specification created a set of artifacts containing modular CDA templates (and associated value sets) for the purpose of the International Patient Summary, and the templates can be reused across any number of CDA document types.

There are different kinds of templates that might be created. Among them, the most common ones are:

• CDA Document Level Templates constrain fields in the Clinical Document Architecture (CDA) header, and define containment relationships to CDA sections.
  For example, a History-and-Physical document-level template might require that the patient’s name be present, and that the document contain a Physical Exam section.
• CDA Header Level Templates constrain fields for parts of the CDA header, like the patient (record target), the author, participations or the service event.
• CDA Section Level Templates constrain fields in the CDA section, and define containment relationships to CDA entries.
  For example, a Physical-exam section-level template might require that the section/code be fixed to a particular LOINC code, and that the section contain a Systolic Blood Pressure observation.
• CDA Entry Level Templates constrain the CDA clinical statement model in accordance with real world observations and acts.
  For example, a Systolic-blood-pressure entry-level template defines how the CDA Observation class is constrained (how to populate observation/code, how to populate observation/value, etc.) to represent the notion of a systolic blood pressure.

Open and Closed Templates

Open templates permit anything to be done in the underlying standard that is not explicitly prohibited. This allows templates to be built up over time that extend and go beyond the original use cases for which they were originally designed.

Closed templates only permit what has been defined in the template, and do not permit anything beyond that. There are good reasons to use closed templates, sometimes having to do with local policy. For example, in communicating information from a healthcare provider to an insurance company, some information may need to be omitted to ensure patient privacy laws are followed. Most templates developed for CDA are of the open sort.

Template versioning

Template versioning is needed to enable template designs to evolve over time.

Template versioning enables template designers to control and shape the conformance statements that make up a template’s design over time tailoring the design to fit the template’s intended purpose.

Each template version is associated with a particular template. The template – as a whole – has a mandatory globally unique, non-semantic, identifier. The identifier serves as the identifier of the original intent of the template and as the identifier of the set of versions that represent the template over time.

Template versions have a mandatory timestamp (date and optional time), called the “effective date”. The date can be seen as the point in time when the template version “came into being”, i.e. was recognized as existent by the governance group. Use of the template prior to this date would be considered an invalid use of the template.

For further information on Templates, Template Versions and related topics refer to the HL7 Templates Standard [HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=377].

Conformance Verbs

The conformance verb keywords SHALL, SHOULD, MAY and SHALL NOT in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide [HL7 Version 3 Publishing Facilitator's Guide http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm].

• SHALL: an absolute requirement
• SHALL NOT: an absolute prohibition against inclusion
• SHOULD: best practice or recommendation. There may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course
• MAY: truly optional; can be included or omitted as the author decides with no implications

Identifiers for Templates and Value Sets

This specification uses the following OIDs for the artifacts that are registered at the HL7 OID registry.

• The root OID for templates is 2.16.840.1.113883.10.22

  • Document Level Templates are sub branch .1, e.g. 2.16.840.1.113883.10.22.1.1 International Patient Summary
  • Header Level Templates are summarized under 2.16.840.1.113883.10.22.2, e.g. 2.16.840.1.113883.10.22.2.1 IPS CDA recordTarget
  • Section Level Templates are summarized under 2.16.840.1.113883.10.22.3, e.g. 2.16.840.1.113883.10.22.3.1 IPS Medication Summary Section
  • Entry Level templates are summarized under 2.16.840.1.113883.10.22.4, e.g. 2.16.840.1.113883.10.22.4.19 IPS Certainty Observation
  • “other” assistance templates are summarized under 2.16.840.1.113883.10.22.9, e.g. 2.16.840.1.113883.10.22.9.2 IPS CDA Device
• The root OID for Value Sets is 2.16.840.1.113883.11

The sub branches for templates follow the recommendations of HL7 International and ISO 13582 [ISO/TS 13582:2015 Health informatics -- Sharing of OID registry information]

Terminologies

Note: Much of the description provided in this section is copied and adapted from the §4.2.8 Vocabulary Conformance section of the C-CDA DSTU R2.1 Implementation Guide Volume 1 [HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379 ]

The templates in this document use terms from several code systems. These vocabularies are defined in various supporting specifications and may be maintained by other bodies, as is the case for the LOINC® and SNOMED CT® vocabularies. The primary terminologies identified for this specification are listed in the Design conventions and principles, section "How to use terminologies (preferred binding)".

Note that value set identifiers (e.g., ValueSet 2.16.840.1.113883.1.11.78 Observation Interpretation (DYNAMIC)) used in the binding definitions of template conformance statements do not appear in the XML instance of a CDA document. The definition of the template must be referenced to determine or validate the vocabulary conformance requirements of the template.

Value set bindings adhere to HL7 Vocabulary Working Group best practices, and include both an indication of stability and of coding strength for the binding. Value set bindings can be STATIC, meaning that they bind to a specified version of a value set, or DYNAMIC, meaning that they bind to the most current version of the value set. If a STATIC binding is specified, a date SHALL be included to indicate the value set version. If a DYNAMIC binding is specified, the value set authority and link to the base definition of the value set SHALL be included, if available, so implementers can access the current version of the value set. When a vocabulary binding binds to a single code, the stability of the binding is implicitly STATIC.

For example, to convey @code=11450-4, the code’s displayName 'Problem List', the OID of the codeSystem from which the code is drawn '2.16.840.1.113883.6.1', and the codeSystemName 'LOINC', the tabular view used in this guide is presented as shown below.

Figure: Binding to a Single Code (tabular view)

HL7 Data Types Release 1 requires the codeSystem attribute unless the underlying data type is “Coded Simple” or “CS”, in which case it is prohibited. The displayName and the codeSystemName are optional, but recommended, in all cases.

The above example would be properly expressed as follows.

<code code="11450-4" codeSystem="2.16.840.1.113883.6.1"/>

<!-- or -->

<code code="11450-4" codeSystem="2.16.840.1.113883.6.1" displayName="Problem List" codeSystemName=”LOINC”/>

Figure: XML Expression of a Single-Code Binding

A full discussion of the representation of vocabulary is outside the scope of this document; for more information, see the HL7 V3 Normative Edition 2010 ^[HL7 V3 Normative Edition 2010 http://www.hl7.org/memonly/downloads/v3edition.cfm] sections on Abstract Data Types and XML Data Types R1.

There is a discrepancy between the HL7 R1 Data Types and this guide in the implementation of translation code versus the original code. The R1 data type requires the original code in the root. The convention agreed upon for this implementation guide is that a code from the required value set is used in the element and other codes not included in the value set are to be represented in a translation for the element. Note: This discrepancy is resolved in HL7 Data Types R2, but that is not available for use in CDA R2.

In the next example, the conformant code is SNOMED CT code 206525008.

<code code="206525008" codeSystem="2.16.840.1.113883.6.96"
  displayName="neonatal necrotizing enterocolitis" codeSystemName="SNOMED CT">
  <translation code="NEC-1" codeSystem="2.16.840.1.113883.19"
    displayName="necrotizing enterocolitis"/>
</code>

Figure: Translation Code Example

Value set tables are present below a template, or are referenced if they occur elsewhere in the specification, when there are value set bindings in the template. The value set table provides the value set identifier, a description, and a link to the source of the value set when possible. Ellipses in the last row indicate the value set members shown are examples and the true source must be accessed to see all members.

If a value set binding has a DYNAMIC stability, implementers creating a CDA document must go to the location in the URL to check for the most current version of the value set expansion.

Note: Much of the description provided in the following three sections on value set definitions and expansions and extending value sets is adapted from Core Principles and Properties of HL7 Version 3 Models [Core Principles and Properties of HL7 Version 3 Models http://www.hl7.org/implement/standards/product_brief.cfm?product_id=58].

Value Set Definitions

Two approaches can be used to define the contents of a Value Set:

• Extensional Definition: Explicitly enumerating each of the Value Set concepts.
  • An Extensional Definition is an enumeration of all of the concepts within the Value Set. A Value Set defined by extension is composed of explicitly enumerated sets of concept representations (with the Code System in which they are valid). The simplest case is when the Value Set consists of only one concept.
• Intensional Definition: Defining an algorithm that, when executed by a machine (or interpreted by a human being), yields an enumeration of all of the concepts within the Value Set, which is called a Value Set Expansion.
  • An Intensional Definition is a set of rules that can be expanded (ideally computationally) to an exact set of concept representations at a particular point in time.

Many of the value sets used in the IPS specification are defined intensionally. The source of truth for these value sets and their definitions for IPS is ART-DECOR® [IPS Value Sets in ART-DECOR®].

Figure: Intensional value set definition.

Value Set Expansions

To obtain a list of enumerated concepts, Value Sets must be expanded. This means that the Value Set Definition must be converted to a list of concept representations at a point in time. This normally is a list of codes that may be used in populating or validating communicated model instances (but it may alternatively be a list of designations). While this is straightforward for extensional Value Set Definitions, an intensional Value Set Definition must be resolved to a Value Set Expansion by processing the rules contained in the Value Set Definition. Value Set Expansion can be done as early as the point of Value Set definition or as late as run time. For intensional Value Sets, the set of concepts contained in the expansion will generally change when the definition is changed (a new version of the Value Set Definition), but also may change with the identical version of the definition if the underlying code systems change, and the changes are part of the Value Set Expansion. This can be controlled if the definition statement refers to specific code system versions, thereby prohibiting the expansion from changing when the code system changes with a new version release. See Core Principles and Properties of HL7 Version 3 Models for additional details [Core Principles and Properties of HL7 Version 3 Models http://www.hl7.org/implement/standards/product_brief.cfm?product_id=58].

In order to implement the IPS specification, the intensionally defined value sets must be expanded (as noted above). ART-DECOR® provides capabilities for generating (and store) the required value set expansions. Other terminology servers are also expected to provide this service.

How to extend Value Sets

For elements with a binding to a value set that allows extensibility (Extensible/CWE), it may at times be necessary to extend the value set in order to support implementation needs. Coded With Extensibility (Extensible/CWE) means that the set of codes resulting from processing the Value Set Definition is not necessarily complete for its intended use-case. There may be some concepts that need to be communicated that cannot be represented within the expansion of the specified value set. In these cases, implementers therefore have permission to send local codes or original text within the coded element if an appropriate code cannot be found within the value set and its current expansion. When this does occur, however, there is an expectation that implementers should feed back these "missing concepts" to the maintainers of the Value Sets or referenced Code System(s) to have the necessary concept added, and then to transition to the new "official" code when one is subsequently added to the value set.