Hi William, I can see the value of what you are proposing but I am not sure that I would carry this kind of knowledge in the archetype. It feels to me more like 'guidelines' knowledge in terms of Alan Rector's diagram.
Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 17 November 2014 06:57, William Goossen <wgoossen at results4care.nl> wrote: > Response to message: Message: 3 > Date: Sat, 15 Nov 2014 09:56:40 +0000 > From: Ian McNicoll <ian at mcmi.co.uk> > To: For openEHR technical discussions > <openehr-technical at lists.openehr.org> > Subject: Re: openEHR-technical Digest, Vol 33, Issue 23 > Message-ID: > <CAG-n1KxpBCjo7eeO+cAn2fpsuQhsdPH9dcTJ6ayh6s1DdOr1fQ at > mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > Dear Ian, > > I would like to differentiate between the attestation as a procedure in the > EHR record, where role 1 enters data and role 2 verifies data. Of course > that should be handled as you say to formally sign and countersign for the > legal requirements. > > But how would one know which procedure must be countersigned and which not? > Such knowledge should in my opinion be part of the archetype describing the > procedure / legal requirement or such, or it should be handled at the higher > level of template or composition level if a procedure has several sub > activities, parts etc. > > So the signing is with author, date, time, location, subject in the EHR. > > The "when to countersign" needs to be part of the medical knowledge as > expressed in the archetype. > From the archetype the EHR can then flag the countersign issue and have the > workflow supported such that only after signature 2 the procedure is run. > It might be that current archetypes have no node or other expression for > this countersigning process, but the knowledge part to tell a user "this > procedure must be countersigned according to hospital protocol XYZ123" can > be expressed in any archetype. > > > vriendelijke groet, > > dr. William T.F. Goossen > > directeur Results 4 Care B.V. > De Stinse 15 > 3823 VM Amersfoort > the Netherlands > telefoon +31654614458 > e-mail: wgoossen at results4care.nl > DCMHelpdesk at results4care.eu > skype: williamgoossenmobiel > kamer van koophandel 32133713 > http://www.zorgictwinkel.nl/ > http://www.results4care.nl > http://results4care.wikispaces.com/ > http://r4c.clinicaltemplates.org > http://www.linkedin.com/company/711047 > > > > -----Oorspronkelijk bericht----- > Van: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] > Namens openehr-technical-request at lists.openehr.org > Verzonden: zaterdag 15 november 2014 10:57 > Aan: openehr-technical at lists.openehr.org > Onderwerp: openEHR-technical Digest, Vol 33, Issue 24 > > 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.or > g > > 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. Re: openEHR-technical Digest, Vol 33, Issue 23 (WILLIAM R4C) > 2. Re: Postulate: DV_QUANTITY should be modelled with fewest > possible units (Ian McNicoll) > 3. Re: openEHR-technical Digest, Vol 33, Issue 23 (Ian McNicoll) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 15 Nov 2014 07:14:05 +0100 > From: WILLIAM R4C <wgoossen at results4care.nl> > To: "openehr-technical at lists.openehr.org" > <openehr-technical at lists.openehr.org> > Subject: Re: openEHR-technical Digest, Vol 33, Issue 23 > Message-ID: <84494DA2-58DF-4967-ACF6-D91646FD87C5 at results4care.nl> > Content-Type: text/plain; charset=us-ascii > > 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.open >> ehr.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.or >> g/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%20AN >> D%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.or >> g/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.c >> om> >> >> 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.or >> g/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.ope >> nehr.org> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open >> ehr.org >> >> -------------- next part -------------- An HTML attachment was >> scrubbed... >> URL: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.or >> g/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.open >> ehr.org >> >> ------------------------------ >> >> End of openEHR-technical Digest, Vol 33, Issue 23 >> ************************************************* > > > > ------------------------------ > > Message: 2 > Date: Sat, 15 Nov 2014 09:42:33 +0000 > From: Ian McNicoll <ian at mcmi.co.uk> > 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: > <CAG-n1KykNrNZC1w2RU_0z3vCkawgK47oG1RNxvfeR4XbzxHGTw at > mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Heather, > > I agree with that approach. I would actually regard this as a kind > specialised archetype, just using template technology. > > One of the advantages of moving to ADL1.5/2.0 is that it is is possible to > do this kind of profiling as a specialised archetype not just within a > template. In fact templates and archetypes are technically identical. > > You do raise an interesting point about how/if we flag that the parent > archetype itself should not normally be used. > > 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 05:03, Heather Leslie > <heather.leslie at oceaninformatics.com> wrote: >> 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? L >> >> >> >> 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 >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open >> ehr.org > > > > ------------------------------ > > Message: 3 > Date: Sat, 15 Nov 2014 09:56:40 +0000 > From: Ian McNicoll <ian at mcmi.co.uk> > To: For openEHR technical discussions > <openehr-technical at lists.openehr.org> > Subject: Re: openEHR-technical Digest, Vol 33, Issue 23 > Message-ID: > <CAG-n1KxpBCjo7eeO+cAn2fpsuQhsdPH9dcTJ6ayh6s1DdOr1fQ at > mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 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.ope >>> nehr.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.o >>> rg/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%20A >>> ND%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.o >>> rg/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.o >>> rg/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.op >>> enehr.org> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.ope >>> nehr.org >>> >>> -------------- next part -------------- An HTML attachment was >>> scrubbed... >>> URL: >>> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.o >>> rg/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.ope >>> nehr.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.open >> ehr.org > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or > g > > ------------------------------ > > End of openEHR-technical Digest, Vol 33, Issue 24 > ************************************************* > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
