Merge pull request #6 from medcomdk/1.0.3-rc1

Updated references, version of standards and requirements for resending.

docs/_config.yml

@@ -4,14 +4,12 @@ description: "Governance for MedCom HL7 FHIR®© Messaging is the basic ruleset
 show_downloads: false
 google_analytics:
 theme: jekyll-theme-minimal
-version: "Version 1.0.2"
+version: "Version 1.0.3"
 fhir_version: "FHIR®© R4"
 releasenote: https://github.com/medcomdk/MedCom-FHIR-Communication/releases
 thisurl: https://medcomdk.github.io/MedCom-FHIR-Communication/
 menuurl_item1: https://medcomdk.github.io/MedComLandingPage/
 menutxt_item1: MedCom FHIR®© LandingPage
 menuurl_item2: https://medcomdk.github.io/MedCom-FHIR-Communication/
 menutxt_item2: MedCom FHIR®©Governance
-menuurl_item3: https://medcomdk.github.io/MedCom-FHIR-Communication/#About
-menutxt_item3: About MedCom FHIR®© Governance
 # menutxt_item4: MedCom FHIR LandingPage 

docs/_layouts/default.html

@@ -169,6 +169,8 @@ <h3>Version of this documentation</h3>
       <hr/>
 
       <i>"FHIR® is the registered trademark of HL7 and is used with the permission of HL7. Use of the FHIR trademark does not constitute endorsement of this implementation guide by HL7, nor affirmation that this content is conformant to the various applicable standards" </i>
+      <p><br/></p>
+      <i><a href="https://www.was.digst.dk/medcomdk-github-io-MedComLandingPage-">Tilgængelighedserklæring</a></i>
       <!--/footer-->
 
     </div>

docs/assets/documents/043_Reliable_Messaging-FHIR.md

@@ -52,7 +52,7 @@ Any of these events can happen over time and therefore Reliable Messaging define
 - A Sending Ecosystem **MUST** send a MedCom Message with a flag indicating that it expects an acknowledgement on the MedCom Message
 - A Receiving Ecosystem **MUST** return an MedCom acknowledgement on a received MedCom Message with a flag indicating that it expects a MedCom acknowledgement on the MedCom Message
 - A Sending Ecosystem **MUST** be able to handle an unacknowledged MedCom Message
--- A Sending Ecosystem **MUST** resend the MedCom Message, when the expected MedCom acknowledgement is not received within a timelimit of 30 minutes
+-- A Sending Ecosystem **MAY** resend the MedCom Message, when the expected MedCom acknowledgement is not received within a timelimit of 30 minutes
 -- A Sending Ecosystem **MUST** change the MessageEnvelopeId and the MessageSentTime of a resend MedCom Message
 -- A Sending Ecosystem **MUST NOT** resend the MedCom Message more than 2 times, when the expected acknowledgement is not received
 - A Receiving Ecosystem **MUST** be able to receive a MedCom Message as a duplicate

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

@@ -5,3 +5,5 @@ All elements marked as MustSupport **SHALL** be presented or easily accessed on
 The message as a whole coherent object **SHALL** be present for easy access for the reader.
 
 The receiving application **SHALL** be able to show only relevant information for the different receiver roles in the receiving organization, eg. only persons in clinical roles **SHALL** be able to read clinical content
+
+All applications **MUST** be able to print relevant messages, due to Danish legislation. Previously, MedCom has tested this, but it is now up to the vendors to ensure they support this.

docs/assets/documents/090_Governance-for-concrete-standards.md

@@ -10,12 +10,12 @@ Each MedCom FHIR Message will potentially add some specific Governance Rules to
 
 ## 1 Acknowledgement
 
-[Click here to go to additional Governance for MedCom Acknowledgement.](/docs/assets/documents/governance-for-acknowledgement.md)
+[Click here to go to additional Governance for MedCom Acknowledgement.](/assets/documents/governance-for-acknowledgement.md)
 
 ## 2 CareCommunication
 
-[Click here to go to additional Governance for MedCom CareCommunication.](/docs/assets/documents/governance-for-careCommunication.md)
+[Click here to go to additional Governance for MedCom CareCommunication.](/assets/documents/governance-for-careCommunication.md)
 
 ## 3 HospitalNotification
 
-[Click here to go to additional Governance for MedCom HospitalNotification.](/docs/assets/documents/governance-for-hospitalNotification.md)
+[Click here to go to additional Governance for MedCom HospitalNotification.](/assets/documents/governance-for-hospitalNotification.md)

docs/assets/documents/FHIRMessages_NetworkEnvelopes_DA.md

@@ -75,7 +75,7 @@ Konkret betyder ovenstående for MedComs FHIR\-meddelelser dette
 |Kuvert  |VANSenvelope          |
 |Format  |"HL7"                 |
 |Name    |"MCM:FDIS91#`<code>`" |
-|Version |"2.0.0"               |
+|Version |"3.0.0"               |
 
 Postfixværdier for Name vil være indenfor dette code udfaldsrum, som er taget fra: <a href="https://medcomfhir.dk/ig/terminology/ValueSet-medcom-careCommunication-categories.html" target="_blank">CareCommunications ValueSet for categories</a>
 
@@ -89,7 +89,7 @@ Name kan eksplicit tages fra følgende Valueset: <a href="https://medcomfhir.dk/
 |Kuvert modtagelse |KOMBITs BeskedFordeler kuvert (EOJ)|
 |Format  |"HL7"                 |
 |Name    |"MCM:FDIS20#`<code>`" |
-|Version |"2.0.0"               |
+|Version |"3.0.0"               |
 
 Postfixværdier for Name vil være indenfor dette code udfaldsrum, som er taget fra HospitalNotifications ValueSet: <a href="https://medcomfhir.dk/ig/terminology/ValueSet-medcom-hospitalNotification-messageActivities.html" target="_blank">MedCom Hospital Notification Message Activity Codes</a>
 

docs/assets/documents/FHIRMessages_NetworkEnvelopes_EN.md

@@ -5,8 +5,8 @@
 * [2. Shipping envelopes](#2-shipping-envelopes)
     * [2.1 VANSEnvelope](#21-vansenvelope)
         * [2.1.1 Format](#211-format)
-        * [2.1.2](#212-name)
-        * [2.1.3](#213-version)
+        * [2.1.2 Name](#212-name)
+        * [2.1.3 Version](#213-version)
 * [3. MedCom FHIR message types](#3-medcom-fhir-message-types)
     * [3.1 CareCommunication](#31-carecommunication)
     * [3.2 HospitalNotification](#32-hospitalnotification)
@@ -76,7 +76,7 @@ Specifically, the above for MedCom's FHIR messages means this
 |**Envelope Receiver**  |VANSEnvelope                           |
 |**Format**             |"HL7"                                  |
 |**Name**               |"MCM:FDIS91#`<postfix value>`"         |
-|**Version**            |"2.0.0"                                |
+|**Version**            |"3.0.0"                                |
 
 Name **MUST** explicitly be taken from the following ValueSet:<a href="https://medcomfhir.dk/ig/terminology/CodeSystem-medcom-messaging-sorEdiSystem.html" target="_blank">CodeSystem-medcom-messaging-sorEdiSystem</a>
 
@@ -93,7 +93,7 @@ The combined Name+Postfix **MUST** explicitly conform with the following ValueSe
 |**Envelope Receiver**  |KOMBIT's BeskedFordeler Envelope (EOJ og andre kommunale systemer)  |
 |**Format**             |"HL7"                                   |
 |**Name**               |"MCM:FDIS20#`<postfix value>`"          |
-|**Version**            |"2.0.0"                                 |
+|**Version**            |"3.0.0"                                 |
 
 Name **MUST** explicitly be taken from the following ValueSet: <a href="https://medcomfhir.dk/ig/terminology/CodeSystem-medcom-messaging-sorEdiSystem.html" target="_blank">CodeSystem-medcom-messaging-sorEdiSystem</a>
 

docs/assets/documents/governance-for-acknowledgement.md

@@ -0,0 +1 @@
+[under development]

docs/assets/documents/governance-for-careCommunication.md

@@ -0,0 +1 @@
+[under development]

docs/assets/documents/governance-for-hospitalNotification.md

@@ -2,9 +2,9 @@
 
 * [1 Exchange of HospitalNotification message](#1-exchange-of-hospitalnotification-message)
   * [1.2 VANS-network and Municipality Message Publisher](#12-vans-network-and-municipality-message-publisher)
-    * [Type A](#type-a)
-    * [Type B](#type-b)
-    * [Type C](#type-c)
+    * [1.2.1 Type A](#121-type-a)
+    * [1.2.2 Type B](#122-type-b)
+    * [1.2.3 Type C](#123-type-c)
   * [1.3 Acknowledgements](#13-acknowledgements)
   * [1.4 Envelopes](#14-envelopes)
 * [2 HospitalNotification message](#2-hospitalnotification-message)
@@ -32,26 +32,18 @@ The flow of events and rules, when sending and receiving a HospitalNotification,
 |A Receiving EcoSystem **SHALL** wrap an Acknowledgement in a Beskedfordeler-envelope|
 |The Municipality Message Publisher **SHALL** unwrap an Acknowledgement in a Beskedfordeler-envelope|
 |The Municipality Message Publisher **SHALL** wrap an Acknowledgement in a VANS-envelope|
-|A Sending EcoSystem **SHALL** unwrap an Acknowledgement in a VANS-envelope|
+|A Sending EcoSystem **SHALL** unwrap a received Acknowledgement in a VANS-envelope|
 
 
-#### Type A
+#### 1.2.1 Type A
 A Type A system is, according to KOMBIT, a receiving system that shall receive and acknowledge. The acknowledgement of a Type A system is the basis for the Municipality Message Publisher to sent an Acknowledgement to the sending system. 
 
-(INSERT sequencediagram)
+#### 1.2.2 Type B
+A Type B system is according to KOMBIT a receiving system that shall receive and acknowledge. The acknowledgement of a Type B system isn't the basis for the Municipality Message Publisher to sent an Acknowledgement to the sending system. It will, though, be the basis of an internal root cause investigation.
 
-
-#### Type B
-A Type B system is according to KOMBIT a receiving system that shall receive and acknowledge. The acknowledgement of a Type B system isn't the basis for the Municipality Message Publisher to sent an Acknowledgement to the sending system.
-
-(INSERT sequencediagram)
-
-#### Type C
+#### 1.2.3 Type C
 A Type C system is according to KOMBIT a receiving system that is able to receive a HospitalNotification, but not to acknowledge it.
 
-(INSERT sequencediagram)
-
-
 ### 1.3 Acknowledgements
 
 All MedCom FHIR messages **SHALL** be acknowledged, which is also valid for a HospitalNotification message. To acknowledge a HospitalNotification message the [MedCom FHIR Acknowledgement](https://medcomdk.github.io/dk-medcom-acknowledgement/) standard **SHALL** be used.

docs/index.md

@@ -11,6 +11,7 @@
 * [4 MedCom FHIR Messages](#4-medcom-fhir-messages)
   + [4.1 Governance for MedCom FHIR Messages](#41-governance-for-medcom-fhir-messages)
   + [4.2 Governance for displaying MedCom FHIR Messages](#42-governance-for-displaying-medcom-fhir-messages)
+  + [4.3 Governance for EpisodeOfCare-identifier](#43-governance-for-episode-of-care-identifiers)
 * [5 Terminology](#5-terminology)
   + [5.1 Governance for MedCom FHIR Terminology](#51-governance-for-medcom-fhir-terminology)
   + [5.2 Governance for MedCom FHIR Terminology Server](#52-governance-for-medcom-fhir-terminology-server)
@@ -30,7 +31,7 @@ The Danish ruleset is based on:
 
 <br>
 
-These MedCom FHIR Messaging Governance rules are intended to clarify the use of MedCom’s FHIR messages for the health and social area. Formerly these kinds of rules for other MedCom Messaging paradigms were known as ”Syntax & Communication Rules”.
+These MedCom FHIR Messaging Governance rules are intended to clarify the use of MedCom’s FHIR messages for the health and social area. Formerly, these kinds of rules for other MedCom Messaging paradigms were known as ”Syntax & Communication Rules”.
 
 It is the intention that the MedCom FHIR Messaging Governance rules together with MedCom’s FHIR standards for the individual messages form the full and sufficient basis for implementing MedCom’s healthcare messages. Thus, the governance rules must be able to function as “a chief judge”, where there is doubt about the practical application of MedCom’s FHIR messages.
 
@@ -79,9 +80,7 @@ This convention is in compliance with HL7 FHIR use of the terms, which is descib
 
 ## 3 Message exchange
 
-MedCom FHIR Messaging is based on Asynchronous Messaging.
-
-In Asynchronous messaging, a Sending EcoSystem dispatches an unsolicited message to a Receiving EcoSystem possibly through several intermediate hubs. Besides sending a possibly requested acknowledgement immediately as a response, the Receiving EcoSystem responds to the Sending EcoSystem separately. The Receiving EcoSystem may respond more than once to any given message.
+MedCom FHIR Messaging is based on Asynchronous Messaging. In Asynchronous messaging, a Sending EcoSystem dispatches an unsolicited message to a Receiving EcoSystem possibly through several intermediate hubs. Besides sending a possibly requested acknowledgement immediately as a response, the Receiving EcoSystem responds to the Sending EcoSystem separately. The Receiving EcoSystem may respond more than once to any given message.
 
 When exchanging a MedCom FHIR message, it is allowed to send in a FHIR+JSON og FHIR+XML format, which is in alignment with HL7 FHIR. 
 
@@ -97,25 +96,25 @@ Governance for Network Layer covers rulesets for VANSEnvelope and Reliable Messa
 
 [Click here to go to Governance for Network Layer.](/assets/documents/030_Governance-for-Network-Layer.md)
 
-Reliable Messaging using VANSEnvelope describes different scenarios when using the VANSEnvelope. This is a profiling of the scenarios described in [Reliable Messaging in general.](/assets/documents/020_Governance-for-Reliable-Messaging-in-general.md) 
+Reliable Messaging using VANSEnvelope describes different scenarios when using the VANSEnvelope. This is a profiling of the scenarios described in [Reliable Messaging in general.](/assets/documents/020_Governance-for-Reliable-Messaging-in-general.md) mentioned in [section 3.1](#31-governance-for-reliable-messaging-in-general). 
 
-[Click here to see how to setup Reliable Messaging using VANSEnvelope](032_Reliable_Messaging-VANSEnvelope.md)
+[Click here to see how to setup Reliable Messaging using VANSEnvelope](/assets/documents/032_Reliable_Messaging-VANSEnvelope.md)
 
 ### 3.3 Governance for MedCom FHIR Message Exchange
 
 Governance for MedCom FHIR Messaging covers Reliable Messaging using MedCom FHIR Messaging, sending and receiving scenarios, and rulesets for FHIR Messaging and FHIR Messaging Acnowledgement.
 
 [Click here to go to Governance for MedCom FHIR Messaging.](/assets/documents/040_Governance4FHIR-Messaging.md)
 
-Reliable Messaging using MedCom FHIR Messaging describes different scenarios when using FHIR messages. This is a profiling of the scenarios described in [Reliable Messaging in general.](/assets/documents/020_Governance-for-Reliable-Messaging-in-general.md) 
+Reliable Messaging using MedCom FHIR Messaging describes different scenarios when using FHIR messages. This is a profiling of the scenarios described in [Reliable Messaging in general.](/assets/documents/020_Governance-for-Reliable-Messaging-in-general.md) mentioned in [section 3.1](#31-governance-for-reliable-messaging-in-general).
 
-[Click here to see how to apply Reliable Messaging using MedCom FHIR Messaging](043_Reliable_Messaging-VANSEnvelope.md)
+[Click here to see how to apply Reliable Messaging using MedCom FHIR Messaging](/assets/documents/043_Reliable_Messaging-VANSEnvelope.md)
 
 ## 4 MedCom FHIR Messages
 
-An implementer of a MedCom FHIR Message Standard **SHALL** be compliant with all parts of the documentation laid out for the MedCom FHIR Message Standard.
+An implementer of a MedCom FHIR Message Standard **SHALL** be compliant with all parts of the documentation laid out for the MedCom FHIR Messaging framework.
 
-You can find a description here:<a href="https://medcomdk.github.io/dk-medcom-messaging/assets/documents/Intro-Technical-Spec-ENG.html#21-medcommessagingmessage-bundle" target="_blank"> Click here to read the documentation for the MedCom FHIR Message Standard</a>
+You can find a description here:<a href="https://medcomdk.github.io/dk-medcom-messaging/assets/documents/Intro-Technical-Spec-ENG.html#21-medcommessagingmessage-bundle" target="_blank"> Click here to read the documentation for the MedCom FHIR Messaging framework</a>
 
 
 ### 4.1 Governance for MedCom FHIR Messages