FHIR Chat · ValueSet Url Validation During IG generation · implementers

Stream: implementers

Topic: ValueSet Url Validation During IG generation

Ross Shnaper (Mar 16 2017 at 21:21):

Hi everyone,

I have a value set with the following id and url:
id: irrs-advance-directive
url: http://cihi.ca/fhir/ValueSet/irrs/irrs-advance-directive

When running the IG tool, I get an error and it seems that the tool doesn't like the fact that my URL has /irrs in it's path. Looking at the IG tool code I see that it assumes that url is composed of canonical url + resource id. Can someone shed some light as to why? And also why this is not an issue for code system? Is that because value sets are considered full fledged resources but code systems are not?

String u = igpkp.getCanonical()+r.getUrlTail();
        if (r.getResource() != null && r.getResource() instanceof MetadataResource) {
          String uc = ((MetadataResource) r.getResource()).getUrl();
          if (uc != null && !u.equals(uc) && !u.startsWith("http://hl7.org/fhir/template-adhoc-ig") && !(r.getResource() instanceof CodeSystem) && !(r.getResource() instanceof ImplementationGuide))
            throw new Exception("URL Mismatch "+u+" vs "+uc);
        }

Eric Haas (Mar 16 2017 at 22:36):

I'm dealing with a similar issue for code systems where the id!= url too. I think this makes it easier for the publisher to sort things out when generating the fragments. But will wait for GGs response.

Brett Esler (Mar 16 2017 at 22:53):

likewise here for code systems owner/definer of the set is (external system url defined); we are holding and managing the FHIR representation under our cannonical base url... reasonably common usage I think?

Grahame Grieve (Mar 16 2017 at 23:24):

so if the IG publishes the content, it will insist that the canonical URL is also the regular end-point of the resource, so that the IG itself is an instance of the FHIR spec

Grahame Grieve (Mar 16 2017 at 23:24):

but I had to allow the rule to be broken for code systems because they sometimes have fixed external urls

Eric Haas (Mar 16 2017 at 23:46):

Grahame Grieve: but I had to allow the rule to be broken for code systems because they sometimes have fixed external urls

Good to know but this is not working for me:

id = blah
url = urn:oid:[OID]

is causing qa.html errors and inability to share definitiions.

Lloyd McKenzie (Mar 17 2017 at 01:51):

@Ross Shnaper In general, there's not much point in having "ValueSet" in your URL if you're not going to have a valid FHIR URL - and that's not a valid FHIR URL. No structure is allowed after the resource name that isn't explicitly defined by FHIR (at least not if you want FHIR systems to recognize it).

Ross Shnaper (Mar 17 2017 at 02:39):

Thanks everyone. Good to know I'm not the only one puzzled by this. @Lloyd McKenzie so ValueSet url should conform to the same rule as one for other FHIR types like StructureDefinition for example (i.e. canonicalUrl/Type/id). Would you or @Grahame Grieve recommend we use the same rule for CodeSystem resources as well although the validation for this rule is intentionally broken in IG to be able to support fixed external urls? Does anything change now that CodeSystem is a resource in itself in STU3?

Lloyd McKenzie (Mar 17 2017 at 02:45):

If you're planning to define the code system in FHIR, then it probably makes sense for the canonical URL to be a valid RESTful URL. For code systems like SNOMED, UCUM, LOINC, etc. that won't be defined as FHIR code systems, that's not important and having the URL point somewhere "useful" is more important.

Ross Shnaper (Mar 17 2017 at 02:58):

Understood. Thanks for the clarification @Lloyd McKenzie

Joel Schneider (Mar 17 2017 at 16:12):

Maintaining a valid RESTful URL as a ValueSet's canonical URL could, over time, become complicated and unwieldly. For example, if the ValueSet needs to be utilized by systems running different versions of the FHIR specification, some of them might eventually have difficulty interacting with the canonical resource. The potential for breakage might also induce pressure that would tend to discourage any upgrades and/or increase the complexity of upgrades. From an implementation standpoint, to me it seems simpler to maintain the canonical URL as a human-readable landing page.

Grahame Grieve (Mar 17 2017 at 19:35):

simpler is not always better.

Grahame Grieve (Mar 17 2017 at 19:35):

but there's a lot to think about there

Lloyd McKenzie (Mar 17 2017 at 21:50):

My general leaning is that if you request HTML, you get the human readable navigation page. If you request FHIR XML/JSON/whatever, you get the current version of the resource.

Michael Lawley (Mar 18 2017 at 07:50):

My general feeling on CodeSystem and ValueSet URLs is that they should work as URIs first and URLs second. If you;ve multiple versions then you can use the version string along with the URI to disambiguate, but if you assume the URI is *the* FHIR URL, then that breaks because you can only have one thing at the end.

Grahame Grieve (Mar 18 2017 at 11:16):

there is a way to retrieve by canonical url and version

Joel Schneider (Mar 19 2017 at 15:51):

API versioning is a tricky topic. Here's a blog article about a service that offers "3 different wrong ways" of doing it (URL versioning, custom request header, and content type), and lets the client pick which one to use: https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/

Chris Moesel (Mar 22 2017 at 19:43):

I apologize for resurrecting an old topic, but... I'd just like to cast my vote that it would be really great if we could provide FHIR representations of value sets with external URIs (outside the IG's canonical url, and not necessarily ending with /ValueSet/${id}). For example, we might want to create an IG providing a FHIR representation of an existing logical model that has value sets with pre-defined URIs. Given that many implementors will likely support processing value set definitions in FHIR format, it would be nice if our IG could include the logical model's value sets in the FHIR format -- but right now, it cannot do that without re-assigning a whole new URI to the value set (so there is no longer *one* unique URI for the VS).

Grahame Grieve (Mar 22 2017 at 19:59):

is there a task about this?

Grahame Grieve (Mar 22 2017 at 20:00):

and I wonder how to make this possible, without also making something authors do by accident?

Eric Haas (Mar 22 2017 at 23:51):

Maybe these valueset URLs need to be called out in the definitions file separately as exceptions so that is :

• a) more of a hassle and
• b) you have to understand what you are doing.

Chris Moesel (Mar 23 2017 at 20:54):

Thanks @Grahame Grieve and @Eric Haas. I've posted an item in the tracker to propose this change:
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13131&start=0

To Eric's point, I think that requiring it to be an intentional action for the author (via configuration or something else) is fine -- especially if it helps to allieviate Grahame's concern about unintentionally mis-matching the URIs.

Thanks for considering!

Michael Lawley (Mar 24 2017 at 06:48):

The key is distinguising URI (universal, but needs resolving) from URL (just one of the locations you might find the thing). Unfortunately FHIR doesn't help here in its naming of certain properties. There is only one *URI* for a VS

Lloyd McKenzie (Mar 24 2017 at 15:27):

I don't recall anything in the URI spec that says that a given entity is only permitted to have a single URI. And I think any such assertion would be fairly unworkable in many environments.

Chris Moesel (Mar 24 2017 at 16:00):

I don't think that having multiple URIs for a value set should be encouraged. If there is a single URI, then implementors don't need to worry about maintaining a mapping of equivalent URIs. But I understand that arguments could be made on either side. Despite that, I still think that FHIR shouldn't _require_ me to fragment my identifying URIs if I don't want to... My preference is that each of my value sets has a _single_ URI -- because I want an unambiguous and singular way to reference it. So, ideally, the FHIR IG publisher would allow me to maintain that one singular identifying URI -- even if that URI isn't prefixed by a canonical FHIR IG URL.

Lloyd McKenzie (Mar 26 2017 at 06:00):

I'm not saying we should encourage it. And for FHIR purposes, we only allow a single canonical URL. But that doesn't mean there can't be more than one. If you're going to have a FHIR resource instance, I think it's reasonable to require that the URL be a valid FHIR URL. It's already possible to have bindings to arbitrary URLs when there's no expectation that the artifact at that URL will be expressible in FHIR form.

Grahame Grieve (Mar 26 2017 at 19:42):

I implemneted this - see http://wiki.hl7.org/index.php?title=IG_Publisher_Documentation#Special_URLs

Chris Moesel (Mar 27 2017 at 13:01):

Thank you, Grahame. I will be careful with it. I understand that with great power comes great responsibility!

Last updated: Apr 12 2022 at 19:14 UTC