FHIR Use Case

Full Title

Carequality FHIR Use Case Proposal

Context

• FHIR Use Case Proposal

Goal

Release of PHI can only occur if the record holder has trust not only that it can accurately identify the requester, but that the request itself, and the requester’s policies and practices around the information once it is released, are appropriate. Such trust is straightforward to establish for an individual connection between two partner organizations, by relying on new or existing contractual relationships bolstered by negotiation of security and other technical details. Such an approach is not scalable, however, as the healthcare industry discovered in the context of document exchange via SOAP-based web services. Carequality’s governance framework can provide a “single on ramp” that allows an organization to sign one contract, implement one technical platform, and connect universally to a broad ecosystem of other participants.

Actors

1. Data Source = data goes from point A to point B. The source is where the data is coming from. Relative to this document, a data source can be a Query Responder or a Push Initiator.
2. Data Receiver I=data goes from point A to point B. The receiver is where the data is going to. Relative to this document, a data receiver can be a Query Initiator or a Push Recipient.
3. Record Locator Service(RLS) = provides the ability to identify where records are located based upon criteria such as a Person ID and/or record data type, as well as providing functionality for the ongoing maintenance of this location information.
4. Provider = A clinician or organization that is directly engaged in treatment services.
5. Patient = A person who is the subject of health records, or an authorized representative acting on such a person’s behalf.
6. Transaction = Per the HL7 website; an interaction that submits a set of actions to perform on a server as a single atomic action. Multiple actions on multiple resources of the same or different types may be submitted, and they may be a mix of other operations (e.g. read, search, create, update, delete, etc.)
7. Research = Work done to improve healthcare costs, outcomes, quality, safety, and innovation via systematic investigation and structured data analysis.

Preconditions

• The patient has a primary care provider with up-to-date medical conditions, prescriptions and allergies.
• The PCP uses an EHR which is part of the US Healthcare Assurance Framework.

Scenarios

Primary Scenario:

1. Patient is traveling, has a shoulder injury and

Alternative Paths:

1. Consumer selects to purchase liquor item.
2. Supplier asks user for over 21 proof with a nonce.
3. Consumer asks verifier directly for proof with nonce from Supplier.
4. Verifier asks consumer to enter token for proof of presence.
5. Verifier send validated claim with nonce of supplier with short expiration time (10-20 mins - alternate life time of duration of session).
6. Consumer sends verified claim to supplier.
7. Monetization is by advertising from verifier to consumer.

A different path using biometrics:

1. 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.

Failed Paths:

1. User does not get verified claim for some reason.
2. Verified claims fails validation at supplier.
3. Verified claims are false.

Results

Accepted Risks:

1. The consumer is not over-21 and has buddy’s token to enter into computer.
2. Session hijacking mitigated with HTTPS and session cookies.
3. MitM attacks mitigated by hardware token bound to origin URL of verifier.
4. Note that the late binding token could be bound to supplier as well as needed.
5. The identity of the verifier/validator is discoverable by the supplier.
6. User makes choices on which attributes are trusted for sharing with the supplier.

Post Condition:

1. If validation accepted, and consumer completes payment, the restricted goods are shipped to the consumer by the supplier.
2. 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:

1. Late binding token - FIDO U2F token, TEE TPM VSC, etc.
2. Client side code - javascript in a browser, native app, etc.

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