DA VINCI USE CASE OVERVIEWS June 2019 ANSI

DA VINCI USE CASE OVERVIEWS June 2019

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 2

Program Status

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, Weill Cornell 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 4

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 5

Work Breakdown to Support CMS NPRM 6

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) 7

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

Use Case Details

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 STATUS Stage Ballot Reconciliation & Connectathons Implementation Guide DEQM FHIR IG (v 0. 2. 0: STU 1 Ballot 2) based on FHIR R 3 • 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) MRP-Reference-App 30 Day Medication Reconciliation Reference Implementation MRP-Payer-App MRP-Operation-Submit. Example MRP-Sample-Patients • Initial example of how Da Vinci funding expandable framework • Multiple groups providing resources to build out measures beyond Da Vinci Colorectal Cancer Screening Reference Implementation • Evaluating missing components to expand types of measures/patterns that could leverage framework (i. e. , public health) Confluence Artifacts COL-Collect. Data-App COL-Submit-App Data Exchange for Quality Measures (DEQM) 10

Data Exchange for 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 11

Coverage Requirements Discovery SUMMARY STATUS • Providers need to easily discover which payer covered services or devices have Stage Ballot Reconciliation & Connectathons Implementation Guide CRD FHIR IG (v 0. 3. 0: STU 1 ballot 2) based on FHIR R 4 • 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. Reference Implementation CRD Git. Hub Repository • The discovery may be based on Confluence Artifacts Coverage Requirements Discovery (CRD) ‒ Specific documentation requirements, ‒ Rules for determining need for specific treatments/services ‒ Requirement for Prior Authorization (PA) or other approvals ‒ Specific guidance. ‒ 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) 12

Coverage Requirements Discovery • Providers need to easily discover which payer covered services or devices have ‒ ‒ Provider 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. Order Procedure, Lab or Referral Discover Any Requirements • 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 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) 13

Coverage Requirements Discovery 1. 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 2. Payer may request additional information from the provider EHR using existing FHIR APIs 3. 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 14

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 15

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) STATUS Stage May Ballot Reconciliation & Sept STU Ballot Implementation Guide DTR FHIR IG (v 0. 1. 0: Ballot for Comment) based on FHIR R 3 Reference Implementation DTR Git. Hub Repository Confluence Artifacts Documentation Templates and Payer Rules (DTR) ‒ 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 16

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 18

Prior Authorization Support SUMMARY STATUS • A FHIR-based B 2 B process to allow implementers to use existing IT infrastructure resources for exchanging prior authorization. Existing business agreements can also be reused. Stage September STU Ballot Implementation Guide Prior Authorization Support – CI Build Reference Implementation Prior Auth Support Git. Hub Repository Confluence Artifacts Prior Authorization Support • 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 X 12 N 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. 19

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 20

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 21

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 22

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

Health Record Exchange: Health Record Exchange Framework/Library SUMMARY STATUS • 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. Stage July STU Ballot Implementation Guide HRex – CI Build • Da Vinci HRex Implementation Guide (IG) will make use of US Core profiles that are based on the FHIR R 4 specification wherever practical. The HRex IG will use the HL 7 FHIR Release 4/US Core STU 3 specification as its base but will provide additional guidance and documentation to support implementations that follow the HL 7 FHIR STU 3/US Core STU 2 and HL 7 FHIR DSTU 2/Argonaut specifications. Reference Implementation N/A Confluence Artifacts Health Record Exchange Framework (HRex) • 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. R 4 US Core profiles) and deprecated in this guide on publication in the updated standard. 24

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

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

PDex: Provider-Health Plan Exchange via CDS-Hook/SMART-on-FHIR • • • DSTU 2 STU 3 R 4 EMR User. Id Patient. Id Encounter. Id Appointments (subscriber. Id) JWT for access • • Call Hook SMART APP R 4 Appointment -book CARD Member Query Summary • • • Review • • • Query EMR for Patient Record Query EMR for Coverage Search by Subscriber. Id Search by Patient Demographics Review > Select > Write • • • Payer Provide Access Token with US Core Scopes Provide URL Link to Smart App FHIR Entrypoint Make Capability. Statement available Human Readable result of Member Query • No data found • Unable to match individual • N records returned Query Payer using Access Token Default Parameters from Provider constrain search Present US Core Records for Provider selection Get EMR Metadata Write constrained by write options in EMR Write document. Reference (Optional – complete or selected Document. Bundle + PDF) 27

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

Health Record Exchange: Payer Data Exchange (PDex) Formulary SUMMARY STATUS • 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. Stage July STU Ballot Implementation Guide PDex Formulary Draft IG Reference Implementation PDex Formulary Git. Hub Repository • 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. Confluence Artifacts Payer Data Exchange (PDex) 29

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

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 Git. Hub Repository Confluence Artifacts Payer Data Exchange (PDex) 31

Alerts/Notifications: Admit/Discharge Notifications, Clinical and Administrative Events SUMMARY STATUS • Current Admit and Discharge notifications typically use an HL 7 V 2 ADT message. Stage 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. Implementation • FHIR resources can be used to transport patient admission and discharge Guide 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 Reference of the massaging based on input from the various stakeholders. The goal is to Implementation provide a FHIR based standard for the definition and exchange of relevant alerts and notifications Confluence Artifacts • Coordination with Argonaut work on the Subscription model (to make it event September STU Ballot TBD Alerts/Notifications 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 32

Alerts/Notifications 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 33

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

CMS NPRM Requirements for Covered Payers Blue Button 2. 0 -- 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 35

Payer Coverage Decision Exchange Member authorization Current treatments Conditions/diagnoses supporting each treatment Payer 1 Clinical Guideline References (where appropriate) Payer 2 Scope of Prior Authorizations (where appropriate) Supporting Documentation 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 STATUS Stage Planning/Discovery Implementation Guide TBD Reference • Patients need accurate, timely access to cost of medical care prior to delivery Implementation of care in order to become better stewards of their healthcare dollars. Exposing cost of services/devices and calculated Care Plan Pretreatment Estimate Confluence within an EMR workflow can lead to clinician/patient care plan decisions with Artifacts increased patient adherence TBD • 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. 37

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

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 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 Da Vinci Program Office: Bob Dieterle, Enable Care rdieterle@enablecare. us