Hi Bert, the way I understand the differences between openSDE and openEHR:
In comparison to openEHR, openSDE does not seem to offer a really clear separation between the domain model and the information model, it does not seem to have a information/reference model comparable to the one of openEHR or separate clinically meaningful knowledge-entities like archetypes offer. In my opinion, openSDE is optimised for structured data entry rather than semantic interoperability. While this is ok for one hospital, in my opinion it does not really help with semantic interoperability in the long run. That not withstanding, I believe openEHR can learn from openSDE when implementing the openEHR model: For example, openSDE offers some really good features within the GUI - how to document structured data, how to display it. That this can be done with a openEHR /archetype-based approach remains to be shown, but I am quite confident that it can be! Further, openSDE uses 'row modelling' (see http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=353023) to convert their domain model to a database and store data which offers some advantages (e.g. no or less changes are needed in the database when knowledge changes). But when implementing openEHR you most likely wouldn't want to use clinically meaningful relational database tables either, but rather store clinical data in accordance with the openEHR model (i.e. in compositions, entries, etc). So you could say, openEHR would then use 'advanced' row modelling. In my opinion, the patience of openEHR will be rewarded soon. Regards Sebastian Dr Sebastian Garde Faculty of Business and Informatics Central Queensland University Rockhampton Qld 4702, Australia s.garde at cqu.edu.au Ph +61 (0)7 4930 6542 Fax +61 (0)7 4930 9729 http://healthinformatics.cqu.edu.au -----Original Message----- From: [email protected] [mailto:owner-openehr-technical at openehr.org] On Behalf Of Bert Verhees Sent: Wednesday, 18 January 2006 8:46 AM To: openehr-technical at openehr.org Subject: Re: difficulties starting an implementation Hi all, Got some tips, just put a database under it and a GUI above, and there is an application. Sounds to me like a practical joke ;-) If it is that easy? why isn't this easy piece of work not published, somewhere on the openehr website? I have no problem writing a GUI, or a persistence-layer, in fact, that are the most simple things to do for a programmer. First year of the programmers school you learn using and writing persistence layers. OK, to write a good GUI involves usability-knowledge. But a stupid GUI any programmer can build. Is a special structure of the persistence-classes needed, an API so to say? I guess so, but that is only one of the questions. But how to connect them to the OpenEhr class-structure puzzles me. F.e. a few sequence diagrams with classes in it would help. I know, the idea of OpenEhr is in fact simple, beautiful by its simplicity. When working out, simplicity turns into complexity. A normal process in ICT. I know from experience that for someone involved in building a project, it is very easy to understand its documentation. In fact such a person does not even need the docs. For someone coming new to such a project it is very hard to step into the many many pages of documentation. This is espcecially true when there is nothing really doing something, and the project is incomplete. Something else: OpenSDE http://www2.eur.nl/fgg/mi/OpenSDE/ I looked to the openSDE-project, which should be inspired by the OpenEhr, as I heard. It really takes to much of my time, to find out if, or in howfar this is true. Maybe someone want to say something in short about this. I was spending some time in their docs, and I found that it was a very open project. The db-scheme's are documented, the API's which are involved in every part of its functionality are explained in detail. I could start right away with this project. My first impression is that it is flexible in implementation, easy in implementation, it has a domain model editor, a simple datamodel, it looks a lot like OpenEhr, but I must say, I am not the right person for qualifying this. I hope people who are, and reading this list, and having time, can spent some words on it. regards Bert Verhees
