HL7 Da Vinci Project July 19, 2021
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
HL7 Da Vinci Project
July 19, 2021
Antitrust Policy
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
Project Challenge
To ensure the success of the industry’s shift to Value Based Care
Transform out of Controlled Chaos: Collaboration: Success Measures:
Develop rapid multi-stakeholder Minimize the development and Use of FHIR®, implementation
process to identify, exercise and deployment of unique solutions. guides and pilot projects.
implement initial use cases. Promote industry wide standards
and adoption.
3
Da Vinci 2021 Multi-Stakeholder Membership
Use Case Focus Areas
Quality Improvement
Clinical Data Payer Data Payer Data
*
Data Exchange for Exchange Exchange Exchange
Quality Measures STU2
Member Access
Payer Data Exchange: Payer Data Exchange: Clinical Data
Clinical Data Exchange
Gaps in Care &
Information
Formulary
* Directory
* Exchange
Payer Coverage
Decision Exchange
*
Patient Cost
Transparency Notifications
*
Coverage / Burden Reduction
Coverage
Requirements
Discovery STU2
Patient Data Exchange
Member Attribution Risk Adjustment
Documentation
Templates and Rules Performing Laboratory
Process Improvement Reporting
Prior-Authorization Publishing
Support Use Case Balloting
HL7 Standards Aligned with specific ONC or CMS rule
Build
Progress
Future Named or supports final CMS or ONC rule 5
Future Build Ballot Published/ing
Use Case
Standard Phase
Connectathon
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
Discovery Assemble Team Requirements
RI Tech
Project start Approach
Build Initial RI Test RI Update Final RI
RI Development
Build Data Set
Build Test Set
Week 0 2 4 6 8 10 12 14 16
Work with appropriate HL7 workgroup for IG sponsorship and input
7
How Da Vinci Solves Business Challenges
Patient - Payer Data Access APIs
Use Case Status Core Capabilities Regulatory Impacts Implementer Progress
Enables a health plan to share key clinical CMS Interoperability and Patient Access final 6 Connectathons
data and patient history with application of rule (CMS-9115-F) – enforcement begins on
STU1 patient’s choice. July 1, 2021 – use to make patients' clinical Active implementations underway,
Published (USCDI) data available via Patient Access emerging vendor and payer go lives in
Payer Data API. preparation for 7/1 rule.
Exchange
Enable payers to share drug estimated cost CMS Interoperability and Patient Access final 6 Connectathons
and information (drug formulary) for rule (CMS-9115-F) – enforcement begins on
STU1 patients/consumers applications. Improves July 1, 2021 – use to make formulary Active implementations underway,
Published clarity of patient cost under current or information available via the Patient Access emerging vendor and payer go lives in
Formulary potential health plan. Improve consumers API and via publicly accessible API. preparation for 7/1 rule.
ability to shop plan coverage better.
Enable patient to more easily understand CMS Interoperability and Patient Access final 6 Connectathons
what providers, facilities, pharmacies are in rule (CMS-9115-F)– use to make provider
STU1 the network covered by the current or directory data available via publicly Active implementations underway,
Published potential future plan. Increases accessible API. emerging vendor and payer go lives
Directory transparency of available service providers underway.
at patient specific level.
Provide data exchange standard in support Rules Impact Evaluation Underway N/A
of payers and providers to display cost • Consolidated Appropriations Act HR-133
information to patients in advance of (No Surprise Billing)
Discovery services.
• CMS Transparency in Coverage Final Rule
Patient Cost
(CMS-9915-F) 1/1/2022
Transparency
• Hospital Price Transparency – 1/1/2021 9
Implementation Guides (IG) Options for
Patient Directed APIs
FHIR IG
FHIR Resource Definition
Da Vinci
Patient Direct API 1/1/21
Directory
Directory Access API
(PLAN NET)
Other related regulation
Da Vinci
PAYER Formulary Individual
FHIR Accelerator Commentary
Product 1. CMS has proposed use of specific
guides in December Reducing
Plan Design Da Vinci
Burden NPRM
Provider Payer Data
2. FHIR Community is working
OAUTH Security Layer
Exchange Consumer collaboratively to ensure the specific
PDEX* for Apps guides meet needs of the final PAAPI
Clinical Data rule and the proposed rule
Operational 3. All guides are Draft Standards for
Support Trial Use (DSTU and approved or
moving towards a published version
of STU1.
CARIN IG for 4. NOTE: Da Vinci Directory and CARIN
Provider Blue Button ® for Real Time Benefit Check for
System Payer and consumer facing applications does
Pharmacy Claims not fall under 7/1/21 Patient Directed
Data API regulations but is called out in
Member NPRM and as a resource on other
Operational Portal
PBM proposed rules
Support 5. CMS has added provider to payer
CARIN and payer to payer requirements to
leverage this subset and additional
PBM Real Time named FHIR IGs.
Benefit Check
for Pharmacy
Patient
Portal
10Health Record Exchange (HRex)
Benefits
• Creates a consistent
framework to exchange clinical
data between Providers and
Payers
FHIR • Enables consistent,
constrained use of FHIR and
US CORE profiled data
US specific resources across all
Da Vinci
Da Vinci data exchange
CORE Implementation Guides
Profiles • Focuses on nuance of
resources like Provenance
which differs by collection
source, or resources currently
not yet in USCDI and US Core
e.g., Coverage
11Payer Data Exchange (PDex)
Benefits
• Creates a full picture of all patient activities
• Providers may be unaware of all the patient clinical activities
outside their facility
• Addition of payer-based data expands the scope of Provider data
information available to the patient and provider to support from CDAs and
clinical decision-making and care planning other sources
• Improves quality of information shared by using FHIR
standard
Alerts (e.g, ADT)
Clinical data based FHIR
Patient Visits Provider Immunizations
resources
Payer Makes
Laboratory (eg,
Data national labs)
Available to
Provider PBM (meds)
EOB
System of record
Adjudication
Payer Gathers Claims based clinical FHIR
Provider Data Extract Definition
EHR Initiates Request
Data Received resources Claims
From Source
System(s)
PDex Information Sources/Flow
12Payer Data Exchange (PDex): Provider Directory
PAYER
RESTful GET
Synchronous
Provider Directory
FHIR
API
Third Party Asynchronous
Application
Pharmacy Directory
Benefits
• Provides a standard approach for requesting and receiving Provider information based on a patient's Insurance plan
• Enables directory to be called as a service by applications for integration of provider search into workflows
• Supports patients’ ability to find providers across multiple plans
• Increases transparency to patients about provider availability in their plan
13Payer Data Exchange (PDex): Formulary
PROVIDER
Benefits
What are my medications? • Enables patient and provider
applications to understand basic
information about their plan or
Medication1, Medication2, Medication3 potential plans formulary
RxNorm coverage
Electronic Health
Record from Provider • Patients can understand the tier
Medication Copays
and alternatives for drugs that
Med Tier Copay have been prescribed, and to
Tell me about Medication1 compare their drug costs across
Med1 1 $5
PAYER
Med1 4 $30 different insurance plans
Med3 2 $10
Medication1 info • Improve transparency for
patients shopping new plans, or
Tell me about Medication2 seeking to understand
alternative options vs current
Medication2 info PDF
• Free data to be used by
Tell me about Medication3 consumer facing applications to
Formulary Service improve shopping options
Medication3 info
Mobile app determines the cost of each
medication under patient's current health plan
14Payer to Payer APIs
Use Case Status Core Capabilities Regulatory Impacts Implementer Progress
Enables a health plan to share key clinical Rules Impact Evaluation Underway 6 Connectathons
data and patient history with application of CMS Interoperability and Patient Access final
STU1 patient’s choice. rule (CMS-9115-F) –– use to make patients'
Published clinical (USCDI) data available to new Payer,
Payer Data
named specifically as a proposed resource in
Exchange
2020 NPRM CMS-9123-P
Ability for payer to share active treatment to Rules Impact Evaluation Underway 6 Connectathons
increase continuity of care. Includes current Functionality meets requirement for January
utilization management decisions and 1, 2022 initially introduced in CMS
supporting data. Focus is to reduce rework Interoperability and Patient Access final rule
Coverage Decision STU1 by patient and provider when patient (CMS-9115-F) –– use to make patients'
Exchange Published changes coverag clinical (USCDI) data available to new Payer,
referenced as a resource in 2020 NPRM
CMS-9123-P
15Payer to Payer Exchange:
On the Way to Patient Access & Portability with
FHIR APIs
16Opportunity to Further Interoperability
• CMS Regulation for Payer to Payer sets a minimum bar for electronic data exchange
• Advanced interoperability requires codified data that is computable
• Da Vinci community members are promoting early adoption of Payer Data Exchange (PDex) as
their FHIR API of choice for January 1, 2022 deadline
• Goal is to voluntarily meet and exceed rules set by CMS for patient access via 3rd party
applications, where minimum is FHIR API
While technical term is payer to payer, this work will improve patient’s portability across payers, and
reduce burden on patient and providers to reshare critical clinical patient information.
17Payer Coverage Decision Exchange
Patient enrolls in new plan
Member Authorization
Current Treatments
Conditions/Diagnoses Supporting Each Treatment
Clinical Guideline References (where appropriate)
PAYER 1 PAYER 2
(“new payer”) Scope of Prior Authorizations (where appropriate) (“old payer”)
Supporting Documentation
Benefits
• Supports continuity of treatment when patients enroll with a new payer by enabling a transfer of “current active treatments” between the prior payer and the new payer
• Reduces the need for providers and/or patients to resubmit supporting documentation to the new payer in order to continue patient treatment
• Reduces interruption in care plan and medication adherence
• Reduces waste and rework by all parties 18Provider - Payer Access APIs
Use Case Status Core Capabilities Regulatory Impacts Implementer Progress
A defined format to send unsolicited May be leveraged to meet ADT notification for 6 Connectathons
notifications to the appropriate actors when select health systems In wait mode until FHIR subscription model
STU1 triggered by an event or request. Provides is matured in R5.
Published enough information to understand what the Several community members have
Notifications notification is about. leveraged this utility IG across several
early adoption FHIR project.
Ability to enable provider to share clinical None 9 Connectathons
STU1 data to payers, other providers in workflow Multiple early adopter projects in flight
across several workflows.
Ballot
Clinical Data Reconciliation
Exchange
Enables a health plan to share key clinical Rules Impact Evaluation Underway 6 Connectathons
data and patient history with application of CMS proposed extension of this IG to support Early adoption underway. Some delay for
STU1 patient’s choice. Provider to Payer exchange of prior provider implementations due to COVID
Published authorization data in December 2020 NPRM response and impact at provider
Payer Data CMS-9123-P Specific guide named in NPRM organizations.
Exchange
Provide data exchange standard in support Rules Impact Evaluation Underway Public calls TBD
of payers and providers to display cost • Consolidated Appropriations Act HR-133
information to patients in advance of (No Surprise Billing)
Discovery services.
• CMS Transparency in Coverage Final Rule
Patient Cost (CMS-9915-F) – 1/1/2022
Transparency • Hospital Price Transparency – 1/1/2021 19Notifications
PRIMARY CARE
HIE/HIN
SPECIALTY CARE Any care team
member can be
connected directly
Site Where or via an
Notifiable Event intermediary
Occurred INPATIENT SERVICES (e.g., HIE)
Potential Interactions:
PAYER
1) Push to “registered” member
(perhaps via payer care team information)
2) Push to intermediary
20Reducing Prior Authorization Burden
Use Case Status Core Capabilities Regulatory Impacts Implementer Progress
Enables exchange of coverage plan Named in the NPRM CMS Interoperability 9 Connectathons
requirements from payers to providers at the and Prior Authorization (CMS-9123-P) by Early adopters and pilots underway
time of treatment decisions, patient specific January 1, 2023, FHIR-based DRLS API
STU1 with a goal to increase transparency for all
Published parties of coverage that may impact
services rendered i.e., is prior authorization
Coverage Requirements
required, are there other predecessor steps;
Discovery
lab tests required, physical therapy
Builds on CRD to specify how payer rules Named in the NPRM CMS Interoperability 8 Connectathons
can be executed in a provider context to and Prior Authorization (CMS-9123-P) by Early adopters and pilots underway
ensure that documentation requirements are January 1, 2023, FHIR-based DRLS API
STU1 met. Provider burden will be reduced
Published because of reduced manual data entry, i.e.,
electronic questionnaires from payers,
Documentation
extract data to pre-populate response
Templates and Rules
Defines FHIR based services to enable Named in the NPRM CMS Interoperability 6 Connectathons
provider, at point of service, to request and Prior Authorization (CMS-9123-P) by Early adopters and pilots underway
authorization (including all necessary January 1, 2023, FHIR-based electronic Prior
STU1 clinical information to support the Authorization Support API
Published request) and receive immediate
Prior-Authorization authorization from Payer (incorporates
Support HIPAA Tx standards)
DRLS = Document Requirements Lookup Service (DRLS) is CMS’ name for the combination of CRD + DTR.
Notice of Proposed Rulemaking (NPRM) Press Release found here. Note: Final CMS’ Interoperability and Prior Authorization Rule links are unavailable pending HHS review. 21Coverage Requirements Discovery, Documentation
Templates & Rules, & Prior Authorization Support
Coverage Requirements CDS Hooks Coverage Requirements
Discovery Discovery
EHR/PROVIDER BACK
OFFICE SYSTEMS
Documentation Templates Documentation Templates
FHIR APIs
and Coverage Rules
PAYER
and Coverage Rules
Transformation
Transformation
X12 278
Optional
Prior Authorization
Layer
Layer
Prior Authorization Support
Support
X12 275
if required
• Improve transparency
• Reduce effort for prior authorization
• Leverage available clinical content and increase automation
22Coverage Requirements Discovery (CRD)/
Documentation Templates & Rules (DTR)
Benefits
• Takes guesswork out of patient specific
coverage by sharing authorization or
process requirements in workflow
• Improves transparency of patient and
procedure specific rules to provider and
patient
• Exposes information about patient
benefits when care team is most likely
with or near patient, so options can be
discussed and decided upon
23Automating Quality Improvement
Use Case Status Core Capabilities Regulatory Impacts Implementer Progress
Focus is on creating a framework to make No current regulatory impacts 8 Connectathons
quality measure collection, attestation and In production across multiple payer-
STU2 proof identifiable, collected and transported provider sites.
Published between trading partners in a repeatable Often initial use case selected for high
Data Exchange for way. Work underway to expand examples. financial and shared value across trading
Quality Measures partners.
To support value-based data exchange by: No current regulatory impacts 9 Connectathons
Represent open and closed gaps in care
BALLOT Define how providers and payers can be
Reconciliation informed of gaps and closings
Gaps in Care & Define a close the loop framework between
Information vendor/payer and providers.
Ability to enable provider to share clinical No current regulatory impacts 7 Connectathons
data to payers, other providers in workflow.
BALLOT
Reconciliation
Clinical Data
Exchange
Provides ability for trading partners to No current regulatory impacts 3 Connectathons
validate patients/members in common to In production or early adopter projects
STU1 ensure for secure transfer of correct across multiple payer-provider sites.
Publishing population. Developed to streamline Seen as a utility across many early
Member Attribution matching for DEQM use case. Expanded adopters.
as applicable across many FHIR APIs
24Data Exchange for Quality Measures
Benefits
Submit Measure Data
• Quality measures are defined as
1. Submit computable artifacts
OperationOutcome • Framework automates data collection
Aggregator or Payer
Provider and quality measure reporting
• Eases the burden of identifying quality
measures applicable to specific patients
Collect Measure Data
• Minimizes the burden of manual data
2. Collect abstraction for measure reporting
Return Measure Data
Payer Provider
Subscribe for Measure Data
3. Subscribe
OperationOutcome
(future)
Aggregator Provider
25Gaps in Care
PAYER PROVIDER Benefits
• Facilitates the exchange of gaps in
care and quality measures between
Provider System/EHR
providers and payers
• Identifies gaps based on patient
Receives list of criteria and contractual agreements
Analysis triggered Request triggered
patients/gaps
(e.g., patient (e.g., patient visit,
• Supports the exchange of clinical data
enrollment, eligibility check,
to close clinical and information gaps
scheduled, etc.) manual, etc.)
Automatically or manually prospectively vs retrospectively
queried for missing data or • Leverages the FHIR-based, quality
exceptions measure framework
Based on measure
criteria, payer determines • Reduces manual data retrieval and
qualifying patient data is cost associated with current practices
missing
• Gets the right triggers to right end
Missing Service users in patient care workflow
Data Found performed increasing probability of positive
Patient list with impact
gaps identified
• Improve quality of information shared
by using FHIR standard
Provider sends
• Can be used for single patient or with
new data to payer
population of patients 26Member Attribution
1
Producer/Consumer enter Benefits
relationship and agree on
PRODUCER attribution method and
CONSUMER • Allows the provider and payer to
(e.g., Payer) (e.g., Provider) establish and maintain an accurate list
need for a list of patients that are attributable to the
provider
Producer Consumer receives • Attribution list supports exchange of
creates initial 2 list & historical other information including gaps in
attribution list information care and quality measures
• Creates common format across
payers and providers, reducing waste
Request and maintenance
Changes needed
Producer Consumer reconciles
adjusts 3a list via their own
algorithm/ list attribution algorithm
No changes needed Current IG
Producer starts 3b Future version IG
sending list on
agreed upon
4 Consumer loads data Out of band process
cadence to various systems to
support various use
cases
27Emerging or Future Use Cases
Use Case Status Core Capabilities Regulatory Impacts Implementer Progress
Creating standard methodology (format) for None Public calls started in March 2021
payers to communicate coding gaps to
Discovery providers for an individual or a group of
patients.
Risk Adjustment
Timely and accurate information exchange None N/A
within the performance period. Focus on
Identifying information that only a payer would have
Participants financial targets, spend, CCFs and quarterly
VBC Cost quality payments. Information at lowest level
Performance Reports of granularity. Access via APIs.
Goal is to share clinical details of specific None N/A
lab results between providers, payers and
lab partners. Only a small fraction of lab
TBD data flows today, Define framework to
Performing Laboratory expand breadth and scope of data
Reporting exchange.
Enable exchange of patient reported data to None N/A
payer and provider partners.
TBD
Patient Data
Exchange
28Join the Da Vinci Community
29Da Vinci Community Support
Most Recent Slides
and Updates
Community
Announcements,
Updates and
Page Tree Navigation Easily Resources
Find Nested Content like Da
Vinci Calendar 30Implementation Guide Dashboard
Quick Links & Look at All
Implementation Guides
Link to Implementor Support Page
31Implementor Support
FHIR 101 Resources
IG Summary &
Relationships
FHIR & DV
Community Tools
Learn about
Implementation Guides
https://confluence.hl7.org/display/DVP/Da+Vinci+Implementer+Support 32Join the Community
Getting Started
1. Register for Confluence
2. Sign up for Listserv
3. Find Implementer Pages
4. Download IGs and
Resources
5. Watch for Meetings,
Create an Account to Connectathons
Watch Key Pages 6. View Demo and
Testimonial Recordings
Sign Up for Listserv for Project 7. Access Reference
Updates Implementation Code,
Orientation Resources for Public New Sandboxes
to Da Vinci
33Membership Support
Summary Ways to Engage
Number of
Vote on Pledge Access to Access to Use Provide
Type Cost (000s) Sponsored
Operating Resource Playbook Case Artifacts Feedback
Providers*
Member $10-90 1 1-2 X X X X
Partner In Kind - - X By Partner By Partner By Partner
Clinical
Advisory None - - X X X X
Council
Use Case
Clinical None - - X X X X
Advisor
Community None - - - - X X
• Premier and Associate Members have the opportunity to nominate partner organizations to join the Operating Committee (proxy
membership) and must be approved by the operating and steering committees.
• Clinical roles are appointed or contracted.
3535Project Structure
• All members sign identical Statement of Understanding between member & HL7
• Initial agreement 2-year commitment
• All outputs to HL7 open-source licensing for public use
• Coordinate closely with HL7 standards development process to obtain workgroup
ownership of Implementation Guides
• Commitment to implement in 2021
Da Vinci expanding 2021 membership. Focus on
missing stakeholders: small and community-
based providers, regional, Medicaid, CHIP, QHP
Plans, missing integration partners; EHRs,
platforms, population health. Contact
davincipmo@pocp.com if interested.
36Governance Structure
STEERING COMMITTEE Clinical Advisory Council
Dr. Steve Waldren, AAFP
HL7 - 1 Dr. Ed Yu, Sutter Health
Payers -3 Providers - 2 IT Vendors- 2 CMS - 1
Sagran Moodley* Deepak
Program Manager & Technical Director
United Sadopagan Hans Buitendjik**
Dr. Viet Nguyen
Kirk Anderson Providence St. Cerner Alex Mugge Dr. Chuck Jaffe
Cambia Health Joseph Ryan Bohochik CMS HL7
Mike Funk Dr. Michael Myint Epic
Humana MultiCare
Jocelyn Keegan
OPERATING COMMITTEE
Use Case 1 Use Case 2 Use Case n+
Project Lead Project Lead Project Lead
DEPLOYMENT COMMITTEE
Update as of January 27, 2021 *Chair **Co-Chair 37Existing Provider/Payer Membership Model
Operating
Sponsor PMO Pledge Access to Access to Use Provide
Level Cost (000s) Committee
Partners* Opportunity Resource Playbook Case Artifacts Feedback
Vote
Premier $ 90k 1 2 X X X X X
Associate $ 75k 1 1 X X X X X
Sponsored
Deployment $75 or 90 1-2 X X X X X
Partner
Sponsor $ 50k 1 - - X X X X
Sponsored - 1 - - X X X X
Member $ 10k - - - X X X X
* Premier and Associate Members have the opportunity to nominate partner organizations to join the
Contributor In kind (proxy -membership)
Operating Committee - and must be
- approvedXby the operating
X X
and steering X
committees.
3838Structure and Operational Role Attributes
STEERING COMMITTEE OPERATING COMMITTEE
• Senior level executive, can make • Prioritization of use cases and project focus,
decisions and commit organization approval for “in kind” and project fees
resources
• Leader and/or influencer across home organization
• Driving interoperability strategy
• Work closely/aligned with senior leadership at home
within home organization and
organization, can queue up commitment and
responsible for coordination with
decisions and drive to conclusion
industry
• Understands and will own HL7 standards
• Final vote on budget approval and
relationship, commitments
high-level direction setting based
upon Operating Committee direction • Roll up sleeve and problem solve use case
development and inventory, priorities, details
• Technology and business ownership
to drive “business case” approval • Identify and gain access/time for “in kind” resources
for priority use case work
3939Clinical Advisory Roles
Operating Committee
Steering Committee
Use Case Team
Clinical Advisory Use Case
Council Clinical Advisor
Program Management Office
Clinical Advisory Council – strategic clinical advisors for the Steering Committee and PMO
Use Case Clinical Advisor – participates in use case development as clinical SME 40Clinical Advisory Roles
Provide
Access to Use Case Participation
Level Fees Advisory Council Seats Training and Support Feedback on
Requirements In Marketing Activities
Use cases
Council None Individual X X X X
Use Case Non None X X X X
The Clinical Advisor provides strategic advice to the Steering Committee and
Program Management Office on relevant industry direction, clinical workflow,
prioritization of specific use cases and other topics relevant to Da Vinci decision
making.New Membership Recommendation Template Process 1. Member Completes 2. Submits to PMO 3. Review/Update 4. PMO Submits Final to Da Vinci Steering Committee for Approval
Antitrust Policy
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
43Membership Recommendation – Denote
Requested Approval Level:
Company Name q Premier
Mission : q Associate
q Sponsor
Vision :
q Sponsor(ed) –Denote Sponsoring Org
Basic Description of Core Business Related to VBC q Deployment Member
Use Cases: List Da Vinci use cases prospective member will participate in and plans to implement in q Refer to Community Member
2021. q Differ to 2022
Experience: Describe role as adopter of new technology, workflows and standards. Describe current
state in FHIR community and/or subject matter expertise to bring to Da Vinci work
Senior Management: Key leadership supporting goals of DV and VBC, potential commitment to STATUS: To Be Completed by PMO
leadership of membership category beyond in kind on projects specific work. Demonstrate support for q Approve
organization to participate in connectathons, early adopter with sufficient resourcing and internal support.
Advocate for getting partners to the table. q Pended
q More Information Requested
Pilot Potential: Describe potential pilot projects, geographical placement to existing or new to Da Vinci
organizations with a highlight toward provider.
Relevant Disclosure: Any potential conflicts or opportunities, unknown aspects of organization relevant
for Da Vinci Steering and PMO to be aware of i.e., ownership stake in partners, ability to bring Provider/Payer Links:
subsidiaries to bear on program • URLs to key parts of partner orgs
Lines of Business or Wholly Owned Subsidiaries:
Primary Sponsor: Current DV members
Company Links: Key URLS Secondary Sponsor: Optional current DV member
PMO recommendation summary.Macro View of Organization - X
Add 1 -2 Slides Max • Screenshots of existing
content/demographic information is fine
• Include in graphical or text format
‒ Geography • Goal is a summary view of assets and
‒ Lives Covered breadth new partner offers
‒ Key partners in market
‒ Key technologies in use (companies and
named technology i.e. Aegis for Testing
Suite and early adopter of CCDA across
15 provider/payer partners)
‒ Size of organization
‒ Breadth/focus of core services
‒ Relevant Organization Breakdown,
included parts of org likely to participate
in Da Vinci activelyDa 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 Project Manager:
Vanessa Candelora, Point of Care Partners
vanessa.candelora@pocp.comYou can also read
