V.1.0.9 rc1

docs/_config.yml

@@ -4,7 +4,7 @@ description: "Governance for MedCom HL7 FHIR®© Messaging is the basic ruleset
 show_downloads: false
 google_analytics:
 theme: jekyll-theme-minimal
-version: "Version 1.0.8"
+version: "Version 1.0.9"
 fhir_version: "FHIR®© R4"
 releasenote: https://github.com/medcomdk/MedCom-FHIR-Communication/releases
 thisurl: https://medcomdk.github.io/MedCom-FHIR-Communication/

docs/assets/documents/030_Governance-for-Network-Layer.md

@@ -47,6 +47,7 @@ Sending MedCom FHIR messages over the VANS Network requires the sending system t
 When sending to both primary and cc destinations.
 
 1. A Sending Ecosystem **MUST** secure that the MedCom FHIR messages for primary and cc receivers differs on ID's as described in [Governance for MedCom FHIR Messaging](040_Governance4FHIR-Messaging.md)
+2. A Sending Ecosystem **MUST** ensure that the size of a MedCom FHIR message embeded in a VANSEnvelope is above 100 MB when send on the VANS Network. If the validation of size is before embedment in a VANSEnvelope, it is allowed for the sending ecosystem to set a limit to 100 MB, e.g. 98 MB, to ensure room for the embedment in VANS-envelope.
 
 ## 4 Receiving MedCom FHIR messages
 

docs/assets/documents/050_Governance-for-MedCom-FHIR-Messages.md

@@ -71,7 +71,7 @@ An inherited instance profile of MedComMessagingMessageHeader **SHALL** follow t
 
 #### 2.1 MedComMessagingMessageHeader Rules
 
-The MedComMessageHeader profile is a resource that **SHALL** be used in all MedCom FHIR Messages. A MedComMessagingMessageHeader **SHALL** include a sender and receiver and it **may** include a carbon-copy receiver, however this is depended on type of standard. Each MedComMessagingMessageHeader **SHALL** include a globally unique id, which **SHALL** be used to reference the message in the message history from the MedComMessagingProvenance profile.
+The MedComMessageHeader profile is a resource that **SHALL** be used in all MedCom FHIR Messages. A MedComMessagingMessageHeader **SHALL** include a sender and receiver and it **MAY** include a carbon-copy receiver, however this is depended on type of standard. Each MedComMessagingMessageHeader **SHALL** include a globally unique id, which **SHALL** be used to reference the message in the message history from the MedComMessagingProvenance profile.
 
 The element event **SHALL** be defined in accordance with the type of standard the message concerns e.g., HospitalNotification and CareCommunication. Due to the different requirements for each standard, it **SHALL** be expected that the MedComMessagingMessageHeader is inherited in each standard.
 
@@ -106,7 +106,7 @@ A MedComMessagingOrganization that is referenced as either a "primary" receiver
 
 A MedComMessagingOrganization **SHALL** include both a SOR and an EAN/GLN identifier.
 
-A MedComMessagingOrganization **MAY** include more identifiers. These Identifiers **SHOULD NOT** be expected to introduce application logic for the receiver(s) of the FHIRMessage.
+A MedComMessagingOrganization **MAY** include more identifiers. These Identifiers ****SHOULD** NOT** be expected to introduce application logic for the receiver(s) of the FHIRMessage.
 
 #### 3.2 MedComMessagingOrganization Links
 
@@ -119,6 +119,7 @@ A MedComMessagingOrganization **MAY** include more identifiers. These Identifier
 <br>
 
 ### 4 MedComMessagingProvenance
+The Provenance resource tracks information about the activity what was created, revised, or deleted, while referencing the current message and previous messages if such exist. To identify the actual content of the message and time of activity, it is important to look in the resources carrying the clinical content, such as the Encounter for the HosptialNotification standard, and the Communication for the CareCommunication standard.
 
 #### 4.1 MedComMessagingProvenance Rules
 
@@ -140,15 +141,13 @@ A MedComMessagingOrganization **MAY** include more identifiers. These Identifier
 
 Unless otherwise stated, the following criteria apply to elements marked as “Must Support” in MedCom's Implementation Guides:
 
-Labeling an element MustSupport means that implementations that produce or consume resources **SHALL** provide "support" for the element in some meaningful way. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as mustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.
+Labeling an element MustSupport means that implementations that produce or consume resources **SHALL** provide "support" for the element in some meaningful way, and is therefore a part of a standard. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as mustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.
 
 <br>
 
 #### 5.1 MustSupport Rules
 
-In MedCom FHIR Messaging MustSupport requires that a system
-
-Systems supporting the profile **MUST NOT** ignore the field.
+In MedCom FHIR Messaging MustSupport requires that a system provides "support" for the element in some meaningful way. A meaningful way depends on the type of information, which will be expressed for each standard.
 
 **For technical profiles**
 
@@ -164,11 +163,11 @@ Systems sending or creating a resource instance
 **MUST** populate the element according to the rules defined for the profile
 
 For Logical Models
-Functional Analysis MUST consider the data element as defined
+Functional Analysis **MUST** consider the data element as defined
 
-“Must Support” elements that are used in an implementation MUST inherit the behaviour and constraints defined for the data element
-“Must Support” elements not needed in a particular implementation MAY be excluded from implementation but such exclusion MUST be described
-Derived implementations SHOULD inherit the field’s “Must Support” flag
+“Must Support” elements that are used in an implementation **MUST** inherit the behaviour and constraints defined for the data element
+“Must Support” elements not needed in a particular implementation MAY be excluded from implementation but such exclusion **MUST** be described
+Derived implementations **SHOULD** inherit the field’s “Must Support” flag
 
 #### 5.2 MustSupport Links
 
@@ -179,15 +178,17 @@ Derived implementations SHOULD inherit the field’s “Must Support” flag
 <br>
 
 ### 6 Narrative Texts
+The narrative text contains sufficient detail to make it "clinically safe" for a human to just read the narrative. 
+
+The narrative text **SHALL** encode all the structured data pointed out by the ∑-symbol in combination with MustSupport. Elements only marked with the ∑-symbol, and not MustSupport are not expected to be a part of the narrative text. 
 
-The narrative text **SHALL** encode all the structured data pointed out by the ∑-symbol and it **SHALL** contain sufficient detail to make it "clinically safe" for a human to just read the narrative.
-Contained resources do not have narrative, but their content **SHALL** be represented in the ressource container.
+Each resource, beside the MedComMessagingMessage, **SHALL** contain a narrative text in the element text, eventhough this element is not marked with MS or has a minimum cardinality of 1.
 
-Narratives contains two sub elements, status and div.
+Narratives contain two sub elements, status and div.
 
 #### 6.1 The status element
 
-In MedCom FHIR Messages The code **SHALL** always be: "additional" meaning that the it is covering the code: extension and allowing for more human readable text in the div element than is produced by: generated and extension.
+In MedCom FHIR Messages the status **SHALL** always be "generated" meaning that the narrative is generated from elements with ∑-symbol and MustSupport, or "extension" meaning that in addition to "generated", it is including extensions.
 
 A narrative in MedCom FHIR Messages **SHALL NEVER** be of code: empty.
 
@@ -197,13 +198,15 @@ The contents of the div element are XHTML fragments that **SHALL** contain only
 
 The XHTML content **SHALL NOT** contain a head, a body element, external stylesheet references, deprecated elements, scripts, forms, base/link/xlink, frames, iframes, objects or event related attributes (e.g. onClick). 
 
-The div element **SHALL** have some non-whitespace content (text or an image).
+If a resource includes a base-64-encoded attachment, this **SHALL NOT** be included in the narrative text, as it will cause the size of the message to increase rapidly.
 
 #### 6.3 General Narrative Text Rules
 
-* All resources in a MedComMessagingMessage **SHALL** contain a Narrative Text defined by the [resource].Text element
-* The Narrative Text **SHALL** have a status with value "extensions". Extensions means that the contents of the narrative are entirely generated from the core elements in the content and some of the content is generated from extensions.
-* The narrative **SHALL** reflect the impact of all modifier extensions.
+* All resources in a MedComMessagingMessage **SHALL** contain a Narrative Text defined by the [resource].text element.
+* The Narrative Text **SHALL** have a status with value "generated" or "extensions". 
+* The Narrative Text **SHALL** include elements marked with ∑-symbol in combination with MustSupport. 
+* The Narrative Text **SHALL NOT** include base-64-encoded attachments.
+
 
 #### 6.4 Links for Narrative Text
 

docs/assets/documents/052.2_MessageHeader_Identifiers_Timestamps.md

@@ -25,3 +25,5 @@ A message has several important timestamps:
 - Provenance.recorded: The Provenance.recorded **SHALL** be a machine understandable time the message was sent
 
 In addition, the message **MAY** have additional timestamps in additional resources in the message. The meaning of these will depend on the message event.
+
+Timestamps of the FHIR data type dateTime or instant **SHALL** include a timezone, which may be 'Z' or a timezone of the format '+00:00', e.g. '+01:00'. 

docs/assets/documents/080_Governance-for-episode-of-care-identifiers.md

@@ -1,14 +1,14 @@
 # Governance for episode of care identifiers
 
 ## General in FHIR messages
-When relevant it is possible to include an episode of care identifier, it is contained in the [MedComCoreEncounter profile](https://medcomfhir.dk/ig/core/StructureDefinition-medcom-core-encounter.html) or a specialization of this profile. The episode of care identifier can be a locally defined UUID for the specific admission/contact or it can be an LPR3 identifier. The identifier is used for linking messages exchanged during a specific message flow. When the episode of care identifier is received e.g. in a ReportOfAdmission (Danish: Indlæggelsesrapport), ProgressOfCarePlan (Danish: Plejeforløbsplan), HospitalNotification (Danish: Advis om sygehusophold) or a previous CareCommunication (Danish: Korrespondancemeddelelse), it **MUST** be returned in the following message.
+When relevant it is possible to include an episode of care identifier, it is contained in the [MedComCoreEncounter profile](https://medcomfhir.dk/ig/core/StructureDefinition-medcom-core-encounter.html) or a specialization of this profile. The episode of care identifier can be a locally defined UUID for the specific admission/contact or it can be an LPR3 identifier. The identifier is used for linking messages exchanged during a specific message flow. When the episode of care identifier is received e.g. in a ReportOfAdmission (Danish: Indlæggelsesrapport), ProgressOfCarePlan (Danish: Plejeforløbsplan), HospitalNotification (Danish: Advis om sygehusophold) or a previous CareCommunication (Danish: Korrespondancemeddelelse), it **SHALL** be returned in the following message. If a correspondance, e.g. CareCommunication, concerns an admission with an episode of care identifier, the identifier can be included in the initial message.
 
-**In case only one episode of care identifier is included in the initial message, either a locally defined UUID for the specific admission/contact or an LPR3 identifier:** The following messages exchanged **MUST** return this episode of care identifier, regardless of whether it is a locally defined UUID or an LPR3 identifier. If more identifiers are subsequently added, these can be ignored (or returned if possible).
+**In case only one episode of care identifier is included in the initial message, either a locally defined UUID for the specific admission/contact or an LPR3 identifier:** The following messages exchanged **SHALL** return this episode of care identifier, regardless of whether it is a locally defined UUID or an LPR3 identifier. If more identifiers are subsequently added, these can be ignored (or returned if possible).
 
-**In case more episode of care identifiers are included in the initial message:** The following messages exchanged **MUST** return the locally defined UUID for the specific admission/contact. The other identifiers can be ignored (or returned if possible).
+**In case more episode of care identifiers are included in the initial message:** The following messages exchanged **SHALL** return the locally defined UUID for the specific admission/contact. The other identifiers can be ignored (or returned if possible).
 
 ### System for locally defined episode of care identifiers
-When a locally defined identifier for the specific admission/contact is included in a message, a system for the identifier shall also be included. The system is used to destinguish between the LPR3 identifier and the locally defined identifier. In the latter case, a new slice in the Encounter.episodeOfCare shall be added and the Encounter.episodeOfCare.identifier.system shall be added. The datatype of the system is Unique Resource Identifier Reference (uri), meaning that the system **MUST** be absolut or relative unique. It is recommended to use SOR-endpoint, which is also definied in the MessageHeader.source.endpoint. This is shown in the XML-snippet and examples below.
+When a locally defined identifier for the specific admission/contact is included in a message, a system for the identifier shall also be included. The system is used to destinguish between the LPR3 identifier and the locally defined identifier. In the latter case, a new slice in the Encounter.episodeOfCare shall be added and the Encounter.episodeOfCare.identifier.system shall be added. The datatype of the system is Unique Resource Identifier Reference (uri), meaning that the system **SHALL** be absolut or relative unique. It is recommended to use SOR-endpoint, which is also definied in the MessageHeader.source.endpoint. This is shown in the XML-snippet and examples below.
 
 ```xml
  <episodeOfCare>
@@ -24,6 +24,6 @@ The general use of an episode of care identifier in OIOXML and EDIFACT messages
 
 
 ## Discrepancy between FHIR and OIOXML/EDIFACT
-In FHIR messages all episode of care identifiers **MUST** be a UUID with a hyphen (-), as displayed in the example above. Due to a limitation in the OIOXML/EDIFACT messages all episode of care identifiers **MUST** be a UUID without a hyphen, hence only numbers and characters. 
+In FHIR messages all episode of care identifiers **SHALL** be a UUID with a hyphen (-), as displayed in the example above. Due to a limitation in the OIOXML/EDIFACT messages all episode of care identifiers **SHALL** be a UUID without a hyphen, hence only numbers and characters. 
 
 It is the systems responsibility to keep track of episode of care identifiers with and without hyphen.