RE: Mandatory elements in archetypes, and user interfaces

-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

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/Diagnosis. We have implemented several strategies to cope with this: · First of all the container must be initialized to

Re: Mandatory elements in archetypes, and user interfaces

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

Re: Mandatory elements in archetypes, and user interfaces

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

Re: Mandatory elements in archetypes, and user interfaces

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

Re: Mandatory elements in archetypes, and user interfaces

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

Re: Mandatory elements in archetypes, and user interfaces

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

Re: Mandatory elements in archetypes, and user interfaces

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

Re: Mandatory elements in archetypes, and user interfaces

> 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

Re: Mandatory elements in archetypes, and user interfaces

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

Re: Mandatory elements in archetypes, and user interfaces

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

Re: Mandatory elements in archetypes, and user interfaces

Hi, we handle mandatory always within the enclosing container. So a particular field (temperature) is only mandatory within the body temperature archetype. So if nothing else is entered in that archetype then temperature is also not mandatory. I also think it's a bad idea to make such 'leading'

Re: Mandatory elements in archetypes, and user interfaces

How we handle this: In our forms, if an archetype root or archetype slot is optional, it renders a remove button that works on a single click. In case it is pressed accidentally, it will then render an add button to add it again. In addition, if a user does not press the remove button and does