Well said! Here is my take on the problem. Imagine having N barrels, and a number of pipes, connecting these barrels. Barrels are filled with water, and pipes carry water from barrel A to barrel A. At an abstract level, both barrels and pipes contain water, but they are supposed to allow different uses of water, and this is reflected to their design.
A pipe mostly has a smaller diameter compared to a barrel, since it is supposed to go through walls, and it is usually made from a different material, considering problems like freezing. So you insert two ends up a pipe into two barrels, and it would help you carry water from one barrel to another. The barrel on the other hand, is designed to hold water, and it has a large cover, matching its wider diameter. You can get a water pot, sink it into the barrel, and fill it with water. This would be your local use of water. By design, pipes provide barrel to barrel connectivity, and people in front of the barrels get their water from the barrel. Now, both in theory and in practice, you can use pipes to store water. Imagine how you'd do it: you get 40-50 pipes, close one end, then bind them all together and put them on the ground , making them stand on their closed end. Then you need to either connect 50 pipes to your 50 vertical pipes, or try to fill them with a water pot, making sure that you don't spill water into the space between them. When it is time to use this set of pipes to fill water into water pot, you can't sink the water pot into the pipe's opening, so you'd have to lean the pipes to fill water to water pot, of course, since all pipes have an open top, you'd have to have to deal with water being wasted. Likewise, you can remove the tops and bottoms of barrels, join them, and try to use them as pipes. This time, you'd be wasting an awful amount of space, since only a certain amount of water is supposed to flow from one point to another and also, you'd find out that 30 cm thick walls can't really contain barrels with 60 cm diameters. Trying to use HL7 to build the whole information system is like trying to use the pipes to store water. It somehow happens, but both the people building the storage (information system) and the people trying to feel the water pot (end users) have problems. If you try to use comprehensive models you've designed to run a clinical information system for messaging, you're trying to put barrels into walls. I think you can see what is wrong here, but life is funny when it comes to software; if it more or less works, then it is simply called "working". I for one, will not be storing water in pipes... Best Regards Seref On Sun, Nov 21, 2010 at 4:09 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 21/11/2010 13:49, William E Hammond wrote: > > To all, > ... Even with > CDA, to send a single data value takes a lot of characters > > > openEHR would be the same in that respect. But the criteria we judge on now > include things like computability, re-usability (of information) and so on, > not just number of bytes and time to display. > > > I think we should be able to define structures independent of the > transmission of the data. How do we work together to move ahead? > > > I have been arguing with HL7 folk for years on this point. But HL7 appears > locked into defining the content within a message based model, full of > message-related attributes and design features. This makes it very hard to > re-use an HL7 content definition, even assuming it was agreed to be done as > an HL7 template (unfortunately, this is in XSD, a disasterous modelling > technology) or an RMIM. > > One of the things we tried to do from the outset with archetypes was to get > away from this. Yes, openEHR archetypes implicate the openEHR reference > model, but only about 30% of it - the semantics that matter to clinical > modellers. And from openEHR templated archetypes, we can generate diverse > downstream artefacts for use by normal programmers. The message XSD is a > end-of-the-line downstream product, not a starting point in openEHR. > > - thomas > > * > * > > _______________________________________________ > 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/20101121/a4dccb3e/attachment.html>
