The Patient Choice Project
Use Case Working Session
January 29th, 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 and Timeline Review
5 minutes
Patient Choice Use Case Development
• Confluence Feedback
• Finalized Pre/Post conditions
10 minutes
Review “PULL” Use Case Scenarios
• Base Flows (13 min)
• Information Interchange Requirements (13 min)
• Activity Diagrams (13 min)
40 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:
» Pre/Post Conditions
» PULL User Stories
–
Base Flows
–
Information Interchange Requirements
–
Activity Diagrams
Click the icon to
open the
Word Document
8
Confluence Feedback
Name
Dan Russler,
Consumer
Dan Russler,
Consumer
Comment
Add: The consumer is aware of the rights granted in Federal Regulations
to personal copies of all her health records from providers of care with
the exceptions as noted in Federal Regulations: Exception 1 Exception 2
Exception 3…
I suggest the addition of the simplest use case:
1. Patient requests update to her current copy of her medical record
Disposition
We can include as a
precondition for all user
stories
This is captured through the
revised PUSH use cases
Precondition: Patient has previously signed a consent directive and
directly received her medical record (she is unemployed and has no third
party agent that holds her person medical records)
1. Patient electronically sends a request for an update to her local
medical record with a starting date for the update and and end date of
current
2. Receiver electronically returns the recent records to the patient as
defined in the scope of the request
Dan Russler,
Consumer
Post condition
Patient now has complete set of medical records locally
Add as second bullet:
Information that must be available at the time of a query for patient data
to enable a data source to determine the scope of the data available from
the data source that falls within the scope defined in the query for
patient data.
Under Consideration
Note: data source not only has to determine if requesting party is
authorized, it needs to assess whether it can technically respond to the
request, e.g. is data available; how much data is available; is there any
data within the scope of the request that is not authorized to be sent in
the response to the requester and, if so, can it be redacted from the
response to the requester.
Note2: should this bullet be in scope or out of scope?
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
• Systems sending Patient data have the capability to enforce the appropriate legal and
policy requirements
• Mechanisms are in place to comply with Privacy Consent Directives and
subsequent handling instructions
• Post Conditions
• Receiving system complies with ongoing obligations
• Receiving system successfully complies with obligations
• Sending and receiving systems have recorded the transactions in their security
audit records
10
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
12
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)
13
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
14
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)
15
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
16
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)
17
Next Steps
• Review and provide feedback to posted materials: User Stories, Pre/Post
Conditions, Base Flows, and Information Interchange Requirements sections
by the following Thursday at 11am ET
» http://confluence.siframework.org/display/PATCH/Use+Case+Development
• Next meeting is Friday, February 5th , 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/
18
Project Contact Information
OCPO-ONC Lead
Jeremy Maxwell
Jeremy.Maxwell@hhs.gov
Project Coordinator
Johnathan Coleman
jc@securityrs.com
Project Manager
Ali Khan
Ali.Khan@esacinc.com
Project Support
Taima Gomez
Taima.Gomez@esacinc.com
Staff SME
Kathleen Connor
klc@securityrs.com
Staff SME
David Staggs
drs@securityrs.com
19
Thank you for joining!
@ONC_HealthIT
@HHSONC