Hi Berth and others, I have been watching the mails flying from technical list for a while but did not just had quality time to digest them and respond...In fact I understand your concerns deep in my heart because I am also kind of "hate-to-wait" type of person ;)
Attention: this is a long message! I had been into openEHR quite a while and all I can say is there nothing comparable in any domain by terms of depth and quality of knowledge...I was even naive and crazy enough last year to put all my personal savings (including selling my car!) to initiate a very ambitious project which uses openEHR as the very kernel...To be submitted to the European Union's Framework 6 Information Society Technologies Programme Call 5 which closed in 22 March 2005. The project idea started in Dec 2004 and we had so little time to gather people and ideas together but we missed the deadline! All needed was maybe a few days more to setup the financial stuff (which I dislike and not understand in my life)...But since there were literally nobody else doing that and assuming that I am not superman we could not finish in time...At the day of proposal the person from university has left for birthday party of her daughter! And the guy who was in charge of preparing A-Forms (just asimple form for each partner) did not do his work! So my university has left me alone and did not had guts ro take the responsibility even though they pushed me to do in initially!...Lack of leadership and committment...Sorry for that but I am still so angry with how things happened that I cannot help myself! At the end of 22 March 6 o'clock Brussels time, I was a man who used the last penny and also has a debt of some 20,000???. If you are interested the project website is still up to provide vision and knowledge for future proposers at the SourceForge site: http://cerebrus-fp6.sourceforge.net You will be amazed how we formulated a very good proposal with the best players in the World...But as the surgeons frequently say: "This was an excellent operation but the patient died!" Well, it took me up to this time till I recovered financially (and mentally of course) but what I learned from this is to be "Patient"....We can not save the World in one day...It takes a while...But we will in the end ;) I agree with Thomas that openEHR is in a way more conservative and careful in not jumping into the Arena and start impementing right away...In a domain so complex and difficult (due to the classical M.D. mentality - I am God!) one has to take into account many viewpoints and things...In one of my Ph.D. classes we had discussed with a Professor from Business Administration that no domain exists that is more demanding than healthcare...Look at the type of services a hospital has to do: In addition to all the Medical core services they must equally think about services for hotel, food, procurement of medical and other supplies, quality management, education, marketing, financial, strategic planning, research, production of some goods and etc. So if you jump off the train before the standardisation work and the technical and organisational frameworks are ready it ends up in a mess - like a premature birth... So I recommend that we all wait for the Rel 1.0 and then decide what to do...Currently I am consulting a multinational Asian based company which won the tender for E-Government Gateway services of Turkey...Of course healthcare is one of our main pathways...I am now training the CTO and other top level project people on openEHR and related work (i.e. HL7)...They are extremely excited and interested and have not even heard of openEHR before although they worked on healthcare related projects in the past. This is typical...There is a big problem, industry is trying to bring solutions and there is a wealth of knowledge gained from past EU and other projects which ended in openEHR...So I strongly believe this is the future for EHR and related businesses...So I do not hesitate to put most of my apples into openEHR basket! (Even though I am one of the founding members of HL7 Turkey Affiliate, I do not promote it as openEHR) I would like to express my idea to the subject of this thread that, after writing some monsterous archetypes with the vi editor by hand I support the change proposed. It makes more sense to me to write the Terminology ID with the code together...It is much more human readable and editable (Look at MST-Colon archetype) This is only one of the set of archetypes I had to write by hand to fulfill my thesis work... I would also like to propose a new idea regarding the type of archetypes; currently two types: 1) Clinical ones, 2) Legacy ones for integration purposes 3) Koray's new proposal: Structural archetypes The rationale is as follows: When you work in a real implementable and clincially usable system, you end up having archetypes which chain smaller components which are themselves archetypes (i.e. via use_achetype notation). In my thesis work I have to model completely the Minimal Standard Terminology for Endoscopic Gastroenterology which is more than a standard terminology but an ontology. So in order to have a useful arhetype which I can use for validating my data and creating dynamic GUI for SDE I need to assemble for an Upper GIS Examination: Esophagus, Stomach and Duodenum archetypes just to describe Findings...But then I also have to manage the Diagnosis, complications, Additional Diagnostic and Therapeutic Procedures and so on....I think the resulting top level Findings of Upper GIS Examination Archetype should have features like History, Event Series, Protocol and so on....But the smaller components for Esopgahus, Stomach.... does not need to have these contextual attributes...So I must be able to assemble them just using a simple tree with Clusters and other leaf nodes. So the structural archetypes might possibly be without these features; the generalized top level clinical archetype can have them. The major problem with current approach is that if due to some problem with data consistency or design errors in an HIS, there may start some esopgahus data flying around without other proper related components. Of course there are the templates...But I do not have any idea how it will solve this problem...Maybe we can start another discussion on the Templates approach. Best regards, Dr. Koray Atalag > -----Original Message----- > From: owner-openehr-technical at openehr.org [mailto:owner-openehr- > technical at openehr.org] On Behalf Of Bert Verhees > Sent: 17 Ocak 2006 Sal?? 12:43 > To: openehr-technical at openehr.org > Subject: Re: difficulties starting an implementation > > Hi Thomas and others, > > Before you start reading, I want to tell you, I think OpenEhr is a very > valuable project, and many people want to use the concepts. > There are however difficulties which I want to address. If sometimes my > writings seem unpolite or harsh, please keep in mind that English is not > my > second language, in fact it is the fourth language I learned in my live. > This can cause some of my expressions to be clumsy or harder then I meant > to. > > I spent quite some time last week with studying the OpenEhr-website, and, > as I > said, it is very valuable, there are also a lot of frustrations one has to > experience when diving into the project. > > I express myself with a lot of words, I often do, afraid people do not > understand me, I do a lot of over-explaining. I admire when people can > express themselves with not so many words, but as I see, sometimes this > can > also come to misunderstandings. > This is an important subject for me, at this time, so I do not want to > take > risks of misunderstanding. > > Sometimes I also repeat myself because, different text-portions require a > similar but slightly different approach or answer. > > So please be patient with me. > > A long introduction (I will not do it again!!) > > > > > there is a Java ITS guide, which will be included here. The > > documentitself is available at > > http://svn.openehr.org/specification/BRANCHES/Release-1.0- > candidate/publish > >ing/its/Java/openEHR-JavaITS.pdf > > This document must be new, or I just have missed it. It is for a > programmer > very interesting document. Such documents prevents that programmers have > to > re-invent things, and can prevent unnecessary branching of code and > concepts, > which without such information can easily happen. > Necessary branching, which is explainable can be a good thing, but > unnecessary > or unintentional branching can be very bad and confusing. > > > > > > - Although there is a lot of Java-code, but it represents a previous > > > version, and there is no guaranteed effort that it will be up to date > > > with the official Openehr-Eiffel-code. > > > It can be used as is, but for own risk for missing the project > > > developments. > > > > this is correct, it is not up to date. The intention is that it will be > > brought up to date very soon after the Feb 1 publishing of Release 1.0, > > probably by my group at UCL in London. > > I will wait a bit with studying the code, anyway, I start studying the > code > when I start the project, I am thinking of. The expectation is that this > will > be very soon. > > > > > > - One can say, the Eiffel-code, as Thomas states somewhere, is the > > > case-tool, it represents the formal state of work/definitions. > > > One can create dotnet-libraries with it, which is already done. I can > > > load them in my Visual Studio and Delphi.NET. But I have no way of > > > checking if there is something happening behind the > > > interface-properties, or if they are just there as placeholders for > > > later use. My knowledge of Eiffel is really not enough for judging the > > > source-files. > > > > are you talking about the ref_impl_eiffel repository? You don't have to > > use that if you are not interested in Eiffel. But I don't know what you > > mean by "interface properties" above... > > It may be a way of describing, connected to other programming > environments. > > Some people may find following a bit boring, but I use this to explain > what I > mean by mixing two enviroments and the problems I experience. > Anyway, just to make it clear. > > <example> > A class has an "interface", this what it makes visible to other classes. A > property is some characteristic of a class. > F.e a class Person has a property bodyLength. This can be in inches or > centimeters. For example bodyLength can give you centimeters or inches, > depending on which Local is configured: > > In java one publishes the getters and setters, they do not use properties > often,though it could be possible. > In object pascal one publishes the property, and private implements the > getters and setters, they do not have to be public or published, the > compiler arranges the connection. One can also publish the getters and > setters in object pascal > In Eiffel I don't know. > > As you can see on the pseudo-code below, I am used to Pascal, Java and > C(++), > I mix them so anyone can understand. I call it Jascal++ ;-) > > const BRITISH = 0; > const OTHER=1; > > class Person{ > public property bodyLength:Integer read getLength; > public property Local write setLocal; > private function getLength:Integer; > private procedure setLocal(value:Integer); > private fLength:Integer; > private fLocal:Integer; > } > > procedure Person.SetLocal(val:Integer); > { > fLocal:=val; > } > > function Person.getLength:Integer{ > if fLocal=BRITISH then Result := fLength/2.54 > else Result := fLength > } > </example> > > In a case tool, only the class-interfaces is mentioned, and in a short > way, > eventually documentation added. > In a case tool a class would look like > > Person > ---------------- > bodyLength:Integer > Local:Integer; > > <comment> > (In XMI one would get about the same (but then in XML). > A case-tool can load the XMI, and generate code following the syntax and > programming standards of that particular language. > I know there are shortcomings in XMI, but still I think, it is better then > nothing, in accompanying docs, want could explain the shortcomings. Most > of > the classes and their particularities can be expressed in XMI) > </comment> > > The implementation-part is in the code, never seen implementation-parts in > a > case-tool. It is possible, but rarely done. > > When you use a case-tool which is at the same time a programming- > enviroment, > then you can eventually compile the code, but there will be no > implementation > behind the class-properties/methods, and in the compiled product, it is > hard > to discover which property/method has implementation-code behind and which > not. Escpecially when it is not explicitely said. > > When I find a DLL, which is compiled code, one could assume, it has all > the > implementation-code in it, why would one else compile it. But the user of > the > environment as a case-tool may also want to compile, just for checking for > errors. > So in this mixed case/programming-environment it is possible to find a > dotnet-dll, which is large, publishing all the classes, but has no or not > all > implementation-code. > > > > > > This is a confusing and maybe conflicting situation. > > > Because the code is at the same time case-tool storage, it serves two > > > purposes, which can for an outsider be confusing. > > > In a case-tool there is no need to write code behind the properties of > > > a class, one does not want to do that because code-writing is another > > > kind of job then software-architecture. A case-tool is a tool for an > > > architect, a designer, not for a programmer, although those two > > > professions can come together in one person, an outsider can never be > > > sure who was talking here behid this particular property or method. > > > > From my point of view, it is very simple. We express the openEHR models > > in Eiffel, which is a nearly pure OO environment, and we compile the > > model to get code. If you write code into the routines, then it is the > > same as programming. That's the whole idea seamless software > > development. We then build executables on Windows (.exe or .Net > > assembly), Linux (we're not doing this yet, but you just recompile on > > Linux to get an executable) and on the Mac (we have done some initial > > recompiles of the ADL workbench on the Mac, but there are some GUI > > anomalies to be solved). But all this is only relevant if you want to > > have any contact with Eiffel. > > > Then I understand that the Eiffel-code has its implementation-parts worked > out. > <comment> > The dotnet-DLL could then be used in a project. Maybe it even can be used > in > Mono, because there want be much Windows-API-stuff in it. Depending of > course > on the dotnet-version. I think the OpenEhr kernel does not take advantage > of > dotnet 2.0, so for compatibility reasons one could stick to dotnet 1.1, > for > the time being > </comment> > > I can understand, that using Eiffel in this way has a lot of advantage for > you, but for people using other programming environments it is difficult. > So interoperability to other programming environments is not so good. This > is > a bit of a vendor lockin, or better said, to a programminglanguage-lockin > > <eiffelstudio> > One is stuck to a certain environment. > I downloaded the community-version of Eiffel-studio 5.6, and I really had > problems to get the thing going. And I am used to many IDE's, Visual > Studio, > Borland-IDE's, KDevelop, and more. Also worked a bit with Eclipse. > Mostly it is simple, start a project, create new classes or add existing > ones > by adding sourcefiles. > Eiffel Studio does these thing a different way, even in the helpfile there > is > no entry which says: "Add a source file to a project." > I used it a few hours, then went back to tools in which I am much more > productive. > I can get used to it, but I must say, it is not very intuitive for me to > work > with. > </eiffelstudio> > > And since the "case-tool" Eiffel can only generate Eiffel-code, users op > other > programming environments have to completely rewrite the code from scratch. > > If one could use an XMI-model, which is an OMG-standard, one could easily > import/generate the code/classes and use them in an IDE and language of > choice. Most programming languages have a way to connect to XMI. > Still there will be a lot work to do, but much less then now, and one can > easier, and is also forced more to follow the code-concepts. > > I understand from a previous mail from you years ago, there are two main > advantages of Eiffel, multiple inheritance and the use of generic > template-types. > > For many languages, Java and object pascal, and also C# are solutions. > More or less elegant. As ACode proves, it is possible to write the kernel > in > Java, this is good news. It maybe possible to write it in other languages. > Though, I had problems importing the code in Rose and in magicDraw, for > re-engineering purposes, but I did not really try hard. Maybe it is > possible. > > > > - There are no example implementations of a complete openehr-system on > > > this website, does this mean that there are no open source > > > implementations? > > > Only parts can be found, which are interesting pieces of work, but the > > > things do not come together now. > > > > that's is true. To my knowledge, there are no complete open source > > implementations. That will take time. > > If it was possible to export the code-concepts in a vendor-independent > way, > Openehr could become useable by much more programmers. > This would really speed up the coming of open source implementations. > > Also there is a need of more ITS and example projects. There is f.e. no > persistence layer and no example GUI-layer, and though there is a lot of > documentation, it is hard to get the pieces together. It takes weeks to > read > and understand the complete docs, after one must start programming, with > bad > luck, from scratch. > > At this moment OpenEhr seems to me more like a OpenConcept-project instead > of > an OpenSource-project. > > > > > > - Are there any known closed source implementations which run fine? > > > > You can see the list of (some) openEHR projects at > > http://www.openehr.org/projects/t_projects.htm > > I tried some of those, hoping to gain some knowledge of OpenEhr > implementing, > but I found some of them not even mentioning the OpenEhr project, and some > of > them did not have much activity in the OpenEhr mailinglists. (I (re)search > for, to discover which ones can really help.) > But I also found some, which do very promising work. > > > > > > - Can the experienced programmers be hired? > > > - why is the ITS and knowledge coming from the closed source-projects > > > not returned to the project? "Give and Take" is the idea of open > > > source which I like. > > > > well, that is always up to the individual projects. Official openEHR.org > > projects (i.e. the ones you see under the website "project" link) are > > all completely open source. > > I did not find a project which does the complete implementation. maybe I > missed it. > > But reading further, i can see that I have to wait. That is a bit of a > problem. It is not that I am on a day to day schedule, but some investors > want to have some time-schedule.They do not want to hear something like > somewhere next year. > > But maybe, I found a company willing to help us, I did not agree to > mention > its name publicly, sorry for that. But it is possible, that there will be > some news in short time. > The people investing in the project are willing to donate the ITS coming > from > their project into the OpenEhr project. > What is needed most, for now, in my humble opinion, is an example > persistence > layer and an example GUI-project for representing medical data > > From your other email: > > we continue to use Eiffel simply because it actually implements > > object-oriented semantics properly, and allows us to validate the model. > > I don't know of any equivalent tool. > > I have no problem with that, I am looking for a way to help more > "Worlds" (specially mine ;-) > > > > I have seen magicDraw UML in the SVN=tree, but is it always updated as > > > the Eiffel-code is? Can it safely be used to generate code? > > > Is it complete enough do do a signifant part of the code-generation? > > > > it is not currently up to date, and we had to introduce some real hacks > > to include even basic things like List<String>. My impression after > > working for some months with this tool, and also other supposedly top > > quality UML tools is that they are basically diagramming tools and do > > By the way, I saw in the Eiffel Studio a menu-option: Export To XMI. > Could that be useful? Is it possible to do those basics things here > > Regards > Bert Verhees
