Stream: new zealand
Topic: Naming System Identifiers
Peter Jordan (Apr 21 2017 at 01:01):
Regarding the Naming System Identifiers for NZ National Health Index (NHI) and Health Provider Index (HPI) Numbers, the current proposal is still to use the following...
NHI (patient)...http://nhi.health.nz
HPI-CPN (common practitioner number)...http://hpi-cpn.health.nz
HPI-FAC (healthcare facility identifier)...http://hpi-fac.health.nz
HPI-ORG (healthcare organization number)...http://hpi-org.health.nz
Since these were first mooted, about a year ago, we have had no significant pushback and it's getting close to the time when we need to ballot their use among HL7 NZ members and seek approval from HISO. I met with the Health Identity Team yesterday and they appeared to be happy with them.
David Hay (Apr 21 2017 at 01:14):
Thanks Peter - Let's propose these to HISO next month. Any more? (since we're on a roll...)
Peter Jordan (Apr 21 2017 at 01:31):
Can't think of any more Naming System Identifiers that we need asap - but do you have any candidates for urgently-required extensions to the patient resource, notably patient-ethnicity, patient-iwi and patient-hapu? Following the process suggested in your recent Blog entry, it might be that another domain has already created one for ethnicity, but Hapu and Iwi are probably unique to NZ.
David Hay (Apr 21 2017 at 01:50):
good idea - I'll ask around. We may as well to hapu/iwi since we'll need that at some point. And same for ethnicity I guess...
David Teirney (Apr 24 2017 at 02:08):
At first glance, the proposed identifier URIs look different to conventions used elsewhere.
For many other identifiers defined by an entity, the domain represents the entity and the path the type of identifier. For example, HL7 International uses http://hl7.org as the domain for all identifiers.
With that in mind an alternative might look like:
http://health.nz/fhir/nhi
http://health.nz/fhir/hpi-cpn
http://health.nz/fhir/hpi-fac
http://health.nz/fhir/hpi-org
Potentially even using /hpi/ as a path parameter to identify that these identifiers are part of the HPI.
http://health.nz/fhir/nhi
http://health.nz/fhir/hpi/cpn
http://health.nz/fhir/hpi/fac
http://health.nz/fhir/hpi/org
health.nz is the base domain owned by the MoH according to https://www.dnc.org.nz/health-nz, so perhaps hiso.health.nz would be a better domain.
http://hiso.health.nz/fhir/nhi
http://hiso.health.nz/fhir/hpi/cpn
http://hiso.health.nz/fhir/hpi/fac
http://hiso.health.nz/fhir/hpi/org
The URIs proposed above feel more similar to identifiers defined by other entities.
Peter Jordan (Apr 24 2017 at 04:18):
Using health.nz/fhir is really not a good idea, because that may well be the FHIR server endpoint for the Ministry so employing it for naming system identifiers will cause no end of issues and confusion. I would also prefer not to use a pseudo-HISO domain as, beyond NHI and HPI identifiers, HL7NZ is more likely to be the custodian of these (as with OIDs). Not sure about any conventions, but I see no reason to place the word fhir in Naming System Identifiers which live independently of FHIR (ditto Code System Identifiers).
David Teirney (Apr 24 2017 at 08:12):
Some HL7 defined identifiers are defined on https://www.hl7.org/fhir/identifier-registry.html.
If HL7 NZ is going to be the custodian (including the associated OID), is the following more appropriate?
http://hl7.org.nz/fhir/nhi
http://hl7.org.nz/fhir/hpi/cpn
http://hl7.org.nz/fhir/hpi/fac
http://hl7.org.nz/fhir/hpi/org
Agree that if these URIs will be used outside of FHIR then not appropriate to include /fhir/.
As someone that's had to use some system URIs, it's very useful to be able to go to that URL and find information about it. Are there plans to support that as well?
Peter Jordan (Apr 24 2017 at 20:44):
I should have explained that better, but HL7NZ is more likely to be the custodian of the registry, not the identifiers themselves. The URIs should reflect the organisation that maintains the Identifier type, code system, etc. hl7.org.nz/fhir is also problematic as that will probably be the HL7NZ FHIR server endpoint. Using resolvable URLs as identifiers is worth discussing, although it should be noted that many of the major code system identifiers are not resolvable - e.g. http://snomed.info/sct.
David Hay (Apr 24 2017 at 21:06):
perhaps the url could resolve to the NamingSystem resource that describes it eg http://hl7.org.nz/fhir/NamingSystem/nhi...
Peter Jordan (Apr 24 2017 at 22:59):
That's an interesting idea, but might depend on whether the Health Identity team would accept that. They might want a Naming System Identifier for NHI and HPI that's not specific to FHIR. My preference is still to have a health.nz component...
now wondering if they should start with health.govt.nz, e.g. http://health.govt.nz/nhi ? That may be more consistent with proposed NZ Code System uris, e.g. http://health.govt.nz/ethnicity-codes-level-1
Peter Jordan (Apr 25 2017 at 21:34):
Still not totally convinced about having FHIR in the Naming System Identifiers for NHI and HPI...unless the aim is for them to point to FHIR Naming Resources on a Ministry FHIR Server. I’m now thinking of...
http://health.govt.nz/nhi
http://health.govt.nz/hpi-cpn
http://health.govt.nz/hpi-fac
http://health.govt.nz/hpi-org
Michael Lawley (May 08 2017 at 22:15):
Have to agree with @Peter Jordan 's unease about including fhir in teh URIs, unless FHIR is an intrinsic part of the identity of the thing being identified
Grahame Grieve (Jul 11 2017 at 07:01):
What's the difference between the different HPIs? if someone says to me that they have 'an hpi', what's the system URL?
Brian Postlethwaite (Jul 11 2017 at 22:36):
They are for the different types of resource
Patient nhi
Practitioner hpi-cpn
Location hpi-fac
Organization hpi-org
Grahame Grieve (Jul 12 2017 at 10:28):
k ta
Peter Jordan (Jul 15 2017 at 04:28):
Candidate Naming System URLs are a few posts back on this Stream. HL7NZ is planning to ballot them later this year.
Peter Jordan (Nov 30 2017 at 23:22):
My quest to seek approval for these candidate identifiers continues...
NHI: http://health.govt.nz/nhi
HPI Common Practitioner Number: http://health.govt.nz/hpi-cpn
HPI Facility ID: http://health.govt.nz/hpi-fac
HPI Organisation ID: http://health.govt.nz/hpi-org
Plus some candidate URIs for NZ-specific Code Systems...
NZ Medicines Terminology: http://nzmt.org.nz
NZ Ethnicity Level 1: http://health.govt.nz/ethnicity-codes-level-1
NZ Ethnicity Level 2: http://health.govt.nz/ethnicity-codes-level-2
NZ Ethnicity Level 3: http://health.govt.nz/ethnicity-codes-level-3
NZ Ethnicity Level 4: http://health.govt.nz/ethnicity-codes-level-4
The Facility, Organisation and Code System identifiers are in use on [Terminz] (http://its.patientsfirst.org.nz/RestService.svc/Terminz). I'll continue to proceed on the basis that it's easier to seek forgiveness than permission!
Graeme Hibbert (Dec 01 2017 at 00:45):
Thanks Peter, these look good. Better than the earlier idea that included /fhir.
Alastair Kenworthy (Dec 01 2017 at 22:57):
My quest to seek approval for these candidate identifiers continues...
NHI: http://health.govt.nz/nhi
HPI Common Practitioner Number: http://health.govt.nz/hpi-cpn
HPI Facility ID: http://health.govt.nz/hpi-fac
HPI Organisation ID: http://health.govt.nz/hpi-orgPlus some candidate URIs for NZ-specific Code Systems...
NZ Medicines Terminology: http://nzmt.org.nz
NZ Ethnicity Level 1: http://health.govt.nz/ethnicity-codes-level-1
NZ Ethnicity Level 2: http://health.govt.nz/ethnicity-codes-level-2
NZ Ethnicity Level 3: http://health.govt.nz/ethnicity-codes-level-3
NZ Ethnicity Level 4: http://health.govt.nz/ethnicity-codes-level-4The Facility, Organisation and Code System identifiers are in use on [Terminz] (http://its.patientsfirst.org.nz/RestService.svc/Terminz). I'll continue to proceed on the basis that it's easier to seek forgiveness than permission!
health.govt.nz is the MOH corporate domain whereas health.nz is the moderated domain for web services; so I’d suggest the latter more suited
Second suggestion is to distinguish that these are namespace identifiers by including a subdomain along the lines of ns.health.nz
ns.health.nz/nhi or ns.health.nz/nhi-number
Actual service endpoints may look something like api.health.nz/
Peter Jordan (Dec 02 2017 at 00:06):
OK with health.nz, rather than health.govt.nz - although the reasoning is dubious, i.e. conflating identifier URIs with web service endpoint addresses. My point remains that these identifiers are not necessarily for the exclusive use in FHIR resources.
Not at all convinced of the need for a subdomain to indicate that they are namespaces or the -number suffix. I've not seen any other examples of this and it isn't done for code systems.
Service endpoints - that's another discussion, although this a case where it might be worth denoting that they are FHIR APIs - e.g. health.nz/FHIR.
Alastair Kenworthy (Dec 05 2017 at 01:49):
I proposed an "ns" subdomain because I believe naming system URIs need to be clearly identifiable as such. Others have used "fhir" or "value-set" subdomains or URI components to do more or less the same in their schemes. In this way ns.health.nz/nhi-number is fairly clearly about the NHI number namespace whereas health.nz/nhi-number is more ambiguous. We also need to think about whether the URIs should be resolvable. What have Aus, UK, US done?
David Hay (Dec 05 2017 at 01:56):
see http://hl7.org/fhir/identifier-registry.html in the spec. AFAIK they don't generally resolve...
Peter Jordan (Dec 05 2017 at 08:11):
Readable information about Naming System Identifiers and Code Systems can be placed in ('human friendly') properties of the relevant terminology resource, such as NamingSystem.description and CodeSystem. title. I think that it would be a mistake to attempt to do this via the URI. From an implementation perspective, the 'ns' prefix on the domain name serves no purpose whatsoever. Incidentally, there is no DNS entry for health.nz, whereas there is one for health.govt.nz. Therefore my quest for the identifiers I've been proposing for the past year continues!
Peter Jordan (Jan 19 2018 at 02:27):
The latest version of Terminz contains NamingSystem resources containing the 9 identifier and code system uris proposed above.... http://its.patientsfirst.org.nz/RestService.svc/Terminz/NamingSystem will return a bundle containing all 9. It's also possible to filter searches by kind (e.d. NamingSystem?kind=identifier or NamingSystem?kind=code system) AND effectively map 'old school' OIDs (e.g. those used in GP2GP) to uris by requesting the NamingSystem where a particular oid is one of the identifier values (e.g. NamingSystem?value=2.16.840.1.113883.2.18.2 for the NHI).
Michael Lawley (Mar 17 2018 at 04:09):
But it's very useful for people if they do. IMO it shouldn't matter for machines because they are URIdentifiers and not URLocations
Alastair Kenworthy (Mar 26 2018 at 03:52):
NZ government wants to establish namespace identifiers for national health identifiers and code systems. Intention is to use the digital.health.nz domain.
As an example of the sort of thing we imagine, see this from Australia: http://ns.electronichealth.net.au/id/medicare-number - the defined namespace identifier for Medicare numbers in Australia
And this from UK: https://fhir.nhs.uk/Id/nhs-number - the namespace identifier for NHS numbers
Of course, this is about supporting FHIR implementation but there may be other uses too.
The FHIR spec seems to recommend that such links should be resolvable. And, for example, http://ns.electronichealth.net.au/id/medicare-number resolves to a web page with human readable info.
A similar scheme in NZ would look something like: http://ns.digital.health.nz/id/nhi-number
Variations on this theme include:
http://ns.digital.health.nz/id/nhi-number-1
http://ns.digital.health.nz/code-system/nhi-number-1
http://standards.digital.health.nz/ns/nhi-number-1
http://standards.digital.health.nz/id/nhi-number-1
http://standards.digital.health.nz/code-system/nhi-number-1
In any case, it would seem that good namespace identifiers should be:
- resolvable (and not likely to conflict with a real API endpoint)
- self-describing (ie obviously about a namespace or naming system or code system)
- versioned
- using the official ecosystem domain (we may also end up using code systems with URIs in other government domains, such as data.govt.nz)
Grahame Grieve (Mar 26 2018 at 03:54):
- "resolvable (and not likely to conflict with a real API endpoint)": we would refer to an API end-point directly on the expectation that if it was just a browser (accept = text/html) then you'd get a description page
- "versioned" - umm maybe. but why? identifier spaces are not usually versioned..
Peter Jordan (Mar 26 2018 at 07:36):
"New Zealand government" - so this is a cabinet recommendation? Yeah right, as the Kiwis say! I could live with http://digital.health.nz/nhi (on reflection, I don't like the versioning suffix - increasing the number of digits won't change the fact that it's an NHI number) . Otherwise, the candidates above remind me of the alternatives in the flag referendum in terms of attempting to select the best from a bad bunch. Personal opinions only of course, I would love to see the views of the FHIR implementation community in NZ, outside of the Cabinet Office and Molesworth St! :)
Alastair Kenworthy (Mar 26 2018 at 19:27):
Sounds like we don't need the version number - so let's turn it around and say instead 'without a version number'
Re Grahame's first point - yes, content negotiation makes is possible to serve a web page describing the API.
But we still want to be able to distinguish namespace URIs from API endpoints. by their structure.
Igor Sirkovich (Mar 26 2018 at 19:37):
We are having a similar discussion in Canada. We plan to have all our URIs resolvable and fully defined using a NamingSystem resource at some point. So far, we've agreed on the following guidelines:
URI guidelines
1. Base url for common public identifiers: https://fhir.infoway-inforoute.ca/NamingSystem
2. Ids should be all all-lower-case-hyphen-separated
3. Ids should avoid abbreviations to improve readability and support unambiguous understanding of terms (whenever is possible and makes sense)
4. Ids that are scoped by province/territory should be prefixed with the ca (for Canada) & province/territory code - e.g. "ca-ab-some-codes" or "ca-ab-some-id"
5. Ids that are national in scope should be prefixed with "ca-" - e.g. "ca-some-id"
6. Words that make up the identifier should start from the general type and then get more specific. E.g. "ca-on-license-driver" rather than "ca-on-driver-license"
6a. Words should be consistent across identifiers when possible. I.e. Try to use "patient-health-number" if everyone else is using "patient-health-number"
7. Words should be expressed in the primary language of the province/territory that manages them
8. Words should not use accented characters
9. Use descriptions from hl7.org/oid where available when we map URIs to the existing OIDs
10. Acceptable abbreviations: ca (for Canada), jurisdictional codes (e.g. ab, on, bc), id (for identifier)
Grahame Grieve (Mar 26 2018 at 20:16):
@Alastair Kenworthy - yes, it's ok for them to be different, and ok for you to make a rule that they should be - I was just being clear about content negotiation.
Peter Jordan (Mar 26 2018 at 21:08):
I also favour the use of NamingSystem resources. Still not convinced about the need to make the URIs resolvable. I see a stronger case for this where the NamingSystem.kind is CodeSystem - although the classic example of a non-resolvable CodeSystem URI is http://snomed.info/sct (interested to know if this is viewed as a positive or negative). Part of my concern around making NZ identifiers resolvable is the fact that, in terms of stability, our Health IT governance landscape matches our physical environment!
Grahame Grieve (Mar 26 2018 at 21:19):
I expect that snomed.info/sct will resolve one day
Igor Sirkovich (Mar 26 2018 at 23:18):
One of the benefits of having URIs of identifier systems resolvable in NamingSystem is an ability to use FHIR API to get definition, contact information, etc. about a concept represented by a URI. Another benefit is an ability to map URIs to OIDs and to other URIs (in case different projects create duplicate URIs, one can be marked as a preferred) using repetitions of uniqueId. Also it's easy to extract URIs needed for your use case, e.g. get all URIs of a patient identifier type in my jurisdiction.
Peter Jordan (Mar 27 2018 at 00:41):
@Igor Sirkovich IMHO, those are all benefits of creating NamingSystem Resources and storing them in a central location - such as a National Terminology Server. A much more robust solution than scattering information about Identifiers among a bunch of Web Pages. For an example see... http://its.patientsfirst.org.nz/RestService.svc/Terminz/NamingSystem
David Hay (Mar 27 2018 at 02:11):
@Grahame Grieve When you say 'resolve', do you mean that the result of the url call would be a NamingSystem resource? ie that entering snomed.info/sct would result in a NamingSystem resource? (Assuming that the accept header was set to application/fhir+{xml/json} ?
Grahame Grieve (Mar 27 2018 at 03:32):
well, I expect that will return a web page. I'm not holding my breath for a naming system or a code system resource but it's possible one day
Alastair Kenworthy (Mar 27 2018 at 09:41):
@Igor Sirkovich I like your naming rules, which are similar to ISO/IEC 11179 we use in NZ for creating names
Alastair Kenworthy (Mar 27 2018 at 09:58):
@Peter Jordan Great to have those machine-readable resources, yes. But also fine to have the URIs resolve to human readable web pages. Because they're at that one address they can hardly be said to be scattered
Igor Sirkovich (Mar 27 2018 at 14:32):
You might also find helpful the FHIR URI Strategy document authored by @Lloyd McKenzie : https://docs.google.com/document/d/1ClF3XpIrE2FiIDG7K7VD3pPjOPx3T950Sfi1Ip8ORcU
Alastair Kenworthy (Mar 27 2018 at 18:10):
That's good read - some useful recommendations in there
Peter Jordan (Mar 27 2018 at 19:18):
@Alastair Kenworthy the one web address point only applies to the NHI and (possibly) HPI - not all NZ Code Systems and Identifiers - but ultimately the decision on whether digital.health.nz endpoints are resolvable, and continuing to ensure that they are, is down to the domain owner. Either way, I'm happy to implement http://digital.health.nz/nhi, http://digital.health.nz/hpi-cpn, etc. as the new candidate identifiers.
Michael Lawley (Mar 27 2018 at 20:52):
In terms of URI resolvability, I think the key thing is the expectation you set. Yes, it's useful if it can resolve to machine-readable content, but if that becomes an expectation / contract, then you'll get software that expects and relies on that resolvability. I would be wary of this as it introduces a maintenance burden and leads to potentially brittle systems.
Alastair Kenworthy (Mar 28 2018 at 00:02):
So, to summarise and following the other international examples (particularly Australia but also UK and Canada) and considering the above points on resolvability and versioning, the proposed scheme is now something like:
http://ns.digital.health.nz/id/nhi-number
http://ns.digital.health.nz/naming-system/nhi-number
http://standards.digital.health.nz/ns/nhi-number
http://standards.digital.health.nz/id/nhi-number
http://standards.digital.health.nz/naming-system/nhi-number
Our namespace identifiers are then:
- self-describing (ie obviously about a namespace, naming system or code system)
- based on ISO/IEC 11179 rules for element names
- not including a version number
- preferably resolvable through content negotiation to a NamingSystem resource and also descriptive web pages
- using the official ecosystem domain (we may also end up using code systems with URIs in other government domains, such as data.govt.nz)
http://digital.health.nz/nhi is a little non-specific and misses some of these things
Peter Jordan (Mar 28 2018 at 01:01):
Don't like the ns (does it denote namespace or naming system??) or standards prefixes on the domain names.
The -number suffixed to nhi confuses the concept of a naming system (in this case the National Health Index) with an instance of that system (an individual NHI number).
How about http://digital.health.nz/naming-system/nhi
David Hay (Mar 28 2018 at 17:41):
If we were to copy what infoway is doing, we'd have:
https//fhir.digital.health.nz/NamingSystem/nhi
going back to the idea of resolvability...
Peter Jordan (Mar 28 2018 at 20:11):
Interesting - advice to affilates from HL7 international is that 'fhir' cannot be used in domain names registered by non-HL7 organizations. Maybe infoway is such an organisation?
Grahame Grieve (Mar 28 2018 at 20:12):
that advice is not correct. where did you get that?
Peter Jordan (Mar 28 2018 at 20:13):
Mark McDougall - but would be grateful to hear any official change to that advice.
Grahame Grieve (Mar 28 2018 at 20:13):
The correct advice is that the use of "fhir" in a domain name by a non-HL7 affiliate is a use of the trademark , and requires written permission from HL7. Such organizations can apply for permission here: http://www.fhir.org/product-license
Grahame Grieve (Mar 28 2018 at 20:14):
the official policy is here: http://wiki.hl7.org/index.php?title=FHIR_Trademark_Policy
Peter Jordan (Mar 28 2018 at 20:15):
Thanks for that. I'll also update the relevant International Council Wiki Page accordingly.
Grahame Grieve (Mar 28 2018 at 20:16):
... infoway do not have such written permission
Peter Jordan (Mar 28 2018 at 20:24):
It's also been mooted (many posts) above that it's not best practice to place 'fhir' anywhere in the URI of a Naming System that isn't specific to FHIR (e.g. the NZ NHI).
David Hay (Mar 28 2018 at 20:24):
so, in the event that NZ did use this url, we'd need permission also?
Grahame Grieve (Mar 28 2018 at 20:25):
yes. Wouldn't be a problem though
Igor Sirkovich (Mar 28 2018 at 20:34):
@Grahame Grieve Infoway is an affiliate of HL7. Do they need to ask a permission to use "fhir" in their sub-domain name? Also eHealth Ontario is a non-direct affiliate via Infoway. I'm wondering if they need a permission to use "fhir" in their URL path, e.g. "https://ehealthontario.ca/API/FHIR/NamingSystem"
Grahame Grieve (Mar 28 2018 at 20:36):
I didn't realise infoway itself was an affiliate. I'm not sure about 'non-direct affiliates' - whatever that means
Grahame Grieve (Mar 28 2018 at 20:36):
how do you read the policy? Is it linked to a formal project for HL7 canada?
Igor Sirkovich (Mar 28 2018 at 20:43):
My understanding is that HL7 Canada under Canada Health Infoway is a Canadian affiliate of HL7 International and that all HL7 Canada members (e.g. eHealth Ontario) are eligible for all benefits of HL7 membership, e.g. use of all HL7 standards, SNOMED CT, etc.
Igor Sirkovich (Mar 28 2018 at 20:46):
I'm going to talk to Infoway / HL7 Canada to clarify this
Peter Jordan (Mar 28 2018 at 21:38):
As I read things, no one needs to seek permission (or forgiveness) for using FHIR in a URL path - only a domain name. Is that correct? If not...'Ann Arbor, we have a problem'.
Grahame Grieve (Mar 28 2018 at 21:39):
I think so
David Hay (Apr 11 2018 at 19:53):
We close to agreement on the Identifier urls yet? My last proposal was https://fhir.digital.health.nz/NamingSystem/nhi which would resolve...
Peter Jordan (Apr 11 2018 at 21:18):
I'm not happy with fhir being part of the domain name, particular as NHI is not a FHIR-specific identifier. Otherwise, that's now the candidate identifier I'll be putting up on Terminz this weekend for the NZ community to look at.
David Hay (Apr 11 2018 at 21:45):
but it will resolve to a NamingSystem resource (if the accept header is appropriately set). And nothing stops it being used outside of FHIR - though not sure where that would be...
Peter Jordan (Apr 11 2018 at 22:10):
If the aim is for this url to resolve to a NamingSystem resource, my personal preference would be for https://digital.health.nz/fhir/NamingSystem/nhi However, questions remain as to when either url might be available and how stable they will be (given the constant changes I've had to make to links to MoH urls over recent years). IMHO, decoupling the identfier url and the resource location would be a prudent design decision - I don't see why the relevant NamingSystem resource couldn't be held on multiple servers, just as other terminology
resources are held in multiple locations. It's also possible that this decoupling might increase the chances of the identifier being immutable?
Lloyd McKenzie (Apr 12 2018 at 20:41):
The intention is that the URL for the NamingSystem would resolve - because that's useful. If the maintaining organization changes, hopefully the domain would be maintained with a redirect. The Naming system URL should certainly be treated as immutable once established.
Peter Jordan (Apr 12 2018 at 21:12):
Thanks Lloyd. The remaining question is whether the (immutable) Naming System URL should resolve to an instance of the relevant Naming System resource - or something else, such as a Web Page?
Lloyd McKenzie (Apr 12 2018 at 22:26):
In Canada, we went with resolving to the NamingSystem because it can in turn point to one (or more) relevant web pages and be updated as those pages change. The web pages of the identifiers and code systems of interest change semi-regularly and are managed by people and processes that don't really care about (or often even know about) FHIR or interoperability standards and interfaces. On the other hand, the repository of NamingSystems would almost certainly be maintained by an organization that does know and care about those things.
Peter Jordan (Apr 12 2018 at 22:32):
Thanks again, Lloyd. That certainly mirrors the NZ experience with web pages. Which organization is likely to maintain the repository of NamingSystem resources in Canada?
Lloyd McKenzie (Apr 12 2018 at 22:33):
Canada Health Infoway
Lloyd McKenzie (Apr 12 2018 at 22:34):
Even if they go poof at some point, that function (and the domain name that it's managed under) would presumably be transferred
Lloyd McKenzie (Apr 12 2018 at 22:34):
And they'd at least recognize the importance of the transition.
David Hay (Apr 13 2018 at 02:08):
and we can still use the accept header to return a web page rather than a NamingSystem...
Daniel Thomson (Apr 20 2018 at 02:13):
If the aim is for this url to resolve to a NamingSystem resource, my personal preference would be for https://digital.health.nz/fhir/NamingSystem/nhi However, questions remain as to when either url might be available and how stable they will be (given the constant changes I've had to make to links to MoH urls over recent years).
FWIW I now manage the dns for digital.health.nz so can setup A / CNAME records as required under the digital.health.nz domain if we have agreement on URLs for name space identifiers for NHI, HPI etc
(prob worth mentioning that the top level of https://digital.health.nz hosts the digital health strategy site and that hosting is provided by an outside party so there maybe more work- but not impossible- at the ministry end in terms of resolving to a URL hosted at the top level i.e. https://digital.health.nz/fhir/naming-system... vs a subdomain like https://fhir.digital.health.nz/naming-system/...)
David Hay (Apr 20 2018 at 02:20):
Do you have a preference for the url patterns to use for the NamingSystems?
Daniel Thomson (Apr 20 2018 at 02:51):
No strong preference at this point- they're all going to work probably! Following Aus / UK / Canada patterns seems sensible as will contribute to recognizing the kind of thing the URI is.
https://standards.digital.health.nz/naming-system/nhi-number seems the most human readable/descriptive of the options if that's a consideration (it's a general nz digital health standard, it's a naming system, it's the nhi)
Peter Jordan (Apr 20 2018 at 04:33):
IMHO, human readability isn't a requirement. I'd also consider the standards prefix on the domain name to be redundant unless it makes it easier to resolve. Thereafter /fhir/NamingSystem/nhi would make more sense if the aim is to resolve to a NamingSystem resource. The -number suffix is also misleading as we are dealing with a naming system (i.e. the National Health Index) NOT an instance of that system.
Lloyd McKenzie (Apr 20 2018 at 13:01):
Human readability is sort of the whole point :) In FHIR, we want the instances to be easy for humans to read because it makes development, and more important, debugging easier. Using abbreviations is fine if they're ones that everyone who might be developing code will understand, but I'd recommend avoiding making things obscure just to save a few characters. (And don't forget that lots of development is now often out-of-country, so think about what would be intuitive outside of New Zealand too).
Peter Jordan (Apr 20 2018 at 20:12):
Each to their own, but identifiers (URLs, or otherwise) aren't my usual bed-time reading. :) Machines do tend to like them, regardless of length, providing they take you somewhere. The longer the length, the more painful they are for many humans - hence bit.ly abbreviations.
Ironically, in terms of making this identifier readable and recognisable outside of NZ, no one has suggested expanding the 'nhi' acronym and even 'National Health Index' doesn't tell you that it's a patient identifier. So maybe the task of human readability is best delegated to a NamingSystem resource (or Web Page)?
David Hay (Apr 21 2018 at 03:10):
I think Lloyds point is that http://hl7.org/fhir/sid/us-medicare is easier to deal with than 2.16.840.1.113883.4.3.2 when trying to debug a problem...
Peter Jordan (Apr 21 2018 at 05:48):
True, but that's rather like saying that ASCII is easier to read than hexadecimal :)
Lloyd McKenzie (Apr 21 2018 at 14:38):
I'm also saying that if you're going through the effort of changing from OIDs to URIs to improve readability for developers, http://hl7.org/fhir/sid/us-medicare-patient is better than http://hl7.org/fhir/sid/usm
Peter Jordan (Apr 21 2018 at 20:28):
In terms of readability, both of those last 2 examples are equally opaque to this developer as I don't know what a 'sid' is - and that illustrates my point about expanding 'nhi' if the NZ identifier is to be readable by developers outside of NZ. As for OIDs, the longer this thread goes on, the more those ugly ducklings are beginning to look like swans.
Michael Lawley (May 07 2018 at 22:45):
I'll only add that I keep seeing the confusion of URLs and URIs and have come to the conclusion that using URIs that look syntactically like FHIR URLs (in this case, anything of the form [base]/NamingSystem/[id] is likely to lead implementers to assume that it's a FHIR URL and not an arbitrary URI.
Lloyd McKenzie (May 07 2018 at 22:47):
The preference is to have URIs that are URLs so they can be resolved by implementers seeking additional information. It's not mandatory, but it's certainly good practice.
Michael Lawley (May 07 2018 at 22:51):
And I would entirely agree with having URIs resolvable, just not mis-interpretable. People don't read documentation, but they do pattern-match. If they see a URI that looks like a FHIR URL, they tend to assume (and write code etc) with that assumption. Hence I would use something like https://digital.health.nz/naming-system/nhi over https://digital.health.nz/fhir/NamingSystem/nhi where the difference is arbitrary, but deliberate.
Lloyd McKenzie (May 07 2018 at 22:55):
Well, in Canada our objective is for NamingSystem to be resolvable as a FHIR resource - so it can be retrieved and parsed by software for things like automatic translation between OIDs and URIs.
Lloyd McKenzie (May 07 2018 at 22:56):
So that choice of URL was deliberate to align with FHIR resource URL conventions.
Michael Lawley (May 07 2018 at 22:59):
And is there an SLA / implied contract that it will always be resolvable?
Lloyd McKenzie (May 08 2018 at 01:24):
No more than there is with the FHIR value sets - which follow the same pattern. It's not not expected to be the primary source targeted by runtime systems, but it's a fallback they can hit and cache the results if they see something they haven't seen before.
Alastair Kenworthy (May 18 2018 at 06:32):
I also need URIs for the ISO country and language code systems.
NZ uses ISO 3166-1 alpha-2 country codes (https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) and ISO 639-2 language codes (https://en.wikipedia.org/wiki/ISO_639-2) (we need Niuean and some others not in "-1"). It looks like the convention is to use urn:iso:std:iso:3166 as the identifier for this country code system - although not distinguishing the alpha-2, alpha-3 and numeric variants - and urn:ietf:bcp:47 as the identifier for the language tag code system encapsulating ISO 639-2 (https://www.hl7.org/fhir/terminologies-systems.html). Is this what people are doing?
Lloyd McKenzie (May 18 2018 at 07:02):
If your code system is listed on the FHIR terminologies page and you claim to be conformant with that version of FHIR, then it's not merely convention - it's a requirement of the standard. So urn:iso:std:iso:3166 for country codes and urn:ietf:bcp:47 for language is the correct answer.
Alastair Kenworthy (Jun 05 2018 at 10:51):
Is anyone creating NamingSystem resources to declare the existence of code systems in addition to creating the CodeSystem resources themselves? The practice seems to be to create a NamingSystem resource for each identifier system and a CodeSystem resource for each code system. Is this enough? The documentation doesn't make it perfectly clear what's required - in various places:
A NamingSystem resource is a curated namespace ...
The NamingSystem resource identifies the existence of a code system or identifier system ...
The CodeSystem resource defines the content of a code system ...
The CodeSystem resource is used to declare the existence of a code system ...
Lloyd McKenzie (Jun 05 2018 at 14:04):
CodeSystem doesn't give you the canonical OID or the v2 code system string. If you don't need those things, then NamingSystem isn't really buying you anything.
Peter Jordan (Jun 05 2018 at 19:36):
I've created NamingSystem resources to allow the main Code System OIDs used in NZ CDA instances, notably GP2GP and NZePS, to be mapped to FHIR CodeSystem URIs. However, the purpose of a NamingSystem resource clearly isn't to declare the existence of a FHIR Code System resource.
Alastair Kenworthy (Jun 05 2018 at 20:50):
Thanks @Lloyd McKenzie and @Peter Jordan, that helps
"The NamingSystem resource identifies the existence of a code or identifier system" - ie correct interpretation of "identifies" seems to be "points to" rather than "declares"
Lloyd McKenzie (Jun 05 2018 at 20:53):
For identifier systems, NamingSystem is really all you have. I'd expect the NamingSystem to include things like rules for normalizing identifiers (e.g. strip all punctuation, use lower-case, retain leading zeros). For CodeSystem, much of the guidance around usage will typically be found in the CodeSystem resource, though it's not wrong to duplicate the same sort of information in NamingSystem. The contents will only live in CodeSystem though.
Peter Jordan (Jun 28 2018 at 03:02):
The NZ Ministry of Health has now created a URL and home page for 'Digital Health Standards' ( https://standards.digital.health.nz) and the following 'Identifier Namespaces'.
NHI Number: https://standards.digital.health.nz/id/nhi
HPI Person Identifier: https://standards.digital.health.nz/id/hpi-person
HPI Organisation Identifier: https://standards.digital.health.nz/id/hpi-organisation
HPI Facility Identifier: https://standards.digital.health.nz/id/hpi-facility
These seem reasonable to me, and they'll be in the next release of Terminz. I'm quite not so thrilled with the code system ones as they might be confused with URLs for CodeSystem resources. Anyway, the 'process' by which we landed here was, shall I say, 'interesting'. :)
John Carter (Jun 05 2019 at 05:09):
Following up on this thread, in the spreadsheet published at https://www.health.govt.nz/nz-health-statistics/data-references/code-tables/common-code-tables/facility-code-table, I see the HPI Organisation Identifier in Column J, and I see the HPI Facility Identifier in Column C. My question: there is also a Health Facility Code in Column B. I don't see an Identifier Namespace for that code... should there be one? Is that Health Facility Code still in active use?
Peter Jordan (Jun 05 2019 at 06:20):
I'm sure that there are still legacy systems that use that Code, but the advice on that page relating to the HPI Facility ID is WAY out of date @Anne Goodwin - most systems now use the HPI Facility ID (e.g. NZePS). To be honest, I don't even bother to expose the Facility Code in directory services as lots of Facilities in the published list don't have one. Therefore, I don't believe that we need an Identifier Namespace for it - do you agree @Alastair Kenworthy ?
Alastair Kenworthy (Jun 05 2019 at 06:32):
We really need to remove all use of the facility code, so let's not honour it with a namespace identifier because it will only encourage continued use
Brian Postlethwaite (Jun 05 2019 at 09:36):
And if you don't specify it, you'll end up with different representations of it if it is in use.
You could include a best practice invariant to discourage its use instead.
Peter Jordan (Jun 05 2019 at 20:31):
It's also worth taking into account the fact that we've never created an OID for the Facility Code.
David Hay (Jun 05 2019 at 21:10):
so to be clear:
- The primary Organization identifier is the HPI Org Id (there are others defined like nzbn (nz business numbers)
- The primary Location identifier is the HPI Facility code (should that be HPI facility Id)
The 'facility code' that John is referrring to is deprecated... That right? Do we want to add any clarification notes to the model? (which will eventually wind up in the IG) - if so let me know either here or via email and I'll update the model...
Peter Jordan (Jun 06 2019 at 03:42):
The primary location identifier in NZ is the HPI Facility ID. I'd completely ignore the (deprecated) HPI Facility Code.
John Carter (Jun 06 2019 at 22:07):
Thanks all, very helpful!
Peter Jordan (Jul 17 2020 at 23:19):
So now - over a year since the standards.digital.health.nz Web Page was created and a Naming System Identifier for the NHI of https://standards.digital.health.nz/id/nhi published - we are are seeing https://standards.digital.health.nz/ns/nhi-id as that identifier in a proposed FHIR IG for the NHI. Too bad for any implementations already using the published identifier and others shown on that Web Page. :sad:
Top-down Control 1 FHIR Community Process 0
Dave deBronkart (Jul 18 2020 at 00:59):
As someone who's still repeatedly getting befuddled by HL7's processes-and-nots, I must ask, is there a protocol for letting others (top and bottom) know that such a thing has happened?
Is it possible to speak (here or elsewhere) to the authors of that IG?
David Hay (Jul 18 2020 at 01:25):
It was determined by the national governmental standards authority
Peter Jordan (Jul 19 2020 at 04:02):
TTBOMK, there is no record of who authorised this change to a published - and implemented - naming system identifier, or why the change was made. Certainly, there has been no community engagement. I could say a lot more, but probably shouldn't on a public forum. :angry:
Dave deBronkart (Jul 19 2020 at 17:45):
David Hay said:
It was determined by the national governmental standards authority
Well it seems silly that citizens working on IT standards weren't involved! I'd expect the health minister would be able to figure out who was involved... otoh I don't have a clue how important it is, vs just plain being annoying.
Peter Jordan (Jul 19 2020 at 20:32):
It's a little below ministerial level :slight_smile: . Health Sector Governance wise, NZ is in a transitional state as the recently-published recommendations of the Health & Disability Sector Review proposed the break-up of the Ministry of Health, with all implementation concerns being passed to a new Crown Entity provisionally titled "Health NZ". With this in mind - not to mention the COVID-19 response and an upcoming General Election - it's really hard to see why an Organisation that is tasked to operate at a policy level should be concerned with FHIR Implementation Details.
Hamish MacDonald (Jul 22 2020 at 10:08):
David Hay said:
It was determined by the national governmental standards authority
Great, so a bottom up system of data interoperability standards (FHIR) is being influenced in New Zealand by a top-down system of "informing" the community what the standards are. (Even if "only" Identifiers in this case, what is the next thing NZ might be 'informed" about? This does not engender confidence to commit to doing FHIR implementations in NZ. Could get very expensive - and retroactively expensive, the worst kind. @Mark Braunstein sorry to drag you into NZ matters, but this is related to what we were talking about today regarding Provenance of data.
Dave deBronkart (Jul 22 2020 at 11:43):
Dumb question: has anyone tried contacting the "offending" authority? Perhaps they didn't realize this work's already underway, and/or perhaps they could be encouraged to rethink it, for the sake of leveraging work that's already being done by developers, vs adding work.
The ideal outcome of course would be if they ended up joining (or at least monitoring) the work!
Last updated: Apr 12 2022 at 19:14 UTC
