On 30-09-16 10:46, GF wrote:
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,
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
On 29/09/2016 13:31, GF wrote:
Each entry in the classification needs:
- a screen representation (‘+++')
- a description (‘moderate')
in theory these two come from DV_ORDINAL.symbol, which is a
DV_CODED_TEXT. That assumes a text value of '+++' and either a
description or synonym (or both)
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')
I agree that they do not fit in a Data Type.
It had better be handled using archetypes.
It is too complex for a DV_Ordinal Data Type
The reason why I wrote what I wrote is that Archetype must do more than the
bare essentials.
Leaving more to the implicit knowledge of humans or value sets stored
5 matches
Mail list logo
