Patient Request for Corrections Implementation Guide
1.0.0 - STU 1 Ballot International flag

Patient Request for Corrections Implementation Guide, published by HL7 International - Patient Empowerment Workgroup. This is not an authorized publication; it is the continuous build for version 1.0.0). This version is based on the current content of https://github.com/HL7/fhir-patient-correction/ and changes regularly. See the Directory of published versions

Resource Profile: PatientCorrectionCommunication - Detailed Descriptions

Draft as of 2023-09-11

Definitions for the patient-correction-communication resource profile.

Guidance on how to interpret the contents of this table can be found here

0. Communication
2. Communication.partOf
Definition

The initial communication sent by a Requester for a record correction.

ShortInitial Patient Correction Communication resource for this request.
Comments

When creating an initial correct request, this element SHALL be empty. Subsequent communications in either direction (to or from the patient) SHALL populate this element with a reference to the original communication requesting a correction.

Control0..1
TypeReference(Patient Correction Communication)
Must Supporttrue
4. Communication.inResponseTo
Comments

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.

Control0..1
TypeReference(Patient Correction Communication)
Must Supporttrue
6. Communication.status
ShortFixed: completed.
Pattern Valuecompleted
8. Communication.category
Control1..1
BindingThe codes SHALL be taken from Patient Correction Communication Types Value Set
Must Supporttrue
10. Communication.subject
ShortThe Patient that the correction request or the log disagreement applies to.
Control1..?
TypeReference(Patient)
Must Supporttrue
12. Communication.topic
ShortA heading/subject line for the message being sent.
Comments

Equivalent to the subject line in an email thread.

Must Supporttrue
14. Communication.about
SlicingThis element introduces a set of slices on Communication.about. The slices are unordered and Open, and can be differentiated using the following discriminators: , and can be differentiated using the following discriminators:
  • type @ reference
16. Communication.about:correctionTask
Slice NamecorrectionTask
Definition

A server-created Correction Task for servicing this correction request.

ShortPatient Correction Task requesting a correction.
Comments

When creating an initial correction request, this element SHALL be empty. If a processing system creates a Task resource related to a correction request, the server SHALL add a reference to that Task here. Any subsequent communication requests regarding the same correction request SHALL reference the relevant Task if present.

Control0..1
TypeReference(Patient Correction Task)
Must Supporttrue
18. Communication.sent
ShortWhen this communication was sent
Comments

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.

Control1..?
20. Communication.recipient
ShortMessage recipient: either a Requestor or a Fulfiller
Comments

Depending on the direction of the patient correction communication, the recipient of the communication may be the Fulfiller or it may be the Requester.

Control1..?
TypeReference(Patient, RelatedPerson, Practitioner, PractitionerRole, Organization, CareTeam, HealthcareService)
Must Supporttrue
Must Support TypesNo must-support rules about the choice of types/profiles
22. Communication.sender
ShortMessage sender: either a Requestor or a Fulfiller
Comments

Depending on the direction of the patient correction communication, the sender of the communication may be the Requester or it may be the Fulfiller. If spawning a Task relating to an initial request (for either correction or logging of disagreement), the Fulfiller SHALL use this sender to represent the Task.requester.

Control1..?
TypeReference(Patient, RelatedPerson, Practitioner, PractitionerRole, Organization, HealthcareService)
Must Supporttrue
Must Support TypesNo must-support rules about the choice of types/profiles
24. Communication.payload
ShortContents of this communication.
Comments

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.

Must Supporttrue
26. Communication.note
ShortNon-actionable notes about this communication.
Comments

If there is NOT a Task created to work on a correction request, this element MAY contain notes from those that are working on a correction. Notes from Requestors SHOULD be placed into additional communications, so that Fulfillers review them. This element SHALL NOT contain actionable requests from either Requestors or Fulfillers.