I agree with Ian, more so because this can of procedures may vary around countries, while the medical concepts described in the archetypes are more generally applicable.
Jan Talmon > On 17 nov. 2014, at 05:30, Ian McNicoll <Ian.McNicoll at > oceaninformatics.com> wrote: > > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
