On Fri, 27 Jun 2008 13:46:27 -0300 Tim Cook <timothywayne.cook at gmail.com> wrote:
> > On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote: > > Very interesting - maybe we could have seperate namespaces for the > > core tags and extensions. Could be a good compromise! While I see > > the advantages of keeping GUI stuff out of the template, I also see > > that this more and more complicated as we add additional abstraction > > layers. > > Ahhh, true. It is complicated. It is the reason why health > informatics is where it is today. The beauty of the openEHR specs is > that each portion does one thing well and yet all the parts fit > together. > > If we get carried away and start mixing the layers then the specs get > more complex, the tools more difficult to use, applications less > likely to inter-operate and there won't be very many implementations. > > <sarcasm> > If you aren't careful you could end up with something HL7v3. > </sarcasm> > > As "my buddy" Albert E. said; Make everything as simple as possible > but no simpler. ;-) > > > --Tim > As counsel for a trade group many years ago, I watched a committee work long, earnestly, and hard to develop a proposal for a standardized set of paper forms for claim notices. When that committee subsequently was asked to review the adequacy of a set of draft EDIFACT messages to communicate the same information content, they had a very difficult time separating the information from its presentation. They were neither stupid nor uncommitted to the effort; their input was both indispensable to success and immediately useful for the developers. But for them, IT was something of a single cloud. It took a while for them to distinguish between the separate problems of (a) signing off on inter-company data sufficiency and (b) implementing and presenting that data on their respective internal systems. And while these people were volunteers in a sense, getting this done was part of their jobs and had the full backing of their employers. But if their input governed the back-end design and development, there would have been no progress. It was successful (or not) project management to get their involvement in the right amounts at the right times. Without any qualifications whatsoever to offer a judgment on this, I see a development interplay among three groups: the clinicians, the developers of the underlying structure, and the designers of implementing systems. (My guess is that's an obvious and seriously non-profound observation.) Aside from a long anecdote, it strikes me that UI decisions should be kept as separate as possible from any of the underlying structure; that presumption could be rebutted where an identified UI need can't otherwise be satisfied. Of course, at some level that's a nullity because the UI needs really define the structure design. As simple as possible can be quite complex. It's amazing what's been accomplished. Greg Harris
