Re: Use of RM:provider
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
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, 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 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
RE: Use of RM:provider
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-boun...@lists.openehr.org] On Behalf Of Ian McNicoll Sent: Tuesday, January 17, 2017 11:36 AM To: For openEHR technical discussions 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, 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<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto: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 mailto: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
Re: Use of RM:provider
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-boun...@lists.openehr.org] *On Behalf Of *Ian McNicoll *Sent:* Tuesday, January 17, 2017 11:36 AM *To:* For openEHR technical discussions *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 openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Use of RM:provider
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: 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 12:34, Thomas Beale 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- > boun...@lists.openehr.org ] *On > Behalf Of *Ian McNicoll > *Sent:* Tuesday, January 17, 2017 11:36 AM > *To:* For openEHR technical discussions openehr.org> > *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 > 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
Re: Use of RM:provider
Hi Bjorn, Thanks - it makes much more sense in the context of Adverse reaction but TBH I still doubt very much if this 'provenance' source metadata is captured or known reliably. I asked a couple of UK GP colleagues and they agreed. I would argue that this data a) often not available b) unreliable c) a pain in the neck to manage and d) not something you ever want to do decision support on. If an allergy has been asserted, it needs to be regarded as positive and kick decision support into life, no matter how vague the provenance or potentially unreliable the witness. But hey, that's what the extension slot in the archetype is for :) 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 18 January 2017 at 10:24, Bjørn Næss wrote: > Hi > > The specified terminology ( OID 2.16.578.1.12.4.1.7498 (Source of > information) ) is defined as “*options to specify the source of data for > an allergic reaction*” (my translation). > > > > Which means this is specific for adverse reaction – and I think it should > be archetyped to model this requirement. If it is only national then there > should be some extension slots in the Archetypes – or we need some > specialization of the Archetype to handle this. > > > > Vennlig hilsen > Bjørn Næss > Produktansvarlig > DIPS ASA > > Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010> > > > > *Fra:* openEHR-technical [mailto:openehr-technical- > boun...@lists.openehr.org] *På vegne av* Ian McNicoll > *Sendt:* tirsdag 17. januar 2017 13.43 > *Til:* For openEHR technical discussions openehr.org> > *Emne:* Re: Use of RM:provider > > > > 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 <07752%20097859> > office +44 (0)1536 414994 <01536%20414994> > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > > > [image: > https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] > > 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 12:34, Thomas Beale > 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- > boun...@lists.openehr.org ] *On > Behalf Of *Ian McNicoll > *Sent:* Tuesday, January 17, 2017 11:36 AM > *To:* For openEHR technical discussions openehr.org> > *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 a
RE: Use of RM:provider
Hi Bjørn and Ian! The original use case for this code set was adverse reactions, but with the development of the national summary records, it’s been expanded for use with other kinds of critical information as specified below. This means that it needs to be used across the adverse reaction risk, problem/diagnosis and precaution archetypes, and I think therefore making a new cluster for use in the Extension slots is the best way to go forward. @Ian: Yes, this information is mandatory for each entry. They’re generally few and seldom changed, so I don’t think there’s too much overhead from this: [cid:image001.png@01D271A4.637D58A0] Regards, Silje From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Ian McNicoll Sent: Wednesday, January 18, 2017 12:33 PM To: For openEHR technical discussions Subject: Re: Use of RM:provider Hi Bjorn, Thanks - it makes much more sense in the context of Adverse reaction but TBH I still doubt very much if this 'provenance' source metadata is captured or known reliably. I asked a couple of UK GP colleagues and they agreed. I would argue that this data a) often not available b) unreliable c) a pain in the neck to manage and d) not something you ever want to do decision support on. If an allergy has been asserted, it needs to be regarded as positive and kick decision support into life, no matter how vague the provenance or potentially unreliable the witness. But hey, that's what the extension slot in the archetype is for :) Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org> Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 18 January 2017 at 10:24, Bjørn Næss mailto:b...@dips.no>> wrote: Hi The specified terminology ( OID 2.16.578.1.12.4.1.7498 (Source of information) ) is defined as “options to specify the source of data for an allergic reaction” (my translation). Which means this is specific for adverse reaction – and I think it should be archetyped to model this requirement. If it is only national then there should be some extension slots in the Archetypes – or we need some specialization of the Archetype to handle this. Vennlig hilsen Bjørn Næss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10 Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>] På vegne av Ian McNicoll Sendt: tirsdag 17. januar 2017 13.43 Til: For openEHR technical discussions mailto:openehr-technical@lists.openehr.org>> Emne: Re: Use of RM:provider 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: i...@freshehr.com<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org> Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 17 January 2017 at 12:34, Thomas Beale mailto:thomas.be...@openehr.org>> 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