Page tree
Skip to end of metadata
Go to start of metadata

Short Description

Testing the Patient Request for Corrections Draft Implementation Guide 

Long Description

Our ultimate goal is to build a FHIR Implementation Guide to provide a standard way to communicate information required to support a patient request for corrections workflow. The purpose of this Connectathon is to task the Patient Request for Correction Draft Implementation Guide that uses the Task Resource to see if this is the best resource to accomplish our goal.

    Our three use cases to be tested include:

  • Patient requests change and change is accepted.
  • Patient requests change and change is denied.
  • Patient disagrees with denial.

Agenda

Tentative Schedule:

Pre-connectathon Spec Preparation Meetings: 

Thursday December 3 @ 1 PM ET
Monday December 7 @ 3 ET
Tuesday December 8 @ 2 ET
Thursday December 10 @ 1 ET

Thursday December 17 @ 1ET  (Track Orientation)
Orientation Recording  Download Orientation PDF

Other pre-connectathon meetings - TBD 

These dates and times are subject to change over the next few weeks but will be finalized before/at the connectathon.

Track Kickoff: Wednesday, January 13th, 3 PM Pacific Time (6 PM US ET)

Track Work: Thursday, January 14th, 8 AM -7 PM Pacific and Friday January 15th, 8AM - 4 PM Pacific

Status Check In Thursday: January 14  8AM Pacific (11 AM US ET) and 1 PM Pacific (4 PM Eastern) and 5 PM Pacific (8 PM Eastern)

Expert Guest Panel Thursday: January 14th, 2PM Pacific (5 PM Eastern)

Status Check In Friday: January 15  8AM Pacific (11 AM US ET) and 1 PM Pacific (4 PM Eastern)

Report Out Friday: Friday, January 15th, 3:00 PM Pacific (6 PM US ET).  Report out slide deck

Type

Test the viability of the implementation guide.

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  

Patient Empowerment Work Group

Track Leads

Virginia Lorenzi (Vlorenzi@nyp.org),

Debi Willis (Debi@MyPatientLink.com),

Related Tracks

None

FHIR Version

R4

Specification(s) this track uses

Patient Corrections FHIR Implementation Guide (draft in progress):   http://build.fhir.org/ig/HL7/fhir-patient-correction/index.html 

Artifacts of focus

Patient Correction Request ProfilePatient Correction Disagreement Profile, Task Resource

Clinical input requested (if any)

Input from health information management personnel and clinicians that have experience responding to patient correction requests is always welcome

Patient input requested (if any)

We have these resources available, but more are welcome!

Expected participants

Sign up here: Connectathon 26 Patient Request for Corrections Participation Sign-Up

Zulip stream

https://chat.fhir.org/#narrow/stream/179262-patient-empowerment/topic/Connectathon26.20-.20Patient.20Request.20for.20Corrections


Track Orientation Date

December 17 at 1 PM ET 

Track Orientation Details

Recording  and Slides to Download

Track Details

(Download Current Testscript for details on Scenario Test Steps)


Scenario 1 – Patient requests that their record is corrected and the request is accepted

Test Summary:

Bob reviews his medical records from Southside Clinic. He notices that he is listed as an everyday smoker. However, Bob has not smoked in 20 years. Bob uses his patient app to request a correction to his chart and to track the status of the request – his correction request is reviewed, accepted, and completed.

 Action: 

  • Bob uses his patient app (CorrectionRequester) to request a correction to his record from Southside Clinic (RequestFulfiller).
  • Southside Clinic (RequestFulfiller) receives Bob request and reviews it. Bob uses his patient app to track the status of his request and is informed that it is being reviewed.
  • Southside Clinic (RequestFulfiller), after reviewing the request, decides to accept it. Bob uses his patient app to track the status of his request and is informed that the correction request has been accepted
  • Southside Clinic (RequestFulfiller completes the correction by amending the chart appropriately. Bob uses his patient app to track the status of his request and is informed that the correction has been completed.

Precondition A Patient resource for Bob is on both the client and on the server.  The client and the server support the Correction Request Task Profile.

Success Criteria Patient Corrections IG is used to convey the new correction request, its acceptance, and its subsequent completion. 

Bonus point(s):  

  1. Request correction for other types of chart errors.
  2. Send an update (PUT) to the Correction Request Task, providing additional information about the request.
  3. Use Task.input to provide more detailed information and context to the request. (such as Encounter, Resource In Error, Who to Contact, Corrected Resource, Attached Image, or document)
  4. Use Task.statusReason to communicate additional information about the status.  (completed by RequestFulfiller)
  5. Use Task.note for details about the work on the Task (completed by RequestFulfiller)
  6. Support additional Task queries: history search, Patient search, and, Task identifier search.


Scenario 2 – Patient requests that their record is corrected and the change is rejected

Test Summary:

Bob reviews his medical records from Southside Clinic. He notices that he is listed as an everyday smoker. However, Bob has not smoked in 20 years. Bob uses his patient app to request a correction to his chart and to track the status of the request – his correction request is rejected.

Action: 

  • Bob uses his patient app (CorrectionRequester) to request a correction to his record from Southside Clinic (RequestFulfiller).
  • Southside Clinic (RequestFulfiller) receives Bob request and reviews it. Bob uses his patient app to track the status of his request and is informed that it is being reviewed.
  • Southside Clinic (RequestFulfiller), after reviewing the request, rejects it and provides an explanation of the rejection as well as information on how to log a disagreement. Bob uses his patient app to track the status of his request and is informed that the correction request has been rejected

Preconditions Patient Bob is on both the client and on the server.  The client and the server support the Correction Request Task Profile.

Success Criteria Patient Corrections IG is used to convey the new correction request and its rejection completion. 


Scenario 3 – Patient Logs a Disagreement with the Rejection to their Correction Request

Test Summary:

After receiving a rejection to his correction request, Bob decides to write and send a formal disagreement using his Patient App (CorrectionRequester).  Southside Clinic (Request Fulfiller) reviews the disagreement and stands firm on their decision not to correct the record.  They provide a rebuttal to the patient. 

Action: 

  • Bob uses his patient app (CorrectionRequester) to log a disagreement to the rejection of his correction request with Southside Clinic (RequestFulfiller).
  • Southside Clinic (RequestFulfiller) receives Bob’s disagreement and reviews it. Bob uses his patient app to track the status of his request and is informed that it is being reviewed.
  • Southside Clinic (RequestFulfiller), after reviewing the disagreement, stands firm on their reason not to correct the record and decides to provide a rebuttal. The rebuttal is provided in Task.output.  Bob uses his patient app to track the status of his request and is informed that the rejection still stands and of the rebuttal.

Preconditions Patient Bob is on both the client and on the server.  The client and the server both contain the rejected Patient Correction Request Task.  Both client and server support the Patient Correct Request Task profile and the Correction Disagreement Task profile.

Success Criteria Patient Corrections IG is used to convey the disagreement, subsequent statuses on its review and rejection including the rebuttal. 

Security and Privacy Considerations:

SMART-ON-FHIR use is assumed but could test without it if a server supports that.