Union of http://hl7.org/fhir/uv/patient-corrections/StructureDefinition/patient-correction-communication and http://hl7.org/fhir/uv/patient-corrections/StructureDefinition/patient-correction-communication

This is the set of resources that conform to either of the profiles Patient Correction Communication (http://hl7.org/fhir/uv/patient-corrections/StructureDefinition/patient-correction-communication) and Patient Correction Communication (http://hl7.org/fhir/uv/patient-corrections/StructureDefinition/patient-correction-communication). E.g. what you have to deal with if you get resources conforming to one of them

Structure

NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
.. Communication 0..*A record of information transmitted from a sender to a receiver
... meta Σ0..1MetaMetadata about the resource
... implicitRules ?!Σ0..1uriA set of rules under which this content was created
... language 0..1codeLanguage of the resource content
Binding: ?? (preferred): A human language.
... text 0..1NarrativeText summary of the resource, for human interpretation
This profile does not constrain the narrative in regard to content, language, or traceability to data elements
... contained 0..*ResourceContained, inline Resources
... extension 0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
... identifier Σ0..*IdentifierUnique identifier
... instantiatesCanonical Σ0..*canonical(PlanDefinition | ActivityDefinition | Measure | OperationDefinition | Questionnaire)Instantiates FHIR protocol or definition
... instantiatesUri Σ0..*uriInstantiates external protocol or definition
... basedOn Σ0..*Reference(Resource)Request fulfilled by this communication
... partOf SΣ0..1Reference(Resource)left: Part of this action; right: Initial Patient Correction Communication resource for this request.
... inResponseTo S0..1Reference(Patient Correction Communication), Reference(Patient Correction Communication)left: 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.; right: Reply to
... status ?!Σ1..1codeFixed: completed.
Binding: ?? (required): The status of the communication.
... statusReason Σ0..1CodeableConceptReason for current status
Binding: ?? (example): Codes for the reason why a communication did not happen.
... category S1..1CodeableConceptMessage category
Binding: ?? (required)
... priority Σ0..1coderoutine | urgent | asap | stat
Binding: ?? (required): Codes indicating the relative importance of a communication.
... medium 0..*CodeableConceptA channel of communication
Binding: ?? (example): Codes for communication mediums such as phone, fax, email, in person, etc.
... subject SΣ1..1Reference(Patient)The Patient that the correction request or the log disagreement applies to.
... topic S0..1CodeableConceptleft: A heading/subject line for the message being sent. Could be thought of as the subject line in an email thread.; right: A heading/subject line for the message being sent.
Binding: ?? (example): Codes describing the purpose or content of the communication.
... about S0..*Reference(Resource)left: 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.; right: Resources that pertain to this communication
... encounter Σ0..1Reference(Encounter)Encounter created as part of
... sent 1..1dateTimeleft: 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.; right: When this communication was sent
... received 0..1dateTimeWhen received
... recipient S1..*Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService)left: Depending on the direction of the patient correction communication, the recipient of the communication may be the Fulfiller, or it may be the Requester.; right: Message recipient: either a Requestor or a Fulfiller
... sender S1..1Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization | HealthcareService)left: 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.; right: Message sender: either a Requestor or a Fulfiller
... reasonCode Σ0..*CodeableConceptIndication for message
Binding: ?? (example): Codes for describing reasons for the occurrence of a communication.
... reasonReference Σ0..*Reference(Condition | Observation | DiagnosticReport | DocumentReference)Why was communication done?
... payload S0..*BackboneElementleft: 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.; right: Contents of this communication.
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... content[x] 1..1Message part content
..... contentStringstring
..... contentAttachmentAttachment
..... contentReferenceReference(Resource)
... note 0..*Annotationleft: Notes from those that are working on the correction about that work (this is not the correction request itself).; right: Non-actionable notes about this communication.

doco Documentation for this format