Stream: terminology
Topic: Named closure tables, clashing names
Josh Mandel (Mar 14 2021 at 15:36):
Generally in fhir when a client needs to create a resource on a server, the POST pattern is most widely supported because servers can manage resource IDs; this avoids issues where two different clients each want to create a Patient/123 but mean different things by it.
I am just reading the definition for the $closure operation and it strikes me that this operation effectively creates (pseudo-resource-like) state on a server, where this state is identified entirely by a client supplied "name" parameter (also called "scope" elsewhere in the docs). It's always possible that different clients might try to manage their own closure tables while happening to assign the same name (e.g., "my-diabetes-codes"). I am guessing this has not been a problem in practice?
Peter Jordan (Mar 14 2021 at 19:52):
Yes, interesting that the server maintains client state. I'm not sure how widely this operation has been implemented, but a Server is expected to return an HTTP Status of 400 with an OperationOutcome Resource if there is an issue with a Closure Table Name, and that would include using the name of an existing table when attempting to initialize a new one. See http://hl7.org/fhir/terminology-service.html#closure
Josh Mandel (Mar 14 2021 at 20:56):
Indeed. Would be interested to hear who has implemented this server-wise and who has consumed it client-wise.
Michael Lawley (Mar 14 2021 at 21:43):
We've implemented it and have used it with our FHIR analytics platform, Pathling (https://pathling.csiro.au)
We haven't run into this problem, but using uuids or similarly generated names, I wouldn't expect to.
Josh Mandel (Mar 14 2021 at 22:36):
Yeah, asking clients to generate IDs within a namespace they control (or with sufficient entropy) helps here. Very cool to see Pathling BTW!
Brian Postlethwaite (Apr 03 2022 at 03:47):
Is there a way to initialize the closure table with a specific valueset?
Michael Lawley (Apr 03 2022 at 05:34):
Not directly; you'd need to expand it then initialise with the result.
But that seems like an unusual question -- why would you want to do this? Normally the concepts you add to a closure table relate to those in a search query and in actual resources (Observation.code for example)
Brian Postlethwaite (Apr 03 2022 at 06:30):
Will chat tomorrow with you about it if you've got some time.
Grahame Grieve (Apr 03 2022 at 21:23):
bring a legacy database into the picture? I could see this as a useful idea
Brian Postlethwaite (Apr 04 2022 at 04:50):
That's roughly what was trying to do. Was going to create a valueset that has the values used in our database so that the terminology server knows that set of values.
Michael Lawley (Apr 04 2022 at 05:58):
Nice. It would be interesting to then maintain that ValueSet incrementally. I'm thinking that FHIRPatch would work if it is only adding new concepts
Last updated: Apr 12 2022 at 19:14 UTC
