Publication cleanup

input/examples/IPS-bundle-01.xml

@@ -14,6 +14,10 @@
 		<resource>
 			<Composition>
 				<id value="30551ce1-5a28-4356-b684-1e639094ad4d"/>
+        <text>
+           <status value="generated" />
+           <div xmlns="http://www.w3.org/1999/xhtml"><p><b>Generated Narrative</b></p><div style="display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%"><p style="margin-bottom: 0px">Resource "30551ce1-5a28-4356-b684-1e639094ad4d" </p></div><p><b>identifier</b>: id: 3f69e0a5-2177-4540-baab-7a5d0877428f</p><p><b>status</b>: final</p><p><b>type</b>: Patient summary Document <span style="background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki"> (<a href="https://loinc.org/">LOINC</a>#60591-5)</span></p><p><b>date</b>: 2017-12-11 02:30:00+0100</p><p><b>author</b>: Beetje van Hulp, MD</p><p><b>title</b>: Patient Summary as of December 11, 2017 14:30</p><p><b>confidentiality</b>: N</p><blockquote><p><b>attester</b></p><p><b>mode</b>: legal</p><p><b>time</b>: 2017-12-11 02:30:00+0100</p><p><b>party</b>: Beetje van Hulp, MD</p></blockquote><blockquote><p><b>attester</b></p><p><b>mode</b>: legal</p><p><b>time</b>: 2017-12-11 02:30:00+0100</p><p><b>party</b>: Anorg Aniza Tion BV</p></blockquote><p><b>custodian</b>: Anorg Aniza Tion BV</p><h3>RelatesTos</h3><table class="grid"><tr><td>-</td><td><b>Code</b></td><td><b>Target[x]</b></td></tr><tr><td>*</td><td>appends</td><td>id: c2277753-9f90-4a95-8ddb-a0b3f6e7d292</td></tr></table><h3>Events</h3><table class="grid"><tr><td>-</td><td><b>Code</b></td><td><b>Period</b></td></tr><tr><td>*</td><td>care provision <span style="background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki"> (<a href="http://terminology.hl7.org/3.1.0/CodeSystem-v3-ActClass.html">ActClass</a>#PCPR)</span></td><td>?? --&gt; 2017-12-11 02:30:00+0100</td></tr></table></div>
+        </text>
 				<identifier>
 					<system value="urn:oid:2.16.724.4.8.10.200.10"/>
 					<value value="3f69e0a5-2177-4540-baab-7a5d0877428f"/>

input/examples/bundle-minimal.json

@@ -14,6 +14,10 @@
       "resource": {
         "resourceType": "Composition",
         "id": "6e1fb74a-742b-4c7b-8487-171dacb88766",
+        "text": {
+          "status": "generated",
+          "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><div style=\"display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%\"><p style=\"margin-bottom: 0px\">Resource \"6e1fb74a-742b-4c7b-8487-171dacb88766\" </p></div><p><b>status</b>: final</p><p><b>type</b>: Patient summary Document <span style=\"background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki\"> (<a href=\"https://loinc.org/\">LOINC</a>#60591-5)</span></p><p><b>date</b>: 2020-12-11 02:30:00+0100</p><p><b>author</b>: Beetje van Hulp, MD </p><p><b>title</b>: Patient Summary as of December 11, 2020 14:30</p><p><b>confidentiality</b>: N</p><blockquote><p><b>attester</b></p><p><b>mode</b>: legal</p><p><b>time</b>: 2020-12-11 02:30:00+0100</p><p><b>party</b>: Beetje van Hulp, MD </p></blockquote><blockquote><p><b>attester</b></p><p><b>mode</b>: legal</p><p><b>time</b>: 2020-12-11 02:30:00+0100</p><p><b>party</b>: Anorg Aniza Tion BV </p></blockquote><p><b>custodian</b>: Anorg Aniza Tion BV</p><h3>RelatesTos</h3><table class=\"grid\"><tr><td>-</td><td><b>Code</b></td><td><b>Target[x]</b></td></tr><tr><td>*</td><td>appends</td><td>id: 20e12ce3-857f-49c0-b888-cb670597f191</td></tr></table><h3>Events</h3><table class=\"grid\"><tr><td>-</td><td><b>Code</b></td><td><b>Period</b></td></tr><tr><td>*</td><td>care provision <span style=\"background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki\"> (<a href=\"http://terminology.hl7.org/3.1.0/CodeSystem-v3-ActClass.html\">ActClass</a>#PCPR)</span></td><td>?? --&gt; 2020-12-11 02:30:00+0100</td></tr></table></div>"
+        },
         "status": "final",
         "type": {
           "coding": [

input/examples/medication-39-07-1.xml

@@ -17,7 +17,7 @@
 			<code value="C10AA01"/>
 			<display value="simvastatin"/>
 		</coding>
-		<text value="Fluspiral 50 mcg"/>
+		<text value="Simvastatin 40 MG Disintegrating Oral Tablet"/>
 	</code>
 	<form>
 		<coding>

input/pagecontent/StructureDefinition-Composition-uv-ips-intro.xml

@@ -1,7 +1,9 @@
 <div xmlns="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 	<blockquote class="stu-note">
-		<p>In this version of the guide the Medication Summary is expressed as a list of MedicationStatements. The reason for this choice is explained in the <a href="design.html#the-use-of-medication-statements-in-the-summary">Design Conventions and Principles</a> page.</p>
-		<p>STU implementers are encouraged to provide their feedback about this design choice.</p>
+		<p>In this version of the guide the Medication Summary is expressed as a list of MedicationStatements or 
+    MedicationRequests. More information on medications lists are included in the <a href="design.html#medication-lists-in-the-ips">
+    Design Conventions and Principles</a> page.</p>
+	  <p>STU implementers are encouraged to provide their feedback about this design choice.</p>
 	</blockquote>
 	<blockquote class="stu-note">
 		<p>Particularly in light of the currect state of global health and the response to the COVID-19 pandemic 

input/pagecontent/design.md

@@ -14,7 +14,7 @@ The following sections are recommended (not required), and for these sections in
 
 All of the other sections are expected to be omitted in the case of absence of information.
 
-### Profiling approach
+### Profiling Approach
 
 By design, the IPS dataset is a "minimal and non-exhaustive patient summary dataset, specialty-agnostic, condition-independent, but readily usable by clinicians for the cross-border unscheduled care of a patient".
 
@@ -26,27 +26,11 @@ The second has been finally chosen for the following reasons:
 * facilitate the reuse of the IPS profiles in sibling use cases.
 * enable a progressive access to additional information beyond the minimal one, if available and relevant for the care provisioning.
 
-### Open slices and the use of alternative Code Systems
+### Open Slicing in the IPS
 
 One of the important and useful capabilities of FHIR profiling is [slicing](http://hl7.org/fhir/profiling.html#slicing), where multiple sets of constraints for a specific use case can be defined for a resource element or a complex element group (slicing can be used with repeating, type choice or non-repeating elements). Most of the slices specified in this guide are _open_ (i.e. `slicing.rules` is not `closed`), which means that it is possible for resource instances with elements that do not match any of the defined slices to still be conformant with the profile as long as they satisfy the remaining profile constraints.
 
-Having this clear is important for correctly understanding the published profiles, particularly those using a value set binding for discriminating the slices.
-
-It is in fact allowed in these cases to use alternative value sets / code systems that are not those that are _'required'_. Let's take as an example the slicing of Condition.code in the [Condition-uv-ips](StructureDefinition-Condition-uv-ips.html) profile. This profile specifies two slices for this element:
-1. One to indicate a problem from the SNOMED CT Global Patient Set (GPS) ( [CORE Problem List Finding/Situation/Event (GPS) - IPS](ValueSet-core-problem-finding-situation-event-gps-uv-ips.html) )
-1. One for  unknown or absent relevant problems ( [Absent or Unknown Problems - IPS](ValueSet-absent-or-unknown-problems-uv-ips.html) )
-
-Since this slicing is open, the presence of these two required value sets doesn't prevent implementers or specifiers from representing a problem by using a code from an alternative code system (e.g. ICD-11) as the primary code. The code fragment below shows an example of using ICD-11 for coding the problem, as included as one of the Coding instances in the [Condition example](Condition-eumfh-39-07-1.html) for "Acute myocardial infarction of anterior wall" in this guide.
-
-```
-	<code>
-		<coding>
-			<system value="http://id.who.int/icd11/mms"/>
-			<code value="BA41&XA7RE3"/>
-			<display value="Acute myocardial infarction & Anterior wall of heart"/>
-		</coding>
-	</code>
-```
+Having this clear is important for correctly understanding the published profiles. For example, the optional section of [Social History](./StructureDefinition-Composition-uv-ips-definitions.html#Composition.section:sectionSocialHistory.entry) has open slicing on the entry element allowing for the use of the [IPS Tobacco Use profile](./StructureDefinition-Observation-tobaccouse-uv-ips.html), the [IPS Alcohol Use profile](./StructureDefinition-Observation-alcoholuse-uv-ips.html), or any other Observation or DocumentReference. Therefore, while specific IPS profiles are described in this guide, other profiles may also be included as well. 
 
 ### Must Support
 In the context of the IPS, mustSupport on any data element SHALL be interpreted as follows:
@@ -94,38 +78,40 @@ In the context of the IPS, mustSupport on any data element SHALL be interprete
    - *required* binding strength (CodeableConcept or code datatypes):
       - use the appropriate exceptional concept code from the value set
 
-### Translation of designations and narratives
+### Translation of Structured Data and Narratives
 
 The functional requirement of supporting the translation of the designations has been addressed in this guide extending the coding data type (Coding-uv-ips).
 
+While the IPS standard allows for language translations to be included, both in coded display and narrative, there should be no expectation by downstream consumers (e.g. another nation in cross-border sharing) that local language translations will be present.
+
 For details about the support of narrative translations please refer to the [Multi-Language support in FHIR](http://build.fhir.org/languages.html) section.
 
 ### Representation of Person Names
+
 This specification requires that any Person Name is represented including at least the given and family components.
 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. 
 
-### The use of medication statements in the summary
-Medication lists may vary significantly depending on the context of use (e.g. support for prescription or dispensing, medication 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 also true 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); a list of actually dispensed medications; a list of relevant medications for the patient (IHE PCC); or conversely, it could be a complete history including the full patient's prescription and dispensing history and information about intended drug monitoring (HL7 C-CDA).
+### Medication Lists in the IPS
 
-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 the medication statement, as represented in the FHIR MedicationStatement resource (see https://www.hl7.org/fhir/medicationstatement.html).
+Medication lists may vary significantly depending on the context of use (e.g. support for prescription or dispensing, medication 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 also true 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); a list of actually dispensed medications; a list of relevant medications for the patient (IHE PCC); or conversely, it could be a complete history including the full patient's prescription and dispensing history and information about intended drug monitoring (HL7 C-CDA).
 
-The IPS medication summary is therefore a list of relevant medication statements, possibly built from either a prescription list or a dispensing 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 regional/national prescribing and/or dispensing systems. In these cases, data obtained from the actual dispensing and/or prescription records can be still recorded in the IPS as statements, and the original request, supply or administration records may be referred to by the statement if really needed.  
+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 can be met with either the [MedicationStatement](./StructureDefinition-MedicationStatement-uv-ips.html) or [MedicationRequest](./StructureDefinition-MedicationRequest-uv-ips.html) profile, both of which are included in this IPS Implementation Guide. 
 
-In the recent US Core [profiles](http://hl7.org/fhir/us/core/index.html) (based on FHIR R4), the use of MedicationStatement has been replaced by [MedicationRequest](http://hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html).  In the IPS IG specification we have elected not to take this approach, and instead are continuing with the approach using medication statements as described above.  However, it should be noted that due to the use of open slicing in the IPS specification, it is still possible to include instances of MedicationRequest as the entries in the Medication section of the IPS Composition and Bundle and remain conformant to the IPS specification.
+The IPS medication summary is therefore a list of relevant medications, possibly built from either a prescription list or a dispensing list. In fact, in many practical cases data included in a Patient Summary are derived from the list of the medicines prescribed by a general practitioner and recorded in its electronic health record; or extracted from regional/national prescribing and/or dispensing systems.   
 
 ### Medicinal Product Identification
 
-A general introduction to the problem of cross-jurisdictional identification of medicinal product is provided in the [IPS CDA implementation guide](http://international-patient-summary.net/mediawiki/index.php?title=IPS_Design_conventions_and_principles_1###Medicinal_Product_Identification)
+A general introduction to the problem of cross-jurisdictional identification of medicinal product is provided in the [IPS CDA implementation guide](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=483)
 
 As for the CDA implementation guide, this guide describes how the relevant IDMP identifiers and attributes, namely the Pharmaceutical Product Identifiers (PhPIDs), the Medicinal Product Identifier (MPID), and the Medicinal Product Package Identifier (PCID) are represented in the IPS.
 
 The solution proposed for the FHIR IPS IG is slightly different from that adopted in the CDA IG and follows the current indications of the FHIR community: all the relevant product codes are represented in fact as one of the possible Codings of the product CodeableConcept, rather than being expressed as distinct attributes/resources (which is a possible approach). The same approach is followed for the vaccines.
 
 ### Provenance
 
-This guide follows the principles described in the [IPS CDA implementation guide](http://international-patient-summary.net/mediawiki/index.php?title=IPS_Design_conventions_and_principles_1###Provenance)
+This guide follows the principles described in the [IPS CDA implementation guide](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=483)
 
 In that sense it allows to determine whether the IPS document is constructed by a human or an automated process, regardless of whether the IPS contains some content of both kinds.