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

As simple as possible can be quite complex. It's amazing what's been

Greg Harris

Reply via email to