Stream: implementers
Topic: ProcedureRequest & Consent
nicola (RIO/SS) (Jul 05 2018 at 09:53):
How to model relation between specific Procedure/ProcedureRequest and Patient Consent?
Grahame Grieve (Jul 05 2018 at 12:05):
are you talking about consent to operate?
nicola (RIO/SS) (Jul 05 2018 at 12:42):
Yes
Lloyd McKenzie (Jul 05 2018 at 13:38):
@David Pyke ?
John Moehrke (Jul 05 2018 at 13:44):
We have not yet gotten much engagement with those that have the domain knowledge on 'consent to operate'. Thus this is NOT today included in the model. Please bring your use-case to the committee for analysis and inclusion in updates of the Consent resource.
Lloyd McKenzie (Jul 05 2018 at 13:53):
It's a modifier. You append it to the name of an existing criteria
John Moehrke (Jul 05 2018 at 13:58):
Nope... the Consent.scope element has a clear definition to differentiate the various areas of consent, with a vocabulary "treatment" readily available for the use-case. What we lack is a understanding on how to use the rest of the elements in Consent for that use-case. It is possible that Consent.provision.type=permit (allow this to happen - yuck, don't like this), and Consent.provision.actor is the doctor or team authorized to do this, and Consent.provision.data references that procedure that is being authorized to be done..... BUT, This is more of a hack of what is there, not because it was designed to do that.
John Moehrke (Jul 05 2018 at 13:59):
so, no need for isModifier... it is part of the definition
John Moehrke (Jul 05 2018 at 14:00):
AH, @Lloyd McKenzie I think your comment was on a different stream ":text vs _text"???
Lloyd McKenzie (Jul 05 2018 at 14:09):
Yes. Sorry. Fixed :)
nicola (RIO/SS) (Jul 05 2018 at 14:13):
In our case we need to link Consent to specific Chemotherapy Procedure Request.
nicola (RIO/SS) (Jul 05 2018 at 14:14):
I think, this is common case to get consent to do some procedure.
Lloyd McKenzie (Jul 05 2018 at 14:15):
Procedure consents are very common. It's absolutely something that needs to be supported. We just haven't had people coming to the table asking for them or willing to get involved in the development yet. Feel free to get the party started...
John Moehrke (Jul 05 2018 at 14:16):
@nicola, How about Consent.scope element of "treatment" readily available for the use-case. . It is possible that Consent.provision.type=permit (allow this to happen - yuck, don't like this), and Consent.provision.actor is the doctor or team authorized to do this, and Consent.provision.data references that procedure that is being authorized to be done.....
John Moehrke (Jul 05 2018 at 14:17):
the commitee members are willing.. just simply don't have the domain knowledge... so as I have said, and Lloyd has emphasized... .please get engaged with the CBCP and help develop this. Even putting your use-case into a CR would be a major benefit.
nicola (RIO/SS) (Jul 05 2018 at 14:30):
I'm thinking about who is a source of reference and who is a target. Let's consider simple use case: Physician recommends some procedure for patient, asks for consent and create order / procedure request, later procedure is completed and documented. We can have references from ProcedureRequest and Procedure to Consent or Consent can refer ProcedureRequest, which later will be referred by Procedure. Do we have some rule of thumb to decide on reference direction?
John Moehrke (Jul 05 2018 at 14:37):
I am not sure we are both on the same use-case.... Are you speaking of a "consent to treat", which is an authorization from the patient to carry out some specific treatment.... Or are you speaking about a "privacy consent", which is an authorization to allow some/all data be used for some purpose? Or are you trying to do both in the same 'consent'? Don't try to combine then into one.
nicola (RIO/SS) (Jul 05 2018 at 14:39):
First - consent to treat
John Moehrke (Jul 05 2018 at 14:47):
Okay. I would think the Consent would point at the procedure that it is authorizing. The consent-to-treat would need to point at the procedure it is authorizing. I don't think the procedure would have any need to point at the consent. right?
nicola (RIO/SS) (Jul 05 2018 at 14:49):
May be - but consent can be taken before Procedure instance is created?
John Moehrke (Jul 05 2018 at 14:50):
right... I am noticing that... So, seems when it comes to scheduled actions, ServiceRequest or CarePlan, are the thing that the consent-to-treat is authorizing?
John Moehrke (Jul 05 2018 at 14:50):
see.... not subject matter expert.... :-)
John Moehrke (Jul 05 2018 at 14:51):
or a Procedure.code = preparation
John Moehrke (Jul 05 2018 at 14:52):
Would EpisodeOfCare or Encounter be logical too?
nicola (RIO/SS) (Jul 05 2018 at 14:55):
Patient gives Consent to Provider to do some procedure/treatment, which at that moment is abstract and can be represented as code in .action element. But it would be useful to link this Consent to instances of ServiceRequests/Procedures - so we can see this relationship from data.
John Moehrke (Jul 05 2018 at 14:57):
so the use-case is that they are authorizing the procedure by some vocabulary value?
nicola (RIO/SS) (Jul 05 2018 at 14:58):
Yes. And we need to track this Consent from Order/Request
John Moehrke (Jul 05 2018 at 14:58):
Im not sure I understand what the value of linking them post-hoc? They are linked by 'time'. I guess you could revise the Consent, but that might not be the right procedural thing, as it would then look like 'revisionist history', might break any digital signature...
John Moehrke (Jul 05 2018 at 15:00):
Long shot.... you could use a Provenance to link the future created Procedure, as being in fulfillment of the Consent-to-treat... yuck
nicola (RIO/SS) (Jul 05 2018 at 15:00):
By regulations practitioner has to ask for consent for specific procedure before order it. But later when somebody will inspect procedures, potentially he will be interested in consent
John Moehrke (Jul 05 2018 at 15:01):
right, today this is done by looking based on TIME and the procedure code... If I find a consent-to-treat in the right timeframe, and it has the same procedure code... then it must have been the one to authorize that procedure... right?
nicola (RIO/SS) (Jul 05 2018 at 15:02):
Yes
John Moehrke (Jul 05 2018 at 15:02):
counter... if this is really strict, then one would be in an environment where a ServiceRequest or CarePlan always exists... else no Procedures (beyond emergency) are allowed.
John Moehrke (Jul 05 2018 at 15:02):
and if you have a ServiceRequest or a CarePlan... those instances are the ones that the Consent-to-treat points at.
John Moehrke (Jul 05 2018 at 15:03):
so the only hole is an environment that wants to have strict consent-to-treat, but doesn't want to have ServiceRequest or CarePlan... right?
John Moehrke (Jul 05 2018 at 15:04):
emergency exceptions happen...
John Moehrke (Jul 05 2018 at 15:05):
this seems like a reasonable and realistic model... right?
nicola (RIO/SS) (Jul 05 2018 at 15:08):
Your proposal is to refer ServiceRequest/CarePlan from Consent.data element, is it?
John Moehrke (Jul 05 2018 at 15:13):
Yes. Consent.scope=treatment, Consent.provision.data points at either a ServiceRequst, CarePlan, or Procedure (in preparation status)
John Moehrke (Jul 05 2018 at 15:17):
Note that there is a mandatory Consent.category.... which I think in when the consent is a consent-to-treat would contain the procedure code.... BUT this is the kind of modeling that needs input from the community.
nicola (RIO/SS) (Jul 05 2018 at 15:20):
Thank you, think this works for us
John Moehrke (Jul 05 2018 at 15:24):
note: .source could still point at the text that the patient actually saw... policy might have some value, but likely empty. policyRule very likely empty. verification might be used when the patient themselve can't approve.... Let me know how it works out... best case, give me an example we can put into the spec.
nicola (RIO/SS) (Jul 05 2018 at 18:12):
Yes, i will create an example, when we finish this module!
Grahame Grieve (Jul 05 2018 at 19:15):
@nicola (RIO/SS) note this, from the Consent scope:
Grahame Grieve (Jul 05 2018 at 19:15):
There are four anticipated uses for the Consent Resource, all of which are written or verbal agreements by a healthcare consumer [grantor] or a personal representative, made to an authorized entity [grantee] concerning authorized or restricted actions with any limitations on purpose of use, and handling instructions to which the authorized entity must comply:
- Privacy Consent Directive: Agreement to collect, access, use or disclose (share)* information.
- Medical Treatment Consent Directive: Consent to undergo a specific treatment (or record of refusal to consent).
- Research Consent Directive: Consent to participate in research protocol and information sharing required.
- Advance Care Directives: Consent to instructions for potentially needed medical treatment (e.g. DNR).
This resource is scoped to cover all four uses, but at this time, only the privacy use case is modeled. The scope of the resource may change when the other possible scopes are investigated, tested, or profiled.
Last updated: Apr 12 2022 at 19:14 UTC
