This is the profile for the Patient Correction Communication, which is used for back and forth conversation about a patient’s request for correction to their medical record. Each Patient Correction Communication resource instance represents a message in the bidirectional conversation needed to complete a patient’s request for correction to their medical record or for logging their disagreement to a correction denial. This profile sets minimum expectations for the Communication resource to support this workflow. It is expected to be used in conjunction with the Patient Correction Task profile.

Mandatory and Must Support data elements

The following data-elements must always be present (Mandatory) definition]) or must be supported if the data is present (Must Support) definition). They are presented below in a simple human-readable explanation. Profile specific guidance is provided as well. The Formal Profile Definition below provides the formal summary, definitions, and terminology requirements. Refer to the Examples section of the guide for example resources provided in the context of an example workflow.

Each implementation of PatientCorrectionCommunication must provide:

1. id: An id
2. status: fixed to “completed”
3. category: indicates whether it’s a “Request for Correction” or “Log Disagreement” process
4. subject: the person whose record is to be corrected
5. sender: who is sending this communication
6. recipient: who is receiving this communication
7. sent: date/time communication was sent
8. about: When the initial Communication request for correction resource is created by the Requester, Communication.about will be empty. When the Fulfiller spawns a Task to support the request, the Fulfiller sets Communication.about to reference the spawned Task that represents the entire request for correction or log disagreement process. On all other Communication resources, Communication.about references the Communication resource that contained the initial request. When a Log Disagreement Task is created, the Fulfiller will update the Communication containing the Log Disagreement request such that Communication.about references the Log Disagreement Task as well as the original correction request Communication.
9. topic: a heading/subject line for the message being sent. Could be thought of as the subject line in an email thread.
10. inResponseTo: points to the prior Communication resource in a conversation thread.
11. Payload: contains the actual message being communicated, including any attachments or references.

Profile-specific implementation guidance

• If the Communication resource represents the start of a Request for Correction or Log Disagreement process, Communication.about will reference the Task representing the overall associated Fulfiller process. On the start of a Log Disagreement, Communication.about will also reference the Communication resource of the initial correction request that is being disagreed with.
• Additional Communication resources are created to represent each component of the back and forth conversation between the Requester and Fulfiller. The sender and recipient is set appropriately based on the direction of the conversation. All Communication resources are stored and queryable on the Fulfiller.
• The Communication resources associated with a request for correction or log disagreement can be assembled into a conversation by first referring to the Communication of the original request, and then finding any Communication resources that reference it in the about field. If there are any threads of conversation, these are connected via Communication.inResponseTo.

• Text Summary
• Differential Table
• Snapshot Table
• Snapshot Table (Must Support)
• All

This structure is derived from Communication

Name	Flags	Card.	Type	Description & Constraints
Communication		0..*	Communication	A record of information transmitted from a sender to a receiver
basedOn		0..0
partOf		0..0
inResponseTo	S	0..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		1..1	code	Fixed: completed. Required Pattern: completed
category	S	1..1	CodeableConcept	Message category Binding: PatientCorrectionCommunicationTypesVS (required)
subject	S	1..1	Reference(Patient)	The Patient that the correction request or the log disagreement applies to.
topic	S	0..1	CodeableConcept	A heading/subject line for the message being sent. Could be thought of as the subject line in an email thread.
about	S	0..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..0
sent		1..1	dateTime	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..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	0..*	BackboneElement	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		0..*	Annotation	Notes from those that are working on the correction about that work (this is not the correction request itself).
Documentation for this format

Name	Flags	Card.	Type	Description & Constraints
Communication		0..*	Communication	A record of information transmitted from a sender to a receiver
id	Σ	0..1	string	Logical id of this artifact
meta	Σ	0..1	Meta	Metadata about the resource
implicitRules	?!Σ	0..1	uri	A set of rules under which this content was created
language		0..1	code	Language of the resource content Binding: CommonLanguages (preferred) Max Binding: AllLanguages: A human language.
text		0..1	Narrative	Text summary of the resource, for human interpretation
contained		0..*	Resource	Contained, inline Resources
extension		0..*	Extension	Additional content defined by implementations
modifierExtension	?!	0..*	Extension	Extensions that cannot be ignored
identifier	Σ	0..*	Identifier	Unique identifier
instantiatesCanonical	Σ	0..*	canonical(PlanDefinition | ActivityDefinition | Measure | OperationDefinition | Questionnaire)	Instantiates FHIR protocol or definition
instantiatesUri	Σ	0..*	uri	Instantiates external protocol or definition
inResponseTo	S	0..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	?!Σ	1..1	code	Fixed: completed. Binding: EventStatus (required): The status of the communication. Required Pattern: completed
statusReason	Σ	0..1	CodeableConcept	Reason for current status Binding: CommunicationNotDoneReason (example): Codes for the reason why a communication did not happen.
category	S	1..1	CodeableConcept	Message category Binding: PatientCorrectionCommunicationTypesVS (required)
priority	Σ	0..1	code	routine | urgent | asap | stat Binding: RequestPriority (required): Codes indicating the relative importance of a communication.
medium		0..*	CodeableConcept	A channel of communication Binding: ParticipationMode (example): Codes for communication mediums such as phone, fax, email, in person, etc.
subject	SΣ	1..1	Reference(Patient)	The Patient that the correction request or the log disagreement applies to.
topic	S	0..1	CodeableConcept	A heading/subject line for the message being sent. Could be thought of as the subject line in an email thread. Binding: CommunicationTopic (example): Codes describing the purpose or content of the communication.
about	S	0..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.
sent		1..1	dateTime	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.
received		0..1	dateTime	When received
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..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.
reasonCode	Σ	0..*	CodeableConcept	Indication for message Binding: SNOMEDCTClinicalFindings (example): Codes for describing reasons for the occurrence of a communication.
reasonReference	Σ	0..*	Reference(Condition | Observation | DiagnosticReport | DocumentReference)	Why was communication done?
payload	S	0..*	BackboneElement	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.
id		0..1	string	Unique id for inter-element referencing
extension		0..*	Extension	Additional content defined by implementations
modifierExtension	?!Σ	0..*	Extension	Extensions that cannot be ignored even if unrecognized
content[x]		1..1		Message part content
contentString			string
contentAttachment			Attachment
contentReference			Reference(Resource)
note		0..*	Annotation	Notes from those that are working on the correction about that work (this is not the correction request itself).
Documentation for this format

Name	Flags	Card.	Type	Description & Constraints
Communication		0..*	Communication	A record of information transmitted from a sender to a receiver
inResponseTo		0..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.
category		1..1	CodeableConcept	Message category Binding: PatientCorrectionCommunicationTypesVS (required)
subject	Σ	1..1	Reference(Patient)	The Patient that the correction request or the log disagreement applies to.
topic		0..1	CodeableConcept	A heading/subject line for the message being sent. Could be thought of as the subject line in an email thread. Binding: CommunicationTopic (example): Codes describing the purpose or content of the communication.
about		0..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.
recipient		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		1..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		0..*	BackboneElement	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.
Documentation for this format

This structure is derived from Communication

Summary

Mandatory: 5 elements
Must-Support: 8 elements
Prohibited: 3 elements

Structures

This structure refers to these other structures:

• Patient Correction Communication (http://hl7.org/fhir/uv/patient-corrections/StructureDefinition/patient-correction-communication)
• Patient Correction Task (http://hl7.org/fhir/uv/patient-corrections/StructureDefinition/patient-correction-task)

Differential View

This structure is derived from Communication

Name	Flags	Card.	Type	Description & Constraints
Communication		0..*	Communication	A record of information transmitted from a sender to a receiver
basedOn		0..0
partOf		0..0
inResponseTo	S	0..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		1..1	code	Fixed: completed. Required Pattern: completed
category	S	1..1	CodeableConcept	Message category Binding: PatientCorrectionCommunicationTypesVS (required)
subject	S	1..1	Reference(Patient)	The Patient that the correction request or the log disagreement applies to.
topic	S	0..1	CodeableConcept	A heading/subject line for the message being sent. Could be thought of as the subject line in an email thread.
about	S	0..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..0
sent		1..1	dateTime	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..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	0..*	BackboneElement	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		0..*	Annotation	Notes from those that are working on the correction about that work (this is not the correction request itself).
Documentation for this format

Snapshot View

Name	Flags	Card.	Type	Description & Constraints
Communication		0..*	Communication	A record of information transmitted from a sender to a receiver
id	Σ	0..1	string	Logical id of this artifact
meta	Σ	0..1	Meta	Metadata about the resource
implicitRules	?!Σ	0..1	uri	A set of rules under which this content was created
language		0..1	code	Language of the resource content Binding: CommonLanguages (preferred) Max Binding: AllLanguages: A human language.
text		0..1	Narrative	Text summary of the resource, for human interpretation
contained		0..*	Resource	Contained, inline Resources
extension		0..*	Extension	Additional content defined by implementations
modifierExtension	?!	0..*	Extension	Extensions that cannot be ignored
identifier	Σ	0..*	Identifier	Unique identifier
instantiatesCanonical	Σ	0..*	canonical(PlanDefinition | ActivityDefinition | Measure | OperationDefinition | Questionnaire)	Instantiates FHIR protocol or definition
instantiatesUri	Σ	0..*	uri	Instantiates external protocol or definition
inResponseTo	S	0..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	?!Σ	1..1	code	Fixed: completed. Binding: EventStatus (required): The status of the communication. Required Pattern: completed
statusReason	Σ	0..1	CodeableConcept	Reason for current status Binding: CommunicationNotDoneReason (example): Codes for the reason why a communication did not happen.
category	S	1..1	CodeableConcept	Message category Binding: PatientCorrectionCommunicationTypesVS (required)
priority	Σ	0..1	code	routine | urgent | asap | stat Binding: RequestPriority (required): Codes indicating the relative importance of a communication.
medium		0..*	CodeableConcept	A channel of communication Binding: ParticipationMode (example): Codes for communication mediums such as phone, fax, email, in person, etc.
subject	SΣ	1..1	Reference(Patient)	The Patient that the correction request or the log disagreement applies to.
topic	S	0..1	CodeableConcept	A heading/subject line for the message being sent. Could be thought of as the subject line in an email thread. Binding: CommunicationTopic (example): Codes describing the purpose or content of the communication.
about	S	0..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.
sent		1..1	dateTime	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.
received		0..1	dateTime	When received
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..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.
reasonCode	Σ	0..*	CodeableConcept	Indication for message Binding: SNOMEDCTClinicalFindings (example): Codes for describing reasons for the occurrence of a communication.
reasonReference	Σ	0..*	Reference(Condition | Observation | DiagnosticReport | DocumentReference)	Why was communication done?
payload	S	0..*	BackboneElement	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.
id		0..1	string	Unique id for inter-element referencing
extension		0..*	Extension	Additional content defined by implementations
modifierExtension	?!Σ	0..*	Extension	Extensions that cannot be ignored even if unrecognized
content[x]		1..1		Message part content
contentString			string
contentAttachment			Attachment
contentReference			Reference(Resource)
note		0..*	Annotation	Notes from those that are working on the correction about that work (this is not the correction request itself).
Documentation for this format