Data-entry for OpenEhr

Technical (archive)
1

Hi all,

I am building an application on base of an OpenEhr kernel.

I would be very happy if people can give some ideas about one question I
have.

I don't need complete technical worked out docuemnts (although I don't
mind to recieve them)
But just some hints make me happy.

My problem is, I am looking for a good way to enter data into an OpenEhr
system.

I did some experiments with XML, which is good but I ran against
limitations (specially in cardinality), which may be possible to solve.

I have my system ready in a way that it eats archetypes, and data
belonging to those archetypes, and stores them in over a persistence layer.

There is only one important step, that is, what is a good way to connect
the data to the archetypes. Is this dADL, or better XML, or other means.

Are there any ideas?

Remember, only hints are already a great help, for considering how to
proceed

Thanks
Bert

2

Bert Verhees wrote:

There is only one important step, that is, what is a good way to connect
the data to the archetypes. Is this dADL, or better XML, or other means.

Are there any ideas?

Does this help?

http://www.openehr.org/wiki/pages/viewpage.action?pageId=786487

- Peter

3

Hi Bert,

[this thread may belong on the implementers list?]

I have my system ready in a way that it eats archetypes, and data
belonging to those archetypes, and stores them in over a persistence layer.

There is only one important step, that is, what is a good way to connect
the data to the archetypes. Is this dADL, or better XML, or other means.

I'm not sure I understand you correctly. But are you saying that you are
storing an empty archetype in a repository and then in other tables
(assuming a SQL database) storing the data collected from a GUI or
webform that was based on the RM constraints represented by that
archetype?

If this is the case then you must be creating a new table for every
archetype (and every new version of it) used. In that case then each
table would be related to the archetype via it's ID. I guess I am also
assuming that you are storing archetypes in your repository as ADL or
XML serializations? This approach seems to me that it would take ALOT!
of source code in order to manage connecting the data rows back to the
archetypes. Hmmm, say a module for every archetype?

If you could describe your data capture process a bit more as well as
your persistence approach it will help.

Of course I cannot leave one of these types of conversations without
mentioning the utility of using an OODBMS for inherently hierarchical
data. :slight_smile:

Cheers,
Tim

4

Peter Gummer schreef:

Bert Verhees wrote:
  

There is only one important step, that is, what is a good way to connect
the data to the archetypes. Is this dADL, or better XML, or other means.

Are there any ideas?
    
Does this help?

http://www.openehr.org/wiki/pages/viewpage.action?pageId=786487

- Peter
  

Thanks, Peter, but that is the part of my system that is ready, my
persistence-layer.

I need an elegant way to pass data (any form will do) together with the
according archetype to the system, so the persistence layer can store it.

I really did a hard job in optimizing the persistence layer, when I
solved this data-entry issue I will see how it performs. I have 6000
patients including complete medical history and anonimized to enter.

The optimizing of the persistence layer is not a matter of big idea's or
leading theories, but deciding what to do in every m*th*rf*ck*ng bit.

I have ways to enter those patients, but I want to do a good in the
first try, that is why I hope I get some ideas here. In the meantime, I
thinka bout ideas myself, tomorrow, I step on my bike, do 100km and hope
the problem is solved in my head when I get back.

We'll see.

Thanks anyway
Bert

5

Tim Cook schreef:

Hi Bert,

[this thread may belong on the implementers list?]

I have my system ready in a way that it eats archetypes, and data
belonging to those archetypes, and stores them in over a persistence layer.
    
There is only one important step, that is, what is a good way to connect
the data to the archetypes. Is this dADL, or better XML, or other means.
    
I'm not sure I understand you correctly. But are you saying that you are
storing an empty archetype in a repository and then in other tables
(assuming a SQL database) storing the data collected from a GUI or
webform that was based on the RM constraints represented by that
archetype?
  

No, no, the persistence part is ready. No problem.
Archetypes are in fact RM-objects, I have a way to store RM-objects
efficiently.

My problems is that I am looking for an elegant and efficient way tot
connect data to an archetype.
A way that can (will) be machine-generated

It is indeed possible that an archetype/template-engine will generate a
HTML-form.
The data in that form must be handed over to the kernel.

This is the spot where I am thinking about.

Because my kernel on forehand does not know which archetypes it will
have to "eat", it eats every archetype (if not it is a bug to be fixed)
Now, the data must come with the archetype , the kernel needs to eat all
data that come with a valid archetype.
My question: In what form should I shape the data, so that form is
usable with every possible valid archetype?

Is the answer dADL, or do I miss the purpose of dADL? Or am I thinking
of a misuse of dADL.

I have given my self a few days to think about this. so there is no hurry?

Maybe I ask the wrong question and should think about this in a compleet
other way.

6

Tim Cook schreef:

Hi Bert,

Please note that this is MY understanding of the reference model and is
subject to change by the expert opinion of others.

Archetypes are in fact RM-objects, I have a way to store RM-objects
efficiently.
    
Okay...good. :slight_smile:

My question: In what form should I shape the data, so that form is
usable with every possible valid archetype?
    
Ahhhh, I think that this is the crux of the issue.
My answer is that you "do not".

When data is captured (or changed) it is valid for THAT time and place
in accordance with the constraints of that version of that archetype.
That data is is not standalone, it is invalid anywhere else.

In order to maintain the semantic context; that data is tied to that
archetype, in a composition and submitted as part of a contribution.
  

I agree, that is what I do, what I try to find is a form to hand over
the data, with the archetype. So both, at the same time will be eaten
and stored by the kernel.
For example, I have a very simple archetype, only one data entry

The definition looks like this

definition
    PERSON[at0] matches {
        identities cardinality matches {0..*; unordered; unique} matches {
            PARTY_IDENTITY[at1] matches {
                name matches {
                    DV_TEXT matches {
                        value matches {"legal identity"}
                    }
                }
}

I want to hand this archetype with data, for example from a webform, or
a message interpreter to my kernel which knows what to do with it.

At this moment, I am thinking about something like this, an XML form
which contains the archetype-ID, and there in, nodes with path and value
Because only leaf-nodes can contain data, there only leafnodes in the
XML-file

For example for this archetype it would be:
<ArchetypedData
archetype_id="openEHR-EHR-CLUSTER.person_demographics.v1draft" >
    <ArchetypedDataset path="/identities[at0]/name[at1]/value"
value="Johnsson"/>
</ArchetypedData>

But I don't know if this is sufficient.

Anyway, this XML file will be given to the RM-builder, together with the
ADL-file, and the rm-builder should be able to validate and create good
RM-objects from this.

That is my idea, but I don't know if it is a good idea

Bert

7

I want to hand this archetype with data, for example from a webform, or
a message interpreter to my kernel which knows what to do with it.

...

Anyway, this XML file will be given to the RM-builder, together with the
ADL-file, and the rm-builder should be able to validate and create good
RM-objects from this.

That is my idea, but I don't know if it is a good idea

Hi Bert,

I hope your bike ride was inspirational. :slight_smile:

But now that I believe that I understand where your problem lies, I
believe that Peter correctly analyzed it by sending you the link to
Persistence on the openEHR wiki.

From your example maybe you are attempting to be too much of a
reductionist as far as stripping down the XML?

Because of my choice of approach, I don't think that I have any more
thoughts to contribute on this.

Mostly because I think that going through the steps of:

1) create an object from the ADL for the UI
2) add the data in the UI
3) validate the data
4) break the object back down to a serialization
5) map the serialization to your persistence layer

then to edit:

1) create an object from the ADL for the UI
2) retrieve serialized data
3) map the data to the object
4) edit the data in the UI
5) validate the data
6) break the object back down to a serialization
7) assign the new version to the serialization
8) map the serialization to your persistence layer

is very application code intensive.

Whereas using an object database:

A parser utility outside of your application is used to parse a set of
serialized archetype definitions into objects one time and they are
stored in an object repository.

1) retrieve the object(s) from the repository
2) add the data into UI
3) validate the data
4) store the object

then to edit:

1) retrieve the object from the database
2) edit the data in the UI
3) update the version information
4) store the new object

Tuning for performance is done by selecting at which levels your objects
inherit from the database persistence machinery.

I wish you the best in solving your persistence layer mapping.

Cheers,
Tim

8

Tim Cook schreef:

I want to hand this archetype with data, for example from a webform, or
a message interpreter to my kernel which knows what to do with it.
    
...

Anyway, this XML file will be given to the RM-builder, together with the
ADL-file, and the rm-builder should be able to validate and create good
RM-objects from this.

That is my idea, but I don't know if it is a good idea
    
Hi Bert,

I hope your bike ride was inspirational. :slight_smile:
  

Thanks, it was inspirational, in a poetic way. Spring is coming up,
flowers, birds, sun carefully shows her face between dark clouds
But now back on the job.

But now that I believe that I understand where your problem lies, I
believe that Peter correctly analyzed it by sending you the link to
Persistence on the openEHR wiki.
  

I think, you understand it almost.

The problem is not the persistence layer, my RM-objects are able to save
themselves in a transparent way. Even if I change the database to an
objectdatabase below, nothing will change. How my RM-objects save their
selves is not rocket science, but it was a lot of work to get this
efficiently done. So I keep this to myself for the moment, must make a
living out of it. Simply said, they have a method to do so. If I would
take a database like Cache, I could use the same interface. Also the
protocol does not make a difference to the interface, jdbc, odbc, API's,
you name it, changed in a short time. This is good news for eventually
buyers of my product.
(just emphasizing the qualities of my product, hope you don't mind)

The problem is indeed in the below section of your reply.

From your example maybe you are attempting to be too much of a
reductionist as far as stripping down the XML?

Because of my choice of approach, I don't think that I have any more
thoughts to contribute on this.

Mostly because I think that going through the steps of:

1) create an object from the ADL for the UI
2) add the data in the UI
3) validate the data
4) break the object back down to a serialization
5) map the serialization to your persistence layer

then to edit:

1) create an object from the ADL for the UI
2) retrieve serialized data
3) map the data to the object
4) edit the data in the UI
5) validate the data
6) break the object back down to a serialization
7) assign the new version to the serialization
8) map the serialization to your persistence layer

is very application code intensive.
  

until here, because, here is where I want to keep the database-type
transparent. This is important to me.

So I was thinking about a solution for handing over the leaf-node-data
to the kernel, and in the same way, make this in more ways functional,
so that with not too much code and also generic code the (G)UI handling,
machine-interface handling can be done. That is what I am looking for,
and I need to make a decision in short time.

A few months ago I saw a discussion about XForms here, but I did not
read it because lack of time.

I will do that now.

Thanks for helping me defining my problem, if you have something more to
add, please do

regards
Bert Verhees

9

Bert,
I think you might be on the right track with your pathed values, it is very
similar to an approach that Tom and I discussed as a more efficient XML
representation of openEHR data. However, I think you are going to have to
keep in mind the complexity of the openEHR Data types, values will not be
able to be represented as attributes unless you have pathed items that go
down to the datatype attribute level such as .../value/magnitude, or invent
a whole new schema representation for each Data Type. You also need to
consider RM attributes such as LOCATABLE.uid, not just archetyped data
elements.

Again, I think the persistence model article on the WIKI is relevant here.
I know you have your own database persistence representation but you could
consider this an intermediate persistence representation. You are certainly
welcome to represent the data within your application as you wish, but it
would be good to work collaboratively to ensure that we don't have a huge
number of alternate intermediate formats and that we learn from these
experiences.

One comment I will make is that when working with application developers
unfamiliar with openEHR that the paths are very difficult for them to
comprehend and if you are at all expecting third parties to utilise an
intermediate format through some API rather than being completely
encapsulated within your software that paths will be problematic to the
uptake of that API. The comparison of openEHR paths with XPath is often not
useful to these kind of developers either.

Ocean is also developing the idea of a Template Data Schema, which will be
published as a draft on openEHR in the coming months. This does provide a
specific XML schema for a template (or combined collect of archetypes) where
the XML element names come from the archetype element names, but there is
additional meta-data in the schema and the XML document based on that schema
which links each XML element back to the archetype element such as the
node_ids so that generic transformation logic can be written to generate an
openEHR instance for any set of archetypes. These Template Data Schemas can
be automatically generated from the archetype/template models based on a set
of rules. I can give you a sample of this if you would like but I suspect
that you don't need this template specific approach, which is intended more
for those that unfamiliar with openEHR or you want a intermediate data
representation that is closer to a specific use-case for integration
purposes.

Heath

10

Thanks Heath, I must consider your writing, and tomorrow is Queens-day,
so it can take a few days before I answer

Bert

11

Ocean is also developing the idea of a Template Data Schema, which will be
published as a draft on openEHR in the coming months. This does provide a
specific XML schema for a template (or combined collect of archetypes) where
the XML element names come from the archetype element names, but there is

That is fine, but I can't wait for that now. I really have to finish my
work on this in short time.
When the TDS will be released, I will study it and probably implement it
then.
Now I will go on with my schema, which, by the way, works with generated
XML-files too

Thanks, for your reply, and I hope TDS will be released to public soon.

Bert

12

Message: 1
Date: Fri, 02 May 2008 00:37:36 +0200
From: Bert Verhees <bert.verhees@rosa.nl>
Subject: Re: Data-entry for OpenEhr
To: heath.frankel@oceaninformatics.com, For openEHR technical
discussions <openehr-technical@openehr.org>
Message-ID: <481A4630.5020207@rosa.nl>
Content-Type: text/plain; charset=us-ascii

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ocean is also developing the idea of a Template Data Schema, which will be
published as a draft on openEHR in the coming months. This does provide a
specific XML schema for a template (or combined collect of archetypes) where
the XML element names come from the archetype element names, but there is

That is fine, but I can’t wait for that now. I really have to finish my
work on this in short time.
When the TDS will be released, I will study it and probably implement it
then.
Now I will go on with my schema, which, by the way, works with generated
XML-files too

Thanks, for your reply, and I hope TDS will be released to public soon.

Bert

I would also like to start importing openEHR content into PatientOS in the new few weeks. I am less concerned with the data at this point, rather I would like to be able to take a template (perhaps initially just archetypes and I will combine them internally to be larger forms) import it and make then available as a data entry form (and display).

I am debating whether to parse the XML generated by the Archetype Editor (awesome tool by the way) or leverage the java reference implementation to read an ADL and then import. I expect the XML would be quicker but more prone to break. Though at this point it is a proof of concept not a long term solution (which may use the TDS instead).

thanks!

Greg
http://www.patientos.org

13

I would also like to start importing openEHR content into PatientOS in
the new few weeks. I am less concerned with the data at this point,
rather I would like to be able to take a template (perhaps initially
just archetypes and I will combine them internally to be larger forms)
import it and make then available as a data entry form (and display).

I am debating whether to parse the XML generated by the Archetype Editor
(awesome tool by the way) or leverage the java reference implementation
to read an ADL and then import. I expect the XML would be quicker but
more prone to break. Though at this point it is a proof of concept not
a long term solution (which may use the TDS instead).

I am going to use a temporary solution, to get my data into my system.
It is not that important, it is only maybe 1% percent of all the code
involved, and with no interface change at most places I can switch
easily to another more standardized solution if it comes up, or maybe a
solution a customer wants, is also possible.

I took a short look at your system (is it yours, or from a team?), I
couldn't find any quick pointers to the architecture behind, and the
standards used. Maybe you can point me to some information.

I am interested.

thanks
Bert

14

------------------------------

Message: 2
Date: Sun, 04 May 2008 21:40:23 +0200
From: Bert Verhees <bert.verhees@rosa.nl>
Subject: Re: Data-entry for OpenEhr
To: For openEHR technical discussions <openehr-technical@openehr.org>
Message-ID: <481E1127.6060805@rosa.nl>
Content-Type: text/plain; charset=ISO-8859-1

> I would also like to start importing openEHR content into PatientOS in
> the new few weeks. I am less concerned with the data at this point,
> rather I would like to be able to take a template (perhaps initially
> just archetypes and I will combine them internally to be larger forms)
> import it and make then available as a data entry form (and display).
>
> I am debating whether to parse the XML generated by the Archetype Editor
> (awesome tool by the way) or leverage the java reference implementation
> to read an ADL and then import. I expect the XML would be quicker but
> more prone to break. Though at this point it is a proof of concept not
> a long term solution (which may use the TDS instead).

I am going to use a temporary solution, to get my data into my system.
It is not that important, it is only maybe 1% percent of all the code
involved, and with no interface change at most places I can switch
easily to another more standardized solution if it comes up, or maybe a
solution a customer wants, is also possible.

I took a short look at your system (is it yours, or from a team?), I
couldn't find any quick pointers to the architecture behind, and the
standards used. Maybe you can point me to some information.

I am interested.

thanks
Bert

The system is open source (GPL) so the team is community based and
while I have been the primary contributor there are others whose
contributions have been more than valuable.

The archtecture is distributed with a fat client and could be
described as including elements of Domain Model,
MVC/ApplicationController, DTO, Gateway, Mediator, though many of the
technologies help to simplify things - specifically Hibernate, JBoss
using EJB 3.0, RMI.

The front end is dynamically generated Swing based upon the database
defined content. The database is PostgreSQL though after 1.0 we will
start supporting Oracle. PatientOS XML integrates with Mirth which
does the heavy lifting for HL7, X12, NCPDP, Web services etc

Today (in development) you can build clinical forms with a forms
wizard but there have been a few people that have expressed interest
in how PatientOS could integrate with OpenEHR. So to start things off
I thought I would import archetypes to generate forms but retain the
archetype value path so that each data element could be mapped to a
corresponding OpenEHR value. How to use that later to support AQL or
OpenEHR messages is anyones guess, I will likely wait for some
direction at that point from someone who needs that level of
integration.

I'll start with the XML generated by the Ocean Archetype Editor and
let you know when those generated 'forms' can be accessed in the demo.

Greg

http://www.patientos.org

15

Greg Caulton wrote:

------------------------------

Message: 2
Date: Sun, 04 May 2008 21:40:23 +0200
From: Bert Verhees <bert.verhees@rosa.nl>
Subject: Re: Data-entry for OpenEhr
To: For openEHR technical discussions <openehr-technical@openehr.org>
Message-ID: <481E1127.6060805@rosa.nl>
Content-Type: text/plain; charset=ISO-8859-1

I would also like to start importing openEHR content into PatientOS in
the new few weeks. I am less concerned with the data at this point,
rather I would like to be able to take a template (perhaps initially
just archetypes and I will combine them internally to be larger forms)
import it and make then available as a data entry form (and display).

I am debating whether to parse the XML generated by the Archetype Editor
(awesome tool by the way) or leverage the java reference implementation
to read an ADL and then import. I expect the XML would be quicker but
more prone to break. Though at this point it is a proof of concept not
a long term solution (which may use the TDS instead).
      

I am going to use a temporary solution, to get my data into my system.
It is not that important, it is only maybe 1% percent of all the code
involved, and with no interface change at most places I can switch
easily to another more standardized solution if it comes up, or maybe a
solution a customer wants, is also possible.

I took a short look at your system (is it yours, or from a team?), I
couldn't find any quick pointers to the architecture behind, and the
standards used. Maybe you can point me to some information.

I am interested.

thanks
Bert

The system is open source (GPL) so the team is community based and
while I have been the primary contributor there are others whose
contributions have been more than valuable.

The archtecture is distributed with a fat client and could be
described as including elements of Domain Model,
MVC/ApplicationController, DTO, Gateway, Mediator, though many of the
technologies help to simplify things - specifically Hibernate, JBoss
using EJB 3.0, RMI.

The front end is dynamically generated Swing based upon the database
defined content. The database is PostgreSQL though after 1.0 we will
start supporting Oracle. PatientOS XML integrates with Mirth which
does the heavy lifting for HL7, X12, NCPDP, Web services etc

Today (in development) you can build clinical forms with a forms
wizard but there have been a few people that have expressed interest
in how PatientOS could integrate with OpenEHR. So to start things off
I thought I would import archetypes to generate forms but retain the
archetype value path so that each data element could be mapped to a
corresponding OpenEHR value. How to use that later to support AQL or
OpenEHR messages is anyones guess, I will likely wait for some
direction at that point from someone who needs that level of
integration.

I'll start with the XML generated by the Ocean Archetype Editor and
let you know when those generated 'forms' can be accessed in the demo.

I have been looking at a similar thing (esp wrt the use of Mirth to
allow us to create HL7 "dynamic" models which then contain the static
models etc & can be used by our test team to create an entire set of
interactions etc which can then be used to test implementations (esp by
the implementers before they come to us for formal testing).

But that's another story. I would point out the recent page:

http://www.openehr.org/specifications/spec_strategy.html

As you are not alone wrt wanting to create forms etc from XML
Archetypes/templates.

We have donated our XML engine here:

https://xmlprocess.projects.openhealthtools.org/

Which allows for the quick & easy creation of forms based on XML documents.

The one point I have been looking at is the how & where of datatypes as
everything else wrt creating XForms from (XML) Archetypes/templates
seems to be fairly straightforward.

Adam

16

Hi!

These might be stupid questions:
Is there anyting in the "xmlprocess" tool currently that is openEHR-related?
If not, are there any near-time plans for that?

I somehow (probably due to wishful thinking) got the impression that
the tool could be used for converting templates and archetypes to
xforms-based entry forms running in Chiba or something similar, but I
can't find anything near that when looking at the tool.

Could you please help me sort things out regarding how "xmlprocess"
relates to openEHR?

Best regards,
Erik Sundvall
erisu@imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579

17

Erik Sundvall wrote:

Hi!

These might be stupid questions:
Is there anyting in the "xmlprocess" tool currently that is openEHR-related?
  

Not yet

If not, are there any near-time plans for that?

Yes...sort of.

A) There is our Message Validator file maintenance app. This uses a
combo of XPath assertions & XSLT files to validate an incoming message
right from http header down to the most inner layer of the message onion
(i.e. through SOAP, EBXML, CDA etc)

One obvious missing part is OpenEHR validation etc & I'm looking at that.

B) I have looked long & hard at some sort of "give me a
template/archetype & I'll create an XForm for it".xslt.....

The fun parts are:

A) Datatypes
B) Subsidiarity - i.e.given choice, reuse etc the relevant XForm should
exist at (be a node under??) the relevant file e.g. every archetype
should have it's own XForm and a linking mechanism allowing it to
subsume others from further down the tree.

i.e. If I load template A then there should be an XForm for template A.
If that template includes Archetype B then there should be a mechanism
to simply bring in the relevant Archetype B XForm much as one would
bring in Archetype B.

i.e. ....."Here's a model (Archetype/Template etc)....&...here's it's view"

This would allow the steady creation of parts connected to specific
things much like that suggested wrt "widgets"

http://www.openehr.org/wiki/display/dev/Data+type+widgets

e.g. you might (hopefully will) have a specific set of XForm-OpenEHR Datatype "widgets".

Oddly enough..........right from the start I designed XMLProcess with
the concept of the "virtual document" aka the "PacMan principle" (Pacman
can only eat what's in front of him).

i.e. the formation of "an" XForm from many constituent parts much as a
Portal/Portlet might
As per something like
http://internet-apps.blogspot.com/2006/08/using-subforms-in-xforms.html

e.g. going & getting specific pieces for specific needs, right
from "I need a form for Template A"
to then "it contains 1...n Archetype B thus I need a muli-record layout
where each line contains the XForm/fragment for Archetype B"
to then "Archetype B contains a DV_DURATION I need to go & grab the
DV_DURATION XForm/fragment from the Datatypes_XForms_Fragments.xml"

I somehow (probably due to wishful thinking) got the impression that
the tool could be used for converting templates and archetypes to
xforms-based entry forms running in Chiba or something similar, but I
can't find anything near that when looking at the tool.

Not yet. It is a matter of writing the XSLT (to autogenerate a
fragment/XForm) & finalizing the inclusion mechanism.

Could you please help me sort things out regarding how "xmlprocess"
relates to openEHR?

Per se it doesn't. As the name suggests it is about creating rich forms
for editing XML rapidly & easily.

Right now the main limiting factor is time & instability wrt the
"operational templates etc".

Adam