esMD Author of Record L1 Use Case Meeting Wednesday, 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 AgendaPresenterTime Frame General Meeting Recap (7/27) and Today’s tasks Sweta Ladwa1:30 – 1:35 AoR Use Case Review Scenario and User Story Write up Presha Patel1: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 Patel2:05 – 2:20 Discuss detailed Sub workgroup proposed structure and charge Bob Dieterle Dan Kalwa2: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 Scenario 1, 2, x… 10.1 User Story 1, 2, x, … 10.2 Activity Diagram Base Flow Alternate Flow 10.3 Functional Requirements Information Interchange Requirements 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 - 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 CA 4.CA generates and issues the credentials and sends notice to Actor 5.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 2 Materials > Use Case(s) > UC 1 (or UC 2) 19

What will you find on the Use Case Pages Materials > Use Case(s) > UC 1 (or UC 2) 20 Links to full Use Case Charter Links to Use Case Sections Links to full Use Case Charter Links to Use Case Sections

Materials >Meeting Artifacts 21 Meeting Materials, Agenda, Recordings for all esMD workgroups

Author of Record L1 Use Case 22 All Works in Progress for the current Use Case + Relevant Use Case announcements

Content available on Wiki from previous meetings o Assumptions, Pre and Post Conditions - +Assumptions%2C+Pre+and+Post+Conditionshttp://wiki.siframework.org/AoR+UC+L1+- +Assumptions%2C+Pre+and+Post+Conditions o Actors and Roles - o Communities of interest table - o User Story - o Glossary - o In Scope and Out of Scope Items - Scope+and+Out+of+Scopehttp://wiki.siframework.org/AoR+Use+Case+L1+-+In- Scope+and+Out+of+Scope o Use Case Context Diagram

AoR Subworkgroup Discussion Dan Kalwa & Bob Dieterle 24

Areas to Address Use Case TopicUC1: RegistrationUC2: eMDRAoR L1 Bundle Identity Proofing Required Digital Identity Management Required Digital Signatures & Signature Artifacts Required Delegation of Rights RequiredNot RequiredOptional PHI Encryption Not ApplicableRequiredTBD Other Topics Characteristics of solution Non-Repudiation* Required Characteristics of solution Data Integrity** Required Provider Directories 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 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 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 –References 29

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 NameInterested Parties / Volunteers as of 8/1 1Identity ProofingRachel Foerster, Raja Kailar, Les Keepper, Ernest Grove 2Digital CredentialsRachel Foerster, Raja Kailar, Les Keepper, Ernest Grove 3SigningRachel Foerster, Raja Kailar, Les Keepper, Ernest Grove 4Delegation and ProxyRachel Foerster, Raja Kailar, Les Keepper, Ernest Grove 32 A Wiki page is now available to sign up for the SWGs.

SUNDAYMONDAYTUESDAYWEDNESDAYTHURSDAYFRIDAYSATURDAY 1234 *Timeline is subject to change AoR Use Case Schedule and Timeline* Note – Weekly Meetings on Wednesdays and Fridays 33 Aug 2012 UC Meeting Review HW items Introduce Scenario and User Story Write up Wiki Overview Continue SWG Charge discussion 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 Meeting Review HW items Finalize User Story and Workflow SWG Meetings discussions

Next Steps / Reminders Review User Story - +User+Storyhttp://wiki.siframework.org/AoR+UC+L1+- +User+Story Review Subworkgroup charge and sign up to participate in one or all 4 – +Subworkgroups+Home+Pagehttp://wiki.siframework.org/AoR+L1+Use+Case+- +Subworkgroups+Home+Page 34