Hi Pablo, I agree with you re the indirect use of IM. I don't necessarily see a big problem with this paper's approach because every approach has its downsides. In fact, some really successful projects and products are built on designs that are shunned by the "collective wisdom" of academia and engineering communities, but they work, they do the job, and most important of all, the cost of dealing with design related issues is acceptable, given the expectations from the system. This is the key: what is the expectation? What defines success in an openEHR implementation? It is very context specific, with human, institutional and other factors having their effect on technical factors. I'm not saying that you're suggesting anything on the contrary, just trying to make a point that this is an implementation that made it to a functioning state and many factors in that process is unknown to us. The authors may not even be able to share those factors. If my memory is correct, when I read this paper some time ago, it mentioned an earlier study, probably by the same group, but I could not access it. That'd be interesting to read as well.
On Tue, Jan 26, 2016 at 1:52 AM, pablo pazos <pazospa...@hotmail.com> wrote: > ORM is not a problem with current tools. In fact frameworks like Hibernate > and Grails make Object-Relational Mapping something enjoyable to work with. > I think the problem with the described approach is the growth of the > relational schema when your knowledge base grows. > > But there are design challenges, ORM doesn't solve all the problems > itself. IMHO, the object model that should be mapped to relational, if > relational is chosen as DBMS, is not the raw openEHR IM. Simplifications > over the IM are needed in order to prevent excessive JOINs and huge > hierarchies. In fact I teach this in one of my courses and this was part of > the tutorial we did on MEDINFO. For example, the OBJECT_REFs can be > designed as simple relationships, because plays the role of a FK in the > object model. There are many simplifications that can be done to reach an > object model that is compatible with the openEHR model but more "relational > friendly". > > -- > Kind regards, > Eng. Pablo Pazos Gutiérrez > http://cabolabs.com <http://cabolabs.com/es/home> > <http://twitter.com/ppazos> > > ------------------------------ > Date: Mon, 25 Jan 2016 18:42:01 +0100 > Subject: Re: Archetype relational mapping - a practical openEHR > persistence solution > From: bert.verh...@rosa.nl > To: openehr-technical@lists.openehr.org > > > Another problem is you have to convert your object oriented model (which > RM is) to a relational model, which becomes complex in converting > templates/aql to SQL. I have been that way. More then five years ago I left > it. It is difficult doable, if you want a full featured openehr kernel. I > would never recommend going this way, unless someone has a really smart > idea. > > It can work for a light featured openehr light derived application model. > > Best regards > Bert > Op 25 jan. 2016 15:26 schreef "pazospa...@hotmail.com" < > pazospa...@hotmail.com>: > > I talked about this approach with a colleague from China during MEDINFO. > The problem is your schema grows with your archetypes. Also, that storing > data from many templates that don't use all the fields in the archetype, > will generate sparse tables (lots of null columns). I told him it was > easier to do an ORM from the IM, because the schema doesn't change and > allows to store data from any archetype/template. But they already have a > system working this way. > > > Sent from my LG Mobile > > ------ Original message------ > > *From: *Ian McNicoll > > *Date: *Mon, Jan 25, 2016 10:06 > > *To: *For openEHR technical discussions; > > *Subject:*Archetype relational mapping - a practical openEHR persistence > solution > Interesting paper from China > > > http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0 > > Ian > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > _______________________________________________ openEHR-technical mailing > list openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
