difficulties starting an implementation
Bert Verhees wrote: I understand more or less what you are saying about hard/soft parts, that is the good thing of OpenEhr which you explain. Very good. But you still need to store the soft parts, so you need a persistence layer. This layer must interface with the kernel. I did not find information where that interface is and how to connect to it. That is the first major problem I encountered, some guys in this list said: Just put a database below But when I ask how they explain that they are not programmers. Makes me angry not too angry I hope! The persistence interface at the moment is not published as part of the specifications. It will be when current efforts in this area in the comunity have borne more fruit. But it is not difficult to design one - there needs to be a layer between the reference model classes and the database which converts the RM objects to a form most suitable for storage and querying on the database platform being used. Eiffel maybe a good language, but I have, reasons to hate the Eiffel Studio. I worked with many programming languages in the past, and I can get used to Eiffel, it is not a hard language to learn. But the studio. It took hours to find out how to add an existing sourcefile to a project, the buttons on the New Class dialog where grayed out. You just use an Ace file to indicate where the classes are. It's very simple. If you add a new class in one of those packages, the tool sees it automatically. Ok, there must be some logic behind it. Then I had to stop, and wanted to save the project. There is no way of saving a project, and it does not prompt me to save when closing the Studio. the project is always saved. I thought, it must have been saved automatically, which I don't like, but maybe there is logic behind it. Later I opened the project again, all my classes where gone, and I had to do the whole thing again, toke me three hours extra. Arrrggg. you've definitely done something strange there. Eiffel Studio is extremely simple: you tell it where the classes are with an Ace file, and you just start the tool. That's it. I guess when one is used to this kind of things, one can work with it, and be productive, but I can imagine it scares people away. well, you have to learn how to use the tool first. I'm sure you realise that no-one using Eiffel loses their work in this way. I sat down with Eclipse for the first time a few months ago, and I thought the way of getting around the packages was problematic. You couldn't hide version control directories. You have all this annoyance with CLASS_PATH. There is all this confusion (initially) between classes that are already on your disc versus ones that are created within the project. And you can't get inheritance-flattened views of anything, or interface views. But I read a fair bit of the book and other documentation, learned my way arond these seemingly strange things (normal to thousands of others of course) until I could drive the thing. I don't use MS Visual Studio often enough to be efficiennt at it, and it drives me crazy to be honest, but I can see that others are very productive, and I read often enough that it is an good IDE to believe it. Bert, there is always some learning involved. Clearly if you are losing 3 hours' of work you are not using the tool properly - there is huge online documentation (and documentation included in the tool help pages). - thomas
difficulties starting an implementation
Bert Verhees wrote: I wonder, Ian, did you ever looked to Cache (www.intersystems.com) It is called Post-relational, this is because it also can understand SQL. But it is a kind of OO-database, I don't know if it has all the OO-particularities like (multiple)inheritence, or object as field of another object. Personally, if I were to build an openEHR system on top of an object or O/R database, I would use Matisse. It is easily the fastest and most elegant system I have ever used, and works with every major language and platform. - thomas
difficulties starting an implementation
Op vrijdag 20 januari 2006 00:12, schreef Ognian Pishev: Cache has a MUMPS background, that is way it is popular among clinicians. Yes, that is true, Micronetics was taken over by Intersystems, that way they got MSM which is a MUMPS-engine for Windows. Cache still supports the Mumps-programming language, there is where you can see that there must be large portions of MSM-code in it. There is a lot of MUMPS-culture in the code, using %-signs a lot, f.e., and use the word do to start something I was on a one-day introduction in Brussels, I saw code, simple code, which create objects, and store them in a database as objects, and retrieve them from the database as objects Cache it is an expensive database-engine. But so is Oracle or SQL-server. They are all expensive. There are a lot of db-engines which are for free, good ones, very good ones. Maybe I understand wrong, but one disadvantage of a OO-db-engine can be data-redundancy. If you avoid data-redundancy it is possible you will be emulating a relational database. For example, if you create a list of address-objects and a list of person-objects, and connect a person to an address from the address-list, then you are playing relational db with an OO-db. Only the way you talk to the engine of an OO-db is then is different, but it is very simple nowerdays to hide SQL in classes, so talking to the database can be done without SQL, even if it is a relational database, but of course, there are limits. You can even use programmers without knowledge of SQL, if they exist. So, I don't know if an OO-db has that much of advantage above a relational-db. Often seen in MUMPS, which is hierarchical database (what is in an name), that programmers are not able to take advantage of its features, but start defining relations between globals (how they call there tables), and because MUMPS does not support relations between data, they have to program it, which causes a lot of code and validations to happen. Maybe there is a good reason for the existence of Relational DB's. Ever thought about that? Not only in the old days to save disk space, but in the new days because it is very smart and safe to relate data instead of redundancy. There is one funny particularity about Intersystems. It is a one person-owned-company, not even a family It has no Stock-Exchange notation, and an offer from Microsoft to buy the company was rejected by its owner on other then financial reasons. The owner, Terry Ragon, loves his company, and is commited to MUMPS since the very early days in 1978. So there are no stockholders which decide, but only he. regards Bert Verhees Ogi Pishev - Original Message - From: Bert Verhees bert.verhees at rosa.nl To: openehr-technical at openehr.org Sent: Friday, January 20, 2006 12:26 AM Subject: Re: difficulties starting an implementation I wonder, Ian, did you ever looked to Cache (www.intersystems.com) It is called Post-relational, this is because it also can understand SQL. But it is a kind of OO-database, I don't know if it has all the OO-particularities like (multiple)inheritence, or object as field of another object. Anyway, a fully functional single user license is free for download. it is the choice of many large health-systembuilders in the Netherlands (Nictiz) and the USA. regards Bert -- Met vriendelijke groet Bert Verhees ROSA Software
difficulties starting an implementation
Ian McNicoll MMS wrote: Either there is a documented interface to a persistence layer, or there isn't. It is quite possible I missed it in the documentations But till now, I asked it three times in three days, is there a documented interface to a persistence layer? Or do I have to puzzle it myself, which is possible, but I do not want to invent a wheel which is already there. As far as I am aware there is no fixed specification for a persistence layer. From a brief chat to Thomas he indicated that a variety of database styles were being used in live projects e.g traditional relational databases, 'shredded' row storage such as OpenSDE, OO databases such as db40 and cache, XML file/stream storage or newer hybrids such as Sql Server 2005. I suspect there is no correct way of doing this. It will depend on circumstances and very rapidly changing persistence options. The whole industry is moving to lessening the 'impedance' between structured OO modeled code and the underlying persistence layer and as yet there does not appear to be a single universally compelling option. yes, all the above is true. Actually, we do have the intention of publishing various persistence mappings of the reference model, but we want them to be tested first. Two that I am involved with take the approach of using a set of P_xxx classes, e.g. P_OBSERVATION, P_SECTION etc, but when you hit small objects like OBSERVATION.data (of type HISTORY), we serialise that whole field into P_OBSERVATION.data: String (really a lump of XML). So you end up with about only 10 - 15 classes to persist, which appears to work much better in hibernate than having all those fine-grained objects like HISTORY, EVENT, CLUSTER, ELEMENT, and all the DATA_VALUEs. There is never any gain in having such fine-grained objects in a persistent layer (although in some ODBs there is not much performance hit for doing it). The second exercise we are testing the use of a P_COMPOSITION class only in a .Net environment, i.e. same approach but even coarser grain. In both cases, you have to add special queryable attributes (i.e. columns) to enable querying to work. These approaches are not new of course, but I feel that we should see some of this stuff working in software before we put it out as specifications. ANyone who wants to contribute persistence mappings or schemata is welcome to do so - we will post them somewhere on the website, and when they can be validated in implementation, they will become a candidate for a more formal specification for the relevant persistence technology. - thomas
difficulties starting an implementation
Bert Verhees wrote: That is good, this means we can trust the dotnet-dll's. I already loaded them in Borland dotnet studio, and everything seems to publish itself as it should. The only thing is that seems to Eiffel publish a lot more then you programmed. I am not sure what to do with it. It looks like there is a lot of default Eiffel-code published. that is true, and I have to admit it is a real annoyance - it is due to the lack of export control in .Net - the Eiffel people discovered there is simply nothing they can connect to in .Net that will hide routines that are in fact hidden in the Eiffel environment (private or protected in the language of most developers). Must initilialize something, finalize something, I don't know. These are problems easy to overcome, a bit of documentation can make a lot of difference. agree there as well. Again, we are working on that. You can see what I mean here: http://www.rosa.nl/eiffelindelphi.gif I made a screenshot. Only the published part with red line is openehr code, as I guess. yes, that is the openEHR reference model you see there, as .Net classes. Don't you think this is a violation of OO concepts? not sure what you mean here - do you mean that more should be hidden? Apparently the lack of control in .Net prevents this. This is very good, but the features of dotnet 2.0 do not effect the openehr concepts, as for now, mathematical calculation performance of dotnet 1.1 is better then native compiled C-code, because it is compiled just before use (JIT) and against highly optimised libraries. Which not always is the case in Borland C 5.5 which Eiffel Studio uses now for Win32 platform. Dotnet 2.0 does not change that much. It adds language features and GUI-feautures. Special LINQ is a powerful new feature, but it will come in dotnet 3.0 and is only usefull in Relational DB's which we al hate and need. Knowing Microsoft it could degrade the dotnet 1.1 libraries so to push people to dotnet 2.0. Dotnet 1.1, as said is compatible with Mono, which makes it a good platform to write software in, and it supports many programming languages. I can't really comment on the above - you are in much deeper into such issues than I! Apart from the one point that being able to write generic classes in C# is a massive improvement semantically and in terms of runtime safety (and it should reduce lines of code as well). It is not that difficult to migrate from Java to C#, mostly. Just re-engineer the java-files in rose and generate C# code. You get getters and setters, maybe, I don't know, maybe rose solves that, so there will still be work to do, but it really makes a difference if the class/method-frameworks are generated. I know people say that, but I have never seen it done. It might be possible with a few core classes, but what you tend to find is that the Java people say have used Spring, Hibernate etc, and that influences the code in a certain way, and the .Net people are using say SqlServer 2005, which makes their code completely different. And a lot of it is about developer culture, what libraries they know, what frameworks etc. I don't see that much hope for much direct code translation, but will be pleasantly surprised if it happens. that is nice theory, and I wish it would work too, but the UML 2.0 meta-model is sadly quite broken and doesn't support all the semantics of all the languages. It is true that it does not support generic types (I believe, I have only experience with UML2.0 for building classes and using OCL), but if so, one can repair it does sort of, but in a broken way. (See the terrible explanation in the UML reference manual - the Booch series book, I forget the title. It's laughably bad). that by hand afterwards, just a document to mention the erreneous spots will do. Still there is a lot of work saved. And a lot of interoperability won. The adl_dotnet_lib.dll is 5 Mb. This must be because of a lot Eiffelcode from which I do not know what it serves, and why it is published. well, this includes all the Eiffel library classes, parser classes etc, garbage collector. It probably could be made smaller actually, I am surprised it is that large - we should do some investigation on it. The same library in C# would be less then 10% large. Not used code is dangerous, it can contain vulnerabilities or cause unexpected situations, one can never know, because one did not write it. Every unused line of code should be avoided. When we generate the DLL, the Eiffel environment strips out unused code. But a lot of library classes are used - hundreds. And I have to admit I don't know the size of the runtime GC part. I will ask some questions on this. It may be that we can make it smaller. These are powerful features of Eiffel, I did the comparison because I was wondering why Eiffel, but you explained. There are advantages, for sure. So maybe the
difficulties starting an implementation
Ian McNicoll MMS wrote: Hello again Rong, Glad to hear things are progressing. Do you have any thoughts about persistence layer options? Hello Ian! Well, we have been exploring the persistence layer ourself. We started with using Prevayler for our demo application, and later chose to use MySQL + Hibernate + Spring solution for our pilot system, which is the kind of persistence solution we are most familiar and experienced with. We did full OR mapping for the openEHR reference model. With the complexity of the reference model, the generated relational model is quite complex too (50+ tables). We haven't had any performance problem yet even the mapping is not fully optimized. On the other hand, we also noticed that having whole reference model fully mapped into relational model doesn't really give us the advantage of querying the data directly using SQL. Therefore, we are also considering other alternatives like the one described by Thomas which essentially only maps certain high level objects and serialize (native or XML) the rest low level objects to reduce the complexity of the relational model. Then the question is really where to set the break point. Hopefully all these early implementation experience would lead to some proven and elegant persistence solutions which can later be abstracted into future specification. In Scotland there is a hope to move to a single EHR for the whole country across all specialities. Personally I remain unconvinced that this is totally achievable, but if it is, it will demand a highly flexible and extensible architecture, backed by an equally structured complex persistence layer - the traditional relational DB will simply not work. Please keep us informed regarding this move. Regards, Rong Regards, Ian As I promised to reply to your post on the list, here I am. :) Personally I am convinced it is possible to implement the openEHR specification even at this stage. We, at Acode, already proved it by building a pilot EHR system which meets real-life requirement. Of course, it wasn't easy since we started from scratch with the Java implementation (kernel, parser, persistence, GUI), but also the specification has been a moving target. After the version 1.0 specification is released, the situation will be quite different. Since then, there won't be any major changes on the reference model which really is the foundation of interoperable EHRs. This will hopefully encourage more open source or commercial development on openEHR in the near future. Cheers,
difficulties starting an implementation
I believe that Mr. (Dr.?) Ian McNicholl is refering specifically to the fact that implementing an EHR system solely using a relational DB is what won't work. I believe he's not refering to the whole concept of OpenEHR, but just to the fact that using a traditional relational system to store information in the form of just text and make queries using one person's social security number or another means of identification is what is being dismissed as a practical solution to the problem of sharing a patient's medical information. In fact, Mr. Nicholls doubts that a single, unified system is even achievable, and that in Scotland they need just that: a single EHR for the whole country across all specialities. Correct me if I'm wrong, please, Mr. Nicholls. But the OpenEHR is clearly a step in the right direction. Cheers, JV -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060119/014789b3/attachment.html
difficulties starting an implementation
Op donderdag 19 januari 2006 11:18, schreef Rong Chen: snip I do not know if it is useable in OpenEhr context, but I like the ideas of Scott W. Ambler, he wrote a paper about persistence-layers:http://www.ambysoft.com/downloads/persistenceLayer.pdf This is about the same architecture as we used in our application. Hibernate is such a product implemented the persistence layer described in his document. In fact, the openEHR kernel is not aware of any persistence layer. The application is interacting with the service layer which uses the underlying persistence layer to perform CRUD and queries. I heard about Hibernate, there also is a dotnet version of it, called NHibernate. But besides the persistence-layer, the GUI is important, how does it connect to the kernel? I wonder. Really good news, I hope we will learn more. We are trying to build generic GUI totally driven by the domain models (archetypes). Again, as the persistence layer this is an area requires lots of exploration and experiment. Fortunately, the reference model is not dependent on either the presentation or persistence layer allowing EHR systems implemented with different GUI and persistence can interact with each other. Am I wrong when I think this will be the publishing of data to be used in a GUI, because a GUI is not only denpending on datasets, but also on usability-guidelines? -- regards Bert Verhees
difficulties starting an implementation
Hi JV, Yes I am a doctor (GP) but no longer doing clinical work. I was not saying that a relational DB would not work, just that without O-R mapping tools or Row modelling/shredding techniques, it is very difficult to support the extensibility/adaptability required by clinical systems, to cope with both inter-specialty differences and a rapidly changing domain. Archetypes provide an excellent way to model and work with these requirements in code. As a design framework OpenEHR seems to me to be on exactly the right lines. What remains unclear is the most efficient way of expressing OpenEHR concepts at persistence level. In a sense this has nothing to do with OpenEHR but it is obviously one of the trickier parts of any implementation. The Object-Relational Impedance issue is by no means unique to healthcare, and one can many attempts across the industry to allow persistence layers to easily mirror the huge advantages brought by OOP modelling and programming. My impression is that there is as yet no clear winning formula which completely reconciles the efficiency (speed and space) of traditional RDBMS design with the extensibility of object orientated methods. I am a big fan of OpenEHR but in answering Bert's original query, issues of the best way to manage persistence have yet to be resolved. In that sense OpenEHR is not as complete as he may have understood it. Ian
difficulties starting an implementation
Bert Verhees wrote: I wonder, Ian, did you ever looked to Cache (www.intersystems.com) It is called Post-relational, this is because it also can understand SQL. But it is a kind of OO-database, I don't know if it has all the OO-particularities like (multiple)inheritence, or object as field of another object. Hi Bert, I have downloaded the free product but had a configuration issue which has topped it working and just at the moment the demands of my 'real job' stops me addressing the problem or experimenting with it. Cache *seems* like an ideal solution but, of course, until one experiments a little and considers the overall cost, it is difficult to be sure. My interest stems from some consulting work I was involved with, attempting to integrate social work systems and clinical systems around Care of the Elderly standard data collection forms. The battles waged (technical and socio-political) over establishing such standards made me convinced of the need for having much more flexible ways of defining common standards. It can be very difficult to arrive at 100% agreement on form design, especially when the elements that make up the form are genuinely contentious or experimental. Far better to standardise at archetype level - that way at least 80-90% of the from will be standardised and the remainder can be handled locally, either as a local fully computable archetype or a 'foreign' archetype, which is only computable in generating some reasonably sensible text on-screen, in a similar fashion to XML/XSLT transformations. Regards, Ian
difficulties starting an implementation
Hi William, Pleased to oblige. Scottish National eHealth.IM at T strategy: http://www.ehealth.scot.nhs.uk/ Scotland is a small country pop. 5 million but which now has completely devolved powers on Health matters and our flavour of NHS now differs substantially from that in England. We have also not adopted Connecting for Health, although we hope to learn from their mistakes in due course :-) I am involved rather at the periphery of this high-level stuff but am attending a national strategy meeting tomorrow to discuss Archetypes and OpenEHR. Ian
HIT Mandates was: difficulties starting an implementation
On Thu, 2006-01-19 at 09:22 -0500, William E Hammond wrote: I am writing a paper on national mandates for HIT and on nation adoptions of the EHR. Can you point me to some documentation on Scotlands plans? Hi Ed, Additional resources that may be of help Canada Health Infoway: http://www.infoway-inforoute.ca/en/home/home_long.aspx?UID=39 Though not National the Alberta NetCare project is Province wide: http://www.albertanetcare.ca/content/about/projectsandservices.php HTH, -- Tim Cook -- 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/20060119/ce77736f/attachment.asc
difficulties starting an implementation
Dear Dr. Hammond, We now have started a very ambitious national EHR project called Turkish Health Information System which addresses nearly all aspects of the domain...I am not so sure whether it will be a success but it the current government is very serious about it and employed highly qualified professionals. There is an English document you can examine: Title: Review of and Recommended Improvements to Turkey eHealth Strategy By: Salah Mandil, Ph.D. Senior Expert Consultant on eHealth eStrategies, to the International Telecommunications Union and, Former Director Health Informatics Telematics World Health Organisation Geneva, Switzerland The pdf is at: http://www.saglik.gov.tr/eng/turkeyehealth_bu.pdf Best regards, Dr. Koray Atalag -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr- technical at openehr.org] On Behalf Of William E Hammond Sent: 19 Ocak 2006 Per?embe 16:22 To: openehr-technical at openehr.org Subject: Re: difficulties starting an implementation Ian, I am writing a paper on national mandates for HIT and on nation adoptions of the EHR. Can you point me to some documentation on Scotlands plans? Thanks Ed Hammond Ian McNicoll MMS ian at gpacc.co.uk To: openehr- technical at openehr.org Sent by:cc: owner-openehr-technical@Subject: Re: difficulties starting an implementation openehr.org 01/18/2006 03:47 PM Please respond to openehr-technical Hello again Rong, Glad to hear things are progressing. Do you have any thoughts about persistence layer options? In Scotland there is a hope to move to a single EHR for the whole country across all specialities. Personally I remain unconvinced that this is totally achievable, but if it is, it will demand a highly flexible and extensible architecture, backed by an equally structured complex persistence layer - the traditional relational DB will simply not work. Regards, Ian As I promised to reply to your post on the list, here I am. :) Personally I am convinced it is possible to implement the openEHR specification even at this stage. We, at Acode, already proved it by building a pilot EHR system which meets real-life requirement. Of course, it wasn't easy since we started from scratch with the Java implementation (kernel, parser, persistence, GUI), but also the specification has been a moving target. After the version 1.0 specification is released, the situation will be quite different. Since then, there won't be any major changes on the reference model which really is the foundation of interoperable EHRs. This will hopefully encourage more open source or commercial development on openEHR in the near future. Cheers,
HIT Mandates was: difficulties starting an implementation
Hi Ed, You likely already know about the openClinical effort to track international projects, but just in case: http://www.openclinical.org/nationalHITprogrammes.html At a recent workshop on Personal Health Records at Claremont Graduate University, Matt Holt summarized his findings on predictors of Highly Digitized Nations with an astonding level of precision and simplicity. His long list of candidate Nations showed the predictor was...IF country's first initial is N, THEN High use of Digital Health Records... My report on the Big N_Aries (New Zealand, Norway, and the Netherlands) is scheduled for completion in late summer. http://www.openclinical.org/natHITprogrammeNZ.html Cheers, Bob Smith, PhD Tall Tree Labs -Original Message- From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of William E Hammond Sent: Thursday, January 19, 2006 8:58 AM To: openehr-technical at openehr.org Subject: Re: HIT Mandates was: difficulties starting an implementation Thanks to Tim. Great things often happen through mistakes. I had meant to send the email only to Ian and did not notice that I was sending to the group. I have had several response and invite more. I am hoping to have the paper completed within 2 months. Thanks to all. Ed Tim Cook twcook at shaw.caTo: openehr-technical at openehr.org Sent by:cc: owner-openehr-technical@Subject: HIT Mandates was: difficulties starting an implementation openehr.org 01/19/2006 10:02 AM Please respond to openehr-technical On Thu, 2006-01-19 at 09:22 -0500, William E Hammond wrote: I am writing a paper on national mandates for HIT and on nation adoptions of the EHR. Can you point me to some documentation on Scotlands plans? Hi Ed, Additional resources that may be of help Canada Health Infoway: http://www.infoway-inforoute.ca/en/home/home_long.aspx?UID=39 Though not National the Alberta NetCare project is Province wide: http://www.albertanetcare.ca/content/about/projectsandservices.php HTH, -- Tim Cook (See attached file: signature.asc)
HIT Mandates was: difficulties starting an implementation
difficulties starting an implementation
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060118/cdefb747/attachment.html
difficulties starting an implementation
Op woensdag 18 januari 2006 01:16, schreef Sebastian Garde: Hi Bert, the way I understand the differences between openSDE and openEHR: Thanks, Sebastian, really helpful answer, gives something to think of Regards Bert Verhees
difficulties starting an implementation
Bert Verhees wrote:
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.
In Eiffel you can do what you want, but you normally publish attributes
and setter routines. Getter and setter routines are bad programming
practice, since they destroy any proper connection of the code with a
model. For example if the model is (pascal-style):
class PERSON
name: String
end
then you can just add the setter to the class to have an operational class:
class PERSON
name: String
set_name(a_str: String) is
do
end
end
But with the getter/setter style you end up with classes like:
class PERSON
get_name: String is
do
end
set_name(a_str: String) is
do
end
end
which is ridiculous in terms of modelling - there is no sensible
property of a PERSON called a get_name. Sadly this kind of programming
has become commonplace.
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++ ;-)
even I can understand it
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.
not sure what you mean here. All our Eiffel implementations are complete
implementations. We haven't finished the kernel (at all) but the ADL
parser is interfaces with code behind that compiles to a running tool,
including GUI (the ADL workbench is 100% Eiffel code).
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.
well that's true, but they wouldn't normally bother to generate a DLL
and publish it - there would be no point.
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.
technically, that is true, but no-one I know does that. We only generate
DLLs or other executables when they actually do something. Otherwise, we
just build test programs to test the classes. That's how we know the
openEHR models are valid - they are always tested in Eiffel. We couldn't
do that in other languages because we would have to mangle the model so
much just to get it expressed that we wouldn't be validating the model,
we would be validating a -implementation of it.
This doesn't mean you can't write good (or even great) software in any
other language - you can - it's just that that software will be a
certain transform from the original model, and some parts of the
transform are human-determined, due to limitations of the various
languages (e.g., lack of genericity in both Java and C# until recently).
Then I understand that the Eiffel-code
difficulties starting an implementation
Hi,
It seems to me you are turning around a really subtle and complex concept.
Like a building, information systems must have some hard parts (to stand
up) and a flexible content (so you can live in it).
The usual way is to have the hard parts being whether a database model
or some pieces of code, or the both of them. The flexibility is very
low, and I am used to saying that these systems can only tell one story,
but it is neat and usual for programmers.
Now comes the 2 levels systems, where what can be told is not mixed
with what can tell it.
Some examples of components of the kind I have been working on :
- Archetypes, of course, to separate the data model from the code and
the database
- Data querying, with such tools as the Pilot that uses XML scripts to
describe a query workflow, instead of hard programming SQL or Corba or
Web services connectors
- Security components, with such a project as MP6 where the rules are
expressed in a predicate language with a genuine abstraction from the
software code
One of the key advantage (among many others) of these 2 levels systems
is that we can build proof components for the model itself and not
just test if the software is bug free. This is the genuine hard part
of our modern buildings.
Thomas is trying to express that Eiffel is not used as a programing
language here (even if it could be, but it can be confusing) but as a
way to express and validate some concepts.
However, living in Paris, I can assess that Eiffel is such a good
programing language that we have here a quite impressive monument raised
to glorify it. And we don't have any Java tower or C++ tower or any
other tower of the kind.
Cheers,
Philippe
Thomas Beale a ?crit :
Bert Verhees wrote:
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.
In Eiffel you can do what you want, but you normally publish
attributes and setter routines. Getter and setter routines are bad
programming practice, since they destroy any proper connection of the
code with a model. For example if the model is (pascal-style):
class PERSON
name: String
end
then you can just add the setter to the class to have an operational
class:
class PERSON
name: String
set_name(a_str: String) is
do
end
end
But with the getter/setter style you end up with classes like:
class PERSON
get_name: String is
do
end
set_name(a_str: String) is
do
end
end
which is ridiculous in terms of modelling - there is no sensible
property of a PERSON called a get_name. Sadly this kind of
programming has become commonplace.
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++ ;-)
even I can understand it
const BRITISH = 0;
const OTHER=1;
class Person{
publicproperty bodyLength:Integer read getLength;
public property Local write setLocal;
privatefunction getLength:Integer;
private procedure setLocal(value:Integer);
privatefLength:Integer;
privatefLocal: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
difficulties starting an implementation
Op woensdag 18 januari 2006 17:10, schreef Ian McNicoll MMS: Either there is a documented interface to a persistence layer, or there isn't. It is quite possible I missed it in the documentations But till now, I asked it three times in three days, is there a documented interface to a persistence layer? Or do I have to puzzle it myself, which is possible, but I do not want to invent a wheel which is already there. As far as I am aware there is no fixed specification for a persistence layer. From a brief chat to Thomas he indicated that a variety of database styles were being used in live projects e.g traditional relational databases, 'shredded' row storage such as OpenSDE, OO databases such as db40 and cache, XML file/stream storage or newer hybrids such as Sql Server 2005. Thanks Ian, thanks very much, for your clear answer. When there will come no further mails which state different, I take your answer for truth. I guess I have to write it myself, or get help from people which already did. The row-storage as from OpenSDE looks as a good solution. But when this is true, and also what you state below, this means that there is still a long way to go for OpenEhr before it will be implementable. Is that true? Do I understand that well? regards Bert Verhees I suspect there is no correct way of doing this. It will depend on circumstances and very rapidly changing persistence options. The whole industry is moving to lessening the 'impedance' between structured OO modeled code and the underlying persistence layer and as yet there does not appear to be a single universally compelling option. Ian
difficulties starting an implementation
On Wed, 2006-01-18 at 17:20 +0100, Bert Verhees wrote: Thanks Ian, thanks very much, for your clear answer. When there will come no further mails which state different, I take your answer for truth. I guess I have to write it myself, or get help from people which already did. The row-storage as from OpenSDE looks as a good solution. But when this is true, and also what you state below, this means that there is still a long way to go for OpenEhr before it will be implementable. Is that true? Do I understand that well? Hi Bert, I think you are still a bit confused about What is OpenEHR? See the FAQ: http://openehr.org/FAQs/t_about_FAQ.htm OpenEHR is (essentially) a non-profit organization that produces specifications for an electronic health record. The specifications are implementation generic documents. Eiffel is used as the reference platform in order to prove that the model actually is implementable (at a class level). The questions you are asking are implementation specific. I suggested once before that you might join the implementers mailing list. Granted there is much traffic there right now but really that is where these discussion would make more sense. http://openehr.org/advice/contents.html Not to say that they are not supposed to be here on the technical list. The description does still specify software building. But on the implementers list you could address the fact that you want help/collaboration with developers using Java, Hibernate and MySQL (if those are your choices) to implement an OpenEHR server. Again, it will help you if you separate the concepts of the generic model and the implementations. Hope this helps. Cheers, -- Tim Cook -- 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/20060118/10332461/attachment.asc
difficulties starting an implementation
Bert Verhees wrote: Op woensdag 18 januari 2006 17:10, schreef Ian McNicoll MMS: Either there is a documented interface to a persistence layer, or there isn't. It is quite possible I missed it in the documentations But till now, I asked it three times in three days, is there a documented interface to a persistence layer? Or do I have to puzzle it myself, which is possible, but I do not want to invent a wheel which is already there. As far as I am aware there is no fixed specification for a persistence layer. From a brief chat to Thomas he indicated that a variety of database styles were being used in live projects e.g traditional relational databases, 'shredded' row storage such as OpenSDE, OO databases such as db40 and cache, XML file/stream storage or newer hybrids such as Sql Server 2005. Thanks Ian, thanks very much, for your clear answer. When there will come no further mails which state different, I take your answer for truth. I guess I have to write it myself, or get help from people which already did. The row-storage as from OpenSDE looks as a good solution. But when this is true, and also what you state below, this means that there is still a long way to go for OpenEhr before it will be implementable. Hi Bert, As I promised to reply to your post on the list, here I am. :) Personally I am convinced it is possible to implement the openEHR specification even at this stage. We, at Acode, already proved it by building a pilot EHR system which meets real-life requirement. Of course, it wasn't easy since we started from scratch with the Java implementation (kernel, parser, persistence, GUI), but also the specification has been a moving target. After the version 1.0 specification is released, the situation will be quite different. Since then, there won't be any major changes on the reference model which really is the foundation of interoperable EHRs. This will hopefully encourage more open source or commercial development on openEHR in the near future. Cheers, Rong Is that true? Do I understand that well? regards Bert Verhees I suspect there is no correct way of doing this. It will depend on circumstances and very rapidly changing persistence options. The whole industry is moving to lessening the 'impedance' between structured OO modeled code and the underlying persistence layer and as yet there does not appear to be a single universally compelling option. Ian
difficulties starting an implementation
Tim Cook wrote: Hi Bert, I think you are still a bit confused about What is OpenEHR? See the FAQ: http://openehr.org/FAQs/t_about_FAQ.htm OpenEHR is (essentially) a non-profit organization that produces specifications for an electronic health record. The specifications are implementation generic documents. Maybe I am a bit confused, but I wrote two days ago, that OpenEhr was more an OpenConcept-project, instead of an OpenSource-project. There I was right, isn't it. Eiffel is used as the reference platform in order to prove that the model actually is implementable (at a class level). The questions you are asking are implementation specific. I suggested once before that you might join the implementers mailing list. Granted there is much traffic there right now but really that is where these discussion would make more sense. http://openehr.org/advice/contents.html Not to say that they are not supposed to be here on the technical list. The description does still specify software building. But on the implementers list you could address the fact that you want help/collaboration with developers using Java, Hibernate and MySQL (if those are your choices) to implement an OpenEHR server. I would be glad to work together with others, if possible. I am subscribed to the implementer list, but I never received one mail from that list. I looked in the archives, and the last message was from september last year (4 months ago). I am afraid not may people read my messages then, and it is more difficult to get the informations I need. offtopic It reminds me of a Linux list where they wanted to get all technical messages in a special list, and all association related messages to the main list. It didn't work, because no-one was reading the technical list, and all messages in the main list got the attentention, so people only interested only in association-news had to read their mail with a finger on the delete-button /offtopic regards bert verhees
difficulties starting an implementation
Gerard Freriks wrote: Bert, ITS = Implementable Technology Specification. It is an HL7 specific term. It is the process that translates an hierargical message specification of a domain information model into: Edifact, HL7v2, XML (HL7v3), or Java formats. I don't know whether they invented it or not, but it isn't HL7-specific in the sense of only being meaningful for HL7 specifications - it's very general idea. We try to re-use terms where they make sense rather than invent competing ones... - thomas
difficulties starting an implementation
Bert Verhees wrote: but as I see, there are very impressive projects in the deploymentsector on the website. They must have used databases, other programming languages, UML created, component-interfaces, plans about how to follow the OpenEhr-developments. F.e. it does not seem effici?nt to me to rewrite the codebase in C#, java, whatever, by hand when the OpenEhr defintions changes signicantly. Release 1.0 is intended to be the end of significant changes. Only error corrections and some additions, but no other changes will be allowed to that release after it is published. Other enhancements will go in later releases. But we expect Release 1.0 to be extremely stable. It would be very nice if those people would share what they know, and discovered. I am not asking them to publish their commercial-product code. well, maybe people asking them on these lists will help... I guess, we must regard toEiffel in OpenEhr-context as a case-tool, not as a programming-environment, because both serve another purpose, and one must be able to distinguish the two. So if the Eiffelcode must be regarded as a product of a case-tool. I must say, I like XMI better. I understand, Thomas likes working with Eiffel, many people have their tools, Thomas has Eiffel. We need a bridge between Thomas his favorite tool and more common case tools, so code can be generated for many other environments. 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 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 ListString. 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 not implement object-oriented modelling ideas properly. They are mostly tied to particular programing langaugues, so that it is difficult to create formal abstract models. And the details are all different in each target programming language. We also investigated the XML-schema and Java output, and there were major errors, due in my opinion to wrong design in the tool, not bugs. We tried to get the manufacturers interested in correcting these, but they have not so far shown any interest. I guess they can still sell lots of copies to people who don't understand the issues. - thomas beale
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
difficulties starting an implementation
(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 onI think the resulting top level Findings of Upper GIS Examination Archetype should have features like History, Event Series, Protocol and so onBut 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
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
difficulties starting an implementation
Tim Cook wrote: On Wed, 2005-09-21 at 23:07 +0200, Bert Verhees wrote: Please correct me if I am wrong, Please take it as a request for information, or if I am wrong and need to be corrected, as a discussion. If you go here: http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/index.html and scroll down a bit you will notice that the kind folks at ACODE have contributed a Java ITS. HTH, Yes, I have seen that, Tim, thanks for pointing me to it. It is very good done, I believe Acode understands very well the needs of an opensource project, but, at this moment, for me, it is not yet much to start working with. Implementing an OpenEhr-solution would still cost multiple man-years. I guess, many things I will write below, I already said in other emails, maybe in slightly different context. I apologise for repeating myself I hope this is the last time I will broe this public with my repeating questions and statements and (sometimes wild) geussing And I do not want to blame somebody for something, but as I see, there are very impressive projects in the deploymentsector on the website. They must have used databases, other programming languages, UML created, component-interfaces, plans about how to follow the OpenEhr-developments. F.e. it does not seem effici?nt to me to rewrite the codebase in C#, java, whatever, by hand when the OpenEhr defintions changes signicantly. It would be very nice if those people would share what they know, and discovered. I am not asking them to publish their commercial-product code. I guess, we must regard toEiffel in OpenEhr-context as a case-tool, not as a programming-environment, because both serve another purpose, and one must be able to distinguish the two. So if the Eiffelcode must be regarded as a product of a case-tool. I must say, I like XMI better. I understand, Thomas likes working with Eiffel, many people have their tools, Thomas has Eiffel. We need a bridge between Thomas his favorite tool and more common case tools, so code can be generated for many other environments. 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? Many questions, I would be really pleased if I would find answers, which make the fantastic concept, which OpenEhr is, useable for me. I think I have to wait another year before I can really use it. Kind regards Bert Verhees
difficulties starting an implementation
Hi all, Some reders of this list have seen me before, I was implementing a part of the GPICs-environment, about a year ago. I do not do that anymore, the project stopped, it is regarded as finished. I am now studying OpenEhr for a new project. I spent yesterday all day on looking at the sourcecode in Java. Thanks for the good work from Sweden, sourcecode in Eiffel for me is difficult to read. For example, I had many problems using the EiffelStudio, doing a simple thing like opening a sourcefile is very difficult in that IDE, though I am used to many IDE's. There must be some way somewhere to do that simply. Anyway, it doesn't matter, I have Java-sourcefiles. Which is a very good thing I created javadocs, to make it better accessable for reading. I know, many people spent a lot of time in writing a lot of documentation, which is very helpful, There maybe is only one part in the documentation missing, I will explain what I need below: -- I understand globally how the thing works, but I need a detailed view about how it really really works. How the specific classes are involved in the functionality. For example, which classes do the database handling, which classes do archetype-parsing, which classes are to be used in/connect to a client application, etc, etc. What I really could use at this stage of studying the project are UML-diagrams, and it this special moment, I really would want to have Sequence Diagrams and Use Case diagrams. I can create them myself, no problem, within two weeks or less I have those diagrams and most of the comprehension and knowledge I need. Specially this would work like that if someone would pay me to do so, which is unfortunately not the case. Maybe I do it anyway, not today, but for free, and for my own understanding, and publish them for other people in a similar a (OpenEher-newbie) position as I am now. If it makes sense in my further plans to spent time on this (still working with OpenEhr). Life is short. But maybe someone else already spent time on this? They diagrams do not need to be accurate, a bit outdated is no problem. So, I come to my questions: Are there any UML-diagrams? Which documents should I read (first) to understand the way the thing works (technical) Thanks very much for reading. I will really appreciate any help. You can also write to me personally, or to the list, whatever you prefer -- Kind regards Bert Verhees
difficulties starting an implementation
On Fri, 2006-01-13 at 10:07 +0100, Bert Verhees wrote: I am now studying OpenEhr for a new project. ... Which documents should I read (first) to understand the way the thing works (technical) This won't help with the details of a specific implementation but it's stuff you need to know. http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/index.html First read the documents under 'Guides', in order. Then move on to the 'Architecture' documents; Data Types, Data Structures, Common, Support, EHR, EHR Extract, Demographics. Join the Implementers mailing list. HTH, -- Tim Cook -- 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/20060113/ac7b413a/attachment.asc
difficulties starting an implementation
Op vrijdag 13 januari 2006 16:13, schreef Tim Cook: On Fri, 2006-01-13 at 10:07 +0100, Bert Verhees wrote: I am now studying OpenEhr for a new project. ... Which documents should I read (first) to understand the way the thing works (technical) This won't help with the details of a specific implementation but it's stuff you need to know. http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publish ing/index.html Thanks, I really was looking to the wrong version documents, I am not that used to SVN, I thought the trunc-version was the latest version, which it is not, never too old to learn Because of that I was missing some essentials. I hope that this version makes all clear. regards Bert Verhees
difficulties starting an implementation
While reading the docs, I stumble on the acronym ITSs. It may not be that important, but I want to know, what does it mean, I searched on www.acronyms.ch and found: Incompatible Time-sharing System Can someone tell me what it really means, thank you regards Bert Verhees
difficulties starting an implementation
Bert, ITS = Implementable Technology Specification. It is an HL7 specific term. It is the process that translates an hierargical message specification of a domain information model into: Edifact, HL7v2, XML (HL7v3), or Java formats. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 13-jan-2006, at 17:53, Bert Verhees wrote: While reading the docs, I stumble on the acronym ITSs. It may not be that important, but I want to know, what does it mean, I searched on www.acronyms.ch and found: Incompatible Time-sharing System Can someone tell me what it really means, thank you regards Bert Verhees -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060113/865139bb/attachment.html
difficulties starting an implementation
On Wed, 2005-09-21 at 23:07 +0200, Bert Verhees wrote: Please correct me if I am wrong, Please take it as a request for information, or if I am wrong and need to be corrected, as a discussion. If you go here: http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/index.html and scroll down a bit you will notice that the kind folks at ACODE have contributed a Java ITS. HTH, -- Tim Cook -- 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/20060113/d4613928/attachment.asc
difficulties starting an implementation
Please correct me if I am wrong, Please take it as a request for information, or if I am wrong and need to be corrected, as a discussion. I will do a few statements about what I have seen around the openehr-website - The folder in the RC 1 for ITS is a bit empty. No database-definitions, no languages specific information, no distribution-formalism. As the roadmap-document explains, this will be taken care of, but has not yet happened. - 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. - 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. 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. - 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. - Are there any known closed source implementations which run fine? - 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. This are very important things for me to realize, because it means, if I am right, there is no way now to implement openehr in a live application open source or commercial for low cost.. Building an implementation at this stage means one has to rebuild the complete system, and in this way contribute to the ITS-part of the specs. Maybe a tool can be build which generates C# and Java from Eiffel-code, but for now, that is not the case. Keeping up with the formal definitions is a matter of re-typing the sources and guarding the developments very well. When this is true, it is, sadly, not suitable for the project I am thinking of. There is not a lot of money to help build a system on a uncertain and lengthly time-schedule. In this way, if I am right the promise of a low maintenance EPD is not yet forfilled. But the possibilty exist then I am really missing important parts which prove that I am very (or a bit) wrong, and it is very well possible at this moment to build a low cost implementation for a project which has to be up and running in a few months. If this is the case, I can donate my thinkings and workings back to the project. Code written in other languages, db-schema's, interface-schemas, etc. Please comment to this!! Next monday I have to report on my findings Thanks Bert Verhees
