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:[email protected]] *On Behalf Of
*Ian McNicoll
*Sent:* Tuesday, January 17, 2017 11:36 AM
*To:* For openEHR technical discussions
<[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
