IPS Functional requirements 1 - Revision history

Gcangioli: /* Code mappings and multilingual support */

2018-01-31T21:01:15Z

‎Code mappings and multilingual support

Gcangioli: /* Functional requirements and high-level use cases */

2018-01-31T20:05:26Z

‎Functional requirements and high-level use cases

Gcangioli: /* Functional requirements and high-level use cases */

2018-01-31T20:04:38Z

‎Functional requirements and high-level use cases

Gcangioli: /* Functional requirements and high-level use cases */

2018-01-31T19:54:49Z

‎Functional requirements and high-level use cases

Rhausam: /* Multilingual support */

2017-12-17T12:45:15Z

‎Multilingual support

Rhausam: /* Concept code mapping */

2017-12-17T12:39:27Z

‎Concept code mapping

Gcangioli: /* Functional requirements and high-level use cases */

2017-10-31T16:41:37Z

‎Functional requirements and high-level use cases

Gcangioli: /* Functional requirements and high-level use cases */

2017-10-31T16:17:27Z

‎Functional requirements and high-level use cases

Gcangioli: /* Multilingual support */

2017-10-11T08:12:40Z

‎Multilingual support

Gcangioli: /* Functional requirements and high-level use cases */

2017-10-11T08:11:12Z

‎Functional requirements and high-level use cases

@@ Line 43: / Line 43: @@
 This section summarizes some of the requirements related to these aspects, including also additional needs derived from the European cross-border services and some lessons learned by the EU/US Trillium Bridge Project.
-The European cross-border services (eHDSI see link to eHDSI) use a business to business exchange infrastructure based on a network of country gateways that mediate access to the national infrastructures. The eHDSI Patient Summary (eHDSI PS) is used as a “pivot” document for the cross-border exchange. Local PS using data/document formats are in fact remapped into the eHDSI PS. The document exchanged is processed each time it passes through one of these gateway applying the needed syntactical transformation, 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 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.

@@ Line 28: / Line 28: @@
 #have one or more EHR sources
 #document information from a single or multiple jurisdictions/organizations
-#aggregate input from a single or multiple encounters
+#aggregate input from a single or multiple encounters.

@@ Line 28: / Line 28: @@
 #have one or more EHR sources
 #document information from a single or multiple jurisdictions/organizations
-#be aggregate input from a single or multiple encounters
+#aggregate input from a single or multiple encounters

@@ Line 9: / Line 9: @@
 #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 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 displayed using a common CDA stylesheet; may be used to extract some relevant information to be displayed by the EHR-S or to be incorporated into the receiver’s EHR. Alternatively, a specialized viewer may be adopted to enable the display of the translated content.
+#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:

@@ Line 67: / Line 67: @@
 *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 flavors any of these solutions.  All of them are supported.
+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 the original coded terms (designations, displayName) shall be recorded in the exchanged documents together with at least the English and the receiving country language terms (designations, displayName) associated to the reference codes.
+The 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.
@@ Line 81: / Line 81: @@
 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 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.
+*the translation methodology applied  (e.g. derived from the coded entries; translated by a generic service;..) should be noted

@@ Line 54: / Line 54: @@
 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 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.
+*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 thses cases.
+*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 ===

@@ Line 13: / Line 13: @@
 Moreover for cross-jurisdiction exchange, the IPS could be used as:
 #shared format among jurisdictions (case A), where jurisdictions originate and use IPS conforming documents unaltered.
-#pivot document among existing summaries / data formats (case B), where IPS is used as intermediate format between the US C-CDA CCD (note that the CCD scope differs from that of the IPS) and the European eHDSI Patient Summary for a Transatlantic Patient Summary exchange.
+#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.

@@ Line 23: / Line 23: @@
 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:
+That said, an International Patient Summary may:
 #be the result of automatic assembly (assembled IPS) or of a human summarization act (human curated IPS)
 #have one or more EHR sources

@@ Line 60: / Line 60: @@
 === Multilingual support ===
-The debate on multilingual 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 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 to the language of  the receiving country: an IPS is prepared before a planned travel; a foreign provider retrieves a translated copy of the IPS from the patient's country of affiliation…
+*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, e.g. 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 flavors any of these solutions.  All of them are supported.
 ==== Translation of Designations====

@@ Line 32: / Line 32: @@
 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 are imposed or assumed by this guide as this strongly depends on the particular use case.
+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: