Mandatory elements in archetypes, and user interfaces

Implementers (archive)
1

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?

2

Hi Silje,

I agree that you should make this mandatory for the archetype to make
sense.

If we have a mandatory item that is always filled with a certain value,
for instance we are storing details a lab test. We would set the
default in the template and make sure it is filled in the API call when
storing the composition, making it unessacary to render that field. In
our case we are making a custom application, not using a form renderer.
But i guess if you use a renderer you can hide the field in question
easily and use the default.

Best regards,

Wouter

De inhoud van dit bericht is uitsluitend bestemd voor de geadresseerde
en kan vertrouwelijke en/of persoonlijke informatie bevatten. Als dit
bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de
afzender te melden en het bericht (inclusief bijlagen) uit uw systeem te
verwijderen. Eurotransplant staat door de elektronische verzending van
dit bericht niet in voor de juiste en volledige overbrenging van de
inhoud, noch voor tijdige ontvangst daarvan.
Voor informatie over Eurotransplant raadpleegt u:
www.eurotransplant.org.

This message is intended for the addressee's eyes only and it may
contain confidential and/or personal information.
If you are not the intended recipient, you are hereby kindly requested
to notify the sender and delete this message (including attachments)
from your system immediately. In view of the electronic nature of this
communication, Eurotransplant is neither liable for the proper and
complete transmission of the information contained therein nor for any
delay in its receipt. For information on Eurotransplant please visit:
www.eurotransplant.org

"Bakke, Silje Ljosland" <silje.ljosland.bakke@nasjonalikt.no>

10/11/2017 11:47 >>>
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 nonnull 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
( https://twitter.com/arketyper_no)

3

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

4

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

5

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
  gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

6

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

7

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

8

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.

9

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

10

Why isn’t it a good idea?

Give an example, svp.

Gerard Freriks
+31 620347088
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

11

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

12

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.

13

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
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

14

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.

15

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.