# Principled (Q)HIN Design: Convenience AND Control

*A wishlist for consumer authorization in HIN-backed exchange.*

## User Stories

All stories feature Elena, a 42-year-old marketing executive whose healthcare providers participate in AcmeConnect, a Health Information Network (HIN).

1. **The Audit Log Discovery** Elena receives an email notification from AcmeConnect HIN about recent access to her health records. Curious, as she hasn't visited a doctor lately, she decides to check her audit log. She navigates to the AcmeConnect HIN site and logs in. She navigates to the "Access Log" section. While reviewing the log, she notices an unexpected access by her former doctor's office for a diabetes risk assessment program she wasn't aware of. This prompts her to investigate stronger data control options available through the HIN.

2. **"Ask Me First" in Action**
   Elena decides to enable the "Ask Me First" feature in her AcmeConnect HIN settings. The following month, she receives a notification from the HIN about a data access request from "Midwest Health Analytics," a provider she doesn't recognize. Elena logs in again, reviews the request details, and learns that it's a third-party service contracted by her insurance company for population health studies. She denies the request and flags it for follow-up with her insurance company.

3. **Life Insurance Application Authorization** While applying for a new life insurance policy online, Elena needs to verify her medical history. She clicks a button to connect to AcmeConnect HIN. The insurance application app redirects her to AcmeConnect HIN, where she logs in and shares her digital driver's license for identity proofing. Once authenticated, Elena is presented with an authorization request from the insurance company for a two-year medical history summary. Elena selects her primary care physician, Dr. Martinez, and approves sharing the specified information. The HIN sends the signed authorization back to the insurance application app, which then proceeds to retrieve Elena's data.

4. **Research Access Authorization** Elena's nephew is diagnosed with Familial Mediterranean Fever (FMF), a rare genetic condition. She decides to participate in a related research study. After signing up through the study's app, Elena is redirected to AcmeConnect HIN for identity proofing and authorization. She logs in using her digital driver's license and reviews the study's request to access her relevant health data from all sources. After approving, the HIN generates a signed authorization and sends it back to the research study app. The study app then uses this authorization to retrieve Elena's data.

## Consumer Authorization Wishlist for Healthcare Data Access through HINs

1. **Robust Identity Proofing**

   - Ensure a reliable identity proofing process that verifies the patient’s identity securely and accurately, establishing trust at the very beginning of the data access chain.

2. **Authorization Bound to Identity**

   - Authorization should be tied to the identity proofing step. For example, a FHIR Consent or Permission resource should be signed by the same Identity Provider (IDP) that verified the identity or by a consumer’s private key that is explicitly linked to the identity documentation.

3. **Support for Multiple Architectures**

   - Authorization processes should support different underlying identity and permission mechanisms:
     - Centralized architecture, such as managed web infrastructure (e.g., login.gov or similar private services).
     - Decentralized architecture involving state-issued mobile drivers licenses (should align with initiatives including NIST’s work on mobile identity wallets).

4. **Patient-Approved Data Requests**

   - Patient-facing applications of all kinds should be able to request healthcare data by first using a HIN-trusted service to establish identity and authorization. Apps then use these identity and authorization artifacts to request data from any permitted source.

5. **B2B Audit Log Management**

   - HINs should be able to capture and manage comprehensive audit logs for all Business-to-Business (B2B) queries authorized through the HIN. This helps ensure transparency and accountability in data exchanges between organizations.

6. **Patient Access to Audit Logs**

   - Patients must be granted access to HIN-managed audit logs, allowing them to view which entities accessed their data, when it was accessed, and for what purposes. Thus helps promote transparency and patient trust in the system.

7. **Patient-Supplied Default Policies**

   - Patients should be able to register their preferred access policies with the HIN. Examples include:
     - **Ask Me First**: Patients should have the option to request a "check with me before data access" policy, ensuring that any B2B data access is explicitly approved by them before proceeding.
     - **Static Access Control Policies**: Patients may choose to allow data sharing only under certain conditions, such as during an emergency or only with specific types of healthcare providers.