Response to message: Message: 3 Date: Sat, 15 Nov 2014 09:56:40 +0000 From: Ian McNicoll <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 *************************************************
