What Pablo is doing in his redesign is precisely the way I think openEHR implementations should be tackled. As far as I can infer, the openEHR model could be best described as sort of a business layer model. Some of its classes (generally speaking, the ?structure classes?) should be represented in an almost ?as-is? manner in the DB backend (with adequate management, of course, of the impedance mismatch problems issues associated with ORM). Regarding ?content structures?, these could be persisted as ?objects? in ad hoc field in the database. Before openEHR, and in a model somehow similar to openEHR we had designed, we persisted these complex structures as XML data in XML fields (in Oracle or SQLServer) or (huge) text fields (in MySQL or Postgres). Unfortunately, in my experience at least, indexing these fields (and making them performant) can be a real nuisance with native tools provided by commercial databases (for example, the SQL Server XML API is, IMHO, too complex and not too efficient). Probably that?s where there is most room for improvement in openEHR implementations, as I feel that that is where performance problems could arise. Regarding EAV approaches, if I properly understood the discussion taking place here (implementing EAV at the database level), I believe it should be used only in some exceptional cases. Although EAV models can be made performant by adding hardware, clustering and optimizing the database (something which, BTW, cannot be done with all databases), I feel it is intrinsically underperformant.
From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Tuesday, June 07, 2011 12:22 PM To: openehr technical Subject: RE: Dual Model EHR implementation I agree with Alan. In OpenEHR-Gen, we have modeled almost all the classes between Folder and Datatypes (Folder, Composition, Section, Entry, Item, DvText, etc) and represented all those concepts in our DB schema. Here you can find our data model: http://code.google.com/p/open-ehr-gen-framework/downloads/detail?name=model. png I think my friend Alan refer to our implementation of the OpenEHR-Gen Framework, that automaticaly generates the DB Schema from the Reference Model classes we programed in Grails Framework (http://www.grails.org/). Grails have a great ORM tool (Object-Relational Mapping, this is diferent to the ORM mentioned by Alan). Through this experience, we have seen that this complex structured model have some shortcomings on performance, but it do not take hours or minutes to complete tasks like data binding and saving or data querying, and this can be boosted by good servers, fast disks and a good DBMS. What we are doing now is redesigning the data model, dividing the classes in two groups, one groups just for structure classes, and the second group for content classes. The first group have the classes that are part of the structure but don't have clinical content, like Section or Cluster. The second group have the clinical/demographic content like Element or Composition. Then can infer the "structure classes" from an archetype, we may not include them into the persistent model, so we'll model only the content classes, and add some metainfo to help reconstruct the complete RM structure as if it has been persisted on the database. So, in the persistent layer we'll have: archetypes, a reduced persistent RM, and metadata. This will be the next step in our open source project. Hope that helps. -- 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: Dual Model EHR implementation Date: Fri, 3 Jun 2011 11:24:04 -0300 Hi all. IMHO the best approach (or at least what I have done and feel is reasonable) is to take only some of the classes in the reference model and represent them in the database. I have seen some implementations which adopt an automatic code generation approach, direct from the reference model. But that builds certain structures into the database which are unnecessary and/or may hinder performance. When analyzing the openEHR it seems to me it was not conceived with its database implementation in mind (which is an absolutely reasonable approach). The way information is persisted, I guess, is left to implementators and I believe that is probably Alberto?s issue. To solve the multiple database problem, the structure openEHR database structure could be designed using ORM tools such as that in http://www.ormfoundation.org (again, that is what I have used). I agree that archetypes should pose no performance problem at the database level if care is exercised no to try to represent them in the database. In the final analysis, it seems to me that that is what openEHR is all about: separating (represented, archetyped) knowledge from the (storage) structure From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Alberto Moreno Conde Sent: Friday, June 03, 2011 9:28 AM To: For openEHR technical discussions Subject: Dual Model EHR implementation Dear all, Within the Virgen del Rocio University Hospital we are analysing how to implement a EHR based on Dual Model Approach. When we analysed direct implementation a database based on of either OpenEHR Reference Model or ISO 13606, we have detected that it could have slow performance . Given that we are concerned about this problem, we would like to know possible strategies have been identified by implementers in order to fasten the performance of storage and query. Also the granularity level is one open issue that impacts on the performance, I would like to know if the level of granularity of the archetypes contained within the OpenEHR CKM is able to satisfy the requirements of an EHR with more than 1 million records. Kind Regards Alberto Alberto Moreno Conde GIT-Grupo de Innovaci?n Tecnol?gica Hospital Universitario Virgen del Roc?o Edif. Centro de Documentaci?n Cl?nica Avanzada Av. Manuel Siurot, s/n. C.P.: 41013 SEVILLA _______________________________________________ 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/20110607/df7c6243/attachment.html>
