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, 1. Result of test/analysis We know that from the archetype name 2. Observed by treating physician Captured potentially by provider 3. Patient’s own information Party = Self 4. Information from next of kin Party = carer 5. Obtained from other records Can use Feed_audit but practically very difficult to manage. 6. Other 7. Reported by responsible clinician Captured by composer Can you tell us more about the background? Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 17 January 2017 at 10:14, Thomas Beale <thomas.be...@openehr.org> wrote: > Hi Silje, > > there is no immediate equivalent of these codes, which have indirect > equivalents, i.e. > > 1. Result = OBSERVATION; provider = lab; limited to certain > archetypes; also comes under SOAP 'O' Heading > 2. Observed by physician = OBSERVATION, provider = PARTY_IDENTIFIED > (physician); limited to certain archetypes; also comes under SOAP 'O' > Heading > 3. Patient information = OBSERVATION, with provider = PARTY_SELF, > possibly limited to specific archetypes ; also comes under SOAP 'S' heading > 4. Info from next of kin = OBSERVATION, with provider = > PARTY_IDENTIFIED (next of kin) > 5. Info from other records = any ENTRY, with FEEDER_AUDIT set > appropriately > 6. ?? > 7. Reported by responsible clinician could be 1, 2, most EVALUATIONs, > most/all INSTRUCTIONs some or many ACTIONs; provider = PARTY_IDENTIFIED > (clinician) > > I'd say it can be mostly set by using ENTRY.provider. 5 is a different > thing - it's about provenance of data obtained from elsewhere. Presumably 6 > means 'not any of 1-5 or 7'. > > I'd also say it isn't a very well designed code-set, and I don't know what > use it would be in real life... > > - thomas > > On 16/01/2017 13:14, Bakke, Silje Ljosland wrote: > > Hi everyone, > > > > I’ve got a problem about where to put non-identifying information about > the source of information for an ENTRY. The value set we need to store is > the code set identified by the OID 2.16.578.1.12.4.1.7498 (Source of > information), as following: > > > > 1. Result of test/analysis > > 2. Observed by treating physician > > 3. Patient’s own information > > 4. Information from next of kin > > 5. Obtained from other records > > 6. Other > > 7. Reported by responsible clinician > > > > Our first hypothesis was that the reference model element “provider” > should be used for this, but then someone pointed out that the “provider” > should be an identifiable person or entity, and not just a generalised > coded text like this. So, where should this information go, if not in > RM:provider? > > > > Kind regards, > *Silje Ljosland Bakke* > > > > Information Architect, RN > > Coordinator, National Editorial Board for Archetypes > Nasjonal IKT HF > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
