Hi Randolph, My answer was bounced by the list manager, I tried to send an attachment with the current DB schema :( Anyway, this schema is generated on the startup of the server, so anybody that download and test the framework could generate the schema and see how information is stored, but remember: this is automatically generated by the ORM, so is better to understand the class model first.
-- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: [email protected] To: openehr-technical at openehr.org Subject: RE: openEHR - Persistence of Data Date: Fri, 24 Feb 2012 07:45:10 -0300 Hi Randolph, I'm on travel but you can see the model.png here http://code.google.com/p/open-ehr-gen-framework/downloads/list to get an idea of the RM classes we implemented.This has changed a little because of bug fixes and added support to other functionalities. Attached is the schema of the current DB. Maybe later I can give you more detail. Thank you for your interest in the project. Date: Thu, 23 Feb 2012 22:09:34 -0500 Subject: Re: openEHR - Persistence of Data From: [email protected] To: openehr-technical at openehr.org Thank you, Pablo. I spent some time with your Grail reference. It looks like a very robust tool! Can I ask how complex your schema is? How many tables (or representations of classes) and how complex the relations are? And can you give some indication of the sheer size of your production DB? I'm curious what a Grail schema would look like capable of OpenEHR, and how large the data capacity can be, how well it scales. I will have to review again what is involved with your Reference Model, something I did some years ago, but have forgotten. Ultimately, the actual information described by specific archetypes (which are themselves a kind of "class" OOP system, right?) must be sent to the database. My understanding was that at that level some, if not most, OpenEHR implementations were using XML or some sort of "blob" rather than discrete rows and columns. Not so with you and Grail? The more I think about this, the more I'd be interested in your schema. Do you mean to tell me that with your implementation you do not persist the final level of archtyped data in document representations like XML nor do you use BLOBS whose internals cannot be queried directly by the DBMS? If so, this would be dramatically different from what I've understood (perhaps mistakenly) Thomas Beale to describe. Do you really have everything in formal DB rows and columns? You might not want to publicize your schema; it would be enough for me to know whether or not you manage to get everything into DB tables, straight from Grail objects. Thanks again! Randolph Neall On Wed, Feb 22, 2012 at 7:22 PM, pablo pazos <pazospablo at hotmail.com> wrote: Hi Randolph, OK, what you say is reassuring. One of the things I had admired about OpenEHR was what I thought you were violating with ORM, which, in many contexts does exactly what I described, but evidently not in yours. That depends on each implementation, we decided to implement the RM as close as possible to the specs. The ORM tool does the heavy work managing all the SQL stuff (we don't write SQL we do object-oriented queries using a criteria API http://grails.org/doc/1.0.x/guide/5.%20Object%20Relational%20Mapping%20(GORM).html). >The schema is generated when you start the server, so all the process is >automatic, and no need to generated or regenerate classes. I don't quite understand why a schema would be generated when the server starts if the schema does not change relative to domain-specific content. But this is a minor point, something I don't need to understand. That's the way the framework works (http://grails.org/). But I must specify that the schema is generated when the server starts when you are in "DEVELOPMENT" mode. In "PRODUCTION" mode, this schema generation is done the first time you deploy the application on an application server. But this is just how the tool we choose work... Also, your "classes" are themselves apparently quite abstract, allowing all kinds of content to be housed in them, thus reducing the number of classes to some maneagable number. Nope, we have RM classes and framework classes that handle all the logic. There is one class implemented in EHRGen by each class on the openEHR RM specs (or at least it should). So, no abstract classes here ("abstract" in OO has other meaning), only classes straight from the specs, this is a considerable quantity but it's a fixed number (not growing). You can see the classes in our SVN repo. We had around 80+ classes implemented from the openEHR RM specs. Now we don't support classes like EHR, EHR_STATUS, LINK and some others, but we plan to do it. Those are no needed for a small EMR system. Am I correct that GUI generation, the one thing you say you do generate, is simply a matter of generating html? Yep, just html with forms for data entry, and labels for data display. If you are interested in the project, you could download and try it and you'll see the things I told you here (an image is better than a thousand words :D) Kind regards, Pablo. Thanks very much! Randy Neall -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120227/8e0cd57c/attachment.html>
