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 > > > > On Wed, Feb 22, 2012 at 11:18 AM, pablo pazos <pazospablo at > hotmail.com>wrote: > > Hi Randolph, > > I've commented between your lines. > > > -- > 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 <http://twitter.com/ppazos> > > ------------------------------ > Hi Pablo, > > I'm sorry for being so slow responding to your questions. I may not be > understanding you fully, nor have I made myself totally clear to you. > First, a DLL is a file system file known as a Dynamic Link Library, a unit > of compiled machine-executable code, typically invoked from a computer code > file with a .EXE extension or from another DLL file, with a .DLL file name > extension. These naming conventions are used by Microsoft Windows programs, > but may not be used by other platforms, which which I am unfamiliar. > > Of course, but in these context I rather prefer to give platform > independent answers :D > > > The ORM approach, as you describe it (correct me if I'm wrong), involves > the creation of specific classes, expressed as compileable source code, and > which therefore end up baked into the executable code files (EXE, DLL, or > whatever the equivalent is called on your chosen platform). I am not sure > how automated this process actually is in your OpenEHR context. Are you, > for instance, able to download an archetype from the OpenEHR web site, > press one button in your ORM, and thereby generate a class in your source > code, which is then compiled into machine code (in something like a DLL)? > And then, after that, with another push of a button, does a schema > magically materialize, matching your auto-generated classes? If so, that's > wonderful. > > Yes, you can download and configure and archetype in the system and the > system will generate the GUI. We don't need to generate classes for these > arcehtypes. The openEHR RM is implemented and it's persistent (I mean you > don't need more classes than the RM, that's the point of using a reference > model). The ORM persists the openEHR RM clases, and a binding component > creates RM instances from user input data. > So, there is no class generation and no compilation here. > The schema is generated when you start the server, so all the process is > automatic, and no need to generated or regenerate classes. The only thing > that needs (re)generation is the GUI (just html files). > > > But I have a concern that has nothing to do with automation, and which > could actually be *aggravated* by automation. However automated the class > or schema generation is or isn't, and no matter which process comes first > (generating the classes or generating the schema), and no matter which > process is dependent on the other, you still end up with both a schema and > compiled code that will expand with each new class that you create. > > As I explained, that's not the case: no new code needed and no new schema > generation needed to support new archetypes. Code and schemas are fixed. > (don't take me wrong, I think you are attached to some technology or > solution that is completely diferent of what we tried to implement). > > > That's what I mean by "hard-wired." You can do a lot of hard-wired > stuff very fast via ORM code or schema generation automation. Your DLLs (or > whatever your equivalent is) will expand in size and number. Your schema > will grow in size and complexity in direct proportion to the number of > classes it is trying to persist. You don't feel the pain, however, because > the computer did it all (or a lot of it) for you. > > Nope, no expansion of code here, only explansion of the config file and > the knowledge base (archetypes and templates). > You can see the code here: > http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen<http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen> > > > But you're still left with an end product (consisting of schema and > compiled code) that will bloat with each new thing it is designed to > express, manage, present and store. That process can go on for a very long > time, yes, but it can't go on forever. And the human body, with all the > things that can go wrong with that body, ultimately requires thousands, > maybe tens of thousands, of classes to describe just what can go wrong with > the nervous system, to say nothing of the rest. > > It seems to me that the better solution would be to develop a > metadata-based system capable of describing all that must be expressed, > allowing both schema and program code to remain unchanged while presenting > to the user information of which the compiled code and schema are both > essentially ignorant. In other words, neither the program code nor your > schema has any awareness of particular structures of medical information. > All of that is instead in the metadata, not schema, in the metadata, not > classes. > > *That's exactly what we have done! :D* > I'm sorry if I didn't explain it correctly. The design is based on this > principle: none dependency to custom domain information on the system > backend, that dependency is only on the GUI side (the only thing we need to > generate). > > My mistake in all this may be that I am mentally associating "classes" > with source code that ends up as compiled code, but maybe you mean > something else by your OOP terminology, something more akin to metadata > that never gets baked in to the machine code. But I don't think I've > misunderstood your concept of a schema. > > I had all along thought that OpenEHR was intended to operate in precisely > the way I have described, as a basis for expressing complex information > with simple schema and source code, neither of which embody, in hard-wired > form, particular medical information structures. Your description of ORM > seems to me to mean something else. If I'm wrong, I certainly apologize. > > Thanks, > > Randy Neall > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > _______________________________________________ openEHR-technical mailing > list openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120223/eaa411e4/attachment.html>
