ORIGINAL_VERSION.attestations is needed in the IM?

[Kalra, Dipak]

Dear Pablo,

This function originated from the need to support countersignature. There are a 
number of clinical documents that need to be signed by more than one person, 
such as a consent form, the report of an operation, or the authorisation to 
detain a person in a mental healthcare institution. When evolving to a more 
electronic solution for capturing consent, and other situations where a legal 
record of care decisions or actions might need more than one signature, we felt 
we should provide for the possibility that a composition might need to be 
attested by more than one person.

With best wishes,

Dipak

Dipak Kalra
Clinical Professor of Health Informatics
Centre for Health Informatics and Multiprofessional Education
University College London

President, The EuroRec Institute
Honorary Consultant, The Whittington Hospital NHS Trust, London

On 14 Nov 2014, at 21:14, Thomas Beale mailto:thomas.beale at oceaninformatics.com>> wrote:


Hi Pablo,

yep, it's correct as it is - the model satisfies the use case where there can 
be more than on attestation. It was designed to deal with things like (from 
memory) a junior doc attesting, and later a more senior doc. These were 
clinical expert's requirements at the time, and someone like Dipak Kalra or Sam 
Heard would remember the exact situations it was designed for.

On the second one, could you please post a problem 
here,
 so we don't forget it.

thanks

- thomas


On 14/11/2014 19:09, pablo pazos wrote:
I'm reviewing the versioning aspects of the IM for a new course I'm giving, and 
I'm not understanding why we need more than one attestation per 
ORIGINAL_VERSION.

A composition shouldn't be signed by just one person?

Also, I found a bug:
6.2.5. Contributions (in common_im page 41)
attestation of item: a new ATTESTATION is added to the attestations list of an 
existing ORIGINAL_VERSION; the ATTESTATION.commit_audit.change_type is set to 
the code for ?attestation?.

Should be VERSION.commit_audit_change_type.


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 

ORIGINAL_VERSION.attestations is needed in the IM?

[Thomas Beale]

Hi Pablo,

yep, it's correct as it is - the model satisfies the use case where 
there can be more than on attestation. It was designed to deal with 
things like (from memory) a junior doc attesting, and later a more 
senior doc. These were clinical expert's requirements at the time, and 
someone like Dipak Kalra or Sam Heard would remember the exact 
situations it was designed for.

On the second one, could you please post a problem here 
,
 
so we don't forget it.

thanks

- thomas


On 14/11/2014 19:09, pablo pazos wrote:
> I'm reviewing the versioning aspects of the IM for a new course I'm 
> giving, and I'm not understanding _why we need more than one 
> attestation per ORIGINAL_VERSION_.
>
> A composition shouldn't be signed by just one person?
>
> Also, I found a bug:
> 6.2.5. Contributions (in common_im page 41)
> attestation of item: a new ATTESTATION is added to the attestations 
> list of an existing ORIGINAL_VERSION; 
> theATTESTATION.commit_audit.change_type is set to the code for 
> ?attestation?.
>
> Should be VERSION.commit_audit_change_type.


-- next part --
An HTML attachment was scrubbed...
URL: 

ORIGINAL_VERSION.attestations is needed in the IM?

[pablo pazos]

I'm reviewing the versioning aspects of the IM for a new course I'm giving, and 
I'm not understanding why we need more than one attestation per 
ORIGINAL_VERSION.

A composition shouldn't be signed by just one person?

Also, I found a bug:
6.2.5. Contributions (in common_im page 41)
attestation of item: a new ATTESTATION is added to the attestations list of an 
existing ORIGINAL_VERSION; the ATTESTATION.commit_audit.change_type is set to 
the code for ?attestation?.
Should be VERSION.commit_audit_change_type.

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com   
-- next part --
An HTML attachment was scrubbed...
URL: