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/governance-for-careCommunication.md

@@ -50,7 +50,7 @@ It is a requirement that a system can send a reply to an already received CareCo
 |Rule name|Rules to contrain the use of reply CareCommunications|
 |:---|:---|
 |medcom-carecommunication-3 | User of a sender system **SHALL** be able to reply to a new CareCommunication or the latest received reply or forwarded CareCommunication. In these cases, the communication identifier **SHALL** remain the same in the reply. |
-|medcom-carecommunication-4 | User of a sender system SHOULD be able to reply to the latest message when the latest message is sent from the sender system itself. |
+|medcom-carecommunication-4 | User of a sender system **SHOULD** be able to reply to the latest message when the latest message is sent from the sender system itself. |
 |medcom-carecommunication-5 | User of the sender system **SHALL** NOT be able to reply to messages which isn't the latest. If this is necesary, a new message thread with a unique communication identifier **SHALL** be created. |
 |medcom-carecommunication-6 | When replying to a CareCommunication that already includes an attachment, the base64-encoded content **SHALL** NOT be included, but the identifier, timestamp and title **SHALL** be included, and author information **SHALL** be included if available. |
 
@@ -63,7 +63,7 @@ It is a requirement that a system can send a reply to an already received CareCo
 |medcom-carecommunication-8 | In cases where a CareCommunication does not arrive and an unknown message segment is afterwards included in a received CareCommunication, the unknown message segment **SHALL** be displayed to the user in the associated message thread. The messages **SHALL** be ordered by the timestamp from the message segment. It **SHALL** be clear to the user that an unread message is received.|
 |medcom-carecommunication-9 | In cases where a CareCommunication arrives in unexpected order the received messages **SHALL** be displayed to the user in the associated message thread, ordered by the timestamp from the message segment. When a delayed CareCommunication appears, it **SHALL** be displayed in the same message thread. It **SHALL** be clear to the user that an unread message is received. |
 |medcom-carecommunication-10 | In cases where a reply is received with an unknown communication identifier, the message segment(s) **SHALL** be displayed to the user in a new message thread.|
-|medcom-carecommunication-11 | When two systems, at the same time, sends a reply to the same CareCommunication with the same communication identifier, both systems **SHALL** be able to handle receiving a reply which is not the latest reply in the message thread in the system. This is managed by including the received CareCommunication in the message thread with the same communication identifier. The flow for parallel sent CareCommunications is illustrated on <a href="#Fig2">Figure 2</a>. It **SHALL** be clear to the user that an unread message is received and which message it is a reply to. If the time stamps in the message segments are different, the messages **SHALL** be ordered by these and if they are identical the message segments **SHALL** be ordered by the sender of the messages. The message sent by the initiator of the communication **SHALL** appear as the first, followed by the message send by the replier.|
+|medcom-carecommunication-11 | When two systems, at the same time, sends a reply to the same CareCommunication with the same communication identifier, both systems **SHALL** be able to handle receiving a reply which is not the latest reply in the message thread in the system. This is managed by including the received CareCommunication in the message thread with the same communication identifier. The flow for parallel sent CareCommunications is illustrated on <a href="#Fig2">Figure 2</a>. It **SHALL** be clear to the user that an unread message is received and which message it is a reply to. If the time stamps in the message segments with the message text are different, the messages **SHALL** be ordered by these and if they are identical the message segments **SHALL** be ordered by the sender of the messages. The message sent by the initiator of the communication **SHALL** appear as the first, followed by the message send by the replier. In both case no other changes must be applied to the message segment or Provenance instances.|
 |medcom-carecommunication-12 | The user **SHALL** be able to continue the communication in the message thread after the flow of messages received in 8, 9, 10, and 11.|
 
 > Note: For the scenarios (8, 9 and 10) the handling in the receiver system is the same: A) create a new message thread if the communication identifier is unknown or if known, include the message in the message thread with an identical communication identifier, B) order the messages based on the time stamp in the message segment, and C) make it clear to the user that an unread message is received.
@@ -89,8 +89,8 @@ It is optional for the system to support forwarding of a CareCommunication; howe
 
 |Rule name|Rules to contrain the use of forwarding CareCommunications|
 |:---|:---|
-|medcom-carecommunication-13 | User of sender system SHOULD be able to forward all CareCommunication in a message thread, as illustrated in <a href="#Fig3">Figure 3</a>. In this case, the forwarding **SHALL** include all previous message segments and the sender system **SHALL** create a new message thread with a new, unique communication identifier.|
-|medcom-carecommunication-14 | User of sender system SHOULD be able to forward the latest sent or received CareCommunication or a previously sent or received CareCommunication. If the user forwards and choose specific parts of the message, only the selected CareCommunication **SHALL** be included. |
+|medcom-carecommunication-13 | User of sender system **SHOULD** be able to forward all CareCommunication in a message thread, as illustrated in <a href="#Fig3">Figure 3</a>. In this case, the forwarding **SHALL** include all previous message segments and the sender system **SHALL** create a new message thread with a new, unique communication identifier.|
+|medcom-carecommunication-14 | User of sender system **SHOULD** be able to forward the latest sent or received CareCommunication or a previously sent or received CareCommunication. If the user forwards and choose specific parts of the message, only the selected parts **SHALL** be included, meaning the associated message segment(s) and Provenances. It is not allowed only to removed attachment, as this will cause the references to the payload in the Provenance to be incorrect.|
 |medcom-carecommunication-15 | After forwarding a CareCommunication, the user **SHALL** be able to continue the communication in the original message thread.|
 
 **Receiver system**<br>