The HL7 Da Vinci Project is an industry initiative to develop payer/provider interoperability use cases based on FHIR for value-based care. Da Vinci members write free implementation guides and create open-source reference implementations which any healthcare organization can use. This presentation will cover the project history, give a summary of current use cases, explain the development process, and dive into the technical aspects of a few key use cases. We will also cover how UnitedHealthcare has leveraged Da Vinci Project in our EMR Integration Service Layer (EISL) which acts as a gateway between that payer’s internal systems and their network providers.

1. Payer/Provider - Interoperability &
HL7 Da Vinci Project
HealthDev: FHIR Meetup during the JP Morgan Healthcare
Conference #2

2. HL7 Da Vinci Project
2

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

4. Empower End Users to Shift to Value
Source: © 2018 Health Catalyst
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®
4

5. Focus
Da Vinci is Driving 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
Quality Measure Reporting
Encounter Notifications
Payers Providers
5

6. 2019 MEMBERSHIP

7. Vendors
7
Membership by Primary Industry Role
Payers (15)
Providers
Payers
Partners
For current membership:
http://www.hl7.org/about/davinci/members.cfm

8. 8
2019 Implementation Guide Schedule
Project Process
 Define requirements:
 Clinical
 Business
 Technical
 Testing
 Create Implementation Guide (IG)
 Create and test Reference Implementation
(RI) (prove the IG works)
 Pilot the solution
 Deploy the Solution
Health Record
Exchange
Framework / Library
Documentation
Templates and
Coverage Rules
Gaps in Care &
Information
Coverage
Requirements
Discovery
Performing
Laboratory Reporting
Data Exchange for
Quality Measures
Prior-Authorization
Support
Risk Based
Contract Member
Identification
Alerts/Notifications:
Transitions in Care,
ER admit/discharge
Patient Cost
Transparency
Chronic Illness
Documentation for
Risk Adjustment
Payer Data
Exchange
Use Case Status
Health Record
Exchange: Patient
Data Exchange
Payer Coverage
Decision Exchange
Clinical Data
Exchange
Payer Data
Exchange:
Provider Network
Payer Data
Exchange:
Formulary
In Ballot Reconciliation
Early February or February 2020 Ballot
In Build
In Discovery

9. Documentation
Templates and Rules
Gaps in Care &
Information
Coverage
Requirements
Discovery
Performing Laboratory
Reporting
Data Exchange for
Quality Measures
Prior-Authorization
Support
Risk Based Contract
Member Identification
9
Alerts / Notifications
Patient Cost
Transparency
Chronic Illness
Documentation for
Risk Adjustment
Payer Data
Exchange
Use Case Focus Areas
Patient Data Exchange
Payer Coverage
Decision Exchange
Clinical Data
Exchange
Payer Data Exchange:
Directory
Payer Data Exchange:
Formulary
QualityImprovement
ClinicalDataExchange
Coverage/BurdenReduction
Process Improvement
Payer Data
Exchange
MemberAccess
Clinical Data
Exchange
In Ballot Reconciliation
Early February or February 2020 Ballot
In Build
In Discovery
Use Case
Status
Documentation
Templates and Rules

10. Burden Reduction

11. 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)
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)
11
STATUS

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

13. 13
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
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)
STATUS

14. 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.
Stage September STU Ballot
Implementation
Guide
Prior Authorization
Support – CI Build
Reference
Implementation
Prior Auth Support
GitHub Repository
Confluence
Artifacts
Prior Authorization
Support
14
Prior Authorization Support
STATUS

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

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

17. Quality Improvement

18. 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)
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)
18
STATUS

19. Quality Data Quality Measures
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
1. Submit
3. Subscribe
2. Collect
Payer Aggregator
Submit Measure Data
OperationOutcome
Provider
Collect Measure Data
Return Measure Data
Payer
Aggregator
Subscribe for Measure Data
OperationOutcome
Provider
19

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

21. Clinical Data Exchange/Member Access

22. HRex
Health Record exchange
Framework/Library
Interactions and Profiles
PDex
Payer Data exchange
MRP
Medication Reconciliation
Post-discharge
Additional Measures for
DEQM IG
DEQM
Data Exchange for
Quality Measures
Framework
CDex
Clinical Data exchange
Health Record Exchange

23. 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.
Stage July STU Ballot
Implementation
Guide
HRex – CI Build
Reference
Implementation
N/A
Confluence
Artifacts
Health Record
Exchange Framework
(HRex)
23
STATUS
Health Record Exchange:
Health Record Exchange Framework/Library

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 DSTU2, STU3,
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)
24
STATUS

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

26. 26
PDex: Provider-Health Plan Exchange via CDS-Hook/SMART-on-FHIR
Payer
R4
EMR
DSTU2
STU3
R4
Call Hook
SMART APP
Appointment
-book
CARD
Review
Member
Query
Summary
Review >
Select >
Write• Get EMR Metadata
• Write constrained by write options in EMR
• Write documentReference (Optional – complete or selected DocumentBundle + PDF)
• 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
• UserId
• PatientId
• EncounterId
• Appointments
• (subscriberId)
• JWT for access
• Query Payer using Access Token
• Default Parameters from Provider constrain search
• Present US Core Records for Provider selection
• Query EMR for Patient Record
• Query EMR for Coverage
• Search by SubscriberId
• Search by Patient Demographics

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

28. Industry Progress and HIMSS
Demonstration Update
28

29. 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%
Each step represents a provider – payer exchange using FHIR IG
29
UNLOCKING PAYER INFORMATION
TO IMPROVE CARE
HIMSS19 Demonstration
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.
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 Patient Patient Patient Patient1
2
3
4
PCP
Schedul
e Appt
with
Payer
Admitted
for
Angioplast
y
Discharged
with O2
Therapy
PCP
Cardiologist Hospital
Payer
Med Rec
PayerPayer
Patient Data
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.

30. ONC Annual Meeting
Da Vinci Meeting & ConnectathonHL7
Connectathon
Da Vinci
Connectathon &
Working Session
BALLOTED in MAY
 STU Data Exchange for Quality Measures
(DEQM)
 STU Coverage Requirements Discovery (CRD)
 Comment Documentation Templates & Rules
(DTR)
HL7
Connectathon
2019 Implementation Guides and Connectathons
BALLOTED EARLY SEPTEMBER
 STU Health Record Exchange (HRex)
 STU Payer Data Exchange (PDex)
 STU PDex Formulary
 STU Clinical Data Exchange (CDex)
20202019
30
MAR APR MAY JUN JUL AUG SEP OCT NOV DEC JAN FEB MAR
FEBRUARY BALLOT (Dec 27 – Jan 26)
 STU STU Patient Cost Transparency
 STU RBC Member ID and Bulk Data
 STU Alerts / Notifications
BALLOTED SEPTEMBER
 STU Documentation Templates and Rules (DTR)
 STU Payer Coverage Decision Exchange
 STU Prior Authorization Support (Prior Auth)
HL7
Connectathon
BALLOTTED EARLY FEBRUARY
 STU PDex Payer Directory
HIMSS20
Demonstration
HIMSS19
Interop
Showcase
HL7
Connectathon

31. Follow Progress, Test, Implement
FIND
• Listserv Sign Up
• Background collateral
• Active Use Case content
• Implementation Guides
• Reference Implementations
• Calendar of Activities & Updates
RESOURCES
• HL7 Confluence Site -
https://confluence.hl7.org/display/DVP/
• Where to find Da Vinci in Industry -
https://confluence.hl7.org/display/DVP/Da
+Vinci+2020+Calendar
• Use Case Summary and Links to Call In &
Artifacts -
https://confluence.hl7.org/display/DVP/Da
+Vinci+Use+Cases
• Reference Implementation Code
Repository - https://github.com/HL7-
DaVinci
31

32. UnitedHealthcare EMR Integration
Services Layer (EISL)

33. © 2019 United HealthCare Services, Inc. All rights reserved.
EISL Vision
EISL sits at the edge between UHC clinical systems on one side and provider
systems on the other, presenting a unified standards-based interface
between the two. It follows the three pronged vision:
All UHC members receive appropriate care based on best
practices.
EISL
Triple Aim
All authorized UHC participating network providers have
immediate access to current actionable clinical, administrative,
claims, and policy data on our members at the point of care.
All UHC internal systems have complete, simple access to any
provider’s EHR data necessary to perform legitimate business
operations.

34. © 2019 United HealthCare Services, Inc. All rights reserved.
EISL Major Capabilities
• Lab Chase Service
- Automated gap closures for labs data
• Managed Pull Service
- Automated UHC member clinical data pull
• Data Exchange for Quality Measures – Medication Reconciliation Post
Discharge
- End points for providers to submit MRP attestations
• Payer Data Exchange (PDex)
- End point to request for UHC members’ lab data
UHC delivery channel for Da Vinci Project use cases
34

35. EISL Data Acquisition
Concierge
Service
EHR 1
EHR 4
EHR 3
EHR 2 DataAcquisition
Services
EHR 1
Lab 2
Lab 1
EHR 2
DEQM
MRP
COL
…
PDeX
Labs
Meds
Gaps in Care
LinkGateway
ClinicalSource(s)
FHIR
FHIR
FHIR
Individual Health Record
(IHR)JSON
CDSM
ECG
DataAcquisition
Apps
LCS
MPS
CCU
Flat File (from FHIR)
CCD
HL7
CCD, HL7
CCD

36. © 2019 United HealthCare Services, Inc. All rights reserved.
Credits
• HL7 Da Vinci Project
- Jocelyn Keegan: Program Manager, Point of Care Partners
- Viet Nguyen, MD: Technical Lead, Stratametrics LLC
• UnitedHealthcare
- Sagran Moodley: SVP, UHC Clinical Data Services
- Yogesh Rao: Director, Product Management
- Lukasz Nosol: Director, Clinical Integration and Interoperability
36

37. © 2019 United HealthCare Services, Inc. All rights reserved.
Questions?
Nick Radov
Sr. Principal Engineer, TLCP
UnitedHealthcare
UHC Clinical Services, CDSM
nradov@uhc.com
+1 (612)632-2612
37