FHIR Chat · Master resource among federated resources · implementers

Stream: implementers

Topic: Master resource among federated resources


view this post on Zulip Tim Berezny (Aug 17 2020 at 17:39):

I'm looking at implementing a federated approach to publishing a resource, where instances of it will exist in many places with a syncing mechanism - the HealthcareService in particular.

Different HealthcareService resource's "master source of truth" instance may exist in different places, and various directories could hold either a copy or the master instance of any given HealthcareService. For updates, ideally a directory would know where to look to get the its "master" instance.

Is there a preferred approach to this type of model? I'm currently thinking of either:
1) creating an extension that points to the master instance of a resource - or -
2) Putting the URL of the master instance of the HealthcareService into an identifier, with one (or more?) of .use/.system/.type to indicate what the purpose is.

What might the best approach to this be?

view this post on Zulip Jose Costa Teixeira (Aug 17 2020 at 20:06):

Provenance resource?

view this post on Zulip Jose Costa Teixeira (Aug 17 2020 at 20:07):

one question: is your "directory" a thing? Are these resources packaged in some way for being distributed (like a List or Composition)? or the sync is just on each of the resources individually?

view this post on Zulip Tim Berezny (Aug 17 2020 at 20:46):

Provenance, that's an interesting/appealing thought. So essentially, would the Provenance.target reference the distributed instance, and the "Provenance.entity.what(role=source)" referencing the master instance?

No, it is not pre-packaged, the directory is intended to be query-able, so you can get a bundle of many or just one HealthcareService at a time (and its related Organization/Location/Endpoint resources)

view this post on Zulip John Moehrke (Aug 17 2020 at 20:50):

Yes that is how you would use Provenance.

view this post on Zulip John Moehrke (Aug 17 2020 at 20:52):

You could additionally mark the copy as a "COPY" -- http://build.fhir.org/v3/ActCode/cs.html#v3-ActCode-COPYMark... that way you would see in the meta.security of the copy a clear indication that it is a copy, thus you would know to look for a Proveanance.target equal to that copy, so that you could then follow the Provenance.entity to the original

view this post on Zulip Tim Berezny (Aug 17 2020 at 23:43):

Oh very interesting, it sounds like a very robust and viable approach. Thanks @John Moehrke / @Jose Costa Teixeira !

view this post on Zulip John Moehrke (Aug 18 2020 at 13:23):

it is robust... in theory... let us know how well it works in reality... hoping that theory and reality are similar... :-)


Last updated: Apr 12 2022 at 19:14 UTC