Stream: Da Vinci CDex
Topic: Signatures and technical approach questions
Eric Haas (Mar 18 2021 at 19:47):
Regarding signatures on task based queries...
Technical approach:
| Question | Binary Documents ( eg PDFs) | FHIR Documents | Search Bundles | Individual Resources (including Collection Bundles) |
|---|---|---|---|---|
| What type in Task.output.valueReference | DocumentReference | Bundle or DocumentReference? | Bundle | Any |
| Where is Signature? | on Document itself ( e.g. signed PDF) | on Document bundle | ??? | ??? |
| Where is Guidance on how to do it? | NA | CCDA on FHIR | CDEX | CDEX |
Options for FHIR Resources outside FHIR Documents:
- Put sig on Task
- Attestation Provenance pointing to Task and reference in Task.output.valueReference
- Attestation Provenance pointing to individual Resources and reference in Task.output.valueReference
Questions:
- What about multiple sigs for single task request. how to keep track of which sig for what output?
- What about consistency across all types of data requests and output? ( e.g sig on task only if a search Bundle or individual resource otherwise look at the output itself)
Eric Haas (Mar 18 2021 at 19:49):
@Lloyd McKenzie , @Robert Dieterle ?
Lloyd McKenzie (Mar 18 2021 at 20:31):
There's three types of attestation possible:
- "this document is accurate" (which would be intrinsic to the document, either as a wet signature in a scanned PDF, a signature in a CDA or a Bundle signature for a FHIR document). I don't think either HRex or CDex needs to say anything about that other than "payers may expect signatures to be present on certain documents before they'll accept them". This type of signature is only relevant on documents. It won't generally exist on any other records.
- "this arbitrary resource was created by x" or "this arbitrary resource is accurate" is covered by Provenance.signature. (I'm not sure which of the two is what it actually does.) I'm not clear if we need either of these.
- "this information I'm returning is the complete answer to your question" - I suspect this is what's really wanted. And if we're going to have it, it'll need to be on Task - either as an extension or an output. Note that one signature would apply to the complete set of outputs (be they documents or other resources)
Eric Haas (Mar 19 2021 at 01:47):
My impression when listening to Bob and to the guy representing a payer on the Wednesday 1PM Call was that it more like 2. I don't think it is a matter of completeness but more vouching on the veracity of the data. We already talk about it needing to come from the source to and not some HIE to get the assurance that someone cannot deny the validity of something (Non-repudiation) So I assume that in this context, there is also need to ensure that a party to a communication must accept the responsibility for its accuracy. Will need to get find out exactly what.
Lloyd McKenzie (Mar 19 2021 at 01:56):
There are going to be challenges with that. Someone who updates a Patient phone number (most recent author of the Patient instance) isn't necessarily vouching for all of the patient's contact information. Someone who discharges a patient isn't necessarily vouching or the admission diagnosis. To get the true set of "who vouches for what", you'd need the Provenances for all actions and all updates. This isn't the same where someone compiles a document, reviews it and says "I believe all of this is accurate".
Eric Haas (Mar 19 2021 at 02:29):
someone compiles a document, reviews it and says "I believe all of this is accurate".
this is what I mean
Eric Haas (Mar 19 2021 at 02:30):
we just need to figure out what the Payer means
Lloyd McKenzie (Mar 19 2021 at 02:38):
Right - that doesn't happen for individual resources with Provenance. If we want to represent "I have reviewed all of these conditions and deem them accurate", I think we need something more than just the Provenance associated with each Condition. Agree we need to understand exactly what sort of a declaration the payers want - and what sort of declarations providers and EHRs believe Provenances actually represent.
Eric Haas (Mar 19 2021 at 02:45):
Then how this translate to a signature on a task ( if we go that route) looking at http://hl7.org/fhir/ValueSet/signature-type
or a Provenance of type ? + signature + target...
Lloyd McKenzie (Mar 19 2021 at 02:56):
If we decide that whatever attestation needed best appears on Task (which I suspect is likely), it would either be an output or an extension
John Moehrke (Mar 19 2021 at 11:45):
There are signature alternatives to cover these intentions. I will first express that they are very difficult to work, and expensive to support. So I will state right now that everyone wants signatures until they realize just how expensive and difficult they are.
John Moehrke (Mar 19 2021 at 11:49):
What they really want is a statement that I John have reviewed the things that a Duck is responsible for reviewing and am good with the values. This is less of a signature, and more of an 'initial here'. These can be implemented with cryptographic signatures (digital signatures), or can be done with electronic signatures (aka marks). Both can be done with Provenance, one has a digital signature.
John Moehrke (Mar 19 2021 at 11:51):
Note that Provenance.signature can also be a non-digital signature, it can be anything, including a scanned ink signature. It can even just be a type, when, and who. (I john signed this today because I reviewed it)
John Moehrke (Mar 19 2021 at 11:56):
now the expensive and difficult... the project could define a subset of elements that are defined for "I reviewed this CDex task for what clinicians reviewed". This would subset the elements in task that a "clinician" would be expected by policy to review. It could do this with XML-Signature ability to do partial signatures; or it could create an intermediate FHIR object or bundle that holds only those elements and signs that.
do this for all the partial signatures (initials here) use-cases that you have.
John Moehrke (Mar 19 2021 at 11:57):
now the part that is infinitely expensive and difficult... all of the digital signatures ultimately get shelfed because you must have a comprehensive certificate management system that is designed to last the life span of any one signature with comprehensive support for revocation... and provable timestamps.
John Moehrke (Mar 19 2021 at 12:00):
I suspect you just want a Provenance without a .signature element. A Provenance that lists generally the objects reviewed (Provenance.target), a set of URI for the various kinds of partial signatures to put into .policy.
John Moehrke (Mar 19 2021 at 12:02):
true non-repudiation is a great idea, it is a great theory, it can be done. But the expense tends to be more costly than the thing being protected.
John Moehrke (Mar 19 2021 at 12:06):
of course... there is also blockchain... I have described above everything you need. just take the "now the expensive..." and place that temporary blob onto the blockchain. Now you just need to get everyone who would sign something to have a recognized blockchain identity. Likely that blockchain would need to be both permissioned and private. Which is indistinguishable from a database jointly owned by the private collective.
Lloyd McKenzie (Mar 19 2021 at 13:31):
I don't think we're talking about digital signatures here, though we want to allow them for those who choose to bother with them. I'm hoping no-one is seriously thinking about blockchain. We're just wanting formal attestation. However, we do need to know exactly what's being attested to - and it's not clear how that's defined in Provenance.signature.
Last updated: Apr 12 2022 at 19:14 UTC
