HL7 Da Vinci Project Deep Dive September 2019

HL7 Da Vinci Project Deep Dive September 2019
Jocelyn Keegan, Program Manager Point of Care Partners Viet Nguyen, MD, Technical Director Stratametrics LLC Introduce ourselves and ask participants to introduce themselves, their background and personal goals

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.

Agenda What is Da Vinci? Why is it needed? What does it do/deliver?
What are the use cases and where should I focus? How do I get involved?

Context

VBC Programs Drive Focus to Patient Outcomes
VALUE Cost Constraints Regulatory Impact Patient Outcomes Enable provider to see right data at right time for specific patient coverage, benefits and care coordination Historically, payment and coverage data completely separate from care

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® Source: © 2018 Health Catalyst

Market Influences on Shift to Value
VBC fundamentally changing relationships between payers, providers across care settings Goal is to shift focus on outcomes Contracts include exchange of clinical data Payers and strategic partners or wholly owned practices becoming “Payviders” Mega-acquisitions are bringing Payers and PBMs under single organization HL7 acting as a convener of stakeholders to identify ways FHIR can help Provider Healthcare Directory Payers Patient Medical Record CDS Services (eg, DME, Imaging) Referral/ Consult Public Health Research

Regulator Drivers towards Value
Source Primary Target Stakeholder Types of Drivers Sample ONC Office of the National Coordinator EHRs under ONC; Promoting Interoperability Programs provider certification requirements for EHRs and related vendors FHIR called out by name USCDI support Epic, Cerner, Athenahealth Allscripts, CMS Centers for Medicaid and Medicare Services Payers, often through Qualified Health Plans (ACA), CHIP and Medicare Advantage CMS funding and promoting Da Vinci IGs Payer to Payer data sharing Focus on Cost Transparency FHIR Aetna, Blues, Cigna Humana, Oscar, United Underpinning the regulatory activitiy is legislation like 21st Cures Act and other laws passed by Congress

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.

Formation of Da Vinci

Founding Members

Governance Structure STEERING COMMITTEE OPERATING COMMITTEE
Payers -3 Providers - 2 IT Vendors- 2 CMS - 1 HL7 - 1 Sagran Moodley* United Kirk Anderson Cambia Health Mike Funk Humana Dr. Shafiq Rab, Rush Medical Dr. Steven Lane Sutter Health Hans Buitendjik** Cerner Peter DeVault Epic Melanie Combs-Dyer CMS Fee for Service Dr. Ed Hammond/ Dr. Chuck Jaffe Program Manager & Technical Director Jocelyn Keegan Dr. Viet Nguyen STEERING COMMITTEE Senior level executive, can make decisions and commit organization resources Driving interoperability strategy within home organization and responsible for coordination with industry Technology and business ownership to drive “business case” approval OPERATING COMMITTEE Budget planning and approval for “in kind” and project fees Leader and/or influencer across home organization Work closely/aligned with senior leadership at home organization, can queue up commitment and decisions and drive to conclusion Understands and will own HL7 standards relationship, commitments Roll up sleeve and problem solve use case development and inventory, priorities, details Identify and gain access/time for “in kind” resources for priority use case work OPERATING COMMITTEE Use Case 1 Project Lead Use Case 2 Project Lead Use Case n+ Project Lead DEPLOYMENT COMMITTEE Disclaimer *Chair **Co-Chair

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) Early January ballot (Oct 15 – Nov 15) STU PDex Payer Directory 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 Alerts / Notifications STU Gaps in Care STU STU Patient Cost Transparency STU RBC Member ID and Bulk Data SEPTEMBER BALLOT (Aug 9 - Sept 9) STU Documentation Templates and Rules (DTR) STU Prior Authorization Support (Prior Auth) HIMSS20 HL7 Connectathon HL7 Connectathon

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

Process: How We Work

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

Member Project Commitment
HL7 and Da Vinci Relationship Model Member Project Commitment PSS SOU with HL7 Goal is lightweight burden with clear understand of relationships Establish high level agreement to participate in Da Vinci, recognizing HL7 as convener, administrator and maintain Project Da Vinci Steering Committee autonomy Coordinate with US REALM Task Force on two fronts; overarching project to establish process for Da Vinci and on a per project basis to establish workgroup home, artifacts to bring into standards process Member to Member commitment to project and partner organizations establish rules of the road Add member agreement/project commitment as add’l rules between members. . .

Da Vinci Interaction with FHIR Standards Process
Workgroup TSC Develop Reference Implementation Use Case PSS Develop Implementation Guide Pilot RI Note: Sponsor depends on specific use case and HL7 support process for Da Vinci Sponsor Note: WG Sponsor(s) determine level of participation from informational updates to active participation Review and approve NIB Approve for ballot Reconcile comments Re-ballot or publish (effort supported by Da Vinci members) Co-Sponsor Co-Sponsor Give detail approved upon working model by HL7 executive board. This is baked into each organizations Statement of Understanding. Let’s look at an example. Review and Approve Review and Approve Publish HL7 Note: Not all Da Vinci projects will result in artifacts for HL7 ballot and publication 18

Use Case: eHealth Record Exchange: HEDIS/Stars & Clinician Exchange
Sample HL7 WG Participation Use Case: eHealth Record Exchange: HEDIS/Stars & Clinician Exchange Da Vinci HL7 International Participation Model Workgroup Active involvement by one or more WG member CIC (sponsor) Da Vinci provides: project management, SME(s), development lead, Members provide: business lead, IG and RI development support Project: eHealth Record Exchange Weekly updates Attachments (co-sponsor) CLEAR PREVIOUS with one or two sentences, and spend time here. . .discuss already underway with 30 Day and Coverage Requirements. Updates at significant events Financial Management (co-sponsor) Note: most roles are a partial FTE dedicated to the specific use case driven project

What We Deliver

Follow Progress, Test, Implement
FIND Background collateral/call details Implementation Guide(s) 2 Balloted Sept ’18 3 May Ballot 4 Early Sept Ballot 3 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 Vinci+2019+Calendar Use Case Summary and Links to Call In & Artifacts Vinci+Use+Cases Reference Implementation Code Repository - DaVinci

Reference/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

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

Active Use Case Details

Use Case Focus Areas Quality Improvement Member Access
Clinical Data Exchange Data Exchange for Quality Measures Clinical Data Exchange Payer Data Exchange Payer Data Exchange Gaps in Care & Information Payer Data Exchange: Formulary Payer Data Exchange: Directory Clinical Data Exchange Process Improvement Payer Coverage Decision Exchange Patient Cost Transparency Alerts / Notifications Coverage / Burden Reduction Coverage Requirements Discovery Risk Based Contract Member Identification Chronic Illness Documentation for Risk Adjustment Patient Data Exchange Documentation Templates and Rules Documentation Templates and Rules Prior-Authorization Support Performing Laboratory Reporting May ballot STU and for comment In early September ballot (July) as STU September ballot as STU Currently targeted for early or regular January 2020 ballot Use cases in discovery (some may be balloted in January 2020) Use Case Status 25

Relationship to Other Industry Activities

CMS NPRM Information Exchanges Supported by Da Vinci IGs
[10] Provider Data [12] Alerts/Notifications Quality Measures and Gaps [1] Data Exchange for Quality Measures [2] Gaps in Care and Information Member Directed Exchange (CMS NPRM) [3] Payer Data Exchange [4] Payer Data Exchange: Directory [5] Payer Data Exchange: Formulary [6] Payer Coverage Decisions (Treatment) Coverage/Documentation Requirements [7] Coverage Requirements Discovery [8] Documentation Templates and Rule [9] Prior-Authorization Support Patient Data Exchange [10] Clinical Data Exchange (Provider Data) [11] Payer Data Exchange (Payer Data) [12] Alerts/Notification Patient Cost Transparency (in discovery) [2] Gaps in Care [7] Coverage Requirements [8] Documentation Rules [11] Payer Data Provider Provider [1] Quality Data [10] Provider Data [9] Prior-Authorization [12] Alerts/Notifications [3] USCDI [6] Continuity of Treatment [2] Aggregated Quality Measure Reporting Payer Payer [3] USCDI [4] Directory [5] Formulary Patient [3] USCDI [4] Directory [5] Formulary Member Authorization Consumer Application

RAPID INDUSTRY ADOPTION
ONC FAST - Standards Efforts Towards FHIR Adoption FUNCTIONAL USE CASES SHARED Technical Challenges to FHIR Scalability FHIR Solutions for VBC RAPID INDUSTRY ADOPTION Payers/Providers Patient & Provider Identity Management Directory Services Version Identification Scale Exchange Process/Metadata Testing, Conformance & Certification Security Core Data Services Common Scalability Approaches Provider/Provider FHIR Consumer Solutions Mention FHIR Acellerators Consumers Other Collaborative Efforts to Develop & Implement FHIR Solutions INFRASTRUCTURE USE CASES

Please Return for 11am Start
Questions? Please Return for 11am Start

Use Case Focus Areas Quality Improvement Member Access
Clinical Data Exchange Data Exchange for Quality Measures Clinical Data Exchange Payer Data Exchange Payer Data Exchange Gaps in Care & Information Payer Data Exchange: Formulary Payer Data Exchange: Directory Clinical Data Exchange Process Improvement Payer Coverage Decision Exchange Patient Cost Transparency Alerts / Notifications Coverage / Burden Reduction Coverage Requirements Discovery Risk Based Contract Member Identification Chronic Illness Documentation for Risk Adjustment Patient Data Exchange Documentation Templates and Rules Prior-Authorization Support Performing Laboratory Reporting May ballot STU and for comment In early September ballot (July) as STU September ballot as STU Currently targeted for early or regular January 2020 ballot Use cases in discovery (some may be balloted in January 2020) Use Case Status 30

Burden Reduction

Coverage Requirements Discovery
SUMMARY 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. The discovery may be based on Plan conditions only (e.g. no need for PHI) Member identification (PHI) in the event the specific plan is not known at the time of request Response may be The answer to the discover request A list of services, templates, documents, rules URI to retrieve specific items (e.g. template) STATUS Stage Ballot Reconciliation & Connectathons Implementation Guide CRD FHIR IG (v0.3.0: STU1 ballot 2) based on FHIR R4 Reference Implementation CRD GitHub Repository Confluence Artifacts Coverage Requirements Discovery (CRD) 32

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. The discovery may be based on Plan conditions only (e.g. no need for PHI) Member identification (PHI) in the event the specific plan is not known at the time of request 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 Providers 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

Documentation Templates & Coverage Rules (DTR)
SUMMARY Providers are challenged to deal with the diversity of administrative and clinical requirements that impact documenting the need for treatment and selecting the appropriate best path for care. The current environment is made more complex by the large number of payer based requirements that must be met to document that covered services and devices are medically necessary and appropriate. The goal of this use case is to reduce provider burden and simplify process by establishing electronic versions of administrative and clinical requirements that can become part of the providers daily workflow. An exemplar for this use case is to follow the approach taken to incorporate formulary requirements interactively into the medication selection process. Proposal includes the ability to inject payer coverage criteria into provider workflows akin to clinical decision support (CDS Hooks), to expose rules prospectively while providers are making care decisions. A limited reference implementation on a limited use case (e.g. Home Oxygen Therapy) Address coverage requirements, documentation compliance, and detect misuse/ abuse Provide value based care requirements at point of service Collect, in real-time, patient information to alert provider or care team STATUS Stage May Ballot Reconciliation & Sept STU Ballot Implementation Guide DTR FHIR IG (v0.1.0: Ballot for Comment) based on FHIR R3 Reference Implementation DTR GitHub Repository Confluence Artifacts Documentation Templates and Payer Rules (DTR)

Documentation Templates and Payer Rules (DTR)
Providers need to easily incorporate payer requirements into their clinical workflow Specific documentation requirements, Rules for determining need for specific treatments/services Requirement for Prior Authorization (PA) or other approvals Specific guidance. Use a FHIR based standard for representing payer “rules” to communicate, in real-time, payer medical necessity and best clinical practice requirements that may affect the ability to have certain services or devices covered by the responsible payer. The template/rules may (examples, not complete list) Specify provider documentation requirements for coverage, medical necessity Provide guidance / documentation requirements regarding social determinates that are antecedents for specific care Collect information for some purpose (e.g. authorizations) Indicate clinical requirements including appropriate use Collect specific documentation for Quality Measures Respond with specific information as requested/documented in the template/rules

DTR/Order Flow

Prior Authorization Support
SUMMARY A FHIR-based B2B process to allow implementers to use existing IT infrastructure resources for exchanging prior authorization. Existing business agreements can also be reused. This use case assumes that the goal is define API services to enable provider, at point of service, to request authorization (including all necessary clinical information to support the request) and receive immediate authorization. The assumption is that this use case will leverage the ASC X12N 278 and 275 for compliance with HIPAA. Clearinghouses can continue to route and translate data as appropriate. Investigate ability to enable translation layer to convert FHIR resources to HIPAA format. STATUS Stage September STU Ballot Implementation Guide Prior Authorization Support – CI Build Reference Implementation Prior Auth Support GitHub Repository Confluence Artifacts Prior Authorization Support 39

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

Quality Improvement

Data Exchange for Quality Measures (DEQM)
SUMMARY 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 Emerging DEQM patterns 30 Day Medication Reconciliation (Attestation Pattern) Colorectal Cancer Screening (Screening Pattern) Venous Thromboembolism Prophylaxis (Process Pattern) 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/patterns that could leverage framework (i.e., public health) STATUS Stage Ballot Reconciliation & Connectathons Implementation Guide DEQM FHIR IG (v0.2.0: STU1 Ballot 2) based on FHIR R3 30 Day Medication Reconciliation Reference Implementation MRP-Reference-App MRP-Payer-App MRP-Operation-Submit-Example MRP-Sample-Patients Colorectal Cancer Screening Reference Implementation COL-CollectData-App COL-Submit-App Confluence Artifacts Data Exchange for Quality Measures (DEQM) 43

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

STU1 – Ballot Reconciliation
Emerging DEQM Patterns Measure Pattern Status 30 Day Medication Reconciliation Process STU1 – Ballot Reconciliation Colorectal Cancer Screening Screening Venous Thromboembolism Prophylaxis Controlling Blood Pressure Outcome Discovery 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

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. STATUS Stage Planning/Discovery Implementation Guide TBD Reference Implementation Confluence Artifacts

Clinical Data Exchange/Member Access

Health Record Exchange
HRex Health Record exchange Framework/Library 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

Health Record Exchange: Health Record Exchange Framework/Library
SUMMARY The Da Vinci Payer Health Record Exchange (HRex) Framework/Library specifies the FHIR elements used in multiple Da Vinci implementation guides. This includes FHIR profiles, functions, operations, and constraints on other specifications such as CDS-Hooks and other aspects of Da Vinci Use Cases that are common across more than a single use case. Da Vinci HRex Implementation Guide (IG) will make use of US Core profiles that are based on the FHIR R4 specification wherever practical. The HRex IG will use the HL7 FHIR Release 4/US Core STU3 specification as its base but will provide additional guidance and documentation to support implementations that follow the HL7 FHIR STU3/US Core STU2 and HL7 FHIR DSTU2/Argonaut specifications. The HRex profiles documented in this IG will be used to exchange data between providers systems (e.g. EHRs) and other providers, payers, and third-party applications were appropriate. In addition, exchanges from payer systems to providers, other payers, and third-party applications are supported by the HRex profiles and operations. HRex may define new extensions, profiles, value sets, constraints/extension to other specification (e.g. specific CDS-Hooks) that are specific Da Vinci requirements. Where appropriate these Da Vinci specific artifacts will be promoted for incorporation into the future versions of existing standards (e.g. R4 US Core profiles) and deprecated in this guide on publication in the updated standard. STATUS Stage July STU Ballot Implementation Guide HRex – CI Build Reference Implementation N/A Confluence Artifacts Health Record Exchange Framework (HRex) 49

Health 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, STATUS Stage July STU Ballot Implementation Guide CDex - CI Build Reference Implementation CDex Communication Response App CDex Communication Request App Confluence Artifacts Clinical Data Exchange (CDex) 50

Health 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. STATUS Stage July STU Ballot Implementation Guide PDex – CI Build Reference Implementation PDex GitHub Repository Confluence Artifacts Payer Data Exchange (PDex) 51

R4 PDex: Provider-Health Plan Exchange via CDS-Hook/SMART-on-FHIR
UserId PatientId EncounterId Appointments (subscriberId) JWT for access Call Hook SMART APP Query EMR for Patient Record Query EMR for Coverage Search by SubscriberId Search by Patient Demographics Appointment-book EMR DSTU2 STU3 R4 Payer R4 Provide Access Token with US Core Scopes Provide URL Link to Smart App FHIR Entrypoint Make CapabilityStatement available Human Readable result of Member Query No data found Unable to match individual N records returned CARD Member Query Summary Review Query Payer using Access Token Default Parameters from Provider constrain search Present US Core Records for Provider selection Review > Select > Write Get EMR Metadata Write constrained by write options in EMR Write documentReference (Optional – complete or selected DocumentBundle + PDF)

R4 PDex: Member-Authorized Health Plan Exchange (OAuth2.0)
Old Health Plan R4 New Health Plan 3rd Party App 1 Member Login New Health Plan 2 Member Authentication API Handoff 3 Member Access Authorization Member Login 3rd Party App Authenticated Access Token Returned 4 5 API Query with Access Token Eg. URL/Patient/12345/$everything 53

Health Record Exchange: Payer Data Exchange (PDex) Formulary
SUMMARY This project defines a FHIR interface to a health insurer's drug formulary information for patients/consumers. A drug formulary is a list of brand-name and generic prescription drugs a health insurer agrees to pay for, at least partially, as part of health insurance coverage. Drug formularies are developed based on the efficacy, safety and cost of drugs. The primary use cases for this FHIR interface enable consumers/patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans. STATUS Stage July STU Ballot Implementation Guide PDex Formulary Draft IG Reference Implementation PDex Formulary GitHub Repository Confluence Artifacts Payer Data Exchange (PDex) 54

PDex: Health Plan Formulary (SMART-on-FHIR)

Health Record Exchange: Payer Data Exchange (PDex) Plan Network Directory
SUMMARY This Implementation Guide covers the requirements and profiles required to enable health plans to publish Healthcare and Pharmacy network information to members via API. STATUS Stage September STU Ballot Implementation Guide PDex Plan Network Directory – CI Build Reference Implementation PDex Plan Network Directory GitHub Repository Confluence Artifacts Payer Data Exchange (PDex) 56

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. . STATUS Stage September STU Ballot Implementation Guide TBD Reference Implementation Confluence Artifacts Payer Coverage Decision Exchange 57

CMS NPRM Requirements for Covered Payers
Blue Button CARIN Member Directed APP USCDI -- Da Vinci PDex Directory -- Da Vinci Payer Network Formulary -- Da Vinci Formulary Coverage -- Da Vinci PCD Payer 1 Payer 2 Member authorization

Payer Coverage Decision Exchange
Member authorization Payer 1 Current treatments Conditions/diagnoses supporting each treatment Clinical Guideline References (where appropriate) Payer 2 Scope of Prior Authorizations (where appropriate) Supporting Documentation

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 STATUS Stage Build Implementation Guide TBD Reference Implementation Confluence Artifacts Alerts/Notifications

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. STATUS Stage Planning/Discovery Implementation Guide TBD Reference Implementation Confluence Artifacts 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.

Process Improvement

Risk Based Contract Member Identification Overview
SUMMARY Goal: Enable Payers and Providers to exchange information that identifies members of a patient population associated with a particular risk-based contract Method for payers and providers to synchronize data from practice management and EHRs, and to enable providers and payer organization to validate enrollment in Value-Based Care (VBC) programs at the point of care and for population level program management Information to be exchanged should be sufficient to identify a specific existing patient for inclusion in a risk-based contract or create such a patient in the PM/EHR if the patient does not already exist and the PM/EHR has the capability Scenarios Share member attribution list Update member attribution list Opportunities to use the list in order to share data for the identified members STATUS Stage Active Development Implementation Guide TBD Reference Implementation Confluence Artifacts Risk Based Contract Member Identification Disclaimer

Attribution List Creation Workflow – Current State
Producer/Consumer enter relationship and agree on attribution method and need for a list Producer Consumer 1 Producer creates initial attribution list Consumer receives list & historical information 2 Producer adjusts algorithm/ list Consumer reconciles list via their own attribution algorithm 3 Request Changes needed Producer starts sending list on agreed upon cadence 3 No changes needed Consumer loads data to various systems to support various use cases 4 Disclaimer

Questions? & How to Get Involved
Sign Up

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) Early January ballot (Oct 15 – Nov 15) STU PDex Payer Directory 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 STU RBC Member ID and Bulk Data STU Alerts / Notifications SEPTEMBER BALLOT (Aug 9 - Sept 9) STU Documentation Templates and Rules (DTR) STU Payer Coverage Decision Exchange STU Prior Authorization Support (Prior Auth) HL7 Connectathon HL7 Connectathon

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

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

HL7 Da Vinci Project Deep Dive September 2019

Similar presentations

Presentation on theme: "HL7 Da Vinci Project Deep Dive September 2019"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

HL7 Da Vinci Project Deep Dive September 2019

Similar presentations

Presentation on theme: "HL7 Da Vinci Project Deep Dive September 2019"— Presentation transcript:

Similar presentations

About project

Feedback