Issues around UI technologies and bindings to back end

Technical (archive)
1

Hi,
Even if it feels a little bit too implementation related I’d like to get your opinions about the various UI implementation ideas/practices you may have, especially about web based applications.
I’ve written an initial set of things here : http://www.openehr.org/wiki/display/projects/Technology+and+architecture+challenges+in+UI+implementation. based on Opereffa, but I’d really like to hear how others are tackling UI layer.
I’m a little bit worried since I can see MS CUI being a little bit isolated from model driven approaches. If we are going to make use of this work (and I think we should), along with our own work, we’d better try to see how implementations of rich UI widgets can be put into use for clinicians.
Your comments will be appreciated

Kind regards
Seref

2

Hi Seref,

Seref Arikan wrote:

I've written an initial set of things here :
http://www.openehr.org/wiki/display/projects/Technology+and+architecture+challenges+in+UI+implementation.
based on Opereffa, but I'd really like to hear how others are tackling UI
layer.
I'm a little bit worried since I can see MS CUI ...

I had a look at these Silverlight "controls" - such as
http://www.mscui.net/Components/SingleConceptMatching.aspx
etc - perhaps I missed something, but
I can't see anything greatly different from what a Luddite
like me might achieve with XHTML-like select, check-boxes etc.

Complexity grows, in any case, when one considers screens where
one data-value (e.g. drop-down list) should vary in accordance with
another control's value (e.g. another list's item).
I am not even sure how openEHR archetypes fully allow such co-occurrence
constraints to be defined - I guess I'd try using invariant rules.
This isn't just a case of panels/containers being present/visible or not
- as archetype-slot toggling ought to be able to handle.

If we assume that detailed co-occurrence variations can be declared as
ASL invariant rules then - IMHO - it makes sense to take that
declarative approach down to the GUI level and interpret such rules at
data entry.
This is what xForms was supposed to be designed to do (using it's bind
declarations) - but the majority opinion of openEHR developer is that
xForms are dead in the water - and we should instead instantiate
object-oriented widgets to implement our GUIs.

I am not so convinced - I've played with the Orbeon xForms server
http://www.orbeon.com/
which embeds the eXist xml-db an I am quite impressed just how far
you can get in modern browsers without writing javascript or
requiring plugins. XML in XML out. It's nice to be web-based/RESTful
since it gives you so much for free.
It would be nice to implement a demo that compiles-down ADL to a form
Orbeon can serve - but, as I noted earlier, this is not a main-line
idea here: for one thing it mostly throws out the "O" from the "AOM".

Good work with Opereffa

Gavin Brelstaff
CRS4 Sardinia Italy.

3

Hi Gavin,
Thanks for the input, Now, to see a little bit more, please visit http://www.mscui.net/PatientJourneyDemonstrator/
Omer Hotomaroglu notified me of this some time ago, and I guess everyting here is not in CUI specs yet, but this is a much better demonstration of how GUI specialization can end up.
Of course I’m not a clinician, but assuming MS has someone telling them that clinicians would be happy with this, I’m focusing on the functionality.
As you’ve said it is about interactions between UI controls, and if you check this page you’ll see that layout related capabilities are also important, I’ll write about the in the wiki in detail, but the link above shows that making use of every UI capability is useful, actually, I’ve written about this in my blog some time ago : http://www.serefarikan.com/?p=42
The problem, especialy with these specific controls is, what will we do when a widget binds to multiple models? or there is an overlap between two models, which are used by two widgets on the same UI? I have reason to believe that our binding approaches are a little bit naive at this point, and I’d be satisfied when I can bind GUIs like in the Patient Journey Demonstrator to openEHR back end.

Now about UI - model relationship, my view is the GUI layer is way too complex and diverse to include in openEHR specifications, even a subset of the UI related stuff would be enough to introduce more problems than it solves.
IF there emerges a cross platform AND cross technology declerative markup for GUI and GUI interactions and bindings, and this is a big if, then it may be considered, otherwise, my personal opinion is to simply leave certain things out of the specifications. Templates may have some space in them where you can act naughty? Like the Z segment of HL7 V2, a redlight district where everyone visits every once in a while, but does not mention so much..

I’ve never heard about Orbeon, and I’ll be taking a good look at it, if it looks handy, I can simply add a link to it from Opereffa, to see how things will shape up.

Thanks again for the input, and the useful discussion.

Kind regards
Seref

4

Seref Arikan said the following on 22/7/09 11:39:

Now about UI - model relationship, my view is the GUI layer is way too
complex and diverse to include in openEHR specifications, even a subset
of the UI related stuff would be enough to introduce more problems than
it solves.
IF there emerges a cross platform AND cross technology declerative
markup for GUI and GUI interactions and bindings, and this is a big if,
then it may be considered, otherwise, my personal opinion is to simply

Hi, I must confess I've only half followed this discussion due to time
constraints, but this remark comes very close to my findings in a paper
I've written on this topic, which is now available as epub:

Generic screen representations for future-proof systems, is it possible?
There is more to a GUI than meets the eye.
van der Linden H, Austin T, Talmon J.
Comput Methods Programs Biomed. 2009 Sep;95(3):213-26. Epub 2009 Apr 15.
http://www.ncbi.nlm.nih.gov/pubmed/19368989

Re Orbeon: I think that's a nice start. Should dive into it more in the
near future.

With regards,

Helma van der Linden

5

Thanks Helma,
Very interesting feedback. Considering one of the authors, Tony Austin, is in the next room, and here I am hearing about this work from you :slight_smile:

Kind regards
Seref

6

Date: Wed, 22 Jul 2009 15:16:20 +0200
From: hepabolu <hepabolu@gmail.com>
Subject: Re: Issues around UI technologies and bindings to back end
To: For openEHR technical discussions <openehr-technical@openehr.org>
Message-ID: <4A671124.7020002@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Seref Arikan said the following on 22/7/09 11:39:

Now about UI - model relationship, my view is the GUI layer is way too
complex and diverse to include in openEHR specifications, even a subset
of the UI related stuff would be enough to introduce more problems than
it solves.
IF there emerges a cross platform AND cross technology declerative
markup for GUI and GUI interactions and bindings, and this is a big if,
then it may be considered, otherwise, my personal opinion is to simply

I agree, to start integrating UI related content into the archetypes is a very bad idea.

Most modern UIs follow a Model-View-Controller approach. For PatientOS Archetypes provide the data elements. The relationships and constraints within the archetype data elements is implemented in our model. We have different views - fat client, web client which are implemented through controllers written in java or javascript.

Atttempts to push everything into the archetype definition would create a complex beast which would defeat KISS principal.

As a side note I also think the ADL files is hampering adoption - not for us as there is a Java parser. Since everything that is the ADL must be expressable in XML (otherwise interoperability of the definitions would be problematic) - why have both - XML is ubiquitous and I think the benefits of readibility of an ADL file is no longer needed since there are tools which replace it - how many people read an ADL file any more?

7

Hi Greg,
I for one read ADL. We have Java parser, and .NET people has a .NET parser. If there are others out there with technologies without a parser (Python? anyting else?) I’d like to hear it voiced as a request.
Here is the reason I’d rather see ADL instead of XML: According to me, ADL is a machine processable representation for humans, and XML is a human processable representation for machines, and for some reason I find myself reading ADL from time to time.

Kind regards
Seref

8

More people than you think still read and write ADL by hand, as
openEHR clinical model is not the only language you can build
archetypes (for instance, you can do archetypes of openEHR
demographics, CEN EN13606 clinical model or demographics). However,
it's true that available tools support or plan to support different
models, but the tools that support those models are still unknown to a
lot of potential users

9

To clarify one thing: UI structures have to be based on templates, which are essentially specific ‘data set’ definitions, not archetypes, which standardise all content irrespective of any particular use. But I agree with the point that any such artefact cannot be assumed to be a direct basis for automated GUI building. I don’t think it is impossible, merely difficult (which reminds me of the Galen motto: “making the impossible very difficult”).

Re: ADL files; the reason ADL exists is because an ADL archetype is definitive - there is only one possible expression. With XML on the other hand, we have the current published schema; in the near future, I suspect it will be upgraded to be more efficient (seems everyone hates innefficient XML), and that could easily happen a few more times into the future.

Practically speaking, you are right, most normal system / product developers/vendors don’t need to care about the ADL if they don’t like it, they can just use the XML, and everything will work fine.

If ADL is ‘hampering adoption’ then we need to improve how we communicate the notion of archetypes, how to use them etc. Suggestions in this area are welcome.

  • thomas beale

Greg Caulton wrote:

(attachments)

OceanCsmall.png

10

There is an open source ADL to XML conversion library for .NET written in c# located at http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/BlueChina/XMLParser. This is used by the Archetype Editor to generate a pure XML representation of the ADL file via the ADL_Parser so that it can create a canonical xml representation of the archetype model for hashing purposes. The XML displayed and files generated directly from the Archetype Editor uses a different (legacy) mechanism and is not as reliable as that produced by the conversion library, the result is slightly different XML output. We just have not had enough volunteer time to replace this legacy approach within the Archetype Editor.

If anyone need assistance in using this conversion library I can provide an NUnit test library that shows how it can be used, or you can sift through the Archetype Editor code if you prefer VB.

We actually have a publishing tool using this library that can run a batch process against an entire Archetype file repository that can be run within an auto-build process and committed back into svn. This is how the XML archetypes on openEHR used to get generated prior to CKM.

I am not sure if CKM supports XML output of archetypes as yet but if it is felt that not having archetypes available in XML is holding back openEHR adoption then I am sure this can be put on the change request list for prioritisation.

Regards

Heath

Heath Frankel

Product Development Manager

Ocean Informatics

heath.frankel@oceaninformatics.com

+61 (0) 8 7127 5574

Regards

Heath

11

Heath Frankel wrote:

I am not sure if CKM supports XML output of archetypes as yet but if
it is felt that not having archetypes available in XML is holding back
openEHR adoption then I am sure this can be put on the change request
list for prioritisation.

No, it doesn't yet, but shouldn't be too hard.
There is a Java XML Generator as well, but not sure if it is consistent
with the C# conversion library yet.

Sebastian

12

Message: 1
Date: Sat, 25 Jul 2009 01:59:36 +0930
From: “Heath Frankel” <heath.frankel@oceaninformatics.com>
Subject: RE: Issues around UI technologies and bindings to back end
To: “‘For openEHR technical discussions’”
<openehr-technical@openehr.org>
Message-ID:
<00db01ca0c7b$f05e67f0$d11b37d0$@frankel@oceaninformatics.com>
Content-Type: text/plain; charset=“us-ascii”

There is an open source ADL to XML conversion library for .NET written in c#
located at
http://www.openehr.org/svn/knowledge_tools_dotnet/RELEASES/BlueChina/XMLPars
er. This is used by the Archetype Editor to generate a pure XML
representation of the ADL file via the ADL_Parser so that it can create a
canonical xml representation of the archetype model for hashing purposes.
The XML displayed and files generated directly from the Archetype Editor
uses a different (legacy) mechanism and is not as reliable as that produced
by the conversion library, the result is slightly different XML output. We
just have not had enough volunteer time to replace this legacy approach
within the Archetype Editor.

If anyone need assistance in using this conversion library I can provide an
NUnit test library that shows how it can be used, or you can sift through
the Archetype Editor code if you prefer VB.

We actually have a publishing tool using this library that can run a batch
process against an entire Archetype file repository that can be run within
an auto-build process and committed back into svn. This is how the XML
archetypes on openEHR used to get generated prior to CKM.

I am not sure if CKM supports XML output of archetypes as yet but if it is
felt that not having archetypes available in XML is holding back openEHR
adoption then I am sure this can be put on the change request list for
prioritisation.

Regards

Heath

Generating XML from ADL is one piece - but what is needed is the schema definition and not the generic one that fits all archetypes but rather one that is specific to the data elements and content of each archetype.

The technical people working with Archetypes today are obviously content with working with an ADL file but IMHO the software developers of tomorrow need to spend about 1 hour evaluating archetypes, import the definitions and then demonstrate that this well thought out, well structured OpenEHR data is of more value that defining ones own data hierarchy using HL7, LOINC, SNOMED etc.

XML, XSD has orders of more tooling support, ADL only has the few tools available that we know of and that affects productivity. If XML/XSD became the defacto standard I could take our administrative and billing data model and convert into ‘archetypes’ and quickly people could begin to review them.

As the CKM clinical reviews take place and the quality and quantity of the clinical archetypes increases the content becomes more valuable. But without easy access to that content I believe it does hamper adoption.

13

Greg Caulton wrote:

Generating XML from ADL is one piece - but what is needed is the schema definition and not the generic one that fits all archetypes but rather one that is specific to the data elements and content of each archetype.

Hi Greg,
both are needed. The generic openEHR XSD is used for software processing archetypes, including model authoring software and run-time software. A second kind of schema we call a ‘Template Data Schema’ is generated from an openEHR template, i.e. 1 template = 1 schema. This has not yet been openly specified due to lack of resources, but will as soon as it is possible. The reason why this kind of schema needs to be based on templates is because templates are the data-sets that correspond to any particular scenario of data capture or messaging. Archetypes as schemas in general don’t make clinical sense (a few come close, like some of the lab ones, which causes for some people the illusion that it is a general phenomenon).

The technical people working with Archetypes today are obviously content with working with an ADL file but IMHO the software developers of tomorrow need to spend about 1 hour evaluating archetypes, import the definitions and then demonstrate that this well thought out, well structured OpenEHR data is of more value that defining ones own data hierarchy using HL7, LOINC, SNOMED etc.

yes - but to do this, they need to be working with templates. Archetypes on their own don’t make sense as direct data-capture models.

XML, XSD has orders of more tooling support, ADL only has the few tools available that we know of and that affects productivity. If XML/XSD became the defacto standard I could take our administrative and billing data model and convert into ‘archetypes’ and quickly people could begin to review them.

what would be needed for that is to develop and publish more templates, along with their generate schemas, this would give the lever you are looking for.

  • thomas beale
14

yes - but to do this, they need to be working with templates.
Archetypes on their own don't make sense as direct data-capture models.

Thomas, I wonder why this is, maybe you can explain this or point to an
explanation.

Thanks
Bert

15

Bert Verhees wrote:

yes - but to do this, they need to be working with templates.
Archetypes on their own don't make sense as direct data-capture models.


Thomas, I wonder why this is, maybe you can explain this or point to an
explanation.

Archetypes act as a way to standardise the possible data points that could be captured about some topic, in any possible context (i.e. type of patient, type of clinic etc). So for example, the blood pressure archetype (see http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.130) contains the following data points in the ‘data’ part:

  • systolic pressure (SP)

  • diastolic pressure (DP)

  • mean arterial pressure (MAP) - perfusion pressure used by anaesthetists

  • pulse pressure (PP) - difference between SP and DP

  • comment
    Now, in actual real contexts, the things that can be used in a meaningful way are one of the following:

  • SP, DP // the usual one

  • MAP - which is related by a formula to SP & DP (see http://en.wikipedia.org/wiki/Mean_arterial_pressure)

  • PP - either computed from SP - DP, or measured directly by some devices
    MAP will never be needed in a normal GP or nursing context, and PP won’t usually be either, although I believe it is becoming moreso, because the PP history is recognised as an indicator of some problems. The point is, you will (probably) never create any data set (such as a form or a message) that corresponds to a particular clinical event (such as GP visit, etc) that contains all of these. Instead, you will make a template, that contains the SP and DP, possbly some other BP archetype items, and also a bunch of other items from other archetypes. This latter combination of items is what is being recorded in the specific situation. For another context, e.g. emergency department admission, a different combination of items will be recorded. Both could easily contain common elements from the archetypes they use; this is why archetypes exist - to standardise the semantic definitions of the information items; templates exist to put them together (sometimes with further constraints) for specific use cases.

One reason that this is not always clear is that there are some archetypes that would normally be used in their entirety in the template, e.g. Apgar, Barthel, some lab results and so on (although even then, the protocol information may or may not be included).

hope this clarifies

  • thomas beale
16

This reminds me a thing. Would be useful to have at ADL level
something like postconditions? (In your example, something stating how
to obtain or validate MBP from available values). I think this falls
into "knowledge" level.

17

Hi,

I can see the difference between templates and archetypes and why the templates are needed
for UI:s. The problem is the there is no complete template specification.

Is there a time plan for when it will be finished?

Regards

Olof

18

hope this clarifies

Thanks, Thomas, it clarifies why archetypes do not suffice in
application-context for data entry/presentation.
For the moment, we can live without templates (leave it to form-developers
to define where to use a specific archetype-item), or fabricate
template-definition for internal use. In initial phase, it does not have
to be very complicated.

for UI:s. The problem is the there is no complete template
specification.

I agree with Olof that there is a need for formal template-specification.

I think that when there is, it will be possible to exchange templates,
application forms, or even better, develop to exchangeable
application-functionality. This would cause the openehr-kernel to become a
supporting module which presents forms and stores data. But the real
application will be defined in the templates.

Is this the road-map we are looking at? Or are the goals different?

My thoughts on a Sunday-morning:
Medical-information-application-development will be a matter of writing
templates and archetypes. This can than be done by people specialized in
writing/defining GUI's and specialized in medical applications. I remember
this to be one of the original goals of the openehr-kernel.

The mix needed for software development, not only medical, is that an
application-developer needs to have technical knowledge, but also
domain-knowledge. Very often this prevents developers to be as good
skilled as would be possible if they could concentrate on either.
(no flame bait intended, there are many positive exceptions)

Software-developers than can concentrate on writing a good kernel, writing
good tooling. They can concentrate on the technical part of an
application. For example: It would even be possible to write a OpenEHR-OS,
highly optimized for this purpose. This could, for example, be based on
the Linux-kernel which is available for this, because it is open source
and therefore modifiable.

It also fits in the idea of having a separate OS-instantiation for each
separate service-application possible running in virtual environments.
If for scalability-purpose needed, it can also run on separate servers,
clusters, or even distributed. A matter of modularity.

regards,
Bert

19

Diego Boscá wrote:

This reminds me a thing. Would be useful to have at ADL level
something like postconditions? (In your example, something stating how
to obtain or validate MBP from available values). I think this falls
into "knowledge" level.

we already have ‘invariants’, which in ADL 1.5 would be renamed to ‘rules’. These are first-order predicate logic expressions that can reference anything in the definition. In ADL 1.5 I think they will be in a variant of Xpath syntax. This would enable the relationship between various data points to be asserted (e.g. with a formula).

There is also the idea that derived data points should be able to be expressed as functions, which I think will also occur in the future - this is probably what you are thinking about. This would allow the computation of a data point to be defined.

  • thomas beale
20

Olof Torgersson wrote: