Stream: implementers
Topic: Define urls for passports' identification
Alexander Zautke (Feb 11 2021 at 12:38):
There is currently a discussion in Germany ongoing on how to represent passport identifiers. It seems that there are currently two JIRA tickets discussing the issue: https://jira.hl7.org/browse/FHIR-26437 and https://jira.hl7.org/browse/FHIR-19671. FHIR-19671 already has a resolution, which seems to solve the issue in FHIR-26437. Is this already documented anywhere except these tickets?
Alexander Zautke (Feb 11 2021 at 12:38):
@Giorgio Cangioli
Giorgio Cangioli (Feb 11 2021 at 13:15):
I support your request @Alexander Zautke : -)..
.. FHIR-19671 recommends a pattern, but the status of this issue seems to be "resolved-change required".
So ..it is not clear to me if this is the pattern that we should use or not.. any choice is fine for me, if there is one..
Lloyd McKenzie (Feb 11 2021 at 15:28):
There are a lot of change requests approved by FHIR-I and MnM that aren't yet actioned. We're going to talk about that on FHIR-I tomorrow. Volunteers welcome...
Alexander Zautke (Feb 11 2021 at 21:25):
I tried my best here: https://github.com/HL7/fhir/pull/1094
As far as I can see in the source, it should be enough to get the entry added to the Identifier registry.
Daniel Mechanik (Apr 05 2021 at 22:02):
We have the same issue here in Israel.
We really need a single URI pattern - a base URL + country code suffix, that will allow us to represent international passport numbers.
We also came across this https://github.com/HL7/fhir/pull/1094/files and decided to go for this pattern instead of something of our own, but after we incorporated it into our profile (by binding identifier.system to a ValueSet containing the URI's for different countries) we got an error from the java validator because the URL isn't resolveable.
It seems like the validator only outputs this kind of error when the URL is under HL7's domain. When we switched to a URL under our domain, everything worked.
So now we need to make a decision - should we use our own URL, knowing that this issue will almost surely be incorporated into the standard in the future, which means we will need to change the URL to be interoperable, or should we go for one of the suggested patterns in the existing tickets, which means we can't validate our resources until the URL becomes resolvable?
Jose Costa Teixeira (Apr 06 2021 at 06:09):
Some questions on that PR:
- could we change "passport numbers" to "passport number"? seems more consistent with other NS
- is it valid to have this in the unique id? http://hl7.org/fhir/sid/passport-[XXX]
- what is the meaning of having different unique uris? Can they be different? Is any of those preferred?
Alexander Zautke (Apr 06 2021 at 07:28):
- Sounds good, I can adapt the PR
- I choose the pattern based on some URIs I found on the CodeSystem Page here https://www.hl7.org/fhir/terminologies-systems.html, some of those also have a "[X]" in it
Alexander Zautke (Apr 06 2021 at 07:35):
- Would there be the assumption that the URIs are preferred over the oids? The oid represents the root of all country-specific oids, in general it would be identical to using "http://hl7.org/fhir/sid/passport-[XXX]". Both identify the root. At least that's my current understanding.
Alexander Zautke (Apr 06 2021 at 07:46):
The question now becomes how would a country publish its country-specific naming system, e.g. http://hl7.org/fhir/sid/passport-ISR, given that it's under an HL7 domain
Jose Costa Teixeira (Apr 06 2021 at 09:58):
For preferred uri, I don't mean preferred URIs to OIDs. I mean which of the URIs has a preferred flag to True
Alexander Zautke (Apr 06 2021 at 10:50):
That's what I meant, sorry for being unclear. Why would "http://hl7.org/fhir/sid/passport-[XXX]" be preferred over "2.16.840.1.113883.4.330" other than the fact that an uri may be preferred over an oid?
Alexander Zautke (Apr 06 2021 at 10:52):
Both identify the same namespace
Alexander Zautke (Apr 06 2021 at 10:57):
@Jean Duteau @Ron Shapiro You originally voted on the ticket (J#19671), any suggestions on how to handle the country specific naming systems? So we can help out @Daniel Mechanik here
John Moehrke (Apr 06 2021 at 12:00):
To be clear the pattern http://hl7.org/fhir/sid/passport-{XXX} is proposed that the {XXX} is just the country code. Thus the URL is a legitimate .system for our Identifier datatype.
John Moehrke (Apr 06 2021 at 12:00):
the actual passport number is carried in the Identifier.value
John Moehrke (Apr 06 2021 at 12:01):
and JUST the identifier, right? not some of the other stuff found in the machine readable passport barcode? https://en.wikipedia.org/wiki/Machine-readable_passport
Alexander Zautke (Apr 06 2021 at 12:11):
Yes, currently we are only talking about the system
Daniel Mechanik (Apr 06 2021 at 13:59):
Alexander Zautke said:
The question now becomes how would a country publish its country-specific naming system, e.g. http://hl7.org/fhir/sid/passport-ISR, given that it's under an HL7 domain
If it will depend on each country publishing it's own then it's not really solving our original problem. We treat patients from all around the world and identify them by a country code + passport number. In order to represent this in FHIR we need all countries' URI's to be considerred valid as long as the country code is valid, and the pattern should be the same for all countries so that we can autogenerate the URI without a lookup in a registry.
Is there a way to do this? If not, then I guess generating and publishing all countries at once is a better aprocach
Ron Shapiro (Apr 06 2021 at 15:53):
@Lloyd McKenzie Can the validator error be suppressed for now under the assumption that eventually the change will be applied and the validator will then accept the URI?
Lloyd McKenzie (Apr 06 2021 at 16:33):
Validator errors can't be suppressed. Only warnings and info messages.
Alexander Zautke (Apr 06 2021 at 17:24):
The validator really throwing an error or is it just a warning anyway? @Daniel Mechanik
Daniel Mechanik (Apr 07 2021 at 09:36):
Alexander Zautke said:
The validator really throwing an error or is it just a warning anyway? Daniel Mechanik
It's an actual error, not a warning
Daniel Mechanik (Apr 07 2021 at 13:54):
This is the validator output:
FAILURE validating PatientTest.json: error:1 warn:0 info:0
Error @ Patient.identifier[2].system (line 23, col56) : URL value "http://hl7.org/fhir/sid/passport-USA" does not resolve
Alexander Zautke (Apr 07 2021 at 14:27):
Ah I guess, because it's an HL7 domain it's expected to resolve
Daniel Mechanik (Apr 07 2021 at 15:03):
Alexander Zautke said:
Ah I guess, because it's an HL7 domain it's expected to resolve
Yes, this is what we found out :(
And correct me if I'm wrong here but it's an entirely different issue to have all countries' URL's resolve vs having the URL's in the HL7 registry. I think once they are resolved, then the entry isn't necessary for the validator.
Daniel Mechanik (Apr 07 2021 at 15:09):
One more thought - maybe if we switch the dash to a question mark, then we can make the base URL resolvable, something like this:
http://hl7.org/fhir/sid/passport
and then all possible strings that come after the question mark will also resolve.
So the URI for a USA passport will be:
http://hl7.org/fhir/sid/passport?USA
and it will be resolved.
Is that a valid approach @Lloyd McKenzie ?
Lloyd McKenzie (Apr 08 2021 at 02:36):
Having a question-mark would add complexity when searching - you'd have to escape it. Also, it will make implementing the resolution process harder once we actually get around to doing it. So I wouldn't be in favor of that as a change.
Daniel Mechanik (Apr 08 2021 at 07:37):
Thank @Lloyd McKenzie, good point.
Daniel Mechanik (Apr 08 2021 at 07:37):
Anyway I've been doing some testing trying to understand when exactly the validator expects the URL to resolve, and it seems that most of the URI's in the registry that are HL7 URL's aren't resolvable either. For example the URL for US social security number, http://hl7.org/fhir/sid/us-ssn, behaves exactly the same as http://hl7.org/fhir/sid/passport-[xxx], but the validator accepts it. So I guess once it's in the registry it does not need resolution. I wonder how hard will it be to add ALL countries to the registry at once?
René Spronk (Apr 08 2021 at 09:01):
Which countries? The list depends on the point in time when you create a list, on historic countries that may no longer exist, on countries that may or may not have been recognized as such by some other countries. Good luck :-)
Daniel Mechanik (Apr 08 2021 at 09:14):
Well I guess all codes defined in iso3166, just to make it simple. If there is a code for a country, then we may encounter a passport from that country. It's true though that the list is static and will have to be updated when new countries are born but that's pretty rare. We actually did this but not as NamingSystems, just as a ValueSet for the binding.
Daniel Mechanik (Apr 08 2021 at 09:17):
@René Spronk of course if there's another solution that can support what we want to do without pre generating all possible URL's it would be better...
Daniel Mechanik (Apr 08 2021 at 09:27):
René Spronk said:
countries that may or may not have been recognized as such by some other countries. Good luck :-)
I don't think recognition is relevant for looking at a passport as a means of identification for a person. The 'country' can be regarded as just the issuing authority of the document, it doesn't need to be recognized as a 'true' country by everyone. I guess the political headache you are talking about is more centerred around what codes enter iso3166
Lloyd McKenzie (Apr 08 2021 at 15:39):
In short, don't worry about the fact that the validator yells - it's an issue with the validator. Submit a Git issue against it.
Daniel Mechanik (Apr 08 2021 at 16:12):
Thanks @Lloyd McKenzie . How would I define the issue? is it that the validator shouldn't try to resolve HL7 URL's at all? or should it skip the resolution check specifically for the passport pattern? Or maybe for all URL's under HL7 domain that have a [xxx] in them? Another option might be to skip the check for URL's that are found in a binded ValueSet... A lot of option here :)
Lloyd McKenzie (Apr 08 2021 at 17:08):
The validator should definitely check URLs in the HL7 space - because it should theoretically know about all of them. The issue is that it doesn't know about these ones. It's a bit trickier to handle these because it's not a fixed enumeration. If and when there's a new country code, there'll be a need for a new SID. However, given that the validator has access to the full set of country codes, it should be able to handle it.
Patrick Werner (May 24 2021 at 09:33):
added a regex fixing this issue: https://github.com/hapifhir/org.hl7.fhir.core/pull/512
Patrick Werner (May 24 2021 at 09:34):
This PR only matches the pattern, no countryCode validation (added this as a TODO: in the code)
Grey Faulkenberry (Aug 13 2021 at 18:37):
It's always nice when someone has already asked the question I want to know about. However, in addition to passports, is there anything similar with Tax ID numbers?
Michele Mottini (Aug 13 2021 at 20:44):
Identifier system URI for EIN (= tax id) is urn:oid:2.16.840.1.113883.4.4 (see http://oidref.com/2.16.840.1.113883.4.4)
Last updated: Apr 12 2022 at 19:14 UTC
