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

Specification

Communication with Task

A patient request for correction is initiated by invoking the $correction-request operation. The input for the operation is a Patient Correction Bundle which includes a Patient Correction Communication resource that describes the specific request. The invocation of the operation on the fulfiller results in the posting of the Patient Correction Communication resource on the fulfiller. It is also expected to result in the creation of a Patient Correction Task resource which can be used to track the status of the request.

All Communications related to the correction request can be located by searching the about field for the original Communication.

The Communication recipient and sender fields are used to track whether each Communication is from the patient to the fulfiller, or vice versa.

RESTful interactions

Restful Correction Request ProcessCorrectionRequesterCorrectionRequesterRequestFulfillerRequestFulfillerSend a new Correction RequestInvoke $correction-request operation (Bundle) with a new CommunicationCreate Task using internal processingreturn Bundle with created Communication resourcewith pointer to new Task in Communication.aboutaltWhen more information is neededthen the Task status is updated anda new Communication is created that asks for the additional informationupdate Task status and create new Communicationpoll (query) for any changes to Task status and forany new Communication.altCorrespond with Fulfiller to respond to requestInvoke $correction-request operation (Bundle)When the request is fulfilled(agreed or rejected) thenthe Task status is updated anda new concluding Communication is created.update Task status and create new Communication with denial or accept/amendpoll (query) for any changes to Task status and for concluding Communication.

Linkages between resources

Certain fields in Task and Communication provide important linkage information.

Communication about will be empty for the initial Communication when the $correction-request operation is made to the server. Communication about for the initial Communication will then be populated with a reference to the correction Task when the Task for the request is spawned as result of the operation.

All subsequent Communication resources will point to the initial Communication resource for the correction request in their Communication about fields.

The Communication recipient and sender fields are used to track whether each Communication is from the patient to the fulfiller, or vice versa.

Task input points to the Communication that contains the initial request details, and Task output points to the Communication that contains the final results (amendment or denial details).

The Task reasonReference field is used to link a Log Disagreement Task to the related Correction Request Task.

The following diagrams show the Communication and Task linkages.

Amendment requested and accepted

amendment-requested-and-accepted.png

Amendment requested and rejected

amendment-requested-and-rejected.png

Logging a disagreement

logging-a-disagreement.png

Task Status

The Task.status and Task.businessStatus are used to convey the the state of the patient correction.

Task.status Task.businessStatus (Code) Task.businessStatus (Display) Task.businessStatus Definition
ready queued Queued A request to correct a record or log a disagreement has been received by the fulfiller (e.g. provider) but has not yet been reviewed.
in-progress in-review In Review Review is in progress.
in-progress waiting-for-information Waiting for Information The fulfiller (e.g. provider) is waiting for additional information.
cancelled requester-cancelled Cancelled The request has been cancelled by the requester (e.g. patient).
in-progress accepted Accepted Decision was made to accept the correction request.
in-progress partial-accept Partial Accept Part of the correction request was accepted, and part was denied.
completed amendment-completed Amendment Completed The record has been amended (corrected).
completed denied Denied The request has been denied.
completed disagreement-logged Disagreement Logged The fulfiller (e.g. provider) has logged the requester’s (e.g. patient’s) disagreement with the correction request denial.
completed inform-rebuttal-option Inform Rebuttal Option The fulfiller (e.g. provider) has logged the requester’s (e.g. patient’s) disagreement with the correction request denial, and provided a formal rebuttal.
completed partial-amendment-completed Partial Amendment Completed The record has been partially amended (corrected).

Task Status state machine

in_progresscompletein_reviewwaiting_for_informatione.g. Additional Information NeededacceptedDecision made to acceptpartial_acceptDecision made thatpart of request is acceptedand part is denied,disagreement can be loggedamendment_completeddeniedDecision made to deny,disagreement can be loggedpartial_amendment_completedreadyqueuedRequest receivedbut not reviewedcancelledrequester_cancelledRequester decided to cancelthe request for correctionTask.statusTask.businessStatusExternal post of Communication resourceInform requester onadditional time neededCommunication to informon rebuttal option

Please note that statuses shown containing underscores in these diagrams actually use hyphens instead. For example, “in_review” should be interpreted as “in-review”.

in_progresscompleteloggingin_reviewwaiting_for_informatione.g. Additional Information Neededpartial_acceptDecision made thatpart of request is acceptedand part is denied,disagreement can be loggeddeniedDecision made to deny,disagreement can be loggedpartial_amendment_completeddisagreement_loggedinform_rebuttal_optionreadyqueuedRequest receivedbut not reviewedTask.statusTask.businessStatusExternal post of Communication resourceInform requester onadditional time neededCommunication to informon rebuttal option

Must Support

Must Support on any profile data element SHALL be interpreted as follows:

  • content creators
    • SHALL be capable of populating all data elements marked Must Support.
    • when the Must Support element is known, it SHALL be populated.
  • content consumers
    • SHALL be capable of processing resource instances containing the Must Support data elements without generating an error or causing the application to fail.
    • SHALL interpret missing data elements within resource instances as data not present.
    • SHOULD be capable of displaying the data elements for human use or storing it for other purposes.

NOTE: The above definition of Must Support is derived from HL7v2 concept “Required but may be empty - RE” described in HL7v2 V28_CH02B_Conformance.doc. NOTE: Readers are advised to understand FHIR Terminology requirements, FHIR RESTful API based on the HTTP protocol, along with FHIR Data Types, FHIR Search and FHIR Resource formats before implementing US Core requirements.

Security

The Patient Request for Corrections workflow is a bidirectional communication between a patient (or their proxy) and a fulfiller. Proper authentication is critical so that the communication is not exploited by malicious actors resulting in exposure of patient data. All transactions in the Patient Request for Corrections workflow must be secured appropriately with access to limited authorized individuals, data protected in transit, and appropriate audit measures taken.

  • Implementers SHALL be aware of and conform to security guidance associated with FHIR transactions.
  • Systems SHOULD establish a risk analysis and management regime.
  • Systems SHALL reference a single time source to establish a common time base for security auditing, as well as clinical data records, among computing systems.
  • Systems SHALL keep audit logs of the various transactions.
  • Systems SHALL use TLS version 1.2 or higher for all transmissions not taking place over a secure network connection. (Using TLS even within a secured network environment is still encouraged to provide defense in depth.)
  • For Authentication and Authorization, systems SHOULD support the SMART App Launch Framework for client <-> server interactions. NOTE: The SMART on FHIR specifications include the required OAuth 2.0 scopes for enabling security decisions. In lieu of SMART on FHIR, an alternative framework for authentication and authorization SHOULD be followed (example, Security for Scalable Registration, Authentication, and Authorization which uses UDAP).
  • Systems MAY protect the confidentiality of data at rest via encryption and associated access controls. The policies and methods used are outside the scope of this specification.