Patient Experience

From MgmtWiki
Revision as of 11:29, 29 September 2021 by Tom (talk | contribs) (→‎Immunization Status Use Case)

Jump to: navigation, search

Full Title or Meme

A good medical Whole of Patient Experience is only created where the patient is informed and involved in each decision and how it fits into their care plan.

Context

  • This experience document focuses on only two subjects, the patient and the provider.
  • It sill always be that others are involved or that different names are given to the subjects, but ithe care plan will be in the PCP office.
  • While the most significant part of the patient experience might be the outcome, this page focuses on the part of the journey that leads to that outcome, but not on the outcome itself.
  • Patient Choice needs to be top-of-mind as we move the entire medical establishment into the digital age.

Problems

In the absence of a single payer health care network, the US is blessed with a plethora of solutions, but plagued with the resultant lack of interoperability. As a result it has been impossible in the past for user's to effectively carry their health history around with them as they move about the country or even across town.

Health Equity requires that any patient that wants to access their health data can do given their capabilities and resources (or lack of resources). A variety of capabilities will be enabled with the trust registry to assure that vulnerable populations can be served when and where they chose. While this Patient Experience document focuses on the smart-phone case, other media, like paper based QR codes need to be provided in complete solutions.

Immunization Status Use Case

As a place holder this is the current status of the Smart Health Card use case

  • The Patient goes to a pharmacy (lab, whatever) for a vaccination.
  • The patient taps their phone at the pharmacy desk.
  • After receiving the Presentation Request from the pharmacy, and acceptance by the user, the data (and any co-pay) is transferred from the phone to the pharmacy.
  • After the shot, and a wait for seizures, the patient is again asked to tap the phone at the desk.
  • A Smart Health Card is added to the patient's phone wallet.
  • There may be a "not before" date on the card. Typically this is two weeks for COVID. After that date the patient is able to access venues for "fully vaccinated" people.

Link to Smart Health Cards https://tcwiki.azurewebsites.net/index.php?title=Smart_Health_Card

A Complex Use Case

  • A child is visiting their grandparents out-of-state. The child has a chronic thyroid condition and needs a prescription renewal filled locally. This requires a blood test and prescription refill at providers that have never seen the child previously.
  • The user case will focus on a fully automated wallet in the possession of the child.
  • The following documentation is required.
  1. Portions of the patient's health history and diagnosis with doctor's scripts and medical allergies or other conditions.
  2. State issued ID.
  3. Payor approval.
  4. PCP data (phone number, etc.)
  5. Co-pay funds
  6. Parental consent
  • The patient visits the urgent care center closest to the grandparents' home.
  • The patient taps their phone on the card center's in-take desk.
  • The care center sends a "Presentation Request' to the patient's phone.
  • The patient is told by their phone what information is requested, including co-pay.
  • The patient accepts, the information and money is passed from the patient to the care center.
  • The lab later reports results which are forwarded by the care center to the local pharmacy selected by the patient.
  • The smartphone interchange at the pharmacy exactly maps the experiment at the care center.
  • Success - everyone is pleased with the result.

link to this https://tcwiki.azurewebsites.net/index.php?title=Patient_Experience

Solutions

Patient Identifiers

  • The patient is assumed to go through some sort of registration process with the provider's practice and is "known to the practice".
  • A Medical Records Identifier will be assigned by the practice so that it can recall its own interactions with the patient.
  • Every other practice that the patient visits will likewise create a Medical Records Identifier that it uses to track the patient.
  • There will never be a good Patient Experience where the patient needs to know any of these Medical Records Identifiers.
  • On subsequent visits to the practice, and at each care station within the practice, the patient will be reidentified in an appropriate simplified protocol.

Patient Histories

It is generally agreed that it is better for doctors to have a full set of patient health histories to enable adequate care, especially in life-or-death emergency cases. FHIR, pronounced 'fire' is working on Information Sharing APIs, and the details of that is not addressed here. This page basically assumes that the information sharing part actually is deployed and works reasonably well.

  • Patient histories are available to the patient on demand. A good Patient Experience will provide a complete set of records for the patient. These records are likely to be voluminous, so a paper set of records is to be discouraged.
  • At the end of every care visit the patient will be provided with medical records of the visit that the patient can understand as well as changes to the care plan THAT THE PATIENT HAS SEEN WITH THE PROVIDER, UNDESTOOD AND AGREED TO.

Patient Care Plan

  • The best Patient Experience will come from empathy with the patients journey, including the fear and discomfort that they will inevitably experience.
  • The only valid care plan is one that the patient understands and agrees is best for them.

Presentation Request

The patient cannot be expected to know what documents or data are required for a given use case. It is assumed that the care provider can create a Presentatin Request to send to the patient's phone. This will give the phone the information it needs to determine if it can meet the information requirements and formulate a request for consent to show the user. Only after some sort of consent gesture by the user will any personal information or payment be transmitted to the requestor.


Patient Consent

  • See FHIR Resource Consent - Content Abstract: FHIR provides a Consent resource suitable for use by FHIR clients and servers to record current Privacy Consent state. The meaning of a consent or the absence of the consent is a local policy concern. The Privacy Consent may be a pointer to privacy rules documented elsewhere, such as a policy identifier or identifier in XACML. The Privacy Consent has the ability to point at a scanned image of an ink-on-paper signing Ceremony, and supports digital signatures through use of Provenance. The Privacy Consent has the ability to include some simple FHIR centric base and exception rules.
  • Consent Receipt - need to find a user friendly description ****

Patient Follow-though

  • The care plan may not work and the patient may not communicate that with the provider.
  • While technically the patient has the responsibility for following the agreed healthcare plan the provider must recognize:
  1. The patient may agree, but not understand what the instructions mean, or not accept the effort, cost or experience of following the plan.
  2. The patient may not have the ability to remember or perform all the steps required.
  3. The patient will get other advice from professional and commercial sites that contradict the care plan.

User Research

  • The only way to judge the patient's satisfaction is to ask them.
  • The only way to improve the patient's satisfaction is to try different strategies and, again, ask for feedback.

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Patient_Experience&oldid=12043"