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:
- 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-Case||Provider interaction||Payer implementation||Likely implementation options||Interoperability needs across each actor/participant||Alternatives|
|CRD||CDS-Hook produced during medical order||Respond with coverage requirements, based on payer's coverage rules|
|Display card with DTR SoF link||Card link is to payer's DTR implementation choice|
|DTR||Review and supply PA questionnaire||Clinical evaluation and questionnaire, based on payer's rules for the medical service/order|
|PAS||Submit PA and receive status|
Support submission and status service
(could this be an existing X12 intermediary - representing Availity, Change, etc.?)
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.