Stream: implementers
Topic: Passport as Identifier, where to store additional properties
Leonid Toporkov (Nov 17 2018 at 09:12):
Passport number works great as Person/Patient/Practitioner unique identifier (authorities in charge to care about its uniqueness), however for other purposes like filling contract form or other forms, I need to store additional properties of passport as a document: date of issue, place of issue, code of issuing organization…
Where is the right place to store such info? Extend Identifier type or there some resources or approaches I missed? The way to extend Identifier looks controversial, because, in this case we store information which is not used as identifier directly.
I’m sure it's not the only situation w/ passport and Patient resource. Correct solution will help to those who have similar issues w/ Organization.identifier or any other kinds of identifiers where you have to save additional properties for further paperwork.
Thank you!
Lloyd McKenzie (Nov 17 2018 at 20:18):
Identifier.period.low should work for date of issue and Identifier.organization can take you to code of the issuing organization. issuing location would need to be an extension - though you could submit a change request for it to be a standard extension.
AbdulMalik Shakir (Nov 18 2018 at 06:27):
A passport is a document. Shouldn’t it be represented as a composition with patient as its subject?
By the way the passport identifier identifies the passport not the patient. It’s a great surrogate identifier for patient because each passport has one and only one subject.
Grahame Grieve (Nov 18 2018 at 11:07):
Shouldn’t it be represented as a composition with patient as its subject?
if we were actually support passport management, maybe. But we're just recording a proxy patient identifier
Lloyd McKenzie (Nov 18 2018 at 13:05):
Even then, it doesn't really behave as a document in the FHIR sense. It's not a frozen snapshot. (It's intended to be updated with visas, entry and exit stamps, etc.) It also doesn't have a primary purpose of telling a human mediated story where order can be variable and context is important.
Leonid Toporkov (Nov 18 2018 at 15:09):
@Lloyd McKenzie thanks! you mentioned very interesting type of document: visa, which is document by itself (despite the fact it is attached to your passport): it is issued by foreign authorities, it has unique number (identifier), it has own issue date and effective period (btw, here is starting point of the effective period doesn't necessarily have to be the same with Issue date). I don't think Visas are important for healthcare systems, but as a sample it seems tricky to use it as identifier and store its properties without extending...
@Grahame Grieve do you think it is better to store such data using external systems either FHIR resources?
Lloyd McKenzie (Nov 18 2018 at 15:21):
Again, calling a Visa a "document" is a bit of a misnomer in the FHIR space. A collection of data elements does not necessarily represent a "document".
Grahame Grieve (Nov 18 2018 at 22:40):
do you think it is better to store such data using external systems either FHIR resources?
Before I'd hazard an opinion on that, I'd want to know what other external standards existed
AbdulMalik Shakir (Nov 18 2018 at 23:59):
How is a passport and for that matter a visa not a document?
"A document is an immutable set of resources with a fixed presentation that is authored and/or attested by humans, organizations and devices."
I can't think of a use case in which passport management was important in a health information system, however, @Leonid Toporkov seems to have a need for more detailed about a passport than simply its role as a surrogate patient identifier. Perhaps it is important for medical tourism, I don't know. But whatever the use case a passport is a document. Not a clinical document, but a document nonetheless.
Lloyd McKenzie (Nov 19 2018 at 00:18):
A pathologist report is a document - the narrative has primacy and tells a story intended to be consumed by a human and read in order. A passport in FHIR is just a collection of data elements. Narrative would not be relevant and it doesn't tell a story. The order in which the information is consumed by a human doesn't matter.
Richard Townley-O'Neill (Nov 19 2018 at 00:30):
Could one use DocumentReference to refer to a passport?
AbdulMalik Shakir (Nov 19 2018 at 01:04):
Perhaps we are tripping over the term "document." What if instead, we used the word "report," documentation of the outcome of an act. Emphasis on "documentation." I think that a passport is a report of the act of certifying a person's citizenship. It's a certification, not unlike a birth certificate, a death certificate, or wedding certificate. It is not unusual to think of these certification reports as documents. But if not documents they can be considered compositions with predefined sections of information.
SNOMED defines certification (the act of certifying) as a type of procedure (310417005). The FHIR Procedure resource includes a report element "Any report resulting from the procedure." The only procedure report type defined at the moment is the DiagnosticReport resource. I assert that a passport is a report of citizenship certification. I would choose to use a composition resource to represent it and request that Procedure.report be allowed to reference a composition. This might be useful for death certificate and birth certificate also.
Lloyd McKenzie (Nov 19 2018 at 01:43):
Everything in healthcare is a record of some sort. And in the paper world, we refer to all sorts of information as a "document". That leads people to gravitate towards using Composition for things. But, in most cases, it should never be necessary to use Composition to share a piece of information in FHIR. Whether you're talking about a lab report or a prescription, there's nothing inately "document" about them. It's fully possible to share such information without bringing Composition or the notion of FHIR documents into play. (That doesn't mean that you can't package them in a document if the need arises, just that you never have to and that the relevant information never lives in Composition as its primary representation.
If verification were what was of interest, VerificationResult might be a possibility.
AbdulMalik Shakir (Nov 19 2018 at 02:20):
@Lloyd McKenzie would you suggest using "VerificationResult" for birth certificate and death certificate also? Are certification and verification the same concepts.
Yunwei Wang (Nov 19 2018 at 02:23):
(deleted)
Lloyd McKenzie (Nov 19 2018 at 02:37):
I think certification and verification are essentially the same, yes. @Brian Postlethwaite your thoughts?
Leonid Toporkov (Nov 19 2018 at 07:11):
Let’s say, new patient comes in for an exam.
His first physical stop happens at the check-in desk (encounter), where patient presents his id (passport) and administrative staff has to do some paperwork, particularly fill contract and general consent form.
I do create new Patient resource and put there passport number as identifier element (+ we use NamingSystem to describe passport realm), but for filling contract and consent according to the local policy I have to retrieve and store additional properties of the passport: date of issue, code of issuing organisation (code of certain police station), name of issuing organization, males have military/army marks. Technically, for a medical system these fields are useless, there no situation where I need code of Organization which issues passports for any analytics or identifying purpose.
So, in general, my problem and initial question is simple, what is best practice for this:
(1) put into Patient.Identifier.value only passport number and store other passport properties which are required by local policy somewhere in other database/tables/services, I mean somewhere outside fhir space, and retrieve those properties on the application level for particular tasks: e.g. print contract form. Thats I think @Grahame Grieve was saying;
(2) put Identifier.value passport number, Identifier.period.low as issue date, create issuing Organization resource and put its code to Organization.Identifier.value, then put reference to Patient.Identifier.assigner. That’s what @Lloyd McKenzie was talking about. Thats looks very reasonable, but I was confused that we have to generate and maintain about 1500 organization resources just for supporting one property of the passport - code of issuing organization. Meanwhile medical system doesn’t care about it at all;
(3) somehow use Composite or DocumentReference as a storage of any additional properties, and that’s was the idea from @AbdulMalik Shakir and @Richard Townley-O'Neill ;
That’s I was confused with and thanks to all for your help!
Alexander Ivanov (Nov 19 2018 at 10:45):
Patient.Identifier.assigner is the Reference type and it contains not only reference field but Identifier and Display as well, you can use them.
John Moehrke (Nov 19 2018 at 13:45):
I think the problem is that we are struggling with understanding WHY you need anything other than the passport identifier and assigning authority. Once we understand why, we can help guide you on where it seems logical to put it. Grahame is trying to leverage external standards where ever possible. If there is an external standard for storing passport data, then that should be used. It likely means that the passport gets encoded into that format, and that format is stored in Binary that is referenced by a DocumentReference. Thus you have a comput processible format, stored in FHIR.
John Moehrke (Nov 19 2018 at 13:47):
I ask why you need it, as once you record it you will need to protect it appropriate to regulations/laws around that storage. Just because there is rich data on a passport, does not mean it should be captured. Privacy-by-Design would have you not capture any elements that you don't legitimately need.
John Moehrke (Nov 19 2018 at 13:53):
as to the assigning authority, you don't need to use an Organization resource for this. for passports, the 3 letter alpha of the assigning country is used as the assigning authority.
The three-letter code used by the International Civil Aviation Organization (ICAO) adopted by ISO/IEC 7501-1:2008, Identification Cards – Machine Readable Travel Documents – Part 1: Machine Readable Passports, and used by all international machine readable travel documents (MRTD) issuing entities, is intimately linked with the alpha-3 code employed in the first part of ISO 3166-1, Part 1: Country codes.
AbdulMalik Shakir (Nov 19 2018 at 14:00):
Reading the last note from @Leonid Toporkov it seems that the passport is being used as authenticating an identity claim. It this way it is no different than a driver's license, birth certificate, voter's registration card, digital certificate, or government issued photo id. The data captured are only those that are sufficient to use the device as an authoritative source of personal identity verification. The fact that it is a passport is not the central piece of the requirements.
John Moehrke (Nov 19 2018 at 14:03):
I did enter a change request to get it clarified on how to put a passport number into Identifier, specifically consistent treatment of .system element for R5 GF#19671
Leonid Toporkov (Nov 19 2018 at 14:07):
Patient.Identifier.assigner is the Reference type and it contains not only reference field but Identifier and Display as well, you can use them.
@Alexander Ivanov genius! i missed that. do you use it that way?
Alexander Ivanov (Nov 19 2018 at 14:18):
@Leonid Toporkov Yes, we use it for internal purposes. Would you like to use it for Russian passports? We can discuss it in Russian thread then, it would be great to have a common system id for a Russian passport. Also, it would be great to have a common approach to encode series and number.
Leonid Toporkov (Nov 19 2018 at 14:23):
@Alexander Ivanov yes, the issue with national passports.
Leonid Toporkov (Nov 19 2018 at 14:57):
@AbdulMalik Shakir yes, I think you're right. I was saying about passport just as a sample document. in case we use unique number as patient.identifier everything is fine, but if (in our case) local policies require to store custom properties of document, it's not easy to decide where to place it.
Elliot Silver (Nov 19 2018 at 20:17):
@John Moehrke I always thought of the system as the country, and the specific passport office as the assigner. Your tracker essentially proposes a passport "system", and the country as the assigner. I wonder if there is a place or need to track issuing office.
John Moehrke (Nov 19 2018 at 20:34):
It is not clear. I only intended to get a CR started to choose a path and document it. I think your thinking is what my thinking is, which could be different than I wrote...
Brian Postlethwaite (Dec 03 2018 at 11:30):
I don't think that VerificationResult and Qualification are the same. You can use a Verification Result to record the details that a qualification is real, and current, and how you found that out, and when (and if) you plan to re-check this periodically and using what process.
A qualification is just the recording of the details of the qualification.
So a VerificationResult could be used to record the details of checking a passport details, and if you need to do it more than once etc, but wouldn't store the details of the passport, that would need to be somewhere else.
I don't think including them in the passport would be a sensible place, except maybe the number itself - only because the patient is shared around so much, and the information is Very sensitive.
Lloyd McKenzie (Dec 11 2018 at 00:13):
Well, it's a question of whether you're trying to represent the passport, or whether you're using the passport as the mechanism of verifying identity. In healthcare, if you're capturing details about a passport, it's typically for the process of using it as a credential to verify identity.
Last updated: Apr 12 2022 at 19:14 UTC
