Stream: implementers
Topic: Involuntary commitment/ forced treatment
Øyvind Aassve (Aug 12 2019 at 13:23):
Hi,
we have a need for documenting involuntary commitments/ forced treatments (Involuntary commitment or civil commitment - also known informally as sectioning or being sectioned in some jurisdictions, such as the United Kingdom - is a legal process through which an individual who is deemed by a qualified agent to have symptoms of severe mental disorder is ordered by a court into treatment in a psychiatric hospital (inpatient) or in the community (outpatient). )
Is information on these kind of decisions within scope of FHIR?
Cheers,
øyvind
John Moehrke (Aug 12 2019 at 13:45):
I don't think that Provenance is your solution, but Provenance can record much of the reason behind why a resource was created or updated. Thus it might be useful to bind actions to cause. However I am unclear that this is what you were asking about.
Øyvind Aassve (Aug 13 2019 at 06:56):
Hi John, the question was maybe not so clear - most of it was a copy-pasted definition of the concept from Wikipedia :). To clarify - the question is what clinical (or maybe adminstrative?) resource is the most fit to describe the fact that a patient is hospitalized/ treated (normally for mental conditions) against the patients own will. So there is some kind of decision that overrides the patients normal rights to deny treatment. How can we represent these facts in FHIR?
Josh Mandel (Aug 13 2019 at 12:46):
have you looked at the Encounter resource? This might be the right level of which to document these kinds of facts. You might think about using a specific encounter type or class.
Øyvind Aassve (Aug 13 2019 at 14:57):
Hi Josh, that could be an option. A consequence of this is that the decision then is bound to the Encounter. And normally this will be linked to some kind of encounter/intervention. If so - what kind of information could be profiled/extended to express the (legal) decision that is the background for the encounter and the subsequent procedures. I was thinking that this (legal) decision maybe could be referenced on its own - as an independent entitity in order to communicate in all necessary setting that this patient now is under involuntary commitments/ forced treatment ....
John Moehrke (Aug 13 2019 at 15:26):
I don't think there would be a specific Resource type for this. I would expect that this is an exception case, and thus paper explaination would be used. Where that paper is captured in a DocumetReference. This DocumentReference could be referenced where ever it is needed to add emphasis. I don't think there is a LOINC defined document code for this, so possibly a locally defined code for the DocumentReference.type
John Moehrke (Aug 13 2019 at 15:27):
Possibly a use of Consent that is got a Consent.performer that is the legal authority that is committing against the wishes. But even this would likely defer to Consent.sourceReference as the DocumentReference I mention above.
John Moehrke (Aug 13 2019 at 15:29):
would be best to see how this use-case is done in paper world today. Guessing without that background is dangerous. Doing use-case analysis given that paper world is a good
David Pyke (Aug 13 2019 at 15:38):
The Consent resource with a use case of treatment would be a good start. Having the court order (or other document) attahced as Consent.sourceReference (or any other Consent.source) would be a good start.
Jose Costa Teixeira (Aug 13 2019 at 17:20):
The Consent resource with a use case of treatment would be a good start. Having the court order (or other document) attahced as Consent.sourceReference (or any other Consent.source) would be a good start.
@David Pyke isn't that using consent to something other than a consumer’s choice?
David Pyke (Aug 13 2019 at 17:21):
In the case of court ordered treatment, consumer choice isn't the issue. Consent has been "given" on their behalf via court order.
Jose Costa Teixeira (Aug 13 2019 at 17:21):
I think we need something to express permission. Consent is the consumer choice, so perhaps we need something else.
Jose Costa Teixeira (Aug 13 2019 at 17:23):
(I just took the Consent resource description, which states consumer choice)
Øyvind Aassve (Aug 13 2019 at 20:24):
I think I am struggelig togheter with Jose with what i perceive as a break with the fundamental semantics of the Consent resource (ref - A healthcare consumer's choices to permit or deny recipients or roles to perform actions for specific purposes and periods of time). This is more or less the complete opposite - the healtcare consumer is stripped for all rights to choose. Maybe we can introduce a negation on the resource ;). DocumentReference.type is maybe a possibility - if there is no way to reference these semantics more directly? I could not find any SCT-codes for the two terms used in the stream-header either, but I expect this is a quite universal thing - and very important to document properly
David Pyke (Aug 13 2019 at 21:16):
This is the first time the use case has been brought forward. And while the description is about patient choice, when the patient is unable to choose (or a court chooses for them) we need to document that "consent". A code added to the consent-category may be the first step in addressing this. We meet at 2pm ET on Thursday (I know that may be late for you). That would be the best time to discuss this case
Jose Costa Teixeira (Aug 14 2019 at 01:44):
Maybe we can introduce a negation on the resource ;).
I really don't think we should do that.
Jose Costa Teixeira (Aug 14 2019 at 01:48):
I would gove one step back - why are we even looking at Consent resource?
Jose Costa Teixeira (Aug 14 2019 at 01:51):
The use case is: how do we document that the patient is there against their will, forced by a court?
This is not security, this could more easily be encounter.class.
Øyvind Aassve (Aug 14 2019 at 10:30):
Thanks for the invitation David, I will do my best to be there.
Cheers
Øyvind Aassve (Aug 14 2019 at 10:37):
@David Pyke
Community-Based Care and Privacy (CBCP) ?
David Pyke (Aug 14 2019 at 12:34):
Yes, that' s us
Øyvind Aassve (Aug 14 2019 at 13:01):
:+1:
John Moehrke (Aug 14 2019 at 14:06):
Maybe we can introduce a negation on the resource ;).
I really don't think we should do that.
We do have negation in the Consent resource. Each rule is either a PERMIT or a DENY rule.
Further we do not constrain the policy upon which the Consent is built.
John Moehrke (Aug 14 2019 at 14:09):
No question "Consent" is an overloaded term... What we have (and intend to support) is a resource that holds both consents and dissents, rules associated with a subject/patient for access to ... "PatientRules" seems equally obscure...
John Moehrke (Aug 14 2019 at 14:17):
or should we go back to a profile on Contract? We left Contract because it has overloaded term and because it is a very complex resource intended to cover a much broader space.
Jose Costa Teixeira (Aug 14 2019 at 14:59):
Well, if the encounter is involuntary, that would be in the encounter resource
Jose Costa Teixeira (Aug 14 2019 at 14:59):
That is the starting point, right?
Jose Costa Teixeira (Aug 14 2019 at 15:00):
Then we see where to put the legal justification
Jose Costa Teixeira (Aug 14 2019 at 15:02):
I proposed a different model that seems more linear, based on the notion of permission, of which an expression of consent can be an evidence.
Jose Costa Teixeira (Aug 14 2019 at 15:03):
I think some people would surely model this as an observation ... :) I would make our resource boundaries are clear. I do not see why consent came into this picture. Seemed a long stretch
Jose Costa Teixeira (Aug 14 2019 at 15:13):
If we keep adding stuff to the Consent resource, when is the time to evaluate the core concept? I pointed that the definition of the resource already seems to misalign with this case. We can update the definition, but that seems we are redefining the consent notion, not only adjusting the text.
Jose Costa Teixeira (Aug 14 2019 at 15:14):
Last week, @John Moehrke asked me to read the definition. That was clear but something was missing.
Now if the consent can also be used for court mandates it is no longer clear because that is not what it says in the box.
Jose Costa Teixeira (Aug 14 2019 at 15:14):
I think it is not the word that is overloaded, it is the concept that does not have a stable boundary.
Jose Costa Teixeira (Aug 14 2019 at 15:16):
also, keep in mind that for a latin brain, Consent means Agreement.
John Moehrke (Aug 14 2019 at 15:46):
also, keep in mind that for a latin brain, Consent means Agreement.
yes it is a problem. but there is not really a better word.. permission is also a positive word and wouldn't be understood as holding denials.
John Moehrke (Aug 14 2019 at 15:46):
I have been dealing with this going back to IHE-BPPC profile.
Jose Costa Teixeira (Aug 14 2019 at 18:30):
Yes, but permission is also not what I would use in this case. I did not want to force "permission" as a solution, I just think consent is not a clear solution for this use case
Jose Costa Teixeira (Aug 14 2019 at 18:31):
Sorry I can't be more constructive than saying "this could be a class of encounter, and we need to find a way to convene the mandate for that. It could be an extension
Jose Costa Teixeira (Aug 14 2019 at 18:34):
Or we can use an Episode of are which honestly sounds much more adequate semantically, and we could use something like .referralrequest instead of Consent. Point is that consent seems inadequate
Jose Costa Teixeira (Aug 14 2019 at 18:38):
(and on this thread I want to go back to the question and say we should have a better solution than stretching consent to fit the need
Grahame Grieve (Aug 15 2019 at 02:33):
I think in this case, the root concept is spread across multiple resources - a Contract for the underlying paperwork/directives, a flag on the Encounter/CareEpisode. And the consent that works as per usual, but the author of the consent is not the patient, it's the court
John Moehrke (Aug 15 2019 at 15:37):
The modeling question is if the part within Consent today that defines various PERMIT/DENY permissions, could be exteralized so that it could be used in Contract more naturally or in a more general "business" policy way. The concept of a permission is an abstraction used throughout privacy, security, and business process. Thus it is potentially something that is standalone.
The then question is if this need is specific to FHIR, or we should just use other standards such as XACML. The benefit of defining it in FHIR is that we can leverage the FHIR constructs and more naturally call out common FHIR vocabulary. The drawback is that one must convert this FHIR permission structure to another permission standard, such as XACML, in order to use a permission decision/enforcement engine.
Note that IHE, for XDS/XCA, defined a mapping of XDS metadata and such, into XACML vocabulary --- this is what the IHE APPC profile is all about.
Lloyd McKenzie (Aug 20 2019 at 21:37):
Encounter represents a particular stay. A given patient could be shuffled amongst multiple institutions all based on one court order - so Encounter is definitely not the ideal way to represent an involuntary commitment order. I look at Consent as a record of permission - permission might well be granted by the patient themselves, their representative or the state. And that might be part of the story here. I.e. "The state is giving permission for this to occur on the patient's behalf" - just as a mother might give permission for a child to be immunized (over the child's vocal objections). However, the actual order for treatment should be captured as a ServiceRequest - the same as an order/referral for psychiatric assessment/treatment would be represented in cases where the patient was fully on-board. In summary, my recommendation:
- ServiceRequest (to indicate what sort of therapy is being ordered - and by whom) + Consent (to indicate that consent has been explicitly given by the state on patient's behalf, and potentially overriding the patient's express wishes).
Last updated: Apr 12 2022 at 19:14 UTC
