Difference between revisions of "IPS Functional requirements 1"

From HL7 IPS
Jump to: navigation, search
(Functional requirements and high-level use cases)
(Code mappings and multilingual support)
 
(39 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
=Functional requirements and high-level use cases=
 
=Functional requirements and high-level use cases=
  
Several cases may be identified for the International Patient Summary within its scope  (“specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care”). Section [[#Examples (in progress)|Examples (in progress)]]  provides examples of some real world user stories for the cross-border care developed by the [http://www.trilliumbridge.eu Trillium Bridge Project ] and by the [http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative S&I EU-US eHealth Cooperation Initiative ] in the scope of the EU/US Roadmap initiative.
+
Several use cases may be identified for the International Patient Summary within its scope  (“specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care”). Section [[#Examples (in progress)|Examples]]  provide a subset of some real world user stories for the cross-border care developed by the [http://www.trilliumbridge.eu Trillium Bridge Project ] and by the [http://wiki.siframework.org/EU-US+eHealth+Cooperation+Initiative S&I EU-US eHealth Cooperation Initiative ] in the scope of the EU/US Roadmap initiative.
  
The cross-border care is not however the only expected usage scenario for the IPS: some European countries have already manifested their interest on the IPS work for their future national Patient Summary for unscheduled care.
+
The cross-border care is not however the only expected usage scenario for the IPS. Some European countries have already manifested their interest on the IPS work for their future national Patient Summary for unscheduled care. Patient summary initiatives are currently in various stages of development in other parts of the world.
  
As shown by the user stories there are several possible options for the IPS in term of creation, sharing and usage of an IPS, for example:
+
As shown by the user stories there are several possible options in terms of creation, sharing and usage of an IPS. For example:
#an IPS could be a created when requested and used (before or during a care episode); or can be asynchronously generated and made available for future usage (e.g. store and retrieve).
+
#An IPS can be created when requested and used before, during, or after a care episode; or can be asynchronously generated and made available for future usage (e.g. store and retrieve).
#the IPS can be retrieved using a document exchange infrastructure; transported by the patient; or shared using cloud-services.
+
#The IPS can be retrieved using a document exchange infrastructure; transported by the patient; or shared using cloud-services.
#the IPS may be subject of a transformation process, that may include syntactical conversions; coded concepts mappings and coded concept designation or free text translations. This transformation process may be performed in the creation phase; during the transmission or after the reception for example using an external service.
+
#The IPS may be subject of a transformation process that may include syntactical conversions, coded concept mappings and coded concept designation or free text translations. This transformation process may be performed in the creation phase, during the transmission, or after the IPS has been received, possibly using an external service.
#Finally, the received CDA may be expected to be displayed using a common CDA stylesheet; may be used to extract some relevant information to be displayed by the EHR-S or to be incorporated into the receiver’s EHR; or a specialized viewer may be adopted to enable the display of the translated content.
+
#Finally, the received CDA may be used in different ways. For example, displayed using a common CDA stylesheet; display the extracted relevant information; incorporated into the receiver’s EHR. Alternatively, a specialized viewer may be adopted to enable the display of the translated content.
  
Moreover for cross-organizations/jurisdictions exchange the IPS could be used as:
+
 
#shared format among jurisdictions (case A): jurisdictions originate and use IPS conformant documents;
+
Moreover for cross-jurisdiction exchange, the IPS could be used as:
#pivot document among existing summaries / data formats (case B): for example as intermediate format between the US C-CDA CCD (Please note that the CCD scope differs from that of the IPS) and the European eHDSI Patient Summary for a Transatlantic Patient Summary exchange.
+
#shared format among jurisdictions (case A), where jurisdictions originate and use IPS conforming documents unaltered.
#Or in a mixed mode (Case C): either the originator or the consumer is expected to use an IPS conformant document.
+
#pivot document among existing summaries / data formats (case B). For example, the IPS is used as intermediate format between the US C-CDA CCD (please note that the CCD scope differs from that of the IPS) and the European eHDSI Patient Summary for a Transatlantic Patient Summary exchange.
 +
#mixed mode (Case C), where either the originator or the consumer is expected to use an IPS conforming document.
  
 
[[File:IPS_cases.png|none|600px]]
 
[[File:IPS_cases.png|none|600px]]
<ref group="Figure">Examples of IPS usage</ref>Examples of IPS usage
+
<ref group="Figure"> Examples of IPS usage</ref> Examples of IPS usage
  
 
Considering all those possible combinations and additional business requirements agreed by jurisdictions, there are several technical infrastructures and services that may be designed to support these requirements.
 
Considering all those possible combinations and additional business requirements agreed by jurisdictions, there are several technical infrastructures and services that may be designed to support these requirements.
  
It is out of scope of this standard to provide any indication about solutions and strategies for the IPS creation, sharing, syntactical and semantic mapping, translation, use.
+
It is out of scope of this standard to provide any indication about solutions and strategies for the IPS creation, sharing, syntactical and semantic mapping, translation, and use.
  
Having said that an International Patient Summary may be characterized by:
+
That said, an International Patient Summary may:
#being the result of an automatic assembling (assembled IPS) or of a human summarization act (human curated IPS)
+
#be the result of automatic assembly (assembled IPS) or of a human summarization act (human curated IPS)
#having one or more EHR sources
+
#have one or more EHR sources
 
#document information from a single or multiple jurisdictions/organizations
 
#document information from a single or multiple jurisdictions/organizations
#being the result of a single or multiple encounters
+
#aggregate input from a single or multiple encounters.
 +
 
  
A clear determination of such a kind of contextual information helps the comprehension and the trustiness on the received IPS. Most of these aspects are related to the data provenance, introduced in section [[#Provenance | Provenance]] above.
+
A clear determination of such contextual information raises the trustworthiness of the received IPS and helps the appropriate usage of its content by the receiver . Most of these aspects are related to data provenance introduced in [[#Relationships with other projects and guidelines| section 1.8]] and further detailed in  [[#Provenance| section 4.11]].
  
Even if in many jurisdictions require that only one active Patient Summary for unscheduled care would be made available; no constraints on this purpose are imposed by this guide being this strongly dependent on the case for which this template is used.
+
Even if many jurisdictions require that only one active Patient Summary for unscheduled care be made available, this guide does not impose such constraints and leaves them to jurisdictional implementations.
  
Moreover it is also out of scope for this guide to:
+
Moreover it is also out of scope of this guide to:
*provide guidance on how to determine the relevancy of data for their inclusion in a IPS;  
+
*provide guidance on how to determine the relevance of data for their inclusion in a IPS;  
 
*define selection or composition rules for facing potential inconsistencies from multiple sources in case of automatic collection.
 
*define selection or composition rules for facing potential inconsistencies from multiple sources in case of automatic collection.
  
== Code mappings and multilinguistic support ==
+
== Code mappings and multilingual support ==
The capability of managing locally used coded concepts and reference terminologies, and that of providing receiving providers with human readable information in a language that can be understood by them, are critical aspects to be taken in account for the cross-border sharing of documents.  
+
The capability of managing locally used coded concepts and reference terminologies, and that of providing receiving providers with human readable information in a language that can be understood by them, are critical aspects to be taken in account in the cross-border sharing of documents.  
 
This section summarizes some of the requirements related to these aspects, including also additional needs derived from the European cross-border services and some lessons learned by the EU/US Trillium Bridge Project.  
 
This section summarizes some of the requirements related to these aspects, including also additional needs derived from the European cross-border services and some lessons learned by the EU/US Trillium Bridge Project.  
The European cross-border services (eHDSI see link to eHDSI) use a business to business exchange infrastructure based on a network of countries’ gateways that hide the national infrastructures; the eHDSI Patient Summary (eHDSI PS) is used as a “pivot” document for the cross-country exchange: local data/document formats are in fact remapped into the eHDSI PS; the document exchanged is processed each time it passes through one of these a gateway applying the needed syntactical transformations; codes mapping; codes designations’ translation; finally, in the current practice the received PSs are displayed using specialized display tools, that build a human readable representation of the PS in the target language using the translated designations reported in the coded entries.
+
 
The adoption of translated narratives in the received document has been one of the indications received by the Trillium Bridge Project. This in fact allows extending the multi-linguistic support for the cross-border patient summaries to a wider set of potential consumers (EHR-Systems), without requiring specialized viewers as applied in the European services.  
+
The European cross-border services (eHDSI) use a business to business exchange infrastructure based on a network of country gateways that mediate access to the national infrastructures. The eHDSI Patient Summary (eHDSI PS) is used as a “pivot” document for the cross-border exchange. Local PS using data/document formats are in fact remapped into the eHDSI PS. The document exchanged is processed each time it passes through one of these gateway applying the needed syntactical transformation, code mappings. and translation of the code designations. Finally, in the current practice the received PSs are displayed using specialized display tools that build a human readable representation of the PS in the target language using the translated designations reported in the coded entries.
 +
 
 +
The adoption of translated narratives in the received document has been one of the indications received by the Trillium Bridge Project. This in fact allows extending multilingual support for the cross-border patient summaries to a wider set of potential consumers (EHR-or PHR systems), without requiring specialized viewers as applied in the eHDSI services.  
  
 
=== Concept code mapping===
 
=== Concept code mapping===
In several real world cases the records used as source for the Patient Summaries may use locally adopted terminologies that – when possible – are remapped into the reference value sets; or may be able in some cases to provide only uncoded information.
+
In several real world use cases the records used as source for the Patient Summaries may use locally adopted terminologies, which are mapped to the reference value sets when possible, or otherwise used directly to provide uncoded information. This leads to a series of requirements listed below and detailed further in [[#Design conventions and principles| section 4 Design conventions and principles]].
This leads to a series of requirements for the IPS that will be discussed in the [[#Design conventions and principles| Design conventions and principles]] section.
 
*When the original coded concept is mapped in one of the coded concepts included in the reference value sets (called hereafter reference code/coded concept), both the original and the reference codes should be reported in the IPS instance.
 
*When the original coded concept is not mapped in one of the coded concepts included in the reference value sets, the original code should be reported in the IPS instance as well as the indication that the mapping didn’t occur.
 
*When the original record, for a specific coded element, is not able to provide coded but only textual information, this information should be preserved in the IPS instance.
 
  
Moreover it should be taken in account that:
+
*When the original coded concept is mapped to one of the coded concepts included in the reference value sets (called hereafter reference code/coded concept), both the original and the reference codes '''SHALL''' be reported in the IPS instance.  
*The original record may support multiple coding, so that the IPS instance should be able to distinguish if the additional codes belong to the original content or they are the result of a coded concepts mapping.
+
*When the original coded concept is not mapped to one of the coded concepts included in the reference value sets, the original code '''SHALL''' be reported in the IPS instance as well as the indication that mapping was not successful.
*The original record may include references to the pieces of text the coding was derived from, if present, the IPS instance should preserve this link between the original code and the referred text.
+
*When the original record, for a specific coded element, is not able to provide coded but only textual information, this information '''SHALL''' be reported in the IPS instance.
*Distinct original and the reference coded concepts may belong to the same code system. This may be the result of a different level of granularity between the original and the reference value sets; or of a format transformation (e.g. a CCD document is used as input for generating an IPS). Also for these cases the requirement of recording both coded concepts should be applied.  
 
  
''Note: in some jurisdictions (as the European Cross-border services) some of these "should" may be turned into a "shall".''
+
This guide also accommodates these situations:
 +
*The original record may support multi-coding. The IPS instance should make clear whether the additional codes belong to the original content or are the result of post hoc concept code mapping.
 +
*The original record may include references to the pieces of text the coding was derived from.  If present, the IPS instance should preserve this link between the original code and the referred text.
 +
*Distinct original and reference coded concepts may belong to the same code system. This may be the result of a different level of granularity between the original and the reference value sets, or the result of format transformation - e.g. CCD document is used as input for generating an IPS. The requirement of recording both coded concepts applies also to these cases.
  
=== Multilinguistic support ===
+
=== Multilingual support ===
 
   
 
   
The debate on the multi linguistic support for the IPS could be split in two distinct subjects:
+
Multilingual support by IPS can be split in two categories of action:
 
#The translation of coded concept designations (displayName)
 
#The translation of coded concept designations (displayName)
#The translation of the narrative
+
#The translation of the narrative.
In both cases several options may be identified depending also on the use cases considered:
+
These actions may deal with various choices:
*The translation in the receiving country language: an IPS is prepared before a planned travel; a foreign provider retrieves a translated copy of the IPS from the patient country of affiliation…
+
*Translation to the language of the receiving care provider: a foreign provider retrieves a translated copy of the IPS from the patient's country of affiliation…
*The translation into a commonly agreed language: an English version of the IPS is prepared...
+
*Translation to a commonly agreed language: an English version of the IPS is prepared.
*The predefined set of translations is included in the shared IPS...
+
*Predefined set of translations included in the shared IPS.
It is out of the scope of this guide to suggest any of these solutions: all of them should be supported by this standard.
+
This guide does not favor any of these solutions.  All of them are supported.
  
==== Designations’ Translation ====
+
==== Translation of Designations====
Basically, the requirements related to the translation of the designations derive from the European Cross-border services imposing as functional requirements that for “safety and liability reasons” that all the terms (designations, displayName) associated to the original codes in the original language shall be recorded in the exchanged documents; together with the English and the receiving country language terms (designations, displayName) associated to the reference codes. The designations translated in the receiving country language are used for generating the human readable content shown to the receiving provider. No free text translation is applied in this case.
+
The European Cross-border services requires that for “safety and liability reasons” all of the original coded terms (designations, displayName) shall be recorded in the exchanged documents together with at least the English and the receiving country language terms (designations, displayName) associated with the reference codes.  
In order to accomplish this need, the IPS should have the capability of recording one or more designations, possibly indicating the language used.
+
The designations translated in the receiving country language are used to generate the human readable content shown to the receiving provider. No free text translation is applied in this case.
 +
In order to accomplish this objective, the IPS should have the capability to record one or more designations, possibly indicating the language used.
 +
The solution chosen to fulfill this requirement is specified in section 4.6.
  
 
==== Narrative Translation ====
 
==== Narrative Translation ====
With the term narrative translation two different concepts are covered:
+
Narrative translation covers two kinds of operations:
*The translation of the original narrative text. This can be in principle:
+
*Translation of the original narrative text, which can be automated (e.g. using translation services) and/or human curated.
**Human curated
+
*Creation of new narrative for the target language, based on the coded entries.
**Automatically performed (e.g. using specialized or generic translation services)
 
*The creation of a new translated narrative based on the coded entries.
 
  
Different levels of quality and liability can be obtained depending on the solution adopted and on the translation service used.  
+
The level of quality and liability obtained depends on the solution adopted and on the quality of the translation service used.
It is out of the scope of this guide to suggest any of these solutions, in all the cases however:
+
It is out of the scope of this guide to suggest any of these solutions.  In all cases, however:
 
*the language of the narrative should be identifiable
 
*the language of the narrative should be identifiable
 
*the original and the translated narrative should be clearly distinguished
 
*the original and the translated narrative should be clearly distinguished
*the methodology applied for the narrative translation (e.g. derived from the coded entries; translated by a generic service;..) should be recognizable
+
*the translation methodology applied (e.g. derived from the coded entries; translated by a generic service;..) should be noted

Latest revision as of 21:01, 31 January 2018

Functional requirements and high-level use cases

Several use cases may be identified for the International Patient Summary within its scope (“specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care”). Section Examples provide a subset of some real world user stories for the cross-border care developed by the Trillium Bridge Project and by the S&I EU-US eHealth Cooperation Initiative in the scope of the EU/US Roadmap initiative.

The cross-border care is not however the only expected usage scenario for the IPS. Some European countries have already manifested their interest on the IPS work for their future national Patient Summary for unscheduled care. Patient summary initiatives are currently in various stages of development in other parts of the world.

As shown by the user stories there are several possible options in terms of creation, sharing and usage of an IPS. For example:

  1. An IPS can be created when requested and used before, during, or after a care episode; or can be asynchronously generated and made available for future usage (e.g. store and retrieve).
  2. The IPS can be retrieved using a document exchange infrastructure; transported by the patient; or shared using cloud-services.
  3. The IPS may be subject of a transformation process that may include syntactical conversions, coded concept mappings and coded concept designation or free text translations. This transformation process may be performed in the creation phase, during the transmission, or after the IPS has been received, possibly using an external service.
  4. Finally, the received CDA may be used in different ways. For example, displayed using a common CDA stylesheet; display the extracted relevant information; incorporated into the receiver’s EHR. Alternatively, a specialized viewer may be adopted to enable the display of the translated content.


Moreover for cross-jurisdiction exchange, the IPS could be used as:

  1. shared format among jurisdictions (case A), where jurisdictions originate and use IPS conforming documents unaltered.
  2. pivot document among existing summaries / data formats (case B). For example, the IPS is used as intermediate format between the US C-CDA CCD (please note that the CCD scope differs from that of the IPS) and the European eHDSI Patient Summary for a Transatlantic Patient Summary exchange.
  3. mixed mode (Case C), where either the originator or the consumer is expected to use an IPS conforming document.
IPS cases.png

[Figure 1] Examples of IPS usage

Considering all those possible combinations and additional business requirements agreed by jurisdictions, there are several technical infrastructures and services that may be designed to support these requirements.

It is out of scope of this standard to provide any indication about solutions and strategies for the IPS creation, sharing, syntactical and semantic mapping, translation, and use.

That said, an International Patient Summary may:

  1. be the result of automatic assembly (assembled IPS) or of a human summarization act (human curated IPS)
  2. have one or more EHR sources
  3. document information from a single or multiple jurisdictions/organizations
  4. aggregate input from a single or multiple encounters.


A clear determination of such contextual information raises the trustworthiness of the received IPS and helps the appropriate usage of its content by the receiver . Most of these aspects are related to data provenance introduced in section 1.8 and further detailed in section 4.11.

Even if many jurisdictions require that only one active Patient Summary for unscheduled care be made available, this guide does not impose such constraints and leaves them to jurisdictional implementations.

Moreover it is also out of scope of this guide to:

  • provide guidance on how to determine the relevance of data for their inclusion in a IPS;
  • define selection or composition rules for facing potential inconsistencies from multiple sources in case of automatic collection.

Code mappings and multilingual support

The capability of managing locally used coded concepts and reference terminologies, and that of providing receiving providers with human readable information in a language that can be understood by them, are critical aspects to be taken in account in the cross-border sharing of documents. This section summarizes some of the requirements related to these aspects, including also additional needs derived from the European cross-border services and some lessons learned by the EU/US Trillium Bridge Project.

The European cross-border services (eHDSI) use a business to business exchange infrastructure based on a network of country gateways that mediate access to the national infrastructures. The eHDSI Patient Summary (eHDSI PS) is used as a “pivot” document for the cross-border exchange. Local PS using data/document formats are in fact remapped into the eHDSI PS. The document exchanged is processed each time it passes through one of these gateway applying the needed syntactical transformation, code mappings. and translation of the code designations. Finally, in the current practice the received PSs are displayed using specialized display tools that build a human readable representation of the PS in the target language using the translated designations reported in the coded entries.

The adoption of translated narratives in the received document has been one of the indications received by the Trillium Bridge Project. This in fact allows extending multilingual support for the cross-border patient summaries to a wider set of potential consumers (EHR-or PHR systems), without requiring specialized viewers as applied in the eHDSI services.

Concept code mapping

In several real world use cases the records used as source for the Patient Summaries may use locally adopted terminologies, which are mapped to the reference value sets when possible, or otherwise used directly to provide uncoded information. This leads to a series of requirements listed below and detailed further in section 4 Design conventions and principles.

  • When the original coded concept is mapped to one of the coded concepts included in the reference value sets (called hereafter reference code/coded concept), both the original and the reference codes SHALL be reported in the IPS instance.
  • When the original coded concept is not mapped to one of the coded concepts included in the reference value sets, the original code SHALL be reported in the IPS instance as well as the indication that mapping was not successful.
  • When the original record, for a specific coded element, is not able to provide coded but only textual information, this information SHALL be reported in the IPS instance.

This guide also accommodates these situations:

  • The original record may support multi-coding. The IPS instance should make clear whether the additional codes belong to the original content or are the result of post hoc concept code mapping.
  • The original record may include references to the pieces of text the coding was derived from. If present, the IPS instance should preserve this link between the original code and the referred text.
  • Distinct original and reference coded concepts may belong to the same code system. This may be the result of a different level of granularity between the original and the reference value sets, or the result of format transformation - e.g. CCD document is used as input for generating an IPS. The requirement of recording both coded concepts applies also to these cases.

Multilingual support

Multilingual support by IPS can be split in two categories of action:

  1. The translation of coded concept designations (displayName)
  2. The translation of the narrative.

These actions may deal with various choices:

  • Translation to the language of the receiving care provider: a foreign provider retrieves a translated copy of the IPS from the patient's country of affiliation…
  • Translation to a commonly agreed language: an English version of the IPS is prepared.
  • Predefined set of translations included in the shared IPS.

This guide does not favor any of these solutions. All of them are supported.

Translation of Designations

The European Cross-border services requires that for “safety and liability reasons” all of the original coded terms (designations, displayName) shall be recorded in the exchanged documents together with at least the English and the receiving country language terms (designations, displayName) associated with the reference codes. The designations translated in the receiving country language are used to generate the human readable content shown to the receiving provider. No free text translation is applied in this case. In order to accomplish this objective, the IPS should have the capability to record one or more designations, possibly indicating the language used. The solution chosen to fulfill this requirement is specified in section 4.6.

Narrative Translation

Narrative translation covers two kinds of operations:

  • Translation of the original narrative text, which can be automated (e.g. using translation services) and/or human curated.
  • Creation of new narrative for the target language, based on the coded entries.

The level of quality and liability obtained depends on the solution adopted and on the quality of the translation service used. It is out of the scope of this guide to suggest any of these solutions. In all cases, however:

  • the language of the narrative should be identifiable
  • the original and the translated narrative should be clearly distinguished
  • the translation methodology applied (e.g. derived from the coded entries; translated by a generic service;..) should be noted


Cite error: <ref> tags exist for a group named "Figure", but no corresponding <references group="Figure"/> tag was found, or a closing </ref> is missing