ANSI Antitrust Policy ANSI neither develops standards nor

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 1

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

Empower End Users to Shift to Value As a private industry project under HL 7 International, Da Vinci will unleash critical data between payers and providers required for VBC workflows leveraging HL 7® FHIR® Source: © 2018 Health Catalyst 3

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 Quality Measure Reporting Encounter Notifications Providers 4

HL 7 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. Provider Members: Dallas Children's Health, Multi. Care, OHSU, Providence St. Joseph Health, Rush University Medical Center, Sutter Health, Texas Health Resources, Weil Cornel Medicine Payer Members: Anthem, BCBSAL, BCBSM, BCBST, BC Idaho, Cambia Health, Cigna, Guide. Well, HCSC, Humana, Independence, United Healthcare Vendor Members: Allscripts, Athenahealth/Virence(aka GE Centricity), Casenet, Cerner, Cognosante, Edifecs, Epic, Health. LX, Inter. Systems, Juxly, Optum, Inter. Systems, Surescripts, Ze. Omega Project Process q q q 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 5

2019 MEMBERSHIP

Founding Members 16 Payers 4 9 HIT Vendors EH Dozen Providers Rs 14 Use Cases Members are building initial implementations. 7

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

Da Vinci Members 9

New Membership Categories 10

Program Status

2019 Implementation Guide Schedule Data Exchange for Quality Measures Coverage Requirements Discovery Documentation Templates and Coverage Rules Health Record Exchange Framework / Library Clinical Data Exchange Prior-Authorization Support Payer Data Exchange: Provider Network Alerts/Notifications: Transitions in Care, ER admit/discharge Use Case Status In Ballot Process through HL 7 Targeted for September Ballot In Discovery targeted for HL 7 January Ballot Use cases in discovery (some may be balloted in Payer Data Exchange: Formulary January 2020) Project Process 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 q Define requirements (clinical, business, technical and testing q Create Implementation Guide (IG) q Create and test Reference Implementation (RI) (prove the IG works) q Pilot the solution q Deploy the Solution 12

Work Breakdown to Support CMS NPRM 13

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

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

UNLOCKING PAYER INFORMATION TO IMPROVE CARE HIMSS 19 Demonstration Patient 1 Patient Schedule Appt with Payer Patient Discharged with O 2 Therapy Admitted for Angioplasty 3 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 Cardiologist Hospital PCP 2 Med Rec 4 Payer Patient Data Payer 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 92. 7% CLINICAL SUMMARY Activities by the Numbers AEGIS Touchstone available Stats 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 % Da Vinci is demonstrating the ability to exchange information between payers and providers using HL 7 ® 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. 16

Summary of Active Use Cases & Resources 17

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 Project start RI Development RI Tech Approach Build Initial RI Test RI Update Final RI Build Data Set Build Test Set Week 0 2 4 6 8 10 12 14 16 Work with appropriate HL 7 workgroup for IG sponsorship and input 18

Follow Progress, Test, Implement FIND • Background collateral RESOURCES • Implementation Guide(s) • HL 7 Da Vinci Wiki & Listserv signup - http: //www. hl 7. org/about/davinci/index. cfm ‒ ‒ 2 Balloted Sept ’ 18 3 May Ballot Underway 4 Early Ballot July Progress 5 September Ballot • Reference Implementation ‒ HL 7 Connectathon participants ‒ Publicly available • HL 7 Confluence Site - https: //confluence. hl 7. org/display/DVP/ • Where to find Da Vinci in Industry - https: //confluence. hl 7. org/display/DVP/Da+Vi nci+2019+Calendar • Use Case Summary and Links to Call In & Artifacts - https: //confluence. hl 7. org/display/DVP/Da+Vi nci+Use+Cases • Reference Implementation Code Repository - https: //github. com/HL 7 -Da. Vinci 19

20

Active Use Case Details

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 1. Submit Operation. Outcome Payer Collect Measure Data 2. Collect Return Measure Data Provider • Timely exchange of key data is critical to evaluate and capture quality • Additional Scenarios underway to expand measure patterns in framework Aggregator Payer Subscribe for Measure Data 3. Subscribe Operation. Outcome Aggregator Provider 22

Emerging DEQM Patterns Measure Pattern Status 30 Day Medication Reconciliation Attestation STU Colorectal Cancer Screening May Ballot Venous Thromboembolism Prophylaxis Process May Ballot • 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 23

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

Coverage Requirements Discovery Provider • 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. Order Procedure, Lab or Referral Discover Any Requirements • 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) Payer 25

Coverage Requirements Discovery 1. 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 1. Payer may request additional information from the provider EHR using existing FHIR APIs 2. Payer responds to the EHR with any specific requirements that may impact the clinical decisions or coverage Provider requests coverage requirements from payer Provider utilizes this information to make treatment decisions while considering specific payer coverage requirements. Optional: request additional information Provider Payer responds to the request Payer 26

CRD and Document Templates & Rules Invokes service & sends pre-fetch FHIR data including order information SMART on FHIR App 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 Library of coverage rules/templates PAYER EHR/PROVIDER BACK OFFICE SYSTEMS DME Ordered “orderreview” hook triggers query CDS Service searches repository leveraging FHIR data Send CDS Hooks Response with link to SMART on FHIR App 27

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

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

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

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 Provider can access Plan Formulary information Payer to Provider/ Member Data Exchange (PDex): Formulary Patient can access Plan Formulary information Provider to Payer Exchange (CDex) PROVIDER Provider can share relevant Provider Sourced Data to Payer and/or other Providers PAYER PATIENT/ MEMBER 31

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

e. 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. Category Level of Effort Medium Complexity Medium Time to Ref Imp 4 -6 mo • The focus is on the exchange of provider and payer originated information to improve patient care and reduce provider and payer burden. Source/HL 7 WG Patient Care, Documents on FHIR • 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). FHIR Fitness • This project will reference, where possible, the prior work from Argonaut, US Core and QI Core effort for FHIR DSTU 2, STU 3, Standards Dev Scope (including IG) Implementation Challenges Excellent Easy-Medium-Complex 33

e. 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 (e. HRx) Framework Implementation Guide which in turn will utilize prior work from Argonaut, US Core and QI Core effort for FHIR DSTU 2, STU 3, and R 4. 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 DSTU 2, STU 3, and R 4 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 Effort Complexity Level of Effort Medium Low-Medium Time to Ref Imp 3 -5 mo Source/HL 7 WG Finance, Patient Care FHIR Fitness Standards Dev Scope (including IG) Implementation Challenges Excellent Easy-Medium 34

Alerts/Notifications: Admit/Discharge Notifications, Clinical and Administrative Events SUMMARY • Current Admit and Discharge notifications typically use an HL 7 V 2 ADT message. While HL 7 V 2 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 Effort Complexity Level of Effort Low-Medium Low Time to Ref Imp 2 -4 initial scope Source/HL 7 WG CDS/OO FHIR Fitness Excellent Standards Dev Scope (including IG) Implementation Challenges Low Medium 35

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

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 Category Effort High Complexity High • Patients need accurate, timely access to cost of medical care prior to delivery Time to Ref Imp of care in order to become better stewards of their healthcare dollars. Exposing Source/HL 7 WG cost of services/devices and calculated Care Plan Pretreatment Estimate within an EMR workflow can lead to clinician/patient care plan decisions with FHIR Fitness increased patient adherence Standards Dev • Providers need accurate, timely access to pricing transparency prior to and Scope (including IG) immediately after delivery of pharmaceutical/medical care to collect financial responsibility from patients at the practice check out, immediately after Implementation providing care to increase patient responsibility collection and reduce collection Challenges 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. Level of Effort 4 -6 limited scope, Finance Good High Complex 37

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 Effort Complexity Level of Effort Medium-High Medium Time to Ref Imp 2 -3 limited scope, 6 -8 full scope Source/HL 7 WG Finance FHIR Fitness Good-Excellent Standards Dev Scope (including IG) Medium 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 A 1 C 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 Effort Complexity Level of Effort Medium-High Medium Time to Ref Imp 2 -3 limited scope, 6 -8 full scope Source/HL 7 WG ? FHIR Fitness Standards Dev Scope (including IG) Implementation Challenges Good-Excellent Medium Complex 39

Da Vinci Program Manager: Jocelyn Keegan, Point of Care Partners jocelyn. keegan@pocp. com Da Vinci Technical Lead: Dr. Viet Nguyen, Stratametrics LLC vietnguyen@stratametrics. com