Stream: implementers
Topic: custom type as path parameter
Jens Villadsen (Jun 13 2017 at 12:21):
Is it in the pipeline to consider a more loose coupling between the type and the name the type is served under? lets say my wonderful system has two profiles for patient, MyPatient1 and MyPatient2. I would like to host them under both /Patient (all patients) - and for convenience /MyPatient1 (patients only conforming to MyPatient1) and /MyPatient2 (patients only conforming to MyPatient2) - each being shorthand notation for the _profile parameter and also serve as endpoint with server speficied validation. But from what I can read in the spec and see in the capabilitystatement, that is not currently supported. To me it would sort of tidy things up.
Lloyd McKenzie (Jun 13 2017 at 14:52):
There's nothing that prevents you from responding to any URL you like, but those wouldn't be "standard" URLs and therefore the standard doesn't provide a mechanism to talk about them. (There's already a standard way to query for patients filtered to a particular profile.)
Grahame Grieve (Jun 13 2017 at 22:33):
we've considered this before. it would be convenient from some perspectives, but it also creates lots of challenges. So we've not specified it, though as Lloyd says, servers can add additional URLs
Lloyd McKenzie (Jun 14 2017 at 00:20):
CapabilityStatement is extensible, so in principle, you could extend it to talk about the additional "special" URLs you support.
Jens Villadsen (Jun 14 2017 at 07:57):
Right ... -I thought about that ... back and forth ... and sure, one can execute the queries using _profile and when creating resources the profile is already part of the data definition. After having thought about it I think the current state is actually fine - as @Lloyd McKenzie says, - I could probably tweak the CapabilityStatement to support it, but hey - the data itself is already marked with the profile it conforms to, so there probably is little value added in adding those extra paths.
Eric Haas (Jun 14 2017 at 16:30):
deleted
Brian Postlethwaite (Jul 10 2017 at 02:25):
unfortunately can't create the custom type, as the rest.resource.type property which is where this custom value MyPatient1 would need to go is required to bind to the standard fhir resource types. So no love on defining a valid CapabilityStatement to support this.
Lloyd McKenzie (Jul 10 2017 at 14:54):
The recommendation had been to use an extension. That would still be a valid CapabilityStatement?
Brian Postlethwaite (Jul 11 2017 at 22:41):
Nope. If you had Patient has the base value for the type, and the extension with the other name that would be fine, but if you tried to add multiple entries for the different patient profiles it would violate invariant cpb-9
Lloyd McKenzie (Jul 11 2017 at 22:46):
@Brian Postlethwaite You're assuming using CapabilityStatement.rest.resource. I'm thinking Capability.rest.extension - where you can throw whatever you like. The system might not expose a "Patient" endpoint at all. (Though obviously no off-the-shelf systems would then be able to interact with it.)
Brian Postlethwaite (Jul 11 2017 at 22:48):
So wouldn't be able to define all the goodness of the capability, just that it exists. Without going nuts with more extensions to create a complex extension
Lloyd McKenzie (Jul 11 2017 at 22:49):
The whole thing is outside the FHIR spec. So going crazy with extensions is going to be somewhat necessary.
Brian Postlethwaite (Jul 11 2017 at 22:50):
yes.
Last updated: Apr 12 2022 at 19:14 UTC
