Patient with Lab and Referral Use Case
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.
Actors
- Patient
- Provider of patient's general health care
- Lab to perform test on patient sample
- Provider of specialized services related to patient diagnosis
Preconditions
- The patient is "known to the practice" where general health care is provided.
- A trust registry exists which the patient knows and trusts.
- 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.
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
Primary Scenario:
- Patient schedules an appointment with primary care physician and is authenticated at the front desk.
- Patient see doctor, is reauthenticated and explains symptoms.
- Doctor schedules a lab test for a sensitive condition
- 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 doctors 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 receives a consent receipt from the primary doctor as to the transfer of health records to that other practice
Results
Accepted Risks:
- The consumer is not over-21 and has buddy’s token to enter into computer.
- 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:
- If validation accepted, and consumer completes payment, the restricted goods are shipped to the consumer by the supplier.
- 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.
Examples:
- Late binding token - FIDO U2F token, TEE TPM VSC, etc.
- Client side code - javascript in a browser, native app, etc.
Dependencies::
- Web Sites must be trusted before any user information is released.
- Trust federations can be used to help users make informed decisions.
- User consent and trust must begin with no user information transferred.
- Standards exist to collect needed attributes where-ever they may be.
Workflow Diagram
TK