Patient Experience - Revision history

Tom: /* Patient Follow-though */

2025-11-01T22:26:09Z

‎Patient Follow-though

Tom: /* Patient Histories */

2022-01-22T21:06:14Z

‎Patient Histories

Tom: /* Patient Histories */

2022-01-22T21:00:27Z

‎Patient Histories

Tom: /* Patient Histories */

2022-01-22T20:57:42Z

‎Patient Histories

Tom: /* Patient Consent */

2021-12-08T22:53:30Z

‎Patient Consent

Tom: /* Patient Consent */

2021-12-08T22:52:28Z

‎Patient Consent

Tom: /* Presentation Request */

2021-09-30T20:53:54Z

‎Presentation Request

Tom: /* A Complex Use Case */

2021-09-30T20:52:58Z

‎A Complex Use Case

Tom: /* A Complex Use Case */

2021-09-30T18:31:39Z

‎A Complex Use Case

Tom: /* A Complex Use Case */

2021-09-30T18:25:47Z

‎A Complex Use Case

@@ Line 84: / Line 84: @@
 #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 contradict the care plan.
 ===User Research===

@@ Line 58: / 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.
 *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.
+# 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.
+* [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===

@@ Line 65: / Line 65: @@
 # 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]
+* [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===

@@ Line 59: / Line 59: @@
 *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===

@@ Line 69: / Line 69: @@
 ===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 ****
+* Consent Receipt - need to find a user-friendly description ****
 ===Patient Follow-though===

@@ Line 65: / Line 65: @@
 ===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.
+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===

@@ Line 25: / Line 25: @@
 ===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.
+* 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.
-* The user case will focus on a fully automated wallet in the possession of the child.
+* 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 a HL7 Implementation Guide)
+# 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

@@ Line 31: / Line 31: @@
 # State (or other) issued ID. (disclosure using a health profile) (assumed to be ISO 18013)
 # Payor approval.
-# PCP data (phone number, etc.)
+# PCP contact data (phone number, etc.) (Electronic equal of a business card.) (perhaps a HL7 Implementation Guide)
 # Co-pay method of payment (including any deductible)
 # Parental consent
@@ Line 42: / Line 42: @@
 * 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