Randolph & Alan, In our approach we will give a shot to store the group of "structure classes" I mentioned before, directly on a relational DB, in an atomic way (we will have tables and columns to each field, not a blob to store all the structure). With this approach I think we can boost performance about 70%, the big bottleneck in our implementation is de dynamic data binding (put data input from a user in a RM structure), and with this improvements, 1. this logic will be much more simple, 2. the DB schema wil be simpler also. I hope we'll have some results soon. We'll be evaluating performance on MySQL and Postgres DBMSs. The XML approach is our plan B :D
This approach is based on some requirements: We need the clinical data on the production DB (that DB is relational, and the clinical data is stores in the "content classes" I mentioned before.The repository must support querying data at an atomic level without loading a huge amount of data on memory (for example: find all the patients with systolic BP over 130). In the end we need a complete structure: the structure classes can be infered by arcehtypes and metadata (that can be persisted on filesystem, or could be instanced on memory) There are other options too: 1. use an object-oriented dabatase (an ger rid of the Object-Relational Mapping tool), 2. use a document oriented DB: a. a XML native DB or b. a JSON native DB like http://www.mongodb.org/, 3. mix of relational dbs or oo dbs and filesystem (to store documents XML or JSON). Just my 2 cents. -- 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 Date: Tue, 7 Jun 2011 16:53:10 -0400 Subject: Re: Dual Model EHR implementation From: randy.ne...@veriquant.com To: openehr-technical at openehr.org Alan, Thanks for clarifying. I thought in your earlier post you had ruled out XML. I was curious what the alternative would be. JSON, as you suggest, would be better. Since writing my post I realized I had not given you credit for one innovation I had not seen before, namely, placing "structure classes" directly into the DB. That would allow you to keep your JSON content instances relatively small and hence searchable with formal queries, at least to some extent. I could be mistaken, but I think an alternative approach I had heard about on this forum would be to create basically just one blob or just one XML document to contain an entire medical record for a patient, a record that would be extended with each encounter, with the prior instance of the record deleted or at least never referenced again. Again, I will probably be corrected here. Your approach sounds better. Randy On Tue, Jun 7, 2011 at 3:49 PM, Alan March <alandmarch at gmail.com> wrote: >Regarding ?content structures?, these could be persisted as ?objects? in ad >hoc field in the database. What kind of "objects"? And how would any approach of this sort be much better than XML? You'd still have to retrieve, parse or otherwise deserialize the entire blob before you could productively read, or navigate to, the tiniest part of it, taking time and resources. And it would seem that your object would have to be mixed with a lot of instance-level metadata (as in XML), further bloating its size, complexity and internal overhead. And are there non-proprietary ways to do this? I never mentioned blobs. Precisely?XML structures would be one of the best choices (or probably better: a JSON ?object?). If you read on you?ll see that that is precisely what I did in the past. That is why I enclosed the word object with double quotes (meaning to use the concept metaphorically). Serializing (real) runtime objects into XML or JSON ?objects? and storing these ?complex data types? (I should probably have used this terminology) is, to the best of my understanding, the most convenient choice. So I fully agree with your comments. I don't see how the functionality of such objects would greatly exceed that of a PDF text document (possibly including a document-level table of contents), which, at the end of the day, is what a lot of EMR systems essentially amount to. Doctors typically pull up text-based notes often autogenerated from discrete fields never searched upon again and which may even die upon the generation of the note. I understand that one approach is to provide some basic indexed "pointers" to the blob within the DB, but that does not really overcome the basic problem that blobs pose. Sure. Blobs are ghastly and under no circumstance would I propose their use for storing information of the type we are dealing with here. One could argue that this at least avoids the problems often associated with EAV, but at the expense of easy and efficient access to discrete data elements. If a weight is too heavy to lift one solution is simply not to lift it. _______________________________________________ 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/20110607/965bc98b/attachment.html>
