Stream: implementers
Topic: Power Of Attorney attribute
Akeem Leighton Foster Spencer (Feb 14 2018 at 16:07):
Hi,
I'm somewhat comfortable with the architecture behind the FHIR RestFUL exchange. I have a question regarding the related persons. Is there a way to designate the RelatedPerson as true being the power of attorney or do I need to make an extension for that resource to verify if the person has that status?
Lloyd McKenzie (Feb 14 2018 at 16:37):
@Brian Postlethwaite ?
Akeem Leighton Foster Spencer (Feb 14 2018 at 16:50):
How should FHIR define the power of attorneys A.K.A healthcare directives for a related person resource to a patient?
Akeem Leighton Foster Spencer (Feb 16 2018 at 13:50):
I see FHIR has a resource called "Consent", should this resource be referenced for validating whether a "Related Person" has access to receive information regarding the patient?
Please advise if anyone is experienced enough and has an understanding in HIPAA compliance when it comes to treatment and conditions occurring to patients
Andy Stechishin (Feb 16 2018 at 15:13):
I think you might want to look at Contract to record power of attorney
Lloyd McKenzie (Feb 16 2018 at 15:43):
Most systems don't actually transmit the full copy of the power of attorney - they just capture who has it.
John Moehrke (Feb 19 2018 at 14:21):
The Consent resource has included in scope the use-case where within a Consent a guardian is granted access, and where a guardian is the one approving a Consent. As Lloyd has indicated the use-case for recording the legal facts of the Guardians "Power of Attorney" contract is not typical for a Healthcare system , or the subject of healthcare communications. It is possible the Contract resource could be used. The Contract resource is there to hold various business contracts.
Jose Costa Teixeira (Feb 19 2018 at 14:22):
contract can be a possible solution for the "Design" (opposed to transactional) aspects of GDPR.
Jose Costa Teixeira (Feb 19 2018 at 14:24):
but it may require more analysis.
Jose Costa Teixeira (Feb 19 2018 at 14:25):
e.g. there is a difference between a list of contracts and the list of processing activities.
Abbie Watson (Feb 27 2018 at 23:18):
We're going to begin modeling this for OurCareWishes in the next month. The plan is to support both Contract and Consent. I'm planning to start with the following fields.
Contract.action.text = "Power of Attorney" Contract.agent.role.text = "Attorney" Contract.agent.actor(RelatedPerson) Contract.signer[0].signature.whoReference(Patient) Consent.sourceReference.reference(Contract)
Seems like the basic Power of Attorney is modeled by the Contract resource; and it has to be in place for the agent to provide Consent. So, start with Contract, then move onto Consent when that's in place.
John Moehrke (Feb 28 2018 at 13:21):
I would agree that a Contract is possibly first needed.... but that agreement is based on an unclear 'need' to have the details of the Power of Attorney in a FHIR formatted form. What I am saying is that I don't think that most would ever spend energy putting that very specifically legal kind of a document into a FHIR format. It would be a legal ceremony held outside of healthcare, as it is broader than just healthcare. Yes the healthcare world does need to be informed that there is a legal standing, but that can be done administratively without the need for FHIR encoding. So I am not saying anything against the use of Contract for this purpose, only that we should not look to duplicate all data in a FHIR format. I might indicate that the copy of the paperwork (really paper) be scanned and simply recorded as a DocumentReference-->Binary; with specific metadata to indicate what the contents are, and that they are not medically relevant, but are administratively and authorization relevant.
Lloyd McKenzie (Feb 28 2018 at 14:20):
When thinking about whether to use Contract, ask the question: "Is the FHIR representation the sole or primary legal representation of this legal instrument?". Then ask "Is there a more content-suitable resource that can satisfy the legal requirements?". If the answer to the first is "yes" and the answer to the second is "no", then you need Contract. Not everything with legal force necessarily needs to be represented with Contract, even if the legal instrument only exists in electronic FHIR form. And Contract isn't necessarily your only option.
Akeem Leighton Foster Spencer (Feb 28 2018 at 16:22):
@Lloyd McKenzie @John Moehrke Thank you, to Lloyd's post, for the possibility of question #1 answered "no" and question #2 being "no", this would mean the legal documents supporting disclosure of information must be verified and double checked by the administrator on his/her discretion? The notary public or the IRB who witnessed the parties agree to the settlements in the documents, is that primary entity the administrator needs validation from before sending information to the related persons?
I just want to understand the workflow when sending statuses to a RelatedPerson instance.
Lloyd McKenzie (Feb 28 2018 at 16:52):
If the business case is just knowing that "RelatedPerson has power of attorney", all you need is a flag. Someone looking at the resource would have as much (or as little) trust in the value of that flag as they have in the name, phone number or other information. Any of that might have been verified by someone (e.g. looking at a drivers license) or not. If knowledge of the verification is important, you can use Provenance to capture who did the verification and what the source information was, but in typical healthcare workflows, we don't bother with that level of overhead. It's sufficient to be able to go back and see who set the flag and if there's an issue, to contact them.
Igor Sirkovich (Mar 12 2018 at 16:34):
We had requested to add additional codes to http://hl7.org/fhir/ValueSet/relatedperson-relationshiptype in the past and in response the binding of RelatedPerson.relationship was relaxed from Required to Preferred. So, we were able to use some additional codes from http://hl7.org/fhir/v3/RoleCode, e.g. GUARD (guardian) and POWATT (power of attorney) in our implementation.
Paul Knapp (Mar 13 2018 at 05:37):
I wouldn't want to discourage the improved handling of this information though. As we move towards electronic contract conveyance, eg. signed pdfs and smart contracts, they aren't all going to be on paper, and further identification of these in your 'contracts file' will be more efficient administratively for some than dumping them into a predominantly clinical document repository.
Simon Knee (Jul 11 2018 at 09:57):
@Lloyd McKenzie Bit late to the party. We are also looking at how best to model the presence of LPoA (SNOMED codes) for a patient and who the attorney contacts are. Looking at the options discussed your flag proposal looks feasible. Would this include an extension that references the relatedPerson (contact) or is the suggestion that the provenance resource will carry the contact information? Can you expand on the proposal? Thanks
Lloyd McKenzie (Jul 11 2018 at 13:58):
There are two options. If the power of attorney relationship is the only one you care about (i.e. you don't care that the LPoA is the mother/father/daughter/whatever of the Patient), then just use the RelatedPerson.relationship element. If you need the personal relationship plus the fact this individual is the LPoA, then you'd use an extension to convey that they're a LPoA. Note that you only need to use RelatedPerson at all if you're expecting the person to be an actor in your system - authoring, reporting, receiving, etc. If you just need contact information, use Patient.contact.
Last updated: Apr 12 2022 at 19:14 UTC
