Stream: new zealand
Topic: Valueset uri
David Hay (Aug 12 2019 at 22:43):
Currently the Uri we're using for ethnicity valueset is https://standards.digital.health.nz/valueset/ethnic-group-level-4
Any objection to using http rather than https? ie http://standards.digital.health.nz/valueset/ethnic-group-level-4
and - while we're at it - making it a bit more aligned with FHIR names - so:
http://standards.digital.health.nz/fhir/ValueSet/ethnic-group-level-4
(which, I believe, was an issue you had @Peter Jordan - and one I've come to appreciate as I've been working more closely with them!)
(Same for CodeSystems)...
Peter Jordan (Aug 12 2019 at 23:13):
The uri for the related Value Set should be a canonical identifier and represent the definitive source of truth (aka 'master copy') for the location of that ValueSet. Ultimately, that's for the owner of the underlying Code System to determine; so I'm agnostic on whether it should be http or https. However, if you wish that uri to resolve to a definition of that Value Set, then the uri you're proposing looks good.
Obviously, it's permissible for other servers to hold copies of that ValueSet - e.g https://terminz.azurewebsites.net/fhir/ValueSet/NzEthnicityL4
Once you've decided on this, I will change the name property of that ValueSet accordingly and put the definitive source in the valueSet (canonical) property of the underlying CodeSystem resource on my Server.
David Hay (Aug 13 2019 at 00:01):
It's mostly that having 'codesystem' in the url is confusing (at least, I find it so)...
Peter Jordan (Aug 13 2019 at 00:21):
Fully agree. I did push-back against having the Naming System kind in those urls - particularly when it's a lower case version of a FHIR Resource name. That was bound to cause confusion. I could say more, but probably shouldn't on here!
David Hay (Aug 13 2019 at 01:42):
Yeah - I now understand why you objected! Can we add this to the next HISO meeting @Alastair Kenworthy ?
Alastair Kenworthy (Aug 13 2019 at 07:40):
We need https because these are resolvable
'codesystem 'I've seen contracted to 'cs', if you want something shorter
Value sets could be denoted ValueSet or valueset or vs
Yes, we can discuss at HISO - and also the day before at the meds workshop, because we should make it a priority to identify the namespaces we need for meds
David Hay (Aug 13 2019 at 08:30):
well, none of the urls in the spec use https (as the canonical url) so that should be solvable...
wrt the content of the url , the problem with using something like "...codesystem..." is that it is enormously confusing when you are using it - at least that's how I've found it working on the NHI / HPI project. It's close enough to the API (but different) to be really confusing...
I'd like to see something like, say, http://standards.digital.health.nz/fhir/ValueSet/{name} for a ValueSet so it's quite explicit that it is a ValueSet resource that is being indicated (and uses the standard FHIR API to resolve it)...
Peter Jordan (Aug 13 2019 at 09:29):
We need https because these are resolvable
'codesystem 'I've seen contracted to 'cs', if you want something shorter
Value sets could be denoted ValueSet or valueset or vs
Yes, we can discuss at HISO - and also the day before at the meds workshop, because we should make it a priority to identify the namespaces we need for meds
Since when have http end points not been resolvable?
With regard to Code Systems - in this context I believe that we are discussing Naming System Identifiers for those Code Systems, in which case creating an identifier that looks rather like an instance of a CodeSystem Resource is not a great idea - cs would be preferable.
In the case of Value Sets we are NOT talking about Naming System Identifiers (valueset is not a NamingSystem Type) . Instead, we are looking at Canonical URLs that resolve to the 'master copy' of a FHIR ValueSet resource. Therefore, there is no question that the URL should contain 'ValueSet' - anything else and it won't be a valid FHIR endpoint.
WRT to Namespaces for 'Meds', I wonder if anyone who has actually implemented a working FHIR Terminology Services API for NZMT (or AMT for that matter) will be at that 'workshop'? Better still, this should be discussed on an open forum, such as here, rather than behind closed doors. For starters, take a look at this...
https://terminz.azurewebsites.net/fhir/NamingSystem/NZMT
David Hay (Aug 13 2019 at 18:31):
So let's take a real example.
- I created a CodeSystem for iwi with a url of http://standards.digital.health.nz/fhir/CodeSystem/nziwi
- Then, I created a ValueSet with a url of http://standards.digital.health.nz/fhir/ValueSet/nziwi that has a compose.include.system that refers to http://standards.digital.health.nz/fhir/CodeSystem/nziwi
My thinking is that both of these (CodeSystem and ValueSet) could resolve once the infrastructure was in place (ie http://standards.digital.health.nz/fhir).
Does that seem reasonable?
I didn't create a NamingSystem for the CodeSystem, but if I did so, then it would have a .kind of 'codesystem' and a .uniqueId with .type='uri' and a .value of http://standards.digital.health.nz/fhir/CodeSystem/nziwi The .id could be anything - though nziwi would be consistent
agree?
The CodeSystem and ValueSet are on Ontoserver (https://ontoserver.csiro.au/stu3-latest/) if you want to take a look...
(btw - quite happy for the actual names to be challenged - they're in the model at nz.clinfhir.com - I just want to get everything working so they can be reviewed)
Alastair Kenworthy (Aug 13 2019 at 19:26):
Have you been to a website with 'http' lately?
To avoid any confusion, 'cs' is an option others have taken and we could too
We had a pattern for these namespaces, there was discord in the process but I thought we had agreement, and now it seems everyone has their own personal favourite approach
David Hay (Aug 13 2019 at 20:40):
Well, the use of 'http:' seems to be what most other IG's are using - take a look at US-Core for example... (or the other guides in fhir.org) - so would be good to be consistent with that. - http://hl7.org/fhir/us/core/STU3/index.html
wrt canonical URL's - yes, 'cs' seemed fine - until I actually started using it and got horribly confused at times... So I think we should use a full URL - again like US Core does: http://hl7.org/fhir/us/core/STU3/ValueSet-omb-race-category.html
After all, this is all about 'doing it for real' to see if our assumptions were correct - and being prepared to change if not...
Peter Jordan (Aug 13 2019 at 23:16):
I'm happy with David's proposal, apart from the NamingSystem uri for the 'codesystem' kind. IMHO, this should not be the URL of a FHIR CodeSystem resource - instead, it should be a canonical identifier for the code system (i.e. CodeSystem.url). We discussed this in today's SNOMED on FHIR call and I am going to put in a gForge Tracker to suggest that this distinction be clarified in the FHIR specification.
David Hay (Aug 13 2019 at 23:38):
Here's what I would suggest for a NamingSystem
{
"resourceType":"NamingSystem",
"name":"NZ_IWI",
"status":"active",
"kind":"codesystem",
"date":"2019-08-14",
"description":"The identifiers for a CodeSystem containing the NZ IWI concepts",
"uniqueId": [
{
"type":"uri",
"value":"http://standards.digital.health.nz/fhir/CodeSystem/nziwi"
}
]
}
Peter Jordan (Aug 13 2019 at 23:43):
Disagree. A per my previous post, that value should not be the URL of a FHIR CodeSystem resource - it should be what is in the CodeSystem.url property of the relevant CodeSystem resource - something like https://standards.digital.health.nz/cs/nziwi.
If it helps in making that distinction, consider that many NamingSystem identifiers for code systems are not FHIR-specific. An obvious example is http://snomed.info/sct
David Hay (Aug 13 2019 at 23:54):
Hold on - I thought we agreed above the the CodeSystem.url value would be http://standards.digital.health.nz/fhir/CodeSystem/nziwi - like others do when a CodeSystem is not already defined - eg http://hl7.org/fhir/us/core/STU3/CodeSystem-condition-category.html ?
Peter Jordan (Aug 14 2019 at 00:07):
The ones created to date resolve to Web Pages - rather than FHIR CodeSystem resources - e.g.
https://standards.digital.health.nz/codesystem/ethnic-group-level-4
We have to be mindful of code systems that are not FHIR-specific. Not to mention the fact that there is no FHIR endpoint on that domain.
Michael Lawley (Mar 24 2020 at 13:33):
And be mindful of when you're talking about URIs and when you're talking about URLs.
It is "nice" if URIs are resolvable, but not required. Furthermore, the resolution process can redirect (eg from an http-based URI to an https-based URL).
(sorry to drop in late -- this just presses my URIs are not URLs button)
Peter Jordan (Mar 24 2020 at 18:38):
Indeed. Code System URIs are identifiers and one might expect to see them in NamingSystem Resources where the Identifier Type is uri. OTOH, Code System URLs are locations and one would expect to see the Canonical URL of a Code System in the url property of all instances of the related CodeSystem Resource.
Marcus Shirrefs (May 10 2021 at 03:00):
Hi all, I've been searching to see if there's a defined extension for capturing Ethnicity and Iwi against the Patient resource (esp. for NZ). Seems this thread is one of the closest. Can anyone point me to anything already agreed/done around extensions to Patient for these two? TIA, Marcus
Peter Jordan (May 10 2021 at 04:31):
A FHIR API for the NZ NHI (National Health Index) is due to be published very shortly and the Patient Profile contains extensions, and associated terminology resources, for NZ Ethnicity and Iwi. @David Hay has worked on this, and may be able to provide an update. The proposed national extension for Ethnicity can be found here, but its status is only draft at this stage.
Marcus Shirrefs (May 11 2021 at 06:33):
Thanks for the update @Peter Jordan . Looked at the proposed extension. Not sure if I'm reading it right, but looks like it is targeted for Patient and Practitioner. Does that mean RelatedPerson and Person aren't getting it @David Hay ?
David Hay (May 11 2021 at 06:36):
Well, it's a draft proposal so not yet discussed by the HL7NZ committee. No technical reason why not - do you have a use case where this is required? ie where Patient / Practitioner is not appropriate?
Marcus Shirrefs (May 11 2021 at 06:41):
@David Hay No, no use case for those other two at this stage. Just looking forwards. Just thinking out loud, perhaps via RelatedPerson you might seek to trace Ethnicity or Iwi relationship / inheritance? e.g. My "Welsh" component of ethnicity comes from RelatedPerson.relationship = mother. But I have no use case for that atm.
David Hay (May 11 2021 at 08:35):
No worries - further contexts can always be added if needed...
Last updated: Apr 12 2022 at 19:14 UTC
