Stream: implementers
Topic: Tagging a Patient
Bob Milius (Sep 13 2017 at 21:39):
We have the need to tag a Patient as a "donor" or as a "recipient." This is in the context of a hematopoietic stem cell transpant (eg bone marrow, peripheral blood stem cells). How would we do this? (edited typo)
Michel Rutten (Sep 13 2017 at 21:41):
You could define an extension.
Joel Schneider (Sep 13 2017 at 21:43):
Meta.tag may be another option
https://www.hl7.org/fhir/resource-definitions.html#Meta.tag
Grahame Grieve (Sep 13 2017 at 21:43):
@Brian Postlethwaite this sounds like a PA issue to me. Have PS discussed it?
Michel Rutten (Sep 13 2017 at 21:44):
https://www.hl7.org/fhir/resource-definitions.html#Meta.tag
"Tags are intended to be used to identify and relate resources to process and workflow, and applications are not required to consider the tags when interpreting the meaning of a resource."
Joel Schneider (Sep 13 2017 at 21:46):
Consent or Provenance might also be useful in relation to the (potential) donor recruitment process
Lloyd McKenzie (Sep 13 2017 at 21:49):
A given patient could be both a donor and a recipient - and might end up being both multiple times over their lifetime. So this doesn't sound like a characteristic of Patient, but rather a characteristic of their relationship to the planned procedure. - so perhaps an extension on ProcedureRequest.subject?
Bob Milius (Sep 13 2017 at 21:52):
yes, Lloyd, good catch. This is not uncommon, so as you say it's a description of the relationship between the two patients and the transplant material itself (where it came from and who received it)
Bob Milius (Sep 13 2017 at 21:54):
We also have to identify Potential Donors, eg. those who have been typed and are entered in a donor registry, but not yet (if ever) donated
Lloyd McKenzie (Sep 14 2017 at 03:33):
So for those that have donated, you'd have an explant procedure on one patient, an inplant procedure on the other and the linkage would be the common product. What would be the need to tag the patient themselves?
Lloyd McKenzie (Sep 14 2017 at 03:34):
In terms of those on a donor registry, you could have a List for each type of registry
Brian Postlethwaite (Sep 14 2017 at 03:53):
I don't recall this specifically being discussed at PA, but a flag indicating is an organ donor I think does makes sense.
The details of it that have given, or recieved a donation I agree does not belong on here.
Lloyd McKenzie (Sep 14 2017 at 04:51):
There's a difference between "Patient has donated an organ" (e.g. kidney) vs. "Patient is willing to donate their organs upon death". Agree an indicator makes sense in the latter case.
John Moehrke (Sep 18 2017 at 14:34):
The CBCC committee has been asked to support this on Consent. Is that not true anymore? I have been in ongoing discussions in another stream https://chat.fhir.org/#narrow/stream/implementers/subject/Organ.20Donor.20Registry.20records
Grahame Grieve (Sep 18 2017 at 21:10):
there's a clear difference between recording an actual consent, and flagging on the patient record that such a consent exists. In practice, existing electronic records are more likely to do the second, and delegate the 1st to an external ad-hoc system (paper, or email)
John Moehrke (Sep 19 2017 at 00:36):
Agreed. I would not be against simple flags on the Patient. I just wanted to point out the need for a more complete model in Consent resouce; rather than creating any complex extensions in Patient. I am just bringing up the topic, and reaching out for support and eagerness to have experts help CBCC (us).
Joel Schneider (Sep 20 2017 at 03:50):
Some comments/background on the hematopoietic stem cell transplantation (HSCT) story ...
A need to tag (or flag) the Patient as a "recipient" would arise if, for example, the initial search for a donor with a matching tissue type fails and the Patient's search for a matching donor needs to continue. Additionally, the privacy and confidentiality constraints applicable to a "recipient" differ from those for a donor (e.g. organizational affiliations ...).
Using a FHIR List to represent the HSCT donor registry (which has over 10 million members) seems impractical. Additional FHIR operations for working with a large List might help, but it seems the use case would still eventually require custom SOA operations. For example, the full use case would involve a "match result" data structure (or resource?) containing a comparison of the (mostly HLA) tissue types of a recipient and donor.
Side note: Patients who are candidates for HSCT generally have conditions which disqualify them from acting as a HSCT donor.
To me, it feels like parts of the HSCT story may be of general interest, but other parts may fall into extension territory.
Last updated: Apr 12 2022 at 19:14 UTC
