The Patient Choice Project
Use Case Working Session
January 8th, 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
Patient Choice Use Case Development
• Use Case Timeline
• In/Out of Scope, Assumption, Scenarios
• Introduction to User Stories
50 minutes
Next Steps/Questions
5 minutes
3
General Announcements
• The Patient Choice project will meet weekly on Fridays @ 11 am ET
» The working group meeting on Friday, January 15th, 2016 has been CANCELLED
due to HL7
» The next working group meeting will be on Friday, January 22nd, 2016 at 11 am
ET
4
5
General Use Case Outline
• 1.0 Preface and Introduction
• 2.0 Initiative Overview
» 2.1 Initiative Challenge Statement
• 3.0 Use Case Scope
» 3.1 Background
» 3.2 In Scope
» 3.3 Out of Scope
» 3.4 Communities of Interest
• 10.0 Scenario: Generic Provider Workflow
– 10.1 User Story 1, 2, x, …
– 10.2 Activity Diagram
o 10.2.1 Base Flow
o 10.2.2 Alternate Flow
– 10.3 Functional Requirements
o 10.3.1 Information Interchange
Requirements
o 10.3.2 System Requirements
– 10.4 Sequence Diagram
• 4.0 Value Statement
• 5.0 Use Case Assumptions
• 6.0 Pre-Conditions
• 7.0 Post Conditions
• 8.0 Actors and Roles
• 11.0 Risks, Issues and Obstacles
• 12.0 Dataset Requirements
• Appendices
– Related Use Cases
– Previous Work Efforts
– References
• 9.0 Use Case Diagram
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, Actors and Roles, Activity
Diagram and Base Flow
Review: User Stories, Pre/Post
Conditions, Actors and Roles, Activity
Diagram and Base Flow
6
1/29
Review: Finalized User Stories, Finalized Pre/Post
Conditions, Finalized Actors and Roles, Activity Diagram
and Base Flow.
Introduce: Functional Requirements & Sequence Diagram
Review: Activity Diagram and Base Flow,
and Functional Requirements &
Sequence Diagram
7
2/5
Review: Finalized Activity Diagram and Base Flow, and
Functional Requirements & Sequence Diagram
Introduce: Data Requirements and Risks & Issues
Review: 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
Use Case Development Process
8
Section Review
• 1. Discuss and review the following sections:
1. Scope Items
2. Assumptions
Click the icon to
open the
Word Document
3. Activity Diagram
• 2. Introduce and review the following sections:
1. Draft User Stories
9
Phase 1: In-Scope
• Semantic understanding of a Basic Choice consent decision and the
corresponding information that comprises a privacy consent directive
• Information that must be available a the time of a query for patient data to
enable a data source to determine if the requester is authorized to receive a
response
• Demonstrate the use of computable consent to enable privacy policy
implementation and information access control decisions
10
Phase 1: Out of Scope
• Methods for Capturing Consent
• Patient Interfaces
• Mechanisms for managing a consent directive
» Policies surrounding information that has already been shared when a patient
changes their privacy consent directive to “Do not share”
» Mechanisms to update privacy consent directives
• Maintenance and updating of consent registries
• Maintenance and updating of consent repositories
11
Use Case 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 Federal privacy and security rules
•
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
•
Policy is in place for handling missing or not yet recorded Patient preferences for data sharing
•
All parties commit to having the capability to comply with Patient privacy preferences and subsequent handling instructions. is in place for
handling information that has already been shared when a patient changes their privacy consent directive to “Do not share”
•
Disclosures are appropriately updated in the system to be reflected in accounting for disclosures that may be requested by the Patient
•
Appropriate security audit mechanisms are in place
•
Appropriate methods for capturing consent are in place
•
Appropriate patient interfaces are in place
•
Consent Directives are based on the most current and up to date Patient privacy preferences
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 1: 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 1: 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 1: 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 1: 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
Scenario 2: Push Consent Directive and Authorization
Data Requester
Data Holder
Start
1. Data Requester sends Privacy Consent Directive and
request for Patient data to provider 2
2. Data Holder receives Privacy Consent Directive
and request for Patient data
3. Data Holder decides which information to return
and assembles response.
5. Data Requester receives response from Data Holder
4. Data Holder sends response to Data Requester
End
20
Scenario 2: Push Consent Directive and Authorization
User Story 1
SSA receives an electronic and hard-copy of Alice’s SSA-827 Authorization to
Disclose Information to SSA. SSA is able to validate Alice’s identify because she
authenticated to her MyHealtheVet account when she filled out, digitally
signed, and submitted her electronic SSA-827. SSA is also in receipt of her
hard-copy version of the same SSA-827 form. SSA attaches her Consent
Directive to SSA’s request for all of her VHA records.
VHA receives SSA’s request for all of Alice’s records along with her electronic
Consent Directive via NwHIN. VHA processes this request through the
enterprise VHA access control system, which is connected to all points of
external protected health information disclosure. VHA’s access control system
determines that VHA is a trusted NwHIN partner. VHA validates that Alice is
the author the SSA-827 Form by checking her digital signature, and releases
the requested information to SSA via NwHIN.
21
Next Steps
• Review and provide feedback to posted materials: User Stories, In/Out of
Scope, Assumptions, and Scenarios sections by the following Thursday at
11am ET
» http://confluence.siframework.org/display/PATCH/Use+Case+Development
• Next meeting is Friday, January 22nd, 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/
22
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
23
Thank you for joining!
@ONC_HealthIT
@HHSONC