Stream: implementers
Topic: identical urls across different structuredefinitions
Jens Villadsen (Feb 12 2019 at 14:56):
Whats the expected behavior for FHIR servers where multiple structuredefinitions are stored with identical urls (I guess this case is not much different from updating a structuredef where the server support versioned structuredefs). Should the server allow it at all? Which structuredef can the client expect its resources to be validated against? Is it random?
Lloyd McKenzie (Feb 12 2019 at 16:18):
It's totally ok for the same canonical URL to appear on multiple instances on the same server. (Though the 'version' element of each should be different.) If servers validate against the local copy of a referenced profile, the expectation is they'll use the most recent 'version' unless the declaration is version-specific. (And in general, version-specific profile declarations are recommended.)
Michel Rutten (Feb 12 2019 at 16:21):
As an example, Simplifier also allows duplicate canonical urls. A common canonical url may be assigned to many profiles across many different projects. However the system requires that all public resources must have a unique canonical url - to prevent globally visible url conflicts.
Lloyd McKenzie (Feb 12 2019 at 16:33):
@Michel Rutten How would you handle exposing different versions of a profile or value set? (Given that the canonical URL can - and generally should - remain the same across versions)
Michel Rutten (Feb 12 2019 at 17:07):
Good question!
More precisely, for public resources, Simplifier requires that the canonical url and version are globally unique.
For private resources, Simplifier requires that the canonical url and version are unique within the containing project.
Michel Rutten (Feb 12 2019 at 17:08):
(And requests for unversioned canonical urls get the latest available version)
Jens Villadsen (Feb 13 2019 at 09:03):
It's totally ok for the same canonical URL to appear on multiple instances on the same server. (Though the 'version' element of each should be different.) If servers validate against the local copy of a referenced profile, the expectation is they'll use the most recent 'version' unless the declaration is version-specific. (And in general, version-specific profile declarations are recommended.)
So for instance, http://hapi.fhir.org/baseDstu3/StructureDefinition?url=http://trifork.dk/fhir/StructureDefinition/dk-tm-message&_count=3 gives you 3 StructureDefs all with the same canonical url and the 3 StructureDefs are independent of each other - meaning that they carry independent version numbers (all v1). Which one should the server use for validation ?
Grahame Grieve (Feb 13 2019 at 10:42):
that can't be resolved. It's probably bad business practice to allow that, but it's a business decision to decide how that's resolved
Jens Villadsen (Feb 13 2019 at 10:51):
Its really bad practice ... so since its so evidently bad practice why allow it in terms of the standard?
Grahame Grieve (Feb 13 2019 at 11:03):
are you claiming that there should be no way to have a server like simplifier that allows compartmented duplications? Are you sure that there's never a valid use for a serer to allow duplicates even if it doesn't and can't do validation? Just a general purpose repository, maybe for audit/archive purposes?
Grahame Grieve (Feb 13 2019 at 11:04):
when we define a conformance service (parallel to the terminology service) then that's the place to make rules about URLs and business management decisions
Jens Villadsen (Feb 13 2019 at 11:30):
so whats the terminology here ... we have terminology services, conformance services .... and what is the name for the actual FHIR services hosting the actual data
Grahame Grieve (Feb 13 2019 at 11:36):
it's about purpose, not which is actually hosting the data. If you're hosting the resources in order to provide validation services, you shouldn't allow duplicates to exist
Jens Villadsen (Feb 13 2019 at 11:49):
I would say that Simplifiers approach seems valid - but I would also think that Simplifier is more of an exception to most of the FHIR servers out there
Grahame Grieve (Feb 13 2019 at 13:20):
it is. but hard rules don't allow for exceptions
Jens Villadsen (Feb 13 2019 at 15:31):
I guess I'll have to index myself out of that one - and so does everybody else or do something alike
Jim Steel (Feb 14 2019 at 06:42):
Ontoserver's general approach is to delay raising it as a problem. So you can add ValueSets/StructureDefinitions/CodeSystems/etc with identical urls/versions, and it will only be raised as a problem when an operation needs to resolve one and can't
Jim Steel (Feb 14 2019 at 06:44):
e.g. if you use type-level ValueSet $expand with a url and no version, then we will try to resolve either a unique ValueSet with that URL, or if there are multiple versions available, with a uniform version string format that allows the server to determine a latest version, then it will work. Otherwise Ontoserver will return either 400 or 422 (depending on where the ambiguity comes from), along with a message saying what the ambiguity was
Jens Villadsen (Feb 14 2019 at 08:32):
@Jim Steel - so if you would like to validate incoming a resource that is to be created and you have multiple structuredefs with the same url but with different (conflicting) requirements - what do you then do?
Jens Villadsen (Feb 14 2019 at 10:16):
@Grahame Grieve - I can suggest that there would be a set of recommended constraints for each type of services that's out there - e.g. conformance services, terminology services and 'treatment services (regular instances that aids in storing state for patient treatment)' and so on - stating what would be good practice and why
Jim Steel (Feb 14 2019 at 23:19):
Same logic. If the StructureDefs all have a version, and all of those versions are in a consistent format (e.g. 1.2.3 or 20190215), then we will use the most recent. If not, we will return a 400 (if the SD url was provided in the request) or a 422 (if the SD url was in a resource that was already on the server).
Brian Postlethwaite (Feb 15 2019 at 02:18):
Maybe there's a need for a search parameter type of canonical that applies these rules in the server for resolution.
Working out which is the latest version etc. Without the client needing to know about it.
(Then the resolve from the validator can call that, and doesn't have to work things out itself)
Jim Steel (Feb 15 2019 at 03:33):
If the validator calls an operation without specifying a version, the same thing will happen
Grahame Grieve (Feb 15 2019 at 10:48):
@Brian Postlethwaite I could see the canonical being useful, but I'd have to review the existing spec to see if it is actually new functionality not already defined
@Jens Villadsen I agree that this would be good. Since we only have one service defined, we should start by adding a section to that one.. a task would be good
Jens Villadsen (Feb 18 2019 at 09:15):
@Grahame Grieve https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=20398
Jens Villadsen (Oct 07 2019 at 12:49):
What about uniqueness on SearchParameters ... shouldn't that also be the case?
Grahame Grieve (Oct 07 2019 at 13:15):
Yes
Jens Villadsen (Oct 07 2019 at 13:18):
maybe it all could be a BOF topic on devdays?
Michel Rutten (Oct 07 2019 at 13:27):
@Jim Steel, yes, Forge takes the same approach. If the project folder contains multiple profiles with a common canonical url, then Forge allows you to open/edit each of the duplicates. However if you open some other profile with a reference to that canonical url, then Forge will raise a runtime error (ambiguous).
Note: we could implement a opoup dialog that allows the user to choose the target profile from a list of available duplicates.
Jens Villadsen (Nov 18 2019 at 09:27):
Anyone up for a BoF on this topic in the upcoming days?
Grahame Grieve (Nov 18 2019 at 09:27):
what is there to talk about?
Jens Villadsen (Nov 18 2019 at 11:33):
best practice rules for uniqueness on the different kinds of services out there and what/how uniqueness is best expressed in terms of structuredefs and searchparams
Jens Villadsen (Nov 18 2019 at 11:36):
an where such content should be placed
Michael Lawley (Nov 18 2019 at 11:38):
Resources have rules about when changing something should impact its business version. That's one dimension of the uniqueness story, but it's probably attenuated for any Resource with draft status.
I think a discussion about version resolution OTOH would be very useful -- If a canonical references blah|4.0.0 is it valid to resolve that to an available resource with url blah|4.0.1 - what about a canonical of the form blah|4.0 - should that match the latest of any blah|4.0.x canonicals?
Hans van Amstel (Nov 18 2019 at 11:52):
Having a discussion on version resolution would be very useful. The business version (after the url) is independent of the FHIR version, as a custom profile is extended it gets a new business version but the FHIR version and canonical remains the same. Can I then query a FHIR server for the canonical|business version combination to only get resources of the latest business version of a profile?
Jens Villadsen (Mar 30 2020 at 20:51):
So back to this again (now located on https://jira.hl7.org/browse/FHIR-20398). When I advise my clients on the use of FHIR and what they should do in order to establish a safe test bed where they themselves can change the SD's and if they run on the HAPI FHIR stack, I always advise them to make the url on SD's unique by setting up indexes using Search Params using the special HAPI FHIR extensions. I still believe this should be mentioned as a way harnessing a FHIR test environment in order to make which versions of an SD one validates against - @Grahame Grieve @Rob Hausam @Jim Steel @Michael Lawley @Hans van Amstel .
Last updated: Apr 12 2022 at 19:14 UTC
