Page tree
Skip to end of metadata
Go to start of metadata

A full Da Vinci PA implementation involves multiple use-case interactions. With the HIMSS 2020 interoperability showcase, we have the opportunity to validate whether multiple implementations can truly be "swapped out" for each other and to understand whether each participating actor/system is following the same specifications - FHIR version, hooks version, infrastructure services, etc.

For the interoperability showcase, the end-to-end flow will need to work for multiple versions of EHR, payer services and apps. Thus, we will typically need to standardize on one version of each FHIR API interaction, or make sure that the endpoints are flexible enough to support multiple versions. e.g. an EHR that uses order-select vs. one that uses order-review, or an EHR with STU3 vs. DSTU2.

Key interoperability interaction points

For the end-to-end flow, these are interoperable interactions between actors/participants that must be in-place:

  • CDS-Hooks
  • SoF app launch and UI environment
  • EHR FHIR endpoint
  • PAS submit and status API

Optional/potential interoperability interaction points

These are interoperable interactions that could be optional (inside the black box):

  • CQL and questionnaire library endpoint
  • X12 (278, 275, 278i)

Options for an end-to-end clinical scenario

Within a single PA interaction, each use-case step will need to be coordinated with the neighboring steps. The implementation options and considerations are in this grid:

Da Vinci Use-CaseProvider interactionPayer implementationLikely implementation optionsInteroperability needs across each actor/participantAlternatives
CRDCDS-Hook produced during medical orderRespond with coverage requirements, based on payer's coverage rules 
  1. Payer BYO service
  • same hook (order-select)
    • (across Cerner, Epic, ...)
  • same FHIR release (for resources that may vary across versions)
  • Payer CRD service supports multiple versions of hook
Display card with DTR SoF linkCard link is to payer's DTR implementation choice
  • EHR supports SoF launch with app context
  • Context passed via url link and browser state
DTRReview and supply PA questionnaireClinical evaluation and questionnaire, based on payer's rules for the medical service/order
  1. MITRE RI with payer-provided CQL and questionnaires, OR
  2. Payer-specific DTR app, using own rules and forms
  • external library implementation for rules & templates (opt 1 only)
  • same FHIR release (for EHR resources)
  • Embed library of CQL and questionnaire within RI
  • DTR RI supports multiple server versions
PASSubmit PA and receive status

Support submission and status service

(could this be an existing X12 intermediary - representing Availity, Change, etc.?)

  1. Supply to X12 payer endpoint (using 278, 275 and 278I), OR
  2. Process directly from FHIR interactions
  • DTR app uses same specification as expected by PAS service and can direct to appropriate endpoint, based on payer

Alternatively, we can limit the combination of actors/roles to just those that expect the same versions, e.g. based on a particular clinical scenario (stress echo, cardiac cath, etc.). However, this would not likely pressure-test the status of interoperability. 

  • No labels