Stream: patient empowerment
Topic: RelatedPerson vs. Practitioner - adding care givers
Dave deBronkart (Dec 18 2019 at 22:45):
Claudia Williams, former Obama White House advisor on health technology, has just published a concise and potent post about the human cost paid by family caregivers when a sick person's data cannot be aggregated (or even obtained) from hospitals. It's a good short read that provides a reminder on one reason the work we do here is important.
Addressing the Unfair Health Information Burden on Caregivers and Patients:
Restoring balance, equity, and trust between clinicians, caregivers, and patients in the year ahead
@Rien Wertheim we might consider a category (or at least a possible focus) on family caregivers in future Patient Innovator Track events.
@Grahame Grieve @Lloyd McKenzie @John Moehrke anyone, is "family caregiver" a well known use case in the community? It's certainly one where the need is often amplified, because the data-manager commonly is managing the patient's care in addition to the burdens of their own life.
John Moehrke (Dec 18 2019 at 22:48):
Yes FHIR supports that. It is a form of "RelatedPerson" http://build.fhir.org/relatedperson
Grahame Grieve (Dec 18 2019 at 22:56):
I usually bring this up when I speak about FHIR: the family care giver is the primary care giver, but they are not part of the system - insane
In the technical sense:
The care giver acting on behalf of the patient is both a Patient.contact, and also a RelatedPerson who acts on or on behalf of the patient. Our standard practice is that RelatedPerson should be able to do anything that a practitioner can do unless there are very specific reasons why not (one example: MedicationRequest.recorder).
But looking through the list (most convenient display is at build.fhir.org/patterns.html, search for Practitioner to see what a Practitioner con do that a RelatedPerson can't) makes it obvious to me that we aren't delivering on our own standard practice... it would be a good patient empowerment group to review the list of things we think a practitioner can do that a patient carer can't - good task for this stream here. Dave, want to have a go? (it'd be a good learning experience for you)
Dave deBronkart (Dec 18 2019 at 23:01):
@Grahame Grieve what I've seen so far of Confluence and HL7 protocols (e.g. how to decide something, yikes!) leaves me petrified about what I'm getting myself into if I say yes to anything around here :-), so I'll just say, you know me and my interests & constraints, so count me as interested and willing to do anything useful and viable.
I would quickly, though, punt the whole discussion to some unnamed far broader population of people who've actually been caregivers.
A fair number are involved in @S4PM - perhaps we could cross-pollenate a study group somewhere? @Abigail Watson is just now in the process of building friendship with the Chicago @S4PM community, which is led by Geri Baumblatt, who got into it while being caregiver for her mum.
Grahame Grieve (Dec 18 2019 at 23:01):
well, it will help if I just make the list, so here it is:
Grahame Grieve (Dec 18 2019 at 23:01):
references to Practitioner that don't include RelatedPerson:
- Account.subject
- BiologicallyDerivedProduct.collection.collector
- CatalogEntry.referencedItem
- Claim.careTeam.provider
- Claim.enterer
- Claim.provider
- ClaimResponse.addItem.provider
- ClaimResponse.requestor
- ClinicalImpression.performer
- Consent.verification.verifiedBy
- Contract.author
- Contract.contentDefinition.publisher
- CoverageEligibilityRequest.enterer
- CoverageEligibilityRequest.item.provider
- CoverageEligibilityRequest.provider
- CoverageEligibilityResponse.insurance.item.provider
- CoverageEligibilityResponse.requestor
- DetectedIssue.author
- DetectedIssue.mitigation.author
- DeviceRequest.requester
- DiagnosticReport.performer
- DiagnosticReport.resultsInterpreter
- DocumentManifest.subject
- DocumentReference.authenticator
- DocumentReference.subject
- EnrollmentRequest.provider
- EnrollmentResponse.requestProvider
- EpisodeOfCare.careManager
- ExplanationOfBenefit.addItem.provider
- ExplanationOfBenefit.careTeam.provider
- ExplanationOfBenefit.enterer
- ExplanationOfBenefit.provider
- Flag.author
- Flag.subject
- Group.member.entity
- ImagingStudy.interpreter
- ImagingStudy.referrer
- Immunization.performer.actor
- Linkage.author
- List.source
- MeasureReport.reporter
- MedicationDispense.substitution.responsibleParty
- MedicationRequest.recorder
- MessageHeader.author
- MessageHeader.destination.receiver
- MessageHeader.enterer
- MessageHeader.responsible
- MessageHeader.sender
- NutritionOrder.orderer
- ObservationDefinition.publisher
- Patient.generalPractitioner
- PaymentNotice.payee
- PaymentNotice.provider
- PaymentReconciliation.detail.payee
- PaymentReconciliation.detail.submitter
- PaymentReconciliation.requestor
- RequestGroup.author
- ResearchStudy.principalInvestigator
- RiskAssessment.performer
- Specimen.collection.collector
- SpecimenDefinition.publisher
- SupplyDelivery.receiver
- SupplyDelivery.supplier
- Topic.publisher
- VerificationResult.attestation.onBehalfOf
- VerificationResult.attestation.who
- VerificationResult.primarySource.who
- VisionPrescription.prescriber
Dave deBronkart (Dec 18 2019 at 23:03):
well, it will help if I just make the list, so here it is:
IBID! IBID! :-)
I punt any commitment to action on this until after Christmas and/or until my book is finished (a nasty confluence of constraints). So, sketch away, but so far I'm of no use in pursuing this.
Grahame Grieve (Dec 18 2019 at 23:05):
well, here's my list of the participations that should include RelatedPerson:
Grahame Grieve (Dec 18 2019 at 23:05):
- BiologicallyDerivedProduct.collection.collector
- ClinicalImpression.performer
- Consent.verification.verifiedBy
- DetectedIssue.author
- DetectedIssue.mitigation.author
- DeviceRequest.requester
- DiagnosticReport.performer
- DiagnosticReport.resultsInterpreter
- DocumentManifest.subject
- DocumentReference.subject
- Flag.author
- Flag.subject
- ImagingStudy.interpreter
- Immunization.performer.actor
- Linkage.author
- List.source
- MedicationDispense.substitution.responsibleParty
- MedicationRequest.recorder
- MessageHeader.author
- MessageHeader.destination.receiver
- MessageHeader.enterer
- MessageHeader.responsible
- MessageHeader.sender
- NutritionOrder.orderer
- RiskAssessment.performer ?
- Specimen.collection.collector
- SupplyDelivery.receiver
- VerificationResult.attestation.onBehalfOf
- VerificationResult.attestation.who
- VerificationResult.primarySource.who
Grahame Grieve (Dec 18 2019 at 23:05):
@John Moehrke discovered issue - why is DocumentManifest.subject different to DocumentReference.subject?
John Moehrke (Dec 18 2019 at 23:13):
because someone put in a CR on DocumentReference and didn't put in similar one on DocumentManifest.. Mostly because hardly anyone cares about DocumentManifest. Thus XDS being the only driver for DocumentManifest, it is happy with subject being only Patient
Grahame Grieve (Dec 18 2019 at 23:14):
should be the same, right?
John Moehrke (Dec 18 2019 at 23:16):
that depends, not all DoumentReference will need to be included in a DocumentManifest -- which is 100% true of the XDS use-case.
John Moehrke (Dec 18 2019 at 23:16):
but.. generally speaking, sure it seems reasonable that DocumentManifest should always be capable of carrying all flavors of DocumentReference
John Moehrke (Dec 18 2019 at 23:17):
That said... I am wondering if DocumentManifest should be merged with List and thus go away.
John Moehrke (Dec 18 2019 at 23:19):
to the RelatedPerson topic... is this another case where a pattern of agents should be driven more consistently? Because new Resources that are defined to have agency appear and not everyone (almost no-one) knows that this new agent type exists.
Grahame Grieve (Dec 18 2019 at 23:21):
we're working on that as a methodology issue, but that's not the issue here - RelatedPerson has been there from the start, and committees just aren't considering the use case in their design proces
Lloyd McKenzie (Dec 18 2019 at 23:25):
BiologicallyDerivedProduct.collection.collector - this is collecting blood, marrow, organs or other tissues for transplant (it's not about collecting stool, swabs or other things - those would be specimens). Pretty sure excluding RelatedPerson is reasonable there.
ClinicalImpression - maybe. It's still pretty loosy-goosy
Consent.verification - as defined, it seems like this needs to be someone acting on behalf of the organization
DetectedIssue stuff, DeviceRequest stuff, sure
DIagnosticReport - not familiar with DiagnosticReports ever being created by non-clinicians/professionals
DocumentManifest & DOcumentReference - would we have documents about a caregiver that are still in the context of their relationship to the patient?
Flag - sure
ImagingStudy.intepreter - seems a stretch, probably not core
Immunization - not familiar with situations where this can be done by a non-professional
Linkage, List - absolutely
MedicationDispense - RelatedPerson could ask, but the decision of whether it should happen or not would still be the professionals
MedicationRequest, sure
MessageHeader - don't know how much messaging stuff will involve care-givers, but I guess in theory
NutritionOrder - definitely
RiskAssessment - yes
SPeciment - yes
VerificationResult sure
Grahame Grieve (Dec 18 2019 at 23:27):
not familiar with DiagnosticReports ever being created by non-clinicians/professionals
not in the past, no. But welcome to the new world...
Grahame Grieve (Dec 18 2019 at 23:27):
would we have documents about a caregiver that are still in the context of their relationship to the patient?
yeah, I think that will happen, yes
Grahame Grieve (Dec 18 2019 at 23:28):
MedicationDispense - RelatedPerson could ask, but the decision of whether it should happen or not would still be the professionals
I think that depends on jurisdictional
Dave deBronkart (Dec 19 2019 at 03:25):
How's about one of us goes back upthread and renames most of this thing?
Grahame Grieve (Dec 19 2019 at 03:30):
kinda hard - have to go edit each post
Vassil Peytchev (Dec 19 2019 at 03:43):
kinda hard - have to go edit each post
I think you could do it at the top
Grahame Grieve (Dec 19 2019 at 03:45):
well.. it looked like it was going to let me do it once, so I cancelled to see if I had that option elsewhere, but now I can't do it anywhere except per message
Vassil Peytchev (Dec 19 2019 at 03:47):
When you edit a message in the thread (on he web interface), and edit the title only, you get another drop-down that lets you change the whole thread....
Lloyd McKenzie (Dec 19 2019 at 04:43):
I think it depends on how old the content is
Vassil Peytchev (Dec 19 2019 at 05:04):
I was able to do it 5 hours after the original post
Rien Wertheim (Dec 19 2019 at 07:30):
As for the Patient Innovator Track: it doesn't seem far fetched to include the family caregiver as a target audience. Just think of Kristina Sheridan. Let's put in on the list of things to discuss @Dave deBronkart
Bart Carlson (Dec 28 2019 at 03:54):
Their are numerous arguments for including Caregivers in the Patient Innovator Track. For example: 1) Every Parent is a Caregiver for some period of time to their Children; 2) Children are often times Caregivers for their aging parents; 3) Friends can be a Caregiver for another Friend; and 4) Home Nurses, Aids, and many other Professionals can also serve as Caregivers to the elderly.
Dave deBronkart (Dec 31 2019 at 04:25):
Can't believe I've been off-list since Friday - my bad!
My personal sense (which hasn't been officially nailed down and articulated ... hasn't been made normative?) is that the goal of the PIT is to demonstrate that people on the NEED side of the care transaction can have needs that they want served, which they may be ABLE to serve, with or without requiring involvement of the care system (the PROVIDER side of the transaction). These contributions, from the need side of the transaction, generate value as defined by the needy person, and are thus worthy of notice.
Examples from FHIR events in the past 15 months include Michael Morris, the Sheridans, Dana Lewis and the #OpenAPS crowd, BloodNumbers, and more ... not to mention all the people (@Debi Willis to name one) who've started companies out of their own experiences of needing care. But the PIT is explicitly not about corporations who decide to get into the business.
So CERTAINLY caregivers (people on the NEED side of the transaction) qualify. They also have the trait, generally, of needing efficiency, since they tend to do their caregiving in the middle of having a normal busy life. That heightens the need, which in turn increases the value of a useful solution.
Last updated: Apr 12 2022 at 19:14 UTC
