Patient with Lab and Referral Use Case: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
 
(27 intermediate revisions by the same user not shown)
Line 3: Line 3:


==Context==
==Context==
To provide good assurance that a patient data is kept as private as possible.
To provide good assurance that a patient data is kept as private as possible consistent with quality health care.


===Goal===
===Goal===
The patient in the very near future has full capability to exercise their right to participate in the care plan and see who has access to their medical records.
* The patient in the very near future has full capability to exercise their right to participate in the care plan and see who has access to their medical records.
* Provide the two apis as described in the [[Health Care Profile]].
# Trusted Identifiers for all providers, and perhaps patients as well.
# Consent experience for patient


===Actors===
===Actors===
Line 15: Line 18:


==Preconditions==
==Preconditions==
*The Consumer has acquired a late binding token from any provider at all.
# The patient is "known to the practice" where general health care is provided.
*The Consumer has registered an over-21 claim with verifier using token.
# A trust registry exists which the patient knows and trusts.
*The Consumer has established an account with supplier using a DID or other persistent ID.
# The providers of health care and lab services present the patient with a trusted identity which confirms that they subscribe to the privacy regulations of the trust provider.
# Different providers are unlikely to allow each other, or the patient, to write into their [https://tcwiki.azurewebsites.net/index.php?title=EHR EHR], so it is expected that the patient will have multiple repositories, each with their own [https://tcwiki.azurewebsites.net/index.php?title=Medical_Records_Identifier Medical Records Identifier].
# Patient can always get their own data, but only after strong authentication. This data will include a list of existing consent grants. The patient always has the right to revoke consent
# The patient has the right to eliminate some individuals in a practice from seeing their data even when the practice has access.
 
An optional condition would be for the patient to have a trusted identity in cyberspace that can be used to access their health records at any of their care providers.


==Scenarios==
==Scenarios==
Scenario: Consumer signs into supplier and has never purchased liquor from this site.
The goal of this scenario is to test the functionality of the APIs associated with patient trust of the providers and patient consent granting and recording.
#Consumer selects to purchase liquor item
#Supplier asks user for over 21 proof with a nonce.
#Consumer sends verifiable claim of over 21 they acquired from verifier.
#Supplier asks verifier for proof. (This would be by redirect to verifier through user browser)
##Verifier supplies validated claim (or statement of non-revocation) bound to nonce by redirect to Supplier, if this VC is bound to the user’s session with supplier, it can have a lifetime of the duration of bound session.
#Monetization is by direct micro payment (on the order of $.05) from supplier to verifier.
 
 
Alternative Paths:
#Consumer selects to purchase liquor item.
#Supplier asks user for over 21 proof with a nonce.
#Consumer asks verifier directly for proof with nonce from Supplier.
#Verifier asks consumer to enter token for proof of presence.
#Verifier send validated claim with nonce of supplier with short expiration time (10-20 mins - alternate life time of duration of session).
#Consumer sends verified claim to supplier.
#Monetization is by advertising from verifier to consumer.


A different path using biometrics:
Primary Scenario:
#Patient schedules an appointment with primary care physician (PCP) and is authenticated at the front desk. (This might involve re-affirmation of the consent with the practice.)
#Patient sees the doctor, is reauthenticated (this reauth will be less onerous than that at the front desk) and explains symptoms.
#Doctor schedules a lab test for a sensitive condition (for example sexually transmitted disease) in order to test patient consent to share such information with referral.
#The patient is given a consent receipt that tells the patient the labs trusted identity and adherence with the trust registry conditions for handling patient records.
#The patient positively gives consent consonant with the receipt by signing a copy and returning to the doctor's practice.
#The patient goes to the lab which gives a trusted identifier to the patient.
#The patient is authenticated and given the test.
#The lab has consent and so passes the patient data to the doctor's practice.
#The doctor asks for patient consent to schedule further diagnostics with a doctor in a different practice.
#The patient can evaluate that other practice with respect to competence and compliance with appropriate privacy practices.
#The patient gives consent, schedules a consultation and the lab results are passed to the other practice. The patient may or may not also get the results.
#The patient receives a consent receipt from the primary doctor as to the transfer of health records to that other practice


#Yoti, a London-based startup which wants to become the “world’s trusted identity platform”, is one of many attempts to provide such a service. Its system stores government id documents and biometrics. If a user wants to buy a bottle of wine at a supermarket self-check-out and needs to prove their age, they scan a qr code and take a selfie using Yoti’s app. The retailer can be sure of their age, but no one has seen their name or nationality. From the Financial Times.
Alternate Scenario:
# The patient can sign onto the various practices' web sites and preform the actions from the comfort of her living room. In this case electronic consents are appropriate.
# In this case the consent reciepts will be renderable to the user in understandable user experience.


Failed Paths:
Alternate Scenario:
#User does not get verified claim for some reason.
# In the above scenario the lab delivers the patient results to the PCP for inclusion in their EHR, in some cases the patient will contract directly with the lab which will maintain an EHR for the patient.
#Verified claims fails validation at supplier.
# In this scenario the patient needs to explicitly request the data be transfer to the PCP, or transfer it to the PCP themselves.


==Results==
==Results==
Accepted Risks:
Accepted Risks:
#The consumer is not over-21 and has buddy’s token to enter into computer.
#Data transfers involved work within a framework of trust and mutual understand as to the patient's wishes with respect to care and privacy.
#Session hijacking mitigated with HTTPS and session cookies.
#MitM attacks mitigated by hardware token bound to origin URL of verifier.
#Note that the late binding token could be bound to supplier as well as needed.
#The identity of the verifier/validator is discoverable by the supplier.
#User makes choices on which attributes are trusted for sharing with the supplier.


Post Condition:
Post Condition:
#If validation accepted, and consumer completes payment, the restricted goods are shipped to the consumer by the supplier.
#There are now two additional consents steps, lab with sensitive data and secondary provider with sensitive.
#Note that at the end of the process of validating the user’s age, the state issued license to sell alcoholic beverages will determine which path to use. The penalty for the supplier using the wrong path is loss of the license to sell alcohol.
#No data is ever shared with any provider that has not been strongly identified to the patient.
#The patient results are available it is assumed that the consent receipt acknowledged that the data would be sent back to the primary care doctor.


Examples:
Examples:
#Late binding token - FIDO U2F token, TEE  TPM VSC, etc.
#tbd
#Client side code - javascript in a browser, native app, etc.


Dependencies::
Dependencies::
Line 75: Line 76:


[[Category:Use Cases]]
[[Category:Use Cases]]
[[Category:Profile]]
[[Category:Health]]
[[Category:Health]]

Latest revision as of 17:21, 3 May 2019

Full Title of Use Case

Patient at private care provider is given a lab test which results to a referral to a different practice.

Context

To provide good assurance that a patient data is kept as private as possible consistent with quality health care.

Goal

  • The patient in the very near future has full capability to exercise their right to participate in the care plan and see who has access to their medical records.
  • Provide the two apis as described in the Health Care Profile.
  1. Trusted Identifiers for all providers, and perhaps patients as well.
  2. Consent experience for patient

Actors

  1. Patient
  2. Provider of patient's general health care
  3. Lab to perform test on patient sample
  4. Provider of specialized services related to patient diagnosis

Preconditions

  1. The patient is "known to the practice" where general health care is provided.
  2. A trust registry exists which the patient knows and trusts.
  3. The providers of health care and lab services present the patient with a trusted identity which confirms that they subscribe to the privacy regulations of the trust provider.
  4. Different providers are unlikely to allow each other, or the patient, to write into their EHR, so it is expected that the patient will have multiple repositories, each with their own Medical Records Identifier.
  5. Patient can always get their own data, but only after strong authentication. This data will include a list of existing consent grants. The patient always has the right to revoke consent
  6. The patient has the right to eliminate some individuals in a practice from seeing their data even when the practice has access.

An optional condition would be for the patient to have a trusted identity in cyberspace that can be used to access their health records at any of their care providers.

Scenarios

The goal of this scenario is to test the functionality of the APIs associated with patient trust of the providers and patient consent granting and recording.

Primary Scenario:

  1. Patient schedules an appointment with primary care physician (PCP) and is authenticated at the front desk. (This might involve re-affirmation of the consent with the practice.)
  2. Patient sees the doctor, is reauthenticated (this reauth will be less onerous than that at the front desk) and explains symptoms.
  3. Doctor schedules a lab test for a sensitive condition (for example sexually transmitted disease) in order to test patient consent to share such information with referral.
  4. The patient is given a consent receipt that tells the patient the labs trusted identity and adherence with the trust registry conditions for handling patient records.
  5. The patient positively gives consent consonant with the receipt by signing a copy and returning to the doctor's practice.
  6. The patient goes to the lab which gives a trusted identifier to the patient.
  7. The patient is authenticated and given the test.
  8. The lab has consent and so passes the patient data to the doctor's practice.
  9. The doctor asks for patient consent to schedule further diagnostics with a doctor in a different practice.
  10. The patient can evaluate that other practice with respect to competence and compliance with appropriate privacy practices.
  11. The patient gives consent, schedules a consultation and the lab results are passed to the other practice. The patient may or may not also get the results.
  12. The patient receives a consent receipt from the primary doctor as to the transfer of health records to that other practice

Alternate Scenario:

  1. The patient can sign onto the various practices' web sites and preform the actions from the comfort of her living room. In this case electronic consents are appropriate.
  2. In this case the consent reciepts will be renderable to the user in understandable user experience.

Alternate Scenario:

  1. In the above scenario the lab delivers the patient results to the PCP for inclusion in their EHR, in some cases the patient will contract directly with the lab which will maintain an EHR for the patient.
  2. In this scenario the patient needs to explicitly request the data be transfer to the PCP, or transfer it to the PCP themselves.

Results

Accepted Risks:

  1. Data transfers involved work within a framework of trust and mutual understand as to the patient's wishes with respect to care and privacy.

Post Condition:

  1. There are now two additional consents steps, lab with sensitive data and secondary provider with sensitive.
  2. No data is ever shared with any provider that has not been strongly identified to the patient.
  3. The patient results are available it is assumed that the consent receipt acknowledged that the data would be sent back to the primary care doctor.

Examples:

  1. tbd

Dependencies::

  1. Web Sites must be trusted before any user information is released.
  2. Trust federations can be used to help users make informed decisions.
  3. User consent and trust must begin with no user information transferred.
  4. Standards exist to collect needed attributes where-ever they may be.

Workflow Diagram

TK

References

Retrieved from "https://wiki.idesg.org/index.php?title=Patient_with_Lab_and_Referral_Use_Case&oldid=12928"