The ERS system needs to be able to represent faithfully that what was shown on
a screen.
This is what the HcProvider signs off/attests.
See the requirements imposed on ERS systems in ISO 18308.
Therefor I’m of the opinion that the archetype used to store data in, and
retrieve data from, the database must be able to carry that screen info.
For Clinical Decision Support Systems this screen info is irrelevant.
For legal purposes it is essential.
HcProviders always will use their own local classifications. They never
uniformly will use one and the same, all the time.
These local classifications need to be mapped on a standardised internal
pattern/archetype for classifications. It is this pattern that is stored and
retrieved annex to the mapping to the local classification.
Gerard
> On 30 Sep 2016, at 10:06, Bert Verhees <bert.verh...@rosa.nl> wrote:
>
> On 29-09-16 14:31, GF wrote:
>> Each entry in the classification needs:
>> - a screen representation (‘+++')
>> - a description (‘moderate')
>> - an expression defining the inclusion criteria ('Lower Limit' < ‘Value' <
>> 'Higher limit'
>> - an expression defining the exclusion criteria ('no diagnosis of xyz')
>>
>> And perhaps each entry needs:
>> - Ranking number (‘1')
>> - Presentation ranking number (‘4')
>> - Associated value for calculation support (‘100')
>
>
> I don't think screen presentations should be something to consider in
> archetype-structures. A few weeks ago this was said to me on this list, and I
> think that is right. Screen presentation-definitions should be something to
> use in templates for screen presentation. There can also be templates for
> other purposes, messages, reports, etc.
>
> Archetypes, except for its original purpose: data-structure-representation,
> need to be purpose independent. Archetypes are the base to build templates
> on, and depending of the purpose of the template, the data will be
> represented in a different way.
>
> So archetypes need to be as much as possible machine-processable, and if you
> use all kind of convenient terms to, for example, indicate pain, then you
> will never be able to datamine (research in the history of a patient, or in a
> population) in a more generic way, and you will also need that specific
> archetype.
>
> Imagine a hospital with 7000 archetypes, it will become nearly impossible to
> find persons which have pain, what kind of pain and how severe it is.
>
> Better is to code pain, and I know SCT has good codes for pain (there may be
> other code-systems too). This makes machine processable searching for pain,
> kind of pain, severity of pain possible and will improve healthcare for a
> specific patient or a population.
>
> Bert
>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
