1 / 28

esMD Author of Record L1 Use Case Meeting

esMD Author of Record L1 Use Case Meeting. Friday, July 27, 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.

woods
Download Presentation

esMD Author of Record L1 Use Case Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. esMD Author of Record L1Use Case Meeting Friday, July 27, 2012

  2. 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 • 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

  3. Use Case Overview Agenda

  4. 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

  5. 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

  6. Scope AoR (L1) 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) • In Scope • Identity Proofing as part of Non-Repudiation of Actor Identity • Digital Credential Management required for Non-Repudiation Actions (Signingand 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

  7. 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. • Actors and Roles - http://wiki.siframework.org/AoR+L1+-+Actors+and+Roles • Communities of interest table - http://wiki.siframework.org/AoR+L1+-+Communities+of+Interest • User Story - http://wiki.siframework.org/AoR+UC+L1+-+User+Story • Glossary - http://wiki.siframework.org/AoR+L1+Use+Case+-+Glossary+of+Terms

  8. User Story / Workflow • Need Volunteers to draft a first pass for the following by next Wednesday 8/1 • Overall User Story Components • Need Volunteer - All Actors obtain and maintain a non-repudiation digital identity • Keith Salzman- Provider registers for esMD (see UC1)* • Need Volunteer - Payer requests documentation (see UC2)* • Reed Gelzer - Provider submits digitally signed document (bundle) to address request by payer • 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)

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

  10. 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.

  11. Draft Assumptions Federal Bridge and NIST specifications for Level 3 identity assurance are available. Registrations Authority models (RA) and registration authority processes exist for Level 3 identity proofing Certificate Authorities (CA) exist and are capable of providing the necessary digital credentials for signing, encryption and other services required by this Use Case. Technology exists to utilize the digital credentials for signing and encryption of documents and transactions Provider registration process as defined in Use case 1 and AoR L1 require support for proxy or delegation of rights 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 Payer, Payer Contractors and Payer Gateway shall be treated as the Payer Entity A Provider, Group of Providers, Agent, and Hospital/Health Systems shall be treated as Provider Entity The signature on a bundle attests that the information submitted is an appropriate, complete (except as noted) and accurate response to the information requested All entities involved in AoR L1 transactions will maintain appropriate audit logs

  12. Draft Assumptions Cont. • The below items are all from UC 1 and 2 • All actors shall create all transactions utilizing industry accepted standards, where available • All actors shall ensure all transactions will have appropriate security to ensure data is transmitted with integrity, confidentiality, and reliability • All actors and systems shall ensure all transactions will be delivered in a timely manner • All actors shall have signed any required participation or data use agreements • Others??

  13. 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.

  14. Draft Pre Conditions (In process) Payer Entity has the ability to register Provider Entitles for the esMD service, produce and electronically transmit the eMDR to the Provider Entity 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. 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 2 Provider Entity and Payer Entity shall have completed any required onboarding processes. Provider Entity systems shall maintain the ability to receive eMDRs after successful registration unless terminated through established mechanisms Others???

  15. 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.

  16. Draft Post Conditions (In process) Post submission credential and signature artifact processing required by the transmission standard Payer Entity information system process the Document Bundle Others???

  17. AoR Use Case Schedule and Timeline*Note – Weekly Meetings on Wednesdays and Fridays • Use Case Kick Off • UC Overview • Context Diagrams • Areas to Address • In-Scope/Out-of-Scope • Introduce SWG • 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 7/24 Review and provide feedback on 7/20 discussion July 2012 HW items for 8/1 Review and provide feedback on 7/25 & 7/27 discussions 17

  18. AoR Use Case Schedule and Timeline*Note – Weekly Meetings on Wednesdays and Fridays UC Meeting • Review HW items • Cont. User Story • Assumptions Cont. • Pre Conditions Cont. • Post Conditions Cont. • SWG Charge discussion Aug 2012 UC Meeting UC Meeting HW items for 8/8 Review and provide feedback on previous weeks discussion UC Meeting UC Meeting HW items for 8/15 Review and provide feedback on previous weeks discussion UC Meeting UC Meeting HW items for 8/22 Review and provide feedback on previous weeks discussion UC Meeting HW items for 8/29 Review and provide feedback on previous weeks discussion

  19. 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

  20. AoR Subworkgroup Discussion Dan Kalwa & Bob Dieterle

  21. Areas to Address *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.

  22. User Story Components / Workflow / Sub-workgroups (4) Note - Sub-workgroup leaders & meeting schedule is TBD at this time

  23. User Story -- Additional Components / Workflow

  24. Sub WorkGroup: Identity Proofing 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 • 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

  25. Sub WorkGroup: 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 • 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

  26. Sub WorkGroup: Digital Signatures 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 • 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

  27. Sub WorkGroup: Delegation and Proxy 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 • 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

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

More Related