Yes..what we did is to store these small XML "documents in ad hoc fields designated as XML data types (in SQL Server). These fields are indexable but the API is a programmer's nightmare and for reasons I fail to grasp (one probably being my own incompetence.that can't be ruled out ;-), not too efficient. But the fact remains that that's probably the best way to go. How to index the data elements inside the XML structure so that individual records may be retrieved admits many different solutions. Probably a mix of several approaches would do the trick: EAV for some particular fields could be used (ie: fields often used in searches or sorting), indexing the XML fields with the database API in others. Even indexing outside the database by way of Lucene or something similar could do (but that could bring serious synchronization problems).
I've given a great deal of thought to these problems and experimented whenever possible but lacked the time to approach these issues in a more orderly manner. I am still waiting for that crucial paper or technical document which may help to clarify the issue as I think there lies the clue to a widespread adoption of a model as elegant and intelligent as openEHR strikes me to be. Cheers and thanks for listening From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Tuesday, June 07, 2011 5:53 PM To: For openEHR technical discussions Subject: Re: Dual Model EHR implementation 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110607/85df4630/attachment.html>
