HL7 IPS - User contributions [en]

IPS implementationguide 1

2018-09-06T08:00:29Z

Gcangioli:

__NOTOC__
{{Infobox_Document
|Title = HL7 CDA® R2 Implementation Guide<br/>International Patient Summary<br/>STU Release 1 (Universal Realm)
|Short = International Patient Summary
|Namespace = cdaips
|Type = Standard for Trial Use
|Version = 1.86
|Sponsored = 
|Date = September 6, 2018
|Status = Final
|Period = STU
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2018 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.<br>Use of this material is governed by HL7's IP Compliance Policy.
|Topright = CDAR2_INTLPATSUMMARY_STU_R1_2018SEP
}}

{{: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 to this guide, and how other artifacts 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 the subject of a “conformity assessment” satisfies the business or the design requirements this specification complies to. It should, however, be clear that compliance with the specified business or design requirements, for example in the future with the CEN prEN 17269 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 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 they are most often not 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"></ref> 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 artifacts 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 they apply 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>).

This guide does not provide additional requirements regarding the Recipient and the Originator Responsibilities.

The formal representation used in this implementation guide for expressing the conformance statement is described in chapter "How to read the table view for templates" 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 and validation capabilities.

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, however, may not be 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 electronic implementation of the WHO yellow card for vaccinations; or the IPS section templates are used to communicate to the country of affiliation minimal and non-exhaustive information about the encounter in which the Patient Summary has been used (cross-border encounter report ). Implementers may take advantage of the template openness to better support specific cases - "extended” parts, however, may not be interoperable among them.
* IPS as a reference: the implementation is conformant with templates that are an adaptation of 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 may not be not large. Typical examples are templates in which alternatives vocabularies are used.

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

{{:IPS_Alltemplates}}

{{: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 Care 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
*[[2.16.840.1.113883.10.22.11]] IPS Address

==CDA Template References ==
* [[2.16.840.1.113883.10.21.9.1]] UV Use Period

==Unconstrained Templates from the original CDA specification ==
* [[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

==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.5]] CORE Problem List Disorders
*[[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
*[[2.16.840.1.113883.11.22.54]] IPS Personal Relationship
*[[2.16.840.1.113883.11.22.55]] IPS Target Site
*[[2.16.840.1.113883.11.22.56]] IPS Specimen Type
*[[2.16.840.1.113883.11.22.57]] Laterality (qualifier)
*[[2.16.840.1.113883.11.22.58]] Topographical modifier (qualifier)
*[[2.16.840.1.113883.11.22.59]] IPS Current Smoking Status
*[[2.16.840.1.113883.11.22.60]] Allergy-intolerance Criticality

==Value Sets References==
*[[2.16.840.1.113883.1.11.1]] AdministrativeGender
*[[2.16.840.1.113883.1.11.10706]] Timing Event
*[[2.16.840.1.113883.1.11.11610]] x_ActRelationshipDocument
*[[2.16.840.1.113883.1.11.15933]] ActStatus
*[[2.16.840.1.113883.1.11.16926]] HL7 BasicConfidentialityKind
*[[2.16.840.1.113883.1.11.19446]] x_ActRelationshipEntry
*[[2.16.840.1.113883.1.11.19563]] PersonalRelationshipRoleType
*[[2.16.840.1.113883.1.11.19601]] x_ServiceEventPerformer
*[[2.16.840.1.113883.1.11.19709]] ActSubstanceAdministrationImmunizationCode
*[[2.16.840.1.113883.1.11.19890]] x_ActStatusActiveComplete
*[[2.16.840.1.113883.1.11.201]] TelecommunicationAddressUse
*[[2.16.840.1.113883.1.11.20386]] SeverityObservationCode
*[[2.16.840.1.113883.1.11.78]] Observation Interpretation
*[[2.16.840.1.113883.11.20.9.18]] MoodCodeEvnInt
*[[2.16.840.1.113883.11.20.9.33]] INDRoleclassCodes
*[[2.16.840.1.113883.3.88.12.80.60]] Social History Type

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

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

==Extensions==
=== Detailed medications information ===
This specification uses CDA extensions in order to provide details about medications, as further described in the section on the design conventions for [[ IPS_implementationguide_1#Medicinal_Product_Identification|Medicinal Product Identification]] and as used in template 2.16.840.1.113883.10.22.4.3 ''IPS Manufactured Material''. The extension uses the namespace <code>urn:hl7-org:pharm</code>.

This is the list of elements defined for that template.

*pharm:formCode (Administrable Pharmaceutical Dose Form)
*pharm:asContent (Packaging of the medication)
**pharm:quantity
**pharm:containerPackagedMedicine (Most inner Package Item or the Packaged Medicinal Product)
***pharm:code
***pharm:name (Name of the Package Item or of the Packaged Medicinal Product)
***pharm:formCode (type of the most inner package item or of the or the Packaged Medicinal Product)
***pharm:capacityQuantity (the functional capacity of the container)
***pharm:asContent (Containing package)
****pharm:quantity
****pharm:containerPackagedMedicine (Intermediate Package Item or the Packaged Medicinal Product)
*****pharm:code
*****pharm:name (Name of the Package Item or of the Packaged Medicinal Product)
*****pharm:formCode (type of the intermediate package item or of the or the Packaged Medicinal Product)
*****pharm:capacityQuantity (the functional capacity of the container)
*****pharm:asContent (Containing package)
******pharm:quantity
******pharm:containerPackagedMedicine (Packaged Medicinal Product)
*******pharm:code
*******pharm:name (Name of the Packaged Medicinal Product)
*******pharm:formCode (type of the Packaged Medicinal Product)
*******pharm:capacityQuantity (the functional capacity of the container)
*pharm:asSpecializedKind (used to represent any classification of the product (ATC code, future PhPIDs,..) )
**pharm:generalizedMaterialKind
***pharm:code
***pharm:name
*pharm:ingredient (list of active substances used for this product)
**pharm:quantity (strength)
**pharm:ingredientSubstance (active substance)
***pharm:code
***pharm:name

===Translation of designations===
This specification recommends the introduction of an optional extension for properly recording multilingual designations, that is further described in the [[IPS_implementationguide_1#Translation_of_designations_2|section on the translation of designations]]
*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"/>

[[Category:IG]]

File:IPS world.png

2018-07-17T10:22:52Z

Gcangioli: Gcangioli uploaded a new version of File:IPS world.png

IPS Design conventions and principles 1

2018-07-17T09:53:55Z

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

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated in section 1.5, 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 or EDQM Standard Terms. In some selected cases, in consideration of the availability of other globally usable reference terminologies and for alignment with a future FHIR version of the IPS, FHIR-defined terminologies have been specified. These 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; unless exceptions have been agreed.
* The 'displayName' of the Primary Code '''SHALL''' be populated with a term representing this same code in the terminology used, 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 'displayName'.
* In case the primary code is derived from an alternate terminology the alternate code '''SHOULD''' be provided in the translation element.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.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 (“general condition/activity unknown” and “general condition/activity/known absent” ) using explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes or human readable text (possibly not understood by the foreign country receiver).

In contrast to the practice to use negationInd or nullFlavor attributes on a section itself, we prohibit the use of these attributes on section level to express “unknown” or “no information” situations. A section holds the categorized (coded) narrative part of the documented activity and will never carry negationInd or nullFlavor attributes. Instead, we enforce by design, that “unknown” or “no information” expressions always go to the coded entry with a corresponding act code.

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 make clinical content representation 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 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.

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.

When needed, more specific statements such as the absence of a specific condition or activity, although considered as beyond the set of essential data for IPS, can still be expressed by using the native negationInd attribute of CDA R2.

==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 ''Required'' (aka 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 data type to better support this situation.''

The second case, that applies both to ''Required'' (aka CNE, coded no extensions) and ''Extensible'' (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 code to be used here would be "UNC" (Uncoded). This code is available in the current and other recent versions of the HL7 RIM, but it is not present in version 2.07 of the RIM on which the CDA R2 standard is based. In the absence of "UNC", the most appropriate NullFlavor code to use for representing that the data is unable to be coded is "NI".''

== 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, it is recommended to populate the original code in the IPS instance (in a 'translation' sub-element), with a nullFlavor indicating that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.). The nullFlavor value depends upon the coding strength of the binding.

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

In the case of coding strength Required (CNE), use nullFlavor "OTH":

<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 there are no codes applicable in the reference value set, which is possible with Data Types R2.''

''Future versions of this guide may consider extending the data type to better support this situation.''

In the case of Extensible (CWE) coding strength, this guide recommends representing the original code in the <translation> sub-element and using a nullFlavor for the primary code. This highlights the fact that a mapping to the reference value set was attempted, but no suitable target codes were identified.

<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 set. When this occurs, both the original and the reference codes should be reported in the IPS instance.

Functional requirements exposed in [[#Concept code mapping|section 3.1]] (multi-coding, link to original text, mapping between codes of the same code system) are also detailed below.

Case 1: Single local code mapped to primary code from the reference value set.

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

Case 2: Multiple local codes mapped together using nested 'translation' elements, and mapped to the primary code from the reference value set.

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

Case 3: 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 data type 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. Data Types 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).

Given that the base CDA R2 standard which uses datatypes R1 does not offer a native way to convey the language translation of 'displayName', this guide introduces an optional 'ips:designation' extension to the CD datatype for that purpose.

Below are examples of usage 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 language="it-IT">Profilo Sanitario Sintetico</ips:designation>
<ips:designation language="fr-FR">Patient Summary</ips:designation>
<ips:designation language="en">Patient Summary</ips:designation>
</code>
</syntaxhighlight>

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

== Narrative Translations ==

“Narrative translation” means 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 with this process are described in the [[#Designations’ Translation| Designations’ Translation]] section under [[#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.

Regarding the translation of section narrative <text>, this guide recommends providing this translation on purely textual subordinate sections (one per translation) as specified in the IPS Translation Section (2.16.840.1.113883.10.22.3.15) template.

An example of this is:

<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"></ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime).
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 became inactive, and it is present if the statusCode of the concern act is "completed". If this date is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

'''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 specialized 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 (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"></ref>

'''Confirmation status'''

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

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

A medication list 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 is still true also for the medication summary in a Patient Summary. It could be, for instance, a list of "Relevant prescribed medicines whose period of time indicated for the treatment has not yet expired whether it has been dispensed or not" (European guidelines on Patient Summary <ref>EHN Guideline on the electronic exchange of health data under Cross-Border Directive 2011/24/EU. Release 2. (https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Business+Analysis+and+Requirements+Management?preview=/55878732/55878698/(Adopted)%20Patient%20Summary%20Guideline%20cross-border%20exchange%20of%20health%20data%20(release%202).pdf</ref>); a list of actually dispensed medications; a list of relevant medications for the patient (IHE PCC <ref>IHE Patient Care Coordination Technical Framework http://ihe.net/Technical_Frameworks/#pcc</ref>); or conversely, it could be 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>).

Moreover, for the scope of the International Patient Summary, it is important to know what medications are being taken by or have been given to a patient; without necessarily providing all the details about the medication order, supply, administration or monitoring. 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 IPS medication summary is therefore a list of relevant medication statements, possibly built from either a prescription list or a dispensation list. In fact, in many practical cases data included in a Patient Summary are derived from the list of the medicines prescribed by a GP and recorded in its EHR-S; or extracted from a in regional/national prescribing and/or dispensation systems. In these cases, data obtained from actual dispensation and/or prescription records can be still recorded in the IPS as statements and the original request, supply or administration records referred by the statement if really needed.

==Medicinal Product Identification==

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

The set of ISO standards called IDMP<ref>IDMP standards https://www.idmp1.com/idmp-standards</ref> - designed initially for the regulatory scope, 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>European project OpenMedicine 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. Nonetheless, it takes into account, however, relevant IDMP identifiers and attributes which are already usable in the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depend on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while the 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 the absence of a global identification system for medicinal products, the solution proposed here 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.

Medication data is 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 the CDA model has been extended enhancing the Manufactured Material class with attributes and relationships derived from the latest published version of the R_Medication CMET (see HL7 V3 Normative Edition 2017) based on the HL7 Common Product 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.”'') .

<ref group="Figure" name="cdaextensions"></ref> shows how the CDA model has been enhanced with the R_Medication CMET.

{{IncludeImage|IPS extensions.png|700px|90%}}

<ref group="Figure" name="cdaextensions">CDA model has been enhanced with the R_Medication</ref>Extension of the CDA model from the content of the R_Medication CMET.

== 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:
*Allow optional documentation of section-level provenance.
*Require document-level provenance.
*Define IPS document provenance as one of two types: human-curated or software-assembled, based on the authors recorded in the header.
**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 (the verifier is represented as a participant with typeCode "VRF"). 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.''

== Representation of Names ==

This specification requires that any Person Name is represented including at least the given and family components and therefore is never documented as a single string.

Even though it is recognized that there is not in all cultures the same concept of “family name”, no evidence has been collected in analyzing the international context (e.g. Japan, Korea; China) that justifies the retirement of this requirement.

Moreover, due to the global scope of the International Patient Summary, the case of non-alphabetic representations of the names has also been considered.

In this case, to facilitate the global use of the IPS, at least one alphabetic representation of the name SHALL be provided.

IPS Design conventions and principles 1

2018-07-17T08:47:49Z

Gcangioli: /* Provenance */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated in section 1.5, 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 or EDQM Standard Terms. In some selected cases, in consideration of the availability of other globally usable reference terminologies and for alignment with a future FHIR version of the IPS, FHIR-defined terminologies have been specified. These 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; unless exceptions have been agreed.
* The 'displayName' of the Primary Code '''SHALL''' be populated with a term representing this same code in the terminology used, 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 'displayName'.
* In case the primary code is derived from an alternate terminology the alternate code '''SHOULD''' be provided in the translation element.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.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 (“general condition/activity unknown” and “general condition/activity/known absent” ) using explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes or human readable text (possibly not understood by the foreign country receiver).

In contrast to the practice to use negationInd or nullFlavor attributes on a section itself, we prohibit the use of these attributes on section level to express “unknown” or “no information” situations. A section holds the categorized (coded) narrative part of the documented activity and will never carry negationInd or nullFlavor attributes. Instead, we enforce by design, that “unknown” or “no information” expressions always go to the coded entry with a corresponding act code.

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 make clinical content representation 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 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.

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.

When needed, more specific statements such as the absence of a specific condition or activity, although considered as beyond the set of essential data for IPS, can still be expressed by using the native negationInd attribute of CDA R2.

==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 ''Required'' (aka 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 data type to better support this situation.''

The second case, that applies both to ''Required'' (aka CNE, coded no extensions) and ''Extensible'' (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 code to be used here would be "UNC" (Uncoded). This code is available in the current and other recent versions of the HL7 RIM, but it is not present in version 2.07 of the RIM on which the CDA R2 standard is based. In the absence of "UNC", the most appropriate NullFlavor code to use for representing that the data is unable to be coded is "NI".''

== 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, it is recommended to populate the original code in the IPS instance (in a 'translation' sub-element), with a nullFlavor indicating that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.). The nullFlavor value depends upon the coding strength of the binding.

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

In the case of coding strength Required (CNE), use nullFlavor "OTH":

<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 there are no codes applicable in the reference value set, which is possible with Data Types R2.''

''Future versions of this guide may consider extending the data type to better support this situation.''

In the case of Extensible (CWE) coding strength, this guide recommends representing the original code in the <translation> sub-element and using a nullFlavor for the primary code. This highlights the fact that a mapping to the reference value set was attempted, but no suitable target codes were identified.

<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 set. When this occurs, both the original and the reference codes should be reported in the IPS instance.

Functional requirements exposed in [[#Concept code mapping|section 3.1]] (multi-coding, link to original text, mapping between codes of the same code system) are also detailed below.

Case 1: Single local code mapped to primary code from the reference value set.

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

Case 2: Multiple local codes mapped together using nested 'translation' elements, and mapped to the primary code from the reference value set.

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

Case 3: 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 data type 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. Data Types 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).

Given that the base CDA R2 standard which uses datatypes R1 does not offer a native way to convey the language translation of 'displayName', this guide introduces an optional 'ips:designation' extension to the CD datatype for that purpose.

Below are examples of usage 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 language="it-IT">Profilo Sanitario Sintetico</ips:designation>
<ips:designation language="fr-FR">Patient Summary</ips:designation>
<ips:designation language="en">Patient Summary</ips:designation>
</code>
</syntaxhighlight>

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

== Narrative Translations ==

“Narrative translation” means 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 with this process are described in the [[#Designations’ Translation| Designations’ Translation]] section under [[#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.

Regarding the translation of section narrative <text>, this guide recommends providing this translation on purely textual subordinate sections (one per translation) as specified in the IPS Translation Section (2.16.840.1.113883.10.22.3.15) template.

An example of this is:

<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"></ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime).
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 became inactive, and it is present if the statusCode of the concern act is "completed". If this date is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

'''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 specialized 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 (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"></ref>

'''Confirmation status'''

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

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

What a medication 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 of attributes is still useful when limiting the scope to the medication summary within a Patient Summary. This medication summary could be, for instance, the list of all prescribed medicines whose indicated treatment period has not yet expired, regardless of 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 could also be narrowed down to the actually dispensed medications. Or conversely, it could be 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>). It could also be simply stated as 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 are not relevant for an IPS. It is important, however, to know what medications are being taken by or have been given to a patient, independent of 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 is therefore a list of relevant medication statements, built from either a prescription list 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 cases, data obtained from actual dispensation and/or prescription records can be recorded as statements and the original request, supply or administration records may be referred to from the statement if really needed.

==Medicinal Product Identification==

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

The set of ISO standards called IDMP<ref>IDMP standards https://www.idmp1.com/idmp-standards</ref> - designed initially for the regulatory scope, 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>European project OpenMedicine 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. Nonetheless, it takes into account, however, relevant IDMP identifiers and attributes which are already usable in the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depend on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while the 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 the absence of a global identification system for medicinal products, the solution proposed here 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.

Medication data is 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 the CDA model has been extended enhancing the Manufactured Material class with attributes and relationships derived from the latest published version of the R_Medication CMET (see HL7 V3 Normative Edition 2017) based on the HL7 Common Product 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.”'') .

<ref group="Figure" name="cdaextensions"></ref> shows how the CDA model has been enhanced with the R_Medication CMET.

{{IncludeImage|IPS extensions.png|700px|90%}}

<ref group="Figure" name="cdaextensions">CDA model has been enhanced with the R_Medication</ref>Extension of the CDA model from the content of the R_Medication CMET.

== 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:
*Allow optional documentation of section-level provenance.
*Require document-level provenance.
*Define IPS document provenance as one of two types: human-curated or software-assembled, based on the authors recorded in the header.
**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 (the verifier is represented as a participant with typeCode "VRF"). 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.''

== Representation of Names ==

This specification requires that any Person Name is represented including at least the given and family components and therefore is never documented as a single string.

Even though it is recognized that there is not in all cultures the same concept of “family name”, no evidence has been collected in analyzing the international context (e.g. Japan, Korea; China) that justifies the retirement of this requirement.

Moreover, due to the global scope of the International Patient Summary, the case of non-alphabetic representations of the names has also been considered.

In this case, to facilitate the global use of the IPS, at least one alphabetic representation of the name SHALL be provided.

IPS Design conventions and principles 1

2018-07-17T08:47:28Z

Gcangioli: /* Medicinal Product Identification */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated in section 1.5, 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 or EDQM Standard Terms. In some selected cases, in consideration of the availability of other globally usable reference terminologies and for alignment with a future FHIR version of the IPS, FHIR-defined terminologies have been specified. These 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; unless exceptions have been agreed.
* The 'displayName' of the Primary Code '''SHALL''' be populated with a term representing this same code in the terminology used, 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 'displayName'.
* In case the primary code is derived from an alternate terminology the alternate code '''SHOULD''' be provided in the translation element.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.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 (“general condition/activity unknown” and “general condition/activity/known absent” ) using explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes or human readable text (possibly not understood by the foreign country receiver).

In contrast to the practice to use negationInd or nullFlavor attributes on a section itself, we prohibit the use of these attributes on section level to express “unknown” or “no information” situations. A section holds the categorized (coded) narrative part of the documented activity and will never carry negationInd or nullFlavor attributes. Instead, we enforce by design, that “unknown” or “no information” expressions always go to the coded entry with a corresponding act code.

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 make clinical content representation 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 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.

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.

When needed, more specific statements such as the absence of a specific condition or activity, although considered as beyond the set of essential data for IPS, can still be expressed by using the native negationInd attribute of CDA R2.

==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 ''Required'' (aka 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 data type to better support this situation.''

The second case, that applies both to ''Required'' (aka CNE, coded no extensions) and ''Extensible'' (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 code to be used here would be "UNC" (Uncoded). This code is available in the current and other recent versions of the HL7 RIM, but it is not present in version 2.07 of the RIM on which the CDA R2 standard is based. In the absence of "UNC", the most appropriate NullFlavor code to use for representing that the data is unable to be coded is "NI".''

== 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, it is recommended to populate the original code in the IPS instance (in a 'translation' sub-element), with a nullFlavor indicating that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.). The nullFlavor value depends upon the coding strength of the binding.

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

In the case of coding strength Required (CNE), use nullFlavor "OTH":

<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 there are no codes applicable in the reference value set, which is possible with Data Types R2.''

''Future versions of this guide may consider extending the data type to better support this situation.''

In the case of Extensible (CWE) coding strength, this guide recommends representing the original code in the <translation> sub-element and using a nullFlavor for the primary code. This highlights the fact that a mapping to the reference value set was attempted, but no suitable target codes were identified.

<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 set. When this occurs, both the original and the reference codes should be reported in the IPS instance.

Functional requirements exposed in [[#Concept code mapping|section 3.1]] (multi-coding, link to original text, mapping between codes of the same code system) are also detailed below.

Case 1: Single local code mapped to primary code from the reference value set.

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

Case 2: Multiple local codes mapped together using nested 'translation' elements, and mapped to the primary code from the reference value set.

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

Case 3: 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 data type 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. Data Types 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).

Given that the base CDA R2 standard which uses datatypes R1 does not offer a native way to convey the language translation of 'displayName', this guide introduces an optional 'ips:designation' extension to the CD datatype for that purpose.

Below are examples of usage 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 language="it-IT">Profilo Sanitario Sintetico</ips:designation>
<ips:designation language="fr-FR">Patient Summary</ips:designation>
<ips:designation language="en">Patient Summary</ips:designation>
</code>
</syntaxhighlight>

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

== Narrative Translations ==

“Narrative translation” means 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 with this process are described in the [[#Designations’ Translation| Designations’ Translation]] section under [[#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.

Regarding the translation of section narrative <text>, this guide recommends providing this translation on purely textual subordinate sections (one per translation) as specified in the IPS Translation Section (2.16.840.1.113883.10.22.3.15) template.

An example of this is:

<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"></ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime).
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 became inactive, and it is present if the statusCode of the concern act is "completed". If this date is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

'''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 specialized 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 (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"></ref>

'''Confirmation status'''

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

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

What a medication 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 of attributes is still useful when limiting the scope to the medication summary within a Patient Summary. This medication summary could be, for instance, the list of all prescribed medicines whose indicated treatment period has not yet expired, regardless of 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 could also be narrowed down to the actually dispensed medications. Or conversely, it could be 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>). It could also be simply stated as 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 are not relevant for an IPS. It is important, however, to know what medications are being taken by or have been given to a patient, independent of 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 is therefore a list of relevant medication statements, built from either a prescription list 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 cases, data obtained from actual dispensation and/or prescription records can be recorded as statements and the original request, supply or administration records may be referred to from the statement if really needed.

==Medicinal Product Identification==

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

The set of ISO standards called IDMP<ref>IDMP standards https://www.idmp1.com/idmp-standards</ref> - designed initially for the regulatory scope, 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>European project OpenMedicine 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. Nonetheless, it takes into account, however, relevant IDMP identifiers and attributes which are already usable in the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depend on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while the 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 the absence of a global identification system for medicinal products, the solution proposed here 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.

Medication data is 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 the CDA model has been extended enhancing the Manufactured Material class with attributes and relationships derived from the latest published version of the R_Medication CMET (see HL7 V3 Normative Edition 2017) based on the HL7 Common Product 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.”'') .

<ref group="Figure" name="cdaextensions"></ref> shows how the CDA model has been enhanced with the R_Medication CMET.

{{IncludeImage|IPS extensions.png|700px|90%}}

<ref group="Figure" name="cdaextensions">CDA model has been enhanced with the R_Medication</ref>Extension of the CDA model from the content of the R_Medication CMET.

== 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:
*Allow optional documentation of section-level provenance.
*Require document-level provenance.
*Define IPS document provenance as one of two types: human-curated or software-assembled, based on the authors recorded in the header.
**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 (the verifier is represented as a participant with typeCode "VRF"). 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.

== Representation of Names ==

This specification requires that any Person Name is represented including at least the given and family components and therefore is never documented as a single string.

Even though it is recognized that there is not in all cultures the same concept of “family name”, no evidence has been collected in analyzing the international context (e.g. Japan, Korea; China) that justifies the retirement of this requirement.

Moreover, due to the global scope of the International Patient Summary, the case of non-alphabetic representations of the names has also been considered.

In this case, to facilitate the global use of the IPS, at least one alphabetic representation of the name SHALL be provided.

IPS implementationguide 1

2018-07-02T10:31:44Z

Gcangioli: /* List of all artifacts used in this guide */

__NOTOC__
{{Infobox_Document
|Title = HL7 CDA® R2 Implementation Guide<br/>International Patient Summary, Release 1
|Short = International Patient Summary
|Namespace = cdaips
|Type = HL7 STU Ballot
|Version = 1.76
|Sponsored = Structured Documents Workgroup
|Date = December 17, 2017
|Status = Draft
|Period = Ballot
|OID = n.n.
|Realm = Universal
|Custodian = HL7
|Copyrighttext = © 2016-2018 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.<br>Use of this material is governed by HL7's IP Compliance Policy.
|Topright = CDAR2_INTLPATSUMMARY_R1_D2_2018JAN
}}

{{: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 to this guide, and how other artifacts 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 the subject of a “conformity assessment” satisfies the business or the design requirements this specification complies to. It should, however, be clear that compliance with the specified business or design requirements, for example in the future with the CEN prEN 17269 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 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 they are most often not 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"></ref> 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 artifacts 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 they apply 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>).

This guide does not provide additional requirements regarding the Recipient and the Originator Responsibilities.

The formal representation used in this implementation guide for expressing the conformance statement is described in chapter "How to read the table view for templates" 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 and validation capabilities.

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, however, may not be 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 electronic implementation of the WHO yellow card for vaccinations; or the IPS section templates are used to communicate to the country of affiliation minimal and non-exhaustive information about the encounter in which the Patient Summary has been used (cross-border encounter report ). Implementers may take advantage of the template openness to better support specific cases - "extended” parts, however, may not be interoperable among them.
* IPS as a reference: the implementation is conformant with templates that are an adaptation of 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 may not be not large. Typical examples are templates in which alternatives vocabularies are used.

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

{{:IPS_Alltemplates}}

{{: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 Care 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
*[[2.16.840.1.113883.10.22.11]] IPS Address

==CDA Template References ==
* [[2.16.840.1.113883.10.21.9.1]] UV Use Period

==Unconstrained Templates from the original CDA specification ==
* [[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

==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.5]] CORE Problem List Disorders
*[[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
*[[2.16.840.1.113883.11.22.54]] IPS Personal Relationship
*[[2.16.840.1.113883.11.22.55]] IPS Target Site
*[[2.16.840.1.113883.11.22.56]] IPS Specimen Type
*[[2.16.840.1.113883.11.22.57]] Laterality (qualifier)
*[[2.16.840.1.113883.11.22.58]] Topographical modifier (qualifier)
*[[2.16.840.1.113883.11.22.59]] IPS Current Smoking Status
*[[2.16.840.1.113883.11.22.60]] Allergy-intolerance Criticality

==Value Sets References==
*[[2.16.840.1.113883.1.11.1]] AdministrativeGender
*[[2.16.840.1.113883.1.11.10706]] Timing Event
*[[2.16.840.1.113883.1.11.11610]] x_ActRelationshipDocument
*[[2.16.840.1.113883.1.11.15933]] ActStatus
*[[2.16.840.1.113883.1.11.16926]] HL7 BasicConfidentialityKind
*[[2.16.840.1.113883.1.11.19446]] x_ActRelationshipEntry
*[[2.16.840.1.113883.1.11.19563]] PersonalRelationshipRoleType
*[[2.16.840.1.113883.1.11.19601]] x_ServiceEventPerformer
*[[2.16.840.1.113883.1.11.19709]] ActSubstanceAdministrationImmunizationCode
*[[2.16.840.1.113883.1.11.19890]] x_ActStatusActiveComplete
*[[2.16.840.1.113883.1.11.201]] TelecommunicationAddressUse
*[[2.16.840.1.113883.1.11.20386]] SeverityObservationCode
*[[2.16.840.1.113883.1.11.78]] Observation Interpretation
*[[2.16.840.1.113883.11.20.9.18]] MoodCodeEvnInt
*[[2.16.840.1.113883.11.20.9.33]] INDRoleclassCodes
*[[2.16.840.1.113883.3.88.12.80.60]] Social History Type

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

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

==Extensions==
=== Detailed medications information ===
This specification uses CDA extensions in order to provide details about medications, as further described in the section on the design conventions for [[ IPS_implementationguide_1#Medicinal_Product_Identification|Medicinal Product Identification]] and as used in template 2.16.840.1.113883.10.22.4.3 ''IPS Manufactured Material''. The extension uses the namespace <code>urn:hl7-org:pharm</code>.

This is the list of elements defined for that template.

*pharm:formCode (Administrable Pharmaceutical Dose Form)
*pharm:asContent (Packaging of the medication)
**pharm:quantity
**pharm:containerPackagedMedicine (Most inner Package Item or the Packaged Medicinal Product)
***pharm:code
***pharm:name (Name of the Package Item or of the Packaged Medicinal Product)
***pharm:formCode (type of the most inner package item or of the or the Packaged Medicinal Product)
***pharm:capacityQuantity (the functional capacity of the container)
***pharm:asContent (Containing package)
****pharm:quantity
****pharm:containerPackagedMedicine (Intermediate Package Item or the Packaged Medicinal Product)
*****pharm:code
*****pharm:name (Name of the Package Item or of the Packaged Medicinal Product)
*****pharm:formCode (type of the intermediate package item or of the or the Packaged Medicinal Product)
*****pharm:capacityQuantity (the functional capacity of the container)
*****pharm:asContent (Containing package)
******pharm:quantity
******pharm:containerPackagedMedicine (Packaged Medicinal Product)
*******pharm:code
*******pharm:name (Name of the Packaged Medicinal Product)
*******pharm:formCode (type of the Packaged Medicinal Product)
*******pharm:capacityQuantity (the functional capacity of the container)
*pharm:asSpecializedKind (used to represent any classification of the product (ATC code, future PhPIDs,..) )
**pharm:generalizedMaterialKind
***pharm:code
***pharm:name
*pharm:ingredient (list of active substances used for this product)
**pharm:quantity (strength)
**pharm:ingredientSubstance (active substance)
***pharm:code
***pharm:name

===Translation of designations===
This specification recommends the introduction of an optional extension for properly recording multilingual designations, that is further described in the [[IPS_implementationguide_1#Translation_of_designations_2|section on the translation of designations]]
*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 Alltemplates

2018-07-02T10:10:11Z

Gcangioli: /* CDA Entry Level Templates */

<div class="landscape">
=CDA Document Level Templates=
==International Patient Summary==
{{:2.16.840.1.113883.10.22.1.1/dynamic}}
=CDA Header Level Templates=
==IPS CDA author==
{{:2.16.840.1.113883.10.22.2.2/dynamic}}
==IPS CDA custodian==
{{:2.16.840.1.113883.10.22.2.3/dynamic}}
==IPS CDA documentationOf ==
{{:2.16.840.1.113883.10.22.2.6/dynamic}}
==IPS CDA legalAuthenticator==
{{:2.16.840.1.113883.10.22.2.4/dynamic}}
IPS CDA Organization
{{:2.16.840.1.113883.10.22.9.1/dynamic}}
IPS CDA Person
{{:2.16.840.1.113883.10.22.9.3/dynamic}}
==IPS CDA recordTarget==
{{:2.16.840.1.113883.10.22.2.1/dynamic}}
==IPS CDA relatedDocument==
{{:2.16.840.1.113883.10.22.2.7/dynamic}}
==IPS Patient Contacts==
{{:2.16.840.1.113883.10.22.2.5/dynamic}}

=CDA Section Level Templates=
==IPS Advance Directives Section==
{{:2.16.840.1.113883.10.22.3.12/dynamic}}
==IPS Allergies and Intolerances Section==
{{:2.16.840.1.113883.10.22.3.2/dynamic}}
==IPS Functional Status Section==
{{:2.16.840.1.113883.10.22.3.8/dynamic}}
==IPS History of Past Illness Section==
{{:2.16.840.1.113883.10.22.3.7/dynamic}}
==IPS History of Pregnancy Section==
{{:2.16.840.1.113883.10.22.3.11/dynamic}}
==IPS History of Procedures Section==
{{:2.16.840.1.113883.10.22.3.4/dynamic}}
==IPS Immunizations Section==
{{:2.16.840.1.113883.10.22.3.5/dynamic}}
==IPS Medical Devices Section==
{{:2.16.840.1.113883.10.22.3.6/dynamic}}
==IPS Medication Summary Section==
{{:2.16.840.1.113883.10.22.3.1/dynamic}}
==IPS Plan of Care Section==
{{:2.16.840.1.113883.10.22.3.9/dynamic}}
==IPS Problems Section==
{{:2.16.840.1.113883.10.22.3.3/dynamic}}
==IPS Results Section==
{{:2.16.840.1.113883.10.22.3.14/dynamic}}
==IPS Social History Section==
{{:2.16.840.1.113883.10.22.3.10/dynamic}}
==IPS Translation Section==
{{:2.16.840.1.113883.10.22.3.15/dynamic}}

=CDA Entry Level Templates=
==IPS Allergy and Intolerance Concern==
{{:2.16.840.1.113883.10.22.4.5/dynamic}}
==IPS Allergy Certainty Observation==
{{: 2.16.840.1.113883.10.22.10/dynamic}}
==IPS Allergy or Intolerance==
{{:2.16.840.1.113883.10.22.4.1/dynamic}}
==IPS Allergy Status Observation==
{{:2.16.840.1.113883.10.22.4.21/dynamic}}
==IPS Body Author==
{{:2.16.840.1.113883.10.22.4.14/dynamic}}
==IPS CDA Device==
{{:2.16.840.1.113883.10.22.9.2/dynamic}}
==IPS Certainty Observation==
{{:2.16.840.1.113883.10.22.4.19/dynamic}}
==IPS Comment Activity==
{{:2.16.840.1.113883.10.22.4.22/dynamic}}
==IPS Criticality Observation==
{{:2.16.840.1.113883.10.22.4.18/dynamic}}
==IPS Immunization==
{{:2.16.840.1.113883.10.22.4.15/dynamic}}
==IPS Immunization Medication Information==
{{:2.16.840.1.113883.10.22.4.16/dynamic}}
==IPS Internal Reference==
{{:2.16.840.1.113883.10.22.4.31/dynamic}}
==IPS Laboratory Result Observation==
{{:2.16.840.1.113883.10.22.4.13/dynamic}}
==IPS Manufactured Material==
{{:2.16.840.1.113883.10.22.4.3/dynamic}}
==IPS Medical Device==
{{:2.16.840.1.113883.10.22.4.26/dynamic}}
==IPS Medication Information (detail)==
{{:2.16.840.1.113883.10.22.4.2/dynamic}}
==IPS Medication Statement==
{{:2.16.840.1.113883.10.22.4.4/dynamic}}
==IPS ObservationMedia==
{{:2.16.840.1.113883.10.22.4.23/dynamic}}
==IPS Pathology Result Observation==
{{:2.16.840.1.113883.10.22.4.11/dynamic}}
==IPS Pregnancy Expected Delivery Date Observation==
{{:2.16.840.1.113883.10.22.4.29/dynamic}}
==IPS Pregnancy Outcome Observation==
{{:2.16.840.1.113883.10.22.4.28/dynamic}}
==IPS Pregnancy Status Observation==
{{:2.16.840.1.113883.10.22.4.27/dynamic}}
==IPS Problem Concern Entry==
{{:2.16.840.1.113883.10.22.4.7/dynamic}}
==IPS Problem Entry==
{{:2.16.840.1.113883.10.22.4.8/dynamic}}
==IPS Problem Status Observation==
{{:2.16.840.1.113883.10.22.4.20/dynamic}}
==IPS Procedure Entry==
{{:2.16.840.1.113883.10.22.4.17/dynamic}}
==IPS Radiology Result Observation==
{{:2.16.840.1.113883.10.22.4.12/dynamic}}
==IPS Reaction Manifestation==
{{:2.16.840.1.113883.10.22.4.6/dynamic}}
==IPS Result Observation==
{{:2.16.840.1.113883.10.22.4.10/dynamic}}
==IPS Result Organizer==
{{:2.16.840.1.113883.10.22.4.9/dynamic}}
==IPS Severity Observation==
{{:2.16.840.1.113883.10.22.4.25/dynamic}}
==IPS Social History Alcohol Use==
{{:2.16.840.1.113883.10.22.4.35/dynamic}}
==IPS Social History Tobacco Use==
{{:2.16.840.1.113883.10.22.4.34/dynamic}}
==IPS Specimen Collection==
{{:2.16.840.1.113883.10.22.4.30/dynamic}}
==IPS Subordinate SubstanceAdministration==
{{:2.16.840.1.113883.10.22.4.33/dynamic}}

=HL7 V2/V3 Datatype Level Template=
==IPS Address==
{{:2.16.840.1.113883.10.22.11/dynamic}}
</div>

IPS Alltemplates

2018-05-02T16:13:04Z

Gcangioli: /* Medicinal Product Identification */

=Design conventions and principles=
==How to use terminologies (preferred binding)==
As stated in section 1.5, 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 or EDQM Standard Terms. In some selected cases, in consideration of the availability of other globally usable reference terminologies and for alignment with a future FHIR version of the IPS, FHIR-defined terminologies have been specified. These 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; unless exceptions have been agreed.
* The 'displayName' of the Primary Code '''SHALL''' be populated with a term representing this same code in the terminology used, 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 'displayName'.
* In case the primary code is derived from an alternate terminology the alternate code '''SHOULD''' be provided in the translation element.

===Primary Code===
In the data type for codeable elements (CD constrained by the CD.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 (“general condition/activity unknown” and “general condition/activity/known absent” ) using explicit coded elements rather than relying on specific mechanisms of HL7 CDA such as nullFlavor and negationInd attributes or human readable text (possibly not understood by the foreign country receiver).

In contrast to the practice to use negationInd or nullFlavor attributes on a section itself, we prohibit the use of these attributes on section level to express “unknown” or “no information” situations. A section holds the categorized (coded) narrative part of the documented activity and will never carry negationInd or nullFlavor attributes. Instead, we enforce by design, that “unknown” or “no information” expressions always go to the coded entry with a corresponding act code.

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 make clinical content representation 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 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.

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.

When needed, more specific statements such as the absence of a specific condition or activity, although considered as beyond the set of essential data for IPS, can still be expressed by using the native negationInd attribute of CDA R2.

==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 ''Required'' (aka 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 data type to better support this situation.''

The second case, that applies both to ''Required'' (aka CNE, coded no extensions) and ''Extensible'' (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 code to be used here would be "UNC" (Uncoded). This code is available in the current and other recent versions of the HL7 RIM, but it is not present in version 2.07 of the RIM on which the CDA R2 standard is based. In the absence of "UNC", the most appropriate NullFlavor code to use for representing that the data is unable to be coded is "NI".''

== 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, it is recommended to populate the original code in the IPS instance (in a 'translation' sub-element), with a nullFlavor indicating that the mapping didn’t occur. (See also the [[#Concept code mapping| Concept code mapping]] in the functional requirements section.). The nullFlavor value depends upon the coding strength of the binding.

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

In the case of coding strength Required (CNE), use nullFlavor "OTH":

<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 there are no codes applicable in the reference value set, which is possible with Data Types R2.''

''Future versions of this guide may consider extending the data type to better support this situation.''

In the case of Extensible (CWE) coding strength, this guide recommends representing the original code in the <translation> sub-element and using a nullFlavor for the primary code. This highlights the fact that a mapping to the reference value set was attempted, but no suitable target codes were identified.

<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 set. When this occurs, both the original and the reference codes should be reported in the IPS instance.

Functional requirements exposed in [[#Concept code mapping|section 3.1]] (multi-coding, link to original text, mapping between codes of the same code system) are also detailed below.

Case 1: Single local code mapped to primary code from the reference value set.

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

Case 2: Multiple local codes mapped together using nested 'translation' elements, and mapped to the primary code from the reference value set.

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

Case 3: 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 data type 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. Data Types 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).

Given that the base CDA R2 standard which uses datatypes R1 does not offer a native way to convey the language translation of 'displayName', this guide introduces an optional 'ips:designation' extension to the CD datatype for that purpose.

Below are examples of usage 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 language="it-IT">Profilo Sanitario Sintetico</ips:designation>
<ips:designation language="fr-FR">Patient Summary</ips:designation>
<ips:designation language="en">Patient Summary</ips:designation>
</code>
</syntaxhighlight>

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

== Narrative Translations ==

“Narrative translation” means 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 with this process are described in the [[#Designations’ Translation| Designations’ Translation]] section under [[#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.

Regarding the translation of section narrative <text>, this guide recommends providing this translation on purely textual subordinate sections (one per translation) as specified in the IPS Translation Section (2.16.840.1.113883.10.22.3.15) template.

An example of this is:

<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"></ref>''

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime).
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 became inactive, and it is present if the statusCode of the concern act is "completed". If this date is not known, then effectiveTime/high will be present with a nullFlavor of "UNK".

'''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 specialized 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 (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"></ref>

'''Confirmation status'''

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

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

What a medication 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 of attributes is still useful when limiting the scope to the medication summary within a Patient Summary. This medication summary could be, for instance, the list of all prescribed medicines whose indicated treatment period has not yet expired, regardless of 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 could also be narrowed down to the actually dispensed medications. Or conversely, it could be 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>). It could also be simply stated as 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 are not relevant for an IPS. It is important, however, to know what medications are being taken by or have been given to a patient, independent of 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 is therefore a list of relevant medication statements, built from either a prescription list 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 cases, data obtained from actual dispensation and/or prescription records can be recorded as statements and the original request, supply or administration records may be referred to from the statement if really needed.

==Medicinal Product Identification==

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

The set of ISO standards called IDMP<ref>IDMP standards https://www.idmp1.com/idmp-standards</ref> - designed initially for the regulatory scope, 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>European project OpenMedicine 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. Nonetheless, it takes into account, however, relevant IDMP identifiers and attributes which are already usable in the IPS, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID).

''Note: IDMP Medicinal Product (MPID) and Medicinal Product Package (PCID) identifiers depend on the market authorization. The “same” product might therefore have different IDs if different authorizations have been received in different countries, while the 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 the absence of a global identification system for medicinal products, the solution proposed here 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.

Medication data is 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 the CDA model has been extended enhancing the Manufactured Material class with attributes and relationships derived from the R_Medication CMET.

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="cdaextensions"></ref> shows how the CDA model has been enhanced with the R_Medication CMET.

{{IncludeImage|IPS extensions.png|700px|90%}}

<ref group="Figure" name="cdaextensions">CDA model has been enhanced with the R_Medication</ref>Extension of the CDA model from the content of the R_Medication CMET.

== 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:
*Allow optional documentation of section-level provenance.
*Require document-level provenance.
*Define IPS document provenance as one of two types: human-curated or software-assembled, based on the authors recorded in the header.
**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 (the verifier is represented as a participant with typeCode "VRF"). 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.

== Representation of Names ==

This specification requires that any Person Name is represented including at least the given and family components and therefore is never documented as a single string.

Even though it is recognized that there is not in all cultures the same concept of “family name”, no evidence has been collected in analyzing the international context (e.g. Japan, Korea; China) that justifies the retirement of this requirement.

Moreover, due to the global scope of the International Patient Summary, the case of non-alphabetic representations of the names has also been considered.

In this case, to facilitate the global use of the IPS, at least one alphabetic representation of the name SHALL be provided.

File:IPS extensions.png

2018-05-02T16:11:39Z

Gcangioli: Gcangioli uploaded a new version of File:IPS extensions.png

2018-01-31T23:00:49Z

Gcangioli: /* Identifiers for Templates and Value Sets */

= Technical Background =
{{:CDA_Background}}

==Conformance Verbs==
The conformance verb keywords '''SHALL''', '''SHOULD''', '''MAY''' and '''SHALL NOT''' in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide<ref>HL7 Version 3 Publishing Facilitator's Guide http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm</ref>.
*'''SHALL''': an absolute requirement
*'''SHALL NOT''': an absolute prohibition against inclusion
*'''SHOULD''': best practice or recommendation. There may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course
*'''MAY''': truly optional; can be included or omitted as the author decides with no implications

==Identifiers for Templates and Value Sets==
This specification uses the following OIDs for the artifacts that are registered at the HL7 OID registry.
*The root OID for templates is 2.16.840.1.113883.10.22
**Document Level Templates are sub branch '''.1''', e.g. 2.16.840.1.113883.10.22.1.1 ''International Patient Summary''
**Header Level Templates are summarized under 2.16.840.1.113883.10.22'''.2''', e.g. 2.16.840.1.113883.10.22.2.1 ''IPS CDA recordTarget''
**Section Level Templates are summarized under 2.16.840.1.113883.10.22'''.3''', e.g. 2.16.840.1.113883.10.22.3.1 ''IPS Medication Summary Section''
**Entry Level templates are summarized under 2.16.840.1.113883.10.22'''.4''', e.g. 2.16.840.1.113883.10.22.4.19 ''IPS Certainty Observation''
**“other” assistance templates are summarized under 2.16.840.1.113883.10.22'''.9''', e.g. 2.16.840.1.113883.10.22.9.2 ''IPS CDA Device''
* The root OID for Value Sets is 2.16.840.1.113883.11
The sub branches for templates follow the recommendations of HL7 International and ISO 13582<ref>ISO/TS 13582:2015 Health informatics -- Sharing of OID registry information</ref>

==Terminologies==
''Note: Much of the description provided in this section is copied and adapted from the §4.2.8 Vocabulary Conformance section of the C-CDA DSTU R2.1 Implementation Guide Volume 1.<ref name="ccda21"></ref>''

The templates in this document use terms from several code systems. These vocabularies are defined in various supporting specifications and may be maintained by other bodies, as is the case for the LOINC® and SNOMED CT® vocabularies. The primary terminologies identified for this specification are listed [[IPS_implementationguide_1#How_to_use_terminologies_(preferred_binding)|in section 4.1]].

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

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

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

<table style="font-size: 11px;">
<tr style="vertical-align: top; background-color: rgb(255, 234, 234); display: table-row;" class="branch expanded"><td style="padding: 7px;"><tt><strong>hl7:code</strong></tt></td><td style="padding: 7px;"><strong> </strong></td><td style="padding: 7px;"><span style="color: black;"><strong>1 … 1</strong></span></td><td style="padding: 7px;"><span style="color: color: black;"><strong>M</strong></span></td><td></td><td style="background-color: #FFEEEE;"><span title=""> </span></td></tr>
<tr style="vertical-align: top; display: table-row;" ><td style="padding: 7px;"><span class="indenter" style="padding-left: 38px;"></span><tt><strong>@code</strong></tt></td><td rowspan="3" style="padding: 7px;" class="conf">CONF</td><td style="padding: 7px;"><span style="color: black;"><strong>1 … 1</strong></span></td><td style="padding: 7px;"><strong>F</strong></td><td style="padding: 7px;" colspan="2">11450-4</td></tr>
<tr style="vertical-align: top; display: table-row;" class="leaf expanded"><td style="padding: 7px;"><span class="indenter" style="padding-left: 38px;"></span><tt><strong>@codeSystem</strong></tt></td><td style="padding: 7px;"><span style="color: black;"><strong>1 … 1</strong></span></td><td style="padding: 7px;"><strong>F</strong></td><td style="padding: 7px;" colspan="2">2.16.840.1.113883.6.1 (LOINC)</td></tr>
<tr style="vertical-align: top; display: table-row;" class="leaf expanded"><td style="padding: 7px;"><span class="indenter" style="padding-left: 38px;"></span><tt><strong>@displayName</strong></tt></td><td style="padding: 7px;"><span style="color: black;"><strong>1 … 1</strong></span></td><td style="padding: 7px;"><strong>F</strong></td><td style="padding: 7px;" colspan="2">Problem List</td></tr>
</table>

<ref group="Figure">Binding to a Single Code (tabular view)</ref> Binding to a Single Code (tabular view)

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

The above example would be properly expressed as follows.
<syntaxhighlight lang="xml">
<code code="11450-4" codeSystem="2.16.840.1.113883.6.1"/>



<code code="11450-4" codeSystem="2.16.840.1.113883.6.1"
displayName="Problem List" codeSystemName=”LOINC”/>
</syntaxhighlight>
<ref group="Figure">XML Expression of a Single-Code Binding</ref> XML Expression of a Single-Code Binding

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

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

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

<syntaxhighlight lang="xml">
<code code="206525008" codeSystem="2.16.840.1.113883.6.96"
displayName="neonatal necrotizing enterocolitis" codeSystemName="SNOMED CT">
<translation code="NEC-1" codeSystem="2.16.840.1.113883.19"
displayName="necrotizing enterocolitis"/>
</code>
</syntaxhighlight>
<ref group="Figure">Translation Code Example</ref> Translation Code Example

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

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

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

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

Many of the value sets used in the IPS specification are defined intensionally. The source of truth for these value sets and their definitions for IPS is ART-DECOR®<ref>IPS Value Sets in ART-DECOR® https://art-decor.org/art-decor/decor-valuesets--hl7ips-</ref>.

{{IncludeImage|IPS_intensionalvs.png|500px|70%}}
<ref group="Figure">Intensional value set definition</ref> Intensional value set definition.

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

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

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