Partial attestation

https://specifications.openehr.org/releases/RM/latest/ehr.html#_composition_class
“A Composition is… … the unit of attestation by authorising clinicians”

Architecturally it makes sense to attest the entire composition. But in my experience as a resident, a senior clinician often ‘attests’ (by speech) only part of the data in a composition. E.g. when I would examine an abdomen and the surgeon agreed there is a palpable mass. This does not mean the surgeon attests the blood pressure I took as well, even though it would be recorded in the same composition.
Since I worked on a non openEHR EMR, I would record something like:
“RR: 120/80mmHg
(Dr. Marsh) Abd: palpable mass

I don’t think we should force or imply attestation off the blood pressure by the senior clinician as well. So I feel the specs are too limited compared to clinical practise.

There’s no urgent usecase for us, but I wanted to mention this since otherwise the specs are exceptionally well in sync with (my) clinical practise.

We have that already :slight_smile: Every Entry has a ‘provider’ attribute for that purpose . it is optional and is assumed to be the same person as the composer if absent.

https://specifications.openehr.org/releases/RM/latest/ehr.html#_entry_class

There also is a Attestation feature on commts if the whole composition needs to be signed off by a senior colleague.

https://specifications.openehr.org/releases/RM/latest/common.html#_attestation_class

1 Like

The actual model makes attestation optional (here is the relevant part of the model), and as Ian said, the ‘provider’ attribute on each Clinical Statement (= ENTRY & subtypes like OBSERVATION, etc) allows the identity of the actor providing that information to be recorded on each statement.

1 Like

Happy to hear this has been considered:) I do feel using provider is mostly good enough for practical usage.(8t’s also what my example note above implies, for efficiency purposes).

But I do think there is a subtle difference between attesting and providing information: if the composer does the abdominal exam he is the provider if the surgeon witnesses the exam he can attest the abdominal exam, but he is not the provider.

Isn’t the items attribute in the attestation class what I’m looking for?
“*
Items attested, expressed as fully qualified runtime paths to the items in question. Although not recommended, these may include fine-grained items which have been attested in some other system. Otherwise it is assumed to be for the entire VERSION with which it is associated.”*
Also on the same page: “Normally the list of items being attested should be a single Entry or Composition, but there is nothing stopping it including fine-grained items, even though separate attestation of such items does not appear to be commensurate with good clinical information design or process.”
So I’m now fully at ease again with the technical design possibilities of the RM.

I guess my issue is mostly with the description of the composition class:
A Composition is considered the unit of modification of the record, the unit of transmission in record Extracts, and the unit of attestation by authorising clinicians.”
Re unit of modification: Is a correction to or addition of information in a single element in a previously created composition not a modification itself?
Rephrasing “unit of modification” to “unit of addition” or “unit of information recording” feels better.

Re unit of transmission: I expect often information will be transferred in way smaller chunks than a composition. E.g. a gp to nurse phone call: “what was the latest blood pressure?” “120/80”. Also with regards to GDL and patient proxy, if my systems wants to know the latest BP for a chadvasc your system has, I’ll query and transfer only that latest (interpretation off) BP, not the entire composition it’s part off. Maybe a case could be made that one should process the entire composition to properly interpret the single BP. But that’s not the way things are done in the real world.

Re unit of attestation: I think this sentence is inconsistent with the attestation class (description).

This was written I think nearly 15y ago; so we might need to review the requirements again in any case. We could also potentially change this text to read e.g. ‘… and the default unit of attestation by authorising clinicians’.

1 Like

That explains it. The “default unit of attestation” would be a small change that would have prevented my confusion:D

@joostholslag - this would be another good documentation fix to add to the CR for that purpose for the next RM release (just add a new comment with a reminder of what to fix, from this discussion).

1 Like

Done, thanks for pointing me to the right way to address this:) it’s nice to be able to contribute, however small it is:)