| Name | Flags | Card. | Type |
Description & Constraints
|
|---|---|---|---|---|
Communication
|
Communication | |||
basedOn
|
.. 0 | |||
|
partOf
|
.. 0 | |||
inResponseTo
|
S | ..1 | Reference (Patient Correction Communication) | Patient Correction Request Communication that this is in response to. This will only be filled in if it represents a response to another Communication resource. It can be used to query and assemble conversation threads related to the request process. |
|
status
|
Fixed: completed. Required Pattern: completed |
|||
|
category
|
S | 1..1 | Binding: Patient Correction Communication Types Value Set ( required ) | |
|
subject
|
S | 1.. | Reference ( Patient ) | The Patient that the correction request or the log disagreement applies to. |
|
topic
|
S | A heading/subject line for the message being sent. Could be thought of as the subject line in an email thread. | ||
|
about
|
S | ..2 | Reference (Patient Correction Task | Patient Correction Communication) | If this is the original Patient Correction Request then Communication.about will initially be empty when posted by the Requester but populated with the Request for Correction Task reference by the Fulfiller when the Fulfiller spawn a Task to represent the Request for Correction or Logging of Disagreement process. For all subsequent Communication resources that represent conversations help between Requester and Fulfiller as part of the process, Communication.about references the Communication resource that contains the original request. If this Communication represents the start of a Log Disagreement request, then when the Fulfiller spawns a Task to support the logging of the disagreement, Communication.about will also reference the spawned Task. |
|
encounter
|
.. 0 | |||
|
sent
|
1.. | The date that this particular part of the conversation is sent. On the initial request from the Requestor for either correction or logging a disagreement, this date/time will be used as Task.authoredOn to signify when the process was initiated on the Fulfiller. | ||
|
recipient
|
S | 1..1 | Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService ) | Depending on the direction of the patient correction communication, the recipient of the communication may be the Fulfiller, or it may be the Requester. |
|
sender
|
S | 1.. | Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization | HealthcareService ) | Depending on the direction of the patient correction communication, the sender of the communication may be the Requester or it may be the Fulfiller. On the initial request for correction or logging of disagreement, the Fulfiller will use sender to represent the Task.requester. |
|
payload
|
S | The contents of this particular conversation component. If this is the original correction request or logging of a disagreement, then the payload would contain the request. If it is the final outcome of the request, then the payload would contain the final outcome information. Otherwise it contains a single message in back and forth conversation needed to process the initial request. Since it is possible to have a Communication resource reference a conversation held outside of the FHIR Rest protocol (email, mail, portal messaging – see Communication.channel) the minimum cardinality is zero. However, it is expected in most cases payload will be valued. | ||
note
|
Notes from those that are working on the correction about that work (this is not the correction request itself). | |||
|
Documentation for this format
|
||||