1 / 22

Electronic Submission of Medical Documentation (esMD)

Electronic Submission of Medical Documentation (esMD). Provider Profiles Authentication Workgroup. Agenda. Face-to-Face Meeting - April, 2012. Face to Face April meeting has been scheduled for April 11-13 th Location –Westin Alexandria 400 Courthouse Square Alexandria, Virginia

asher
Télécharger la présentation

Electronic Submission of Medical Documentation (esMD)

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. Electronic Submission of Medical Documentation (esMD) Provider Profiles Authentication Workgroup

  2. Agenda

  3. Face-to-Face Meeting - April, 2012 • Face to Face April meeting has been scheduled for April 11-13th • Location –Westin Alexandria • 400 Courthouse Square Alexandria, Virginia • Additional registration and logistics information will be emailed to all S&I participants via email • FYI - No phone or WebEx will be available during the Face to Face • Wiki Link - http://wiki.siframework.org/S%26I+2012+Face+to+Face+%28F2F%29+Meeting

  4. UC 1 Consensus Voting Open • PPA UC 1 is up for consensus as of Monday 3/5/12 and will close EOD next Monday 3/12/12. • Full Use Case is posted - http://wiki.siframework.org/PPA+Use+Case+1+-+Provider+Registration+with+Payer • Consensus voting page - http://wiki.siframework.org/esMD+PPA+Use+Case+Consensus+Form • The goal is unanimous consent, which is obtained by carefully considering and addressing significant input from the Community of Interest. Where unanimity is not possible, a group SHOULD strive to make consensus decisions where there is significant support and few abstentions. • Only one vote per organization will count towards total votes. Each Initiative Member will provide one of the following votes during the Consensus process: • Yes - A Yes vote does not necessarily mean that the deliverable is the ideal one from the perspective of the Initiative Member, but that it is better to move forward than to block the deliverable • Yes with comments - If a Consensus Process attracts significant comments (through Yes with comment votes), it is expected that the comments be addressed in a future revision of the deliverable. • Formal Objection- with comments indicating a path to address the objection in a way that meets the known concerns of other members of the Community of Interest. "Formal Objection" vote without such comments will be considered Abstain votes. • Abstain (decline to vote)

  5. Reminder CMS: Phase 1 and Phase 2 of esMD Phase 1: Paper Medical Documentation Request (MDR) Went live 9/15/11 electronic This is the portion our workgroup is currently working on Phase 2: electronic MDR Future release electronic 6

  6. esMD Provider Profiles Authentication Timeline July ‘12 Oct ‘12 Oct ‘11 Jan ‘12 April ‘12 Pre-Discovery Initiative Charter/Scope Today (3/7/12) Target Initiative Completion: Oct ‘12 11/30-12/7 Charter Consensus Kick-Off/ F2F PPA Workgroup Discovery Implementation Pilot Use Case #1 Goal: Consensus by 3/14 Outline Use Cases & Stories Harmonization/ Standards Analysis of Registration (Use Case #1) Use Case #1: Registration Harmonization/ Standards Analysis of UC #1 and #2 Use Case #2: Sending eMDR (Weds) Goal: Use Case #2 Consensus by 4/30 Combined Registration/ eMDR Pilots Structured Content WG Harmonization/ Standards Analysis of eMDR (Use Case #2) Associated with Use Case #2: Sending eMDR (Fri) 7

  7. PPA Purpose (Wednesday Focus) • The purpose of the PPA workgroup is to evaluate solutions to: • UC 1: Register providers with payers to receive electronic medical document requests (eMDR) –Consensus Voting Ongoing • UC 2: Send eMDRs from a payer or their contractor to a provider or their agent • These solutions will enable Payers/CMS Review Contractors to send electronic medical document requests (eMDR), as an alternative to current paper processes. • This effort culminates in the selection/creation of standards for message format and content to communicate with CMS and its Review Contractors that may be adopted by other segments of the payer community to simplify and automate communication between providers and payers with respect to requests for medical documentation.

  8. Structured Content merge with PPA UC 2 (Friday Focus) • The purpose of Structured Content WG was to define the requirements for the structure of the electronic Medical Documentation Request (eMDR) itself • Work related to Structured Content will now be incorporated into the development of PPA UC 2. • The focus of PPA UC 2 is around securely sending the eMDR from the payer/payer contractor to the provider • Structured Content Wiki page- http://wiki.siframework.org/esMD+-+Structured+Content

  9. esMD Use Case 1: Introduction to Harmonization 10

  10. esMD Initiative: Harmonization Process Harmonization for Use Case 1 may include the following steps: • Expand dataset requirements into a full data model • Reuse elements from PD Data Model and CEDD • Review and select standards identified by SDS • Choose standards based on use case, data model requirements, and community expertise • Map data model to select standards • Identify gaps and work with SDS to communicate needs with SDOs • Develop registration processes for CMS and commercial payers • Expand on Section 10 in Use Case 1 document to prepare detailed process guidance for Implementation Guide(s) • Develop Implementation Guide(s) for CMS and commercial payers • Guide should enable implementation of data model and registration request processes 11

  11. esMD Initiative: Harmonization Process In order to align Use Case 1 and Use Case 2 to the same standards, we will focus on steps 1 and 4 while Use Case 2 is under development. We will continue with steps 2, 3, and 5 when Use Case 2 is complete. • Expand dataset requirements into a full data model • Reuse elements from PD Data Model and CEDD • Review and select standards identified by SDS • Choose standards based on use case and data model requirements and community expertise • Map data model to select standards • Identify gaps and work with SDS to communicate needs with SDOs • Develop registration processes for CMS and commercial payers • Expand on Section 10 in Use Case 1 document to prepare detailed process guidance for Implementation Guide(s) • Develop Implementation Guide(s) for CMS and commercial payers • Guide should enable implementation of data model and registration request processes 12

  12. esMD Initiative Notional Timeline Sept 2012 Aug 2012 Oct 2011 Nov 2011 Dec 2011 Jan 2012 Feb 2012 Mar 2012 Apr 2012 May 2012 Jun 2012 Jul 2012 Oct 2012 PPA Workgroup PPA Use Case 1 Development Outline Use Cases and Stories Harmonization Phase PPA Use Case 2 Development Structured Content Development Combined Harmonization of PPA Use Case 1, Use Case 2, and Structured Content Initial Harmonization of PPA Use Case 1 Combined Registration and eMDR Pilot

  13. Meeting schedules • Use Case 2 Development will take place concurrently with the initial phase of Use Case 1 Harmonization. • Use Case 2 Development • Wednesdays, 1:30 – 3:00 PM EST • Fridays, 2:00 – 3:00 PM EST • Use Case 1 Harmonization • Support team will identify new meeting time • Meetings will begin week of March 12th 14

  14. General Approach to Structured Content • We have two broad approaches for Use Case 2 and Structured Content • Design Structured Content of the eMDR with the goal of including it as part of a transaction where the individual elements are specifically defined. • Examples: Most X12N, IHE and HL7 messages • Work with the assumption that the eMDR is an object or metadata structure (like the CDA/CCD) and the transaction/messaging standard manages the identification, routing, and security, but is otherwise content neutral. • Examples: IHE XDS, Direct, HL7 MDM, …

  15. Next Steps / Questions • Next Steps • Continue Use Case 2 Development during regularly scheduled times • Identify new meeting time for Use Case 1 Harmonization starting week of March 12th • Next Work Group Meeting • Use Case 1 Consensus/Use Case 2 Development - Friday, March 9th 2:00pm - 3:00pm • For questions, please feel free to contact esMD support leads • Sam Elias (IC); sam.elias@sghealthit.com • Emily Mitchell (Use Case); emily.d.mitchell@accenture.com • Presha Patel (Use Case); presha.patel@accenture.com • William Ryan (Harmonization); wiryan@deloitte.com • Shay Paintal (Harmonization); spaintal@deloitte.com • Sweta Ladwa (Overall); sweta.ladwa@esacinc.com 16

  16. Kick off PPA UC 2Use Case Context Diagrams

  17. PPA Use Case Context Diagram – Information Exchange Paths – Generic External Provider Directories Registration Requestor (Provider / Provider Organization) Payer Contractors / Intermediaries Gateway Agent / Access Payer Internal System Access

  18. PPA Use Case Context Diagram – CMSSecure MDR transmission from Contractors External Provider Directories In to Contractor Out from Contractor Out to Provider 3. Sends request to retrieve updated ESI information 4. Receives updated ESI Information 1. Sends request for provider registration status Registration Requestor (Provider / Provider Organization) Contractors / Intermediaries CMS esMD Gateway 2. Receives validation of registration status HIH Payer Internal System Connect 5. Electronic medical documentation request (eMDR) sent securely to Provider or HIH as needed * Key : ESI – Electronic Services Information PD – Provider Directory HIH – Health Information Handler CMS - Medicare

  19. PPA Use Case Context Diagram – Secure eMDR transmission from Commercial Payer via Contractor External Provider Directories In to Contractor Out from Contractor Out to Provider 3. Sends request to retrieve updated ESI information 4. Receives updated ESI Information 1. Sends request for provider registration status Registration Requestor (Provider / Provider Organization) Contractors / Intermediaries Commercial Payer Gateway 2. Receives validation of registration status Agent Payer Internal System Connect 5. Electronic medical documentation request (eMDR) sent securely to Provider or Agent as needed * Key : ESI – Electronic Services Information

  20. PPA Use Case Context Diagram – Secure eMDR transmission from Commercial Payer External Provider Directories 1. Sends request to retrieve updated ESI information Out to Provider 2. Receives updated ESI Information Registration Requestor (Provider / Provider Organization) Commercial Payer Gateway Agent Payer Internal System Connect 3. Electronic medical documentation request (eMDR) sent securely to Provider or Agent as needed * Key : ESI – Electronic Services Information

  21. Volunteers to draft the following • Assumptions • BM • Mahbulbul • Pre Conditions • BM • Mahbulbul • Post conditions • BM • Mahbulbul

More Related