esmd author of record l1 use case meeting
DESCRIPTION
esMD Author of Record L1 Use Case Meeting. Wednesday, August 1, 2012. Meeting Etiquette. From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute . NOTE: This meeting is being recorded and will be posted on the esMD Wiki page after the meeting. - PowerPoint PPT PresentationTRANSCRIPT
esMD Author of Record L1Use Case MeetingWednesday, August 1, 2012
Meeting Etiquette
• Please announce your name each time prior to making comments or suggestions during the call
• Remember: If you are not speaking 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 – Hold = Elevator Music = very frustrated speakers and participants
• This meeting, like all of our meetings, is being recorded– Another reason to keep your phone on mute when not speaking!
• Feel free to use the “Chat” or “Q&A” feature for questions or comments
NOTE: This meeting is being recorded and will be posted on the esMD Wiki page after the
meeting
From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute
2
Use Case Overview Agenda
Agenda Presenter Time Frame
General• Meeting Recap (7/27) and Today’s tasks Sweta Ladwa 1:30 – 1:35
AoR Use Case • Review Scenario and User Story Write up Presha Patel 1:35 – 2:05
Wiki Page Overview• Where to find meeting recordings, Agenda and
meeting materials?• Finding information on previous Use Cases• AoR Use Case content
Presha Patel 2:05 – 2:20
• Discuss detailed Sub workgroup proposed structure and charge
Bob Dieterle Dan Kalwa 2:20 – 3:00
3
Recap of the Last Meeting
• Introduced and reviewed the Assumptions, Pre Conditions, and Post Conditions
• Solicited feedback via the Wiki for sections reviewed during the meeting on Wednesday, 7/25 (Actors & Roles, Communities of Interest, User Story, and Glossary of Terms)
• Reviewed the preliminary scope for the Sub-workgroups introduced last week• Provided a Wiki Sign up page for those interested in participating
in the 4 AoR SWGs
4
Today’s Objectives
• Review any community feedback from the homework items from last weeks meetings:• Actors and Roles• Communities of Interest • Glossary of Terms• User Story• Assumptions, Pre/Post Conditions
• Review the draft AoR L1 User Story• Continue discussions for the charge and deliverables for each of the
Sub-workgroups introduced during the last call
5
• 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.2 Out of Scope • 3.3 Communities of Interest
• 4.0 Value Statement • 5.0 Use Case Assumptions • 6.0 Pre-Conditions • 7.0 Post Conditions • 8.0 Actors and Roles • 9.0 Use Case Diagram
Use Case Outline – Where are we?Note- This is tailored for each Initiative
6
• 10.0 Scenario 1, 2, x… • 10.1 User Story 1, 2, x, … • 10.2 Activity Diagram
• 10.2.1 Base Flow • 10.2.2 Alternate Flow
• 10.3 Functional Requirements • 10.3.1 Information
Interchange Requirements • 10.3.2 System Requirements
• 10.4 Sequence Diagram • 11.0 Dataset Requirements • 12.0 Risks, Issues and Obstacles
Appendices • Related Use Cases • Previous Work Efforts • References
Completed initial review of highlighted sections 1-9
Scenario and User Story
7
Scenario and User Story
Scenario - Section Description: • Comprehensive description of the actors, interactions, activities, and
requirements associated with the information exchange. • It is a prototypical sequence of interactions in a business collaboration or
the application context. • Scenarios pertain to supporting the health information exchange and,
describing key flows, and are supplemented by User Story / Stories.
8
User Story - Section Description: • User Stories summarize the interaction between the actors of the Use
Case, and specify what information is exchanged from a contextual perspective.
• Describes the real world application as an example of the Scenario. These interactions are further described in subsequent sections (Base flow, Activity Diagram, Sequence Diagram).
Scenario and User Story Example
Scenario• Specialist requests patient information from Primary Care Provider
(PCP).
User Story• A Specialist receives a referral and requires more information to treat the
patient properly at the point of care. Using an EHR System, the Specialist sends a request to the PCP for the patient’s Clinical Care Summary. The PCP successfully receives the requests, understands the requests, and sends the patient’s Clinical Care Summary back to the Specialist via the EHR System. The Specialist successfully receives the patient information, understands it, and makes an informed decision that can provide better quality of care to the patient.
9
User Story / Workflow Components
Overall User Story Components
1) All Actors obtain and maintain a non-repudiation digital identity
2) Provider registers for esMD (see UC1)*
3) Payer requests documentation (see UC2)*
4) Provider submits digitally signed document (bundle) to address request by payer
5) Payer validates submission signature and encryption artifacts and acknowledges validity to provider
*User Stories for esMD UC 1 and 2 have already been defined.
Workgroup will help further define bullets 1), 4), and 5)
10
AoR Scenario
A Provider Entity with a digital identity has successfully registered with a Payer Entity to receive electronic medical documentation requests (eMDRs) in support of a claim. In response to the eMDR, the Provider Entity is able to send requested medical documentation as a digitally signed, aggregated document bundle. The Payer Entity is able to validate the submitter and integrity (not the accuracy) of the documentation submission by the Provider Entity.
11
User Story Components & Write up
User Story Components
Suggested steps in the process
1. Establishing Digital Identity
• All Actors (Payer and Provider Entities) obtain and maintain a non-repudiation digital identity using a similar process as outlined below
1. All Actors initiate a Request to obtain a Certificate from a Federal Bridge cross certified Certificate Authority (CA)
2. Identity Information is sent by requestor and reviewed by Registration Authority (RA)
3. RA approves( or rejects) the request and sends approved request to CA4. CA generates and issues the credentials and sends notice to Actor5. Actors obtain credentials and incorporate into their business process
In order to participate in esMD, both Payer and Provider Entities obtain and maintain a non-repudiation digital identity. Both actors initiate the process to obtain a digital certificate from a Federal Bridge cross certified Certificate Authority. Entities approved by a Registration authority will receive Credentials from a Certificate Authority to incorporate into their business process.
12
User Story Components & Write up (Cont.)User Story Components
Suggested steps in the process
2. Provider registers for esMD (see UC1)
Note – May need to abbreviate the UC1 User Story
• Provider Entity submits request to Payer Entity to receive electronic medical documentation requests (eMDR)
• Payer Entity checks providers ability to receive an electronic request • Payer Entity requests and receives Electronic Service Information (ESI)• Provider Entity is either confirmed or rejected to receive eMDRs by Payer
Entity
Provider Entity with digital credentials submits a request to the Payer Entity to receive electronic medical documentation request in support of a claim. The Payer Entity checks the Provider Entity’s ability to receive such requests with an External Provider Directory. The Provider Entity receives a response either confirming or rejecting the request to receive eMDRs by Payer Entity.
13
User Story Components & Write up (Cont.)User Story Components
Suggested Steps in the process
3. Payer requests documentation (see UC2)*
Note – May need to abbreviate the UC2 User Story
• Payer Entity identifies a need for additional documentation for a claim• Payer Entity checks to see if Provider Entity is registered to receive eMDR• Payer Entity requests and receives current ESI from External Provider
Directory for Provider Entity• Payer Entity sends eMDR to provider
When a Payer Entity identifies the need for additional documentation for a claim, they must first check to see if Provider Entity is registered to receive an electronic request (eMDR). If registered, the Payer Entity requests the current Electronic Service Information (ESI) of the Provider Entity from the External Provider Directory. Upon receiving the current ESI, the Payer Entity is able to send the encrypted/digitally signed? eMDR to the Provider Entity.
14
User Story Components & Write up (Cont.)User Story Components
Suggested Steps in the process
4. Submission of Document Bundle
• Provider Entity collects and combines requested patient documentation for claim
• Provider Entity digitally signs the entire document bundle keeping in mind• Delegation of Rights to the signer by registered provider entity• Signatures and Delegation of Rights must provide Non Repudiation• Signature Artifacts must ensure that data integrity of document bundle
is assured• Provider Entity submits digitally signed document bundle to address request
by payer The Provider Entity who has satisfied the registrations requirements to send and receive information as part of esMD, bundles relevant medical documentation requested by the eMDR. To satisfy the eMDR, the Provider Entity applies a non-repudiation digital signature to each aggregated document bundle required and sends them to the Payer Entity.
15
User Story Components & Write up (Cont.)
User Story Components
Suggested Steps in the process
5. Payer validates submission artifacts
• Validates Digital Certificate(s) and chain to Federal Bridge• Validates delegation of rights if required• Validates signer or rights delegation is registered provider• Validates signature artifact• Decrypts hash of document bundle and validates data integrity
Upon receiving the digitally signed bundle of relevant claims documents, the Payer Entity validates the following: Digital Certificate and chain to Federal Bridge, delegation of rights where required, Signature Artifact as well as confirm that the a registered Provider Entity has delegated rights. Additionally the Payer Entity decrypts the hash of document bundle and validates data integrity of the information received. (Note - The Payer Entity does not validate the accuracy of the information received.) Payer Entity sends an acknowledgement of the success or failure of the validation performed by the Payer Entity to the Provider Entity.
16
Complete User Story Write Up
In order to participate in esMD, both Payer and Provider Entities obtain and maintain a non-repudiation digital identity. Both actors initiate the process to obtain a digital certificate from a Federal Bridge cross certified Certificate Authority (validate with Commercial payers). Entities approved by a Registration authority will receive Credentials from a Certificate Authority to incorporate into their business process.
Provider Entity with digital credentials submits a request to the Payer Entity to receive electronic medical documentation request in support of a claim. The Payer Entity checks the Provider Entity’s ability to receive such requests with an External Provider Directory. The Provider Entity receives a response either confirming or rejecting the request to receive eMDRs by Payer Entity
When a Payer Entity identifies the need for additional documentation for a claim, they must first check to see if Provider Entity is registered to receive an electronic request (eMDR). If registered, the Payer Entity requests the current Electronic Service Information (ESI) of the Provider Entity from the External Provider Directory. Upon receiving the current ESI, the Payer Entity is able to send the encrypted and digitally signed eMDR to the Provider Entity
The Provider Entity who has satisfied the registrations requirements to send and receive information as part of esMD, bundles relevant medical documentation requested by the eMDR. To satisfy the eMDR, the Provider Entity applies a non-repudiation digital signature to each aggregated document bundle required and sends them to the Payer Entity.
Upon receiving the digitally signed bundle of relevant claims documents, the Payer Entity validates the following: Digital Certificate and chain to Federal Bridge, delegation of rights where required, Signature Artifact as well as confirm that the a registered Provider Entity has delegated rights. Additionally the Payer Entity decrypts the hash of document bundle and validates data integrity of the information received. (Note - The Payer Entity does not validate the accuracy of the information received.) Payer Entity sends an acknowledgement of the success or failure of the validation performed by the Payer Entity to the Provider Entity.
17
S&I Wiki Overview
Where to find all of the Information?• Meeting Materials, Recordings, Agenda from our weekly calls• Consensus approved and Final Use Case 1 & 2• AoR Use Case Materials and working documents
18
esMD Use Cases 1 and 2Materials > Use Case(s) > UC 1 (or UC 2)
19
What will you find on the Use Case PagesMaterials > Use Case(s) > UC 1 (or UC 2)
20
Links to full Use Case
Charter
Links to Use Case Sections
Materials >Meeting Artifacts
21
Meeting Materia
ls, Agenda,
Recordings fo
r all e
sMD
workgroups
Author of Record L1 Use Case
22
All Works
in Progress
for the
curre
nt Use Case + Releva
nt Use
Case announcements
Content available on Wiki from previous meetings
o Assumptions, Pre and Post Conditions -http://wiki.siframework.org/AoR+UC+L1+-+Assumptions%2C+Pre+and+Post+Conditions
o Actors and Roles - http://wiki.siframework.org/AoR+L1+-+Actors+and+Roles
o Communities of interest table - http://wiki.siframework.org/AoR+L1+-+Communities+of+Interest
o User Story - http://wiki.siframework.org/AoR+UC+L1+-+User+Story
o Glossary - http://wiki.siframework.org/AoR+L1+Use+Case+-+Glossary+of+Terms
o In Scope and Out of Scope Items - http://wiki.siframework.org/AoR+Use+Case+L1+-+In-Scope+and+Out+of+Scope
o Use Case Context Diagram - http://wiki.siframework.org/AoR+Use+Case+Context+Diagram
23
AoR Subworkgroup Discussion
Dan Kalwa & Bob Dieterle
24
Areas to Address
Use Case Topic UC1: Registration UC2: eMDR AoR L1 Bundle
Identity Proofing Required Required Required
Digital Identity Management Required Required Required
Digital Signatures & Signature Artifacts Required Required Required
Delegation of Rights Required Not Required Optional
PHI Encryption Not Applicable Required TBD
Other Topics
Characteristics of solutionNon-Repudiation* Required Required Required
Characteristics of solutionData Integrity** Required Required Required
Provider Directories Required Required TBD
25
*Non-repudiation (NIST) - Non-repudiation is a service that is used to provide assurance of the integrity and origin of data in such a way that the integrity and origin can be verified by a third party. This service prevents an entity from successfully denying involvement in a previous action.
**Data Integrity (NIST) - Data integrity is a property whereby data has not been altered in an unauthorized manner since it was created, transmitted or stored. Alteration includes the insertion, deletion and substitution of data.
User Story Components / Workflow / Sub-workgroups (4)
1. Identity Proofing
• Federal Bridge / NIST Level 3
• Individual and Organization
• Proof of identity requirements
• Allowed proofing processes
2. Digital Credentials
• Issuance• Credential types
and forms• Credential uses
(Identity, Signing, Proxy, Encryption, Data Integrity)
• Specific use credentials (e.g. Direct)
• Maintenance requirements
• Revocation
3. Signing
• Transaction and AoR L1
• Workflow• Artifacts
4. Delegation and Proxy
• Credential approach• Delegation process• Use and limitations
on Use• Revocation
Note - Sub-workgroup leaders & meeting schedule is TBD at this time
26
User Story -- Additional Components / Workflow
Provider Directories (required for entire initiative)
Information requirements
Interactions (transactions)
Entry validation standards
Use and limitations on use
esMD Policy Issues(following report from SWG 1-4)
Requiring digital identities
Requiring digital signing of transactions
Requiring digital signing of submission
Implications of attestation
Other General Issues
Non-repudiation
Data integrity
PHI encryption
27
Sub WorkGroup: Identity Proofing
Type: Sub workgroup
Makeup– Leadership: – SMEs:– Community:
Goal– Define required process for identity proofing of
healthcare individuals and organizations for esMD
Requirements– NIST SP 800-63 Level 3 authentication (V 1.0.2)
2006
In-Scope – RA qualifications and certification– Combining RA process with other healthcare identity
proofing (e.g. credentialing)– Policy issues regarding identity proofing
Out-of-Scope– Digital Credential Management– Digital Signatures– Proxy or Delegation
Deliverable: “Summary White Paper”– Assumptions– Statement of Problem– Recommended Solution(s)
• Review of Standards (e.g. NIST, FICAM)• Certification requirements for RAs• Proof of identity requirements for
– Entities– Individuals
• Allowed proofing processes (e.g. as part of credentialing?)
• Frequency of Identity review• Appeals process for denial• Variation based on specific
credentials/use?• Revocation (triggers and process)
– Identify gaps in current policy impacting Identity Proofing
– References
28
Sub WorkGroup: Digital Credentials
Type: Sub workgroup
Makeup– Leadership: – SMEs: – Community:
Goal– Define required process for issuing and managing
digital credentials for esMD
Requirements– NIST SP 800-63 Level 3 authentication (V 1.0.2)
2006– Federal Bridge Certification Authority (FBCA)
certified Medium Level– Digital Certificates must be X.509 V3 based– Must be from CA cross-certified with FB– Must provide for non-repudiation as part of the
credentials and artifacts
In-Scope– Digital credential life cycle– Relevant standards– Policy issues regarding Digital Credentials
Out-of-Scope– Identity Proofing– Digital Signatures
Deliverable: “Summary White Paper”– Assumptions– Statement of Problem
– Recommended Solution(s)• Review of standards (e.g. NIST, FBCA,
FICAM)• CA qualifications and list• Issuance process• Credential types and forms• Credential uses (Identity, Signing, Proxy,
Encryption, Data Integrity)• Specific use credentials (e.g. Direct,
DEA)• Maintenance requirements• Revocation process• Trust anchor validation• Non-repudiation assurance
– Identify gaps in current policy impacting Digital Credentials
– References29
Sub WorkGroup: Digital Signatures
Type: Sub workgroup
Makeup– Leadership: – SMEs:– Community:
Goal– Define process, artifacts and standards for
transaction and document bundle digital signatures for esMD
Requirements– Must provide for non-repudiation as part of the
credentials and artifacts– Must ensure data integrity
In-Scope– Use Case 1 and 2 transactions– AoR L1– Signature workflow– Signature artifacts– Identification of relevant standards
Out-of-Scope– AoR L2– AoR L3
Deliverable: “Summary White Paper”– Assumptions– Statement of Problem– Recommended Solution(s)
• Review of Standards (e.g. OASIS, IHE, HL7, …)
• Transaction signature process• Transaction artifacts to meet Use Case
1 and 2 requirements• Document Bundle signature process• Artifacts to meet AoR L1 requirements• Data Integrity requirements• Non-repudiation assurance
– References
30
Sub WorkGroup: Delegation and Proxy
Type: Sub workgroup
Makeup– Leadership: – SMEs:– Community:
Goal– Define credentials, artifacts and process for
Delegation of Rights for esMD
Requirements– Must provide for non-repudiation (NIST definition)
as part of the credentials and artifacts– Revocable
In-Scope– Use Case 1 and AoR L1 Delegation of Rights
requirements– Delegation/Proxy workflow– Delegation/Proxy artifacts– Identification of relevant standards
Out-of-Scope– AoR L2– AoR L3
Deliverable: “Summary White Paper”– Assumptions– Statement of Problem– Recommended Solution(s)
• Review of Standards (e.g. OASIS, IHE, HL7, …)
• Proxy/Delegation Credential/Artifact(s) • Operational consideration for
Proxy/Delegation Creation• Scope/Content of Proxy/Delegation• Revocation of Proxy• Credential Transaction proxy
requirements• Transaction artifacts to meet Use Case
1 requirements• Document Bundle proxy signature
process• Artifacts to meet AoR L1 signature
proxy requirements• Data Integrity requirements• Non-repudiation assurance
– References
31
Get Involved in the SWGs!
Subworkgroup Name Interested Parties / Volunteers as of 8/1
1 Identity Proofing Rachel Foerster, Raja Kailar, Les Keepper, Ernest Grove
2 Digital Credentials Rachel Foerster, Raja Kailar, Les Keepper, Ernest Grove
3 Signing Rachel Foerster, Raja Kailar, Les Keepper, Ernest Grove
4 Delegation and Proxy Rachel Foerster, Raja Kailar, Les Keepper, Ernest Grove
32
A Wiki page is now available to sign up for the SWGs. http://wiki.siframework.org/AoR+L1+Use+Case+-+Subworkgroups+Home+Page
SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY
1 2 3 4
*Timeline is subject to change
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
AoR Use Case Schedule and Timeline*Note – Weekly Meetings on Wednesdays and Fridays
33
Aug 2012
UC Meeting
UC Meeting
UC Meeting
Review HW items• Introduce Scenario
and User Story Write up
• Wiki Overview• Continue SWG
Charge discussion
UC Meeting
UC Meeting
UC Meeting
UC Meeting
HW items for 8/8• Review and
provide feedback on previous weeks discussion
HW items for 8/15• Review and
provide feedback on previous weeks discussion
HW items for 8/22• Review and
provide feedback on previous weeks discussion
HW items for 8/29• Review and
provide feedback on previous weeks discussion
UC MeetingReview HW items• Finalize User Story
and Workflow• SWG Meetings
discussions
Next Steps / Reminders
• Review User Story - http://wiki.siframework.org/AoR+UC+L1+-+User+Story
• Review Subworkgroup charge and sign up to participate in one or all 4– http://wiki.siframework.org/AoR+L1+Use+Case+-+
Subworkgroups+Home+Page
34