Anyone knows where i can find instance examples of Compositions? Thanks,
*M?rcio Costa* B.Sc. in Computer Science @ Cin/UFPE M.Sc. Candidate in Computer Science @ CIn/UFPE MSN: mdckoury at gmail.com 2012/2/24 Randolph Neall <randy.neall at veriquant.com> > 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 >> >> > > _______________________________________________ > 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/20120225/9e80be3d/attachment.html>
