The Patient Choice Project
Use Case Working Session
February 5th, 2016
Call Logistics
• If you are not speaking, please keep your phone on mute
• Do not put your phone on hold – if you need to take a call, hang up and dial
in again when finished with your other call
• This meeting is being recorded
• Feel free to use the “Chat” feature for questions, comments or any items
you would like the moderator or participants to know
2
Agenda
Topic
Time Allotted
General Announcements
5 minutes
Additional Assumptions & Pre/Post Conditions
10 minutes
Revised Push Scenarios
20 minutes
Review “PULL” Use Case Scenarios
• Updated Activity Diagrams
• New Sequence Diagrams
20 minutes
Next Steps/Questions
5 minutes
3
General Announcements
• The Patient Choice project will meet weekly on Fridays @ 11 am ET
» The next working group meeting will be on Friday, February 5th , 2016 at 11 am
ET
• Introductions
4
Phase 1 - Timeline
(Today)
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
July
Aug
Sept
Oct
Nov
Use Case Working Group Kick Off Session
Review and development of formal use cases
Kick Off Pilot Activities
Conduct Pilots Needs Assessment
Begin Pilot Work
Develop Best Practices IG
Draft Basic Choice
Standard
5
6
Proposed Use Case & Functional
Requirements Development Timeline
Week
Target Date
Working Session Tasks
Review and Provide Comments via
Confluence (due Thursdays @ 11 am ET)
1&2
12/28
Use Case Process Overview
Introduce: In/Out of Scope, Assumptions, Scenarios, User
Stories
Review: In/Out of Scope, Assumptions,
Scenarios, and User Stories
3
1/8
Review: In/Out of Scope, Assumptions, Scenarios, User
Stories
Review: In/Out of Scope, Assumptions,
and User Stories
4
1/15
CANCELLED for HL7
Review: In/Out of Scope, Assumptions,
and User Stories
5
1/22
Review: Finalized In/Out of Scope, Finalized Assumptions,
and User Stories
Introduce: Pre/Post Conditions and Base Flow
Review: User Stories, Pre/Post
Conditions and Base Flow
6
1/29
Review: Finalized Pre/Post Conditions, PULL Base Flows
and Information Interchange Requirements
Introduce: PULL Activity Diagrams
Review: PULL Base Flows and
Information Interchange Requirements,
and Activity Diagrams
7
2/5
Review: Finalized PULL Base Flows and Information
Interchange Requirements and Activity Diagrams.
Introduce: Revised PUSH User Stories and PULL Functional
Requirements & Sequence Diagram,
Data Requirements and Risks & Issues
Review: Revised PUSH User Stories and
PULL Functional Requirements &
Sequence Diagram, Data Requirements,
and Risks & Issues
8
2/12
Review: Finalized Functional Requirements & Sequence
Diagram, Finalized Data Requirements, and Finalized Risks
& Issues
End to End Review
7
Section Review
• 1. Discuss and review the following sections:
» Assumptions
» Pre/Post Conditions
» PULL User Stories
–
Base Flows
–
Information Interchange Requirements
–
Activity Diagrams
–
Sequence Diagrams
Click the icon to
open the
Word Document
8
Assumptions
•
The requirements of the use case can be implemented in a variety of architectures
•
Patients who are consumers of healthcare services are aware of their ability to complete Consent Directives and do offer such
direction to the clinicians and organizations which they engage to provide them healthcare services
•
Electronic systems have the capability to manage and update consent registries/repositories
•
Electronic service information is known
•
All parties in the exchange comply with applicable privacy and security rules
»
Policy is in place for handling missing or not yet recorded Patient preferences for data sharing
»
All parties comply with Patient privacy preferences and subsequent handling instructions
•
The use case includes systems where the additionally protected information is integrated with other data within an EHR or
other systems that manages Patient health information
•
Disclosures are appropriately updated in the system to be reflected in accounting for disclosures that may be requested by the
Patient
•
Requester identity is verified and authorized to conduct a query for patient data
•
Appropriate security audit mechanisms are in place
•
Appropriate methods for capturing consent are in place
•
Appropriate patient interfaces are in place
9
Pre-Conditions and Post-Conditions
• Pre Conditions
• Mechanisms are in place for handling missing or not yet recorded Patient
preferences for data sharing
• Mechanisms are in place for systems having Patient data have to enforce the
appropriate legal and policy requirements
• Mechanisms are in place to comply with Privacy Consent Directives and
subsequent handling instructions
• Mechanisms are in place to ensure the data holder sends the minimum
information necessary to a requester in accordance to HIPAA
• Post Conditions
• Receiving system complies with ongoing obligations
• Sending and receiving systems have recorded the transactions in their security
audit records
10
Push Scenario 1 - Provider pushes Consent Directive to Consent Directive
Repository
• Context
»
Alice’s PCP participates in the local HIO
»
Alice consents to her PCP sharing all of her records with other providers for Treatment through the HIO
»
The HIO accesses patient consent directives through an affiliated Consent Directive Repository
• User Story
•
Alice recently moved to a new state and finds a new PCP.
•
Her PCP wants to refer her to a Specialist.
•
The PCP tells Alice about the local HIO and explains how the HIO enables her PCP to share her health
information quickly and securely with this Specialist versus the alternative of using fax or mailing paper
copies.
•
Alice is comfortable with sharing her health information through the HIO for treatment purposes, so
she signs the HIO opt-in consent directive.
•
Alice’s PCP pushes Alice’s consent directive to the HIO’s affiliated Consent Directive Repository.
•
Alice’s PCP makes a referral to her Specialist and informs the Specialist that Alice has consented to
sharing her health information through the HIO.
•
Alice’s Specialist is now able to request health information from the HIO. [Go to PULL use case.]
11
Push Scenario 2 - Provider PUSH to HIO for TPO
• Context
» Alice’s HIO Data Holder allows a patient to opt-out of disclosure.
» Alice’s HIPAA Provider is an authorized HIO participant, e.g., has signed the HIO’s DURSA.
» Alice’s HIO permits authorized participants to PUSH a patient’s revised HIO consent
directive to override the patient’s current Exchange/NwHIN HIO consent directive
• User Story
» Alice signs a consent directive opting out of HIO disclosure of health information it has
collected from her participating providers.
» Alice begins receiving care from a specialist, who is an authorized HIO participant.
» Alice changes her mind and wants her HIO health information disclosed to her specialist.
» She signs a HIO opt-in consent directive.
» The specialist pushes Alice’s opt-in consent directive with a request for Alice’s health
information to the HIO.
» The HIO overrides her current opt-out consent directive with Alice’s opt-in consent
directive, and sends Alice’s health information to the specialist.
12
Scenario 1: Query for Consent Directive (Pull)
Provider/ Healthcare Provider
Organization
Data Holder/HIO
Consent Directive Registry
Consent Repository
Start
1. Determines that Patient data
should be requested
2. Sends query for Patient data to
the HIO
3. Receives query for Patient
data
4. Determines if consent is
required to share Patient data
5. Sends query to Consent
Directive registry for Privacy
Consent Directive location
7. Sends query to Privacy
Consent Directive Repository
9. Review Privacy Consent
Directive to determine the data
that may be disclosed.
11. Receives Patient data
End
10. Sends Patient data to
requesting Provider
6. Sends Privacy Consent
Directive location
8. Sends Privacy Consent
Directive to HIO
Scenario 1: Query for Consent Directive (Pull)
User Story 1: HIE Consent Repository
• Context
• HIE maintains a consent repository
• HIE does not provide data unless request is allowed under recorded consent
• User Story
• Patient X presents with abnormal heart rhythm at clinic A
• Doctor Able recommends taking an exercise stress test from a heart specialist
at hospital B
• Patient X’s consent is (or has been) sent to the HIE
• Doctor Baker at hospital B requests medical record from the HIE
• HIE receives request for Patient X record , evaluates request against consent
in the repository, and sends the record to Doctor Baker
14
Scenario 1: Query for Consent Directive (Pull)
User Story 1: HIE Consent Repository
4
Health Information
Exchange
Clinical IT
System
1a
1b
Other IT
System
2
Clinical IT
System
3
Consent
Repository
HIE Security Domain
• Query for consent (3) upon receipt of request for clinical data (2)
15
Scenario 2: Query for Consent Directive (Pull)
User Story 2: HIE / Registry Consent Repository
• Context
• HIE and state registry both maintain a consent repository
• Neither HIE nor state registry provide records unless allowed under consent
• HIE is integrated within state registry and can forward consent messages
• User Story
• Patient Y’s “opt-in” to sharing immunization records from state immunization
registry has been sent to the HIE by doctor or patient
• Patient Y moves within state and visits pediatrician at new location
• Doctor Charlie requests immunization records from HIE
• HIE receives request for records, evaluates request against consent in its
repository, and sends the request to state registry
• State registry receives request, evaluates request against consent in its
repository, and sends the record to HIE that is then forwarded to Dr. Charlie
16
Scenario 2: Query for Consent Directive (Pull)
User Story 2: HIE/Registry Consent Repository
2b
2a
Clinical IT
System
Immunization Registry
Health Information
Exchange
4
3
1a
Consent
Repository
Registry Security Domain
1c
Consent
Repository
HIE Security Domain
Clinical IT
System
1b
Other IT
System
• Query for consent (3, 4) upon receipt of request for clinical data (2a, 2b)
17
Scenario 3: Query for Consent Directive (Pull)
User Story 3: Hospital Consent Repository
• Context
• General Hospital maintains a consent repository
• Care teams do not provide records unless request is allowed under consent
• User Story
• Patient Z receives hip replacement at General Hospital, which is required to
follow Comprehensive Care for Joint Replacement (CJR) payment model
• Patient Z’s consent is (or has been) sent to General Hospital repository
• Patient Z is discharged to a skilled nursing facility (SNF)
• Doctor Delta is assigned to follow progress of Patient Z for 90 days post
discharge
• Later, Doctor Delta requests Patient Z’s medical record from the SNF
• SNF receives request for Patient Z record , evaluates request against consent
in General Hospital repository, and sends the record to Doctor Delta
18
Scenario 3: Query for Consent Directive (Pull)
User Story 3: Hospital Consent Repository
2
4
Clinical IT
System
Care Team
IT System
3
1
Care Team
IT System
Consent
Repository
Service Team
IT System
Hospital Security Domain
• Query for consent (3) upon receipt of request for clinical data (2)
19
Next Steps
• Review and provide feedback to posted materials: PUSH Activity Diagrams,
Functional Requirements & Sequence Diagrams by the following Thursday
at 11am ET
» http://confluence.siframework.org/display/PATCH/Use+Case+Development
• Next meeting is Friday, February 12th , 2016 at 11 am ET
• Reminder: All Patient Choice Announcements, Schedules, Project Materials,
and Use Case will be posted on the Patient Choice Confluence page
» http://confluence.siframework.org/display/PATCH/
20
Project Contact Information
OCPO-ONC Lead
Jeremy Maxwell
[email protected]
Project Coordinator
Johnathan Coleman
[email protected]
Project Manager
Ali Khan
[email protected]
Project Support
Taima Gomez
[email protected]
Staff SME
Kathleen Connor
[email protected]
Staff SME
David Staggs
[email protected]
21
Thank you for joining!
@ONC_HealthIT
@HHSONC