Dear Jan, I am referring to the generic knowledge for procedures. Not to the local variations, the latter must be handled in the system according the reference model. Let's stop the mails on it, I think it is clear to all what the options are.
Vriendelijke groet, Dr. William Goossen Directeur Results 4 Care BV +31654614458 > Op 17 nov. 2014 om 13:08 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. Re: openEHR-technical Digest, Vol 33, Issue 24 (Talmon (CRISP)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 17 Nov 2014 13:08:02 +0100 > From: "Talmon (CRISP)" <talmon at maastrichtuniversity.nl> > To: For openEHR technical discussions > <openehr-technical at lists.openehr.org> > Subject: Re: openEHR-technical Digest, Vol 33, Issue 24 > Message-ID: > <A9D745E1-69D3-4A88-8414-318BA3BB5FC1 at maastrichtuniversity.nl> > Content-Type: text/plain; charset="us-ascii" > > 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 > > > > > ------------------------------ > > 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 29 > *************************************************
