1 / 34

esMD Author of Record L1 Use Case Meeting

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.

ganesa
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 Wednesday, August 1, 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 • 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

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

  6. Use Case Outline – Where are we?Note- This is tailored for each Initiative • 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 • 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 Completed initial review of highlighted sections 1-9

  7. Scenario and User Story

  8. Scenario and User Story • 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 - 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.

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

  10. User Story / Workflow Components • Overall User Story Components • All Actors obtain and maintain a non-repudiation digital identity • Provider registers for esMD (see UC1)* • Payer requests documentation (see UC2)* • Provider submits digitally signed document (bundle) to address request by payer • 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)

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

  12. User Story Components & Write up

  13. User Story Components & Write up (Cont.)

  14. User Story Components & Write up (Cont.)

  15. User Story Components & Write up (Cont.)

  16. User Story Components & Write up (Cont.)

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

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

  19. esMD Use Cases 1 and 2Materials > Use Case(s) > UC 1 (or UC 2)

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

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

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

  23. Content available on Wiki from previous meetings • Assumptions, Pre and Post Conditions -http://wiki.siframework.org/AoR+UC+L1+-+Assumptions%2C+Pre+and+Post+Conditions • 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 • In Scope and Out of Scope Items - http://wiki.siframework.org/AoR+Use+Case+L1+-+In-Scope+and+Out+of+Scope • Use Case Context Diagram - http://wiki.siframework.org/AoR+Use+Case+Context+Diagram

  24. AoR Subworkgroup Discussion Dan Kalwa & Bob Dieterle

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

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

  27. User Story -- Additional Components / Workflow

  28. 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) • Identify gaps in current policy impacting Identity Proofing • 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

  29. 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 • Identify gaps in current policy impacting Digital Credentials • 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

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

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

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

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

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

More Related