esMD Author of Record L1Use Case Meeting

Friday, July 27, 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/25) and Today’s tasks Presha Patel 2:00 – 2:05

AoR Use Case • Review feedback on sections reviewed to

date• Introduce next few sections

Presha Patel 2:05 – 2:30

• Next Steps for Use Case sections Presha Patel 2:30 – 2:35

• Discuss detailed Sub workgroup proposed structure and charge

Bob Dieterle Dan Kalwa 2:35 – 3:00

3

Recap of the Last Meeting• Made updates to the Context Diagrams and the In-Scope and Out-

of-Scope items • Introduced the draft User Story, Actors and Roles, Communities of

Interest, and Glossary of Terms• All items are available to review and posted on the Wiki

• Reviewed the preliminary scope for the Sub-workgroups introduced last week

4

Today’s Objectives• Review any community feedback from the homework items from last

meeting• Actors and Roles• Communities of Interest • Glossary of Terms• User Story

• Introduce Assumption, Pre Conditions and Post Conditions• Begin discussions for the charge and deliverables for each Sub-

workgroups introduced during the last call

5

Scope AoR (L1)In Scope

• Identity Proofing as part of Non-Repudiation of Actor Identity

• Digital Credential Management required for Non-Repudiation Actions (Signing and Delegation), Data Integrity and Encryption

• Digital Signatures and Signature Artifacts for Identity and Non-Repudiation

• Digital Credentials and Artifacts for Non-Repudiation of Delegation as required by UC1 and AoR L1

• Data Integrity requirement actions and artifacts• Encryption of PHI requirements• Interactions between Provider Entity or Payer

Entity and :• Certificate Authority• Registration Authority• External Provider Directory• And each other

Out of Scope• Interactions between:

• Payer and its Payer Contractors• Provider and its Agent• Payer or Payer Contractor and its Gateway

• Transaction level encryption• Document level signatures and individual

contribution signatures (AoR Levels 2,3)• Defining delegation of rights within and between

Providers and other authors (AoR Levels 2,3)

6

Content available on Wiki from 7/25 Mtg.

Introduced Actors and Roles, Communities of Interest table, User Story and Glossary of Terms on 7/25.  Please review and provide feedback by Tuesday 7/31 at 12 noon ET.

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

7

User Story / Workflow Need Volunteers to draft a first pass for the following by next Wednesday 8/1

Overall User Story Components1) Need Volunteer - All Actors obtain and maintain a non-repudiation digital identity2) Keith Salzman- Provider registers for esMD (see UC1)*3) Need Volunteer - Payer requests documentation (see UC2)*4) Reed Gelzer - Provider submits digitally signed document (bundle) to address

request by payer5) Need Volunteer - Payer validates submission artifacts

*User Stories for esMD UC 1 and 2 have already been defined. Workgroup will help further define bullets 1), 4), and 5)

8

Introductions to the next few Use Case Sections • Draft Assumptions• Draft Pre-Conditions• Draft Post-Conditions

9

Assumptions

Section Description – • The Use Case Assumptions section outlines what needs to be in

place to meet or realize the requirements of the Use Case• These points are more functional in nature and state the broad

overarching concepts related to the Initiative. • The Use Case assumptions will serve as a starting point for

subsequent harmonization activities.

10

Draft Assumptions1. Federal Bridge and NIST specifications for Level 3 identity assurance are available.2. Registrations Authority models (RA) and registration authority processes exist for Level

3 identity proofing 3. Certificate Authorities (CA) exist and are capable of providing the necessary digital

credentials for signing, encryption and other services required by this Use Case.4. Technology exists to utilize the digital credentials for signing and encryption of

documents and transactions5. Provider registration process as defined in Use case 1 and AoR L1 require support for

proxy or delegation of rights6. The RA process, CA process, and digital credentials in combination with the signing and

encryption process provide all of the necessary information and security context for non-repudiation of the signer and integrity of the Document Bundle

7. Payer, Payer Contractors and Payer Gateway shall be treated as the Payer Entity8. A Provider, Group of Providers, Agent, and Hospital/Health Systems shall be treated as

Provider Entity 9. The signature on a bundle attests that the information submitted is an appropriate,

complete (except as noted) and accurate response to the information requested10.All entities involved in AoR L1 transactions will maintain appropriate audit logs

11

Draft Assumptions Cont.The below items are all from UC 1 and 2

9. All actors shall create all transactions utilizing industry accepted standards, where available

10.All actors shall ensure all transactions will have appropriate security to ensure data is transmitted with integrity, confidentiality, and reliability

11. All actors and systems shall ensure all transactions will be delivered in a timely manner

12.All actors shall have signed any required participation or data use agreements

Others??

12

Pre Conditions

Section Description: • The Pre-Conditions section describes the state of the system, from

a technical perspective, that must be true before an operation, process, activity or task can be executed.

• It lists what needs to be in place before executing the information exchange as described by the Functional Requirements and Dataset requirements.

13

Draft Pre Conditions (In process)1. Payer Entity has the ability to register Provider Entitles for the esMD service, produce

and electronically transmit the eMDR to the Provider Entity2. Provider Entity has the ability to assemble and electronically transmit the required

documentation to the Payer Entity in the required format to the required destination.3. Provider Entity has the required identity materials to qualify for (be identity proofed),

receive, and maintain the electronic signing credentials.

The below items are all from UC 1 and 24. Provider Entity and Payer Entity shall have completed any required onboarding

processes.5. Provider Entity systems shall maintain the ability to receive eMDRs after successful

registration unless terminated through established mechanisms

Others???

14

Post Conditions

Section Description: • The Post Conditions section describes the state of the system, from

a technical perspective, that will result after the execution of the operation, process activity or task.

15

Draft Post Conditions (In process)1. Post submission credential and signature artifact processing required by the

transmission standard2. Payer Entity information system process the Document Bundle

Others???

16

SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY

1 2 3 4 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

*Schedule and Timeline is subject to change

AoR Use Case Schedule and Timeline*Note – Weekly Meetings on Wednesdays and Fridays

July 2012

Use Case Kick Off• UC Overview• Context Diagrams• Areas to Address• In-Scope/Out-of-Scope• Introduce SWG

17

HW items for 7/24Review and provide feedback on 7/20 discussion

• Review HW items• Glossary of Terms• Communities of

Interest• Actors & Roles• User Story

• Review 7/25 items• Assumptions• Pre Conditions• Post Conditions• Discuss detailed

charge of each SWG

HW items for 8/1Review and provide feedback on 7/25 & 7/27 discussions

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

18

Aug 2012UC Meeting

UC Meeting

UC Meeting

Review HW items• Cont. User Story• Assumptions Cont.• Pre Conditions Cont.• Post Conditions Cont.• SWG Charge discussion

UC Meeting

UC Meeting

UC Meeting

UC Meeting

HW items for 8/8Review and provide feedback on previous weeks discussion

HW items for 8/15Review and provide feedback on previous weeks discussion

HW items for 8/22Review and provide feedback on previous weeks discussion

HW items for 8/29Review and provide feedback on previous weeks discussion

UC Meeting

Next Steps / Reminders

• Need Volunteers to draft a first pass for the User Story by next Wednesday 8/1

• Need Volunteers to review and propose additions and/or revisions to Assumptions, Pre and Post Conditions

• Review Subworkgroup tasks and charge for additional discussion next week. Please sign up to participate in the SWGs!– http://wiki.siframework.org/AoR+L1+Use+Case+-+

Subworkgroups+Home+Page

19

AoR Subworkgroup DiscussionDan Kalwa & Bob Dieterle

20

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

21

*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

22

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

23

Sub WorkGroup: Identity ProofingType: Sub workgroupMakeup

– Leadership: – SMEs:– Community:

Goal– Define required process for identity proofing of

healthcare individuals and organizations for esMDRequirements

– 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)

– References

24

Sub WorkGroup: Digital CredentialsType: Sub workgroupMakeup

– Leadership: – SMEs: – Community:

Goal– Define required process for issuing and managing

digital credentials for esMDRequirements

– 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 artifactsIn-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

– References

25

Sub WorkGroup: Digital SignaturesType: Sub workgroupMakeup

– 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

26

Sub WorkGroup: Delegation and ProxyType: Sub workgroupMakeup

– Leadership: – SMEs:– Community:

Goal– Define credentials, artifacts and process for

Delegation of Rights for esMDRequirements

– Must provide for non-repudiation (NIST definition) as part of the credentials and artifacts

– RevocableIn-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

27

Get Involved in the SWGs!

Subworkgroup Name Interested Parties / Volunteers

1 Identity Proofing

2 Digital Credentials

3 Signing

4 Delegation and Proxy

28

A Wiki page is now available to sign up for the SWGs. http://wiki.siframework.org/AoR+L1+Use+Case+-+Subworkgroups+Home+Page