Stream: implementers
Topic: Using PDQm on top of MPI with XAD-PID
Stefan Berger (Jan 07 2019 at 20:47):
I'm relatively new to FHIR and have read about PDQm and FHIR Patients for a few hours including the parts on patient.html about patient ids, linking, and merging.
I'm a developer on a software project that offers PIX, PDQ, and XDS transactions. We want to wrap the PIX and PDQ SOAP endpoints with REST services to offer the PDQm and PIXm transactions.
Now to the technical question: A PIX Manager stores patient records of different assigning authorities, for example IHERED, IHEBLUE and IHEGREEN for the Connectathon. All 3 of them are linked together using a newly created XAD-PID because they share the same demographics. The Connectathon tests for PDQm even tell you to load the same patient with different assigning authorities into your system.
Is each one of them its own Patient Resource with its own logical id or do they have to be merged to one Patient entry? If there should be one Patient entry per assigning authority, should the "link" property be filled with the URLs of the same patient in other assigning authorities with the link type property set to "seealso"?
Also is it a bad idea to use an auto-generated primary key value from the database for the Resource.id of a Patient?
I hope anyone can answer my questions.
Best regards,
Stefan Berger
John Moehrke (Jan 07 2019 at 21:00):
This is my understanding, which I suspect we are all discovering the complexity. This very much depends on if you are told to Merge, or Link. Merged would end up with one Patient with two .identifier values. Linked would be an update of the 'linked' Patient.link... which brings up more issues/questions than it closed.
John Moehrke (Jan 07 2019 at 21:00):
Yes, Resource.id should use your auto-generated primary key.... as long as it is a legitimate GUID
John Moehrke (Jan 07 2019 at 21:04):
issues with linked Patients that I initiated is GF#19687
Last updated: Apr 12 2022 at 19:14 UTC
