>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 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. 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. Randy Neall -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110607/1fcae7a5/attachment.html>
