Hi William, I don't really agree with your suggested approach. The specific requirement is to be able to formally sign or counter-sign the entire document, possibly for reasons of medico-legal responsibility as Dipak has described, or because specific requests or orders must have senior sign-off. The majority of documents will have no attestations but the potential need is universal, whilst orthogonal to the type of document or content. This makes it entirely sensible to handle at RM level.
Attestation is quite different from the ideas of evidence, use of guidelines etc that you seem to be talking about. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 15 November 2014 06:14, WILLIAM R4C <wgoossen at results4care.nl> wrote: > Hi Pablo, Thomas, > > The attestation knowledge getting lost except perhaps in Dipak and Sam's > minds is more often occurring in clinical models. > > In the ISO technical specification for detailed clinical models there is an > option to include such specific information in one of the clinical fields as > evidence base, instruction or interpretation. Best used it it is a clinical > mind required. > Or in traceability to other standards if a specific guideline or protocol is > used, or issues if it is a Modelling construct deployed in a specific way. > > In your case I would complete some instruction how to handle the junior - > senior clinical situation and to define how that must be expressed in ADL > model in the issue field. > > Of course such issue field would need to become part of ADL. Probably version > 2.2? > > Vriendelijke groet, > > Dr. William Goossen > > Directeur Results 4 Care BV > +31654614458 > >> Op 15 nov. 2014 om 07:04 heeft openehr-technical-request at >> lists.openehr.org het volgende geschreven: >> >> Send openEHR-technical mailing list submissions to >> openehr-technical at lists.openehr.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> or, via email, send a message with subject or body 'help' to >> openehr-technical-request at lists.openehr.org >> >> You can reach the person managing the list at >> openehr-technical-owner at lists.openehr.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of openEHR-technical digest..." >> >> >> Today's Topics: >> >> 1. ORIGINAL_VERSION.attestations is needed in the IM? (pablo pazos) >> 2. Re: ORIGINAL_VERSION.attestations is needed in the IM? >> (Thomas Beale) >> 3. RE: Postulate: DV_QUANTITY should be modelled with fewest >> possible units (Heather Leslie) >> 4. Re: ORIGINAL_VERSION.attestations is needed in the IM? >> (Kalra, Dipak) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 14 Nov 2014 16:09:16 -0300 >> From: pablo pazos <pazospablo at hotmail.com> >> To: openeh technical <openehr-technical at lists.openehr.org> >> Subject: ORIGINAL_VERSION.attestations is needed in the IM? >> Message-ID: <SNT151-W97F76A167D953EF12DACCC88C0 at phx.gbl> >> Content-Type: text/plain; charset="windows-1252" >> >> 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: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141114/cc2496fe/attachment-0001.html> >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 14 Nov 2014 20:14:50 +0000 >> From: Thomas Beale <thomas.beale at oceaninformatics.com> >> To: openehr-technical at lists.openehr.org >> Subject: Re: ORIGINAL_VERSION.attestations is needed in the IM? >> Message-ID: <546662BA.8000405 at oceaninformatics.com> >> Content-Type: text/plain; charset="windows-1252"; Format="flowed" >> >> >> 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 >> <http://www.openehr.org/issues/issues/?jql=project%20%3D%20SPECPR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC>, >> 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: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141114/9a7651d4/attachment-0001.html> >> >> ------------------------------ >> >> Message: 3 >> Date: Sat, 15 Nov 2014 05:03:29 +0000 >> From: Heather Leslie <heather.leslie at oceaninformatics.com> >> To: For openEHR technical discussions >> <openehr-technical at lists.openehr.org> >> Subject: RE: Postulate: DV_QUANTITY should be modelled with fewest >> possible units >> Message-ID: >> <de5380b9c07f405faf552f21cc5a0a62 at >> SIXPR06MB094.apcprd06.prod.outlook.com> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Bj?rn, Thomas >> >> You could potentially create a template for each archetype with this unit >> issue, if you like, and govern it in the Norwegian CKM. That artefact can >> then be published as the 'approved' Norwegian version of the international >> archetype. >> >> Templates of a single archetype are effectively a profile. We use this in >> Ocean's implementations where we want consistent archetype constraints used >> across multiple document templates. >> >> Templates can then be used in other templates and these Norwegian-specific >> constraints could be used consistently across templates within a single >> clinical system and also across multiple clinical systems. >> >> The only remaining issue would be to indicate that the template is the >> preferred modelling artefact - not sure how we do that other than >> notification in CKM. It would not be apparent to modellers deep in the >> tools, and predominantly working with archetypes. Not sure how we could do >> that... :( >> >> Regards >> >> Heater >> >> From: openEHR-technical [mailto:openehr-technical-bounces at >> lists.openehr.org] On Behalf Of Thomas Beale >> Sent: Friday, 14 November 2014 8:04 PM >> To: openehr-technical at lists.openehr.org >> Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible >> units >> >> On 14/11/2014 08:42, Bj?rn N?ss wrote: >> I have been thinking about profiling. I am not sure if this fix the problem >> regarding complexity. >> This may be an governance thing. If we define a metric and british imperial >> profile we may define that in Norway every application MUST use the metric >> profile and other countries may select "british imperial". This could make >> it easier to set up validation on entries. >> >> Is this a usage you were thinking about? >> >> >> exactly. It requires defining the profiles in the archetypes as per my last >> post. I can see that it could work for units, not sure about other things. >> If such profiles were defined, it would then be possible to make a template >> tool remove elements you don't want when creating templates. This would be >> done by the normal means e.g. >> >> path/to/imperial/quantity occurrences matches {0} >> >> but it would be done for you, and noone would have to go looking for them. >> >> - thomas >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141115/f79f18ab/attachment-0001.html> >> >> ------------------------------ >> >> Message: 4 >> Date: Sat, 15 Nov 2014 06:04:24 +0000 >> From: "Kalra, Dipak" <d.kalra at ucl.ac.uk> >> To: For openEHR technical discussions >> <openehr-technical at lists.openehr.org> >> Subject: Re: ORIGINAL_VERSION.attestations is needed in the IM? >> Message-ID: <F8856553-BCAE-4807-ADD9-A491C8B734CA at ucl.ac.uk> >> Content-Type: text/plain; charset="windows-1252" >> >> 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 <thomas.beale at >> oceaninformatics.com<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<http://www.openehr.org/issues/issues/?jql=project%20%3D%20SPECPR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC>, >> 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<mailto: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: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141115/c4795a94/attachment.html> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> ------------------------------ >> >> End of openEHR-technical Digest, Vol 33, Issue 23 >> ************************************************* > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
