Difference between revisions of "Patient Experience"

From MgmtWiki
Jump to: navigation, search
(→‎Patient Histories)
(→‎Patient Histories)
 
(45 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
−
A good [[Patient Experience]] is only created where the patient is informed and involved in their care plan.
+
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==
 
==Context==
−
*This experience document focuses on only two subjects, the patient and the provider. It may be that others are involved or that different names are given to the subjects, but in the majority of cases there will be a mapping to these two subjects.
+
*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.
 
*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.
 +
* [https://wiki.idesg.org/wiki/index.php/Patient_Choice Patient Choice] needs to be top-of-mind as we move the entire medical establishment into the digital age.
  
 
==Problems==
 
==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.
+
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. This provider requires payment in advance of treatment since there is no relationship with the patient.
 +
* This use case will focus on a fully automated wallet in the possession of the child.
 +
* The following documentation is required.
 +
# Selections of the patient's health history and diagnosis with doctor's scripts and medical allergies or other conditions.
 +
# State (or other) issued ID. (disclosure using a health profile) (assumed to be ISO 18013)
 +
# Payor approval.
 +
# PCP contact data (phone number, etc.) (Electronic equal of a business card.) (perhaps as an HL7 Implementation Guide)
 +
# Co-pay method of payment (including any deductible)
 +
# 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.
 +
 
 +
The assumption is that the recipient is a HIPAA covered entity.
 +
 
 +
link to this https://tcwiki.azurewebsites.net/index.php?title=Patient_Experience
  
 
==Solutions==
 
==Solutions==
 
===Patient Identifiers===
 
===Patient Identifiers===
−
*The patient is assumed to go through some fort of registration process with the provider's practice and is "known to the practice".
+
*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.
 
*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.
 
*Every other practice that the patient visits will likewise create a [[Medical Records Identifier]] that it uses to track the patient.
Line 20: Line 58:
 
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]] [[API]]s, 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.
 
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]] [[API]]s, 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.
 
*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.
+
*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, UNDERSTOOD AND AGREED TO.
 +
 
 +
The big issue with patient histories are:
 +
# Where are the original records kept and is it possible to download electronic copies.  Most [[EHR]]s now support download in [[FHIR]] format.
 +
# Is the a place to keep all of a patient's records from multiple providers, a phone or a web service are two possibilities.
 +
# Does the patient's health insurance provider provide a solution.
 +
Here are a few of the current offerings:
 +
* [https://www.smilecdr.com/interoperability-patient-story A patient Story from Smile CDR] based on records maintained by a Medicare Advantage plan.
  
 
===Patient Care Plan===
 
===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 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.
 
*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 [[Presentation 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 [https://hl7.org/fhir/consent.html 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===
 
===Patient Follow-though===
Line 31: Line 83:
 
#The patient may agree, but not understand what the instructions mean, or not accept the effort, cost or experience of following the plan.
 
#The patient may agree, but not understand what the instructions mean, or not accept the effort, cost or experience of following the plan.
 
#The patient may not have the ability to remember or perform all the steps required.
 
#The patient may not have the ability to remember or perform all the steps required.
−
#The patient will get other advice from professional and commercial sites that contract the care plan.
+
#The patient will get other advice from professional and commercial sites that contradict the care plan.
 
*
 
*
  
Line 40: Line 92:
 
==References==
 
==References==
 
<References />
 
<References />
−
 
+
* Johns Hopkins [https://www.hopkinsmedicine.org/office-of-johns-hopkins-physicians/best-practice-news/optimizing-the-patient-experience Optimizing the Patient Experience] (2017-11-20)
 +
* AMA [https://www.ama-assn.org/delivering-care/patient-support-advocacy/6-steps-improve-patients-experience-your-organization Six steps to improve patients’ experience in your organization] 2017-09-07
 +
* CLC (Chile) [https://www.hopkinsmedicine.org/international/partners-forum/past-presentations/2016/04_boekemeyer_slater_mapping_the_patient_experience_at_clc.pdf PATIENT JOURNEY MAPS] 2016-10
 +
* Physician Practice [http://www.physicianspractice.com/patient-relations/five-steps-improve-patient-experience  Five Steps to Improve the Patient Experience.] (2015-11-12)
 +
* See wiki page on [[Wallet User Experience]]
  
 
[[Category:User Experience]]
 
[[Category:User Experience]]
 
[[Category:Best Practice]]
 
[[Category:Best Practice]]
 
[[Category:Health]]
 
[[Category:Health]]

Latest revision as of 13:06, 22 January 2022

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. This provider requires payment in advance of treatment since there is no relationship with the patient.
  • This use case will focus on a fully automated wallet in the possession of the child.
  • The following documentation is required.
  1. Selections of the patient's health history and diagnosis with doctor's scripts and medical allergies or other conditions.
  2. State (or other) issued ID. (disclosure using a health profile) (assumed to be ISO 18013)
  3. Payor approval.
  4. PCP contact data (phone number, etc.) (Electronic equal of a business card.) (perhaps as an HL7 Implementation Guide)
  5. Co-pay method of payment (including any deductible)
  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.

The assumption is that the recipient is a HIPAA covered entity.

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, UNDERSTOOD AND AGREED TO.

The big issue with patient histories are:

  1. Where are the original records kept and is it possible to download electronic copies. Most EHRs now support download in FHIR format.
  2. Is the a place to keep all of a patient's records from multiple providers, a phone or a web service are two possibilities.
  3. Does the patient's health insurance provider provide a solution.

Here are a few of the current offerings:

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 Presentation 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=13600"