Download presentation
Presentation is loading. Please wait.
Published byJared Barnett Modified over 9 years ago
1
Submit Quality Measures Sender Onboarding 1 Michigan Health Information Network Shared Services Marty Woodruff – Director, Production and Operations Megan Herbst – Onboarding Coordinator Lindsey Weeks – Onboarding Coordinator Copyright© 2015 - Michigan Health Information Network Shared Services
2
Agenda Scope Information Prerequisites Submitting Quality Measures Onboarding Steps Onboarding Process Meaningful Use: Quality Measures Overview Currently Supported Quality Measures Currently Supported Quality Formats QRDA Category 1 Files QRDA Category 3 Files Transport Options Direct REST API Requirements For Go-Live Summary and Next Steps Additional Resources 2 Copyright© 2015 - Michigan Health Information Network Shared Services
3
Scope Information Clinical Quality Measures (CQMs): measures of quality generated in clinical settings by using clinically-gathered information such as lab results, vital signs, etc. Clinical Quality Measurement Recovery and Repository (CQMRR) service: enables providers to submit, view, analyze, and act upon electronic CQMs for: Medicaid / Meaningful Use attestation Non-Medicaid providers wishing to take advantage of electronic CQMs for Clinical Quality Improvement Copyright 2015 - Michigan Health Information Network 3
4
Prerequisites Participating organizations should begin two parallel onboarding tracks simultaneously: Legal: Obtain, review, and execute legal agreements Technical: Establish technical transport and test Legal agreements for first-time onboarding consist of a Trusted Data Sharing Organization Agreement and the first Use Case Agreement Data Sharing Agreements: http://mihin.org/about-mihin/resources/mihin- legal-document-templates/Data Sharing Agreements: http://mihin.org/about-mihin/resources/mihin- legal-document-templates/ NOTE: The type of Data Sharing Agreement will depend on the specific relationship you are seeking with MiHIN. For help picking the correct legal document and to initiate legal onboarding, contact legal@mihin.org legal@mihin.org Exchange-Access Clinical Quality Measures Use Case Agreement: http://mihin.org/wp-content/uploads/2013/07/MIHIN-UCA-Exchange- Access-Clinical-Quality-Measures-PUBLISHED-v12-09-30-15.docx http://mihin.org/wp-content/uploads/2013/07/MIHIN-UCA-Exchange- Access-Clinical-Quality-Measures-PUBLISHED-v12-09-30-15.docx For onboarding additional Use Cases after the first, only a new Use Case Agreement is required 4 Copyright© 2015 - Michigan Health Information Network Shared Services
5
VPN/REST API Convert to Desired Format Copyright 2015 Michigan Health Information Network Shared Services 5 Submitting Quality Measures MIDIGATE ® “Catch, Detach, Dispatch” inbox@direct.mihin.org Trusted Data Sharing Organization Validate Store Quality Check Quality Score Validate Sender NPI Senders Eligible/Critical Access Hospitals Eligible Providers Patients Reporting Layer Reports, Dashboards, Comparisons, Mining Medicaid Data Warehouse Quality Portals Quality Data Mart Health Provider Directory REST API Direct Secure Message
6
Onboarding Steps Express interest in onboarding Use Case Kick-off meeting Exchange contact information Distribute Use Case Summary and other information Present onboarding overview Legal onboarding: receive, review, and execute legal documents Trusted Data Sharing Organization Agreement Use Case Agreement(s) Technical onboarding: exchange required technical documents (can occur simultaneously with legal onboarding) Use Case Implementation Guide Establish transport method/connectivity (e.g. via Direct or VPN) Test transport Test submission mechanism Verify data quality Legal document check – confirm documents are fully executed Go live into production 6 Copyright© 2015 - Michigan Health Information Network Shared Services
7
Onboarding Process 7 Copyright© 2015 - Michigan Health Information Network Shared Services
8
Meaningful Use: Quality Measures Submit Quality Measures Use Case supports 2013 release of Meaningful Use (MU) measures: Eligible Professionals must submit at least 9 of 64 provider measures Eligible Hospitals and Critical Access Hospitals must submit at least 16 of 29 hospital measures All submitters must submit measures from at least 3 of 6 quality measure domains Participation in this Use Case will result in MU credit Copyright 2015 - Michigan Health Information Network 8
9
Currently Supported Quality Measures 9 Description Meaningful Use Clinical Quality Measures, 2013 release Purpose Clinical quality measures, or CQMs, are tools that help measure and track the quality of health care services provided by eligible professionals, eligible hospitals and critical access hospitals (CAHs) within our health care system. Hospital Measures 29 Measures Provider Measures 64 Measures Source Link http://www.cms.gov/Regulations-and- Guidance/Legislation/EHRIncentivePrograms/ClinicalQualityMeasures.html Other Requirements Copyright© 2015 - Michigan Health Information Network Shared Services
10
Currently Supported Quality Formats 10 Description Clinical Quality Measures Purpose To establish quality metrics of health care providers HL7 Standard C-CDA QRDA Category 1 files, C-CDA QRDA Category 3 files Transport Method REST API via Virtual Private Network (VPN) Direct Secure Messaging (DSM) HISP must be EHNAC-DTAAP accredited by February 2015 Implementation Guide http://mihin.org/about-mihin/resources/use-cases-in-production/ Other Requirements National Provider Identifier (NPI) must be listed Copyright© 2015 - Michigan Health Information Network Shared Services
11
QRDA Category 1 Files 11 Description Individual patient level data for one or more measures This format qualifies for Meaningful Use clinical quality measure requirements Purpose These measures have not been calculated by measure criteria HL7 Standard C-CDA QRDA Category 1 Files Transport Method REST API via Virtual Private Network (VPN) Direct Secure Messaging (DSM) HISP must be EHNAC-DTAAP accredited Implementation Guide http://mihin.org/about-mihin/resources/use-cases-in-production/ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=35 Other Requirements National Provider Identifier (NPI) must be listed Copyright© 2015 - Michigan Health Information Network Shared Services
12
QRDA Category 3 Files 12 Description Aggregate population level data for one or more measures This format qualifies for Meaningful Use clinical quality measure requirements Purpose These measures have been calculated by measure criteria HL7 Standard C-CDA QRDA Category 3 Files Transport Method REST API via Virtual Private Network (VPN) Direct Secure Messaging (DSM) HISP must be EHNAC-DTAAP accredited by February 2015 Implementation Guide http://mihin.org/about-mihin/resources/use-cases-in-production/ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=286 Other Requirements National Provider Identifier (NPI) must be listed Copyright© 2015 - Michigan Health Information Network Shared Services
13
Establishing Transport and Testing: Transport Option 1 - Direct MiHIN requires exchange of non-production messages to confirm connectivity prior to Go-Live Sender attaches QRDA file(s) to Direct Secure Message and sends to MIDIGATE™ inbox at MiHIN (e.g. cat1@direct.mihin.org) Sender’s Direct Secure Messaging (DSM) HISP must be EHNAC-DTAAP accredited (DirectTrust)Direct Secure MessagingHISP EHNAC-DTAAP If sender does not have compliant Direct account, MiHIN can provide Direct accounts for small annual fee (help@mihin.org)help@mihin.org MiHIN performs validations and transformations on XML document received from sender (specific to given collection, case insensitive) MiHIN sends acknowledgement to Direct message senders (eventually including content scoring) 13 Copyright© 2015 - Michigan Health Information Network Shared Services
14
Establishing Transport and Testing: Transport Option 2 - REST API MiHIN requires exchange of non-production messages to confirm connectivity prior to Go-Live Sender transmits QRDA file to MiHIN via REST API Every request must declare content type to be application/xml and must be authenticated MiHIN performs validations and transformations on XML document received from sender (specific to given collection, case insensitive) An HTTP 200 OK response means message has been accepted into system Response will have JSON body that contains validation errors, if any, along with additional metadata See API Guide for more information 14 Copyright© 2015 - Michigan Health Information Network Shared Services
15
Sample Acknowledgement Message Copyright 2015 - Michigan Health Information Network 15 Subject: MiHIN MIDIGATE ACK {“score”:80,“validation”:[{“name”:“cda-2014”,“weight”:20,“errors”:”},{“name”:“schematron-2014”,“weight”:60, “errors”,”},{“name”:“dynamic-npi-check”,“weight”:20,“errors”:“Invalid npi: FakeNPI”}],“trackingId”: “55d33e1a128302563e7c80d8”} Attachments:
16
Requirements For Go-Live Test transport (Direct or REST) Finalize required documentation Execute legal documents Complete transport document Coordinate “go-live” production schedule Go-live should be scheduled a minimum of one week in advance of requested date Schedule via “help@mihin.org” 16 Copyright© 2015 - Michigan Health Information Network Shared Services
17
Summary and Next Steps 17 TaskMiHIN Trusted Data Sharing Organization (TDSO) Determine date/time for next check point XX Exchange and execute legal agreements XX Send “care package” X Send completed transport document X Establish connectivity X Coordinate testing X Go-Live XX Copyright© 2015 - Michigan Health Information Network Shared Services
18
Additional Resources For all support issues: help@mihin.org For more information: www.mihin.org Contact information: 18 Marty WoodruffLindsey WeeksMegan Herbst Director, Prod/OPSOnboarding Coordinator Marty.woodruff@mihin.orgLindsey.weeks@mihin.orgMegan.herbst@mihin.org 517-937-2088517-588-8373586-549-1674 Copyright© 2015 - Michigan Health Information Network Shared Services
19
Production Support Severity 1Severity 2Severity 3Severity 4 Description Critical Impact/System Down: Business critical software is down or critical interface has failed. The issue is impacting all production systems, causing all QO’s or other organization’s ability to function to be unusable. Significant Business Impact: Software component severely restricted. Entire organization is unable to continue business functions, causing all communications and transfer of messages to be halted. Partial Failure or Downtime: Program is usable and less significant features unavailable. The service is online, though may not be working as intended or may not currently be working as intended or may not currently be accessible, though other systems are currently available. Minimal Business: A non-critical software component is malfunctioning, causing minimal impact, or a test system is down. Example Example: All messages to and from MiHIN are unable to be sent AND received, let alone tracked. Example: MiHIN cannot communicate (send or receive) messages between single or multiple QOs, but can still successfully communicate with other organizations. Example: Messages are lost in transit, messages can be received but NOT transmitted Example: Additional feature requested Initiation Method Phone (517)336-1430 & Email to help@mihin.org Help Desk- help@mihin.org Initial Response Within 2 hours 1 business day Resolution Goal 24 hours 3 business days7 business days Copyright© 2015 - Michigan Health Information Network Shared Services
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.