Stream: implementers
Topic: Patient Contact
Lauren Wolejsza (Apr 14 2017 at 20:32):
Hello! We are using Patient.Contact elements to store multiple contacts such as providers, insurance, personal, etc. However, the Contact object does provide a UniqueID for each Contact generated in the array object. This of course causes serious problems when doing CRUD operations. Is there a plan to either add an identifier of some kind for each Contact within Patient resource or consider separating Contacts into its own resource that can be referenced to Patient? I do not see any change in the structure between DSTU2 and STU3 thus we are getting very creative (aka development hack) in identifying a Contact within Patient when there is more than one. Insights appreciated! Thanks, Lauren
Lloyd McKenzie (Apr 15 2017 at 06:11):
It's not an issue for CRUD in FHIR because when you do a U, you're updating the entire patient record - so you're replacing one snapshot of all the patient's contacts with another. You *can* put an id element on each one if you wanted to manipulate them using an operation or something.
Grahame Grieve (Apr 15 2017 at 21:19):
id *attribute* in XML.
Grahame Grieve (Apr 15 2017 at 21:19):
can you clarify what the problems are?
Lauren Wolejsza (Apr 20 2017 at 13:51):
Good Morning!
Our concern is the fact that you are doing an update to the entire Patient record for one of many contacts. Does this make sense given a Patient could have a large number of contacts and the Patient record is critical for all other resources as a reference? Is there any concern of data corruption, etc.? Granted, you could use RelatedPerson to handle contacts where each contact would be its own record, however, based on the description this appears to be more for family members not healthcare, insurance, or other non-family member contacts. Also, yes there is _history for the resource record so you can see the previous version. However, it may make more sense to take something that is changing at a different rate than true Patient demographic information to separate these concepts.
Reminder: We are using a Mongo-based HAPI FHIR API to collect patient-generated health data from mobile applications. We are not connected to an EHR where the Patient records would be more likely managed by an administrator of the healthcare entity. Our mobile apps do not allow a patient to change their demographic information, however, we are allowing patients to enter their Contacts information which in turn touches their Patient record.
Our other concern is the ability to identify uniquely and update a given contact within the array of contacts in the Patient resource. There is no unique identifier available for a contact. We are attempting to create a unique ID by concatenating fields however this is not 100% full proof either.
It would be nice if Contacts was either its own resource with a reference back to the Patient resource or to make Contacts within the Patient resource more like Components in Observation where each component has a code to uniquely identify the entered value[x].
Hopefully this additional detail helps.
Thanks,
Lauren
John Moehrke (Apr 20 2017 at 13:56):
I agree.. It seems RelatedPerson does overlap Patient.contact... and would, as you nicely point out, better support CRUD operations. I would like to see Patient.contact removed, favoring RelatedPerson.
Lloyd McKenzie (Apr 20 2017 at 15:01):
RelatedPerson is intended for people who will "do" things - author data, perform services, attest to information. In general, a patient isn't likely to have more than 10 or so contacts - people listed as "next of kin", "emergency contact", etc. It's not to capture their family physician or pharmacy - that goes elsewhere.
David Hay (Apr 20 2017 at 17:52):
Perhaps that is where Patch might be an option for you? ( http://hl7.org/fhir/http.html#patch )
Grahame Grieve (Apr 20 2017 at 20:19):
regarding generating ids for contacts - if it was it's own resource, you'd have to come up with a primary key for it anyway. So why would it be easier to give it an id if it was a resource of it's own not an entry in another resource?
Lauren Wolejsza (Apr 21 2017 at 12:18):
@John Moehrke & @Lloyd McKenzie - Agree, RelatedPerson serves a different purpose but a resource like it for Contacts (business, insurance, or other personal) would be nice.
@David Hay - Thanks for the suggestion for Patch! I have shared this with our development team.
@Grahame Grieve - Sorry if I was unclear. We are suggesting a unique ID or additional codeable concept (in addition to relationship) for the contact within Patient.contact array. This would certainly help the CRUD operations to be more efficient rather than creating a key of concatenated fields to search for a given contact within the array. If the Contacts were its own resource, the ID would be handled per the structure of FHIR and ideally allow for a reference back to the Patient resource of course.
Our use case may be a bit more robust than an EHR where a Contact (per cited definition) is for anyone that can be contacted about the patient. In our case, we are attempting to store healthcare contacts (physicians, nurses, dentists, etc.) and organizations/clinics (pharmacy, hospital, lab, nursing home, etc.), insurance company contact info, and other personal contacts (family, friend, co-worker, lawyer, etc.) of interest to the patient.
Thanks again for the continued support as we continue to make the FHIR framework work with PGHD!
~Lauren
John Moehrke (Apr 21 2017 at 12:43):
@Lauren Wolejsza when I look at the definition of Patient.contact vs the scope and usage on the RelatedPerson Resource; they seem identical. RelatedPerson includes the examples you speak of. It is true the RelatedPerson can be used in more ways, but that should be expected of a Resource vs an element. In what way do you see RelatedPerson described that restricts you?
Lauren Wolejsza (Apr 21 2017 at 13:21):
@John Moehrke - Hi John! It may be that our approach is not the right one. When I think of a contact within the Patient resource, I think of someone who is the primary POC, next of kin, POA, or the individual(s) identified on a HIPAA form. Basically, the person who the doctor's office or hospital is going to call about a Patient's status. When I think of RelatedPerson resource, I think of anyone else beyond those in Patient.contact. Yes, the definitions for both do overlap hence some of the confusion.
I guess then the question is how can these 2 similar elements/resources be better defined to be clearer for those of us attempting to utilize FHIR.
Interested in your thoughts given our use case.
John Moehrke (Apr 21 2017 at 13:26):
My opinion... Patient.contact should be removed, thus it would be clear RelatedPerson would be the right solution. This would be easier to 'secure', and better support individual updates. As a privacy/security person, I prefer smaller --right sized-- resources. I don't have knowledge of arguments against this, except for the number of resources. That seems like a non-issue.
Lloyd McKenzie (Apr 21 2017 at 15:36):
RelatedPerson exists to be an actor - someone who can do things, the same as the Patient or any Practitioner. Recording the phone number of a patient's mother or power of attourney is a very different thing. I'm not a fan of squishing these two use-cases together - nor of imposing the complexity of requiring separate resources for someone who just wants to capture a patient's "next of kin"
John Moehrke (Apr 21 2017 at 15:43):
why not? In the old days there was storage space and network bandwidth issues.. I don't think they apply anymore. The benefit of more finegrain resources is my rational for my preference.
Lloyd McKenzie (Apr 21 2017 at 18:51):
Because sending one RESTful transaction is a whole lot easier than sending 20. Next of Kin typically aren't independently identified objects - at least not in v2.
Grahame Grieve (Apr 21 2017 at 20:29):
But you have a unique id... the id on the contact itself
Grahame Grieve (Apr 21 2017 at 20:30):
I don't know whether it's right for .contact to be in Patient or outside, but I do know that RelatedPerson and Patient.contact are not at all the same thing
John Moehrke (Apr 23 2017 at 15:39):
@Grahame Grieve The definitions and examples are the same thing between Patient.contact and RelatedPerson.... I don't see any distinction. It looks to me like it is just an architectural difference. What is your perceived difference that makes them "not at all the same thing"?
Lloyd McKenzie (Apr 23 2017 at 20:19):
RelatedPerson is essentially a "user" - someone who can take responsibility for actions. Patient.contact is just a bunch of names and phone numbers.
Lauren Wolejsza (Apr 24 2017 at 14:04):
@Grahame Grieve - Can you send me an example in JSON of a Patient.contact with a unique ID? I do not see any id elements associated with Patient.contact. The Patient ID is not unique to each contact. The only "id" so to speak would be the enumeration in the Patient.contact array and that is not truly full proof.
Lauren Wolejsza (Apr 24 2017 at 14:12):
@Lloyd McKenzie - Thank you for all the clarifications, however, the current specification definitions for these resources are not quite as distinct as you are describing. If the 2 places to store non-patient contact information, it would be helpful if these definitions were clearer. At this point, we are going to move forward using Patient.contact (DSTU2) and re-evaluate/recommend using RelatedPerson for future refactoring work (STU3) for this mobile application.
Lloyd McKenzie (Apr 24 2017 at 14:56):
@Lauren Wolejsza Your criticism is well-taken. Would you be willing to submit a change request to get this clarified in the next release? (Propose a change link at the bottom of each page in the spec.)
Grahame Grieve (Apr 24 2017 at 18:50):
{ "resourceType" : "Patient",
"contact" : {
"id" : "5228797b-b4a3-4723-aab2-b20e1cda6c8c",
"name" : {
....
}
}
}
Jayashree Surnar (Apr 25 2017 at 12:29):
hello all, in our ipad app, in on of the screen we are storing the patients's contact persones. for that we are using RelatedPerson. in related person we have the patient's reference. so that we can get the patient from RelatedPerson. but what we want is get/ search perticular patient's contact person. so how to get that please help.
thank you.
Lauren Wolejsza (Apr 25 2017 at 12:53):
@Grahame Grieve - Thanks for the code example. This would be for the Patient resource and not for each individual contact in the array. This is where an contact id would be helpful.
Lauren Wolejsza (Apr 25 2017 at 12:53):
@Lloyd McKenzie - Certainly.
Grahame Grieve (Apr 25 2017 at 21:03):
the id is on the contact not the patient resource
Lauren Wolejsza (Apr 27 2017 at 12:04):
@Grahame Grieve - Where did this "id" element come from? It is not cited in the specification anywhere? Is this meant as an extension? In other words, it is not obvious that an ID is created/available for each contact within the Patient array. Sorry if I am missing something here.
John Moehrke (Apr 27 2017 at 12:07):
Read about Resource, it is the template at the top of all resources... http://hl7.org/fhir/STU3/resource.html
Lloyd McKenzie (Apr 27 2017 at 13:06):
Resources have an inheritance hierarchy - most resources inherit from DomainResource and all inherit from Resource. These elements aren't shown to avoid clutter/redundancy. However, in STU3, there's also an explicit line that lists them. E.g. "Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension"
Richard Townley-O'Neill (Apr 27 2017 at 23:24):
contact does not inherit from Resource, contact is a BackboneElement and so gets id by inheritance from Element.
Same result, slightly different mechanism.
Lloyd McKenzie (Apr 27 2017 at 23:30):
Thanks for paying attention and actually answering the question asked @Richard Townley-O'Neill :smile:
Richard Townley-O'Neill (Apr 27 2017 at 23:32):
Thanks @Lloyd McKenzie for giving me the starting point to find it.
Last updated: Apr 12 2022 at 19:14 UTC
