openEHR - Persistence of Data

Technical (archive)
21

Pablo,

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.

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.

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.

Am I correct that GUI generation, the one thing you say you do generate, is simply a matter of generating html?

Thanks very much!

Randy Neall

22

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

23

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

24

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@gmail.com

2012/2/24 Randolph Neall <randy.neall@veriquant.com>

25

Hi Randolph,

My answer was bounced by the list manager, I tried to send an attachment with the current DB schema :frowning:

Anyway, this schema is generated on the startup of the server, so anybody that download and test the framework could generate the schema and see how information is stored, but remember: this is automatically generated by the ORM, so is better to understand the class model first.

26

Boa tarde Marcio,
Marquei com você e realmente tive demandas aqui no CESAR e não consegui ir, por isso gostaria de remarcar com você ai no CIN uma reunião para convesarmos sobre Arquetypes, tenho algumas dúvidas e também algum conhecimento, talvez possamos trocar informações, pode ser amanhã as 15:30 ai ni CIN, você me aguardaria lá na entrada principal, pode ser?

2012/2/16 Márcio Costa <mdckoury@gmail.com>