IPS Design conventions and principles 1

Design conventions and principles

How to use terminologies (preferred binding)

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

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

In order to maximize the international scope and usability of patient summaries, and also to accommodate the exceptional situations listed above, this specification makes these requirements:

• The Primary Code of a codeable element should be populated.
• If populated, the Primary Code of a codeable element shall be chosen from the primary terminology assigned to the value set bound to this element.
• The Display Name of the Primary Code shall be populated with a term representing this same code in the primary terminology, in the language chosen for the current instance of the patient summary.
• When the primary 'code' element is not populated, an appropriate 'nullFlavor' value shall be used along with the 'originalText' element (referencing a textual expression in the narrative representing the meaning for the producer) and/or one or more coded 'translation' elements.
• One or more Alternate Codes from a local interface terminology may be provided, each with its associated Display Name.

Primary Code

In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Primary Code is represented by the attributes @code, @displayName, @codeSystem, @codeSystemName, @codeSystemVersion.

Alternate Code

In the data type for codeable elements (CD constrained by the CD.EPSOS template), an Alternate Code is carried in a "translation" sub-element.

Original Text

In the data type for codeable elements (CD constrained by the CD.EPSOS template), the Original Text is provided in the "originalText" sub-element.

Representing "known absent" and "not known"

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

1. condition or activity unknown
2. condition or activity known absent.

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

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

The main reasons for this choice are:

• @negationInd in CDA has been superseded in V3 later by two other negation indicators: @actNegationInd and @valueNegationInd.
• To have a representation of the clinical content of the patient summary, which is less dependent on a particular format or syntax, enabling a more practical path to transforming and exchanging data from one standard format (e.g. CDA R2) to another (e.g. FHIR).
• to provide one single method to express either the presence or absence of a particular condition (e.g. an allergy) or activity (e.g. an immunization), or the lack of knowledge regarding this kind of condition or activity, resulting in a more robust and easily implementable specification.

In some cases, this required the creation of new SNOMED CT concepts. For example, a known absent Allergy/Intolerance would be represented by "716186003 |No known allergy (situation)|" (or any combination of its descendants), whereas no information about Allergy/Intolerance would be represented by a code with the meaning "Allergic disposition not known (situation)". For these cases, an HL7 extension to SNOMED CT has been created, working for their future inclusion in the SNOMED CT International Release.

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

Uncoded information

An IPS originator may not be able to value a coded element with an appropriate coded concept, but only with textual information. This may happen for two reasons:

1. the originator is not able to express the concept in the reference value sets
2. the originator is not able to express the concept in any known terminology.

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

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

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

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

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

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

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

Unmapped Coded Concepts

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

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

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

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

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

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

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

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

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

Mapped coded concepts

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

All those aspects are considered in this section.

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

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

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

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

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

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

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

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

Translation of designations

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

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

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

No code mapping

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

Codes mapping

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

---

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

No code mapping

<code code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Patient Summary">
    <translation code="60591-5" codeSystem="2.16.840.1.113883.6.1"codeSystemName="LOINC" displayName="Profilo Sanitario Sintetico" /> 
</code>

Codes mapping

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

---

Narrative Translations

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

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

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

Hereafter an example:

<section>
  <templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/>
   <id root="1.2.3.999" extension="--example only--"/>
   <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
   <title>Allergies and Intolerances</title>
   <text>No known Allergies</text>
   <!-- omissions -->
   <component>
      <section>
        <!--  subordinate section carrying a translation of the parent section -->
        <title>Allergie ed Intolleranze</title>
        <text>Nessuna Allergia Nota</text>
        <languageCode code="it-IT"/>
      </section>
    </component>
</section>

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

A recipient must be able to determine whether the status of an entry — which can include a problem, a medication administration, etc. — is active, completed, or in some other state. Determination of the exact status is dependent on the interplay between an act’s various components (such as statusCode and effectiveTime), and inconsistent modelling between different objects. The following principles apply when representing or interpreting the status of a clinical statement.

• The Act.statusCode of the clinical statement specifies the state of the entry: Per the RIM, the statusCode “reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing, not the status of what is being observed.”
• Act.statusCode and Act.moodCode are inter-related: Generally, an act in EVN (event) mood is a discrete event (a user looks, listens, measures, and records what was done or observed), so generally an act in EVN mood will have a statusCode of “completed.” A prolonged period of observation is an exception, in which a user would potentially have an observation in EVN mood that is “active.” For an Observation in RQO (request) mood, the statusCode generally remains “active” until the request is complete, at which time the statusCode changes to “completed.” For an Observation in GOL (goal) mood, the statusCode generally remains “active” as long as the observation in question is still an active goal for the patient.
• Act.statusCode and Act.effectiveTime are interrelated: Per the RIM, the effectiveTime, also referred to as the “biologically relevant time,” is the time at which the act holds for the patient. So, whereas the effectiveTime is the biologically relevant time, the statusCode is the state of the activity. For a provider seeing a patient in a clinic and observing a history of heart attack that occurred 5 years ago, the status of the observation is completed, and the effectiveTime is five years ago.

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

There are different kinds of status that could be of clinical interest for a condition:

• The status of the concern (active, inactive,..)
• The status of the condition (e.g. active, inactive, resolved,..)
• The confirmation status [verification status, certainty] (e.g. confirmed, provisional, refuted,…)

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

Status of the concern and related times

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

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

Status of the condition and related times

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

Problem Concern Act (from C-CDA IG DTSU R2.1)

Confirmation status

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

The use of medication statements in the summary

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

This plurality is not removed even limiting the scope to a medication summary within a Patient Summary. It may be for example the list of all prescribed medicines, whose indicated treatment period has not yet expired, whether they have been dispensed or not (European guidelines on Patient Summary ). It may be a list of only the active ones or a complete history including the full patient's prescription and dispensation history and information about intended drug monitoring (C-CDA ) or generally a list of relevant medications for the patient (IHE PCC ).

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

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

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

Medicinal Product Identification

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

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

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

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

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

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

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

Representation of medicines in CDA

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

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

This choice has been made:

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

shows how the CDA model has been enhanced with the Common Product Model: the relationship and classes of the CPM manufactured material (Product) class has been added as extensions to that of the CDA model (Material); the same has been done for the ManufacturedProduct classes.

CDA model and the Common Product Model

Provenance

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

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

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

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