ZD Communication
Resources conforming to this profile are requested by ZorgDomein using a FHIR read request. The Communication resource is requested to obtain the body text of documents that are generated by the information system of the sender of the document. The resource ID that is used to do the read request is derived from the reference in the message slice on Task.input. See Send documents for more details.
The canonical URL for this profile is:
http://zorgdomein.nl/fhir/StructureDefinition/zd-communication
This profile builds on Communication.
| Communication | 0..* | Communication | Element IdCommunication A record of information transmitted from a sender to a receiver DefinitionAn occurrence of information being transmitted; e.g. an alert that was sent to a responsible provider, a public health agency was notified about a reportable condition.
| |
| identifier | Σ | 0..* | Identifier | Element IdCommunication.identifier Unique identifier DefinitionIdentifiers associated with this Communication that are defined by business processes and/ or used to refer to it when a direct URL reference to the resource itself is not appropriate (e.g. in CDA documents, or in written / printed documentation).
|
| definition | Σ | 0..* | Reference(PlanDefinition | ActivityDefinition) | Element IdCommunication.definition Instantiates protocol or definition DefinitionA protocol, guideline, or other definition that was adhered to in whole or in part by this communication event. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(PlanDefinition | ActivityDefinition) Constraints
|
| basedOn | Σ | 1..1 | Reference(ZD Task) | Element IdCommunication.basedOn Task resource that is used to communicate a specific task to ZorgDomein during SSO Alternate namesfulfills DefinitionAn order, proposal or plan fulfilled in whole or in part by this Communication. This must point to some sort of a 'Request' resource, such as CarePlan, CommunicationRequest, ReferralRequest, MedicationRequest, etc.
|
| reference | Σ | 1..1 | string | Element IdCommunication.basedOn.reference Literal reference, Relative, internal or absolute URL DefinitionA reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources. Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server.
|
| identifier | Σ | 0..1 | Identifier | Element IdCommunication.basedOn.identifier Logical reference, when literal reference is not known DefinitionAn identifier for the other resource. This is used when there is no way to reference the other resource directly, either because the entity is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference. When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it - see CapabilityStatement.rest.resource.referencePolicy. When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it.
|
| display | Σ | 0..1 | string | Element IdCommunication.basedOn.display Text alternative for the resource DefinitionPlain text narrative that identifies the resource in addition to the resource reference. This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.
|
| partOf | Σ | 0..* | Reference(Resource) | Element IdCommunication.partOf Part of this action Alternate namescontainer DefinitionPart of this action. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| status | Σ ?! | 1..1 | codeBinding | Element IdCommunication.status preparation | in-progress | suspended | aborted | completed | entered-in-error DefinitionThe status of the transmission. This element is labeled as a modifier because the status contains the codes aborted and entered-in-error that mark the communication as not currently valid.
|
| notDone | Σ ?! | 0..1 | boolean | Element IdCommunication.notDone Communication did not occur DefinitionIf true, indicates that the described communication event did not actually occur. Creating a Communication where notDone is true is intended for situations where there's a need for a specific statement in the record about something not being done. If the need is merely to indicate that a request wasn't fulfilled, that should be handled using Task. This element is labeled as a modifier because it marks the communication as a communication that did not occur. The more attributes are populated, the more constrained the negated statement is.
|
| notDoneReason | Σ | 0..1 | CodeableConcept | Element IdCommunication.notDoneReason Why communication did not occur DefinitionDescribes why the communication event did not occur in coded and/or textual form. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. CommunicationNotDoneReason (example) Constraints
|
| category | 0..* | CodeableConcept | Element IdCommunication.category Message category DefinitionThe type of message conveyed such as alert, notification, reminder, instruction, etc. There may be multiple axes of categorization and one communication may serve multiple purposes. CommunicationCategory (example) Constraints
| |
| medium | 0..* | CodeableConcept | Element IdCommunication.medium A channel of communication DefinitionA channel that was used for this communication (e.g. email, fax). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. v3 Code System ParticipationMode (example) Constraints
| |
| subject | Σ | 0..1 | Reference(Patient | Group) | Element IdCommunication.subject Focus of message Alternate namespatient DefinitionThe patient or group that was the focus of this communication. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| recipient | 0..* | Reference(Device | Organization | Patient | Practitioner | RelatedPerson | Group) | Element IdCommunication.recipient Message recipient DefinitionThe entity (e.g. person, organization, clinical information system, or device) which was the target of the communication. If receipts need to be tracked by individual, a separate resource instance will need to be created for each recipient. Multiple recipient communications are intended where either a receipt(s) is not tracked (e.g. a mass mail-out) or is captured in aggregate (all emails confirmed received by a particular time). References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Device | Organization | Patient | Practitioner | RelatedPerson | Group) Constraints
| |
| topic | 0..* | Reference(Resource) | Element IdCommunication.topic Focal resources DefinitionThe resources which were responsible for or related to producing this communication. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
| |
| context | Σ | 0..1 | Reference(Encounter | EpisodeOfCare) | Element IdCommunication.context Encounter or episode leading to message Alternate namesencounter DefinitionThe encounter within which the communication was sent. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Encounter | EpisodeOfCare) Constraints
|
| sent | 0..1 | dateTime | Element IdCommunication.sent When sent DefinitionThe time when this communication was sent.
| |
| received | 0..1 | dateTime | Element IdCommunication.received When received DefinitionThe time when this communication arrived at the destination.
| |
| sender | 0..1 | Reference(Device | Organization | Patient | Practitioner | RelatedPerson) | Element IdCommunication.sender Message sender DefinitionThe entity (e.g. person, organization, clinical information system, or device) which was the source of the communication. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Device | Organization | Patient | Practitioner | RelatedPerson) Constraints
| |
| reasonCode | Σ | 0..* | CodeableConcept | Element IdCommunication.reasonCode Indication for message DefinitionThe reason or justification for the communication. Textual reasons can be caprued using reasonCode.text. SNOMED CT Clinical Findings (example) Constraints
|
| reasonReference | Σ | 0..* | Reference(Condition | Observation) | Element IdCommunication.reasonReference Why was communication done? DefinitionIndicates another resource whose existence justifies this communication. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Condition | Observation) Constraints
|
| payload | 1..1 | BackboneElement | Element IdCommunication.payload Body text of the message or document DefinitionText, attachment(s), or resource(s) that was communicated to the recipient.
| |
| contentString | 1..1 | string | Element IdCommunication.payload.content[x]:contentString Message part content DefinitionA communicated content (or for multi-part communications, one portion of the communication). Note that FHIR strings may not exceed 1MB in size
| |
| note | 0..* | Annotation | Element IdCommunication.note Comments made about the communication DefinitionAdditional notes or commentary about the communication by the sender, receiver or other interested parties. For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. Annotations SHOULD NOT be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).
|
See the profile on simplifier.net for additional details.
Example resource
Below you find an example of a resource that conforms to the ZD Communication profile.
{
"resourceType": "Communication",
"meta": {
"profile": [
"http://zorgdomein.nl/fhir/StructureDefinition/zd-communication"
]
},
"basedOn": [
{
"reference": "Task/1864"
}
],
"status": "in-progress",
"subject": {
"reference": "Patient/1"
},
"payload": [
{
"contentString": "Geachte heer I.O. Huisarts, \n\nQuisque vel felis facilisis, rhoncus dolor in, tempor lacus. Vestibulum at elementum orci. Vivamus fringilla vestibulum pretium. Quisque auctor, lectus id molestie ullamcorper, quam elit fermentum arcu, sit amet pulvinar sem nunc et nisl. Curabitur sed mauris tempus, vulputate urna ac, feugiat sapien. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Quisque sed mauris eget nibh condimentum semper nec vel mauris. \n\nMet vriendelijke groet, \n\nDhr. I.O. Fysio Breukelen"
}
]
}
<Communication xmlns='http://hl7.org/fhir'>
<meta>
<profile value='http://zorgdomein.nl/fhir/StructureDefinition/zd-communication'/>
</meta>
<basedOn>
<reference value='Task/1864'/>
</basedOn>
<status value='in-progress'/>
<subject>
<reference value='Patient/1'/>
</subject>
<payload>
<contentString value='Geachte heer I.O. Huisarts,
Quisque vel felis facilisis, rhoncus dolor in, tempor lacus. Vestibulum at elementum orci. Vivamus fringilla vestibulum pretium. Quisque auctor, lectus id molestie ullamcorper, quam elit fermentum arcu, sit amet pulvinar sem nunc et nisl. Curabitur sed mauris tempus, vulputate urna ac, feugiat sapien. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Quisque sed mauris eget nibh condimentum semper nec vel mauris.
Met vriendelijke groet,
Dhr. I.O. Fysio Breukelen'/>
</payload>
</Communication>