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