Dear All,
I was quite amazed with the frequency and quality of ideas and discussion on the openEHR technical list lately...Thank you for all your great contributions. I would like to give some information regarding openSDE...It has been developed by the Medical Informatics Dept. At Erasmus University Medical Center - the center founded by Dr. Jan Van Bemmel...For me the father of Medical Informatics. My journey with openSDE started in 2001 when I established the first (real) Medical Informatics department in Turkey at Hacettepe University. So I just jumped on a plane and got myself to the MIEUR with a very precious hand made copper plate with the Erasmus portrait carved and painted...Mr. Bemmel and others were very pleased I guess :) I was luckily hosted by Ms. Astrid van Ginneken during most of the day and I had a live demo of ORCA System which is actually openSDE based. This was before they went into Open Source... They were one of the core partners of the CEREBRUS project last year and I had been a messaging agent between openSDE and openEHR people...So we came up to a point that they agreed upon their existing systems main drawbacks and aimed at doing a joint research together with openEHR. The very reason that information and knowledge layers are not separated is because of some practical reasons for implementability...If you look at the history of Structured Data Entry research at the department some of you might well be a teenager when they started it! Even if that we did not have a successful project together, this was at least good for both parties to learn about each other and related methodologies. SO here are the draft proposed Work Packages (WPs) of MIEUR from CEREBRUS proposal: http://cerebrus-fp6.sourceforge.net/docs/FP6-2004-IST_PartB_IP_CEREBRUS_V2.5 .pdf Workpackage number: WP 2.1 Participant id: ERASMUS MC openEHR METU Person-months per participant: 12 6 3 Objectives Explore to what extent the dynamic approach of OpenSDE accommodates the requirements for data collection and consultation in the domain of patient care and clinical genetics in cardiology. Description of work Define scope and detail of information to be covered. Create a domain model for cardiology based on the inventory. Tailor the user interface of OpenSDE to data collection and consultation tasks in order to optimize the usability. Create a prototype to evaluate the usability of the domain model in combination with the dynamic approach of OpenSDE. Deliverables D 2.1 Domain model for patient care and clinical genetics in cardiology D 2.2 A prototype for evaluation D 2.3 Evaluation report Milestones[1] and expected result M 2.1 Evaluation whether the OpenSDE approach can serve as a valuable extension to OpenEHR. Workpackage number: WP 2.2 Participant id Erasmus MC Hacettepe METU Person-months per participant: 12 6 3 Objectives Insight into the compatibility of OpenSDE domain models with archetypes. Description of work Gain insight into and become acquainted with the use of archetypes. Express the required information as specified in D2.1 in the archetype model. Determine the syntactic and semantic similarities and differences between the OpenSDE domain model and the archetype model. Deliverables D 2.1 Archetype model of patient care and clinical genetics in cardiology D 2.2 Report on comparison of both models Milestones[2] and expected result M 2.1 Evaluation moment for possible adaptation of OpenSDE approach depending on comparison results. Workpackage number: WP 2.3 Participant id Erasmus MC MEDINFO ?????? METU Person-months per participant: 18 6 3 Objectives Applying the OpenSDE approach as part of OpenEHR to generate dynamic user interfaces using the insights gained the work packages 2.1 and 2.2. Description of work Using the insights gained from WP2.1 and WP2.2, OpenSDE will be adapted. Furthermore it will be made available as a stand alone application and be made suitable for integration with OpenEHR. Describe how OpenSDE generates user interfaces based on dynamic models. Deliverables D 2.1 Standalone implementation of OpenSDE and localized for target languages. D 2.2 Description of OpenSDE approach to generate dynamic user interfaces. D 2.3 OpenSDE module suitable for integration with OpenEHR. Milestones[3] and expected result M 2.1 OpenEHR with the capability to generate user interfaces based on dynamic models. So I hope nobody is angry with be because I share this information publicly...But this is the very reason that I put the project at sourceforge site... As a last comment, for us the openEHR community, I strongly believe that we really have a valuable lesson to be learned from openSDE especially in presentation, persistance and also data mining and information/knowledge extraction....The real beauty of such two-level systems come into play when you want to extract useful info out of clinical data...openSDE has a methodology called the Entity Export and openEHR proposes a term: Intelligent Querying... I am also putting Astrid van Ginneken and Marcel de Wilde in the CC list so that maybe they want to speak for themselves...And also Dr. Bemmel so that he may be interested with (and hopefully support) openEHR... Pretty exciting ha? Best regards, Dr. Koray Atalag > -----Original Message----- > From: owner-openehr-technical at openehr.org [mailto:owner-openehr- > technical at openehr.org] On Behalf Of Sebastian Garde > Sent: 18 Ocak 2006 ?ar?amba 02:16 > To: openehr-technical at openehr.org > Subject: RE: difficulties starting an implementation > > 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: owner-openehr-technical at openehr.org > [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 > > >
