Data-entry for OpenEhr
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 at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 On Wed, May 7, 2008 at 3:12 PM, Adam Flinton adam.flinton at nhs.net wrote: [...] 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.
Data-entry for OpenEhr
Greg Caulton wrote: -- Message: 2 Date: Sun, 04 May 2008 21:40:23 +0200 From: Bert Verhees bert.verhees at rosa.nl Subject: Re: Data-entry for OpenEhr To: For openEHR technical discussions openehr-technical at openehr.org Message-ID: 481E1127.6060805 at 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 ** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail **
Data-entry for OpenEhr
-- Message: 2 Date: Sun, 04 May 2008 21:40:23 +0200 From: Bert Verhees bert.verhees at rosa.nl Subject: Re: Data-entry for OpenEhr To: For openEHR technical discussions openehr-technical at openehr.org Message-ID: 481E1127.6060805 at 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
Data-entry for OpenEhr
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
Data-entry for OpenEhr
Message: 1 Date: Fri, 02 May 2008 00:37:36 +0200 From: Bert Verhees bert.verhees at rosa.nl Subject: Re: Data-entry for OpenEhr To: heath.frankel at oceaninformatics.com, For openEHR technical discussions openehr-technical at openehr.org Message-ID: 481A4630.5020207 at 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080502/32322dff/attachment.html
TDS, public development on openEHR wiki instead? (Was: Data-entry for OpenEhr)
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080502/cef37e6e/attachment.html
Data-entry for OpenEhr
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIGkYwsr/NIrczD3MRAgyNAJ9rHqDiaMhREnK2rOFTMRH7xECZzwCgo1yj ugRnj6/xj0/qya+olysU+MI= =8lBr -END PGP SIGNATURE-
Data-entry for OpenEhr
Thanks Heath, I must consider your writing, and tomorrow is Queens-day, so it can take a few days before I answer Bert
Data-entry for OpenEhr
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
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Bert Verhees
Sent: Thursday, 24 April 2008 12:42 AM
To: For openEHR technical discussions
Subject: Re: Data-entry for OpenEhr
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.
On Wed, 2008-04-23 at 16:16 +0200, Bert Verhees wrote:
Archetypes are in fact RM-objects, I have a way to store RM-objects
efficiently.
Okay...good. :-)
My question: In what form should I shape the data, so that form is
usable with every possible valid archetype?
A, 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
TDS, public development on openEHR wiki instead? (Was: Data-entry for OpenEhr)
Hi! I believe TDS is a very nice approach for som especific integration purposes. Simple and wonderful invention (the best ones are often simple...) For those new to TDS there was a thread regarding this earlier: http://www.openehr.org/mailarchives/openehr-technical/msg03116.html Are there any specific reasons for keeping the development internal to Ocean Informatics? As I understand it you sometimes internally use a wiki for these kinds of developments, I would suggest that you move the TDS (and if possible the AQL) development to the public openEHR wiki instead as they are of strategic importance to openEHR. Just post what you have right now including a comment that this is only experimental. This way you might get more input and wider testing.Certainly people/projects wanting to use TDS early will feel a lot more confident regarding progress and might trust it as a viable path to go for certain projects that would be riskier if there was only an expected release date from a company that may need to revise it's at priorities any time (as most companies do). Preliminary implementation experiments could be started right away and updated+launched when the real specification is finished. Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 On Mon, Apr 28, 2008 at 3:46 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: 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.
TDS, public development on openEHR wiki instead? (Was: Data-entry for OpenEhr)
Erik, The only reason for keeping it internal at this point is resources, having the time to document what has been done thus far in a publishable form. We have also been refining the rules and transformation based on implementation experience which has made this even more difficult. However, we feel that we are very close and are working on the documentation as quickly as we can (given priorities). I understand that you want us to simply publish what we currently have, but this is not the approach that Thomas wants to take at this point. Our intent is to provide a description of the transformation rules, and an XSL transform. The other factor is that the source of this transform is an Operational Template document, which is yet to be stabilised as we are awaiting the next draft of the Template Specification. I suspect that the TDS transformation will be published after this. I will leave it to Thomas to make any further comment on his return from leave. Heath -Original Message- From: e.sundvall at gmail.com [mailto:e.sundvall at gmail.com] On Behalf Of Erik Sundvall Sent: Monday, 28 April 2008 5:44 PM To: heath.frankel at oceaninformatics.com; For openEHR technical discussions Subject: TDS, public development on openEHR wiki instead? (Was: Data-entry for OpenEhr) Hi! I believe TDS is a very nice approach for som especific integration purposes. Simple and wonderful invention (the best ones are often simple...) For those new to TDS there was a thread regarding this earlier: http://www.openehr.org/mailarchives/openehr-technical/msg03116.html Are there any specific reasons for keeping the development internal to Ocean Informatics? As I understand it you sometimes internally use a wiki for these kinds of developments, I would suggest that you move the TDS (and if possible the AQL) development to the public openEHR wiki instead as they are of strategic importance to openEHR. Just post what you have right now including a comment that this is only experimental. This way you might get more input and wider testing.Certainly people/projects wanting to use TDS early will feel a lot more confident regarding progress and might trust it as a viable path to go for certain projects that would be riskier if there was only an expected release date from a company that may need to revise it's at priorities any time (as most companies do). Preliminary implementation experiments could be started right away and updated+launched when the real specification is finished. Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 On Mon, Apr 28, 2008 at 3:46 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: 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.
TDS, public development on openEHR wiki instead? (Was: Data-entry for OpenEhr)
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080428/20165f5d/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanInformaticsl.JPG Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080428/20165f5d/attachment.JPG
Data-entry for OpenEhr
Tim Cook schreef: On Wed, 2008-04-23 at 17:11 +0200, Bert Verhees wrote: 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. :-) 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 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Data-entry for OpenEhr
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
Data-entry for OpenEhr
Hi Bert, [this thread may belong on the implementers list?] On Wed, 2008-04-23 at 14:43 +0200, Bert Verhees wrote: 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 -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080423/8b00dc87/attachment.asc
Data-entry for OpenEhr
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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Data-entry for OpenEhr
Tim Cook schreef: Hi Bert, [this thread may belong on the implementers list?] On Wed, 2008-04-23 at 14:43 +0200, Bert Verhees wrote: 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. - Let me tell you what I have. I have wonderful code from Rong, I changed it here and there, and some things I did completely renew. But what is very recognizable is the rm-builder. As I seen it last, Rongs feeds it with an archetype and an array of data, and the rm-builder manages to create an rm-object from that. How I use it is about the same, but I use it recursive and I have a complex layer of software around it, and now, it should manage to eat every archetype. I publish the parts of it which are derived from Rong's code later. --- Thanks Tim for your thinking with me I hope I made myself clear, it is difficult to ask the right question and get because of that, the right answer. 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Data-entry for OpenEhr
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.
On Wed, 2008-04-23 at 16:16 +0200, Bert Verhees wrote:
Archetypes are in fact RM-objects, I have a way to store RM-objects
efficiently.
Okay...good. :-)
My question: In what form should I shape the data, so that form is
usable with every possible valid archetype?
A, 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
Compositions are versioned in order to maintain temporal context. A
contribution is a change set of versioned compositions and these are key
to describing the validity of the data. See the openEHR EHR Information
Model reference document at
http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/roadmap.html
I hope I made myself clear, it is difficult to ask the right question
and get because of that, the right answer.
I agree. Asking the right question is always the hard part of systems
analysis. :-)
I hope this helps.
Cheers,
Tim
