# Data-entry for OpenEhr

**URL:** https://discourse.openehr.org/t/data-entry-for-openehr/14746
**Category:** Technical (archive)
**Created:** [23 April 2008 12:43 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746 "2008-04-23T12:43:37Z")
**Posts on this page:** 17
**Page:** 1

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 April 2008 12:43 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/1 "2008-04-23T12:43:37Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Peter\_Gummer1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/p/258eb7/32.png) [@Peter\_Gummer1](https://discourse.openehr.org/u/Peter_Gummer1)
#### Post date: [23 April 2008 13:21 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/2 "2008-04-23T13:21:49Z")

</div>

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](http://www.openehr.org/wiki/pages/viewpage.action?pageId=786487)

- Peter

---

<div class="post-metadata">

### Author: ![Tim\_Cook2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/57b2e6/32.png) [@Tim\_Cook2](https://discourse.openehr.org/u/Tim_Cook2)
#### Post date: [23 April 2008 13:52 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/3 "2008-04-23T13:52:12Z")

</div>

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. 🙂

Cheers,  
Tim

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 April 2008 13:56 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/4 "2008-04-23T13:56:37Z")

</div>

Peter Gummer schreef:

> Bert Verhees wrote:  
> &nbsp;&nbsp;
> 
> > 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?  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > Does this help?
> 
> [http://www.openehr.org/wiki/pages/viewpage.action?pageId=786487](http://www.openehr.org/wiki/pages/viewpage.action?pageId=786487)
> 
> - Peter  
> &nbsp;&nbsp;

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

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 April 2008 14:16 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/5 "2008-04-23T14:16:10Z")

</div>

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.  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > 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.  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > 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?  
> > &nbsp;&nbsp;

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.

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 April 2008 15:11 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/6 "2008-04-23T15:11:43Z")

</div>

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.  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > Okay...good. 🙂
> 
> > My question: In what form should I shape the data, so that form is  
> > usable with every possible valid archetype?  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > 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.  
> &nbsp;&nbsp;

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  
&nbsp;&nbsp;&nbsp;&nbsp;PERSON[at0] matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;identities cardinality matches {0..\*; unordered; unique} matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PARTY\_IDENTITY[at1] matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;name matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DV\_TEXT matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value matches {"legal identity"}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
}

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" \>  
&nbsp;&nbsp;&nbsp;&nbsp;\<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

---

<div class="post-metadata">

### Author: ![Tim\_Cook2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/57b2e6/32.png) [@Tim\_Cook2](https://discourse.openehr.org/u/Tim_Cook2)
#### Post date: [24 April 2008 14:21 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/7 "2008-04-24T14:21:44Z")

</div>

> 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. 🙂

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

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [25 April 2008 07:23 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/8 "2008-04-25T07:23:53Z")

</div>

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.  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > ...
> 
> > 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  
> > &nbsp;&nbsp;&nbsp;&nbsp;  
> > Hi Bert,
> 
> I hope your bike ride was inspirational. 🙂  
> &nbsp;&nbsp;

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.  
> &nbsp;&nbsp;

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.  
> &nbsp;&nbsp;

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

---

<div class="post-metadata">

### Author: ![Heath\_Frankel3](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/e19b73/32.png) [@Heath\_Frankel3](https://discourse.openehr.org/u/Heath_Frankel3)
#### Post date: [28 April 2008 01:46 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/9 "2008-04-28T01:46:34Z")

</div>

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

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [29 April 2008 10:41 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/10 "2008-04-29T10:41:01Z")

</div>

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

Bert

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [1 May 2008 22:37 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/11 "2008-05-01T22:37:36Z")

</div>

> 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

---

<div class="post-metadata">

### Author: ![Greg\_Caulton](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/g/f14d63/32.png) [@Greg\_Caulton](https://discourse.openehr.org/u/Greg_Caulton)
#### Post date: [2 May 2008 13:30 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/12 "2008-05-02T13:30:27Z")

</div>

> Message: 1  
> Date: Fri, 02 May 2008 00:37:36 +0200  
> From: Bert Verhees \<[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)\>  
> Subject: Re: Data-entry for OpenEhr  
> To: [heath.frankel@oceaninformatics.com](mailto:heath.frankel@oceaninformatics.com), For openEHR technical  
> discussions \<[openehr-technical@openehr.org](mailto:openehr-technical@openehr.org)\>  
> Message-ID: \<[481A4630.5020207@rosa.nl](mailto: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](http://www.patientos.org)

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [4 May 2008 19:40 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/13 "2008-05-04T19:40:23Z")

</div>

> 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

---

<div class="post-metadata">

### Author: ![Greg\_Caulton](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/g/f14d63/32.png) [@Greg\_Caulton](https://discourse.openehr.org/u/Greg_Caulton)
#### Post date: [5 May 2008 13:24 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/14 "2008-05-05T13:24:21Z")

</div>

> ------------------------------
> 
> 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](http://www.patientos.org)

---

<div class="post-metadata">

### Author: ![Adam\_Flinton](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@Adam\_Flinton](https://discourse.openehr.org/u/Adam_Flinton)
#### Post date: [7 May 2008 13:12 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/15 "2008-05-07T13:12:16Z")

</div>

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).  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> > 
> > 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](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/](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

---

<div class="post-metadata">

### Author: ![erik.sundvall](https://discourse.openehr.org/user_avatar/discourse.openehr.org/erik.sundvall/32/1961_2.png) [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [9 May 2008 07:18 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/16 "2008-05-09T07:18:35Z")

</div>

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/](http://www.imt.liu.se/~erisu/) Tel: +46-13-227579

---

<div class="post-metadata">

### Author: ![Adam\_Flinton](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@Adam\_Flinton](https://discourse.openehr.org/u/Adam_Flinton)
#### Post date: [9 May 2008 10:20 UTC](https://discourse.openehr.org/t/data-entry-for-openehr/14746/17 "2008-05-09T10:20:38Z")

</div>

Erik Sundvall wrote:

> Hi!
> 
> These might be stupid questions:  
> Is there anyting in the "xmlprocess" tool currently that is openEHR-related?  
> &nbsp;&nbsp;

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](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](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