Interop Framework for Payer2Payer and Internal Systems

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive
    • Priority: Medium
    • US Da Vinci CDex (FHIR)
    • 0.2.0 [deprecated]
    • Patient Care
    • Data Consumer Client CapabilityStatement
    • Hide

      First, CDex is focused on Provider to Payer and Provider to Provider exchanges, not payer-to-payer.  (Payer to Payer is covered by the PDex IG.)

      Second, the hierarchy of systems within a particular provider environment is outside our scope.  FAST is dealing with registries to help discover the appropriate endpoints to use for particular types of searches.  OIDs will almost certainly not be a part of this solution as identifier hierarchy and system topology should generally be unrelated.  (Identifiers shouldn't ever change once they exist, while system topologies change on a semi-regular basis.

      Third, the scope of CDex is focused on FHIR data exchange, and doesn't cover the sharing of v2 or other data (while in principle, CDA, PDF and other types of documents could be returned via DocumentReference as part of the CDex spec, CDex is completely silent about standards around the encoding of these).  There is no expectation for collation of data as part of the CDex specification.

      Show
      First, CDex is focused on Provider to Payer and Provider to Provider exchanges, not payer-to-payer.  (Payer to Payer is covered by the PDex IG.) Second, the hierarchy of systems within a particular provider environment is outside our scope.  FAST is dealing with registries to help discover the appropriate endpoints to use for particular types of searches.  OIDs will almost certainly not be a part of this solution as identifier hierarchy and system topology should generally be unrelated.  (Identifiers shouldn't ever change once they exist, while system topologies change on a semi-regular basis. Third, the scope of CDex is focused on FHIR data exchange, and doesn't cover the sharing of v2 or other data (while in principle, CDA, PDF and other types of documents could be returned via DocumentReference as part of the CDex spec, CDex is completely silent about standards around the encoding of these).  There is no expectation for collation of data as part of the CDex specification.

      With the upcoming P2P requirement, Payers need a comprehensive framework which details their internal systems access to other Payers data.

      1. Single point of access to external endpoints. a) identification and hierarchy of internal systems that can be used to so that retrieval of data can be distributed to the appropriate downstream internal system. Could OID's help?
      2. Data aggregation of data retrieved from external APIs. If data is retrieved how do we register all the different types of data and formats (CCDA, Hl7v2, Fhir, Flat File?) that we might receive so that it can be collated and returned in a response?

            Assignee:
            Unassigned
            Reporter:
            michaelykim
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: