Christmas cleaning of the openEHR wiki...

[Bakke, Silje Ljosland]

Hi everyone,

Sorry for the crossposting, but I thought this would concern everyone.

I believe the openEHR wiki is an important documentation tool that has probably 
been a bit neglected(?). The default Confluence theme isn't super pretty, and 
the site is difficult to navigate, in my opinion because of the large number of 
spaces and the lack of a proper front page for the site as a whole.

I'd like to suggest reducing the number of spaces by removing/merging/archiving 
the spaces that are empty and/or abandoned. Those are:

Effectively empty:

  *   https://openehr.atlassian.net/wiki/spaces/healthcare (mostly empty pages, 
last edit in 2011)
  *   https://openehr.atlassian.net/wiki/spaces/ds (Demo default Confluence 
space?)
  *   https://openehr.atlassian.net/wiki/spaces/CQ
  *   https://openehr.atlassian.net/wiki/spaces/WEB

Apparently abandoned:

  *   
https://openehr.atlassian.net/wiki/spaces/ADL
 (last three edits 338, 965 and 1631 days ago)
  *   https://openehr.atlassian.net/wiki/spaces/CIMI (last activity in 2015)
  *   https://openehr.atlassian.net/wiki/spaces/edu (two pages, the most recent 
edited in 2012)
  *   https://openehr.atlassian.net/wiki/spaces/ontol (only one page, edited in 
2012)
  *   https://openehr.atlassian.net/wiki/spaces/projects (last real 
contribution 720 days ago)
  *   https://openehr.atlassian.net/wiki/spaces/stds (last real contribution 
950 days ago)
  *   https://openehr.atlassian.net/wiki/spaces/SYS (last activity 2015)
  *   https://openehr.atlassian.net/wiki/spaces/term (last activity 2014)
  *   https://openehr.atlassian.net/wiki/spaces/oecom (last real contribution 
805 days ago)

I suggest the empty spaces are deleted, and the abandoned ones are archived.

This will leave us with:

  *   https://openehr.atlassian.net/wiki/spaces/dev
  *   https://openehr.atlassian.net/wiki/spaces/healthmod
  *   https://openehr.atlassian.net/wiki/spaces/resources
  *   https://openehr.atlassian.net/wiki/spaces/spec

...which in my opinion is a much more manageable selection of spaces.

I'm not sure what to do about the look of the page though. Maybe making a 
simple front page for the entire wiki with links and short descriptions about 
each space would solve a lot for now?

Thoughts?

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

[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 
; For openEHR clinical discussions 
(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

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>) 
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

Versioning of archetypes: Minor or major changes?

[Bakke, Silje Ljosland]

Another crosspost between the Clinical and the Implementers lists.

In versioning archetypes, we've defaulted to SemVer's three version levels 
MAJOR.MINOR.PATCH. When discussing with DIPS what should be considered MINOR or 
MAJOR changes, we've come to the preliminary conclusion that many more changes 
than we previously thought may require a MAJOR version change. This is 
exemplified below mostly with exchange of information between systems, but may 
also be relevant within a system when adding new functionality with a newer 
version of the same archetype.

These are as follows:

  1.  Adding non-mandatory elements (ie elements with occurrences 0..*): 
Depending on the validation mechanism at the receiving end, a system with an 
earlier version of the archetype that receives a message or payload with an 
element it doesn't recognise may reject the message or just ignore the new 
element.
  2.  Adding values to an internal value set:
 *   If adding the value Z to a value set that was originally "X, Y, 
Other", you're modifying the value of "Other", which previously would include 
Z. Semantically this is a major change, even if technically it's a minor one.
 *   If sending data to a system that has an earlier version of the 
archetype, the new value will not be understood.
  3.  Adding a run time name constraint: A run time name constraint has its own 
AT code, which could confuse a receiving system if it receives a code it 
doesn't know about.
  4.  All changes in cardinality or occurrences that opens up the archetype's 
constraints, such as making a previously mandatory element optional, or making 
a previously single occurrence element multiple occurrence. Not receiving an 
element you thought was mandatory or receiving more instances of an element 
than you thought possible, can make a receiving system's validation mechanism 
protest.

Thoughts?

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

Mandatory elements in archetypes, and user interfaces

[Bakke, Silje Ljosland]

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