Hi Thomas, I'm not convinced as yet that this is a universally useful requirement, particularly as we carry much of this source/ provenance metadata already.
@Silje - are the GPs expected to add this extra information to every Entry in the summary? That seems like a significant burden, and actually in many cases unknowable. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 17 January 2017 at 12:34, Thomas Beale <[email protected]> wrote: > > Ideally there would be one or more classifiers at the ENTRY level, > something that does not exist today. There are some others that we will > include, e.g. relating to epistemic_status. > > I would follow Ian's suggestion on the extension slot; it may be that the > coding recorded there may need to be adjusted to a new place in relevant > archetypes later on. Not ideal, but not a big problem either, assuming they > are not used to create data before that is done. > > Ian - do we have a related PR mooted for RM Release-1.0.4? > > - thomas > > On 17/01/2017 11:22, Bakke, Silje Ljosland wrote: > > Thank you Thomas and Ian! > > > > This is indeed a national requirement, and one where we do need to > represent the chosen value in a coded text element. The background here is > an entry in the critical information part of the national summary record, > ie an adverse reaction, complication from anaesthesia, critical condition, > ongoing treatment, implant, change of treatment routine, or infection. Each > of these will be either an EVALUATION.adverse_reaction_risk, > EVALUATION.problem_diagnosis, or EVALUATION.precaution. The patient’s GP > normally records the information, and this code set is supposed to be used > to specify where the GP got the information about each of the entries from. > > > > Regards, > *Silje* > > > > *From:* openEHR-technical [mailto:openehr-technical- > [email protected] <[email protected]>] *On > Behalf Of *Ian McNicoll > *Sent:* Tuesday, January 17, 2017 11:36 AM > *To:* For openEHR technical discussions <openehr-technical@lists. > openehr.org> <[email protected]> > *Subject:* Re: Use of RM:provider > > > > Hi Silje, > > > > I would agree with your and Thomas's assessment. This codeset does not > really fit with provider, or indeed with any other RM attributes, although > many but not all of these items could be calculated/ derived from existing > attributes. > > > > I guess this is part of a national requirement, and is a similar issue to > the one we faced in Sweden, where the V-TIM standard was largely aligned > with openEHR but had some extra specific metadata around Contsys-2 that > needed to be captured. > > > > This was exactly the purpose for the Extension slot that we are adding to > new archetypes, so that would be my suggestion. Having said that, I do > wonder about the purpose of this data -where is the value, over and above > what is already captured by native openEHR RM. This feels like largely a > derived set of data for reporting purposes > > e,g, > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
