HL7 IPS - User contributions [en]

IPS Introduction 1

2017-07-29T22:48:45Z

Cchronaki: /* Structuring Choices */

=Introduction=

The '''International Patient Summary''' (IPS) is a electronic health record extract containing essential healthcare information intended for use in the unscheduled, cross-border care scenario comprising at least the required elements of the IPS dataset. The IPS dataset is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country.
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"></ref>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"></ref>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”; and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Note that the last two items are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extent possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017, HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS:

{{IncludeImage|IPS_principles.png|300px|30%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref> The IPS Principles

#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
#The standards specification for the IPS will be applicable for global use
#*Strive for global accessibility of standards for use at no cost
#*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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|600px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref> The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available the IPS value sets for global use at no cost for implementation of the IPS.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable and understood, a patient summary must rely as much as possible on structured data and multilingual international reference terminologies that are licensed at no cost for global use in the International Patient Summary. In the case of SNOMED CT, it is expected that SNOMED CT and HL7 will make arrangements per their agreement to support the use of SNOMED CT in HL7 artefacts for global use. In this spirit, the International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR®<ref>ART-DECOR® art-decor.org</ref> as the specification platform for this Implementation Guide and uses the HL7 template exchange format<ref name="teits"></ref>. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.
Users of the specification can visit the IPS project page in ART-DECOR® to browse the specifications and review examples. User may also use the tool to validate their IPS instances. For more information please review the Appendix.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br>Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br>Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br>Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br>Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br>This document is focused on the European cross-country services.
<div style="padding-left:30px">
{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref> The European Commission CEN/TC 251 Grant Agreement
</div>
* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref> This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

Hereafter a set of other related initiatives:
* The '''HL7 Consolidated CDA (C-CDA)''' <ref>http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref> implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br>This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br>This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service''' <ref>https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications</ref>.This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. This is one of the primary sources for this Implementation Guide.
* The Joint Initiative on SDO Global Health Informatics Standardization '''(JIC) Patient Summary Standards Set''' is a set of health informatics standards and related artefacts that can be used to support the implementation of a Patient Summary <ref>JIC http://www.jointinitiativecouncil.org/index.asp</ref>. The definition of the Patient Summary given by this initiative is a little broader than that adopted by the HL7 and CEN/TC 251 projects, being ““the minimum set of information needed to assure healthcare coordination and the continuity of care” .
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1<ref>HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=420</ref> is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Introduction 1

2017-07-24T22:19:42Z

Cchronaki: /* Structuring Choices */

=Introduction=

The '''International Patient Summary''' (IPS) is a electronic health record extract containing essential healthcare information intended for use in the unscheduled, cross-border care scenario comprising at least the required elements of the IPS dataset. The IPS dataset is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country.
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"/>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"/>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”; and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Note that the last two items are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extend possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.

{{IncludeImage|IPS_principles.png|300px|30%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref>The IPS Principles

#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
#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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|400px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref>The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.
Users of the specification can visit the IPS project page in ART-DECOR® to browse the specifications and review examples. User may also use the tool to validate their IPS instances. For more information please review the Appendix 1.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br /> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br />Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br />Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br />Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br />Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br />This document is focused on the European cross-country services.

{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref>The European Commission CEN/TC 251 Grant Agreement

* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref> This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

Hereafter a set of other related initiatives:
* The '''HL7 Consolidated CDA (C-CDA)''' <ref>http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379 </ref> implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br />This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br />This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service''' <ref>https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications</ref>.This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. This is one of the primary sources for this Implementation Guide.
* The Joint Initiative on SDO Global Health Informatics Standardization '''(JIC) Patient Summary Standards Set''' is a set of health informatics standards and related artefacts that can be used to support the implementation of a Patient Summary <ref>JIC http://www.jointinitiativecouncil.org/index.asp</ref>. The definition of the Patient Summary given by this initiative is a little broader than that adopted by the HL7 and CEN/TC 251 projects, being ““the minimum set of information needed to assure healthcare coordination and the continuity of care” .
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1<ref>http://www.hl7.org/implement/standards/product_brief.cfm?product_id=420</ref> is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Appendix 1

2017-07-24T21:59:59Z

Cchronaki: /* Validation artifacts */

=Appendix (Informative) =

==Acronyms and abbreviations ==
<div class="column clearfix">
<div class="col-md-12">
<table class="table table-bordered wikitable">
<tr><td>'''CCD'''</td><td>Continuity of Care Document</td></tr>
<tr><td>'''C-CDA'''</td><td>Consolidated CDA</td></tr>
<tr><td>'''CDA'''</td><td>Clinical Document Architecture</td></tr>
<tr><td>'''CEN'''</td><td>Comité Européen de Normalisation (European Committee for Standardization)</td></tr>
<tr><td>'''CEN/TC 251 '''</td><td>CEN Technical Committe 251</td></tr>
<tr><td>'''DSTU'''</td><td>Draft Standard for Trial Use</td></tr>
<tr><td>'''EC'''</td><td>European Commission</td></tr>
<tr><td>'''EDQM'''</td><td>European Directorate for the Quality of Medicines & Healthcare</td></tr>
<tr><td>'''eHDSI'''</td><td>Digital Service Infrastructure for eHealth</td></tr>
<tr><td>'''eHN'''</td><td>eHealth Network</td></tr>
<tr><td>'''EHR'''</td><td>Electronic Healthcare Record</td></tr>
<tr><td>'''EN'''</td><td>European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''epSOS'''</td><td>European Patient Smart Open Services</td></tr>
<tr><td>'''EU'''</td><td>European; Europe</td></tr>
<tr><td>'''FDA'''</td><td>Food and Drug Administration (USA)</td></tr>
<tr><td>'''GP'''</td><td>General Practitioner</td></tr>
<tr><td>'''HL7'''</td><td>Health Level Seven</td></tr>
<tr><td>'''HP'''</td><td>Healthcare Professional</td></tr>
<tr><td>'''IDMP'''</td><td>IDentification of Medicinal Products (ISO Standard)</td></tr>
<tr><td>'''IHE'''</td><td>Integrating the Healthcare Enterprise</td></tr>
<tr><td>'''INTERPAS'''</td><td>International Patient Summary (HL7 International Project)</td></tr>
<tr><td>'''IPS'''</td><td>International Patient Summary</td></tr>
<tr><td>'''ISO'''</td><td>International Organization for Standardization</td></tr>
<tr><td>'''JAseHN'''</td><td>Joint Action to Support the eHealth Network</td></tr>
<tr><td>'''JIC'''</td><td>Joint Initiative Council on SDO Global Health Informatics Standardization</td></tr>
<tr><td>'''LOINC'''</td><td>Logical Observation Identifiers Names & Codes</td></tr>
<tr><td>'''MOU'''</td><td>Memorandum of Understanding (on cooperation surrounding health related information and communication technologies, that between EU and US)</td></tr>
<tr><td>'''MPID'''</td><td>Medicinal Product Identifier </td></tr>
<tr><td>'''ONC'''</td><td>Office of the National Coordinator for Health Information Technology (USA)</td></tr>
<tr><td>'''PCC'''</td><td>Patient Care Coordination</td></tr>
<tr><td>'''PCID '''</td><td>Medicinal Product Package Identifier</td></tr>
<tr><td>'''PhPID(s)'''</td><td>Pharmaceutical Product Identifier(s)</td></tr>
<tr><td>'''prEN'''</td><td>Draft European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''prTS'''</td><td>Draft Technical Specifications (CEN)</td></tr>
<tr><td>'''PS'''</td><td>Patient Summary</td></tr>
<tr><td>'''S&I'''</td><td>Standards and Interoperability (S&I) Framework (run by ONC)</td></tr>
<tr><td>'''SAIF'''</td><td>Service Aware Interoperability Framework</td></tr>
<tr><td>'''SDO'''</td><td>Standards Developing Organization</td></tr>
<tr><td>'''STU'''</td><td>Standard for Trial Use</td></tr>
<tr><td>'''TS'''</td><td>Technical Specifications (CEN)</td></tr>
<tr><td>'''UCUM'''</td><td>Unified Code for Units of Measure</td></tr>
<tr><td>'''WHO'''</td><td>World Health Organization</td></tr>
</table>
</div>
</div>

==Glossary ==
*'''Compliance.''' A standard or specification is compliant with another standard or specification if all propositions that are true in the initial standard are also true in the complying standard. The target artifact is compliant with the source artifact if and only if all conforming implementations of the target are also conforming with the source (RM-ODP). The term compliance is also used to state expectations as to how certain specifications need to satisfy possible legislative or regulatory constraints or requirements.
*'''Conformance''' relates an implementation to a standard. Any proposition that is true of the specification must be true in its implementation. (ISO, 2010).
*'''Conformance Assessment''' is a process whereby a given implementation instance is evaluated to determine which of its various Conformance Assertions are valid implementations of a given specification’s Conformance Statements.
*'''Conformance Statement''' is a statement that identifies testable requirements at a specified Conformance Point within a specification, explicitly defining the behavior which must be satisfied at these points. Conformance Statements will only occur in standard which are intended to constrain some feature of a real implementation, so that there exists, in principle, the possibility of testing.
*'''Conformance Assertion''' is a testable, verifiable statement made about a specific implementation instance against a corresponding Conformance Statement.
*'''Conformance Points''' are the evaluation of conformance at specific points in the implementation or specification. See Conformance.
* '''Electronic Patient Summary''': electronic health record extract containing essential healthcare information intended for specific uses . (EN ISO 13940: 2016)
* '''International Patient Summary''' : electronic patient summary for use in the unscheduled, cross-border care scenario comprising at least the required elements of the IPS dataset.
* '''International Patient Summary dataset''': a minimal and non-exhaustive patient summary dataset, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient.

== Real World User Stories ==

This section reports a series of real world user stories adapted from the Trillium Bridge project <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the eHDSI initiative <ref>The eHDSI initiative https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home. </ref>

=== IPS Storyboard 1: Martha, a traveling corporate executive ===
Martha, a 45-year old corporate executive and breast cancer survivor travels frequently on business between the US and EU countries. She carries a clinical summary on her mobile phone and on paper just in case she needs to seek medical care regarding recurring symptoms. Martha’s summary includes
*Breast cancer Stage II with no evidence of recurrence following treatment
*hot flashes as problems
*Anastrozole 1 mg. once daily
*Black Cohosh Extract herbal supplement as medications
*the indication of an allergy to Penicillin
*and finally as Plan of Care, to continue hormone medication with Anastrozole for total of 5 years
*and monitor for potential breast cancer recurrence.

During a visit in Austria, Martha walks up a hill and experiences shortness of breath, faints, and wakes up a few minutes later after hitting her head on a stone step. A passerby helps her get to the emergency department of a local hospital. An ambulance is called and she is brought to the emergency ward.

During registration and admission, Martha hands in her patient summary in a USB key. At the hospital, Martha is evaluated by an oncologist and a cardiologist.

Following care provision, Martha receives an encounter report. When back home she hands in the encounter report to her primary physician, who updates her record.

=== IPS Storyboard 2: Paolo, a retired businessman ===
Paolo Cerruti is a 67-year-old retired businessman, who normally lives in the outskirts Bergamo, near Lake Como, in Lombardy. He is generally healthy, but has long-standing hypertension. His regular physician changed his medication two weeks ago because of poor blood pressure control on his previous medication. He is on holiday going through New England, US, travelling on his own to enjoy the autumn foliage, and is presently in Boston, MA. He is nearing the end of his holiday, and will be returning to Italy in three days’ time. Two days ago he lost his day bag. The bag included his hypertension medication, and he has not been able to take his tablets for two days.

This morning he has woken up feeling dizzy and has blurred vision. The hotel is able to put him in urgent contact with a local general practitioner (GP). Having assessed him, the GP noted a raised blood pressure, but is uncertain about whether to attribute these symptoms to the raised blood pressure or a side effect of the new medication. Now, the GP in Boston needs to know the medication, and the past few blood pressure readings to determine how exceptional the present reading is and manage Paolo appropriately.

Immediate access to his International Patient Summary would be the perfect answer. Paolo may retrieve his online European Patient Summary for emergency access that is retrieved, transformed into an IPS and shown its content translated in English.

The GP notes that visual disturbances are a recognized side effect of this medication. No specific treatment is indicated, and Paolo is reassured that side effects will gradually subside, and his GP can prescribe a suitable antihypertensive medication upon his return to Lake Como.

=== IPS Storyboard 3: Diana, a pregnant woman ===
Diana is a 34-year-old pregnant woman from Lisbon with a past medical history of allergic asthma and thyroid cancer during adolescence; for the latter she had a surgical procedure done (thyroidectomy) and, as a consequence, suffers hypothyroidism which requires hormone replacement for life (levothyroxine). At the age of 31 she was diagnosed with a hereditary cardiac disorder – Brugada Syndrome – and had a cardioverter defibrillator implanted to control potentially lethal arrhythmias.

During the pregnancy of her first child (C-section delivery), she suffered gestational diabetes that developed into type 2 diabetes after giving birth and needs now to receive subcutaneous insulin. As chronic treatment she also needs nebulizations three-time per day for her asthma - this condition is condition is aggravated in her case by being a smoker (1 pack per day) as included in the Social History Section.

At this moment, she presents severe pre-eclampsia (hypertension during pregnancy) in treatment with two oral antihypertensive agents (a combination medication). Additionally, she is following a 14-day-course of antibiotic treatment due to an acute pyelonephritis (kidney infection more likely to be develop in pregnant women due to the physiological changes that may interfere with the flow of urine).

Other sections of her Summary include allergies to latex and kiwi (which are very often associated) and to aspirin, and intolerance to lactose; immunizations administered during childhood and adolescence are also present.

Although being real choices for the different diseases and conditions, the selection of the patient's current medication tries to present some easily described medication as well as not so easily ones: e.g. insulin degludec, amoxicilin+clavulanic acid, and the combination of ipratropium bromide+salbutamol for nebulization. For the oral treatment of the pre-eclampsia the agents selected would not be used in real practice during pregnancy.

==Integrated examples==
The IPS specification releases are published at ips.art-decor.org the [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials that the W3C schemas are part of; it also includes example CDA document instances. A set of use cases have been defined and represented in IPS format. Also multiple languages are covered.

It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Validation artifacts ==
You can test your implementation (instances) against the IPS specification. To download materials to your computer for local testing and validation consider...
* ...the W3C schemas (actually valid for any CDA specification) located at ips.art-decor.org the [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances.
* ..the ISO schematron, automatically generated by the tool. These are files to do validation locally by associating IPS CDA instances with the main schematron using an XML editor or to use the derived XSLT conversions and apply the according XSLT derivation to your local IPS CDA instance.

For further information you can follow the documentation.

==Operational information ==
* The IPS project has an official mailing list address ips(at)lists.hl7.org, hosted at the HL7 listserver. Visit your [http://www.hl7.org/myhl7/managelistservs.cfm?ref=common Listserv Subscriptions] at hl7.org and subscribe to the '''International Patient Summary (IPS)''' that is summarised under the Structured Documents Work Group.
* We also offer to write an email to ''info(at)international-patient-summary.net'' for inquiries regarding the specification
* * The original specification is hosted on the logical ART-DECOR main server art-decor.org under the ''Governance Group'' '''HL7 International''', the project is reachable at the [http://art-decor.org/art-decor/decor-project--hl7ips- Live Project Landing Page].
* Any IPS specification release in HTML format resides at [http://ips.art-decor.org Project Publication Page]. It is likely that the publication site will move to hl7.org permanently, we will inform about that process.
* The IPS specification on the wiki is hosted here (international-patient-summary.net). It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Licenses==
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
*'''SNOMED CT''': SNOMED International (formerly know as International Healthcare Terminology Standards Development Organization IHTSDO)<ref>Get SNOMED CT http://www.ihtsdo.org/snomed-ct/get-snomed-ct</ref> or info@ihtsdo.org
*'''Logical Observation Identifiers Names & Codes''' (LOINC): The Regenstrief Institute, Inc.
*'''Unified Code for Units of Measure (UCUM) : Regenstrief Institute, Inc. and the UCUM Organization
*'''EDQM Standard Terms ''' : European Directorate for the Quality of Medicines & Healthcare (EDQM) <ref>EDQM Standard Terms https://standardterms.edqm.eu</ref>

==FAQ’s ==

''This is a placeholder for future Frequently Asked Questions about the International Patient Summary.''

IPS Appendix 1

2017-07-24T21:59:18Z

Cchronaki: /* Integrated examples */

=Appendix (Informative) =

==Acronyms and abbreviations ==
<div class="column clearfix">
<div class="col-md-12">
<table class="table table-bordered wikitable">
<tr><td>'''CCD'''</td><td>Continuity of Care Document</td></tr>
<tr><td>'''C-CDA'''</td><td>Consolidated CDA</td></tr>
<tr><td>'''CDA'''</td><td>Clinical Document Architecture</td></tr>
<tr><td>'''CEN'''</td><td>Comité Européen de Normalisation (European Committee for Standardization)</td></tr>
<tr><td>'''CEN/TC 251 '''</td><td>CEN Technical Committe 251</td></tr>
<tr><td>'''DSTU'''</td><td>Draft Standard for Trial Use</td></tr>
<tr><td>'''EC'''</td><td>European Commission</td></tr>
<tr><td>'''EDQM'''</td><td>European Directorate for the Quality of Medicines & Healthcare</td></tr>
<tr><td>'''eHDSI'''</td><td>Digital Service Infrastructure for eHealth</td></tr>
<tr><td>'''eHN'''</td><td>eHealth Network</td></tr>
<tr><td>'''EHR'''</td><td>Electronic Healthcare Record</td></tr>
<tr><td>'''EN'''</td><td>European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''epSOS'''</td><td>European Patient Smart Open Services</td></tr>
<tr><td>'''EU'''</td><td>European; Europe</td></tr>
<tr><td>'''FDA'''</td><td>Food and Drug Administration (USA)</td></tr>
<tr><td>'''GP'''</td><td>General Practitioner</td></tr>
<tr><td>'''HL7'''</td><td>Health Level Seven</td></tr>
<tr><td>'''HP'''</td><td>Healthcare Professional</td></tr>
<tr><td>'''IDMP'''</td><td>IDentification of Medicinal Products (ISO Standard)</td></tr>
<tr><td>'''IHE'''</td><td>Integrating the Healthcare Enterprise</td></tr>
<tr><td>'''INTERPAS'''</td><td>International Patient Summary (HL7 International Project)</td></tr>
<tr><td>'''IPS'''</td><td>International Patient Summary</td></tr>
<tr><td>'''ISO'''</td><td>International Organization for Standardization</td></tr>
<tr><td>'''JAseHN'''</td><td>Joint Action to Support the eHealth Network</td></tr>
<tr><td>'''JIC'''</td><td>Joint Initiative Council on SDO Global Health Informatics Standardization</td></tr>
<tr><td>'''LOINC'''</td><td>Logical Observation Identifiers Names & Codes</td></tr>
<tr><td>'''MOU'''</td><td>Memorandum of Understanding (on cooperation surrounding health related information and communication technologies, that between EU and US)</td></tr>
<tr><td>'''MPID'''</td><td>Medicinal Product Identifier </td></tr>
<tr><td>'''ONC'''</td><td>Office of the National Coordinator for Health Information Technology (USA)</td></tr>
<tr><td>'''PCC'''</td><td>Patient Care Coordination</td></tr>
<tr><td>'''PCID '''</td><td>Medicinal Product Package Identifier</td></tr>
<tr><td>'''PhPID(s)'''</td><td>Pharmaceutical Product Identifier(s)</td></tr>
<tr><td>'''prEN'''</td><td>Draft European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''prTS'''</td><td>Draft Technical Specifications (CEN)</td></tr>
<tr><td>'''PS'''</td><td>Patient Summary</td></tr>
<tr><td>'''S&I'''</td><td>Standards and Interoperability (S&I) Framework (run by ONC)</td></tr>
<tr><td>'''SAIF'''</td><td>Service Aware Interoperability Framework</td></tr>
<tr><td>'''SDO'''</td><td>Standards Developing Organization</td></tr>
<tr><td>'''STU'''</td><td>Standard for Trial Use</td></tr>
<tr><td>'''TS'''</td><td>Technical Specifications (CEN)</td></tr>
<tr><td>'''UCUM'''</td><td>Unified Code for Units of Measure</td></tr>
<tr><td>'''WHO'''</td><td>World Health Organization</td></tr>
</table>
</div>
</div>

==Glossary ==
*'''Compliance.''' A standard or specification is compliant with another standard or specification if all propositions that are true in the initial standard are also true in the complying standard. The target artifact is compliant with the source artifact if and only if all conforming implementations of the target are also conforming with the source (RM-ODP). The term compliance is also used to state expectations as to how certain specifications need to satisfy possible legislative or regulatory constraints or requirements.
*'''Conformance''' relates an implementation to a standard. Any proposition that is true of the specification must be true in its implementation. (ISO, 2010).
*'''Conformance Assessment''' is a process whereby a given implementation instance is evaluated to determine which of its various Conformance Assertions are valid implementations of a given specification’s Conformance Statements.
*'''Conformance Statement''' is a statement that identifies testable requirements at a specified Conformance Point within a specification, explicitly defining the behavior which must be satisfied at these points. Conformance Statements will only occur in standard which are intended to constrain some feature of a real implementation, so that there exists, in principle, the possibility of testing.
*'''Conformance Assertion''' is a testable, verifiable statement made about a specific implementation instance against a corresponding Conformance Statement.
*'''Conformance Points''' are the evaluation of conformance at specific points in the implementation or specification. See Conformance.
* '''Electronic Patient Summary''': electronic health record extract containing essential healthcare information intended for specific uses . (EN ISO 13940: 2016)
* '''International Patient Summary''' : electronic patient summary for use in the unscheduled, cross-border care scenario comprising at least the required elements of the IPS dataset.
* '''International Patient Summary dataset''': a minimal and non-exhaustive patient summary dataset, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient.

== Real World User Stories ==

This section reports a series of real world user stories adapted from the Trillium Bridge project <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the eHDSI initiative <ref>The eHDSI initiative https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home. </ref>

=== IPS Storyboard 1: Martha, a traveling corporate executive ===
Martha, a 45-year old corporate executive and breast cancer survivor travels frequently on business between the US and EU countries. She carries a clinical summary on her mobile phone and on paper just in case she needs to seek medical care regarding recurring symptoms. Martha’s summary includes
*Breast cancer Stage II with no evidence of recurrence following treatment
*hot flashes as problems
*Anastrozole 1 mg. once daily
*Black Cohosh Extract herbal supplement as medications
*the indication of an allergy to Penicillin
*and finally as Plan of Care, to continue hormone medication with Anastrozole for total of 5 years
*and monitor for potential breast cancer recurrence.

During a visit in Austria, Martha walks up a hill and experiences shortness of breath, faints, and wakes up a few minutes later after hitting her head on a stone step. A passerby helps her get to the emergency department of a local hospital. An ambulance is called and she is brought to the emergency ward.

During registration and admission, Martha hands in her patient summary in a USB key. At the hospital, Martha is evaluated by an oncologist and a cardiologist.

Following care provision, Martha receives an encounter report. When back home she hands in the encounter report to her primary physician, who updates her record.

=== IPS Storyboard 2: Paolo, a retired businessman ===
Paolo Cerruti is a 67-year-old retired businessman, who normally lives in the outskirts Bergamo, near Lake Como, in Lombardy. He is generally healthy, but has long-standing hypertension. His regular physician changed his medication two weeks ago because of poor blood pressure control on his previous medication. He is on holiday going through New England, US, travelling on his own to enjoy the autumn foliage, and is presently in Boston, MA. He is nearing the end of his holiday, and will be returning to Italy in three days’ time. Two days ago he lost his day bag. The bag included his hypertension medication, and he has not been able to take his tablets for two days.

This morning he has woken up feeling dizzy and has blurred vision. The hotel is able to put him in urgent contact with a local general practitioner (GP). Having assessed him, the GP noted a raised blood pressure, but is uncertain about whether to attribute these symptoms to the raised blood pressure or a side effect of the new medication. Now, the GP in Boston needs to know the medication, and the past few blood pressure readings to determine how exceptional the present reading is and manage Paolo appropriately.

Immediate access to his International Patient Summary would be the perfect answer. Paolo may retrieve his online European Patient Summary for emergency access that is retrieved, transformed into an IPS and shown its content translated in English.

The GP notes that visual disturbances are a recognized side effect of this medication. No specific treatment is indicated, and Paolo is reassured that side effects will gradually subside, and his GP can prescribe a suitable antihypertensive medication upon his return to Lake Como.

=== IPS Storyboard 3: Diana, a pregnant woman ===
Diana is a 34-year-old pregnant woman from Lisbon with a past medical history of allergic asthma and thyroid cancer during adolescence; for the latter she had a surgical procedure done (thyroidectomy) and, as a consequence, suffers hypothyroidism which requires hormone replacement for life (levothyroxine). At the age of 31 she was diagnosed with a hereditary cardiac disorder – Brugada Syndrome – and had a cardioverter defibrillator implanted to control potentially lethal arrhythmias.

During the pregnancy of her first child (C-section delivery), she suffered gestational diabetes that developed into type 2 diabetes after giving birth and needs now to receive subcutaneous insulin. As chronic treatment she also needs nebulizations three-time per day for her asthma - this condition is condition is aggravated in her case by being a smoker (1 pack per day) as included in the Social History Section.

At this moment, she presents severe pre-eclampsia (hypertension during pregnancy) in treatment with two oral antihypertensive agents (a combination medication). Additionally, she is following a 14-day-course of antibiotic treatment due to an acute pyelonephritis (kidney infection more likely to be develop in pregnant women due to the physiological changes that may interfere with the flow of urine).

Other sections of her Summary include allergies to latex and kiwi (which are very often associated) and to aspirin, and intolerance to lactose; immunizations administered during childhood and adolescence are also present.

Although being real choices for the different diseases and conditions, the selection of the patient's current medication tries to present some easily described medication as well as not so easily ones: e.g. insulin degludec, amoxicilin+clavulanic acid, and the combination of ipratropium bromide+salbutamol for nebulization. For the oral treatment of the pre-eclampsia the agents selected would not be used in real practice during pregnancy.

==Integrated examples==
The IPS specification releases are published at ips.art-decor.org the [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials that the W3C schemas are part of; it also includes example CDA document instances. A set of use cases have been defined and represented in IPS format. Also multiple languages are covered.

It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Validation artifacts ==
You can test your implementation (instances) against the IPS specification. To download materials to your computer for local testing and validation consider...
* ...the W3C schemas (actually valid for any CDA specification) located at the [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances.
* ..the ISO schematron, automatically generated by the tool. These are files to do validation locally by associating IPS CDA instances with the main schematron using an XML editor or to use the derived XSLT conversions and apply the according XSLT derivation to your local IPS CDA instance.

For further information you can follow the documentation.

==Operational information ==
* The IPS project has an official mailing list address ips(at)lists.hl7.org, hosted at the HL7 listserver. Visit your [http://www.hl7.org/myhl7/managelistservs.cfm?ref=common Listserv Subscriptions] at hl7.org and subscribe to the '''International Patient Summary (IPS)''' that is summarised under the Structured Documents Work Group.
* We also offer to write an email to ''info(at)international-patient-summary.net'' for inquiries regarding the specification
* * The original specification is hosted on the logical ART-DECOR main server art-decor.org under the ''Governance Group'' '''HL7 International''', the project is reachable at the [http://art-decor.org/art-decor/decor-project--hl7ips- Live Project Landing Page].
* Any IPS specification release in HTML format resides at [http://ips.art-decor.org Project Publication Page]. It is likely that the publication site will move to hl7.org permanently, we will inform about that process.
* The IPS specification on the wiki is hosted here (international-patient-summary.net). It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Licenses==
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
*'''SNOMED CT''': SNOMED International (formerly know as International Healthcare Terminology Standards Development Organization IHTSDO)<ref>Get SNOMED CT http://www.ihtsdo.org/snomed-ct/get-snomed-ct</ref> or info@ihtsdo.org
*'''Logical Observation Identifiers Names & Codes''' (LOINC): The Regenstrief Institute, Inc.
*'''Unified Code for Units of Measure (UCUM) : Regenstrief Institute, Inc. and the UCUM Organization
*'''EDQM Standard Terms ''' : European Directorate for the Quality of Medicines & Healthcare (EDQM) <ref>EDQM Standard Terms https://standardterms.edqm.eu</ref>

==FAQ’s ==

''This is a placeholder for future Frequently Asked Questions about the International Patient Summary.''

IPS Appendix 1

2017-07-24T21:58:46Z

Cchronaki: /* Integrated examples */

=Appendix (Informative) =

==Acronyms and abbreviations ==
<div class="column clearfix">
<div class="col-md-12">
<table class="table table-bordered wikitable">
<tr><td>'''CCD'''</td><td>Continuity of Care Document</td></tr>
<tr><td>'''C-CDA'''</td><td>Consolidated CDA</td></tr>
<tr><td>'''CDA'''</td><td>Clinical Document Architecture</td></tr>
<tr><td>'''CEN'''</td><td>Comité Européen de Normalisation (European Committee for Standardization)</td></tr>
<tr><td>'''CEN/TC 251 '''</td><td>CEN Technical Committe 251</td></tr>
<tr><td>'''DSTU'''</td><td>Draft Standard for Trial Use</td></tr>
<tr><td>'''EC'''</td><td>European Commission</td></tr>
<tr><td>'''EDQM'''</td><td>European Directorate for the Quality of Medicines & Healthcare</td></tr>
<tr><td>'''eHDSI'''</td><td>Digital Service Infrastructure for eHealth</td></tr>
<tr><td>'''eHN'''</td><td>eHealth Network</td></tr>
<tr><td>'''EHR'''</td><td>Electronic Healthcare Record</td></tr>
<tr><td>'''EN'''</td><td>European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''epSOS'''</td><td>European Patient Smart Open Services</td></tr>
<tr><td>'''EU'''</td><td>European; Europe</td></tr>
<tr><td>'''FDA'''</td><td>Food and Drug Administration (USA)</td></tr>
<tr><td>'''GP'''</td><td>General Practitioner</td></tr>
<tr><td>'''HL7'''</td><td>Health Level Seven</td></tr>
<tr><td>'''HP'''</td><td>Healthcare Professional</td></tr>
<tr><td>'''IDMP'''</td><td>IDentification of Medicinal Products (ISO Standard)</td></tr>
<tr><td>'''IHE'''</td><td>Integrating the Healthcare Enterprise</td></tr>
<tr><td>'''INTERPAS'''</td><td>International Patient Summary (HL7 International Project)</td></tr>
<tr><td>'''IPS'''</td><td>International Patient Summary</td></tr>
<tr><td>'''ISO'''</td><td>International Organization for Standardization</td></tr>
<tr><td>'''JAseHN'''</td><td>Joint Action to Support the eHealth Network</td></tr>
<tr><td>'''JIC'''</td><td>Joint Initiative Council on SDO Global Health Informatics Standardization</td></tr>
<tr><td>'''LOINC'''</td><td>Logical Observation Identifiers Names & Codes</td></tr>
<tr><td>'''MOU'''</td><td>Memorandum of Understanding (on cooperation surrounding health related information and communication technologies, that between EU and US)</td></tr>
<tr><td>'''MPID'''</td><td>Medicinal Product Identifier </td></tr>
<tr><td>'''ONC'''</td><td>Office of the National Coordinator for Health Information Technology (USA)</td></tr>
<tr><td>'''PCC'''</td><td>Patient Care Coordination</td></tr>
<tr><td>'''PCID '''</td><td>Medicinal Product Package Identifier</td></tr>
<tr><td>'''PhPID(s)'''</td><td>Pharmaceutical Product Identifier(s)</td></tr>
<tr><td>'''prEN'''</td><td>Draft European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''prTS'''</td><td>Draft Technical Specifications (CEN)</td></tr>
<tr><td>'''PS'''</td><td>Patient Summary</td></tr>
<tr><td>'''S&I'''</td><td>Standards and Interoperability (S&I) Framework (run by ONC)</td></tr>
<tr><td>'''SAIF'''</td><td>Service Aware Interoperability Framework</td></tr>
<tr><td>'''SDO'''</td><td>Standards Developing Organization</td></tr>
<tr><td>'''STU'''</td><td>Standard for Trial Use</td></tr>
<tr><td>'''TS'''</td><td>Technical Specifications (CEN)</td></tr>
<tr><td>'''UCUM'''</td><td>Unified Code for Units of Measure</td></tr>
<tr><td>'''WHO'''</td><td>World Health Organization</td></tr>
</table>
</div>
</div>

==Glossary ==
*'''Compliance.''' A standard or specification is compliant with another standard or specification if all propositions that are true in the initial standard are also true in the complying standard. The target artifact is compliant with the source artifact if and only if all conforming implementations of the target are also conforming with the source (RM-ODP). The term compliance is also used to state expectations as to how certain specifications need to satisfy possible legislative or regulatory constraints or requirements.
*'''Conformance''' relates an implementation to a standard. Any proposition that is true of the specification must be true in its implementation. (ISO, 2010).
*'''Conformance Assessment''' is a process whereby a given implementation instance is evaluated to determine which of its various Conformance Assertions are valid implementations of a given specification’s Conformance Statements.
*'''Conformance Statement''' is a statement that identifies testable requirements at a specified Conformance Point within a specification, explicitly defining the behavior which must be satisfied at these points. Conformance Statements will only occur in standard which are intended to constrain some feature of a real implementation, so that there exists, in principle, the possibility of testing.
*'''Conformance Assertion''' is a testable, verifiable statement made about a specific implementation instance against a corresponding Conformance Statement.
*'''Conformance Points''' are the evaluation of conformance at specific points in the implementation or specification. See Conformance.
* '''Electronic Patient Summary''': electronic health record extract containing essential healthcare information intended for specific uses . (EN ISO 13940: 2016)
* '''International Patient Summary''' : electronic patient summary for use in the unscheduled, cross-border care scenario comprising at least the required elements of the IPS dataset.
* '''International Patient Summary dataset''': a minimal and non-exhaustive patient summary dataset, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient.

== Real World User Stories ==

This section reports a series of real world user stories adapted from the Trillium Bridge project <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the eHDSI initiative <ref>The eHDSI initiative https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home. </ref>

=== IPS Storyboard 1: Martha, a traveling corporate executive ===
Martha, a 45-year old corporate executive and breast cancer survivor travels frequently on business between the US and EU countries. She carries a clinical summary on her mobile phone and on paper just in case she needs to seek medical care regarding recurring symptoms. Martha’s summary includes
*Breast cancer Stage II with no evidence of recurrence following treatment
*hot flashes as problems
*Anastrozole 1 mg. once daily
*Black Cohosh Extract herbal supplement as medications
*the indication of an allergy to Penicillin
*and finally as Plan of Care, to continue hormone medication with Anastrozole for total of 5 years
*and monitor for potential breast cancer recurrence.

During a visit in Austria, Martha walks up a hill and experiences shortness of breath, faints, and wakes up a few minutes later after hitting her head on a stone step. A passerby helps her get to the emergency department of a local hospital. An ambulance is called and she is brought to the emergency ward.

During registration and admission, Martha hands in her patient summary in a USB key. At the hospital, Martha is evaluated by an oncologist and a cardiologist.

Following care provision, Martha receives an encounter report. When back home she hands in the encounter report to her primary physician, who updates her record.

=== IPS Storyboard 2: Paolo, a retired businessman ===
Paolo Cerruti is a 67-year-old retired businessman, who normally lives in the outskirts Bergamo, near Lake Como, in Lombardy. He is generally healthy, but has long-standing hypertension. His regular physician changed his medication two weeks ago because of poor blood pressure control on his previous medication. He is on holiday going through New England, US, travelling on his own to enjoy the autumn foliage, and is presently in Boston, MA. He is nearing the end of his holiday, and will be returning to Italy in three days’ time. Two days ago he lost his day bag. The bag included his hypertension medication, and he has not been able to take his tablets for two days.

This morning he has woken up feeling dizzy and has blurred vision. The hotel is able to put him in urgent contact with a local general practitioner (GP). Having assessed him, the GP noted a raised blood pressure, but is uncertain about whether to attribute these symptoms to the raised blood pressure or a side effect of the new medication. Now, the GP in Boston needs to know the medication, and the past few blood pressure readings to determine how exceptional the present reading is and manage Paolo appropriately.

Immediate access to his International Patient Summary would be the perfect answer. Paolo may retrieve his online European Patient Summary for emergency access that is retrieved, transformed into an IPS and shown its content translated in English.

The GP notes that visual disturbances are a recognized side effect of this medication. No specific treatment is indicated, and Paolo is reassured that side effects will gradually subside, and his GP can prescribe a suitable antihypertensive medication upon his return to Lake Como.

=== IPS Storyboard 3: Diana, a pregnant woman ===
Diana is a 34-year-old pregnant woman from Lisbon with a past medical history of allergic asthma and thyroid cancer during adolescence; for the latter she had a surgical procedure done (thyroidectomy) and, as a consequence, suffers hypothyroidism which requires hormone replacement for life (levothyroxine). At the age of 31 she was diagnosed with a hereditary cardiac disorder – Brugada Syndrome – and had a cardioverter defibrillator implanted to control potentially lethal arrhythmias.

During the pregnancy of her first child (C-section delivery), she suffered gestational diabetes that developed into type 2 diabetes after giving birth and needs now to receive subcutaneous insulin. As chronic treatment she also needs nebulizations three-time per day for her asthma - this condition is condition is aggravated in her case by being a smoker (1 pack per day) as included in the Social History Section.

At this moment, she presents severe pre-eclampsia (hypertension during pregnancy) in treatment with two oral antihypertensive agents (a combination medication). Additionally, she is following a 14-day-course of antibiotic treatment due to an acute pyelonephritis (kidney infection more likely to be develop in pregnant women due to the physiological changes that may interfere with the flow of urine).

Other sections of her Summary include allergies to latex and kiwi (which are very often associated) and to aspirin, and intolerance to lactose; immunizations administered during childhood and adolescence are also present.

Although being real choices for the different diseases and conditions, the selection of the patient's current medication tries to present some easily described medication as well as not so easily ones: e.g. insulin degludec, amoxicilin+clavulanic acid, and the combination of ipratropium bromide+salbutamol for nebulization. For the oral treatment of the pre-eclampsia the agents selected would not be used in real practice during pregnancy.

==Integrated examples==
The IPS specification releases are published at ips.art-decor.org [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials that the W3C schemas are part of; it also includes example CDA document instances. A set of use cases have been defined and represented in IPS format. Also multiple languages are covered.

It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Validation artifacts ==
You can test your implementation (instances) against the IPS specification. To download materials to your computer for local testing and validation consider...
* ...the W3C schemas (actually valid for any CDA specification) located at the [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances.
* ..the ISO schematron, automatically generated by the tool. These are files to do validation locally by associating IPS CDA instances with the main schematron using an XML editor or to use the derived XSLT conversions and apply the according XSLT derivation to your local IPS CDA instance.

For further information you can follow the documentation.

==Operational information ==
* The IPS project has an official mailing list address ips(at)lists.hl7.org, hosted at the HL7 listserver. Visit your [http://www.hl7.org/myhl7/managelistservs.cfm?ref=common Listserv Subscriptions] at hl7.org and subscribe to the '''International Patient Summary (IPS)''' that is summarised under the Structured Documents Work Group.
* We also offer to write an email to ''info(at)international-patient-summary.net'' for inquiries regarding the specification
* * The original specification is hosted on the logical ART-DECOR main server art-decor.org under the ''Governance Group'' '''HL7 International''', the project is reachable at the [http://art-decor.org/art-decor/decor-project--hl7ips- Live Project Landing Page].
* Any IPS specification release in HTML format resides at [http://ips.art-decor.org Project Publication Page]. It is likely that the publication site will move to hl7.org permanently, we will inform about that process.
* The IPS specification on the wiki is hosted here (international-patient-summary.net). It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Licenses==
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
*'''SNOMED CT''': SNOMED International (formerly know as International Healthcare Terminology Standards Development Organization IHTSDO)<ref>Get SNOMED CT http://www.ihtsdo.org/snomed-ct/get-snomed-ct</ref> or info@ihtsdo.org
*'''Logical Observation Identifiers Names & Codes''' (LOINC): The Regenstrief Institute, Inc.
*'''Unified Code for Units of Measure (UCUM) : Regenstrief Institute, Inc. and the UCUM Organization
*'''EDQM Standard Terms ''' : European Directorate for the Quality of Medicines & Healthcare (EDQM) <ref>EDQM Standard Terms https://standardterms.edqm.eu</ref>

==FAQ’s ==

''This is a placeholder for future Frequently Asked Questions about the International Patient Summary.''

IPS Appendix 1

2017-07-24T21:56:51Z

Cchronaki: /* Integrated examples */

=Appendix (Informative) =

==Acronyms and abbreviations ==
<div class="column clearfix">
<div class="col-md-12">
<table class="table table-bordered wikitable">
<tr><td>'''CCD'''</td><td>Continuity of Care Document</td></tr>
<tr><td>'''C-CDA'''</td><td>Consolidated CDA</td></tr>
<tr><td>'''CDA'''</td><td>Clinical Document Architecture</td></tr>
<tr><td>'''CEN'''</td><td>Comité Européen de Normalisation (European Committee for Standardization)</td></tr>
<tr><td>'''CEN/TC 251 '''</td><td>CEN Technical Committe 251</td></tr>
<tr><td>'''DSTU'''</td><td>Draft Standard for Trial Use</td></tr>
<tr><td>'''EC'''</td><td>European Commission</td></tr>
<tr><td>'''EDQM'''</td><td>European Directorate for the Quality of Medicines & Healthcare</td></tr>
<tr><td>'''eHDSI'''</td><td>Digital Service Infrastructure for eHealth</td></tr>
<tr><td>'''eHN'''</td><td>eHealth Network</td></tr>
<tr><td>'''EHR'''</td><td>Electronic Healthcare Record</td></tr>
<tr><td>'''EN'''</td><td>European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''epSOS'''</td><td>European Patient Smart Open Services</td></tr>
<tr><td>'''EU'''</td><td>European; Europe</td></tr>
<tr><td>'''FDA'''</td><td>Food and Drug Administration (USA)</td></tr>
<tr><td>'''GP'''</td><td>General Practitioner</td></tr>
<tr><td>'''HL7'''</td><td>Health Level Seven</td></tr>
<tr><td>'''HP'''</td><td>Healthcare Professional</td></tr>
<tr><td>'''IDMP'''</td><td>IDentification of Medicinal Products (ISO Standard)</td></tr>
<tr><td>'''IHE'''</td><td>Integrating the Healthcare Enterprise</td></tr>
<tr><td>'''INTERPAS'''</td><td>International Patient Summary (HL7 International Project)</td></tr>
<tr><td>'''IPS'''</td><td>International Patient Summary</td></tr>
<tr><td>'''ISO'''</td><td>International Organization for Standardization</td></tr>
<tr><td>'''JAseHN'''</td><td>Joint Action to Support the eHealth Network</td></tr>
<tr><td>'''JIC'''</td><td>Joint Initiative Council on SDO Global Health Informatics Standardization</td></tr>
<tr><td>'''LOINC'''</td><td>Logical Observation Identifiers Names & Codes</td></tr>
<tr><td>'''MOU'''</td><td>Memorandum of Understanding (on cooperation surrounding health related information and communication technologies, that between EU and US)</td></tr>
<tr><td>'''MPID'''</td><td>Medicinal Product Identifier </td></tr>
<tr><td>'''ONC'''</td><td>Office of the National Coordinator for Health Information Technology (USA)</td></tr>
<tr><td>'''PCC'''</td><td>Patient Care Coordination</td></tr>
<tr><td>'''PCID '''</td><td>Medicinal Product Package Identifier</td></tr>
<tr><td>'''PhPID(s)'''</td><td>Pharmaceutical Product Identifier(s)</td></tr>
<tr><td>'''prEN'''</td><td>Draft European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''prTS'''</td><td>Draft Technical Specifications (CEN)</td></tr>
<tr><td>'''PS'''</td><td>Patient Summary</td></tr>
<tr><td>'''S&I'''</td><td>Standards and Interoperability (S&I) Framework (run by ONC)</td></tr>
<tr><td>'''SAIF'''</td><td>Service Aware Interoperability Framework</td></tr>
<tr><td>'''SDO'''</td><td>Standards Developing Organization</td></tr>
<tr><td>'''STU'''</td><td>Standard for Trial Use</td></tr>
<tr><td>'''TS'''</td><td>Technical Specifications (CEN)</td></tr>
<tr><td>'''UCUM'''</td><td>Unified Code for Units of Measure</td></tr>
<tr><td>'''WHO'''</td><td>World Health Organization</td></tr>
</table>
</div>
</div>

==Glossary ==
*'''Compliance.''' A standard or specification is compliant with another standard or specification if all propositions that are true in the initial standard are also true in the complying standard. The target artifact is compliant with the source artifact if and only if all conforming implementations of the target are also conforming with the source (RM-ODP). The term compliance is also used to state expectations as to how certain specifications need to satisfy possible legislative or regulatory constraints or requirements.
*'''Conformance''' relates an implementation to a standard. Any proposition that is true of the specification must be true in its implementation. (ISO, 2010).
*'''Conformance Assessment''' is a process whereby a given implementation instance is evaluated to determine which of its various Conformance Assertions are valid implementations of a given specification’s Conformance Statements.
*'''Conformance Statement''' is a statement that identifies testable requirements at a specified Conformance Point within a specification, explicitly defining the behavior which must be satisfied at these points. Conformance Statements will only occur in standard which are intended to constrain some feature of a real implementation, so that there exists, in principle, the possibility of testing.
*'''Conformance Assertion''' is a testable, verifiable statement made about a specific implementation instance against a corresponding Conformance Statement.
*'''Conformance Points''' are the evaluation of conformance at specific points in the implementation or specification. See Conformance.
* '''Electronic Patient Summary''': electronic health record extract containing essential healthcare information intended for specific uses . (EN ISO 13940: 2016)
* '''International Patient Summary''' : electronic patient summary for use in the unscheduled, cross-border care scenario comprising at least the required elements of the IPS dataset.
* '''International Patient Summary dataset''': a minimal and non-exhaustive patient summary dataset, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient.

== Real World User Stories ==

This section reports a series of real world user stories adapted from the Trillium Bridge project <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the eHDSI initiative <ref>The eHDSI initiative https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home. </ref>

=== IPS Storyboard 1: Martha, a traveling corporate executive ===
Martha, a 45-year old corporate executive and breast cancer survivor travels frequently on business between the US and EU countries. She carries a clinical summary on her mobile phone and on paper just in case she needs to seek medical care regarding recurring symptoms. Martha’s summary includes
*Breast cancer Stage II with no evidence of recurrence following treatment
*hot flashes as problems
*Anastrozole 1 mg. once daily
*Black Cohosh Extract herbal supplement as medications
*the indication of an allergy to Penicillin
*and finally as Plan of Care, to continue hormone medication with Anastrozole for total of 5 years
*and monitor for potential breast cancer recurrence.

During a visit in Austria, Martha walks up a hill and experiences shortness of breath, faints, and wakes up a few minutes later after hitting her head on a stone step. A passerby helps her get to the emergency department of a local hospital. An ambulance is called and she is brought to the emergency ward.

During registration and admission, Martha hands in her patient summary in a USB key. At the hospital, Martha is evaluated by an oncologist and a cardiologist.

Following care provision, Martha receives an encounter report. When back home she hands in the encounter report to her primary physician, who updates her record.

=== IPS Storyboard 2: Paolo, a retired businessman ===
Paolo Cerruti is a 67-year-old retired businessman, who normally lives in the outskirts Bergamo, near Lake Como, in Lombardy. He is generally healthy, but has long-standing hypertension. His regular physician changed his medication two weeks ago because of poor blood pressure control on his previous medication. He is on holiday going through New England, US, travelling on his own to enjoy the autumn foliage, and is presently in Boston, MA. He is nearing the end of his holiday, and will be returning to Italy in three days’ time. Two days ago he lost his day bag. The bag included his hypertension medication, and he has not been able to take his tablets for two days.

This morning he has woken up feeling dizzy and has blurred vision. The hotel is able to put him in urgent contact with a local general practitioner (GP). Having assessed him, the GP noted a raised blood pressure, but is uncertain about whether to attribute these symptoms to the raised blood pressure or a side effect of the new medication. Now, the GP in Boston needs to know the medication, and the past few blood pressure readings to determine how exceptional the present reading is and manage Paolo appropriately.

Immediate access to his International Patient Summary would be the perfect answer. Paolo may retrieve his online European Patient Summary for emergency access that is retrieved, transformed into an IPS and shown its content translated in English.

The GP notes that visual disturbances are a recognized side effect of this medication. No specific treatment is indicated, and Paolo is reassured that side effects will gradually subside, and his GP can prescribe a suitable antihypertensive medication upon his return to Lake Como.

=== IPS Storyboard 3: Diana, a pregnant woman ===
Diana is a 34-year-old pregnant woman from Lisbon with a past medical history of allergic asthma and thyroid cancer during adolescence; for the latter she had a surgical procedure done (thyroidectomy) and, as a consequence, suffers hypothyroidism which requires hormone replacement for life (levothyroxine). At the age of 31 she was diagnosed with a hereditary cardiac disorder – Brugada Syndrome – and had a cardioverter defibrillator implanted to control potentially lethal arrhythmias.

During the pregnancy of her first child (C-section delivery), she suffered gestational diabetes that developed into type 2 diabetes after giving birth and needs now to receive subcutaneous insulin. As chronic treatment she also needs nebulizations three-time per day for her asthma - this condition is condition is aggravated in her case by being a smoker (1 pack per day) as included in the Social History Section.

At this moment, she presents severe pre-eclampsia (hypertension during pregnancy) in treatment with two oral antihypertensive agents (a combination medication). Additionally, she is following a 14-day-course of antibiotic treatment due to an acute pyelonephritis (kidney infection more likely to be develop in pregnant women due to the physiological changes that may interfere with the flow of urine).

Other sections of her Summary include allergies to latex and kiwi (which are very often associated) and to aspirin, and intolerance to lactose; immunizations administered during childhood and adolescence are also present.

Although being real choices for the different diseases and conditions, the selection of the patient's current medication tries to present some easily described medication as well as not so easily ones: e.g. insulin degludec, amoxicilin+clavulanic acid, and the combination of ipratropium bromide+salbutamol for nebulization. For the oral treatment of the pre-eclampsia the agents selected would not be used in real practice during pregnancy.

==Integrated examples==
The IPS specification releases are published at [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials that the W3C schemas are part of; it also includes example CDA document instances. A set of use cases have been defined and represented in IPS format. Also multiple languages are covered.

It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Validation artifacts ==
You can test your implementation (instances) against the IPS specification. To download materials to your computer for local testing and validation consider...
* ...the W3C schemas (actually valid for any CDA specification) located at the [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances.
* ..the ISO schematron, automatically generated by the tool. These are files to do validation locally by associating IPS CDA instances with the main schematron using an XML editor or to use the derived XSLT conversions and apply the according XSLT derivation to your local IPS CDA instance.

For further information you can follow the documentation.

==Operational information ==
* The IPS project has an official mailing list address ips(at)lists.hl7.org, hosted at the HL7 listserver. Visit your [http://www.hl7.org/myhl7/managelistservs.cfm?ref=common Listserv Subscriptions] at hl7.org and subscribe to the '''International Patient Summary (IPS)''' that is summarised under the Structured Documents Work Group.
* We also offer to write an email to ''info(at)international-patient-summary.net'' for inquiries regarding the specification
* * The original specification is hosted on the logical ART-DECOR main server art-decor.org under the ''Governance Group'' '''HL7 International''', the project is reachable at the [http://art-decor.org/art-decor/decor-project--hl7ips- Live Project Landing Page].
* Any IPS specification release in HTML format resides at [http://ips.art-decor.org Project Publication Page]. It is likely that the publication site will move to hl7.org permanently, we will inform about that process.
* The IPS specification on the wiki is hosted here (international-patient-summary.net). It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Licenses==
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
*'''SNOMED CT''': SNOMED International (formerly know as International Healthcare Terminology Standards Development Organization IHTSDO)<ref>Get SNOMED CT http://www.ihtsdo.org/snomed-ct/get-snomed-ct</ref> or info@ihtsdo.org
*'''Logical Observation Identifiers Names & Codes''' (LOINC): The Regenstrief Institute, Inc.
*'''Unified Code for Units of Measure (UCUM) : Regenstrief Institute, Inc. and the UCUM Organization
*'''EDQM Standard Terms ''' : European Directorate for the Quality of Medicines & Healthcare (EDQM) <ref>EDQM Standard Terms https://standardterms.edqm.eu</ref>

==FAQ’s ==

''This is a placeholder for future Frequently Asked Questions about the International Patient Summary.''

IPS Appendix 1

2017-07-24T21:44:57Z

Cchronaki: /* Glossary */

=Appendix (Informative) =

==Acronyms and abbreviations ==
<div class="column clearfix">
<div class="col-md-12">
<table class="table table-bordered wikitable">
<tr><td>'''CCD'''</td><td>Continuity of Care Document</td></tr>
<tr><td>'''C-CDA'''</td><td>Consolidated CDA</td></tr>
<tr><td>'''CDA'''</td><td>Clinical Document Architecture</td></tr>
<tr><td>'''CEN'''</td><td>Comité Européen de Normalisation (European Committee for Standardization)</td></tr>
<tr><td>'''CEN/TC 251 '''</td><td>CEN Technical Committe 251</td></tr>
<tr><td>'''DSTU'''</td><td>Draft Standard for Trial Use</td></tr>
<tr><td>'''EC'''</td><td>European Commission</td></tr>
<tr><td>'''EDQM'''</td><td>European Directorate for the Quality of Medicines & Healthcare</td></tr>
<tr><td>'''eHDSI'''</td><td>Digital Service Infrastructure for eHealth</td></tr>
<tr><td>'''eHN'''</td><td>eHealth Network</td></tr>
<tr><td>'''EHR'''</td><td>Electronic Healthcare Record</td></tr>
<tr><td>'''EN'''</td><td>European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''epSOS'''</td><td>European Patient Smart Open Services</td></tr>
<tr><td>'''EU'''</td><td>European; Europe</td></tr>
<tr><td>'''FDA'''</td><td>Food and Drug Administration (USA)</td></tr>
<tr><td>'''GP'''</td><td>General Practitioner</td></tr>
<tr><td>'''HL7'''</td><td>Health Level Seven</td></tr>
<tr><td>'''HP'''</td><td>Healthcare Professional</td></tr>
<tr><td>'''IDMP'''</td><td>IDentification of Medicinal Products (ISO Standard)</td></tr>
<tr><td>'''IHE'''</td><td>Integrating the Healthcare Enterprise</td></tr>
<tr><td>'''INTERPAS'''</td><td>International Patient Summary (HL7 International Project)</td></tr>
<tr><td>'''IPS'''</td><td>International Patient Summary</td></tr>
<tr><td>'''ISO'''</td><td>International Organization for Standardization</td></tr>
<tr><td>'''JAseHN'''</td><td>Joint Action to Support the eHealth Network</td></tr>
<tr><td>'''JIC'''</td><td>Joint Initiative Council on SDO Global Health Informatics Standardization</td></tr>
<tr><td>'''LOINC'''</td><td>Logical Observation Identifiers Names & Codes</td></tr>
<tr><td>'''MOU'''</td><td>Memorandum of Understanding (on cooperation surrounding health related information and communication technologies, that between EU and US)</td></tr>
<tr><td>'''MPID'''</td><td>Medicinal Product Identifier </td></tr>
<tr><td>'''ONC'''</td><td>Office of the National Coordinator for Health Information Technology (USA)</td></tr>
<tr><td>'''PCC'''</td><td>Patient Care Coordination</td></tr>
<tr><td>'''PCID '''</td><td>Medicinal Product Package Identifier</td></tr>
<tr><td>'''PhPID(s)'''</td><td>Pharmaceutical Product Identifier(s)</td></tr>
<tr><td>'''prEN'''</td><td>Draft European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''prTS'''</td><td>Draft Technical Specifications (CEN)</td></tr>
<tr><td>'''PS'''</td><td>Patient Summary</td></tr>
<tr><td>'''S&I'''</td><td>Standards and Interoperability (S&I) Framework (run by ONC)</td></tr>
<tr><td>'''SAIF'''</td><td>Service Aware Interoperability Framework</td></tr>
<tr><td>'''SDO'''</td><td>Standards Developing Organization</td></tr>
<tr><td>'''STU'''</td><td>Standard for Trial Use</td></tr>
<tr><td>'''TS'''</td><td>Technical Specifications (CEN)</td></tr>
<tr><td>'''UCUM'''</td><td>Unified Code for Units of Measure</td></tr>
<tr><td>'''WHO'''</td><td>World Health Organization</td></tr>
</table>
</div>
</div>

==Glossary ==
*'''Compliance.''' A standard or specification is compliant with another standard or specification if all propositions that are true in the initial standard are also true in the complying standard. The target artifact is compliant with the source artifact if and only if all conforming implementations of the target are also conforming with the source (RM-ODP). The term compliance is also used to state expectations as to how certain specifications need to satisfy possible legislative or regulatory constraints or requirements.
*'''Conformance''' relates an implementation to a standard. Any proposition that is true of the specification must be true in its implementation. (ISO, 2010).
*'''Conformance Assessment''' is a process whereby a given implementation instance is evaluated to determine which of its various Conformance Assertions are valid implementations of a given specification’s Conformance Statements.
*'''Conformance Statement''' is a statement that identifies testable requirements at a specified Conformance Point within a specification, explicitly defining the behavior which must be satisfied at these points. Conformance Statements will only occur in standard which are intended to constrain some feature of a real implementation, so that there exists, in principle, the possibility of testing.
*'''Conformance Assertion''' is a testable, verifiable statement made about a specific implementation instance against a corresponding Conformance Statement.
*'''Conformance Points''' are the evaluation of conformance at specific points in the implementation or specification. See Conformance.
* '''Electronic Patient Summary''': electronic health record extract containing essential healthcare information intended for specific uses . (EN ISO 13940: 2016)
* '''International Patient Summary''' : electronic patient summary for use in the unscheduled, cross-border care scenario comprising at least the required elements of the IPS dataset.
* '''International Patient Summary dataset''': a minimal and non-exhaustive patient summary dataset, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient.

== Real World User Stories ==

This section reports a series of real world user stories adapted from the Trillium Bridge project <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the eHDSI initiative <ref>The eHDSI initiative https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home. </ref>

=== IPS Storyboard 1: Martha, a traveling corporate executive ===
Martha, a 45-year old corporate executive and breast cancer survivor travels frequently on business between the US and EU countries. She carries a clinical summary on her mobile phone and on paper just in case she needs to seek medical care regarding recurring symptoms. Martha’s summary includes
*Breast cancer Stage II with no evidence of recurrence following treatment
*hot flashes as problems
*Anastrozole 1 mg. once daily
*Black Cohosh Extract herbal supplement as medications
*the indication of an allergy to Penicillin
*and finally as Plan of Care, to continue hormone medication with Anastrozole for total of 5 years
*and monitor for potential breast cancer recurrence.

During a visit in Austria, Martha walks up a hill and experiences shortness of breath, faints, and wakes up a few minutes later after hitting her head on a stone step. A passerby helps her get to the emergency department of a local hospital. An ambulance is called and she is brought to the emergency ward.

During registration and admission, Martha hands in her patient summary in a USB key. At the hospital, Martha is evaluated by an oncologist and a cardiologist.

Following care provision, Martha receives an encounter report. When back home she hands in the encounter report to her primary physician, who updates her record.

=== IPS Storyboard 2: Paolo, a retired businessman ===
Paolo Cerruti is a 67-year-old retired businessman, who normally lives in the outskirts Bergamo, near Lake Como, in Lombardy. He is generally healthy, but has long-standing hypertension. His regular physician changed his medication two weeks ago because of poor blood pressure control on his previous medication. He is on holiday going through New England, US, travelling on his own to enjoy the autumn foliage, and is presently in Boston, MA. He is nearing the end of his holiday, and will be returning to Italy in three days’ time. Two days ago he lost his day bag. The bag included his hypertension medication, and he has not been able to take his tablets for two days.

This morning he has woken up feeling dizzy and has blurred vision. The hotel is able to put him in urgent contact with a local general practitioner (GP). Having assessed him, the GP noted a raised blood pressure, but is uncertain about whether to attribute these symptoms to the raised blood pressure or a side effect of the new medication. Now, the GP in Boston needs to know the medication, and the past few blood pressure readings to determine how exceptional the present reading is and manage Paolo appropriately.

Immediate access to his International Patient Summary would be the perfect answer. Paolo may retrieve his online European Patient Summary for emergency access that is retrieved, transformed into an IPS and shown its content translated in English.

The GP notes that visual disturbances are a recognized side effect of this medication. No specific treatment is indicated, and Paolo is reassured that side effects will gradually subside, and his GP can prescribe a suitable antihypertensive medication upon his return to Lake Como.

=== IPS Storyboard 3: Diana, a pregnant woman ===
Diana is a 34-year-old pregnant woman from Lisbon with a past medical history of allergic asthma and thyroid cancer during adolescence; for the latter she had a surgical procedure done (thyroidectomy) and, as a consequence, suffers hypothyroidism which requires hormone replacement for life (levothyroxine). At the age of 31 she was diagnosed with a hereditary cardiac disorder – Brugada Syndrome – and had a cardioverter defibrillator implanted to control potentially lethal arrhythmias.

During the pregnancy of her first child (C-section delivery), she suffered gestational diabetes that developed into type 2 diabetes after giving birth and needs now to receive subcutaneous insulin. As chronic treatment she also needs nebulizations three-time per day for her asthma - this condition is condition is aggravated in her case by being a smoker (1 pack per day) as included in the Social History Section.

At this moment, she presents severe pre-eclampsia (hypertension during pregnancy) in treatment with two oral antihypertensive agents (a combination medication). Additionally, she is following a 14-day-course of antibiotic treatment due to an acute pyelonephritis (kidney infection more likely to be develop in pregnant women due to the physiological changes that may interfere with the flow of urine).

Other sections of her Summary include allergies to latex and kiwi (which are very often associated) and to aspirin, and intolerance to lactose; immunizations administered during childhood and adolescence are also present.

Although being real choices for the different diseases and conditions, the selection of the patient's current medication tries to present some easily described medication as well as not so easily ones: e.g. insulin degludec, amoxicilin+clavulanic acid, and the combination of ipratropium bromide+salbutamol for nebulization. For the oral treatment of the pre-eclampsia the agents selected would not be used in real practice during pregnancy.

==Integrated examples==
The IPS specification releases are published at [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances. A set of use cases have been defined and represented in IPS format. Also multiple languages are covered.

It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Validation artifacts ==
You can test your implementation (instances) against the IPS specification. To download materials to your computer for local testing and validation consider...
* ...the W3C schemas (actually valid for any CDA specification) located at the [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances.
* ..the ISO schematron, automatically generated by the tool. These are files to do validation locally by associating IPS CDA instances with the main schematron using an XML editor or to use the derived XSLT conversions and apply the according XSLT derivation to your local IPS CDA instance.

For further information you can follow the documentation.

==Operational information ==
* The IPS project has an official mailing list address ips(at)lists.hl7.org, hosted at the HL7 listserver. Visit your [http://www.hl7.org/myhl7/managelistservs.cfm?ref=common Listserv Subscriptions] at hl7.org and subscribe to the '''International Patient Summary (IPS)''' that is summarised under the Structured Documents Work Group.
* We also offer to write an email to ''info(at)international-patient-summary.net'' for inquiries regarding the specification
* * The original specification is hosted on the logical ART-DECOR main server art-decor.org under the ''Governance Group'' '''HL7 International''', the project is reachable at the [http://art-decor.org/art-decor/decor-project--hl7ips- Live Project Landing Page].
* Any IPS specification release in HTML format resides at [http://ips.art-decor.org Project Publication Page]. It is likely that the publication site will move to hl7.org permanently, we will inform about that process.
* The IPS specification on the wiki is hosted here (international-patient-summary.net). It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Licenses==
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
*'''SNOMED CT''': SNOMED International (formerly know as International Healthcare Terminology Standards Development Organization IHTSDO)<ref>Get SNOMED CT http://www.ihtsdo.org/snomed-ct/get-snomed-ct</ref> or info@ihtsdo.org
*'''Logical Observation Identifiers Names & Codes''' (LOINC): The Regenstrief Institute, Inc.
*'''Unified Code for Units of Measure (UCUM) : Regenstrief Institute, Inc. and the UCUM Organization
*'''EDQM Standard Terms ''' : European Directorate for the Quality of Medicines & Healthcare (EDQM) <ref>EDQM Standard Terms https://standardterms.edqm.eu</ref>

==FAQ’s ==

''This is a placeholder for future Frequently Asked Questions about the International Patient Summary.''

IPS Appendix 1

2017-07-24T21:40:45Z

Cchronaki: /* Acronyms and abbreviations */

=Appendix (Informative) =

==Acronyms and abbreviations ==
<div class="column clearfix">
<div class="col-md-12">
<table class="table table-bordered wikitable">
<tr><td>'''CCD'''</td><td>Continuity of Care Document</td></tr>
<tr><td>'''C-CDA'''</td><td>Consolidated CDA</td></tr>
<tr><td>'''CDA'''</td><td>Clinical Document Architecture</td></tr>
<tr><td>'''CEN'''</td><td>Comité Européen de Normalisation (European Committee for Standardization)</td></tr>
<tr><td>'''CEN/TC 251 '''</td><td>CEN Technical Committe 251</td></tr>
<tr><td>'''DSTU'''</td><td>Draft Standard for Trial Use</td></tr>
<tr><td>'''EC'''</td><td>European Commission</td></tr>
<tr><td>'''EDQM'''</td><td>European Directorate for the Quality of Medicines & Healthcare</td></tr>
<tr><td>'''eHDSI'''</td><td>Digital Service Infrastructure for eHealth</td></tr>
<tr><td>'''eHN'''</td><td>eHealth Network</td></tr>
<tr><td>'''EHR'''</td><td>Electronic Healthcare Record</td></tr>
<tr><td>'''EN'''</td><td>European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''epSOS'''</td><td>European Patient Smart Open Services</td></tr>
<tr><td>'''EU'''</td><td>European; Europe</td></tr>
<tr><td>'''FDA'''</td><td>Food and Drug Administration (USA)</td></tr>
<tr><td>'''GP'''</td><td>General Practitioner</td></tr>
<tr><td>'''HL7'''</td><td>Health Level Seven</td></tr>
<tr><td>'''HP'''</td><td>Healthcare Professional</td></tr>
<tr><td>'''IDMP'''</td><td>IDentification of Medicinal Products (ISO Standard)</td></tr>
<tr><td>'''IHE'''</td><td>Integrating the Healthcare Enterprise</td></tr>
<tr><td>'''INTERPAS'''</td><td>International Patient Summary (HL7 International Project)</td></tr>
<tr><td>'''IPS'''</td><td>International Patient Summary</td></tr>
<tr><td>'''ISO'''</td><td>International Organization for Standardization</td></tr>
<tr><td>'''JAseHN'''</td><td>Joint Action to Support the eHealth Network</td></tr>
<tr><td>'''JIC'''</td><td>Joint Initiative Council on SDO Global Health Informatics Standardization</td></tr>
<tr><td>'''LOINC'''</td><td>Logical Observation Identifiers Names & Codes</td></tr>
<tr><td>'''MOU'''</td><td>Memorandum of Understanding (on cooperation surrounding health related information and communication technologies, that between EU and US)</td></tr>
<tr><td>'''MPID'''</td><td>Medicinal Product Identifier </td></tr>
<tr><td>'''ONC'''</td><td>Office of the National Coordinator for Health Information Technology (USA)</td></tr>
<tr><td>'''PCC'''</td><td>Patient Care Coordination</td></tr>
<tr><td>'''PCID '''</td><td>Medicinal Product Package Identifier</td></tr>
<tr><td>'''PhPID(s)'''</td><td>Pharmaceutical Product Identifier(s)</td></tr>
<tr><td>'''prEN'''</td><td>Draft European Normative [or Standard] (CEN)</td></tr>
<tr><td>'''prTS'''</td><td>Draft Technical Specifications (CEN)</td></tr>
<tr><td>'''PS'''</td><td>Patient Summary</td></tr>
<tr><td>'''S&I'''</td><td>Standards and Interoperability (S&I) Framework (run by ONC)</td></tr>
<tr><td>'''SAIF'''</td><td>Service Aware Interoperability Framework</td></tr>
<tr><td>'''SDO'''</td><td>Standards Developing Organization</td></tr>
<tr><td>'''STU'''</td><td>Standard for Trial Use</td></tr>
<tr><td>'''TS'''</td><td>Technical Specifications (CEN)</td></tr>
<tr><td>'''UCUM'''</td><td>Unified Code for Units of Measure</td></tr>
<tr><td>'''WHO'''</td><td>World Health Organization</td></tr>
</table>
</div>
</div>

==Glossary ==
*'''Compliance''' of one standard or specification is compliant with another standard or specification if all propositions true in the initial standard are also true in the complying standard. The target artifact is compliant with the source artifact if and only if all conformant implementations of the target are also conformant with the source. (RM-ODP). The term compliance is also used to state expectations as to how certain specifications need to satisfy possible legislative or regulatory constraints or requirements.
*'''Conformance''' relates an implementation to a standard. Any proposition that is true of the specification must be true in its implementation. (ISO, 2010).
*'''Conformance Assessment''' is a process whereby a given implementation instance is evaluated to determine which of its various Conformance Assertions are valid implementations of a given specification’s Conformance Statements.
*'''Conformance Statement''' is a statement that identifies testable requirements at a specified Conformance Point within a specification, explicitly defining the behavior which must be satisfied at these points. Conformance Statements will only occur in standard which are intended to constrain some feature of a real implementation, so that there exists, in principle, the possibility of testing.
*'''Conformance Assertion''' is a testable, verifiable statement made about a specific implementation instance against a corresponding Conformance Statement.
*'''Conformance Points''' are the evaluation of conformance at specific points in the implementation or specification. See Conformance.
* '''Electronic Patient Summary''': electronic health record extract containing essential healthcare information intended for specific uses . (EN ISO 13940: 2016)
* '''International Patient Summary''' : electronic patient summary for use in the unscheduled, cross-border care scenario comprising at least the required elements of the IPS dataset.
* '''International Patient Summary dataset''': a minimal and non-exhaustive patient summary dataset, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient.

== Real World User Stories ==

This section reports a series of real world user stories adapted from the Trillium Bridge project <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the eHDSI initiative <ref>The eHDSI initiative https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home. </ref>

=== IPS Storyboard 1: Martha, a traveling corporate executive ===
Martha, a 45-year old corporate executive and breast cancer survivor travels frequently on business between the US and EU countries. She carries a clinical summary on her mobile phone and on paper just in case she needs to seek medical care regarding recurring symptoms. Martha’s summary includes
*Breast cancer Stage II with no evidence of recurrence following treatment
*hot flashes as problems
*Anastrozole 1 mg. once daily
*Black Cohosh Extract herbal supplement as medications
*the indication of an allergy to Penicillin
*and finally as Plan of Care, to continue hormone medication with Anastrozole for total of 5 years
*and monitor for potential breast cancer recurrence.

During a visit in Austria, Martha walks up a hill and experiences shortness of breath, faints, and wakes up a few minutes later after hitting her head on a stone step. A passerby helps her get to the emergency department of a local hospital. An ambulance is called and she is brought to the emergency ward.

During registration and admission, Martha hands in her patient summary in a USB key. At the hospital, Martha is evaluated by an oncologist and a cardiologist.

Following care provision, Martha receives an encounter report. When back home she hands in the encounter report to her primary physician, who updates her record.

=== IPS Storyboard 2: Paolo, a retired businessman ===
Paolo Cerruti is a 67-year-old retired businessman, who normally lives in the outskirts Bergamo, near Lake Como, in Lombardy. He is generally healthy, but has long-standing hypertension. His regular physician changed his medication two weeks ago because of poor blood pressure control on his previous medication. He is on holiday going through New England, US, travelling on his own to enjoy the autumn foliage, and is presently in Boston, MA. He is nearing the end of his holiday, and will be returning to Italy in three days’ time. Two days ago he lost his day bag. The bag included his hypertension medication, and he has not been able to take his tablets for two days.

This morning he has woken up feeling dizzy and has blurred vision. The hotel is able to put him in urgent contact with a local general practitioner (GP). Having assessed him, the GP noted a raised blood pressure, but is uncertain about whether to attribute these symptoms to the raised blood pressure or a side effect of the new medication. Now, the GP in Boston needs to know the medication, and the past few blood pressure readings to determine how exceptional the present reading is and manage Paolo appropriately.

Immediate access to his International Patient Summary would be the perfect answer. Paolo may retrieve his online European Patient Summary for emergency access that is retrieved, transformed into an IPS and shown its content translated in English.

The GP notes that visual disturbances are a recognized side effect of this medication. No specific treatment is indicated, and Paolo is reassured that side effects will gradually subside, and his GP can prescribe a suitable antihypertensive medication upon his return to Lake Como.

=== IPS Storyboard 3: Diana, a pregnant woman ===
Diana is a 34-year-old pregnant woman from Lisbon with a past medical history of allergic asthma and thyroid cancer during adolescence; for the latter she had a surgical procedure done (thyroidectomy) and, as a consequence, suffers hypothyroidism which requires hormone replacement for life (levothyroxine). At the age of 31 she was diagnosed with a hereditary cardiac disorder – Brugada Syndrome – and had a cardioverter defibrillator implanted to control potentially lethal arrhythmias.

During the pregnancy of her first child (C-section delivery), she suffered gestational diabetes that developed into type 2 diabetes after giving birth and needs now to receive subcutaneous insulin. As chronic treatment she also needs nebulizations three-time per day for her asthma - this condition is condition is aggravated in her case by being a smoker (1 pack per day) as included in the Social History Section.

At this moment, she presents severe pre-eclampsia (hypertension during pregnancy) in treatment with two oral antihypertensive agents (a combination medication). Additionally, she is following a 14-day-course of antibiotic treatment due to an acute pyelonephritis (kidney infection more likely to be develop in pregnant women due to the physiological changes that may interfere with the flow of urine).

Other sections of her Summary include allergies to latex and kiwi (which are very often associated) and to aspirin, and intolerance to lactose; immunizations administered during childhood and adolescence are also present.

Although being real choices for the different diseases and conditions, the selection of the patient's current medication tries to present some easily described medication as well as not so easily ones: e.g. insulin degludec, amoxicilin+clavulanic acid, and the combination of ipratropium bromide+salbutamol for nebulization. For the oral treatment of the pre-eclampsia the agents selected would not be used in real practice during pregnancy.

==Integrated examples==
The IPS specification releases are published at [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances. A set of use cases have been defined and represented in IPS format. Also multiple languages are covered.

It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Validation artifacts ==
You can test your implementation (instances) against the IPS specification. To download materials to your computer for local testing and validation consider...
* ...the W3C schemas (actually valid for any CDA specification) located at the [http://ips.art-decor.org Project Publication Page]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances.
* ..the ISO schematron, automatically generated by the tool. These are files to do validation locally by associating IPS CDA instances with the main schematron using an XML editor or to use the derived XSLT conversions and apply the according XSLT derivation to your local IPS CDA instance.

For further information you can follow the documentation.

==Operational information ==
* The IPS project has an official mailing list address ips(at)lists.hl7.org, hosted at the HL7 listserver. Visit your [http://www.hl7.org/myhl7/managelistservs.cfm?ref=common Listserv Subscriptions] at hl7.org and subscribe to the '''International Patient Summary (IPS)''' that is summarised under the Structured Documents Work Group.
* We also offer to write an email to ''info(at)international-patient-summary.net'' for inquiries regarding the specification
* * The original specification is hosted on the logical ART-DECOR main server art-decor.org under the ''Governance Group'' '''HL7 International''', the project is reachable at the [http://art-decor.org/art-decor/decor-project--hl7ips- Live Project Landing Page].
* Any IPS specification release in HTML format resides at [http://ips.art-decor.org Project Publication Page]. It is likely that the publication site will move to hl7.org permanently, we will inform about that process.
* The IPS specification on the wiki is hosted here (international-patient-summary.net). It is likely that the publication site will move to hl7.org permanently, we will inform about that process.

==Licenses==
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
*'''SNOMED CT''': SNOMED International (formerly know as International Healthcare Terminology Standards Development Organization IHTSDO)<ref>Get SNOMED CT http://www.ihtsdo.org/snomed-ct/get-snomed-ct</ref> or info@ihtsdo.org
*'''Logical Observation Identifiers Names & Codes''' (LOINC): The Regenstrief Institute, Inc.
*'''Unified Code for Units of Measure (UCUM) : Regenstrief Institute, Inc. and the UCUM Organization
*'''EDQM Standard Terms ''' : European Directorate for the Quality of Medicines & Healthcare (EDQM) <ref>EDQM Standard Terms https://standardterms.edqm.eu</ref>

==FAQ’s ==

''This is a placeholder for future Frequently Asked Questions about the International Patient Summary.''

IPS Design conventions and principles 1

2017-07-24T13:30:53Z

Cchronaki: /* Provenance */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''<references group="Figure"/>

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a medications list could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation, drug reconciliation, etc. ) and on the type of information reported (e.g. patient-reported medication, prescribed, dispensed or administered medications, active or past medications, etc.).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary. It may be for example the list of all prescribed medicines, whose indicated treatment period has not yet expired, whether they have been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>). It may be a list of only the active ones or a complete history including the full patient's prescription and dispensation history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) or generally a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, the details about the medication order, supply, administration or monitoring the relevant information for an IPS are not relevant. It is important however, to know what medications are being taken by or have been given to a patient, independent to whether they are reported from the patient, another clinician, or derived from supporting information. In any case provenance information is important.

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independent to whether the original source is a prescription or a dispensation list. In fact, in many practical cases data included in a Patient Summary are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these case, data obtained from actual dispensation and/or prescription can be recorded as statements and the original requests, supplies or administration be referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products is quite easily solved within a single jurisdiction relaying on local drugs databases. In contrast, it is one of the major open issues for eHealth services across jurisdictions.

The set of ISO standards call IDMP <ref> https://www.idmp1.com/idmp-standards/ </ref> - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine <ref> http://www.open-medicine.eu/home.html </ref>. The completion of the IDMP implementation guides, the deployment of the needed supporting services, and the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Additional time is needed before these identifiers and attributes will be available in full for practical use.

Following therefore the IPS principles of “implementability”, “openness and extensibility” the solution proposed here does not rely on IDMP identifiers. It takes into account however, relevant IDMP identifiers and attributes already suitable for representing the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides and any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while he PhPID should be the same. For the purpose of the IPS, future standards and implementation guides should define global product identifiers that do not depend on the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and relate to IDMP identifiers.''

Thus, in absence of a global identification system for medicinal products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), reused by the IHE Pharmacy templates and more recently adopted (for specific cases) by the HL7 Pharmacy Medication statement templates. The main idea is to integrate local drug identifiers e.g. product codes, with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients, administrative dose forms, strength, route of administration, and package description.

Medicines data are usually represented in the CDA Templates using the manufacturedMaterial class, which includes a code and a name to describe any level of the product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the requirements of the IPS.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA <references group="Figure"/>

Hence, in order to describe these attributes, an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes of the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed).

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible to have a single representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent future IDMP identifiers and attributes in the IPS and in other document based standards such as SPL.

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model <references group="Figure"/>

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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 provenance, section-level provenance is optional.
*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 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, verifier 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.

Note: 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.

IPS Design conventions and principles 1

2017-07-24T13:29:34Z

Cchronaki: /* Provenance */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''<references group="Figure"/>

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a medications list could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation, drug reconciliation, etc. ) and on the type of information reported (e.g. patient-reported medication, prescribed, dispensed or administered medications, active or past medications, etc.).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary. It may be for example the list of all prescribed medicines, whose indicated treatment period has not yet expired, whether they have been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>). It may be a list of only the active ones or a complete history including the full patient's prescription and dispensation history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) or generally a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, the details about the medication order, supply, administration or monitoring the relevant information for an IPS are not relevant. It is important however, to know what medications are being taken by or have been given to a patient, independent to whether they are reported from the patient, another clinician, or derived from supporting information. In any case provenance information is important.

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independent to whether the original source is a prescription or a dispensation list. In fact, in many practical cases data included in a Patient Summary are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these case, data obtained from actual dispensation and/or prescription can be recorded as statements and the original requests, supplies or administration be referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products is quite easily solved within a single jurisdiction relaying on local drugs databases. In contrast, it is one of the major open issues for eHealth services across jurisdictions.

The set of ISO standards call IDMP <ref> https://www.idmp1.com/idmp-standards/ </ref> - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine <ref> http://www.open-medicine.eu/home.html </ref>. The completion of the IDMP implementation guides, the deployment of the needed supporting services, and the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Additional time is needed before these identifiers and attributes will be available in full for practical use.

Following therefore the IPS principles of “implementability”, “openness and extensibility” the solution proposed here does not rely on IDMP identifiers. It takes into account however, relevant IDMP identifiers and attributes already suitable for representing the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides and any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while he PhPID should be the same. For the purpose of the IPS, future standards and implementation guides should define global product identifiers that do not depend on the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and relate to IDMP identifiers.''

Thus, in absence of a global identification system for medicinal products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), reused by the IHE Pharmacy templates and more recently adopted (for specific cases) by the HL7 Pharmacy Medication statement templates. The main idea is to integrate local drug identifiers e.g. product codes, with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients, administrative dose forms, strength, route of administration, and package description.

Medicines data are usually represented in the CDA Templates using the manufacturedMaterial class, which includes a code and a name to describe any level of the product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the requirements of the IPS.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA <references group="Figure"/>

Hence, in order to describe these attributes, an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes of the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed).

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible to have a single representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent future IDMP identifiers and attributes in the IPS and in other document based standards such as SPL.

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model <references group="Figure"/>

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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 provenance, section-level provenance is optional.
*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 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.

Note: 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.

IPS Design conventions and principles 1

2017-07-24T13:17:32Z

Cchronaki: /* Medicinal Product Identification */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''<references group="Figure"/>

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a medications list could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation, drug reconciliation, etc. ) and on the type of information reported (e.g. patient-reported medication, prescribed, dispensed or administered medications, active or past medications, etc.).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary. It may be for example the list of all prescribed medicines, whose indicated treatment period has not yet expired, whether they have been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>). It may be a list of only the active ones or a complete history including the full patient's prescription and dispensation history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) or generally a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, the details about the medication order, supply, administration or monitoring the relevant information for an IPS are not relevant. It is important however, to know what medications are being taken by or have been given to a patient, independent to whether they are reported from the patient, another clinician, or derived from supporting information. In any case provenance information is important.

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independent to whether the original source is a prescription or a dispensation list. In fact, in many practical cases data included in a Patient Summary are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these case, data obtained from actual dispensation and/or prescription can be recorded as statements and the original requests, supplies or administration be referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products is quite easily solved within a single jurisdiction relaying on local drugs databases. In contrast, it is one of the major open issues for eHealth services across jurisdictions.

The set of ISO standards call IDMP <ref> https://www.idmp1.com/idmp-standards/ </ref> - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine <ref> http://www.open-medicine.eu/home.html </ref>. The completion of the IDMP implementation guides, the deployment of the needed supporting services, and the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Additional time is needed before these identifiers and attributes will be available in full for practical use.

Following therefore the IPS principles of “implementability”, “openness and extensibility” the solution proposed here does not rely on IDMP identifiers. It takes into account however, relevant IDMP identifiers and attributes already suitable for representing the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides and any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while he PhPID should be the same. For the purpose of the IPS, future standards and implementation guides should define global product identifiers that do not depend on the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and relate to IDMP identifiers.''

Thus, in absence of a global identification system for medicinal products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), reused by the IHE Pharmacy templates and more recently adopted (for specific cases) by the HL7 Pharmacy Medication statement templates. The main idea is to integrate local drug identifiers e.g. product codes, with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients, administrative dose forms, strength, route of administration, and package description.

Medicines data are usually represented in the CDA Templates using the manufacturedMaterial class, which includes a code and a name to describe any level of the product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the requirements of the IPS.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA <references group="Figure"/>

Hence, in order to describe these attributes, an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes of the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed).

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible to have a single representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent future IDMP identifiers and attributes in the IPS and in other document based standards such as SPL.

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model <references group="Figure"/>

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T12:11:38Z

Cchronaki: /* Medicinal Product Identification */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''<references group="Figure"/>

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a medications list could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation, drug reconciliation, etc. ) and on the type of information reported (e.g. patient-reported medication, prescribed, dispensed or administered medications, active or past medications, etc.).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary. It may be for example the list of all prescribed medicines, whose indicated treatment period has not yet expired, whether they have been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>). It may be a list of only the active ones or a complete history including the full patient's prescription and dispensation history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) or generally a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, the details about the medication order, supply, administration or monitoring the relevant information for an IPS are not relevant. It is important however, to know what medications are being taken by or have been given to a patient, independent to whether they are reported from the patient, another clinician, or derived from supporting information. In any case provenance information is important.

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independent to whether the original source is a prescription or a dispensation list. In fact, in many practical cases data included in a Patient Summary are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these case, data obtained from actual dispensation and/or prescription can be recorded as statements and the original requests, supplies or administration be referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP <ref> https://www.idmp1.com/idmp-standards/ </ref> - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine <ref> http://www.open-medicine.eu/home.html </ref>. The completion of the IDMP implementation guides, the deployment of the needed supporting services, and the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Additional time is needed before these identifiers and attributes will be available in full for practical use.

Following therefore the IPS principles of “implementability”, “openness and extensibility” the solution proposed here does not rely on IDMP identifiers. It takes into account however, relevant IDMP identifiers and attributes already suitable for representing the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides and any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while he PhPID should be the same. For the purpose of the IPS, future standards and implementation guides should define global product identifiers that do not depend on the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and relate to IDMP identifiers.''

Thus, in absence of a global identification system for medicinal products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), reused by the IHE Pharmacy templates and more recently adopted (for specific cases) by the HL7 Pharmacy Medication statement templates. The main idea is to integrate local drug identifiers e.g. product codes, with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients, administrative dose forms, strength, route of administration, and package description.

Medicines data are usually represented in the CDA Templates using the manufacturedMaterial class, which includes a code and a name to describe any level of the product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the requirements of the IPS.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA <references group="Figure"/>

Hence, in order to describe these attributes, an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes of the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed).

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible to have a single representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent future IDMP identifiers and attributes in the IPS and in other document based standards such as SPL.

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T12:09:56Z

Cchronaki: /* Medicinal Product Identification */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''<references group="Figure"/>

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a medications list could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation, drug reconciliation, etc. ) and on the type of information reported (e.g. patient-reported medication, prescribed, dispensed or administered medications, active or past medications, etc.).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary. It may be for example the list of all prescribed medicines, whose indicated treatment period has not yet expired, whether they have been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>). It may be a list of only the active ones or a complete history including the full patient's prescription and dispensation history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) or generally a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, the details about the medication order, supply, administration or monitoring the relevant information for an IPS are not relevant. It is important however, to know what medications are being taken by or have been given to a patient, independent to whether they are reported from the patient, another clinician, or derived from supporting information. In any case provenance information is important.

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independent to whether the original source is a prescription or a dispensation list. In fact, in many practical cases data included in a Patient Summary are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these case, data obtained from actual dispensation and/or prescription can be recorded as statements and the original requests, supplies or administration be referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP <ref> https://www.idmp1.com/idmp-standards/ </ref> - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine <ref> http://www.open-medicine.eu/home.html </ref>. The completion of the IDMP implementation guides, the deployment of the needed supporting services, and the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Additional time is needed before these identifiers and attributes will be available in full for practical use.

Following therefore the IPS principles of “implementability”, “openness and extensibility” the solution proposed here does not rely on IDMP identifiers. It takes into account however, relevant IDMP identifiers and attributes already suitable for representing the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides and any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while he PhPID should be the same. For the purpose of the IPS, future standards and implementation guides should define global product identifiers that do not depend on the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and relate to IDMP identifiers.''

Thus, in absence of a global identification system for medicinal products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), reused by the IHE Pharmacy templates and more recently adopted (for specific cases) by the HL7 Pharmacy Medication statement templates. The main idea is to integrate local drug identifiers e.g. product codes, with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients, administrative dose forms, strength, route of administration, and package description.

Medicines data are usually represented in the CDA Templates using the manufacturedMaterial class, which includes a code and a name to describe any level of the product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the requirements of the IPS.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to describe these attributes, an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes of the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed).

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible to have a single representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent future IDMP identifiers and attributes in the IPS and in other document based standards such as SPL.

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T11:49:31Z

Cchronaki: /* The use of medication statements in the summary */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''<references group="Figure"/>

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a medications list could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation, drug reconciliation, etc. ) and on the type of information reported (e.g. patient-reported medication, prescribed, dispensed or administered medications, active or past medications, etc.).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary. It may be for example the list of all prescribed medicines, whose indicated treatment period has not yet expired, whether they have been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>). It may be a list of only the active ones or a complete history including the full patient's prescription and dispensation history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) or generally a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, the details about the medication order, supply, administration or monitoring the relevant information for an IPS are not relevant. It is important however, to know what medications are being taken by or have been given to a patient, independent to whether they are reported from the patient, another clinician, or derived from supporting information. In any case provenance information is important.

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independent to whether the original source is a prescription or a dispensation list. In fact, in many practical cases data included in a Patient Summary are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these case, data obtained from actual dispensation and/or prescription can be recorded as statements and the original requests, supplies or administration be referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.

Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.''

Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.

Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, which includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T11:38:13Z

Cchronaki: /* Determining the Status of Clinical Statement */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''<references group="Figure"/>

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a list of medications could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation; drug reconciliation;. ) and on the type of information reported (e.g. patient-reported medication; prescribed, dispensed or administered medications; active or past medications).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary: it may be for example the list of all relevant prescribed medicines whose period of time indicated for the treatment has not yet expired whether it has been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>); a list of only the active one or a complete history including full patient's prescription and dispense history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) ; or generically a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, are not the details about the medication order, supply , administration or monitoring the relevant information for an IPS, rather it is important to know what medications are being taken by or have been given to a patient; independently by the fact they are reported from the patient or another clinician, or derived from supporting information (provenance information are in any case important).

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independently by the fact the original source might be a prescription or a dispensation list. In fact in many practical cases data included in the Patient Summaries are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these cases data obtained from actual dispensations and/or prescriptions can be recorded as statements and the original requests, supplies or administrations referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.

Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.''

Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.

Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, which includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T11:36:48Z

Cchronaki: /* Determining the Status of Clinical Statement */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''<references group="Figure" name="concernact"/>

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a list of medications could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation; drug reconciliation;. ) and on the type of information reported (e.g. patient-reported medication; prescribed, dispensed or administered medications; active or past medications).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary: it may be for example the list of all relevant prescribed medicines whose period of time indicated for the treatment has not yet expired whether it has been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>); a list of only the active one or a complete history including full patient's prescription and dispense history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) ; or generically a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, are not the details about the medication order, supply , administration or monitoring the relevant information for an IPS, rather it is important to know what medications are being taken by or have been given to a patient; independently by the fact they are reported from the patient or another clinician, or derived from supporting information (provenance information are in any case important).

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independently by the fact the original source might be a prescription or a dispensation list. In fact in many practical cases data included in the Patient Summaries are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these cases data obtained from actual dispensations and/or prescriptions can be recorded as statements and the original requests, supplies or administrations referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.

Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.''

Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.

Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, which includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T11:29:56Z

Cchronaki: /* Determining the Status of Clinical Statement */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting the status of a clinical statement.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy, or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of status that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have been resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was considered a concern. It may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time", is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance was biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

'''Confirmation status'''

The confirmation status, also noted as verification status or certainty, indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a list of medications could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation; drug reconciliation;. ) and on the type of information reported (e.g. patient-reported medication; prescribed, dispensed or administered medications; active or past medications).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary: it may be for example the list of all relevant prescribed medicines whose period of time indicated for the treatment has not yet expired whether it has been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>); a list of only the active one or a complete history including full patient's prescription and dispense history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) ; or generically a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, are not the details about the medication order, supply , administration or monitoring the relevant information for an IPS, rather it is important to know what medications are being taken by or have been given to a patient; independently by the fact they are reported from the patient or another clinician, or derived from supporting information (provenance information are in any case important).

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independently by the fact the original source might be a prescription or a dispensation list. In fact in many practical cases data included in the Patient Summaries are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these cases data obtained from actual dispensations and/or prescriptions can be recorded as statements and the original requests, supplies or administrations referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.

Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.''

Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.

Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, which includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T11:19:29Z

Cchronaki: /* Narrative Translations */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
Moreover, the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

Considering that only one <text> element is allowed for a section, the solution suggested by this guide is to document the narrative translation into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting a clinical statement’s status.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures; records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are inter-related: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of statuses that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was felt to be a concern; it may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time" is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance became biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

'''Confirmation status'''

The confirmation status, also indicated as verification status, or certainty indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a list of medications could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation; drug reconciliation;. ) and on the type of information reported (e.g. patient-reported medication; prescribed, dispensed or administered medications; active or past medications).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary: it may be for example the list of all relevant prescribed medicines whose period of time indicated for the treatment has not yet expired whether it has been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>); a list of only the active one or a complete history including full patient's prescription and dispense history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) ; or generically a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, are not the details about the medication order, supply , administration or monitoring the relevant information for an IPS, rather it is important to know what medications are being taken by or have been given to a patient; independently by the fact they are reported from the patient or another clinician, or derived from supporting information (provenance information are in any case important).

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independently by the fact the original source might be a prescription or a dispensation list. In fact in many practical cases data included in the Patient Summaries are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these cases data obtained from actual dispensations and/or prescriptions can be recorded as statements and the original requests, supplies or administrations referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.

Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.''

Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.

Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, which includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T11:15:59Z

Cchronaki: /* Mapped coded concepts */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to multi-coding, the preservation of the link to the original text, and the mapping between codes in the same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides multiple mappings. In this case, it should be noted if the primary code is the one belonging to the reference value set.
If not, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original term and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems. There is however a common understanding that “it may be more than one representation in a single code system where code systems allow multiple representations, such as SNOMED-CT”. Datatype R2 extended the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed; and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] section, and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
It would be moreover good if the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be recognizable.

Considering that only one <text> element is allowed for section, the solution suggested by this guide is to document the narrative translations into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting a clinical statement’s status.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures; records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are inter-related: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of statuses that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was felt to be a concern; it may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time" is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance became biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

'''Confirmation status'''

The confirmation status, also indicated as verification status, or certainty indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a list of medications could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation; drug reconciliation;. ) and on the type of information reported (e.g. patient-reported medication; prescribed, dispensed or administered medications; active or past medications).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary: it may be for example the list of all relevant prescribed medicines whose period of time indicated for the treatment has not yet expired whether it has been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>); a list of only the active one or a complete history including full patient's prescription and dispense history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) ; or generically a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, are not the details about the medication order, supply , administration or monitoring the relevant information for an IPS, rather it is important to know what medications are being taken by or have been given to a patient; independently by the fact they are reported from the patient or another clinician, or derived from supporting information (provenance information are in any case important).

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independently by the fact the original source might be a prescription or a dispensation list. In fact in many practical cases data included in the Patient Summaries are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these cases data obtained from actual dispensations and/or prescriptions can be recorded as statements and the original requests, supplies or administrations referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.

Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.''

Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.

Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, which includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T11:09:11Z

Cchronaki: /* Uncoded information */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE (coded no extensions) and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to the multiple coding; the preservation of the link to the original text; the mapping between a same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides a multiple mapping. In this case if the primary code is one belonging to the reference value set noting should be done.
If not, as in the example below, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems.. There is however a common understanding that it “may be more than on representation in a single code system where code systems allow multiple representations, such as Snomed-CT”. Datatype R2 extended in fact the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed; and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] section, and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
It would be moreover good if the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be recognizable.

Considering that only one <text> element is allowed for section, the solution suggested by this guide is to document the narrative translations into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting a clinical statement’s status.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures; records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are inter-related: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of statuses that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was felt to be a concern; it may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time" is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance became biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

'''Confirmation status'''

The confirmation status, also indicated as verification status, or certainty indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a list of medications could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation; drug reconciliation;. ) and on the type of information reported (e.g. patient-reported medication; prescribed, dispensed or administered medications; active or past medications).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary: it may be for example the list of all relevant prescribed medicines whose period of time indicated for the treatment has not yet expired whether it has been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>); a list of only the active one or a complete history including full patient's prescription and dispense history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) ; or generically a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, are not the details about the medication order, supply , administration or monitoring the relevant information for an IPS, rather it is important to know what medications are being taken by or have been given to a patient; independently by the fact they are reported from the patient or another clinician, or derived from supporting information (provenance information are in any case important).

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independently by the fact the original source might be a prescription or a dispensation list. In fact in many practical cases data included in the Patient Summaries are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these cases data obtained from actual dispensations and/or prescriptions can be recorded as statements and the original requests, supplies or administrations referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.

Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.''

Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.

Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, which includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Design conventions and principles 1

2017-07-24T11:02:12Z

Cchronaki: /* Representing "known absent" and "not known" */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated above, to be universally exchangeable the International Patient Summary must rely on international multilingual reference terminologies. To that effect, each codeable element of the international patient summary template is bound to a Value Set built upon an international reference terminology, such as SNOMED CT, LOINC, UCUM, EDQM Standard Terms. These reference terminologies have been selected to provide the preferred bindings for the codeable elements of the patient summary. They are the '''primary terminologies''' of this specification.

Nevertheless, it is anticipated that in some situations, a system producing an instance of patient summary might not support one or the other of these primary terminologies, supporting only a local interface terminology instead. Similarly, it is also anticipated that the receiving system might in some cases not be able to use a code in a patient summary, either because this code belongs to a primary terminology that the receiving system does not support or because this code belongs to an interface terminology specific to the country of the producing system.

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:
* The Primary Code of a codeable element should be populated.
* If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
* The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
* When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
* One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.
===Alternate Code===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.
===Original Text===
In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

==Representing "known absent" and "not known" ==

In line with the properties of minimalism and non-exhaustiveness for the IPS (see the IPS definition above), and benefiting from the experience acquired with the European cross-borders services, this guide explicitly addresses two general situations:
# condition or activity unknown
#condition or activity known absent.

Other kinds of negations such as: (a) the negation of an allergy to a specific agent; (b) the absence of a particular disease; or (c) the fact that a specific vaccination has not been performed, have been considered beyond the set of essential data for an IPS.

This specification represents this core set of negations (“condition/activity unknown” and “condition/activity known absent” ) by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes.

The main reasons for this choice are:
* @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
* 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).
* 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.

In some cases, this required 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)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

For the other kinds of negations, not explicitly mentioned in this guide, it is suggested to apply – where possible – the same approach.
Future versions of this guide may extend the number of cases covered and include new coded concepts for supporting them.

==Uncoded information==

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information.
This may happen for two reasons:
# the originator is not able to express the concept in the reference value sets;
# the originator is not able to express the concept in any known terminology.

The first case, assuming that the coding strength is CNE (coded, no extensions), is represented in this guide with the following assertion:

<syntaxhighlight lang="xml">
<code codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH">
<originalText>
<reference value="#ref1"/>
</originalText>
</code>
</syntaxhighlight>

That is expressing that there are no codes applicable in the referred code system (in the example SNOMED CT). Please note that according to this guide the text is documented in the section narrative and only referenced by the coded element.

''Note: Datatype R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.''

The second case, that applies both to CNE and CWE (coded with extensions) coding strengths, is instead here represented valuing the coded element with the most generic nullFlavor “NI” (No Information) and pointing the text in the section narrative:

<syntaxhighlight lang="xml">
<value xsi:type="CD" nullFlavor="NI">
<originalText>
<reference value="#ref1"/>
</originalText>
</value>
</syntaxhighlight>

''Note: the most proper nullFlavor to be used here would be "UNC" (Uncoded) but this code is not part of the nullFlavors foreseen by the CDA R2 standard.''

== Unmapped Coded Concepts ==

In several real world situations the records used as source for the Patient Summaries may use locally adopted terminologies mapped into the reference value sets. When the original coded concept cannot be mapped in one of the coded concepts included in the reference value sets, is recommended that the original code is reported in the IPS instance as well as the indication that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.)

Two circumstances are here considered: the case in which the coding strength is CNE and when it is CWE.

In the case of coding strength CNE the following statement can be used to express that no appropriate target coded concepts were found:

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”OTH”>
[
<originalText>
<reference value='#ref1'/>
</originalText>
]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3"
displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

''Note: It may happen that a mapping would be possible in the target code system, but not in the target value set; datatype R1 doesn't allow to specify this difference, that is that there are no codes applicable in the reference value set, as instead possible with datatype R2. Future versions of this guide may consider extending the datatype to better support this situation.
''

Even if, in case of CWE coding strength, it would be allowed to leave the original code as the primary code, this guide suggests that to highlight that a mapping to the reference value set was attempted and no suitable target codes were identified, it is recommended to represent the original code in the <translation> sub-element and value with a nullFlavor the main coded element.

<syntaxhighlight lang="xml">
<value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor=”NI”>
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="A02.9" codeSystem="2.16.840.1.113883.6.3" displayName="Infezioni da Salmonella non specificate"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

== Mapped coded concepts ==

As mentioned above in several circumstances an original coded concept is mapped into the reference value sets. When this occurs, both the original and the reference codes should be reported in the IPS instance.
Other conditions that should be considered are described in the [[#Concept code mapping| Concept code mapping]] in the functional requirements section, and refer to the multiple coding; the preservation of the link to the original text; the mapping between a same code system.

All those aspects are considered in this section.

The simplest situation is the case of a single code mapped into a reference one, with original and reference codes belonging to different code systems. Hereafter the way to represent it:

<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

''The square brackets [ ] are used to indicate that the originalText element may or may not be present''

<br/> The second example is the case in which the originator provides a multiple mapping. In this case if the primary code is one belonging to the reference value set noting should be done.
If not, as in the example below, all the original primary and alternate coded concepts are represented in a nested translation element, as described by the following example:

<syntaxhighlight lang="xml">
<value code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2" xsi:type="CD">
<originalText><reference value="#problem4name"/></originalText>
<translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/>
<translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM"displayName="Malignant neoplasm of unspecified site of unspecified female breast"/>
</translation>
</value>
</syntaxhighlight>

<br/>
The third case is when the original and the reference coded concepts belong to the same code system (distinct codes). This may be the result of a different level of granularity between the original and the reference value sets.

<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact "/>
</code>
</syntaxhighlight>

''Note: the R1 datatype definition identifies the <translation> as “a set of other concept descriptors that translate this concept descriptor into other code systems.. There is however a common understanding that it “may be more than on representation in a single code system where code systems allow multiple representations, such as Snomed-CT”. Datatype R2 extended in fact the possibility to provide translations also in the same code system.''

== Translation of designations ==

The capability of recording one or more designations, in different languages, for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services (see [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] for more details).

It is known that there is not a “native” way to convey this kind of information using the coded descriptor (and derived) datatypes, in fact the @displayName attribute has cardinality 0...1 and the <translation> was designed for the coding translation, “that is to translate this concept descriptor into other code systems” and not for the translation of designations.

For this reason it is suggested to introduce an optional extension to the CD datatype that allows to convey both the designations and thier languages. Hereafter some examples of possible use of this extension in case of

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<ips:designation lang=”it-IT” value="Profilo Sanitario Sintetico" />
<ips:designation lang=”fr-FR” value="Patient Summary" />
<ips:designation lang=”en” value="Patient Summary" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
<ips:designation lang=”da-DK” value=" Salmonella-gastroenterit" />
<ips:designation lang=”en” value="Salmonella gastroenteritis (disorder)" type=”FSN” />
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
</value>
</syntaxhighlight>

----

''Note for balloters: <br/>
The team also discussed about the possibility of avoiding extensions allowing a flexible use of the <translation> element.
Hereafter some usage examples.
The two options evaluated are not mutually exclusive.''

''No code mapping''
<syntaxhighlight lang="xml">
<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
<translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" />
</code>
</syntaxhighlight>

''Codes mapping''
<syntaxhighlight lang="xml">
<value xsi:type=”CD” code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenterit">
[ <originalText><reference value='#ref1'/></originalText>]
<translation code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis">
<translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/>
<translation />
</value>
</syntaxhighlight>

----

== Narrative Translations ==

With “narrative translation” is meant both the translation of the original narrative text, that can be human curated or automatically performed; and the generation of a translated narrative based on the coded entries.

The functional requirements associated to this process are described in the [[#Designations’ Translation| Designations’ Translation]] under the [[#Functional requirements and high-level use cases | Functional requirements and high-level use cases ]] section, and can be summarized in two main points : (a) language identification and (b) distinguishable original and translated narratives.
It would be moreover good if the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be recognizable.

Considering that only one <text> element is allowed for section, the solution suggested by this guide is to document the narrative translations into subordinate sections (one for translation) as described by the template 2.16.840.1.113883.10.22.3.15.

Hereafter an example:

<syntaxhighlight lang="xml">
<section>
<templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
<id root="1.2.3.999" extension="--example only--"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies and Intolerances</title>
<text>No known Allergies</text>

<component>
<section>

<title>Allergie ed Intolleranze</title>
<text>Nessuna Allergia Nota</text>
<languageCode code="it-IT"/>
</section>
</component>
</section>
</syntaxhighlight>

== Determining the Status of Clinical Statement ==

''Note: most of the description provided in this section is copied from the § 3.3 Determining the Status of Clinical Statement of the C-CDA DSTU R2.1 Implementation Guide Volume 1 <ref> HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects.
The following principles apply when representing or interpreting a clinical statement’s status.
*The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
*Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures; records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
*Act.statusCode and Act.effectiveTime are inter-related: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

The IPS Problem Concern Entry and the IPS Allergy and Intolerance Concern templates reflect an ongoing concern on behalf of the provider that placed the concern (e.g. a disease, an allergy or other conditions) on a patient’s problem or allergy list.
The purpose of the concern act is that of supporting the tracking of a problem or a condition (e.g. an allergy).
A concern act can contain one or more discrete observations related to this concern. Each of them reflects the change in the clinical understanding of a condition over time. For instance, a Concern may initially contain a symptom of “chest pain”, later identified as consequence of a gastroesophageal reflux. The later problem observation will have a more recent author time stamp.

There are different kinds of statuses that could be of clinical interest for a condition:
*The status of the concern (active, inactive,..)
*The status of the condition (e.g. active, inactive, resolved,..)
*The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

Not all of them can be represented in a CDA using the statusCode elements of the concern (ACT) and observation (condition).

'''Status of the concern and related times'''

The statusCode of the Problem Concern Act is the definitive indication of the status of the concern. So long as the provider has an ongoing concern — meaning that the provider is monitoring the condition, whether it includes problems that have resolved or not — the statusCode of the Concern Act is “active.” When the underlying conditions are no longer an active concern, the statusCode of the Problem Concern Act is set to “completed.”

The Concern Act effectiveTime reflects the time that the underlying condition was felt to be a concern; it may or may not correspond to the effectiveTime of the condition (e.g., even five years later, the clinician may remain concerned about a prior heart attack).
The effectiveTime/low of the Concern Act asserts when the concern became active. This equates to the time the concern was authored in the patient's chart. (i.e. it should be equal to the earliest author time stamp)
The effectiveTime/high asserts when the concern become inactive, and it is present if the statusCode of the concern act is "completed".

'''Status of the condition and related times'''

Each Observation contained by a Concern Act is a discrete observation of a condition. Its statusCode is always “completed” since it is the “status of the activity of observing, not the status of what is being observed”.
The clinical status of a condition (e.g. a disease, an allergy,..) is instead recorded by specialised subordinated observations (IPS Allergy Status Observation; IPS Problem Status Observation), documenting whether it is active, in remission, resolved, et cetera.
The effectiveTime, also referred to as the "biologically relevant time" is the time at which the observation holds for the patient. For a provider seeing a patient in the clinic today, observing a history of penicillin allergy that developed six months ago, the effectiveTime is six months ago.
The effectiveTime of the Observation gives an indication of whether or not the underlying condition is resolved, but the current status is documented by a subordinated observation.
The effectiveTime.low The effectiveTime/low (a.k.a. "onset date") asserts when the allergy/intolerance became biologically active.
The effectiveTime/high (a.k.a. "resolution date") asserts when the allergy/intolerance became biologically resolved. If the date of resolution is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

{{IncludeImage|IPS ProblemActConcern.png|600px|90%}}
<ref group="Figure" name="concernact">Problem Concern Act (from C-CDA IG DTSU R2.1)</ref> Problem Concern Act (from C-CDA IG DTSU R2.1)<ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>''

'''Confirmation status'''

The confirmation status, also indicated as verification status, or certainty indicates the certainty associated with a condition (e.g. confirmed, provisional, refuted,…) providing information about the potential risk, for example, of a reaction to the identified substance.
The confirmation status of a condition (e.g. a disease, an allergy,..) is recorded by a specialised subordinated observation (IPS certainty Observation), documenting whether the condition is it is confirmed, unconfirmed, provisional, refuted, et cetera.

== The use of medication statements in the summary ==

What a list of medications could be may strongly vary depending on the context of use (e.g. support for prescription or dispensation; drug reconciliation;. ) and on the type of information reported (e.g. patient-reported medication; prescribed, dispensed or administered medications; active or past medications).

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary: it may be for example the list of all relevant prescribed medicines whose period of time indicated for the treatment has not yet expired whether it has been dispensed or not (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>); a list of only the active one or a complete history including full patient's prescription and dispense history and information about intended drug monitoring (C-CDA <ref>HL7 C-CDA Implementation Guide DSTU R2.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379</ref>) ; or generically a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>).

Considering the scope of the IPS however, are not the details about the medication order, supply , administration or monitoring the relevant information for an IPS, rather it is important to know what medications are being taken by or have been given to a patient; independently by the fact they are reported from the patient or another clinician, or derived from supporting information (provenance information are in any case important).

This information need, in line with the IPS principle of minimum non exhaustive data, is well expressed by the concept of Medication Statement (see https://www.hl7.org/fhir/medicationstatement.html).

The medication summary will be therefore a list of "relevant" medication statements, independently by the fact the original source might be a prescription or a dispensation list. In fact in many practical cases data included in the Patient Summaries are derived from the list of actually prescribed medicines recorded in the GP EHR-S or in regional/national prescribing systems. In these cases data obtained from actual dispensations and/or prescriptions can be recorded as statements and the original requests, supplies or administrations referred in the statement if really needed.

==Medicinal Product Identification==

The identification of medicinal products – that in general is quite-easily solved within a single jurisdiction relaying on local drugs databases – is instead one of the major still open issue for cross-jurisdictional services.

The set of ISO standards call IDMP [ref] - designed initially for the regulatory scopes, but hopefully extensible to other domains- are the most promising solution for solving this known issue as also highlighted by the European project OpenMedicine [ref]. The completion of the IDMP implementation guides; the deployment of the needed supporting services; the development of some companion standards that will allow the seamless flow of the IDMP identifiers and attributes from the regulatory space to the clinical world (and back) are however still in progress. Some further years are needed before these identifiers and attributes will be available for actual use.

Following therefore the IPS principles of “implementability” and “openness and extensibility” the solution here proposed will not then rely on the IDMP identifiers; being however already suitable for representing the IPS relevant IDMP identifiers and attributes: e.g. Pharmaceutical Product Identifiers (PhPIDs); Medicinal Product Identifier (MPID); Medicinal Product Package Identifier (PCID).

''Note for ballotters: IPS members had no access to the latest version of the IDMP implementation guides; any indication that may help the alignment with those standards would be appreciated.''

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depends on the market authorization, the “same” product might therefore have different IDs if different authorizations have been required in different countries (the PhPID should be however the same). For the purpose of the IPS it might be useful if in future standards will be defined new global product identifiers that are independent by the drug registration process (as the Virtual Medicinal Product in SNOMED CT) and related to the IDMP identifiers.''

Thus, in absence of a global identification system for products, the solution here proposed is based on the approach initially adopted by the European cross-border services (epSOS and currently by the eHDSI project), then reused by the IHE Pharmacy templates and more recently adopted (for specific cases) also by the HL7 Pharmacy Medication statement templates. The main idea is in fact that of integrating possible local drug identifiers (e.g. product codes) with all the relevant identifying and descriptive attributes that may help the receiver to understand the type of product the sender is referring to, e.g.: active ingredients; (administrable) dose forms; strengths; route of administration; package description.

Medicines data are usually represented in the CDA Templates using the class manufacturedMaterial, which includes a code and a name used for describing any level of product: packaged product, medicinal product, classes or clusters or products, and so on. This information is not however sufficient for covering the defined needs.

{{IncludeImage|IPS_CDA_SBDAM.png|700px|90%}}

<ref group="Figure">Representation of medicines in CDA</ref> Representation of medicines in CDA

Hence, in order to be able to describe these attributes an extension of the CDA model needs to be applied and this was done in epSOS enhancing the Manufactured Product and Material classes from the CDA model with the attributes and relationships derived from the Medication and Medicine classes from the R_Medication CMET.

The same design approach has been followed for this guide adopting the Common Product Model (R_ProductListed) instead.

This choice has been made:
* considering the expected use of this model (“The common product model is used to improve the alignment between the different representations of products used within the body of HL7 Version 3 models. One goal of this effort is to make it possible for there to be a single such representation, which could then be used as a common message element type (CMET) across those models.”)
* to eventually have a common implementable solution to represent the future IDMP identifiers and attributes in the IPS and in other document based standards (as SPL).

<ref group="Figure" name="cdacpm"/> shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

{{IncludeImage|IPS_CMP_model.png|700px|90%}}

<ref group="Figure" name="cdacpm">CDA model has been enhanced with the Common Product Model</ref> CDA model and the Common Product Model

== Provenance ==

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 [[IPS_implementationguide_1#Scope|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.

 Giorgio</del>
*(Authorship is probably a part to go to Provenance)
-->

IPS Functional requirements 1

2017-07-24T10:49:21Z

Cchronaki: /* Functional requirements and high-level use cases */

=Functional requirements and high-level use cases=

Several use cases may be identified for the International Patient Summary within its scope (“specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care”). Section [[#Examples (in progress)|Examples (in progress)]] provides examples of some real world user stories for the cross-border care developed by the [http://www.trilliumbridge.eu Trillium Bridge Project ] and by the [http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative S&I EU-US eHealth Cooperation Initiative ] in the scope of the EU/US Roadmap initiative.

The cross-border care is not however the only expected usage scenario for the IPS. Some European countries have already manifested their interest on the IPS work for their future national Patient Summary for unscheduled care. Patient summary initiatives are currently in various stages of development in other parts of the world.

As shown by the user stories there are several possible options for the IPS in terms of creation, sharing and usage of an IPS. For example:
#an IPS could be a created when requested and used (before or during a care episode); or can be asynchronously generated and made available for future usage (e.g. store and retrieve).
#the IPS can be retrieved using a document exchange infrastructure; transported by the patient; or shared using cloud-services.
#the IPS may be subject of a transformation process, that may include syntactical conversions; coded concepts mappings and coded concept designation or free text translations. This transformation process may be performed in the creation phase, during the transmission, or after it has been received possibly using an external service.
#Finally, the received CDA may be displayed using a common CDA stylesheet; may be used to extract some relevant information to be displayed by the EHR-S or to be incorporated into the receiver’s EHR. Alternatively, a specialized viewer may be adopted to enable the display of the translated content.

Moreover for exchange cross-jurisdiction, the IPS could be used as:
#shared format among jurisdictions (case A), where jurisdictions originate and use IPS conforming documents as is.
#pivot document among existing summaries / data formats (case B), where IPS is used as intermediate format between the US C-CDA CCD (Please note that the CCD scope differs from that of the IPS) and the European eHDSI Patient Summary for a Transatlantic Patient Summary exchange.
#mixed mode (Case C), where either the originator or the consumer is expected to use an IPS conforming document.

[[File:IPS_cases.png|none|600px]]
<ref group="Figure">Examples of IPS usage </ref> Examples of IPS usage <references group="Figure"/>
Considering all those possible combinations and additional business requirements agreed by jurisdictions, there are several technical infrastructures and services that may be designed to support these requirements.

It is out of scope of this standard to provide any indication about solutions and strategies for the IPS creation, sharing, syntactical and semantic mapping, translation, and use.

Having said that an International Patient Summary may:
#be the result of automatic assembly (assembled IPS) or of a human summarization act (human curated IPS)
#have one or more EHR sources
#document information from a single or multiple jurisdictions/organizations
#be aggregate input from a single or multiple encounters

A clear determination of such contextual information helps the receiver comprehend and the attest to the trustworthiness on the received IPS. Most of these aspects are related to data provenance, introduced in section [[#Provenance | Provenance]] above.

Even if in many jurisdictions require that only one active Patient Summary for unscheduled care would be made available, no constraints are imposed or assumed by this guide as this strongly depends on the particular use case.

Moreover it is also out of scope for this guide to:
*provide guidance on how to determine the relevance of data for their inclusion in a IPS;
*define selection or composition rules for facing potential inconsistencies from multiple sources in case of automatic collection.

== Code mappings and multilingual support ==
The capability of managing locally used coded concepts and reference terminologies, and that of providing receiving providers with human readable information in a language that can be understood by them, are critical aspects to be taken in account in the cross-border sharing of documents.
This section summarizes some of the requirements related to these aspects, including also additional needs derived from the European cross-border services and some lessons learned by the EU/US Trillium Bridge Project.
The European cross-border services (eHDSI see link to eHDSI) use a business to business exchange infrastructure based on a network of country gateways that mediate access to the national infrastructures. The eHDSI Patient Summary (eHDSI PS) is used as a “pivot” document for the cross-border exchange. Local PS using data/document formats are in fact remapped into the eHDSI PS. The document exchanged is processed each time it passes through one of these gateway applying the needed syntactical transformation, codes mapping. and codes designations’ translation. Finally, in the current practice the received PSs are displayed using specialized display tools that build a human readable representation of the PS in the target language using the translated designations reported in the coded entries.
The adoption of translated narratives in the received document has been one of the indications received by the Trillium Bridge Project. This in fact allows extending multilingual support for the cross-border patient summaries to a wider set of potential consumers (EHR-or PHR systems), without requiring specialized viewers as applied in the eHDSI services.

=== Concept code mapping===
In several real world use cases the records used as source for the Patient Summaries may use locally adopted terminologies that – when possible – are remapped into the reference value sets or may be used as is to provide only uncoded information.
This leads to a series of requirements for the IPS that will be discussed in the [[#Design conventions and principles| Design conventions and principles]] section.
*When the original coded concept is mapped in one of the coded concepts included in the reference value sets called hereafter reference code/coded concept, both the original and the reference codes should be reported in the IPS instance.
*When the original coded concept is not mapped to one of the coded concepts included in the reference value sets, the original code should be reported in the IPS instance as well as the indication that mapping was not successful.
*When the original record, for a specific coded element, is not able to provide coded but only textual information, this information should be reported in the IPS instance.

Moreover it should be taken into account that:
*The original record may support multi-coding, so that the IPS instance should be able to distinguish if the additional codes belong to the original content or they are the result of post-hoc concept code mapping.
*The original record may include references to the pieces of text the coding was derived from, if present, the IPS instance should preserve this link between the original code and the referred text.
*Distinct original and reference coded concepts may belong to the same code system. This may be the result of a different level of granularity between the original and the reference value sets, or the result of format transformation e.g. CCD document is used as input for generating an IPS. For these cases the requirement of recording both coded concepts should be applied.

''Note: in some jurisdictions as the European Cross-border services, some of these "should" may be turned into a "shall".''

=== Multilingual support ===

The debate on multilingual support for the IPS could be split in two distinct subjects:
#The translation of coded concept designations (displayName)
#The translation of the narrative
In both cases several options may be identified depending also on the use cases considered:
*The translation to the language of the receiving country: an IPS is prepared before a planned travel; a foreign provider retrieves a translated copy of the IPS from the patient's country of affiliation…
*The translation into a commonly agreed language, e.g. an English version of the IPS is prepared.
*The predefined set of translations is included in the shared IPS.
It is out of the scope of this guide to suggest any of these solutions: all of them should be supported by this standard.

==== Translation of Designations====
Basically, the requirements related to the translation of the designations derive from the European Cross-border services functional requirements that for “safety and liability reasons” all the original coded terms (designations, displayName) shall be recorded in the exchanged documents together with at least the English and the receiving country language terms (designations, displayName) associated to the reference codes. The designations translated in the receiving country language are used to generate the human readable content shown to the receiving provider. No free text translation is applied in this case.
In order to accomplish this objective, the IPS should have the capability to record one or more designations, possibly indicating the language used.

==== Narrative Translation ====
With the term narrative translation two different concepts are covered:
*The translation of the original narrative text. This can be in principle:
**Human curated
**Automatically performed (e.g. using specialized or generic translation services)
**Creation of a new translated narrative based on the coded entries.

Different levels of quality and liability can be obtained depending on the solution adopted and on the translation service used.
It is out of the scope of this guide to suggest any of these solutions, in all the cases however:
*the language of the narrative should be identifiable
*the original and the translated narrative should be clearly distinguished
*the translation methodology applied (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

IPS Functional requirements 1

2017-07-24T10:48:07Z

Cchronaki: /* Functional requirements and high-level use cases */

=Functional requirements and high-level use cases=

Several use cases may be identified for the International Patient Summary within its scope (“specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care”). Section [[#Examples (in progress)|Examples (in progress)]] provides examples of some real world user stories for the cross-border care developed by the [http://www.trilliumbridge.eu Trillium Bridge Project ] and by the [http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative S&I EU-US eHealth Cooperation Initiative ] in the scope of the EU/US Roadmap initiative.

The cross-border care is not however the only expected usage scenario for the IPS. Some European countries have already manifested their interest on the IPS work for their future national Patient Summary for unscheduled care. Patient summary initiatives are currently in various stages of development in other parts of the world.

As shown by the user stories there are several possible options for the IPS in terms of creation, sharing and usage of an IPS. For example:
#an IPS could be a created when requested and used (before or during a care episode); or can be asynchronously generated and made available for future usage (e.g. store and retrieve).
#the IPS can be retrieved using a document exchange infrastructure; transported by the patient; or shared using cloud-services.
#the IPS may be subject of a transformation process, that may include syntactical conversions; coded concepts mappings and coded concept designation or free text translations. This transformation process may be performed in the creation phase, during the transmission, or after it has been received possibly using an external service.
#Finally, the received CDA may be displayed using a common CDA stylesheet; may be used to extract some relevant information to be displayed by the EHR-S or to be incorporated into the receiver’s EHR. Alternatively, a specialized viewer may be adopted to enable the display of the translated content.

Moreover for exchange cross-jurisdiction, the IPS could be used as:
#shared format among jurisdictions (case A), where jurisdictions originate and use IPS conforming documents as is.
#pivot document among existing summaries / data formats (case B), where IPS is used as intermediate format between the US C-CDA CCD (Please note that the CCD scope differs from that of the IPS) and the European eHDSI Patient Summary for a Transatlantic Patient Summary exchange.
#mixed mode (Case C), where either the originator or the consumer is expected to use an IPS conforming document.

[[File:IPS_cases.png|none|600px]]
<ref group="Figure">Examples of IPS usage Examples of IPS usage <references group="Figure"/>
Considering all those possible combinations and additional business requirements agreed by jurisdictions, there are several technical infrastructures and services that may be designed to support these requirements.

It is out of scope of this standard to provide any indication about solutions and strategies for the IPS creation, sharing, syntactical and semantic mapping, translation, and use.

Having said that an International Patient Summary may:
#be the result of automatic assembly (assembled IPS) or of a human summarization act (human curated IPS)
#have one or more EHR sources
#document information from a single or multiple jurisdictions/organizations
#be aggregate input from a single or multiple encounters

A clear determination of such contextual information helps the receiver comprehend and the attest to the trustworthiness on the received IPS. Most of these aspects are related to data provenance, introduced in section [[#Provenance | Provenance]] above.

Even if in many jurisdictions require that only one active Patient Summary for unscheduled care would be made available, no constraints are imposed or assumed by this guide as this strongly depends on the particular use case.

Moreover it is also out of scope for this guide to:
*provide guidance on how to determine the relevance of data for their inclusion in a IPS;
*define selection or composition rules for facing potential inconsistencies from multiple sources in case of automatic collection.

== Code mappings and multilingual support ==
The capability of managing locally used coded concepts and reference terminologies, and that of providing receiving providers with human readable information in a language that can be understood by them, are critical aspects to be taken in account in the cross-border sharing of documents.
This section summarizes some of the requirements related to these aspects, including also additional needs derived from the European cross-border services and some lessons learned by the EU/US Trillium Bridge Project.
The European cross-border services (eHDSI see link to eHDSI) use a business to business exchange infrastructure based on a network of country gateways that mediate access to the national infrastructures. The eHDSI Patient Summary (eHDSI PS) is used as a “pivot” document for the cross-border exchange. Local PS using data/document formats are in fact remapped into the eHDSI PS. The document exchanged is processed each time it passes through one of these gateway applying the needed syntactical transformation, codes mapping. and codes designations’ translation. Finally, in the current practice the received PSs are displayed using specialized display tools that build a human readable representation of the PS in the target language using the translated designations reported in the coded entries.
The adoption of translated narratives in the received document has been one of the indications received by the Trillium Bridge Project. This in fact allows extending multilingual support for the cross-border patient summaries to a wider set of potential consumers (EHR-or PHR systems), without requiring specialized viewers as applied in the eHDSI services.

=== Concept code mapping===
In several real world use cases the records used as source for the Patient Summaries may use locally adopted terminologies that – when possible – are remapped into the reference value sets or may be used as is to provide only uncoded information.
This leads to a series of requirements for the IPS that will be discussed in the [[#Design conventions and principles| Design conventions and principles]] section.
*When the original coded concept is mapped in one of the coded concepts included in the reference value sets called hereafter reference code/coded concept, both the original and the reference codes should be reported in the IPS instance.
*When the original coded concept is not mapped to one of the coded concepts included in the reference value sets, the original code should be reported in the IPS instance as well as the indication that mapping was not successful.
*When the original record, for a specific coded element, is not able to provide coded but only textual information, this information should be reported in the IPS instance.

Moreover it should be taken into account that:
*The original record may support multi-coding, so that the IPS instance should be able to distinguish if the additional codes belong to the original content or they are the result of post-hoc concept code mapping.
*The original record may include references to the pieces of text the coding was derived from, if present, the IPS instance should preserve this link between the original code and the referred text.
*Distinct original and reference coded concepts may belong to the same code system. This may be the result of a different level of granularity between the original and the reference value sets, or the result of format transformation e.g. CCD document is used as input for generating an IPS. For these cases the requirement of recording both coded concepts should be applied.

''Note: in some jurisdictions as the European Cross-border services, some of these "should" may be turned into a "shall".''

=== Multilingual support ===

The debate on multilingual support for the IPS could be split in two distinct subjects:
#The translation of coded concept designations (displayName)
#The translation of the narrative
In both cases several options may be identified depending also on the use cases considered:
*The translation to the language of the receiving country: an IPS is prepared before a planned travel; a foreign provider retrieves a translated copy of the IPS from the patient's country of affiliation…
*The translation into a commonly agreed language, e.g. an English version of the IPS is prepared.
*The predefined set of translations is included in the shared IPS.
It is out of the scope of this guide to suggest any of these solutions: all of them should be supported by this standard.

==== Translation of Designations====
Basically, the requirements related to the translation of the designations derive from the European Cross-border services functional requirements that for “safety and liability reasons” all the original coded terms (designations, displayName) shall be recorded in the exchanged documents together with at least the English and the receiving country language terms (designations, displayName) associated to the reference codes. The designations translated in the receiving country language are used to generate the human readable content shown to the receiving provider. No free text translation is applied in this case.
In order to accomplish this objective, the IPS should have the capability to record one or more designations, possibly indicating the language used.

==== Narrative Translation ====
With the term narrative translation two different concepts are covered:
*The translation of the original narrative text. This can be in principle:
**Human curated
**Automatically performed (e.g. using specialized or generic translation services)
**Creation of a new translated narrative based on the coded entries.

Different levels of quality and liability can be obtained depending on the solution adopted and on the translation service used.
It is out of the scope of this guide to suggest any of these solutions, in all the cases however:
*the language of the narrative should be identifiable
*the original and the translated narrative should be clearly distinguished
*the translation methodology applied (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

IPS Functional requirements 1

2017-07-24T10:46:10Z

Cchronaki: /* Functional requirements and high-level use cases */

=Functional requirements and high-level use cases=

Several use cases may be identified for the International Patient Summary within its scope (“specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care”). Section [[#Examples (in progress)|Examples (in progress)]] provides examples of some real world user stories for the cross-border care developed by the [http://www.trilliumbridge.eu Trillium Bridge Project ] and by the [http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative S&I EU-US eHealth Cooperation Initiative ] in the scope of the EU/US Roadmap initiative.

The cross-border care is not however the only expected usage scenario for the IPS. Some European countries have already manifested their interest on the IPS work for their future national Patient Summary for unscheduled care. Patient summary initiatives are currently in various stages of development in other parts of the world.

As shown by the user stories there are several possible options for the IPS in terms of creation, sharing and usage of an IPS. For example:
#an IPS could be a created when requested and used (before or during a care episode); or can be asynchronously generated and made available for future usage (e.g. store and retrieve).
#the IPS can be retrieved using a document exchange infrastructure; transported by the patient; or shared using cloud-services.
#the IPS may be subject of a transformation process, that may include syntactical conversions; coded concepts mappings and coded concept designation or free text translations. This transformation process may be performed in the creation phase, during the transmission, or after it has been received possibly using an external service.
#Finally, the received CDA may be displayed using a common CDA stylesheet; may be used to extract some relevant information to be displayed by the EHR-S or to be incorporated into the receiver’s EHR. Alternatively, a specialized viewer may be adopted to enable the display of the translated content.

Moreover for exchange cross-jurisdiction, the IPS could be used as:
#shared format among jurisdictions (case A), where jurisdictions originate and use IPS conforming documents as is.
#pivot document among existing summaries / data formats (case B), where IPS is used as intermediate format between the US C-CDA CCD (Please note that the CCD scope differs from that of the IPS) and the European eHDSI Patient Summary for a Transatlantic Patient Summary exchange.
#mixed mode (Case C), where either the originator or the consumer is expected to use an IPS conforming document.

[[File:IPS_cases.png|none|600px]]
<ref group="Figure">Examples of IPS usage</ref>Examples of IPS usage

Considering all those possible combinations and additional business requirements agreed by jurisdictions, there are several technical infrastructures and services that may be designed to support these requirements.

It is out of scope of this standard to provide any indication about solutions and strategies for the IPS creation, sharing, syntactical and semantic mapping, translation, and use.

Having said that an International Patient Summary may:
#be the result of automatic assembly (assembled IPS) or of a human summarization act (human curated IPS)
#have one or more EHR sources
#document information from a single or multiple jurisdictions/organizations
#be aggregate input from a single or multiple encounters

A clear determination of such contextual information helps the receiver comprehend and the attest to the trustworthiness on the received IPS. Most of these aspects are related to data provenance, introduced in section [[#Provenance | Provenance]] above.

Even if in many jurisdictions require that only one active Patient Summary for unscheduled care would be made available, no constraints are imposed or assumed by this guide as this strongly depends on the particular use case.

Moreover it is also out of scope for this guide to:
*provide guidance on how to determine the relevance of data for their inclusion in a IPS;
*define selection or composition rules for facing potential inconsistencies from multiple sources in case of automatic collection.

== Code mappings and multilingual support ==
The capability of managing locally used coded concepts and reference terminologies, and that of providing receiving providers with human readable information in a language that can be understood by them, are critical aspects to be taken in account in the cross-border sharing of documents.
This section summarizes some of the requirements related to these aspects, including also additional needs derived from the European cross-border services and some lessons learned by the EU/US Trillium Bridge Project.
The European cross-border services (eHDSI see link to eHDSI) use a business to business exchange infrastructure based on a network of country gateways that mediate access to the national infrastructures. The eHDSI Patient Summary (eHDSI PS) is used as a “pivot” document for the cross-border exchange. Local PS using data/document formats are in fact remapped into the eHDSI PS. The document exchanged is processed each time it passes through one of these gateway applying the needed syntactical transformation, codes mapping. and codes designations’ translation. Finally, in the current practice the received PSs are displayed using specialized display tools that build a human readable representation of the PS in the target language using the translated designations reported in the coded entries.
The adoption of translated narratives in the received document has been one of the indications received by the Trillium Bridge Project. This in fact allows extending multilingual support for the cross-border patient summaries to a wider set of potential consumers (EHR-or PHR systems), without requiring specialized viewers as applied in the eHDSI services.

=== Concept code mapping===
In several real world use cases the records used as source for the Patient Summaries may use locally adopted terminologies that – when possible – are remapped into the reference value sets or may be used as is to provide only uncoded information.
This leads to a series of requirements for the IPS that will be discussed in the [[#Design conventions and principles| Design conventions and principles]] section.
*When the original coded concept is mapped in one of the coded concepts included in the reference value sets called hereafter reference code/coded concept, both the original and the reference codes should be reported in the IPS instance.
*When the original coded concept is not mapped to one of the coded concepts included in the reference value sets, the original code should be reported in the IPS instance as well as the indication that mapping was not successful.
*When the original record, for a specific coded element, is not able to provide coded but only textual information, this information should be reported in the IPS instance.

Moreover it should be taken into account that:
*The original record may support multi-coding, so that the IPS instance should be able to distinguish if the additional codes belong to the original content or they are the result of post-hoc concept code mapping.
*The original record may include references to the pieces of text the coding was derived from, if present, the IPS instance should preserve this link between the original code and the referred text.
*Distinct original and reference coded concepts may belong to the same code system. This may be the result of a different level of granularity between the original and the reference value sets, or the result of format transformation e.g. CCD document is used as input for generating an IPS. For these cases the requirement of recording both coded concepts should be applied.

''Note: in some jurisdictions as the European Cross-border services, some of these "should" may be turned into a "shall".''

=== Multilingual support ===

The debate on multilingual support for the IPS could be split in two distinct subjects:
#The translation of coded concept designations (displayName)
#The translation of the narrative
In both cases several options may be identified depending also on the use cases considered:
*The translation to the language of the receiving country: an IPS is prepared before a planned travel; a foreign provider retrieves a translated copy of the IPS from the patient's country of affiliation…
*The translation into a commonly agreed language, e.g. an English version of the IPS is prepared.
*The predefined set of translations is included in the shared IPS.
It is out of the scope of this guide to suggest any of these solutions: all of them should be supported by this standard.

==== Translation of Designations====
Basically, the requirements related to the translation of the designations derive from the European Cross-border services functional requirements that for “safety and liability reasons” all the original coded terms (designations, displayName) shall be recorded in the exchanged documents together with at least the English and the receiving country language terms (designations, displayName) associated to the reference codes. The designations translated in the receiving country language are used to generate the human readable content shown to the receiving provider. No free text translation is applied in this case.
In order to accomplish this objective, the IPS should have the capability to record one or more designations, possibly indicating the language used.

==== Narrative Translation ====
With the term narrative translation two different concepts are covered:
*The translation of the original narrative text. This can be in principle:
**Human curated
**Automatically performed (e.g. using specialized or generic translation services)
**Creation of a new translated narrative based on the coded entries.

Different levels of quality and liability can be obtained depending on the solution adopted and on the translation service used.
It is out of the scope of this guide to suggest any of these solutions, in all the cases however:
*the language of the narrative should be identifiable
*the original and the translated narrative should be clearly distinguished
*the translation methodology applied (e.g. derived from the coded entries; translated by a generic service;..) should be noted.

CDA Background

2017-07-24T10:02:26Z

Cchronaki: /* Template versioning */

==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, 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 artefacts 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 are:
*CDA '''Document Level Templates''' constrain fields in the Clinical Document Architecture (CDA) header, and define containment relationships to CDA sections.<br/>''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.<br/>''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.<br/>''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<ref name="teits">HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1</ref>.

DocumentUse

2017-07-23T23:33:25Z

Cchronaki: /* How to read this document */

==How to read this document==
This is a ballot document. The provided text is subject to comments.

All artefacts (templates, value sets etc.) listed with the status [[File:Kyellow.png|14px]] ''Draft'' or [[File:Korange.png|14px]] ''Pending'' are subject to ballot comments.

Artefatcs with other status information, especially [[File:Kgreen.png|14px]] ''Final'' or ''Active'' are not (directly) part of the ballot and some artefacts are actually even used coming from different sources (references artefacts, indicated by the symbol <div class="repo refonly">ref</div>). These references artefacts are also not subject to the ballot, as they might be balloted elsewhere already.

The PDF version contains a ruler on the left side of the pages. A ruler has the page number on top of it and allows locating a line at the page by simply specifying the number at the scale tick. This is more precise and allows also commenting on graphics and pictures.

For example if you have a comment on page 29 because of a typo (see figure), you simply specify the error with its location p0029-04.

Of course you can also refer by classical chapter and section numbers. The use of the ruler has the ballot team's preference though.

{{IncludeImage|IPS_ballotruler.jpg|500px|70%}}
<ref group="Figure">Locating ballot comments</ref> To locate a typo on page 29 as a ballot comment, simply specify the location p0029-04. <references group="Figure"/>

DocumentUse

2017-07-23T23:32:38Z

Cchronaki: /* How to read this document */

DocumentUse

2017-07-23T23:31:18Z

Cchronaki: /* How to read this document */

IPS Introduction 1

2017-07-23T23:29:09Z

Cchronaki: /* Relationships with other projects and guidelines */

=Introduction=

The '''International Patient Summary''' (IPS) is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country.
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"/>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"/>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”; and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary dataset,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Note that the last two items are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extend possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.

{{IncludeImage|IPS_principles.png|300px|90%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref>The IPS Principles

#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
#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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|400px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref>The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br /> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br />Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br />Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br />Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br />Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br />This document is focused on the European cross-country services.

{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref>The European Commission CEN/TC 251 Grant Agreement

* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref> This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

* The '''HL7 Consolidated CDA (C-CDA)''' <ref>http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379 </ref> implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br />This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br />This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service''' <ref>https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications</ref>.This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. This is one of the primary sources for this Implementation Guide.
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1<ref>http://www.hl7.org/implement/standards/product_brief.cfm?product_id=420</ref> is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Introduction 1

2017-07-23T23:25:58Z

Cchronaki: /* Relationships with other projects and guidelines */

=Introduction=

The '''International Patient Summary''' (IPS) is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country.
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"/>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"/>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”; and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary dataset,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Note that the last two items are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extend possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.

{{IncludeImage|IPS_principles.png|300px|90%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref>The IPS Principles

#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
#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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|400px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref>The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br /> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br />Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br />Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br />Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br />Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br />This document is focused on the European cross-country services.

{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref>The European Commission CEN/TC 251 Grant Agreement

* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref>This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

* The '''HL7 Consolidated CDA (C-CDA)''' <ref>http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379 </ref> implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br />This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br />This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service''' <ref>https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications</ref>.This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. This is one of the primary sources for this Implementation Guide.
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Introduction 1

2017-07-23T22:09:17Z

Cchronaki: /* Relationships with other projects and guidelines */

=Introduction=

The '''International Patient Summary''' (IPS) is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country.
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"/>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"/>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”; and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary dataset,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Note that the last two items are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extend possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.

{{IncludeImage|IPS_principles.png|300px|90%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref>The IPS Principles

#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
#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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|400px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref>The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br /> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br />Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br />Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br />Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br />Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br />This document is focused on the European cross-country services.

{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref>The European Commission CEN/TC 251 Grant Agreement

* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref><br />This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

* The '''HL7 Consolidated CDA (C-CDA)''' <ref>http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379 </ref> implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br />This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br />This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service.''' This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. eHDSI specifications are available at https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications. <br />This is one of the primary sources for this Implementation Guide.
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Introduction 1

2017-07-23T22:02:10Z

Cchronaki: /* Scope */

=Introduction=

The '''International Patient Summary''' (IPS) is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country.
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"/>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"/>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”; and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary dataset,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Note that the last two items are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extend possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.

{{IncludeImage|IPS_principles.png|300px|90%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref>The IPS Principles

#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
#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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|400px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref>The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br /> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br />Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br />Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br />Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br />Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br />This document is focused on the European cross-country services.

{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref>The European Commission CEN/TC 251 Grant Agreement

* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref><br />This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

* The '''HL7 Consolidated CDA (C-CDA)''' implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br />This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br />This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service.''' This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. eHDSI specifications are available at https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications. <br />This is one of the primary sources for this Implementation Guide.
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Introduction 1

2017-07-23T22:00:49Z

Cchronaki: /* Project Background */

=Introduction=

The '''International Patient Summary''' (IPS) is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country.
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"/>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"/>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”; and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary dataset,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Although the last two items of course are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extend possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.

{{IncludeImage|IPS_principles.png|300px|90%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref>The IPS Principles

#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
#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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|400px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref>The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br /> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br />Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br />Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br />Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br />Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br />This document is focused on the European cross-country services.

{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref>The European Commission CEN/TC 251 Grant Agreement

* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref><br />This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

* The '''HL7 Consolidated CDA (C-CDA)''' implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br />This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br />This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service.''' This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. eHDSI specifications are available at https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications. <br />This is one of the primary sources for this Implementation Guide.
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Introduction 1

2017-07-23T21:59:33Z

Cchronaki: /* Purpose */

=Introduction=

The '''International Patient Summary''' (IPS) is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country.
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"/>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"/>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”); and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary dataset,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Although the last two items of course are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extend possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.

{{IncludeImage|IPS_principles.png|300px|90%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref>The IPS Principles

#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
#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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|400px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref>The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br /> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br />Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br />Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br />Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br />Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br />This document is focused on the European cross-country services.

{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref>The European Commission CEN/TC 251 Grant Agreement

* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref><br />This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

* The '''HL7 Consolidated CDA (C-CDA)''' implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br />This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br />This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service.''' This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. eHDSI specifications are available at https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications. <br />This is one of the primary sources for this Implementation Guide.
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Introduction 1

2017-07-23T21:57:52Z

Cchronaki:

=Introduction=

The '''International Patient Summary''' (IPS) is '''''a minimal and non-exhaustive patient summary dataset, 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 international patient summary is specified as a templated document using HL7 CDA R2.
The primary use case is to provide support for cross-border or crossjuridictional emergency and unplanned care.

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.
*Value sets based on international vocabularies that are usable and understandable in any country, are proposed where possible
*Data and metadata for document-level provenance.

== Project Background ==

This Implementation Guide has drawn upon the results of multiple previous projects on patient summaries (including but not limited to epSOS, ONC S&I, Trillium Bridge, Sequoia eHealth Exchange), rules and recommendations for vocabularies and value sets (in multilingual settings) and templates for the implementation of international patient summary documents.

The idea of the International Patient Summary has been one of the main results of the 2010 EU/US Memorandum of Understanding through its two operational arms: the European project Trillium Bridge <ref>The Trillium Bridge Project http://www.trilliumbridge.eu</ref> and the Interoperability of EHR work group formed under the ONC Standards and Interoperability Framework (ONC S&I) EU/US eHealth Cooperation Initiative<ref>Memorandum of Understanding between the United States Department of Health and Human Services and the European Commission on Cooperation Surrounding Health Related Information and Communication Technologies http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=1784</ref>.
These initiatives identified the need for common templates and vocabularies for the patient summary.

The Joint Initiative Council (JIC) on SDO Global Health Informatics Standardization has initiated the standard sets project with patient summary as its pilot <ref>http://www.jointinitiativecouncil.org/news/JIC_Standards_Set_development_20160101_v1.00.pdf</ref>; and the IPS became one of the main subjects of the new EU / US roadmap , having as declared goal “to enable a standardized international patient summary (IPS) to be in use by 2020”<ref>Transatlantic eHealth/health IT Cooperation Roadmap http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=12123</ref>.

The first standardization activity concerning the IPS was initially promoted in April 2014 by ONC within HL7 International. The project was called “INTernational PAtient Summary (INTERPAS)”. In May 2016, the European Commission Granted an Agreement with CEN/ TC 251, recognizing the need to effectively support the leadership and active participation in IPS standardization activities. Thanks to the new boost from the European Commission (EC) and ONC a revision of the HL7 project was started in May 2016, as well as the standardization activities in CEN/TC 251 for the European standards on Patient Summaries.
Since the beginning of this new phase, the initiatives were envisaged as a '''single common IPS project''' supported by different organizations; where the CEN/TC 251 and the HL7 teams worked together, taking in account the inputs of the JIC Standard Sets initiative on Patient Summary, with the common intent of developing coherent set of standards to support the International Patient Summary concept.

To expedite progress it was also agreed to set up an informal collaboration, promoting a continuous alignment process between the two SDO-specific projects, thanks also to a cross-participation in the project teams. Overlaps have thus been minimized: the CEN/TC 251 activities have been focused on the IPS dataset, formalized by the CEN/TC 251 European standard (EN) ''"The Patient Summary for Unscheduled, Cross-border Care"'' (the CEN/TC 251 EN PS in <ref group="Figure" name="saif"/>); the HL7 ones initially on its implementation based on HL7 CDA R2 - this guide - and next on FHIR (the HL7 IPS IGs in <ref group="Figure" name="saif"/>). The figure shows how the products of these standardization activities are placed in the HL7 SAIF Interoperability Matrix.

{{IncludeImage|IPS_SAIF.png|600px|90%}}
<ref group="Figure" name="saif">Standards in the HL7 SAIF Interoperability Matrix</ref> Standards in the HL7 SAIF Interoperability Matrix

A formal agreement between HL7 International and CEN/TC 251 has been finally signed in April 2017 in which these organizations established “''in order to further the care for citizens across the globe <…> to collaborate on a single, common International Patient Summary (IPS) specification''”); and that “''the IPS specification shall focus on a minimal and non-exhaustive Patient Summary dataset, which is specialty-agnostic and condition-independent, but still clinically relevant.''”.

==Scope==
As expressed in the introduction, the International Patient Summary is
*a minimal and non-exhaustive patient summary dataset,
*specialty-agnostic,
*condition-independent,
*but readily usable by clinicians for cross-border unscheduled care of a patient.

In this context, ''minimal and non-exhaustive'' means that an IPS is not intended to reproduce (the entire) content of an Electronic Health Record (EHR). It covers the so-called SAMPLE history and beyond. SAMPLE “Forefront Emergency Data” is a list of items (see <ref>https://en.wikipedia.org/wiki/SAMPLE_history</ref>), the information a physician needs to know when he comes to an emergency situation. This list mentions
*S – Signs/Symptoms
*A – Allergies (emergency medical care relevant allergies like caused by medication, radiocontrast agents),
*M – Medications (current, as recent as possible) and
*P – Past Illnesses such as chronic (still active) like coronary heart disease, renal failure or past (not active) diseases like a former myocardial infarction. Other desired information in case of an emergency focuses on
*L – last meal/oral intake and the
*E – events preceding the accident, emergency or other situation leading up to present contact with the health system.
Although the last two items of course are not considered part of a Patient Summary.

''Specialty-agnostic'' means that an IPS is not filtered for a specialty. As an example, allergies are not filtered to the specialty of internal medicine, thus may also include food allergies, if considered to be relevant for, e.g. unplanned care.

''Condition-independent'' means that an IPS is focused on the actual situation (e.g. unscheduled care) and is not intended to represent the entire patient's medical history.

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 global feasibility to the extend possible.

== General Principles for this Specification==

With the formal agreement signed on April 2017 HL7 International and CEN/TC 251 expressed their intent to collaborate under the following principles for the IPS.

{{IncludeImage|IPS_principles.png|300px|90%}}
<ref group="Figure" name="ipsprinciples"> The IPS Principles</ref>The IPS Principles

#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
#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
#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
#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

Moreover HL7 International and CEN/TC 251 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 cross-border or cross-jurisdiction unscheduled care.

The more relevant consequences of these principles in the template design are:

* The adoption of a meet in the middle approach in the templates’ design to balance the need of maximizing the reuse of existing implemented templates (epSOS, C-CDA CCD; IHE PCC…) and facilitate implementation with the need of optimizing the fitness for purpose within the IPS scope. This approach aims to avoid a pure technical exercise of templates harmonization or an academic exercise that does not take in account what is already implemented.

{{IncludeImage|IPS-meet-in-the-middle.png|400px|90%}}
<ref group="Figure" name="ipsmeetmiddle">The IPS meet-in-the-middle approach</ref>The IPS meet-in-the-middle approach

*Cooperate with the HL7 Terminology Authority and the organizations that own the used code systems (e.g. SNOMED International) to make available a set of free value sets that could be globally usable when the IPS would be implemented.
*When global identifiers are not (or not yet) available, as in the case of the medicinal products, enhance the model proposed for that element with relevant identifying and descriptive attributes that could help the global identification of that element.
*Select a set of reference global terminologies, provisioning for the inclusion of the locally used terminologies.
*Avoid solutions (e.g. identifiers, terminologies, standards), even promising in the resolution of some of the well-known issues (as the medicinal product identification), that are not yet available for concrete global use. The IPS has been however, already designed, where possible, to be ready to adopt these solutions when they are made available for real use (e.g. the IDMP identifiers) and to already support parts of those solutions that can be used today.
*Within the scope of the IPS and of the “implementable” principle, attempt to be enough generic in the design of the templates so that the IPS templates are extensible to support new scenarios, specific specialties, or conditions through templates specialization or adaptation mechanisms.

== Structuring Choices ==
The International Patient Summary is specified as a templated document using HL7 CDA R2. The specification has taken account of how FHIR 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 [[IPS_implementationguide_1#Representing "known absent" and "not known"|here]].

To be universally exchangeable, a patient summary must rely on multilingual international reference terminologies. The International Patient Summary defines SNOMED CT as a primary terminology (the meaning of "primary terminology" is explained in [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|a later section]]) and it is used for the majority of value sets. Other primary terminologies used in this specification are LOINC for observations (e.g., laboratory tests) and document sections, UCUM for units of measure, and EDQM for dose forms and routes.

This specification adopts ART-DECOR® as the specification platform for this Implementation Guide and uses the HL7 template exchange format. This tool and format are increasingly used by several regions, including European countries, and have been adopted by the EU eHealth Digital Service Infrastructure (eHDSI) project for the operational deployment of the EU cross-borders patient summary and ePrescription services.

==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 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==

This guide is one of the products of the ''International Patient Summary project'' (see the [[#Project Background| Project Background]] section for details).
This project relates to other projects and products as:

* The '''European Commission CEN/TC 251 Grant Agreement''' “The International Patient Summary Standards Project” (SA/CEN/GROW/EFTA/000/2015-16). <br /> This project has as one of its goal ''“to participate in the creation of an International Patient Summary specification, at a global level, and turn this into a European standard, in line with the Guidelines on Minimum/Nonexhaustive Patient Summary Dataset for Electronic Exchange as adopted by the European eHealth Network"''<br />Under this project two other standard work items have been promoted under CEN/TC 251:
**The '''CEN/TC 251 “prEN: The Patient Summary for Unscheduled, Cross-border Care”'''. <br />Its goal is to “formalise the dataset required to share information about the medical background and history of a patient …. It uses the European guidelines (version 2, November 2016) as an official source for the requirements….” <br />Even if it is a European standard it is designed to be applicable in a wider global context.
**The '''CEN/TC 251 “prTS: The International Patient Summary: Guidance for European Implementation Technical Specification'''. <br />Its goal is to “provide implementation guidance to support the use of the International Patient Summary dataset in a European context” <br />This document is focused on the European cross-country services.

{{IncludeImage|CEN IPS Grant.png|300px|60%}}
<ref group="Figure" name="ipsmeetinthemiddle">The European Commission CEN/TC 251 Grant Agreement</ref>The European Commission CEN/TC 251 Grant Agreement

* The '''European eHealth Network Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2.''' <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/health/sites/health/files/ehealth/docs/ev_20161121_co10_en.pdf</ref><br />This Guideline, together with the general guidelines for the electronic exchange of health data under Cross-Border Directive 2011/24/EU, document the clauses agreed among the European Countries to support the exchange of Patient Summary data for unscheduled care.

The relationships among these standards are shown in the figure included in the section [[#Conformance clause|Conformance clause]] below.

* The '''HL7 Consolidated CDA (C-CDA)''' implementation guide was developed and produced through the joint efforts of HL7, two Sub-Work Groups of the Office of the National Coordinator (ONC) Standards and Interoperability (S&I) Framework — Longitudinal Care Plan (LCP) and Long-Term Post-Acute Care (LTPAC) Transition) — and through the SMART C-CDA Collaborative hosted by ONC and Harvard Medical School. It provides a library of CDA templates for implementing a set of CDA documents. <br />This is one of the primary sources for this Implementation Guide.
*The '''IHE Patient Care Coordination''' (PCC) Cross-Enterprise Sharing of Medical Summaries (XDS-MS) <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref> – “defines a mechanisms to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.” . <br />This is one of the primary sources for this Implementation Guide.
*'''eHealth Digital Service Infrastructure (eHDSI) Patient Summary Service.''' This European initiative operationalizes the work done by the epSOS and EXPAND projects for the implementation of European Cross-border services for the exchange of patient summaries and ePrescriptions. eHDSI specifications are available at https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Specifications. <br />This is one of the primary sources for this Implementation Guide.
* The '''Data Provenance''' is an ONC S&I Initiative addressing the “source data” challenge so that trust in the authenticity of the data can help inform decision making. The HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 is one of the products as result of joint efforts of Health Level Seven (HL7), and the Office of the National Coordinator (ONC) Standards and Interoperability Standards and Interoperability Framework-Data Provenance Initiative.

{{:DocumentUse}}

==Reading Publication Artefacts==
A reading guide is available that explains the formalism used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.

IPS Authors and Contributors

2017-07-23T21:31:31Z

Cchronaki:

<div class="column clearfix">
<div class="col-md-12">
<table class="table table-bordered wikitable">

<tr>
<td>Primary Editor</td>
<td>Giorgio Cangioli, PhD<br/>Consultant, HL7 Italy, <br/>giorgio.cangioli@gmail.com
</td>
</tr>

<tr>
<td>Primary Editor</td>
<td>Rob Hausam<br/> Hausam Consulting LLC <br/>rob@hausamconsulting.com
</td>
</tr>

<tr>
<td>Primary Editor</td>
<td>Dr Kai U. Heitmann<br/>Heitmann Consulting and Services, Gefyra GmbH, HL7 Germany<br/>info@kheitmann.de</td>
</tr>

<tr>
<td>Contributor</td>
<td> François Macary <br/>francois.macary@phast.fr </td>
</tr>

<tr>
<td>Contributor</td>
<td> Dr Philip Scott <br/>philip.scott@port.ac.uk </td>
</tr>

<tr>
<td>Contributor</td>
<td> Dr Christof Geßner <br/>christof.gessner@gematik.de </td>
</tr>

<tr>
<td>Contributor</td>
<td> Dr Stefan Sabutsch <br/>stefan.sabutsch@elga.gv.at </td>
</tr>

<tr>
<td>Contributor</td>
<td> Gary Dickinson <br/>gary.dickinson@ehr-standards.com </td>
</tr>

<tr>
<td>Contributor</td>
<td> Catherine Chronaki<br/>HL7 International Foundation<br/>chronaki@gmail.com </td>
</tr>

<tr>
<td>Contributor</td>
<td> Dr Stephen Chu <br/>chuscmi88@gmail.com </td>
</tr>

<tr>
<td>Contributor</td>
<td> Didi Davis <br/>ddavis@sequoiaproject.org </td>
</tr>

<tr>
<td>Other Contributors</td>
<td> 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)</td>
</tr>

</table>
</div>
</div>