Stream: terminology
Topic: Country Codes
Grahame Grieve (Feb 07 2018 at 01:02):
@Ted Klein @Rob Hausam where would I find the minutes from the WGM in NOLA? I need to implement country codes ASAP and want to do what we said we'd do
Ted Klein (Feb 07 2018 at 01:22):
http://confluence.hl7.org:8090/display/VOC/Wednesday+Q1+Minutes
Ted Klein (Feb 07 2018 at 01:22):
But maybe not the decision you are looking for. Here is what was minuted: Bring in ISO country codes to the unified code systems.
there are numeric codes, 2 character alpha codes and 3 character iso code options used for different purposes.
Versioning is also an issue it is encorporated in the urn.
HTA has to think about how we acknowledge the IP and how we publish an external code system such as this one.
urn:iso:std:iso:3166:-1:ed-1:en this is the urn for the first edition of ISO 3166 part 1 in english
We should publish the identifier, but the registry has to contain the actual content as there is no readilly accessible iso version. The tracker item asks to combine parts 1 and part 2 containing all the parts versions and additions, or we could have the uri at the part level and have a different entry for each variation of the code system.
Grahame Grieve (Feb 07 2018 at 01:25):
so we decided to have different code systems for the different parts
Grahame Grieve (Feb 07 2018 at 01:25):
the link from the old wiki to the new wiki is broke, btw
Ted Klein (Feb 07 2018 at 01:33):
oh good grief. Yes when Patrick moved the Confluence pages the links broke, I'll see if I can fix it tonight. I never got back any information from the email to ISO, and I am trying to get in touch with the 3166 maintenance agency. They announced that they will release a new version in 2018 soon. So we should do separate URLs for each of the 3 parts, then they can track the versioning correctly (as ISO will update the parts on a difference schedule).
Grahame Grieve (Feb 07 2018 at 01:41):
so I forgot to look at this. We've already used urn:iso:std:iso:3166 extensively for the 2 lette codes
Grahame Grieve (Feb 07 2018 at 01:42):
mapped to 1.0.3166.1.2.
Ted Klein (Feb 07 2018 at 02:48):
Well that's not a good urn, according to 5141 for the ISO specs and from ISO themselves. Should be urn:std:iso:3166:-1 And if all you have is the 2 letter codes, that is just 1/3 of the code system content.
Grahame Grieve (Feb 07 2018 at 02:48):
it's not that I disagree, but I think that we're too late to fix this.
Ted Klein (Feb 07 2018 at 02:49):
`
Grahame Grieve (Feb 07 2018 at 02:49):
we can say that we use urn:std:iso:3166:-1 for what we were going to use urn:std:iso:3166:-1 :ed-1 for, and then use the others
Ted Klein (Feb 07 2018 at 02:50):
well that would be too bad then.
Ted Klein (Feb 07 2018 at 02:51):
if the maintenance agency publishes the urn to be used when they do the release later this year, if it is in conflict with us, that would be Bad, IMHO
Ted Klein (Feb 07 2018 at 02:53):
I will send another missive to Geneva and see if I can get a response
Rob Hausam (Feb 07 2018 at 02:53):
I'm sure it's going to be a pain, but I'm not sure why we can't fix it - and if we are going to fix it, doing it now would be better than later.
Ted Klein (Feb 07 2018 at 02:54):
My thought exactly
Grahame Grieve (Feb 07 2018 at 02:54):
well, we have 100s of uses of that url. including in content going normative. if we're going to change it, we have to decide now. And then I have to somehow figure out how to support the old url in code supporting the old versions
Ted Klein (Feb 07 2018 at 02:59):
I think we should swallow the bitter pill now. and btw - the current edition is 2, so the urn would be urn:std:iso:3166:-1:ed-2
Ted Klein (Feb 07 2018 at 02:59):
with edition 3 promised later this year
Rob Hausam (Feb 07 2018 at 02:59):
agree
Rob Hausam (Feb 07 2018 at 03:00):
but Grahame will have to do most of the work :(
Ted Klein (Feb 07 2018 at 03:00):
I just wish Geneva was more responsive. I sent that email over a month ago.
Rob Hausam (Feb 07 2018 at 03:01):
so presumably we'll also need to change again once edition 3 becomes a reality
Ted Klein (Feb 07 2018 at 03:01):
sigh
Ted Klein (Feb 07 2018 at 03:02):
I will CALL the folks in Geneva tomorrow morning. Although it probably won't do any good...
Grahame Grieve (Feb 07 2018 at 03:06):
why would we change the system URL for subsequent version releases? do they change codes? none of the other uses of 2 letter country codes have any versioning infrastrcture
Grahame Grieve (Feb 07 2018 at 03:06):
en-US.. imagine if that changed meaing....
Rob Hausam (Feb 07 2018 at 03:35):
unless I'm missing something, we'll either need to stay with the edition-agnostic url (which doesn't officially exist) or we'll need to keep up with it as the editions change - I'm not thinking of another obvious choice
obviously the former would be far easier, but I believe we're here because we thought we needed to use the "official" urls
Grahame Grieve (Feb 07 2018 at 03:37):
umm. I understood 'edition' to refer to 3 different parts updated independently. So there's 3166, in parts, each of which have versions
Grahame Grieve (Feb 07 2018 at 03:37):
is that wrong?
Lloyd McKenzie (Feb 07 2018 at 03:38):
I'm opposed to using an edition-specific URI. We should have one URI for 2-character codes that we use for all time. If ISO does something bone-headed and re-uses a 2-letter code at some point in the distant future, then people can put the version-specific URI in the Coding.version element.
Rob Hausam (Feb 07 2018 at 03:42):
I believe that edition and part are separate
I just checked Wikipedia which talks about 3 parts and 5 editions, but Ted was referring to the current 2nd and the upcoming 3rd edition, which definitely doesn't correspond - so I'll leave it to Ted to clarify
Rob Hausam (Feb 07 2018 at 03:43):
I think I'm leaning toward Lloyd's position, regardless of what ISO does - maybe we (Ted) can convince them later
Grahame Grieve (Feb 07 2018 at 03:44):
ideally, we'll have stable URLS for the parts, and also URLS for each edition of each part, and we'l use the stable URLs for code system URLs
Rob Hausam (Feb 07 2018 at 03:44):
right
Grahame Grieve (Feb 07 2018 at 03:45):
but I'd rather not change the existing URL for the 2 letter part, even if it breaks the pattern
Rob Hausam (Feb 07 2018 at 03:48):
using "urn:iso:std:iso:3166" to mean specifically the 2-letter codes and not the others doesn't seem like a great idea, but not wanting to change it certainly is understandable
Ted Klein (Feb 07 2018 at 20:13):
OK, sorry didn't look at this until now...so there are three parts. PART ONE contains the 2-letter codes, AND the 3-letter codes AND the numeric codes. THERE EXISTS NO PART OR SEPARATE EDITION OR PUBLICATION OF JUST THE 2-LETTER CODES. Sorry for shouting, but there is a reason that for YEARS we have had to use the HL7 value set machinery to separate the 2-letter codes and the 3-letter codes. That is just what it is, published by someone outside of HL7, It is what it is. It is my understanding that the changes in the editions are the removal of countries that disappear (being gobbled up by aggressive neighbors) and additions of new countries (South Sudan anyone?). I think there may have been some name changes in the past that may or may not have involved code changes, I would have to research that (Burma->Myanmar when the military coup happened all those years ago comes to mind). All this having been said, it would be more convenient to have one stable URI for each Part, and use our HL7 versioning machinery to deal with the edition releases, and I would support that. But Lloyd, if you really want to have one URI for the 2-letter codes only (with potentially a different one for the 3-letter codes) then I would have to insist that you create a new FHIR code system "based on ISO 3166-1" on take on the burden of maintaining it as an HL7 owned and curated object, and remove text that claims that it is the ISO code system so as to avoid violating copyright and IP stuff with ISO. Maybe you can make urn:fair:lloyd:country, for instance :-)
Grahame Grieve (Feb 07 2018 at 20:47):
if part 1 includes in the 2 letter codes and the 2 letter codes and the numeric codes, what do the other parts contain?
Lloyd McKenzie (Feb 07 2018 at 20:59):
-1 includes country codes. -2 includes province/state/territory codes. -3 include retired country codes. Because I guess you need a new code system when you retire things??
Grahame Grieve (Feb 07 2018 at 21:00):
makes sense if you think about publishing rather than code systems
Lloyd McKenzie (Feb 07 2018 at 21:01):
I'm happy for there to be one URI for the country codes and we can filter to 2-character codes using valueset machinery. What I needed was a way to separate out the province/state/territory codes. If we want to treat the whole thing as a single humongous code system and do everything with value set machinery, I can accept that - though we'd need to revamp the existing country code value set too.
Grahame Grieve (Feb 07 2018 at 21:01):
so I'd like to use urn:iso:std:iso:3166 for all 3 kinds of codes, then. Not sure about -3.
Grahame Grieve (Feb 07 2018 at 21:01):
I've never seen anyone using part 2 codes.
Grahame Grieve (Feb 07 2018 at 21:01):
@Lloyd McKenzie do you want to draft a code system for all the codes?
Lloyd McKenzie (Feb 07 2018 at 21:04):
Using province & territory codes?
Grahame Grieve (Feb 07 2018 at 21:11):
well, 2 variants for review?
Lloyd McKenzie (Feb 07 2018 at 22:39):
Not following the request...
Ted Klein (Feb 07 2018 at 22:58):
Part two is country subdivisions (in the US the states, in Canada the provinces, etc). Part 3 is changed/retired country codes, so actually contains the provenance/audit trail for the country codes that were changed/retired.
Grahame Grieve (Feb 07 2018 at 22:59):
so part 3 isn't a separate coding system? and we're not using part 2 in FHIR, we've been using http://hl7.org/fhir/ValueSet/usps-state
Lloyd McKenzie (Feb 07 2018 at 23:05):
usps-state doesn't really fly for an international standard...
Grahame Grieve (Feb 08 2018 at 00:33):
well, you can make a proposal then.
Grahame Grieve (Feb 08 2018 at 00:33):
Eric Haas (Feb 08 2018 at 20:11):
usps-state is used extensively in the US and that aint gonna change anytime soon and I am surprised Canada is not the same. We actually gave you guys NB so a mapping would be good ( and Lloyd should still be thanking us for that :-))
Grahame Grieve (Feb 08 2018 at 20:11):
NB?
Eric Haas (Feb 08 2018 at 20:12):
"In
November 1969, at the request of the Canadian
postal administration, the abbreviation for
Nebraska, originally NB, was changed to NE, to
avoid confusion with New Brunswick in Canada."
Grahame Grieve (Feb 08 2018 at 20:13):
wouldn't happen now...
Grahame Grieve (Feb 08 2018 at 22:14):
@Ted Klein we said in the disposition to this that we would define value sets for the 2/3 letter, and numeric codes from 3166. But because of IP restrictions, I can't do this by enumeration, right?
Rob Hausam (Feb 08 2018 at 22:33):
can't we use filters to do it?
Ted Klein (Feb 08 2018 at 22:34):
I think we can enumerate the 2 letter codes no problem, but for the 3 letter and the numeric ones we probably have to do an intensional definition. If I can ever contact someone at CS I'll get a clarification.
Rob Hausam (Feb 08 2018 at 22:38):
I believe it would be best to use the intensional definitions for all of them, and I'm not sure if the IP affects that
I think we'll also need a value set of 2 character codes plus the 3 character codes where a corresponding 2 character code doesn't exist?
Grahame Grieve (Feb 08 2018 at 23:30):
technically I can do eiher. enumerated is better for the implementers, so I'm happy to do that for 2 letter
David McKillop (Feb 09 2018 at 00:19):
(deleted)
Alexander Henket (Feb 09 2018 at 08:08):
Considering the widespread use of country codes and the widespread misunderstanding of how those work/are maintained, it's probably a good idea to try to add the gist of this discussion to the CodeSystem/ValueSet descriptions.
We've, The Netherlands, not specified ISO 3166 in FHIR so far, as coded countries are a rarity and people have a textual string instead where a code could have been (Address.country) -- also in Address the uri does not surface.
That being said, we've made the mistake of changing things over the years in V3 because we felt they could be done better moving forward all the while forgetting to respect existing implementations more. I really agree with Grahame's argument to accept that implementations for ISO 3166 based on the current uri make it next to impossible to start changing it now.
The current terminologies-systems.html explanation needs updating though:
- urn:iso:std:iso:3166
- ISO 2 letter Country Codes
- A few country codes have been reused (e.g. CS). If a version is needed, simply use the year of publication e.g. 1998
- 1.0.3166.1.2.2
What the current OID mapping is, beats me given the discussion above:
- 1.0.3166.1 Complete iso3166-1
- 1.0.3166.1.2 Complete iso3166-1edition2
- 1.0.3166.1.2.1 Complete iso3166-1edition2numeric
- 1.0.3166.1.2.2 Complete iso3166-1edition2alpha2
- 1.0.3166.1.2.3 Complete iso3166-1edition2alpha3
You would think, that all of the above have some sort of relationship to the uri
Grahame Grieve (Feb 09 2018 at 11:11):
I'm midway through the editorial work of updating it
Grahame Grieve (Feb 09 2018 at 11:32):
you should have run into iso3166 a lot, in StructureDefinition.jurisdiction and ValueSet.jurisdiction
Grahame Grieve (Feb 10 2018 at 03:43):
ok, build.fhir.org is fully updated for iso3166 - please check (mainly at http://build.fhir.org/iso3166.html)
Grahame Grieve (Feb 10 2018 at 03:44):
I haven't updated tx.fhir.org to support iso 3166 yet
Last updated: Apr 12 2022 at 19:14 UTC
