Document Sharing Across Network Topologies - Whitepaper

[JohnMoehrke]

Proposed Work Item: FHIR Federation

Proposal Editor: Joe Lamy Work item Editor: Joe Lamy Date: 19 January 2021 Version: 1.0 Domain: ITI

The Problem

The concept of federation is relatively underspecified in FHIR at this time. The notion of “home community” is used by numerous IHE profiles to enable complex, large-scale heterogeneous networks. See [IHE ITI TF-1] E.9 “XCA Integration with XDS and non-XDS communities” for a number of examples of federated deployments enabled by XCA. FHIR does not have an explicit analog for home community. We would like to add this to the IHE FHIR-based profiles. This would support all-FHIR cases requiring federation (for example, crossing security boundaries) as well as bridging FHIR with non-FHIR mechanisms such as XCA. Our initial use cases address mCSD and MHD, but other profiles could be considered, as well as Appendix Z for common capabilities, such as a consistent encoding of HCID as a business identifier.

https://github.com/IHE/IT-Infrastructure/blob/master/Proposals/IHE_ITI_FHIR_Federation-Brief.docx

UPDATE: Overall scope and status as of 5/14/21

• Push to federated responder: in progress
  • Doc sharing (XCDR): out of scope because no change needed
  • Doc sharing (MHD, XDR): in scope, complete (intendedRecipient)
  • Still need to write a CP to XDR, but analysis done
  • Other FHIR resources: out of scope (X-Destination)
  • mCSD: enable federation and Endpoint lookup, profile id as HCID: in scope, in progress
• Pull from federated responder: in progress
  • Doc sharing (XCA): out of scope because no change needed
  • Could still describe big networks like Carequality in white paper
  • Doc sharing (MHD): in scope, in progress
  • Considering where in metadata the HCID of fed resp can be conveyed
  • mCSD: enable federation lookup, profile id as HCID: in scope, in progress
• Push or pull from federated initiator: just started
  • Routing response back to federated sender: out of scope because can be handled by initiating gateway
  • Which responding actor can perform access control / auditing: in scope, in progress
  • Briefly describe in white paper
  • No normative changes needed
  • Info needed to perform access control / auditing: in scope, in progress
  • Handle “multi-parent”, “multi-requester” use cases
  • IUA: representing initiator(s) in access request: in scope?
  • mCSD: representing different kinds of relationships: in scope
  • mCSD: enable federation lookup, profile id as HCID: in scope, in progress

[JohnMoehrke]

PUSH use-case might need some clarifications or updates to mCSD for use with HCID discovery PULL use-case might need some clarification or updates on PDQm/PIXm use to discover HCID that a patient is known within

Solution might be broken up into four small work tasks all contributing to overall success needed for this work item. The small work tasks would not stand alone, but rather are useful incremental (agile) improvements

[jlamy]

Oops. Accidentally closed. Reopening.

[jlamy]

Adding mostly done detailed proposal.

[jlamy]

MHD to a Federation – November 11, 2021

• JL Reached out to Charles, Vassil and ITI Tech about targeted routing for XCPD and XCA like XDR/XCDR; no response yet
• mCSD: Add use case: “Service Endpoint Discovery”
  • LD Search for endpoints or for orgs then get their endpoints?
  • Would you ever have an endpoint just by itself?
  • Keep Endpoint optional, so same as base FHIR
• Where do changes really need to be made?
  • Can mCSD encompass HPD functions? Let’s go with that.
  • Vol 1
  • High level use cases (alternately could be white paper)
  • Section 7: deployment (i.e. directory population) guidance
  • Directory navigation guidance?
  • Vol 2
  • ITI-90: 2:3.90.4.1.2.2 Organization Resource Message Semantics: add _include=Organization:endpoint
  • ITI-91: Add Endpoint resource
  • Roll into mCSD prior to next F2F, rather than CPs?
  • Trigger: GitHub issue, CP adds overhead
  • JM Ideally JL provide pull request so committee can just accept (work with LD)
• Endpoint connection type
  • JM HL7 will likely make this example binding instead of extensible
  • JM Extensible binding is almost never right one for base; ok for IGs
  • We discourage use of ihe-xcpd, etc.
  • We define code system (for new values) and value set
  • mCSD profile on Endpoint adds extensible binding to this
  • In narrative part of value set, need to lay groundwork for profiles to define connection type that isn’t represented here

[JohnMoehrke]

https://github.com/IHE/ITI.WTF

[JohnMoehrke]

renamed the github repo - https://github.com/IHE/ITI.Topologies