This page is part of the Patient Request for Corrections Implementation Guide (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

Actors and Use Cases

Actors

Actor	Description
CorrectionRequester	The CorrectionRequester represents a patient’s application, such as a personal health record. A patient or their caregiver uses the application to request a correction to their medical record.
RequestFulfiller	The RequestFulfiller represents a provider system – usually an EHR. A Medical Records professional or clinician uses the provider system to review and process the correction request. The RequestFulfiller could also represent a payer system.

General Actor Sequence

Use cases

NOTE: The following list of use cases represent common use cases but is not an exhaustive list. These use cases are designed to follow the HIPAA Request for Amendment workflow.

Use Case 1: Patient Requests a Correction to Their Medical Record Which is Accepted and Corrected.

A patient reviews the records received from a provider (most likely this review is of the electronic health information accessed on their personal health record application). The patient determines that it contains one or more errors or discrepancies. The patient enters a correction request using their application. The request can be a simple unstructured request, but can also contain additional structured information to provide context or to pinpoint the error and the fix. The application (CorrectionRequester) sends the correction request to the appropriate provider system (RequestFulfiller). The provider (most likely a medical records professional but possibly a clinician) reviews the request on the provider system (EHR). If needed, the provider reaches out to the patient to further clarify the request and consults as needed with clinicians to determine if a correction is appropriate. The request for correction is accepted. The appropriate personnel corrects the chart (or charts if the error involves multiple charts) and creates formal amendments to the electronic health record. The correction request is marked complete. If the patient has requested that other parties be notified, notifications of the amendment are sent out accordingly. Meanwhile, the patient has been able to use their application to check for the status of their correction request and is able to determine that it was being reviewed, then was accepted, and later completed.

Use Case 2: Patient Requests a Correction to Their Medical Record Which is Denied.

A patient reviews the records received from a provider (most likely this review is of the electronic health information accessed on their personal health record application). The patient determines that it contains one or more errors or discrepancies. The patient enters a correction request using their application. The request can be a simple unstructured request, but can also contain additional structured information to provide context or to pinpoint the error and the fix. The application (CorrectionRequester) sends the correction request to the appropriate provider system (RequestFulfiller). The provider (most likely a medical records professional but possibly a clinician) reviews the request on the provider system (EHR). If needed, the provider reaches out to the patient to further clarify the request and consults as needed with clinicians to determine if a correction is appropriate. It is determined that the chart is in fact correct. The request for correction is denied. The correction request is updated with: the reason for the rejection, an explanation that the patient has the right to log a disagreement, a statement that the individual may request that the covered entity provide the individual’s request for amendment and the denial with any future disclosures of the protected health information that is the subject of the amendment, a description of how the individual may complain to the covered entity. Meanwhile, the patient has been able to use their application to check for the status of their correction request and is able to determine that it is being reviewed and then later denied.

Use Case 3: Patient Disagrees with Correction Request Denial.

Upon receiving a denial to their correction request, the patient decides to log a formal disagreement with the provider. The patient enters the disagreement using their application. The application (CorrectionRequester) sends the disagreement to the denied correction request to the appropriate provider system (RequestFulfiller). The provider (most likely a medical records professional but possibly a clinician) reviews the disagreement on the provider system (EHR) and consults as needed with clinicians. The chart on the EHR might also be reviewed. The provider determines that the chart is correct and is not swayed by the disagreement. The provider connects the disagreement to the patient’s electronic chart so that it can be referred to and sent along with the record. The provider also potentially provides a formal rebuttal. Meanwhile, the patient has been able to use their application to check for the status of their disagreement and is able to determine that it is being reviewed and then later accepted.

Use Case 4: Patient Requests a Correction to Their Medical Record and Later Sends an Update to Their Correction Request.

A patient reviews the records received from a provider (most likely this review is of the electronic health information accessed on their personal health record application). The patient determines that it contains one or more errors or discrepancies. The patient enters a correction request using their application. The application (CorrectionRequester) sends the correction request to the appropriate provider system (RequestFulfiller). The patient later determines the Correction Request is incorrect or incomplete. For example, the patient may have entered the wrong information, or may want to add a supporting attachment, or a list of contacts to notify upon correction completion. Their application sends an updated correction request to the provider system. The provider system updates the correction request accordingly and continues processing it.