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/91b0656f/attachment.html>
