Stream: Orders and Observation WG
Topic: Co-signing for orders
Bart Decuypere (Jan 19 2022 at 14:10):
I was wondering how to go about a situation in which a ServiceRequest needs to be signed by 2 or more parties before it can be executed. How would you model such a situation? The ServiceRequest should contain the practitioner(s) and their signature.
Jose Costa Teixeira (Jan 19 2022 at 14:19):
@Hans Buitendijk @John David Larkin Nolen ? Any guidance out there?
John Moehrke (Jan 19 2022 at 16:28):
the concepts of co-signatures and counter-signatures are supported in the general Signature datatype (type of signature).
Jose Costa Teixeira (Jan 19 2022 at 20:40):
IIRC the meaning is not to capture the signature itself, but the workflow of ordering and co-ordering, validating, signing...
Lloyd McKenzie (Jan 20 2022 at 02:20):
Requesting a signature would typically be a Task, and the signature itself would typically be captured with Provenance, though it could also be done with an extension.
Jose Costa Teixeira (Jan 20 2022 at 06:49):
We should bring it up to Workflow. in the ServiceRequest we may need to persist the signers/co-signers as References, and their roles. The rest is indeed tasks and capturing the events of signing
Jose Costa Teixeira (Jan 20 2022 at 06:51):
After yesterday's OO call, my current thinking is that the extension on ServiceRequest (and xxxRequest) could look like
* co-requester (0..*)
* role (1..1) Coding
* requester (1..1) Reference
John Moehrke (Jan 20 2022 at 12:31):
Provenance can support any number of co-signatures, counter-signatures, etc... and there is no need for an extension, it is native use-case for Provenance.
Eric Haas (Jan 20 2022 at 17:06):
@Jose Costa Teixeira what is OO's reluctance to use Provenance?
Jose Costa Teixeira (Jan 20 2022 at 17:06):
No reluctance.
Jose Costa Teixeira (Jan 20 2022 at 17:07):
There are 2 sides to this:
Jose Costa Teixeira (Jan 20 2022 at 17:07):
actually 3 sides:
Jose Costa Teixeira (Jan 20 2022 at 17:07):
- Indicate who co-ordered the service
Jose Costa Teixeira (Jan 20 2022 at 17:07):
- If needed get their signatures
Jose Costa Teixeira (Jan 20 2022 at 17:08):
- Manage the entire workflow for "who needs to sign-off next, is this actionable without sign-off"
Jose Costa Teixeira (Jan 20 2022 at 17:08):
The part that is interesting is 1
Jose Costa Teixeira (Jan 20 2022 at 17:08):
The other interesting part is 3.
Jose Costa Teixeira (Jan 20 2022 at 17:09):
part 2 could be interesting IF we need to capture the actual signatures
Jose Costa Teixeira (Jan 20 2022 at 17:09):
I think "co-signing" in this context is about "signing off / approving / athorizing"
Jose Costa Teixeira (Jan 20 2022 at 17:09):
For 1 and 3 there's no need for actual signatures
John Moehrke (Jan 20 2022 at 17:21):
I think you are confusing a "Digtial Signature" from all classes of Signature. The Signature datatype, that is used by Provenance, is a Signature. One can choose to implement that Signature with Digital Signature, or just elements holding codes.
Jose Costa Teixeira (Jan 20 2022 at 18:02):
I have no idea what this means.
Jose Costa Teixeira (Jan 20 2022 at 18:02):
Anyway
Jose Costa Teixeira (Jan 20 2022 at 18:03):
@Bart Decuypere I believe the extension is enough. The workflow thing can be a 2nd priority, i guess?
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Feb 02 2022 at 22:56):
There's also medical/legal requirements for a provider to sign off/request an order/Service Request, such as the CLIA requirements discussed on O&O.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Feb 24 2022 at 14:24):
In non FHIR implementations, the LIS can capture a primary verification of test results and a secondary verifier (two different user IDs), especially where required for CLIA. Assume most EHRs would be able to support a primary and secondary "signer" on an order requisition (i.e. resident and fellow/attending). It should be indicated who ultimately has medico-legal responsibility for the patient in case there are questions too.
The question has arisen about digital signatures for lab orders. The question is whether your use case supports EHR/electronic symptom capturing the "signature" via a valid/authorized User ID on the Service Request or are you trying to capture an actual digital signature, which may be a scanned paper/wet signature or capture of electronic pen or finger image/digital signature? Each are different data and would have different requirements in how they are transmitted.
Last updated: Apr 12 2022 at 19:14 UTC
