RE: Mandatory elements in archetypes, and user interfaces

[Bakke, Silje Ljosland]

Thanks for your good answers, Pieter, Boštjan, Thomas, Pablo and Bjørn!

What I’m taking from this is that it’s not a problem using an archetype with an 
“archetype-mandatory” element in a UI where that element isn’t “UI-mandatory” 
(by which I mean that the element must be displayed and filled, either by 
prefilling or by the user) – the applications should handle no data entered 
into the element in one of several possible ways:

· By the user explicitly removing the archetype by clicking some kind 
of “remove” button.

· By the application automatically choosing not to persist the 
archetype at all if no data is entered. This is of course dependent on there 
being no data entered into any other elements of the archetype, and that the 
archetype itself isn’t set as mandatory in the template.

· By using null flavours as detailed in the openEHR specs.

Regards,
Silje

From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Bjørn Næss
Sent: Monday, November 27, 2017 7:35 PM
To: For openEHR implementation discussions 
<openehr-implementers@lists.openehr.org>; For openEHR clinical discussions 
(openehr-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/Diagnosis.

We have implemented several strategies to cope with this:


· First of all the container must be initialized to make an element 
mandatory.

o   I.e. one of the element in the Problem/Diagnosis archetype must have a 
value to “force” the mandatory element to have a value in the archetype.

o   Of course the container (the entry archetype) must not be mandatory, but 
that’s another topic

· We have added some extra annotations to our Form Designer/ Form 
Renderer to relax the constraints when the container is empty.

· We have the possibility to add “NULL_FLAVOUR” if the user are not 
able to give any reasonable data into the element.





Example of Null Flavours – for those who might have forgotten.








Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>

From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Bakke, 
Silje Ljosland
Sent: fredag 10. november 2017 11:48
To: 
openehr-implementers@lists.openehr.org<mailto:openehr-implementers@lists.openehr.org>;
 For openEHR clinical 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 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 Problem/diagnosis name 
in Problem/diagnosis, and Temperature in Body temperature. This is not intended 
to mean that it’s mandatory to enter data into the element in a UI, but that 
this particular element is mandatory in any persisted composition that uses the 
archetype.

Recently however, we received a request to change the Head circumference 
element in the Head circumference archetype from 1..1 to 0..1 because the 
element being mandatory in the archetype automatically made the UI form builder 
mandate the entering of data into the UI field, and removing the archetype on 
the fly made more unnecessary clicks. In a fit of mental hiccups, I agreed with 
and performed this change, but have since realised this is wrong, because:

· A mandatory archetype element is not the same as a mandatory UI field

· A mandatory UI field is more like a field where you only allow 
persisting non null values, while a mandatory archetype element can be 
persisted with a null value without a problem.

How are implementers actually handling this? Do you separate UI field mandation 
and archetype element mandation?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

RE: Mandatory elements in archetypes, and user interfaces

[Bjørn Næss]

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 make an element 
mandatory.

o   I.e. one of the element in the Problem/Diagnosis archetype must have a 
value to "force" the mandatory element to have a value in the archetype.

o   Of course the container (the entry archetype) must not be mandatory, but 
that's another topic

· We have added some extra annotations to our Form Designer/ Form 
Renderer to relax the constraints when the container is empty.

· We have the possibility to add "NULL_FLAVOUR" if the user are not 
able to give any reasonable data into the element.





Example of Null Flavours - for those who might have forgotten.








Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.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) 
Subject: Mandatory elements in archetypes, and user interfaces

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 Problem/diagnosis name 
in Problem/diagnosis, and Temperature in Body temperature. This is not intended 
to mean that it's mandatory to enter data into the element in a UI, but that 
this particular element is mandatory in any persisted composition that uses the 
archetype.

Recently however, we received a request to change the Head circumference 
element in the Head circumference archetype from 1..1 to 0..1 because the 
element being mandatory in the archetype automatically made the UI form builder 
mandate the entering of data into the UI field, and removing the archetype on 
the fly made more unnecessary clicks. In a fit of mental hiccups, I agreed with 
and performed this change, but have since realised this is wrong, because:

· A mandatory archetype element is not the same as a mandatory UI field

· A mandatory UI field is more like a field where you only allow 
persisting non null values, while a mandatory archetype element can be 
persisted with a null value without a problem.

How are implementers actually handling this? Do you separate UI field mandation 
and archetype element mandation?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[GF]

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 be 
set fully.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 10 Nov 2017, at 15:49, Boštjan Lah  wrote:
> 
> 
> 
>> 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 pressure, etc.
> Perhaps I can make a counter-question - can you give an example where this 
> makes sense?
> 
> Bostjan
> 
> 

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[Pablo Pazos]

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 element. null_flavour
can be set by the system, or there can be a null_flavour field on the UI to
let the user specify why there is no data on the field, on this case what
can be mandatory is the data field or the null_flavour for that field.

Hope that helps.



On Fri, Nov 10, 2017 at 7:47 AM, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> 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 sense
> without this particular element recorded. Examples are Problem/diagnosis
> name in Problem/diagnosis, and Temperature in Body temperature. This is not
> intended to mean that it’s mandatory to enter data into the element in a
> UI, but that this particular element is mandatory in any persisted
> composition that uses the archetype.
>
>
>
> Recently however, we received a request to change the Head circumference
> element in the Head circumference archetype from 1..1 to 0..1 because the
> element being mandatory in the archetype automatically made the UI form
> builder mandate the entering of data into the UI field, and removing the
> archetype on the fly made more unnecessary clicks. In a fit of mental
> hiccups, I agreed with and performed this change, but have since realised
> this is wrong, because:
>
> ·   A mandatory archetype element is not the same as a mandatory UI
> field
>
> ·   A mandatory UI field is more like a field where you only allow
> persisting non *null* values, while a mandatory archetype element can be
> persisted with a * null* value without a problem.
>
>
>
> How are implementers actually handling this? Do you separate UI field
> mandation and archetype element mandation?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
>
> Tel. +47 40203298 <+47%20402%2003%20298>
>
> Web: http://arketyper.no / Twitter: @arketyper_no
> 
>
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[Boštjan Lah]

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 pressure, etc.
Perhaps I can make a counter-question - can you give an example where this 
makes sense?

Bostjan



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 
> 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 further in the Template.

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 be needed in any 
derivative archetype or template, the original parent should have 0..1 or 0..* 
as appropriate.
Yes, but I think making all archetypes generic like Gerard suggests is not a 
good idea.

Bostjan

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[GF]

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  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 further in the 
>>> Template.
>> 
>> 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 be needed in any 
>> derivative archetype or template, the original parent should have 0..1 or 
>> 0..* as appropriate.
> Yes, but I think making all archetypes generic like Gerard suggests is not a 
> good idea.
> 
> Bostjan

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[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 be needed in any 
derivative archetype or template, the original parent should have 0..1 or 0..* 
as appropriate.

Yes, but I think making all archetypes generic like Gerard suggests is not a 
good idea.



I agree. Where there is a focal element that can't be null (in the 
programming sense) it should be 1..1 or 1..*; that's part of the 
semantic definition. Archetypes are about data; what goes on in the 
screen is more complicated sometimes. Particularly with pre-filled 
and/or defaulted fields.


- thomas

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[Thomas Beale]

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 sense without this particular element recorded. Examples are 
Problem/diagnosis name in Problem/diagnosis, and Temperature in Body 
temperature. This is not intended to mean that it’s mandatory to enter 
data into the element in a UI, but that this particular element is 
mandatory in any persisted composition that uses the archetype.




and that it should have a value, but the value may be derived by other 
means, e.g. a default value, or just set to 0 or other equivalent.


Recently however, we received a request to change the Head 
circumference element in the Head circumference archetype from 1..1 to 
0..1 because the element being mandatory in the archetype 
automatically made the UI form builder mandate the entering of data 
into the UI field, and removing the archetype on the fly made more 
unnecessary clicks.




I'm not sure I understand; what was the reason the head circumference 
should not have been visible on the form? A value doesn't have to be 
entered; the form can use default value or current value pre-fill.


In a fit of mental hiccups, I agreed with and performed this change, 
but have since realised this is wrong, because:


·A mandatory archetype element is not the same as a mandatory UI field

·A mandatory UI field is more like a field where you only allow 
persisting non /null/ values, while a mandatory archetype element can 
be persisted with a /null/ value without a problem.




well it depends on what you mean by a 'null' value; in mainstream 
programming languages, this means /no value/, i.e. nothing. This is not 
the same thing as an empty string or zero-valued number.


What does 'a mandatory UI field' mean? It could mean:

 * must be displayed and filled
 * must be displayed; will be prefilled in some way and may be
   optionally filled by the user


How are implementers actually handling this? Do you separate UI field 
mandation and archetype element mandation?


Kind regards,
*Silje Ljosland Bakke*

**




--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[Boštjan Lah]

> 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 further in the 
>> Template.
> 
> 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 be needed in any 
> derivative archetype or template, the original parent should have 0..1 or 
> 0..* as appropriate.
Yes, but I think making all archetypes generic like Gerard suggests is not a 
good idea.

Bostjan

> 
> - thomas
> 
> 
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org


___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[Thomas Beale]

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 
any restriction algebra, of which ADL is an example.


If it is thought that no occurrnces constraint might be needed in any 
derivative archetype or template, the original parent should have 0..1 
or 0..* as appropriate.


- thomas


___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[GF]

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 Templates but NOT Archetypes.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 10 Nov 2017, at 11: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 sense 
> without this particular element recorded. Examples are Problem/diagnosis name 
> in Problem/diagnosis, and Temperature in Body temperature. This is not 
> intended to mean that it’s mandatory to enter data into the element in a UI, 
> but that this particular element is mandatory in any persisted composition 
> that uses the archetype.
>  
> Recently however, we received a request to change the Head circumference 
> element in the Head circumference archetype from 1..1 to 0..1 because the 
> element being mandatory in the archetype automatically made the UI form 
> builder mandate the entering of data into the UI field, and removing the 
> archetype on the fly made more unnecessary clicks. In a fit of mental 
> hiccups, I agreed with and performed this change, but have since realised 
> this is wrong, because:
> ·   A mandatory archetype element is not the same as a mandatory UI field
> ·   A mandatory UI field is more like a field where you only allow 
> persisting non null values, while a mandatory archetype element can be 
> persisted with a nullvalue without a problem.
>  
> How are implementers actually handling this? Do you separate UI field 
> mandation and archetype element mandation?
>  
> Kind regards,
> Silje Ljosland Bakke
>  
> Information Architect, RN
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
> 
> Tel. +47 40203298
> Web: http://arketyper.no  / Twitter: @arketyper_no 
> 
>  
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>  
> 
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[Boštjan Lah]

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' fields 0..1.

Best regards,
Bostjan

On 10 Nov 2017, at 12:48, Pieter Bos 
> wrote:

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 not enter any 
data in any fields in an optional part, we consider that part to be not 
included in the resulting data. So far that approach works well for any models 
we have and is straightforward to use.

You could even add a ‘there is no data, but I want this part to be included’ UI 
element. We have not encountered a use case for that yet which cannot already 
be handled by the null_flavour of Element.

With these approach, the problem you mention does not exist in cases where the 
head circumference is sometimes but not always needed.

For cases where you don’t even want to see the input field at all, ever, we 
support templates. We use ADL 2, but it should be possible in OPT 1.4. Then if 
some users never need the head circumference, they can just set the occurrences 
of the use_archetype to {0} in a template, and the standard or in your case 
national archetype does not have to be changed.

Regards,

Pieter Bos

From: openEHR-implementers 
>
 on behalf of "Bakke, Silje Ljosland" 
>
Reply-To: For openEHR implementation discussions 
>
Date: Friday, 10 November 2017 at 11:47
To: 
"openehr-implementers@lists.openehr.org"
 
>,
 "For openEHR clinical discussions 
(openehr-clini...@lists.openehr.org)"
 >
Subject: Mandatory elements in archetypes, and user interfaces

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 Problem/diagnosis name 
in Problem/diagnosis, and Temperature in Body temperature. This is not intended 
to mean that it’s mandatory to enter data into the element in a UI, but that 
this particular element is mandatory in any persisted composition that uses the 
archetype.

Recently however, we received a request to change the Head circumference 
element in the Head circumference archetype from 1..1 to 0..1 because the 
element being mandatory in the archetype automatically made the UI form builder 
mandate the entering of data into the UI field, and removing the archetype on 
the fly made more unnecessary clicks. In a fit of mental hiccups, I agreed with 
and performed this change, but have since realised this is wrong, because:

· A mandatory archetype element is not the same as a mandatory UI field

· A mandatory UI field is more like a field where you only allow 
persisting non null values, while a mandatory archetype element can be 
persisted with a null value without a problem.

How are implementers actually handling this? Do you separate UI field mandation 
and archetype element mandation?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: 
http://arketyper.no

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[Pieter Bos]

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 not enter any 
data in any fields in an optional part, we consider that part to be not 
included in the resulting data. So far that approach works well for any models 
we have and is straightforward to use.

You could even add a ‘there is no data, but I want this part to be included’ UI 
element. We have not encountered a use case for that yet which cannot already 
be handled by the null_flavour of Element.

With these approach, the problem you mention does not exist in cases where the 
head circumference is sometimes but not always needed.

For cases where you don’t even want to see the input field at all, ever, we 
support templates. We use ADL 2, but it should be possible in OPT 1.4. Then if 
some users never need the head circumference, they can just set the occurrences 
of the use_archetype to {0} in a template, and the standard or in your case 
national archetype does not have to be changed.

Regards,

Pieter Bos

From: openEHR-implementers  on 
behalf of "Bakke, Silje Ljosland" 
Reply-To: For openEHR implementation discussions 

Date: Friday, 10 November 2017 at 11:47
To: "openehr-implementers@lists.openehr.org" 
, "For openEHR clinical discussions 
(openehr-clini...@lists.openehr.org)" 
Subject: Mandatory elements in archetypes, and user interfaces

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 Problem/diagnosis name 
in Problem/diagnosis, and Temperature in Body temperature. This is not intended 
to mean that it’s mandatory to enter data into the element in a UI, but that 
this particular element is mandatory in any persisted composition that uses the 
archetype.

Recently however, we received a request to change the Head circumference 
element in the Head circumference archetype from 1..1 to 0..1 because the 
element being mandatory in the archetype automatically made the UI form builder 
mandate the entering of data into the UI field, and removing the archetype on 
the fly made more unnecessary clicks. In a fit of mental hiccups, I agreed with 
and performed this change, but have since realised this is wrong, because:

· A mandatory archetype element is not the same as a mandatory UI field

· A mandatory UI field is more like a field where you only allow 
persisting non null values, while a mandatory archetype element can be 
persisted with a null value without a problem.

How are implementers actually handling this? Do you separate UI field mandation 
and archetype element mandation?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org