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 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120222/ed849bf9/attachment.html>
