-clini...@lists.openehr.org) <openehr-clini...@lists.openehr.org>
Subject: RE: Mandatory elements in archetypes, and user interfaces
In general I think it is correct to have some mandatory elements in many
archetypes. These are elements which defines the archetype. I.e. problem
element in Problem/Di
hr.org] On Behalf Of Bakke,
Silje Ljosland
Sent: fredag 10. november 2017 11:48
To: openehr-implementers@lists.openehr.org; For openEHR clinical discussions
(openehr-clini...@lists.openehr.org) <openehr-clini...@lists.openehr.org>
Subject: Mandatory elements in archetypes, and user inter
Hi,
You are right; I agree with you.
But …
Archetypes (most times) have to be very forgiving with constraints.
Archetypes are used to build Templates.
These are created for a specific purpose in a specific circumstance.
Templates are used to specify interfaces and then most constraints have to
Hi, there are several cases:
1. data recorded by the software: when a data element is added to the
composition by the software, doesn't need a UI element at all
2. recording null flavour: if no data is entered on the UI field (field is
not mandatory on UI), null_flavour is recorded on the
On 10 Nov 2017, at 15:03, GF > wrote:
Why isn’t it a good idea?
Perhaps it's just a matter of taste, but it makes no sense to me to have
something stored into container Diagnosis and then not have an actual diagnosis
code in it.
Same for temperature, blood
Why isn’t it a good idea?
Give an example, svp.
Gerard Freriks
+31 620347088
gf...@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
> On 10 Nov 2017, at 14:21, Boštjan Lah wrote:
>
>
>
>> On 10 Nov 2017, at 14:19, Thomas Beale
On 10/11/2017 11:21, Boštjan Lah wrote:
On 10 Nov 2017, at 14:19, Thomas Beale wrote:
you can't restrict from 1..1 => 0..* in a template - it's not allowed in any
restriction algebra, of which ADL is an example.
If it is thought that no occurrnces constraint might
Hi Silje,
On 10/11/2017 08:47, Bakke, Silje Ljosland wrote:
Crossposting this between the clinical and implementers lists, since
it belongs in both:
In some archetypes, one or more elements are set as mandatory
(typically occurrences 1..1 or 1..*), because the rest of the concept
makes no
> On 10 Nov 2017, at 14:19, Thomas Beale wrote:
>
>
>
> On 10/11/2017 10:24, GF wrote:
>> Hi,
>>
>> Even when elements make no sense when both are recorded, even then 1..1 is a
>> problem in Archetypes.
>> It is up to the implementer to decide to restrict 0..n
On 10/11/2017 10:24, GF wrote:
Hi,
Even when elements make no sense when both are recorded, even then
1..1 is a problem in Archetypes.
It is up to the implementer to decide to restrict 0..n further in the
Template.
you can't restrict from 1..1 => 0..* in a template - it's not allowed in
Hi,
Even when elements make no sense when both are recorded, even then 1..1 is a
problem in Archetypes.
It is up to the implementer to decide to restrict 0..n further in the Template.
I suggest to make archetype as generic as possible and use almost always 0..n
Implementers are exposed to
discussions
(openehr-clini...@lists.openehr.org<mailto:openehr-clini...@lists.openehr.org>)"
<openehr-clini...@lists.openehr.org<mailto:openehr-clini...@lists.openehr.org>>
Subject: Mandatory elements in archetypes, and user interfaces
Crossposting this between the clinical
ehr.org>
Date: Friday, 10 November 2017 at 11:47
To: "openehr-implementers@lists.openehr.org"
<openehr-implementers@lists.openehr.org>, "For openEHR clinical discussions
(openehr-clini...@lists.openehr.org)" <openehr-clini...@lists.openehr.org>
Subject: Mandato
Crossposting this between the clinical and implementers lists, since it belongs
in both:
In some archetypes, one or more elements are set as mandatory (typically
occurrences 1..1 or 1..*), because the rest of the concept makes no sense
without this particular element recorded. Examples are
14 matches
Mail list logo