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

This page is part of the Patient Request for Corrections Implementation Guide (v1.0.0: STU1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Specification

Page standards status: Informative

There is an ongoing discussion about the minimum requirements for proper support of corrections. Specifically, the infrastructure around the Task resource provides tracking and state information to users that is useful (and necessary for enabling and supporting automation and for managing more complex cases) though may not align with legacy, paper documentation-based, facility processes for applying corrections. Implementer feedback is requested.
Some implementers believe that a more streamlined approach that starts directly with the creation of a Task and without requiring a Communication resource should be considered for the next release.

Communication with Task

A patient request for correction is initiated by the CorrectionRequester by invoking the $correction-request operation on the RequestFulfiller. 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 RequestFulfiller MAY 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.

Some implementations might choose not to create a Task. In that case, there is no explicit status tracking, only messaging back and forth between requester and fulfiller using the Communication resource.

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.
Sequence diagram showing the workflow of a corrections request

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 requestor 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_progresscompleteTaskin_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_completedstatusbusinessStatusreadyqueuedRequest receivedbut not reviewedcancelledrequester_cancelledRequester decided to cancelthe request for correctionExternal 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_progresscompleteloggingTaskin_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_optionstatusbusinessStatusreadyqueuedRequest receivedbut not reviewedExternal 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 requestor (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 (for example, HL7 FAST UDAP Security for Scalable Registration, Authentication, and Authorization).
  • 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.