ANSI Antitrust Policy ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification.

ANSI Antitrust Policy ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification bodies under programs requiring adherence to principles of openness, voluntariness, due process and non-discrimination. ANSI, therefore, brings significant, procompetitive benefits to the standards and conformity assessment community. ANSI nevertheless recognizes that it must not be a vehicle for individuals or organizations to reach unlawful agreements regarding prices, terms of sale, customers, or markets or engage in other aspects of anti-competitive behavior. ANSI’s policy, therefore, is to take all appropriate measures to comply with U.S. antitrust laws and foreign competition laws and ANSI expects the same from its members and volunteers when acting on behalf of ANSI. Approved by the ANSI Board of Directors May 22, 2014 Note: always clear/include antitrust statement in a public meeting.

Pre-Collaboration / Controlled Chaos:
Project Challenge To ensure the success of the industry’s shift to Value Based Care Pre-Collaboration / Controlled Chaos: Develop rapid multi-stakeholder process to identify, exercise and implement initial use cases. Da Vinci simply is an group of industry payers, providers and HIT partners that understand how critical it is to develop common, ideally eventual standard ways for providers and payers to exchange the critical data required for value base case to work. Collaboration: Minimize the development and deployment of unique solutions. Promote industry wide standards and adoption. Success Measures: Use of FHIR®, implementation guides and pilot projects.

Empower End Users to Shift to Value
As a private industry project under HL7 International, Da Vinci will unleash critical data between payers and providers required for VBC workflows leveraging HL7® FHIR® So this is a journey, not immediate change, increasingly providers and the extended care team must have access while caring for a patient, as triggers or integrated in their workflows. While the shift from Fee for Service to paying based on outcomes is a giant shift in US healthcare, this is not a US centric problem. We believe FHIR is best option at this time to get providers across this chasm. Source: © 2018 Health Catalyst

Focus In Less Than Two Years, Da Vinci Efforts Will Drive Standards for the Exchange of Information Critical to Patient Care Prior Auth and Documentation Requirements Payer Clinical Data Exchange Gaps in Care Attribution (Patient Panel) Medical Records for Value-Based Care Payers Providers Quality Measure Reporting Encounter Notifications

HL7 Da Vinci Project: An Overview
To ensure the success of the industry’s shift to Value Based Care, Da Vinci established a rapid multi-stakeholder process to identify, exercise and implement initial use cases between payers and provider organizations. The objective is to minimize the development and deployment of unique solutions with focus on reference architectures that will promote industry wide standards and adoption. Project Process Define requirements (clinical, business, technical and testing Create Implementation Guide (IG) Create and test Reference Implementation (RI) (prove the IG works) Pilot the solution Deploy the Solution Provider Members: Dallas Children's Health, MultiCare, OHSU, Providence St. Joseph Health, Rush University Medical Center, Sutter Health, Texas Health Resources, Weil Cornel Medicine Payer Members: Anthem, BCBSA, BCBSAL, BCBSM, BCBST, BC Idaho, Cambia Health, Cigna, GuideWell, HCSC, Humana, Independence, United Healthcare Da Vinci simply is an group of industry payers, providers and HIT partners that understand how critical it is to develop common, ideally eventual standard ways for providers and payers to exchange the critical data required for value base case to work. Vendor Members: Allscripts, Athenahealth/Virence(aka GE Centricity), Casenet, Cerner, Cognosante, Edifecs, Epic, HealthLX, InterSystems, Juxly, Optum, InterSystems, Surescripts, ZeOmega

2019 MEMBERSHIP

4 EHRs 14 Use Cases 9 HIT Vendors 16 Payers Dozen Providers
Founding Members 16 Payers 4 EHRs 14 Use Cases 9 HIT Vendors Our initial founding group of payers, providers and HIT vendors has grown to a membership group of 27 organizations, including 12 payers, 10 HIT vendors, 6 providers and 3 EHR vendors. Cross-functional teams are currently involved in the project to develop and deploy FHIR-based solutions that positively impact clinical quality, cost and care management outcomes. We’ve paused on adding additional members , but all artifacts including IGs, reference implementations and pilot partners will be open source and available to public. Members are building initial implementations. Dozen Providers

For current membership: http://www.hl7.org/about/davinci/members.cfm
Da Vinci Members For current membership:

Da Vinci Members

New Membership Categories

Program Status

2019 Implementation Guide Schedule
Data Exchange for Quality Measures Coverage Requirements Discovery Documentation Templates and Coverage Rules Use Case Status In Ballot Process through HL7 Targeted for September Ballot In Discovery targeted for HL7 January Ballot Use cases in discovery (some may be balloted in January 2020) Health Record Exchange Framework / Library Clinical Data Exchange Prior-Authorization Support Payer Data Exchange Payer Data Exchange: Provider Network Payer Data Exchange: Formulary Project Process Define requirements (clinical, business, technical and testing Create Implementation Guide (IG) Create and test Reference Implementation (RI) (prove the IG works) Pilot the solution Deploy the Solution Alerts/Notifications: Transitions in Care, ER admit/discharge Payer Coverage Decision Exchange Gaps in Care & Information Health Record Exchange: Patient Data Exchange Patient Cost Transparency Risk Based Contract Member Identification Performing Laboratory Reporting Chronic Illness Documentation for Risk Adjustment 12

Work Breakdown to Support CMS NPRM

Use Case Focus Areas Use Case Status Quality Improvement Member Access
Data Exchange for Quality Measures Framework: Clinical Data Exchange Payer Data Exchange Member Access Payer Data Exchange Gaps in Care & Information Payer Data Exchange: Formulary Payer Data Exchange: Provider Network Clinical Data Exchange Clinical Data Exchange Process Improvement Payer Coverage Decision Exchange Patient Cost Transparency Alerts/Notifications: Transitions in Care, ER admit/discharge Coverage / Burden Reduction Coverage Requirements Discovery Risk Based Contract Member Identification Chronic Illness Documentation for Risk Adjustment Health Record Exchange: Patient Data Exchange Documentation Templates and Coverage Rules Prior-Authorization Support Performing Laboratory Reporting Balloted Planned for September Ballot In Discovery, Planned for January Ballot Use cases in discovery (some may be balloted in January 2020) Use Case Status 14

2019 2020 Ballots and Connectathons
EARLY SEPTEMBER BALLOT (June 21 – July 21) STU Health Record Exchange (HRex) STU Payer Data Exchange (PDex) STU PDex Formulary STU Clinical Data Exchange (CDex) MAY BALLOT (Mar 29 – Apr 29) STU Data Exchange for Quality Measures (DEQM) STU Coverage Requirements Discovery (CRD) Comment Documentation Templates & Rules (DTR) ONC Annual Meeting Da Vinci Meeting & Connectathon HL7 Connectathon 2019 2020 MAR APR MAY JUN JUL AUG SEP OCT NOV DEC JAN FEB MAR Da Vinci Connectathon & Working Session JANUARY BALLOT (Dec 27 – Jan 26) STU Gaps in Care STU STU Patient Cost Transparency SEPTEMBER BALLOT (Aug 9 - Sept 9) STU PDex Payer Directory STU Documentation Templates and Rules (DTR) STU Alerts / Notifications STU Payer Coverage Decision Exchange STU Prior Authorization Support (Prior Auth) HL7 Connectathon HL7 Connectathon

Activities by the Numbers Activities by the Numbers
UNLOCKING PAYER INFORMATION TO IMPROVE CARE HIMSS19 Demonstration Activities by the Numbers Stats Total practice runs 3 Total public runs 23 Filming runs 1 Total variations 14 Total roles 96 Total role system issues 7 Role availability 92.7% Activities by the Numbers Stats AEGIS Touchstone available 100% Total MCs 6 Total EHRs 2 Total Payer/Partner 4 Total Payer only 5 Total Sponsors 16 Number of visitors (approx.) 500 Percent that left during vignette < 10 % Patient 1 2 3 4 PCP Schedule Appt with Payer Admitted for Angioplasty Discharged with O2 Therapy Cardiologist Hospital Payer Med Rec Patient Data CLINICAL SUMMARY Da Vinci is demonstrating the ability to exchange information between payers and providers using HL7® FHIR® and CDS Hooks® as part of the Interoperability Showcase. The vignette describes a clinical encounter for 78-year-old Asian women named Dara that starts with her primary care physician, proceeds to a cardiologist who admits Dara to the hospital for an angiogram and observation where it is determined that her chronic obstructive pulmonary disease has progressed to the point that she needs supplemental oxygen. As Dara returns to her primary care physician, her previous medications are reconciled with those prescribed at discharge, the PCP reports the medication reconciliation, in support of a quality measure the Medicare Advantage program is following for its members. The visual describes the interactions demonstrated at HIMSS Interoperability Showcase, direction of each exchange, the FHIR standards used, the setting where the interaction is occurring and the participants. Each step represents a provider – payer exchange using FHIR IG

Summary of Active Use Cases & Resources

Sample Project Timeline
Represents 4 weeks 2 - 4 sprints IG Development Specify profiles, … IG Framework Create Draft IG Revise and Finalize IG FHIR Gap Analysis Assemble Team Requirements RI Tech Approach Project start RI Development Build Initial RI Test RI Update Final RI Build Data Set Build Test Set Week Work with appropriate HL7 workgroup for IG sponsorship and input

Follow Progress, Test, Implement
FIND Background collateral Implementation Guide(s) 2 Balloted Sept ’18 3 May Ballot Underway 4 Early Ballot July Progress 5 September Ballot Reference Implementation HL7 Connectathon participants Publicly available RESOURCES HL7 Da Vinci Wiki & Listserv signup - HL7 Confluence Site - Where to find Da Vinci in Industry - nci+2019+Calendar Use Case Summary and Links to Call In & Artifacts - nci+Use+Cases Reference Implementation Code Repository -

Highlight: Spaces (top left) Watch (top right) Page Tree (left side) Program status (center) - Key items (center)

Active Use Case Details

Subscribe for Measure Data
Quality Data Quality Measures Submit Measure Data Use case creates a common framework for quality data exchange Enables the exchange of raw quality measure data between quality measurement Teams and Care teams that provide patient care Timely exchange of key data is critical to evaluate and capture quality Additional Scenarios underway to expand measure patterns in framework 1. Submit OperationOutcome Payer Aggregator Collect Measure Data 2. Collect Return Measure Data Provider Payer Subscribe for Measure Data 3. Subscribe OperationOutcome Aggregator Provider

Emerging DEQM Patterns
Measure Pattern Status 30 Day Medication Reconciliation Attestation STU Colorectal Cancer Screening Screening May Ballot Venous Thromboembolism Prophylaxis Process Initial example of how Da Vinci funding expandable framework Multiple groups providing resources to build out measures beyond Da Vinci Evaluating missing components to expand types of measures that could leverage framework i.e., public health

Pilot Implementation REST Architecture Model
Provider EHR Implementation Scope Da Vinci’s Deliverable Scope Payer Implementation Scope EHR Backend Services Payer Backend Services EHR Payer Request Resource Translation Services Endpoint & APIs Endpoint & APIs Translation Services Response Resource EHR Database Payer Database Implementations conforming to the DaVinci FHIR Profiles following the Implementation Guides Industry standard DaVinci Use Case FHIR Profiles with respective Implementation Guides Implementations conforming to the DaVinci FHIR Profiles following the Implementation Guides

Order Procedure, Lab or Referral
Coverage Requirements Discovery Provider Order Procedure, Lab or Referral Discover Any Requirements Payer Providers need to easily discover which payer covered services or devices have Specific documentation requirements, Rules for determining need for specific treatments/services Requirement for Prior Authorization (PA) or other approvals Specific guidance. With a FHIR based API, providers can discover in real-time specific payer requirements that may affect the ability to have certain services or devices covered by the responsible payer. Response may be The answer to the discovery request A list of services, templates, documents, rules URL to retrieve specific items (e.g. template)

Coverage Requirements Discovery
Based on a specific clinical workflow event: scheduling, start of encounter, planning treatment, ordering, discharge Provider’s send FHIR based request, with appropriate clinical context to the responsible payer Payer may request additional information from the provider EHR using existing FHIR APIs Payer responds to the EHR with any specific requirements that may impact the clinical decisions or coverage Payer Provider Provider requests coverage requirements from payer Optional: request additional information Payer responds to the request Provider utilizes this information to make treatment decisions while considering specific payer coverage requirements.

CRD and Document Templates & Rules
CDS Service searches repository leveraging FHIR data DME Ordered “order-review” hook triggers query Invokes service & sends pre-fetch FHIR data including order information Library of coverage rules/templates PAYER SMART on FHIR App EHR/PROVIDER BACK OFFICE SYSTEMS Displays Gaps/Template/Rule Collects Missing Data and Store as Part of Medical Record Retrieve rules, if necessary. Parse rule from CQL, identify gaps in data available in EHR and populate template Send CDS Hooks Response with link to SMART on FHIR App

Prior Authorization Support Abstraction/Transform for HIPAA Compliance
EHR OR PROVIDER SYSTEM CLEARINGHOUSE OR INTEGRATION LAYER PAYER SYSTEM Prior Authorization Support X12 278 Support Authorization Support Transformation Layer Transformation Layer X12 275 Clearinghouse or Integration Required to Meet HIPAA Regulations

Power to Reduce, Inform and Delegate Prior Authorization Support
Coverage Requirements Discovery CDS Hooks Coverage Requirements Discovery Documentation Templates and Coverage Rules FHIR APIs Documentation Templates and Coverage Rules EHR/PROVIDER BACK OFFICE SYSTEMS PAYER Prior Authorization Support X12 278 Prior Authorization Support Transformation Layer Transformation Layer Optional X12 275 if required Improve transparency Reduce effort for prior authorization Leverage available clinical content and increase automation

Pilot Implementation Architecture Model
Provider EHR Implementation Scope Da Vinci’s Deliverable Scope Payer Implementation Scope Industry standard DaVinci Use Case FHIR Profiles with respective Implementation Guides Implementations conforming to the DaVinci FHIR Profiles following the Implementation Guides EHR Database EHR Backend Services Translation Services Endpoint & APIs Request Resource Response Resource EHR Payer Payer Backend Services Payer Database This is a high level architectural view of our reference implementations.

Health Record Exchange Simplified
Health Record Exchange Framework Interactions & Profiles Provider can receive relevant Payer Sourced Data about a patient Payer to Provider Data Exchange (PDex) Provider can access Plan Network Directory information Payer to Provider/ Member Data Exchange (PDex): Directory Patient can access Plan Network Directory information Payer to Provider/ Member Data Exchange (PDex): Formulary Provider can access Plan Formulary information Patient can access Plan Formulary information Provider can share relevant Provider Sourced Data to Payer and/or other Providers Provider to Payer Exchange (CDex) PROVIDER PAYER PATIENT/ MEMBER

eHealth Record Exchange
eHRx electronic Health Record exchange Framework Interactions and Profiles DEQM Data Exchange for Quality Measures Framework CDex Clinical Data exchange PDex Payer Data exchange MRP Medication Reconciliation Post-discharge Additional Measures for DEQM IG

Patient Care, Documents on FHIR
eHealth Record Exchange: Clinical Data Exchange (CDex) SUMMARY Providers and Payers need to exchange information regarding prior and current healthcare services planned for or received by the patient/member to more effectively manage the patients care. Currently, no FHIR implementation guides exist to standardize the method of exchange (push, pull, triggers, subscription, etc.) and the formal representation (e.g. Documents, Bundles, Profiles and Vocabulary) for the range of exchanges between providers and providers or providers and payers of current and emerging interest to the involved parties. The focus is on the exchange of provider and payer originated information to improve patient care and reduce provider and payer burden. This use case will define combinations of exchange methods (push, pull, subscribe, CDS Hooks, …), specific payloads (Documents, Bundles, and Individual Resources), search criteria, conformance, provenance, and other relevant requirements to support specific exchanges of clinical information between: 1) providers, 2) a provider and a payer, 3) a payer and providers, and/or a provider and any third party involved in value based care (e.g. a quality management organization). This project will reference, where possible, the prior work from Argonaut, US Core and QI Core effort for FHIR DSTU2, STU3, Category Level of Effort Effort Medium Complexity Time to Ref Imp 4-6 mo Source/HL7 WG Patient Care, Documents on FHIR FHIR Fitness Excellent Standards Dev Scope (including IG) Easy-Medium Implementation Challenges Medium-Complex 33

eHealth Record Exchange: Payer Data Exchange (PDex)
SUMMARY Providers need access to payer information regarding current and prior healthcare services received by the patient/member to more effectively manage the patients care. It is important to standardize the method of exchange (push, pull, triggers, subscription, etc.) or the formal representation (e.g. Bundles, Profiles and Vocabulary) for specific elements of payer information of interest to providers. The value is to provide a standard for adoption by both payers and providers for the exchange of payer information. Where possible the 'standards' defined by the electronic Health Record exchange (eHRx) Framework Implementation Guide which in turn will utilize prior work from Argonaut, US Core and QI Core effort for FHIR DSTU2, STU3, and R4. The goal is to support the exchange of payer data on specific patients/members for better patient care with providers using technology that support FHIR DSTU2, STU3, and R4 releases of the FHIR standard. Will support the use of other interoperability 'standards' (e.g. CDS Hooks and SMART on FHIR) to effectively exchange payer information regarding the current or previous care, including the provenance of the data, of one or more specific patients/members with a provider responsible for evaluating/specifying/ordering/delivering care for the patient. Category Level of Effort Effort Medium Complexity Low-Medium Time to Ref Imp 3-5 mo Source/HL7 WG Finance, Patient Care FHIR Fitness Excellent Standards Dev Scope (including IG) Easy-Medium Implementation Challenges 34

Alerts/Notifications: Admit/Discharge Notifications, Clinical and Administrative Events
SUMMARY Current Admit and Discharge notifications typically use an HL7 V2 ADT message. While HL7 V2 works well within the confines of a hospital system’s intranet, it is not particularly well suited to cross-enterprise data exchange. FHIR resources can be used to transport patient admission and discharge information as well as information related to other care events to an extended care team. The work effort will include defining the scope and content of the massaging based on input from the various stakeholders. The goal is to provide a FHIR based standard for the definition and exchange of relevant alerts and notifications Coordination with Argonaut work on the Subscription model (to make it event driven) will provide a basis for the exchange of alerts where care team relationships are defined and subscription to appropriate events is supported. The work effort will include exploring options to “push” the defined alerts / notifications where subscription is not a viable solution Category Level of Effort Effort Low-Medium Complexity Low Time to Ref Imp 2-4 initial scope Source/HL7 WG CDS/OO FHIR Fitness Excellent Standards Dev Scope (including IG) Implementation Challenges Medium

Site of where notifiable event occurred
Alerts/Notification HIE / HIN Primary Care Any care team member can be connected directly or via an intermediary (e.g. HIE) Site of where notifiable event occurred Specialty Care Inpatient Services Payer Potential Interactions: Subscribe to event directly (no intermediary) Subscribe to event via intermediary Push to “registered” member (perhaps via payer care team information) Push to intermediary

Patient Cost Transparency
SUMMARY Payer automated capabilities that provide timely, robust pricing transparency between payers and providers, as well as payers and consumers, is an industry priority Robust payer pricing transparency presented prior to the delivery of services will enable patients with their clinician's guidance to make informed decisions on their course of treatment and the cost to the patient Patients need accurate, timely access to cost of medical care prior to delivery of care in order to become better stewards of their healthcare dollars. Exposing cost of services/devices and calculated Care Plan Pretreatment Estimate within an EMR workflow can lead to clinician/patient care plan decisions with increased patient adherence Providers need accurate, timely access to pricing transparency prior to and immediately after delivery of pharmaceutical/medical care to collect financial responsibility from patients at the practice check out, immediately after providing care to increase patient responsibility collection and reduce collection costs. Provide simple exchange for providers to request and display cost information from payer/practice management to enable clinician and patient pharmaceutical/medical device / services / medical care conversation. Category Level of Effort Effort High Complexity Time to Ref Imp 4-6 limited scope, Source/HL7 WG Finance FHIR Fitness Good Standards Dev Scope (including IG) Implementation Challenges Complex This PSS builds on existing implementation guides for the automation of coverage discovery (Coverage Requirements Discovery – CRD) and the Health Record Exchange Library/Framework (HRex) to provide cost information for planned or potential services/devices at the point of care when treatment decision are being made.. Payer automated capabilities that provide timely, robust patient pricing transparency between payers and providers, as well as payers and patients, is an industry priority Robust payer pricing transparency, in the context of program benefits and patient cost, presented prior to the delivery of services will enable patients with their clinicians guidance to make informed decisions on their course of treatment and the cost to the patient Patients need accurate, timely access to cost of medical care prior to delivery of care in order to become better stewards of their healthcare dollars. Exposing cost of services/devices and calculated Care Plan Pretreatment Estimate within an EMR workflow can lead to clinician/patient care plan decisions with increased patient adherence Providers need accurate, timely access to pricing transparency, on patient out-of-pocket costs, prior to and immediately after delivery of pharmaceutical/medical care to collect financial responsibility from patients at the practice check out, immediately after providing care to increase patient responsibility collection and reduce collection costs. This IG will define a simple exchange for providers to request and receive patient cost information from payer to enable clinician and patient medical device / services / medical care conversation. This project will utilize specific triggers and exchange methods (CDS Hooks, Pull, etc.), use of other interoperability "standards" (e.g. SMART on FHIR, CQL) and specific use of FHIR resources to effectively request cost information from the responsible payer and return it in real-time to the provider so they can use it in treatment planning conversations with their patient at point of service. This project will reference, where possible the "standards" defined by the Health Record exchange (HRex) Library/Framework Implementation Guide which in turn will utilize prior work from Argonaut, US Core and QI Core effort for FHIR DSTU2, STU3, and R4 where appropriate. The following diagram depicts the anticipated scope of the HRex Library/Framework IG.

Payer Coverage Decision Exchange
SUMMARY The exchange of specific coverage/treatment decisions from one payer to another payer to allow for continued coverage of specific treatments without needing to repeat the review and authorization process. The decisions may be based on commercial guidelines that can be uniquely referenced or based on specific payer rules (if and when available and defined in a structured, rules-based manner, w/o a proprietary payer's evaluation process). Supports the exchange the supporting documentation used to validate the necessity for coverage of specific treatments This work builds on the Payer Data Exchange – PDex implementation guides to define patient driven/authorized exchange methods to meet the anticipated requirements for coverage portability. . Category Level of Effort Effort Medium-High Complexity Medium Time to Ref Imp 2-3 limited scope, 6-8 full scope Source/HL7 WG Finance FHIR Fitness Good-Excellent Standards Dev Scope (including IG) Implementation Challenges Complex 38

Gaps in Care or Information
SUMMARY To succeed in population health and value-based care, gaps in care and information must be addressed efficiently and in a timely manner. Anticipating or closing gaps in care, at point of care, is an opportunity to improve care quality and cost of care. Gaps in information can adversely affect member outcomes and contribute to inappropriate costs. For providers and payers to improve population health value-based care two items must be addressed: Gaps in Care Information: Disparities in claims vs. clinical information which makes it difficult to assess if best practices are being followed: e.g. a diabetic member with no A1C or a member being prescribed insulin with no diabetes diagnosis. Incomplete Healthcare Information: For example, a request for cancer treatment without providing date of diagnosis or stage of illness at time of diagnosis to support effective care coordination. Bi-directional, real-time, FHIR-based communication that reconciles payer information with clinical EHR data to ensure best practices are followed, improve outcomes, and exchange information to reduce expense and disruption to provider workflows. Category Level of Effort Effort Medium-High Complexity Medium Time to Ref Imp 2-3 limited scope, 6-8 full scope Source/HL7 WG ? FHIR Fitness Good-Excellent Standards Dev Scope (including IG) Implementation Challenges Complex

Da Vinci Program Manager: Jocelyn Keegan, Point of Care Partners
Da Vinci Technical Lead: Dr. Viet Nguyen, Stratametrics LLC

ANSI Antitrust Policy ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification.

Similar presentations

Presentation on theme: "ANSI Antitrust Policy ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

ANSI Antitrust Policy ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification.

Similar presentations

Presentation on theme: "ANSI Antitrust Policy ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification."— Presentation transcript:

Similar presentations

About project

Feedback