Hi,
Let’s say we have a permissioned blockchain that includes multiple members exposing FHIR. I wonder if there is a way to have within FHIR a list of members of such consortium. We would need to include there their FHIR endpoints.
Regards,
Luiz
The simplest mechanism is to have a single server that exposes the Endpoint resource and contains instances for each member of the consortium. If you want to have a servers that manages multiple consortiums, you could have a separate List instance for each consortium, with the List members being the relevant endpoints. (Some endpoints might be in multiple Lists.)
Given a provider directory is often similarly protected as a permissioned block, and the data for each provider is rather static, this would be reasonable information to publish on-chain. Thus you would gain the distributed (non-centeralized) benefit of the chain… Just be careful of putting sensitive or highly changeable information on-chain… I think your use-case is likely reasonable for on-chain FHIR resources (Organization, Practitioner, PractitionerRole, Endpoint). Hard part is how to layout the relational aspects, but not too hard.
Thanks for your inputs, Lloyd and John!
Let me clarify: we are not planing at this point to have any FHIR resource on the chain itself. Resources still reside in their respective organizations. The blockchain just facilitates the communication between organizations. Another important aspect, maybe not really relevant for this particular discussion, is that it’s patient driven.
Anyway, yes we thought about the provider directory and organizations. One drawback is that they are protected and the information about membership doesn’t really have to be. Another option we are considering is some sort of extension to the Capability statement where we would list all consortium members. This way, a patient facing app would have to know at least one member’s endpoint to retrieve a capability statement (no access token required) but from there would be able, if so allowed (client app + patient), to retrieve data from other places.
Not sure what’s meant by “they are protected”. If you’re referring to FHIR resources, there’s no need to place access restrictions unless you want to. Using a resource registry would be more interoperable than an extension on CapabilityStatement
Oh, yes, implicitly I was considering SMART on FHIR, with an OAuth2 server protecting resources.
Are there any examples of “resource registries” that you are aware of? Or at least something close to it?
By the way, are there any concrete use cases where real patient data is not protected? I’m genuinely curious.
In theory, you could have unprotected access to real patient data if the network itself were secure and all clients were fully trusted to manage access appropriately. It wouldn’t be a likely approach due to the development of a defense-in-depth approach, challenges with appropriate logging, etc. However, it’s certainly something FHIR would allow. However, for non-patient data, non-protected read access is quite reasonable.
Every FHIR server acts as a “resource registry”, so there are lots of examples, including the public test servers.