Meeting minutes
References lack a type arc #95
https://
Zulip discussion: https://
dbooth: Need to get clarity about whether the type can be parsed from the URL. If we can, then that requirements should be stated somewhere in the FHIR spec.
eric: Still cannot know that a ref URL will indicate the ref type.
eric: We can validate it if it's a relative URL or a frag ID. Could also add a switch to treat abs URL ref as unknown type or force it to assume that it conforms to FHIR server URL convention.
ACTION: Eric to push back on Lloyd that there still is a gap that would be good to address.
eric: Could add a switch to force deref to determine the result type
Concept IRIs
https://
Proposal document: https://
Gaurav's message, included with his permission:
-------- Forwarded Message --------
Subject: Re: FHIR RDF - Concept URIs document
Date: Tue, 12 Jul 2022 22:54:13 +0000
From: Vaidya, Gaurav <gaurav@renci.org>
To: David Booth <david@dbooth.org>
Hi everybody,
So at the end of our presentation last Thursday, the FHIR Vocab group left us with four questions:
1. Who gets to pick IRI stems and with what criteria?
- Rob McClure would like a solution where all the CodeSystems and NamingSystems (or at least the HL7 ones) have IRI stems, and would like to know how we plan to assign them where the terminology does not itself provide concept IRI templates (as SNOMED CT and LOINC does, for instance).
2. How do we deal with versioning? (i.e. the Coding.version field, which is the version of the vocabulary)
3. How do we do with characters that aren’t in ASCII?
- I think Eric and I managed to explain this to them after they asked it.
- They seemed particularly concerned about spaces, since FHIR code fields [0] have weird restrictions on spaces: "Technically, a code is restricted to a string which has at least one character and no leading or trailing whitespace, and where there is no whitespace other than single spaces in the contents” — so we should make sure this works with our code, and probably put some examples on this on one of the slides.
4. Our proposal does not specifically call for changing FHIR ValueSets to support concept IRIs, but they thought we should consider this
- I think we might just want to make it clear that we don’t plan to incorporate concept IRIs in FHIR itself — except maybe with a {system=urn:ietf:rfc:3987, code=[IRI]}?
- Rob or Reuben specifically mentioned “ValueSets”, but I think what we want to do is more related to “Coding”s — unless I’m missing something?
I took a stab at modifying our presentation to address these four questions specifically [1], except for the “ValueSets” question, which I’ve just left as a blank slide for now. We can discuss this in more detail on Thursday (and figure out if we really want to pitch this to the entire HTA this Monday [2]), but I wanted to send the slides to you now so you could see what I think the answers are for those questions.
Oh, also, here are the meeting minutes [3] if anybody is curious!
Cheers,
Gaurav
[0] https://www.hl7.org/fhir/datatypes.html#code <https://www.hl7.org/fhir/datatypes.html#code>
[1] https://docs.google.com/presentation/d/1boDoAK8_8pndD4W_EXtYVg9OnRtrYCGmZ-OcPbWGIIA/edit <https://docs.google.com/presentation/d/1boDoAK8_8pndD4W_EXtYVg9OnRtrYCGmZ-OcPbWGIIA/edit>
[2] http://www.hl7.org/concalls/CallDetails.cfm?concall=61788 <http://www.hl7.org/concalls/CallDetails.cfm?concall=61788>
[3] https://confluence.hl7.org/pages/viewpage.action?pageId=131052401 <https://confluence.hl7.org/pages/viewpage.action?pageId=131052401>
gaurav: Not sure we're scheduled for that mtg.
… They want an IRI stem assigned for all of them.
dbooth: I think it would be beneficial to fill in IRI stems to the repo.
rob: Two cases: Those that HL7 controls, vs ones that are controlled by other orgs.
rob: Could follow the same process as for System URI.
eric: What if there isn't a System URI, and then the terminology owner decides they want to define one?
rob: Try to get them to find out if they have a preference, and use that. If not, then HTA assigns one.
… Some were decided in the early days of FHIR. Don't want to change those arbitrarily. But becoming more stable process now.
rob: In a few cases an org suggested a different URI, but were convinced to stick with the prev one.
eric: And when the org doesn't say what it should be, it gets assigned to something in the HL7 space? rob: yes.
rob: A few times in the past namespace squatting was done, but no longer.
gaurav: Here are the slides I'm currently editing if anybody wants to follow along: https://
dbooth: Approach amounts to 'choose it or lose it'. Rob: yes.
eric: if Kent Spackman hadn't chosen a SNOMED URI for IRI stem, and we assigned an HL7 URI, then if SNOMED wants to later they want their own URI used, then what?
dbooth: If the org asserts that they then want their own URI used, then they're accepting responsibility for breaking people's code.
rob: If the org doesn't step up, then HTA will look around for what is already in use, such as bioportal.
gaurav: Could also use a URL forwarding mechanism.
eric: Need to go to orgs and ask them if they want to assign one.
eric: Want to make IRI stem changes only 0 or 1 times.
dbooth: separate questions: 1. put IRI stems into the repo at all? 2. Who (which group) should decide what goes into the repo? 3. What should be done if a terminology owner does not step up to specifying their preferred IRI stem? 4. Should we have a way to indicate that an IRI stem may be volatile?
rob: For HTA, they would only own some of these questions. #1 would be question for the THO group. SHould put in a UTG proposal (Jira ticket), and goes through voting and approval process. UTG voters.
gaurav: if UTG doesn't want IRI stems into the repo, then we could do our own.
rob: Re #2, that also should go through UTG proposal, with the exception that if it is external org, then it needs to go through HTA first.
rob: Re #3, if the org doen't step up, then HTA woudl assign one.
rob: Re #4, that's more of an HTA thing.
ACTION: Gaurav to check with UCG group about presenting on July 18.
ADJOURNED