HL7 IPS - User contributions [en]

IPS implementationguide 1

2017-07-28T13:24:42Z

Pscott: /* Literature */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.77
|Submitted = HL7 International
|Date = 26. July 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:IPS_Authors_and_Contributors}}

__TOC__

{{:IPS_Introduction_1}}

{{:IPS_Technical_Background_1}}

{{:IPS_Functional_requirements_1}}

{{:IPS_Design_conventions_and_principles_1}}

=Conformance clause=

This section references the requirements, criteria, or conditions to be satisfied in order that a product (tangible) or a service may claim conformance about this guide, and how other artefacts may claim compliance with it. (Note: The concept of conformance and compliance are used coherently with the HL7 Service-Aware Interoperability Framework: Canonical Definition Specification, Release 2<ref>HL7 Service-Aware Interoperability Framework: Canonical Definition Specification, Release 2 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=3</ref>. The fulfilment of these clauses indirectly assures that a product that is subject of a “conformity assessment” satisfies the business or the design requirements this specification complies to. It should be however clear that the compliance with specified business or the design requirements, for example in the future with the CEN prEN IPS, does not imply that the compliant implementations are technically interoperable. A “conformity assessment” is a process that assesses that any proposition that is true in a given specification, it is also true in the service or product that implements it. In most real-world cases conformance testing objects are used to technically validate the products. These objects provide a great help in the validation of the instances, even if it is not often these kind of validation is not self-sufficient to guarantee the functional/ semantic conformity: many real-life examples can be made about instances that are technically valid, but not clinically meaningful or correct.

<ref group="Figure" name="ipsworld"/> below depicts how this concept applies to the business requirements, the current and hopefully future IPS projects standards (CEN/TC 251 and HL7) and other related artefacts involved in this assessment chain. (see section [[#Relationships with other projects and guidelines | Relationships with other projects and guidelines]] for a description of the standards developed by the CEN/TC 251 IPS project )

{{IncludeImage|IPS_world.png|700px|80%}}

<ref group="Figure" name="ipsworld">The IPS World</ref> The IPS World

The "rules" and processes for refining the standard through constraint and extension, including which standard artifacts are subject to constraint or extension; the definition of constraint and localization profiles; the criteria for establishing a conformance statement; and the principles guiding who may define extensions to the standards and under what circumstances that applies to the CDA standards are defined in §1.3 CDA Conformance of the CDA and detailed in the HL7 V3 Refinement, Constraint and Localization section. (See the CDA R2 Standard<ref>CDA R2 Standard http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>)
There are no additional requirements to be applied for this guide for what concern the Recipient and the Originator Responsibilities.

The formal representation used in this implementation guide for expressing the conformance statement is described in section "[[Reading_Guide_for_Publication_Artefacts]]" of this guide and makes use of a tabular representation that may include also computable or textual constraints. The template rules are formalized using the computable format defined by the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1<ref name="teits">HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=377</ref> in order to facilitate also the automatic generation of consistent testing objects.

This standard (i.e. the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 ) defines also how derived templates may relate to the templates defined in this guide for example:
*Specialization: “A specialized template is a narrower, more explicit, more constrained template based on a “parent” template.
* Adaptation: “The adapted template is “based on” the original template which means it can be an extension or a specialization (restriction) of the original template design.”
* Equivalency: “two templates have the same purpose and the same design; however, their governance and/or metadata and/or details of their design may be different.”

Based on this the following way to use this guide may be considered :
* IPS as a document: the conformance is asserted at the document level. All the rules defined by this guide, or by a specialized IPS document level template, are fulfilled. Implementers may take advantage of the template openness to better support specific cases, “extended” parts may be however not interoperable among them.
* IPS as a library: the conformance is asserted at the section or the entry level. The templates are used as a library to build, for example, new cross-border documents. For example the immunization section may be used to build an electronics implementation of the WHO yellow card for vaccinations; or the used section to send back a cross border encounter report after the Patient Summary has been used. Implementers may take advantage of the template openness to better support specific cases, “extended” parts may be however not interoperable among them.
* IPS as a reference: the implementation is conformant with templates that are adaptation or equivalent to those defined by this guide. In this case some of the rules defined by this guide are not fulfilled and the conformance cannot be asserted. However differences may be limited and the effort required to achieve the harmonization be not so huge. Typical examples are templates in which alternatives vocabularies are used.

Jurisdiction may also decide to impose the closure of the template in order to limit the implementation optionality. This should be carefully evaluated in term of flexibility of the solution.



{{:IPS_Appendix_1}}

=List of all artifacts used in this guide=
==CDA Templates==
* [[2.16.840.1.113883.10.22.1.1]] International Patient Summary
* [[2.16.840.1.113883.10.22.2.1]] IPS CDA recordTarget
* [[2.16.840.1.113883.10.22.2.2]] IPS CDA author
* [[2.16.840.1.113883.10.22.2.3]] IPS CDA custodian
* [[2.16.840.1.113883.10.22.2.4]] IPS CDA legalAuthenticator
* [[2.16.840.1.113883.10.22.2.5]] IPS Patient Contacts
* [[2.16.840.1.113883.10.22.2.6]] IPS CDA documentationOf
* [[2.16.840.1.113883.10.22.2.7]] IPS CDA relatedDocument
* [[2.16.840.1.113883.10.22.3.1]] IPS Medication Summary Section
* [[2.16.840.1.113883.10.22.3.2]] IPS Allergies and Intolerances Section
* [[2.16.840.1.113883.10.22.3.3]] IPS Problems Section
* [[2.16.840.1.113883.10.22.3.4]] IPS History of Procedures Section
* [[2.16.840.1.113883.10.22.3.5]] IPS Immunizations Section
* [[2.16.840.1.113883.10.22.3.6]] IPS Medical Devices Section
* [[2.16.840.1.113883.10.22.3.7]] IPS History of Past Illness Section
* [[2.16.840.1.113883.10.22.3.8]] IPS Functional Status Section
* [[2.16.840.1.113883.10.22.3.9]] IPS Plan of Treatment Section
* [[2.16.840.1.113883.10.22.3.10]] IPS Social History Section
* [[2.16.840.1.113883.10.22.3.11]] IPS History of Pregnancy Section
* [[2.16.840.1.113883.10.22.3.12]] IPS Advance Directives Section
* [[2.16.840.1.113883.10.22.3.14]] IPS Results Section
* [[2.16.840.1.113883.10.22.3.15]] IPS Translation Section
* [[2.16.840.1.113883.10.22.4.1]] IPS Allergy or Intolerance
* [[2.16.840.1.113883.10.22.4.2]] IPS ManufacturedProduct
* [[2.16.840.1.113883.10.22.4.3]] IPS Manufactured Material
* [[2.16.840.1.113883.10.22.4.4]] IPS Medication Entry
* [[2.16.840.1.113883.10.22.4.5]] IPS Allergy and Intolerance Concern
* [[2.16.840.1.113883.10.22.4.6]] IPS Reaction Manifestation
* [[2.16.840.1.113883.10.22.4.7]] IPS Problem Concern Entry
* [[2.16.840.1.113883.10.22.4.8]] IPS Problem Entry
* [[2.16.840.1.113883.10.22.4.9]] IPS Result Organizer
* [[2.16.840.1.113883.10.22.4.10]] IPS Result Observation
* [[2.16.840.1.113883.10.22.4.11]] IPS Pathology Result Observation
* [[2.16.840.1.113883.10.22.4.12]] IPS Radiology Result Observation
* [[2.16.840.1.113883.10.22.4.13]] IPS Laboratory Result Observation
* [[2.16.840.1.113883.10.22.4.14]] IPS Body Author
* [[2.16.840.1.113883.10.22.4.15]] IPS Immunization
* [[2.16.840.1.113883.10.22.4.16]] IPS Immunization Medication Information
* [[2.16.840.1.113883.10.22.4.17]] IPS Procedure Entry
* [[2.16.840.1.113883.10.22.4.18]] IPS Criticality Observation
* [[2.16.840.1.113883.10.22.4.19]] IPS Certainty Observation
* [[2.16.840.1.113883.10.22.4.20]] IPS Problem Status Observation
* [[2.16.840.1.113883.10.22.4.21]] IPS Allergy Status Observation
* [[2.16.840.1.113883.10.22.4.22]] IPS Comment Activity
* [[2.16.840.1.113883.10.22.4.23]] IPS ObservationMedia
* [[2.16.840.1.113883.10.22.4.25]] IPS Severity Observation
* [[2.16.840.1.113883.10.22.4.26]] IPS Medical Device
* [[2.16.840.1.113883.10.22.4.27]] IPS Pregnancy Status Observation
* [[2.16.840.1.113883.10.22.4.28]] IPS Pregnancy Outcome Observation
* [[2.16.840.1.113883.10.22.4.29]] IPS Pregnancy Expected Delivery Date Observation
* [[2.16.840.1.113883.10.22.4.30]] IPS Specimen Collection
* [[2.16.840.1.113883.10.22.4.31]] IPS Internal Reference
* [[2.16.840.1.113883.10.22.4.33]] IPS Subordinate SubstanceAdministration
* [[2.16.840.1.113883.10.22.4.34]] IPS Social History Tobacco Use
* [[2.16.840.1.113883.10.22.4.35]] IPS Social History Alcohol Use
* [[2.16.840.1.113883.10.22.9.1]] IPS CDA Organization
* [[2.16.840.1.113883.10.22.9.2]] IPS CDA Device
* [[2.16.840.1.113883.10.22.9.3]] IPS CDA Person

==Value Sets ==
*[[2.16.840.1.113883.11.22.2]] Allergy or Intolerance Type
*[[2.16.840.1.113883.11.22.3]] Allergy Reaction
*[[2.16.840.1.113883.11.22.4]] ActStatusActiveCompleted
*[[2.16.840.1.113883.11.22.5]] CORE Problem List Disorders
*[[2.16.840.1.113883.11.22.6]] CORE Problem List Procedures
*[[2.16.840.1.113883.11.22.7]] CORE Problem List
*[[2.16.840.1.113883.11.22.8]] IPS Condition Verification Status
*[[2.16.840.1.113883.11.22.9]] Absent or Unknown Allergies
*[[2.16.840.1.113883.11.22.10]] Allergies to substances
*[[2.16.840.1.113883.11.22.11]] Adverse Reaction Agents
*[[2.16.840.1.113883.11.22.12]] ActStatusActiveCompletedAbortedSuspended
*[[2.16.840.1.113883.11.22.13]] Time units (UCUM)
*[[2.16.840.1.113883.11.22.14]] DRUGActCode
*[[2.16.840.1.113883.11.22.15]] Absent or Unknown Medication
*[[2.16.840.1.113883.11.22.16]] Problem Type
*[[2.16.840.1.113883.11.22.17]] Absent or Unknown Problems
*[[2.16.840.1.113883.11.22.18]] Problem Severity
*[[2.16.840.1.113883.11.22.19]] Language Code
*[[2.16.840.1.113883.11.22.20]] IPS Expected Delivery Date Method
*[[2.16.840.1.113883.11.22.21]] IPS Pregnancies Summary
*[[2.16.840.1.113883.11.22.22]] ActStatusActiveCompletedAbortedCancelled
*[[2.16.840.1.113883.11.22.23]] IPS Medical Devices
*[[2.16.840.1.113883.11.22.24]] IPS Condition Status Code
*[[2.16.840.1.113883.11.22.25]] Medicine Doseform
*[[2.16.840.1.113883.11.22.27]] Medicine Package
*[[2.16.840.1.113883.11.22.28]] Quantity Units
*[[2.16.840.1.113883.11.22.29]] WHO ATC
*[[2.16.840.1.113883.11.22.30]] Medicine Strength Numerator
*[[2.16.840.1.113883.11.22.31]] Medicine Strength Denominator
*[[2.16.840.1.113883.11.22.32]] Medicine Active Substances
*[[2.16.840.1.113883.11.22.33]] Medicine Route of Administration
*[[2.16.840.1.113883.11.22.34]] IPS No Drug Substances
*[[2.16.840.1.113883.11.22.35]] IPS Procedures
*[[2.16.840.1.113883.11.22.36]] Absent or Unknown Procedures
*[[2.16.840.1.113883.11.22.37]] IPS Results Organizer
*[[2.16.840.1.113883.11.22.38]] IPS Results Observation
*[[2.16.840.1.113883.11.22.39]] IPS Results Observation Laboratory
*[[2.16.840.1.113883.11.22.40]] IPS Results Observation Radiology
*[[2.16.840.1.113883.11.22.41]] IPS Results Observation Pathology
*[[2.16.840.1.113883.11.22.42]] IPS Allergy Status Code
*[[2.16.840.1.113883.11.22.43]] Absent or Unknown Immunization
*[[2.16.840.1.113883.11.22.44]] IPS Vaccines
*[[2.16.840.1.113883.11.22.45]] IPS Multingredients Products
*[[2.16.840.1.113883.11.22.46]] IPS Results Coded Values Laboratory
*[[2.16.840.1.113883.11.22.47]] IPS Results Coded Values Pathology
*[[2.16.840.1.113883.11.22.48]] IPS Results Coded Values Radiology
*[[2.16.840.1.113883.11.22.49]] IPS Results Microorganism
*[[2.16.840.1.113883.11.22.50]] IPS Results Blood Group phenotypes
*[[2.16.840.1.113883.11.22.51]] IPS Results ABO+RH GROUP
*[[2.16.840.1.113883.11.22.52]] IPS Results Presence/Absence
*[[2.16.840.1.113883.11.22.53]] IPS Healthcare Professional Roles

==Unconstrained Templates from the original CDA specification (no subject to ballot)==
* [[2.16.840.1.113883.10.12.151]] CDA Organization
* [[2.16.840.1.113883.10.12.152]] CDA Person
* [[2.16.840.1.113883.10.12.153]] CDA AssignedEntity
* [[2.16.840.1.113883.10.12.318]] CDA Author (Body)
* [[2.16.840.1.113883.10.12.315]] CDA Device
* [[2.16.840.1.113883.10.12.319]] CDA Informant (Body)
* [[2.16.840.1.113883.10.12.323]] CDA Performer (Body)
* [[2.16.840.1.113883.10.12.313]] CDA PlayingEntity
* [[2.16.840.1.113883.10.12.316]] CDA RelatedEntity

==Data Types ==
Data types for element definitions used
*AD – Address
*AD.IPS – IPS Address (see [https://art-decor.org/mediawiki/index.php?title=DTr1_AD.IPS])
*ANY – ANY
*BL – Boolean
*CD – Concept Descriptor
*CD.IPS – IPS CD (see [https://art-decor.org/mediawiki/index.php?title=DTr1_CD.IPS])
*CE – Coded with Equivalents
*CE.IPS – IPS CE (see [https://art-decor.org/mediawiki/index.php?title=DTr1_CE.IPS])
*CR – Concept Role
*CS – Coded Simple Value
*CV – Coded Value
*CV.IPS – IPS CV (see [https://art-decor.org/mediawiki/index.php?title=DTr1_CV.IPS])
*ED – Encapsulated Data
*EIVL.event – Event-Related Interval of Time
*EIVL_TS – Event-related time interval
*EN – Entity Name
*ENXP – Entity Name Part
*II – Instance Identifier
*INT – Integer
*IVL_PQ – Interval of Physical Quantity
*IVL_TS – Interval of Time Stamp
*IVL_TS.IPS.TZ – IPS IVL Time Stamp TZ (see [https://art-decor.org/mediawiki/index.php?title=DTr1_IVL_TS.IPS.TZ])
*IVL_TS.IPS.TZ.OPT
*IVXB_TS – Interval Boundary of Time Stamp
*ON – Organization Name
*PIVL_TS – Periodic Interval of Timezone
*PN – Person Name
*PQ – Physical Quantity
*SC – String with Codes
*SD.TEXT – Structured Document Text
*ST – Character String
*SXPR_TS – Parenthetic Set Expression of Time Stamp
*TEL – Telecommunication Address
*TEL.IPS – IPS TEL (see [https://art-decor.org/mediawiki/index.php?title=DTr1_IVL_TS.IPS.TZ.OPT])
*TS – Time Stamp
*TS.IPS.TZ – IPS Time Stamp TZ (see [https://art-decor.org/mediawiki/index.php?title=DTr1_TS.IPS.TZ])

Datatypes for attributes used
*bl – boolean code
*cs – code
*oid – identifier
*set_cs – code
*st – string
*uid – identifier

==Extensions==
===Common Product Model (CPM) ===
This specification uses an extension in order to reflect item from the Common Product Model (CPM), that is further described in [[ IPS_implementationguide_1#IPS_Design_conventions_and_principles_1|the section about the design conventions]] and that is used in template 2.16.840.1.113883.10.22.4.3 ''IPS Manufactured Material''. It uses the namespace <code>urn:hl7-org:cpm</code>. This is the list of elements defined for that template.
*cpm:asContent
*cpm:asSpecializedKind
*cpm:capacityQuantity
*cpm:code
*cpm:code
*cpm:containerPackagedProduct
*cpm:denominator
*cpm:formCode
*cpm:generalizedMaterialKind
*cpm:ingredient
*cpm:ingredientSubstance
*cpm:name
*cpm:numerator
*cpm:quantity
===Translation of designations===
The capability of recording multilingual designations for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services.
The IPS project recommends the introduction of an optional 'ips:designation' extension to the CD datatype to allow such translations properly.
*ips:designation

{{:Reading_Guide_for_Publication_Artefacts}}

=References=
==Literature==
* Whiting-O'Keefe QE, Simborg DW, Epstein WV, Warger A: A computerized summary medical record system can provide more information than the standard medical record. JAMA. 1985 Sep 6;254(9):1185-92.
* Boone KW: The CDA Book. Springer 2011, ISBN 978-0-85729-336-7

==Links==
<references/>

==Figures==
<references group="Figure"/>

IPS implementationguide 1

2017-07-28T13:22:16Z

Pscott: /* Conformance clause */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.77
|Submitted = HL7 International
|Date = 26. July 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:IPS_Authors_and_Contributors}}

__TOC__

{{:IPS_Introduction_1}}

{{:IPS_Technical_Background_1}}

{{:IPS_Functional_requirements_1}}

{{:IPS_Design_conventions_and_principles_1}}

=Conformance clause=

This section references the requirements, criteria, or conditions to be satisfied in order that a product (tangible) or a service may claim conformance about this guide, and how other artefacts may claim compliance with it. (Note: The concept of conformance and compliance are used coherently with the HL7 Service-Aware Interoperability Framework: Canonical Definition Specification, Release 2<ref>HL7 Service-Aware Interoperability Framework: Canonical Definition Specification, Release 2 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=3</ref>. The fulfilment of these clauses indirectly assures that a product that is subject of a “conformity assessment” satisfies the business or the design requirements this specification complies to. It should be however clear that the compliance with specified business or the design requirements, for example in the future with the CEN prEN IPS, does not imply that the compliant implementations are technically interoperable. A “conformity assessment” is a process that assesses that any proposition that is true in a given specification, it is also true in the service or product that implements it. In most real-world cases conformance testing objects are used to technically validate the products. These objects provide a great help in the validation of the instances, even if it is not often these kind of validation is not self-sufficient to guarantee the functional/ semantic conformity: many real-life examples can be made about instances that are technically valid, but not clinically meaningful or correct.

<ref group="Figure" name="ipsworld"/> below depicts how this concept applies to the business requirements, the current and hopefully future IPS projects standards (CEN/TC 251 and HL7) and other related artefacts involved in this assessment chain. (see section [[#Relationships with other projects and guidelines | Relationships with other projects and guidelines]] for a description of the standards developed by the CEN/TC 251 IPS project )

{{IncludeImage|IPS_world.png|700px|80%}}

<ref group="Figure" name="ipsworld">The IPS World</ref> The IPS World

The "rules" and processes for refining the standard through constraint and extension, including which standard artifacts are subject to constraint or extension; the definition of constraint and localization profiles; the criteria for establishing a conformance statement; and the principles guiding who may define extensions to the standards and under what circumstances that applies to the CDA standards are defined in §1.3 CDA Conformance of the CDA and detailed in the HL7 V3 Refinement, Constraint and Localization section. (See the CDA R2 Standard<ref>CDA R2 Standard http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>)
There are no additional requirements to be applied for this guide for what concern the Recipient and the Originator Responsibilities.

The formal representation used in this implementation guide for expressing the conformance statement is described in section "[[Reading_Guide_for_Publication_Artefacts]]" of this guide and makes use of a tabular representation that may include also computable or textual constraints. The template rules are formalized using the computable format defined by the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1<ref name="teits">HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=377</ref> in order to facilitate also the automatic generation of consistent testing objects.

This standard (i.e. the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 ) defines also how derived templates may relate to the templates defined in this guide for example:
*Specialization: “A specialized template is a narrower, more explicit, more constrained template based on a “parent” template.
* Adaptation: “The adapted template is “based on” the original template which means it can be an extension or a specialization (restriction) of the original template design.”
* Equivalency: “two templates have the same purpose and the same design; however, their governance and/or metadata and/or details of their design may be different.”

Based on this the following way to use this guide may be considered :
* IPS as a document: the conformance is asserted at the document level. All the rules defined by this guide, or by a specialized IPS document level template, are fulfilled. Implementers may take advantage of the template openness to better support specific cases, “extended” parts may be however not interoperable among them.
* IPS as a library: the conformance is asserted at the section or the entry level. The templates are used as a library to build, for example, new cross-border documents. For example the immunization section may be used to build an electronics implementation of the WHO yellow card for vaccinations; or the used section to send back a cross border encounter report after the Patient Summary has been used. Implementers may take advantage of the template openness to better support specific cases, “extended” parts may be however not interoperable among them.
* IPS as a reference: the implementation is conformant with templates that are adaptation or equivalent to those defined by this guide. In this case some of the rules defined by this guide are not fulfilled and the conformance cannot be asserted. However differences may be limited and the effort required to achieve the harmonization be not so huge. Typical examples are templates in which alternatives vocabularies are used.

Jurisdiction may also decide to impose the closure of the template in order to limit the implementation optionality. This should be carefully evaluated in term of flexibility of the solution.



{{:IPS_Appendix_1}}

=List of all artifacts used in this guide=
==CDA Templates==
* [[2.16.840.1.113883.10.22.1.1]] International Patient Summary
* [[2.16.840.1.113883.10.22.2.1]] IPS CDA recordTarget
* [[2.16.840.1.113883.10.22.2.2]] IPS CDA author
* [[2.16.840.1.113883.10.22.2.3]] IPS CDA custodian
* [[2.16.840.1.113883.10.22.2.4]] IPS CDA legalAuthenticator
* [[2.16.840.1.113883.10.22.2.5]] IPS Patient Contacts
* [[2.16.840.1.113883.10.22.2.6]] IPS CDA documentationOf
* [[2.16.840.1.113883.10.22.2.7]] IPS CDA relatedDocument
* [[2.16.840.1.113883.10.22.3.1]] IPS Medication Summary Section
* [[2.16.840.1.113883.10.22.3.2]] IPS Allergies and Intolerances Section
* [[2.16.840.1.113883.10.22.3.3]] IPS Problems Section
* [[2.16.840.1.113883.10.22.3.4]] IPS History of Procedures Section
* [[2.16.840.1.113883.10.22.3.5]] IPS Immunizations Section
* [[2.16.840.1.113883.10.22.3.6]] IPS Medical Devices Section
* [[2.16.840.1.113883.10.22.3.7]] IPS History of Past Illness Section
* [[2.16.840.1.113883.10.22.3.8]] IPS Functional Status Section
* [[2.16.840.1.113883.10.22.3.9]] IPS Plan of Treatment Section
* [[2.16.840.1.113883.10.22.3.10]] IPS Social History Section
* [[2.16.840.1.113883.10.22.3.11]] IPS History of Pregnancy Section
* [[2.16.840.1.113883.10.22.3.12]] IPS Advance Directives Section
* [[2.16.840.1.113883.10.22.3.14]] IPS Results Section
* [[2.16.840.1.113883.10.22.3.15]] IPS Translation Section
* [[2.16.840.1.113883.10.22.4.1]] IPS Allergy or Intolerance
* [[2.16.840.1.113883.10.22.4.2]] IPS ManufacturedProduct
* [[2.16.840.1.113883.10.22.4.3]] IPS Manufactured Material
* [[2.16.840.1.113883.10.22.4.4]] IPS Medication Entry
* [[2.16.840.1.113883.10.22.4.5]] IPS Allergy and Intolerance Concern
* [[2.16.840.1.113883.10.22.4.6]] IPS Reaction Manifestation
* [[2.16.840.1.113883.10.22.4.7]] IPS Problem Concern Entry
* [[2.16.840.1.113883.10.22.4.8]] IPS Problem Entry
* [[2.16.840.1.113883.10.22.4.9]] IPS Result Organizer
* [[2.16.840.1.113883.10.22.4.10]] IPS Result Observation
* [[2.16.840.1.113883.10.22.4.11]] IPS Pathology Result Observation
* [[2.16.840.1.113883.10.22.4.12]] IPS Radiology Result Observation
* [[2.16.840.1.113883.10.22.4.13]] IPS Laboratory Result Observation
* [[2.16.840.1.113883.10.22.4.14]] IPS Body Author
* [[2.16.840.1.113883.10.22.4.15]] IPS Immunization
* [[2.16.840.1.113883.10.22.4.16]] IPS Immunization Medication Information
* [[2.16.840.1.113883.10.22.4.17]] IPS Procedure Entry
* [[2.16.840.1.113883.10.22.4.18]] IPS Criticality Observation
* [[2.16.840.1.113883.10.22.4.19]] IPS Certainty Observation
* [[2.16.840.1.113883.10.22.4.20]] IPS Problem Status Observation
* [[2.16.840.1.113883.10.22.4.21]] IPS Allergy Status Observation
* [[2.16.840.1.113883.10.22.4.22]] IPS Comment Activity
* [[2.16.840.1.113883.10.22.4.23]] IPS ObservationMedia
* [[2.16.840.1.113883.10.22.4.25]] IPS Severity Observation
* [[2.16.840.1.113883.10.22.4.26]] IPS Medical Device
* [[2.16.840.1.113883.10.22.4.27]] IPS Pregnancy Status Observation
* [[2.16.840.1.113883.10.22.4.28]] IPS Pregnancy Outcome Observation
* [[2.16.840.1.113883.10.22.4.29]] IPS Pregnancy Expected Delivery Date Observation
* [[2.16.840.1.113883.10.22.4.30]] IPS Specimen Collection
* [[2.16.840.1.113883.10.22.4.31]] IPS Internal Reference
* [[2.16.840.1.113883.10.22.4.33]] IPS Subordinate SubstanceAdministration
* [[2.16.840.1.113883.10.22.4.34]] IPS Social History Tobacco Use
* [[2.16.840.1.113883.10.22.4.35]] IPS Social History Alcohol Use
* [[2.16.840.1.113883.10.22.9.1]] IPS CDA Organization
* [[2.16.840.1.113883.10.22.9.2]] IPS CDA Device
* [[2.16.840.1.113883.10.22.9.3]] IPS CDA Person

==Value Sets ==
*[[2.16.840.1.113883.11.22.2]] Allergy or Intolerance Type
*[[2.16.840.1.113883.11.22.3]] Allergy Reaction
*[[2.16.840.1.113883.11.22.4]] ActStatusActiveCompleted
*[[2.16.840.1.113883.11.22.5]] CORE Problem List Disorders
*[[2.16.840.1.113883.11.22.6]] CORE Problem List Procedures
*[[2.16.840.1.113883.11.22.7]] CORE Problem List
*[[2.16.840.1.113883.11.22.8]] IPS Condition Verification Status
*[[2.16.840.1.113883.11.22.9]] Absent or Unknown Allergies
*[[2.16.840.1.113883.11.22.10]] Allergies to substances
*[[2.16.840.1.113883.11.22.11]] Adverse Reaction Agents
*[[2.16.840.1.113883.11.22.12]] ActStatusActiveCompletedAbortedSuspended
*[[2.16.840.1.113883.11.22.13]] Time units (UCUM)
*[[2.16.840.1.113883.11.22.14]] DRUGActCode
*[[2.16.840.1.113883.11.22.15]] Absent or Unknown Medication
*[[2.16.840.1.113883.11.22.16]] Problem Type
*[[2.16.840.1.113883.11.22.17]] Absent or Unknown Problems
*[[2.16.840.1.113883.11.22.18]] Problem Severity
*[[2.16.840.1.113883.11.22.19]] Language Code
*[[2.16.840.1.113883.11.22.20]] IPS Expected Delivery Date Method
*[[2.16.840.1.113883.11.22.21]] IPS Pregnancies Summary
*[[2.16.840.1.113883.11.22.22]] ActStatusActiveCompletedAbortedCancelled
*[[2.16.840.1.113883.11.22.23]] IPS Medical Devices
*[[2.16.840.1.113883.11.22.24]] IPS Condition Status Code
*[[2.16.840.1.113883.11.22.25]] Medicine Doseform
*[[2.16.840.1.113883.11.22.27]] Medicine Package
*[[2.16.840.1.113883.11.22.28]] Quantity Units
*[[2.16.840.1.113883.11.22.29]] WHO ATC
*[[2.16.840.1.113883.11.22.30]] Medicine Strength Numerator
*[[2.16.840.1.113883.11.22.31]] Medicine Strength Denominator
*[[2.16.840.1.113883.11.22.32]] Medicine Active Substances
*[[2.16.840.1.113883.11.22.33]] Medicine Route of Administration
*[[2.16.840.1.113883.11.22.34]] IPS No Drug Substances
*[[2.16.840.1.113883.11.22.35]] IPS Procedures
*[[2.16.840.1.113883.11.22.36]] Absent or Unknown Procedures
*[[2.16.840.1.113883.11.22.37]] IPS Results Organizer
*[[2.16.840.1.113883.11.22.38]] IPS Results Observation
*[[2.16.840.1.113883.11.22.39]] IPS Results Observation Laboratory
*[[2.16.840.1.113883.11.22.40]] IPS Results Observation Radiology
*[[2.16.840.1.113883.11.22.41]] IPS Results Observation Pathology
*[[2.16.840.1.113883.11.22.42]] IPS Allergy Status Code
*[[2.16.840.1.113883.11.22.43]] Absent or Unknown Immunization
*[[2.16.840.1.113883.11.22.44]] IPS Vaccines
*[[2.16.840.1.113883.11.22.45]] IPS Multingredients Products
*[[2.16.840.1.113883.11.22.46]] IPS Results Coded Values Laboratory
*[[2.16.840.1.113883.11.22.47]] IPS Results Coded Values Pathology
*[[2.16.840.1.113883.11.22.48]] IPS Results Coded Values Radiology
*[[2.16.840.1.113883.11.22.49]] IPS Results Microorganism
*[[2.16.840.1.113883.11.22.50]] IPS Results Blood Group phenotypes
*[[2.16.840.1.113883.11.22.51]] IPS Results ABO+RH GROUP
*[[2.16.840.1.113883.11.22.52]] IPS Results Presence/Absence
*[[2.16.840.1.113883.11.22.53]] IPS Healthcare Professional Roles

==Unconstrained Templates from the original CDA specification (no subject to ballot)==
* [[2.16.840.1.113883.10.12.151]] CDA Organization
* [[2.16.840.1.113883.10.12.152]] CDA Person
* [[2.16.840.1.113883.10.12.153]] CDA AssignedEntity
* [[2.16.840.1.113883.10.12.318]] CDA Author (Body)
* [[2.16.840.1.113883.10.12.315]] CDA Device
* [[2.16.840.1.113883.10.12.319]] CDA Informant (Body)
* [[2.16.840.1.113883.10.12.323]] CDA Performer (Body)
* [[2.16.840.1.113883.10.12.313]] CDA PlayingEntity
* [[2.16.840.1.113883.10.12.316]] CDA RelatedEntity

==Data Types ==
Data types for element definitions used
*AD – Address
*AD.IPS – IPS Address (see [https://art-decor.org/mediawiki/index.php?title=DTr1_AD.IPS])
*ANY – ANY
*BL – Boolean
*CD – Concept Descriptor
*CD.IPS – IPS CD (see [https://art-decor.org/mediawiki/index.php?title=DTr1_CD.IPS])
*CE – Coded with Equivalents
*CE.IPS – IPS CE (see [https://art-decor.org/mediawiki/index.php?title=DTr1_CE.IPS])
*CR – Concept Role
*CS – Coded Simple Value
*CV – Coded Value
*CV.IPS – IPS CV (see [https://art-decor.org/mediawiki/index.php?title=DTr1_CV.IPS])
*ED – Encapsulated Data
*EIVL.event – Event-Related Interval of Time
*EIVL_TS – Event-related time interval
*EN – Entity Name
*ENXP – Entity Name Part
*II – Instance Identifier
*INT – Integer
*IVL_PQ – Interval of Physical Quantity
*IVL_TS – Interval of Time Stamp
*IVL_TS.IPS.TZ – IPS IVL Time Stamp TZ (see [https://art-decor.org/mediawiki/index.php?title=DTr1_IVL_TS.IPS.TZ])
*IVL_TS.IPS.TZ.OPT
*IVXB_TS – Interval Boundary of Time Stamp
*ON – Organization Name
*PIVL_TS – Periodic Interval of Timezone
*PN – Person Name
*PQ – Physical Quantity
*SC – String with Codes
*SD.TEXT – Structured Document Text
*ST – Character String
*SXPR_TS – Parenthetic Set Expression of Time Stamp
*TEL – Telecommunication Address
*TEL.IPS – IPS TEL (see [https://art-decor.org/mediawiki/index.php?title=DTr1_IVL_TS.IPS.TZ.OPT])
*TS – Time Stamp
*TS.IPS.TZ – IPS Time Stamp TZ (see [https://art-decor.org/mediawiki/index.php?title=DTr1_TS.IPS.TZ])

Datatypes for attributes used
*bl – boolean code
*cs – code
*oid – identifier
*set_cs – code
*st – string
*uid – identifier

==Extensions==
===Common Product Model (CPM) ===
This specification uses an extension in order to reflect item from the Common Product Model (CPM), that is further described in [[ IPS_implementationguide_1#IPS_Design_conventions_and_principles_1|the section about the design conventions]] and that is used in template 2.16.840.1.113883.10.22.4.3 ''IPS Manufactured Material''. It uses the namespace <code>urn:hl7-org:cpm</code>. This is the list of elements defined for that template.
*cpm:asContent
*cpm:asSpecializedKind
*cpm:capacityQuantity
*cpm:code
*cpm:code
*cpm:containerPackagedProduct
*cpm:denominator
*cpm:formCode
*cpm:generalizedMaterialKind
*cpm:ingredient
*cpm:ingredientSubstance
*cpm:name
*cpm:numerator
*cpm:quantity
===Translation of designations===
The capability of recording multilingual designations for the exchanged Patent Summary is one of the functional requirements requested for “safety and liability reasons” by the European Cross-border services.
The IPS project recommends the introduction of an optional 'ips:designation' extension to the CD datatype to allow such translations properly.
*ips:designation

{{:Reading_Guide_for_Publication_Artefacts}}

=References=
==Literature==
* Whiting-O'Keefe QE, Simborg DW, Epstein WV, Warger A: A computerized summary medical record system can provide more information than the standard medical record. JAMA. 1985 Sep 6;254(9):1185-92.
* Boone KW: The CDA TM Book. Springer 2011, ISBN 978-0-85729-336-7

==Links==
<references/>

==Figures==
<references group="Figure"/>

IPS Design conventions and principles 1

2017-07-28T13:17:44Z

Pscott: /* 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 IPS 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.IPS 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.IPS 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-border 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, new concepts will be requested for inclusion in a future SNOMED CT International Edition release (anticipated for January 2018). While awaiting official publication in SNOMED CT, in this document these concepts are represented by temporary placeholder IDs beginning with 'X-' (e.g., X-noAllergiesInfo).

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: Data Types R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead is possible with Data Types 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; Data Types R1 does not allow the specification of this difference, that is that there are no codes applicable in the reference value set, as instead is possible with Data Types 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 xsi:type="CD" code="422479008" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<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, the IPS project recommends the introduction of an optional 'ips:designation' extension to the CD datatype that allows conveying both the designations and their languages. We propose to take this forward in discussion with the relevant Work Groups. The following are examples of the possible uses of this extension:

''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 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="..." extension="..."/>
<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 name="ccda21"/>''

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 name="ccda21"/>

'''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 name="ccda21">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 relying 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

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 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-28T13:16:40Z

Pscott: /* Translation of designations */

=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 IPS 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.IPS 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.IPS 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-border 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, new concepts will be requested for inclusion in a future SNOMED CT International Edition release (anticipated for January 2018). While awaiting official publication in SNOMED CT, in this document these concepts are represented by temporary placeholder IDs beginning with 'X-' (e.g., X-noAllergiesInfo).

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: Data Types R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead is possible with Data Types 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; Data Types R1 does not allow the specification of this difference, that is that there are no codes applicable in the reference value set, as instead is possible with Data Types 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 xsi:type="CD" code="422479008" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<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, the IPS project recommends the introduction of an optional 'ips:designation' extension to the CD datatype that allows conveying both the designations and their languages. We propose to take this forward in discussion with the relevant Work Groups. The following are examples of the possible uses of this extension:

''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 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="..." extension="..."/>
<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 name="ccda21"/>''

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 name="ccda21"/>

'''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 name="ccda21">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

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 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-28T13:15:32Z

Pscott: /* Unmapped 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 IPS 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.IPS 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.IPS 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-border 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, new concepts will be requested for inclusion in a future SNOMED CT International Edition release (anticipated for January 2018). While awaiting official publication in SNOMED CT, in this document these concepts are represented by temporary placeholder IDs beginning with 'X-' (e.g., X-noAllergiesInfo).

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: Data Types R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead is possible with Data Types 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; Data Types R1 does not allow the specification of this difference, that is that there are no codes applicable in the reference value set, as instead is possible with Data Types 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 xsi:type="CD" code="422479008" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<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, the IPS project recommends the introduction of an optional 'ips:designation' extension to the CD datatype that allows conveying both the designations and their languages. We propose to take this forward in discussion with the relevant Work Groups. The following are examples of the possible uses of this extension:

''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="..." extension="..."/>
<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 name="ccda21"/>''

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 name="ccda21"/>

'''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 name="ccda21">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

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 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-28T13:13:59Z

Pscott: /* 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 IPS 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.IPS 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.IPS 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-border 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, new concepts will be requested for inclusion in a future SNOMED CT International Edition release (anticipated for January 2018). While awaiting official publication in SNOMED CT, in this document these concepts are represented by temporary placeholder IDs beginning with 'X-' (e.g., X-noAllergiesInfo).

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: Data Types R1 doesn't allow specifying that there are no codes applicable in the referred value set, as instead is possible with Data Types 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; Data Types R1 doesn't allow the specification of this difference, that is that there are no codes applicable in the reference value set, as instead is possible with Data Types 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 xsi:type="CD" code="422479008" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2">
<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, the IPS project recommends the introduction of an optional 'ips:designation' extension to the CD datatype that allows conveying both the designations and their languages. We propose to take this forward in discussion with the relevant Work Groups. The following are examples of the possible uses of this extension:

''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="..." extension="..."/>
<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 name="ccda21"/>''

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 name="ccda21"/>

'''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 name="ccda21">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

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 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 Introduction 1

2017-07-28T13:08:01Z

Pscott: /* General Principles for this Specification */

=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 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 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®<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"/>. 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-28T13:07:36Z

Pscott: /* Scope */

=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 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 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®<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"/>. 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 implementationguide 1

2017-05-16T10:07:42Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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.

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T09:11:04Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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 then '''not''' the same as legalAuthenticator. However, in cases where the verifying person intentionally wishes to sign the document, this shall be recorded as a legalAuthenticator.
*Allow optional section level author, provenance type, verifier and informant identification, for IPS source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:30:03Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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.
*Allow optional section level author, provenance type, verifier and informant identification, for IPS source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:29:03Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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", the author shall be the device or system that constructed the IPS document, but an additional "verifier" identify shall name the human who performed this check. For the avoidance of doubt, this is NOT the same as legalAuthenticator.
*Allow optional section level author, provenance type, verifier and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:28:31Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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" may 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", the author shall be the device or system that constructed the IPS document, but an additional "verifier" identify shall name the human who performed this check. For the avoidance of doubt, this is NOT the same as legalAuthenticator.
*Allow optional section level author, provenance type, verifier and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:27:59Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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 provenance type and document "author".
**The "author" may 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", the author shall be the device or system that constructed the IPS document, but an additional "verifier" identify shall name the human who performed this check. For the avoidance of doubt, this is NOT the same as legalAuthenticator.
*Allow optional section level author, provenance type, verifier and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:27:02Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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 source system to identify the IPS provenance type and document "author".
**The "author" may 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", the author shall be the device or system that constructed the IPS document, but an additional "verifier" identify shall name the human who performed this check. For the avoidance of doubt, this is NOT the same as legalAuthenticator.
*Allow optional section level author, provenance type, verifier and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:26:31Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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 source system to identify the IPS provenance type and document "author".
**The "author" may 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", the author shall be the device or system that constructed the IPS document, but an additional "verifier" identify shall name the human who performed this check. For the avoidance of doubt, this is NOT the same as legalAuthenticator.
*Allow optional section level author, provenance type, verifier and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:21:56Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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 source system to identify the IPS provenance type and document "author".
**The "author" may be a human, if the IPS provenance type is "human-curated", or a device or system if the IPS provenance type is "software-assembled".
*Allow optional section level author and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:21:01Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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 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 source system to identify the IPS provenance type and document "author".
**The "author" may be a human, if the IPS provenance type is "human-curated", or a device or system if the IPS provenance type is "software-assembled".
*Allow optional section level author and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-16T08:14:32Z

Pscott: /* Purpose */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

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

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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 provenance as one of three types: human-curated, software-assembled or hybrid (some curated, some assembled content). '''[QUESTION: if some curated, then it is "assembled"?]'''
*Require the source system to identify the provenance type and "author".
*Allow optional section level author and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-15T12:50:16Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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 provenance as one of three types: human-curated, software-assembled or hybrid (some curated, some assembled content). '''[QUESTION: if some curated, then it is "assembled"?]'''
*Require the source system to identify the provenance type and "author".
*Allow optional section level author and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-15T12:44:18Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

Public
*Citizens who want to carry or access their healthcare data for emergency care purposes.
Regulatory
*Policy makers such as healthcare payers or government agencies.
*Healthcare information governance authorities and regulatory bodies.
Clinical
*Healthcare providers that offer unscheduled and emergency care.
*Healthcare providers that populate regional and national patient summaries.
Technical
*Vendors of EHRs unplanned care system, personal health records and mobile health data applications.
*System integrators.
*Organizations that manage regional and national patient summaries.

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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). This matrix offers 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 provenance as one of three types: human-curated, software-assembled or hybrid (some curated, some assembled content). '''[QUESTION: if some curated, then it is "assembled"?]'''
*Require the source system to identify the provenance type and "author".
*Allow optional section level author and informant identification, for source systems that can support this.
*Not attempt to implement the US Realm CDA data provenance templates.

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

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T14:09:32Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

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

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

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

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

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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). This matrix offers 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.

Approach proposed for this version of the IPS
*Document-level not section level
*Not impose the data provenance templates
*Briefly describe how contextual information related to the provenance (e.g. authorship; authenticators; informant;…) can be managed in a CDA.
*Explicitly include as optional elements at the section level author and informant (Last call on May 3rd) [no specific constraints applied]
*Types: human-curated, assembled, hybrid; responsibility on source system to identify.
**Device author
**Human author
**Both kinds

Possible future work: IPS functional profile by EHR WG

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T13:45:32Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

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

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

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

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

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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). This matrix offers a thorough and systematic analysis of provenance characteristics of electronic health records. Given the design 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.

Approach proposed for this version of the IPS
*Document-level not section level
*Not impose the data provenance templates
*Briefly describe how contextual information related to the provenance (e.g. authorship; authenticators; informant;…) can be managed in a CDA.
*Explicitly include as optional elements at the section level author and informant (Last call on May 3rd) [no specific constraints applied]
*Types: human-curated, assembled, hybrid; responsibility on source system to identify.
**Device author
**Human author
**Both kinds

Possible future work: IPS functional profile by EHR WG

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T13:40:35Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

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

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

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

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

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

In 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). This matrix offers a thorough and systematic analysis of provenance characteristics of electronic health records. Given the design 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.

Approach proposed for this version of the IPS
*Document-level not section level
*Not impose the data provenance templates
*Include in the initial part of the Implementation guide sections dedicated to the provenance
*Briefly describe how contextual information related to the provenance (e.g. authorship; authenticators; informant;…) can be managed in a CDA.
*Mention as reference the Provenance CDA IG
*Explicitly include as optional elements at the section level author and informant (Last call on May 3rd) [no specific constraints applied]
*Types: human-curated, assembled, hybrid; responsibility on source system to identify.
**Device author
**Human author
**Both kinds

Possible future work: IPS functional profile by EHR WG

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T13:21:39Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

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

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

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

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

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

Document-level not section level

Cite types: human-curated, assembled, hybrid; responsibility on source system to identify.

Possible future work: IPS functional profile by EHR WG

From EHR WG slides:

*An initial discussion on provenance was started in the Paris meeting
*the HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 - US Realm Draft Standard for Trial Use December 2015 was briefly analyzed
*Several required constraints. Perceived difficult to be concretely implemented today based on the maturity of «systems»

Approach proposed for this version of the IPS
*Not impose the data provenance templates
*Include in the initial part of the Implementation guide sections dedicated to the provenance
*Briefly describe how contextual information related to the provenance (e.g. authorship; authenticators; informant;…) can be managed in a CDA.
*Mention as reference the Provenance CDA IG
*Explicitly include as optional elements at the section level author and informant (Last call on May 3rd) [no specific constraints applied]

Current use in EU specification this information is derived by the authors (not so specific…)
*Device author
*Human author
*Both kinds

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T13:20:05Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

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

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

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

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

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

Document-level not section level

Cite types: human-curated, assembled, hybrid; responsibility on source system to identify.

Possible future work: IPS functional profile by EHR WG

From EHR WG slides:

*An initial discussion on provenance was started in the Paris meeting
*the HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 - US Realm Draft Standard for Trial Use December 2015 was briefly analyzed
*Several required constraints. Perceived difficult to be concretely implemented today based on the maturity of «systems»

Approach proposed for this version of the IPS
*Not impose the data provenance templates
*Include in the initial part of the Implementation guide sections dedicated to the provenance
*Briefly describe how contextual information related to the provenance (e.g. authorship; authenticators; informant;…) can be managed in a CDA.
*Mention as reference the Provenance CDA IG
*Explicitly include as optional elements at the section level author and informant (Last call on May 3rd) [no specific constraints applied]

Current use in EU specification this information is derived by the authors (not so specific…)
*Device author
*Human author
*Both kinds

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T13:16:42Z

Pscott: /* Provenance */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

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

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

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

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

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

Document-level not section level

Cite types: human-curated, assembled, hybrid; responsibility on source system to identify.

Possible future work: IPS functional profile by EHR WG

From EHR WG slides:

An initial discussion on provenance was started in the Paris meeting
the HL7 CDA® Release 2 Implementation Guide: Data Provenance, Release 1 - US Realm Draft Standard for Trial Use December 2015 was briefly analyzed
Several required constraints. Perceived difficult to be concretely implemented today based on the maturity of «systems»

Approach proposed for this version of the IPS
Not impose the data provenance templates
Include in the initial part of the Implementation guide sections dedicated to the provenance
Briefly describe how contextual information related to the provenance (e.g. authorship; authenticators; informant;…) can be managed in a CDA.
Mention as reference the Provenance CDA IG
Explicitly include as optional elements at the section level author and informant (Last call on May 3rd) [no specific constraints applied]

Current use in EU specification this information is derived by the authors (not so specific…)
Device author
Human author
Both kinds

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T11:08:28Z

Pscott: /* Principle on negations, data known absent and data unknown */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

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

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

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

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

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

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

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

Document-level not section level

Cite types: human-curated, assembled, hybrid; responsibility on source system to identify.

Possible future work: IPS functional profile by EHR WG

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T11:06:21Z

Pscott: /* Principle on negations, data known absent and data unknown */

__NOTOC__
{{Infobox_Document
|Title = HL7 International Patient Summary<br/>based on Clinical Document Architecture Release 2
|Short = International Patient Summary
|Namespace = cdaips
|Type = Implementation Guide
|Version = 0.10
|Submitted = HL7 International
|Date = 21. March 2017
|Status = Draft
|Period = Draft
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2017 Health Level Seven International ® ALL RIGHTS RESERVED.<br/>The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
}}

{{:HL7_Important_Note}}

{{:Authors_and_Contributors}}

__TOC__
=Introduction=

{{Responsible|Philip Scott}}
{{Review}}

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

==Purpose==

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

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

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

The international patient summary defines SNOMED CT as the primary terminology (the meaning of "primary terminology" is discussed further in [[IPS_implementationguide_1#Notion_of_.22Primary_Code.22|a later section]]) for the majority of value sets, but uses LOINC for laboratory tests, UCUM for units of measure and EDQM for dose forms and routes.

=== Background ===

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

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

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

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

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

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

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

A. The standards specification for the IPS will be implementable
*Promote (the evolution and convergence of) existing standards
*Rely on solutions that are already implemented or ready for implementation
*Consider new or additional solutions as they become available

B. The standards specification for the IPS will be applicable for global use
*Strive for global accessibility of standards for free
*Strive for a core set of globally accessible and usable terminologies and value sets
*Include free text in addition to the structured codes as needed
*Do not include local solutions in the core specification that are not available in other jurisdictions

C. The standards specification will be extensible and open to future use cases and solutions
*The IPS provides common content that can be extended and specialized for other use cases, or localized for specific jurisdictional needs
*The IPS is open to emerging solutions for unresolved issues or improvements

D. The standards specifications and their implementation must be sustainable through:
*A robust maintenance and update process for the IPS
*A process to ensure clinical validity of the IPS, meeting:
**clinical requirements (including workflow)
**clinical documentation requirements
**information quality requirements

E. We will manage the expectations of the IPS standards specifications among stakeholders, by
*stipulating the role of the IPS as a foundation for others to extend
*justifying the inclusion of items in the IPS within the limited context of unplanned (cross-border) care.

==Ballot Status of the Document==
This Implementation Guide is STU with the intention to go normative.

==Audience==
The audience for this Implementation Guide includes:

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

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

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

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

==Relationships with other projects and guides==
*CEN/TC 251 International Patient Summary
*epSOS/EXPAND/eHDSI
*C-CDA
*IHE-PCC
*Input from the EHR work group about how to define the source(s) of the IPS content, described in the [[IPS_implementationguide_1#Provenance|provenance]] section .

==How to read this document==
'''Kai to write a paragraph'''

=Principles and background=
{{Responsible|Kai Heitmann, Giorgio Cangioli}}
== IPS Principles ==
''(here or in the introduction?)''
==What is a CDA==
==Templated CDA==
==Open and Closed Templates==
==Template versioning==
==Identifiers==
*(OID,...)
==Terminologies==
*Focus on Value Sets
===How to extend Value Sets===
==Datatypes used in this guide==
==Design conventions and principles==
===How to use terminology (preferred binding)===
{{Responsible|Rob Hausam}}
===Notion of "Primary Code"===
{{Responsible|Rob Hausam}}
===Usage of translations===
{{Responsible|Rob Hausam}}
===Principle on negations, data known absent and data unknown ===
{{Responsible|Philip Scott, Giorgio Cangioli, Kai Heitmann, Francois Macary}}

This specification represents negations, known absent data and unknown data by leveraging the expressiveness of SNOMED CT to use explicit coded elements rather than negation indicators or null flavours. In some cases this requires the creation of new SNOMED CT concepts. For example, an

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

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

== Provenance ==
{{Responsible|Philip Scott; Gary Dickinson }}

Document-level not section level

Cite types: human-curated, assembled, hybrid; responsibility on source system to identify.

Possible future work: IPS functional profile by EHR WG

==General implementation guidance==
{{Responsible|Kai Heitmann}}
How to populates IDs, where I can get IDs

Relevant times for a patient summary

Description of the different status definitions

Authorship

Go here or somewhere else?

==Standards used==
SNOMED-CT, ...
==Legend==
Description of formalisms used, symbols, icons, how to read ART-DECOR tables

=Conformance clause=
{{Responsible|Steven Chu}}
Different conformance levels (to be explored)

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



=Appendix=
{{Responsible|NN}}
==Acronyms and abbreviations ==
==Glossary ==
==Licenses (for the artifacts used, for the code systems, etc.) ==
==Integrated examples, links to instances ==
{{Responsible|Kai Heitmann}}
==Validation artifacts (xsd, schematrons) ==
{{Responsible|Kai Heitmann}}
==Links to platforms, binaries, software libraries ==
==Operational information (helpdesk, actual server endpoints for testing/production/validation) ==
==FAQ’s ==
==References / Literature ==
==How to reuse this template==

=List of all artifacts used in this guide=
{{Responsible|Autogenerated, assisted by Kai Heitmann}}
==System OIDs / IDs ==
==Code systems ==
==CDA Templates (list of)==
==Value Sets ==
==Summary tables ==

=Examples (in progress)=
{{Responsible|NN}}

IPS implementationguide 1

2017-05-11T11:04:38Z

Pscott: /* Principle on negations, data known absent and data unknown */

IPS implementationguide 1

2017-05-11T10:34:46Z

Pscott: /* Relationships with other projects and guides */

IPS implementationguide 1

2017-05-11T10:31:21Z

Pscott: /* Purpose */

IPS implementationguide 1

2017-05-11T10:30:28Z

Pscott: /* Purpose */

IPS implementationguide 1

2017-05-11T10:27:30Z

Pscott: /* Principle on negations, data known absent and data unknown */

IPS implementationguide 1

2017-05-11T10:25:41Z

Pscott: /* Relationships with other projects and guides */

IPS implementationguide 1

2017-05-11T10:24:50Z

Pscott: /* Ballot Status of the Document */

IPS implementationguide 1

2017-05-11T10:24:08Z

Pscott: /* Background */

IPS implementationguide 1

2017-05-11T10:22:15Z

Pscott: /* Background */

IPS implementationguide 1

2017-05-11T10:20:55Z

Pscott: /* Purpose */

IPS implementationguide 1

2017-05-11T10:19:46Z

Pscott: /* Purpose */

IPS implementationguide 1

2017-05-11T10:17:49Z

Pscott: /* Relationships with other projects and guides */

IPS implementationguide 1

2017-05-11T10:15:34Z

Pscott: /* Scope */

IPS implementationguide 1

2017-05-11T10:14:49Z

Pscott: /* Scope */

IPS implementationguide 1

2017-05-11T10:14:12Z

Pscott: /* Scope */

IPS implementationguide 1

2017-05-11T10:13:08Z

Pscott: /* Scope */

IPS implementationguide 1

2017-05-11T10:12:06Z

Pscott: /* Scope */

IPS implementationguide 1

2017-05-11T10:11:29Z

Pscott: /* Scope */

IPS implementationguide 1

2017-05-11T10:09:30Z

Pscott: /* Scope */

IPS implementationguide 1

2017-05-11T09:24:35Z

Pscott: /* Purpose */

IPS implementationguide 1

2017-05-11T09:23:30Z

Pscott: /* Relationships with other projects and guides */