FHIR Chat · Patient.contact patient-relatedPerson extension

Stream: implementers

Topic: Patient.contact patient-relatedPerson extension

Spencer Evans (May 05 2020 at 22:20):

Hi All,

I'd like to use the patient-relatedPerson extension (defined here by HL7: https://www.hl7.org/fhir/extension-patient-relatedperson.html) to be able to refer to a RelatedPerson from a given Patient as the contact, rather than using the existing Patient.contact field.

The problem I'm running into is the Constaints imposed on Patient.contact (https://www.hl7.org/fhir/patient.html#invs), Expression: "name.exists() or telecom.exists() or address.exists() or organization.exists()"

I'm wondering how the above extension would work naturally with this constraint? Having both a relatedPerson reference and static fields on Patient.contact (that refer to the same person) would likely to lead to inconsistent data if you were to update the RelatedPerson but not your patient.contact fields or vice-versa. Has anyone thought about this or have ideas for how to reconcile?

I remember seeing that there were modifier extensions that you can put on required fields to indicate that they're just serving as a placeholder, but I'd really prefer not to introduce that.

Grahame Grieve (May 05 2020 at 22:40):

I'm wondering how the above extension would work naturally with this constraint?

It seems that the answer is, the #patient administration WG expects you to denormalise the contact details into the Patient resource even if you reference the RelatedPerson resource

Grahame Grieve (May 05 2020 at 22:40):

which would be so that every user can make that same assumption too

Lloyd McKenzie (May 05 2020 at 22:50):

When sending an extension, there's generally an expectation to populate as many core elements as possible as accurately possible as some eventual receivers of the instance likely won't recognize the extension.

Spencer Evans (May 08 2020 at 17:36):

denormalizing and doing 2-way syncing to any edits made b/t the fields on Patient.contact and the RelatedPerson seems like a pretty big overhead to maintain. I also see it leading to unintended consequences. eg, what should happen if someone edits the name on Patient.contact.name field, should that be understood as changing who the contact is referring to, or fixing a typo on the person's name?

I don't love my solution but I think I'm going to fall back to one of:

just put the extension on Patient itself (not Patient.contact)
add a value to Patient.contact.organization to fulfill the constraint with: { display: "unknown" } then continue with the extension on Patient.contact as originally planned.

I think option 1 is definitely preferable since the organization could be very confusing to others later, but I wanted to throw it out there as an option too.

Lloyd McKenzie (May 08 2020 at 17:57):

If your interest is in maintaining consistent demograhics, you're probably looking at Person - which can link to Patient, RelatedPerson, and can be pointed to by Patient.contact. But you're absolutely expected to maintain the values in multiple places. You can propagate them automatically from Person, but you can't expect systems to follow links to find demographics.