Stream: nordics
Topic: Nordic Person lookup operation
Jens Villadsen (Sep 07 2019 at 21:48):
In DK we have a centralized repo for person demographics where we can lookup a person by using thee national central registration number (CPR). The information that is delivered is the name, the address and so on - all demographics. This feature usually used whenever a new person is created in any healthcare system where the person is then created as a patient (please mind the distinction between patient and person). If I'm not mistaken, you do have the same kind of repo in both sweden and norway, and probably also in finland. If that is the case, may I suggest that we establish a common custom operation for person lookup - eg. `$lookup, that takes a set of Identifiers and based on that, returns a Person with populated national available demographics?
Grahame Grieve (Sep 07 2019 at 21:49):
is not the mpi-match operation?
Jens Villadsen (Sep 07 2019 at 21:49):
thats on patient
Jens Villadsen (Sep 07 2019 at 21:49):
at this moment, the person is not a patient
Jens Villadsen (Sep 07 2019 at 21:50):
mpi assumes that you are a patient
Jens Villadsen (Sep 07 2019 at 21:50):
unless the naming REALLY sucks
Jens Villadsen (Sep 07 2019 at 21:51):
@Grahame Grieve agree?
Grahame Grieve (Sep 07 2019 at 21:52):
well, yes, it is. though it would make sense for it also to be on person. At least, if that's the only issue of difference, put it to PA to define it on Person as well as Patient
Jens Villadsen (Sep 07 2019 at 21:52):
PA?
Jens Villadsen (Sep 07 2019 at 21:54):
there's a huge difference between a patient and a person
Grahame Grieve (Sep 07 2019 at 21:55):
well, yes, and no. In this case, does the principles that leads to a master index match apply to person the same way they do to Patient? and I think they do. PA = Patient Administration WG
Jens Villadsen (Sep 07 2019 at 21:58):
still ... in the nordics it would be worth profiling that operation then - and a match would be wrong terminology
Jens Villadsen (Sep 07 2019 at 21:58):
you ONLY bring a national identifier
Jens Villadsen (Sep 07 2019 at 21:58):
that uniquely points to a person
Jens Villadsen (Sep 07 2019 at 21:59):
its a lookup function ... its not a matching function
Jens Villadsen (Sep 07 2019 at 22:01):
I guess onlyCertainMatches takes care of some of it
Grahame Grieve (Sep 07 2019 at 22:27):
right it's still matching underneath
Jens Villadsen (Sep 07 2019 at 22:29):
so moving/adding/altering it to person and add some profiling to it could do the job maybe
Grahame Grieve (Sep 08 2019 at 08:15):
could do, yes
Jens Villadsen (Sep 09 2019 at 10:01):
@Thomas Tveit Rosenlund @Mikael Rinnetmäki @Espen Stranger Seland @Michael Johansen
Mikael Rinnetmäki (Sep 09 2019 at 10:49):
I agree profiling the Person rather than the Patient makes sense. We want to be able to describe the details of the Practitioners and related persons too, and the namings are similar there.
Mikael Rinnetmäki (Sep 09 2019 at 10:56):
Regarding the match operation, we may have a use case for that specific operation too. The Finnish national PHR operates internally with the national person id, but usually only exposes a pseudonym to wellness apps. When wellness apps want to ensure the real identity of the person the pseudonym is for, they should be able to ask the MPI of the PHR to verify that a certain national person id (that the app can ask from the user) and the pseudonym match. With just a boolean result.
The details are still under specification in Finland. Ping @Anna Korpela.
Thomas Tveit Rosenlund (Sep 09 2019 at 13:15):
I agree @Jens Villadsen . Profile the Person resource. In fact that is excactly what we are doing in Norway to offer Person information to the health care sector.
https://simplifier.net/guide/masterpersonindexr4/servicesforpersoninformation
Brian Postlethwaite (Sep 16 2019 at 20:03):
This is consistent with Patient Adminstration expectations, and yes the usage of the $match operation on Person is 100% ok. We initially proposed it as a generic operation for any resource, and have placed it on Patient to get initial feedback, but there is nothing about the definition that prevents its usage.
We would expect to see its use in any directory style resources, including Patient, Person, RelatedPerson, Practitioner and even Organizations or HealthcareServices, but open to usage on any resource.
Jens Villadsen (Sep 23 2019 at 20:31):
I agree Jens Villadsen . Profile the Person resource. In fact that is excactly what we are doing in Norway to offer Person information to the health care sector.
https://simplifier.net/guide/masterpersonindexr4/servicesforpersoninformation
I just had a look at your site on https://simplifier.net/guide/MasterPersonIndexR4/ReadandSearch - don't you guys have security/audit log issues having the identifier as part of the query param - or is that only a danish issue
Jens Villadsen (Sep 23 2019 at 21:30):
@Brian Postlethwaite - shouldn't the response example on http://build.fhir.org/patient-operation-match.html be wrapped in a Parameters resource?
Brian Postlethwaite (Sep 23 2019 at 21:34):
Doesn't have to be no.
Jens Villadsen (Sep 23 2019 at 21:37):
you're right
Jens Villadsen (Sep 24 2019 at 19:31):
@Brian Postlethwaite - FWIW, I've implemented $match on Person in an upcoming national danish solution ;)
Brian Postlethwaite (Sep 24 2019 at 21:09):
Have you done a profile for the person resource to inform which props you're going to be considering?
(by just marking those props with must support)
Jens Villadsen (Sep 25 2019 at 08:40):
No but I have considered it - basically the $match operation is not a great fit for my need. The only thing I require is the identifier on the person, and that Identifier is profiled as a datatype. As such the match certainty can only be 0 or 1.0 as it basically is just a lookup in a national register
Jens Villadsen (Sep 25 2019 at 08:41):
It would require me to have specific profile for person and that profile would not necessarily be usable in other contexts
Brian Postlethwaite (Sep 25 2019 at 11:11):
Interesting, with that usage just a regular identifier search would work.
Brian Postlethwaite (Sep 25 2019 at 11:12):
But I guess could increase that later.
Jens Villadsen (Sep 25 2019 at 11:12):
Interesting, with that usage just a regular identifier search would work.
Which is what I originally implemented
Jens Villadsen (Sep 25 2019 at 11:13):
So in order to conform to match, I wrapped the Identifier in a person
Jens Villadsen (Sep 25 2019 at 11:14):
Now I just need the match operation to be formally available on the Person resource as well
Jens Villadsen (Sep 25 2019 at 11:21):
@Brian Postlethwaite while we're at it, talking about standardized operations - shouldn't toiCalbe a standardized operation on Appointment, since there are already mappings for it?
Grahame Grieve (Sep 25 2019 at 11:24):
I just need the match operation to be formally available on the Person resource as well
you don't need that. You can implement your own operation whether we define it in the spec or not. (though I think it would be good if we did)
Jens Villadsen (Sep 25 2019 at 11:24):
I know
Jens Villadsen (Sep 25 2019 at 11:25):
But since there's a standard for it, I might as well follow it as long as it isn't unnecessarily inconvenient
Brian Postlethwaite (Sep 25 2019 at 11:26):
I'd actually considered doing a webcal api on my fhir server so I could hook Outlook direct to it, but never got around to it.
Brian Postlethwaite (Sep 25 2019 at 11:27):
We did talk about permitting it on person and practitioner too, and possibly others.
Want to log a tracker for the match operation?
Jens Villadsen (Sep 25 2019 at 11:27):
We initially proposed it as a generic operation for any resource, and have placed it on Patient to get initial feedback, but there is nothing about the definition that prevents its usage.
We would expect to see its use in any directory style resources, including Patient, Person, RelatedPerson, Practitioner and even Organizations or HealthcareServices, but open to usage on any resource.
My two cents are: @Brian Postlethwaite stated that it could candidate for a standardized operation, so I decided to run for it
Jens Villadsen (Sep 25 2019 at 11:28):
I'd actually considered doing a webcal api on my fhir server so I could hook Outlook direct to it, but never got around to it.
Well ... We already implemented it
Brian Postlethwaite (Sep 25 2019 at 11:28):
Nice
Jens Villadsen (Sep 25 2019 at 11:28):
https://docs.ehealth.sundhed.dk/latest/ig/OperationDefinition-ehealth-appointment-toical.html
Brian Postlethwaite (Sep 25 2019 at 11:30):
That's the export, why not just return the ical binary directly without the bundle?
Jens Villadsen (Sep 25 2019 at 11:30):
thats a bug in the doc
Jens Villadsen (Sep 25 2019 at 11:30):
I just fixed it
Jens Villadsen (Sep 25 2019 at 11:30):
locally
Brian Postlethwaite (Sep 25 2019 at 11:31):
That's an ical export, I meant the free busy calendar data from the schedule too... Over the webcal.
I implemented it in another project.
Jens Villadsen (Sep 25 2019 at 12:08):
Well - I meant the iCal export ;)
Jens Villadsen (Sep 25 2019 at 12:09):
hence, the name
Jens Villadsen (Oct 02 2019 at 12:40):
@Brian Postlethwaite - have you looked into caldav , and transforming calendar appointment responses from the mail client to AppointmentResponse?
Brian Postlethwaite (Oct 02 2019 at 20:30):
Only in theory for the mappings, though should be quite possible. Though I have done a POC for the free/busy status stuff that I had working with Outlook at one point.
Jens Villadsen (Oct 02 2019 at 22:00):
using Schedule/Slot/Appointment?
Jens Villadsen (Oct 02 2019 at 22:01):
open source POC?
Brian Postlethwaite (Oct 03 2019 at 03:06):
Nah, was an internal thing.
Brian Postlethwaite (Oct 03 2019 at 03:06):
And yes using schedule/slot (appointments don't come into free busy)
Jens Villadsen (Oct 24 2019 at 07:44):
Pushing $match to the limit here: I have a need for finding related persons from our central national registers. I already have $match on Person - but that is for a single identifier. The case is that I have all the identifiers of the related persons and I have the possibility in the central registries to look multiple identifiers up in a single invocation. Now, match is currently limited to only a single entity - so ... am I the only one seeing the need for being able to look up multiple persons in a single step? @Brian Postlethwaite @Grahame Grieve
Brian Postlethwaite (Oct 24 2019 at 08:00):
That would make it difficult to associate which ones match to which resource?
If you wanted to do it as a so gle call, put them in a bundle.
Brian Postlethwaite (Oct 24 2019 at 08:01):
Do we support bundled operation invocations?
Jens Villadsen (Oct 24 2019 at 08:48):
That would make it difficult to associate which ones match to which resource?
If you wanted to do it as a so gle call, put them in a bundle.
so input would be (1..* identifiers) - response would be (0..* persons with the matching identifiers embedded in each person)
Brian Postlethwaite (Oct 24 2019 at 09:20):
Input are person resources aren't they...
It's not just a set of identifiers.
It's a set of data to try match a resource.
(eg these identifiers, this name, gender, dob and some contact numbers /addresses)
Brian Postlethwaite (Oct 24 2019 at 09:21):
If you're just using identifiers, 6hen use normal searches....
Jens Villadsen (Oct 24 2019 at 09:22):
yeah - it sounds like I need to provide my own custom operation taking a set of identifiers
Last updated: Apr 12 2022 at 19:14 UTC
