Stream: implementers
Topic: Standalone demographics server
Lin Zhang (Dec 10 2020 at 23:50):
Any best practices for building a dedicated FHIR server as a standalone demographics server to facilitate privacy protection? Thanks.
Lloyd McKenzie (Dec 11 2020 at 00:08):
You'd have to think about subject.display and narrative of the referencing resources. Those would often expose name and possibly limited other information. Also, even if you completely protect demographics, other information (e.g. when someone visited particular locations) can, when combined with other information, still breach privacy).
Lin Zhang (Dec 11 2020 at 00:11):
Agree. Thanks for your swift reply:smiling_face:
Derek Ritz (Dec 14 2020 at 16:43):
This seems to me to be an important use case. Is it expected that the "client registry" content will exist on the same FHIR server as the health data associated with the patient ID... or is it expected (or at least supported) that this will be a separate server? If it is a separate server, does it "break" any of the internal references in the other server, where the health data is persisted -- or can fully-formed id's (with the full URL) address cross referencing challenges? @Lloyd McKenzie -- this appears to be related to the "Logical ID changes" thread...
Lloyd McKenzie (Dec 14 2020 at 16:52):
It's totally fine for it to be on a separate server. There's no issue with logical id changes if a reference is a full URL and you're not creating or updating the referenced resource.
Derek Ritz (Dec 14 2020 at 17:00):
Thanks, @Lloyd McKenzie . Would operations or transactions running on the "health data" server still be able to operate on data that is on the "CR" server? For example, if a plandefintion.action.condition needed to fire (or not fire) depending on the gender of the patient... would this still work if the patient resource was on another server (but referenced by a full-URL id)? (Sorry for not knowing how that's expected to operate... and I hope I'm not missing something obvious). @Bryn Rhodes -- has anybody tried this cross-server kind of thing, executing a $apply, for example?
Lloyd McKenzie (Dec 14 2020 at 17:21):
Detecting a condition doesn't necessarily need to happen on the same server, though obviously it needs to be a server that the workflow engine is aware of and has access to.
Bryn Rhodes (Dec 15 2020 at 18:42):
@Derek Ritz , the $evaluate and $apply extensions in CPG-on-FHIR support accessing data on other servers through the use of Endpoints passed as parameters to the operations. See the $apply here: http://build.fhir.org/ig/HL7/cqf-recommendations/branches/master/OperationDefinition-cpg-plandefinition-apply.html
Derek Ritz (Dec 15 2020 at 21:08):
Thanks, @Bryn Rhodes -- so in a situation where the health data was on one FHIR server (an SHR) and the demographic data was on another server (a CR) you could execute a $apply on one of these and pass it the location of the other server in the dataEndpoint parameter. This is a 0..1 cardinality -- so a federation of more than two servers is not supported; do I understand this correctly? (and I'm assuming that content that is on the local server will be included in addition... not just the content on the supplied endpoint... do I understand this correctly?)
Bryn Rhodes (Dec 16 2020 at 16:48):
@Derek Ritz , basically, the behavior supports 3 levels:
- Data provided as part of the request (via a bundle or a set of prefetch bundles)
- Data available in the server itself (and whether this can be used is controlled by the useServerData parameter)
- Data available in the dataEndpoint parameter, if provided.
Any federation scenarios more complicated than that would have to be handled either in the server itself, or with a federating endpoint that you would then pass as the dataEndpoint to the operation.
Bryn Rhodes (Dec 16 2020 at 16:49):
We've applied those same semantics consistently across the $cql, Library/$evaluate, and PlanDefinition and CarePlan/$apply operations.
Derek Ritz (Dec 16 2020 at 17:28):
Thanks @Bryn Rhodes -- much appreciated! :+1:
Last updated: Apr 12 2022 at 19:14 UTC
