Oliver,
I have just waded through this tome and have a few opinions. These
should be taken more as personal observations rather than a litany of
criticisms, because I genuinely applaud NEHTA'S efforts to define the
context within which they will be defining interoperability standards.
That said, I have a sense that this document was written by a committee,
whose motto is not "build it, and they will come", but rather "talk
about it and they will follow". Yes, it gives a very thorough
description of the framework within which NEHTA sees itself operating,
defining a common nomenclature and contextual framework. It is also a
good example of what you get when people are not required to work
according to a commercial deadline, to produce something that actually
works (or are being paid by the hour). As an experienced user of
software design patterns, I appreciate the need to have a conceptual
framework for software design. What the people who depend upon me for
though is working solutions, in non-geological time. Multi-modular
computer applications may start out with a statement of intent, but many
evolve their little rules and regulations as the system grows in
response to user needs. What this NEHTA document attempts to define is
all the possible compliance and conformance rules to be faced by anybody
who embraces SOA. Only by section 5 did I feel it was starting to come
alive, because the academic waffle provides a diaphanous framework
against which one could not possibly hope to benckmark a real, concrete
software design.
I'm happy to give NEHTA the benefit of the doubt for the moment, but I
long for the day when somebody actually produces a few solid, open
source components that demonstrate conformance to their standards in way
that is easy to benchmark. In this document NEHTA have still not
produced something that we, the developers who must build the blocks,
can use as any sort of guide. This is not a standard - it is a statement
of the context within which a standard will be defined.
In short: this may be well received at academic conferences, but is no
bloody good to me yet.
This document is of even less use to consumers of IT services, like you.
But I guess it's a start, because it directs our communal gaze towards
the same point of light in the heavens.
Oliver wrote:
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David More
Sent: Monday, 3 April 2006 10:36 AM
If you browse the document you will see the "common enterprise language" is a
high level description of how language is to be used for interoperation between health
care entities - it is not to do with programming languages I don't think - if that was
what you were asking.
****************
I didn't understand very much of the document in terms of what it means for us
in general practice communicating with patients, each other or with the rest of
the health system.
Can somebody who believes that they do understand what this document says
please at some point give us a one page summary of how they think it may
influence developments in information systems that GPs use?
Oliver Frank, general practitioner
255 North East Road, Hampstead Gardens
South Australia 5086
Ph. 08 8261 1355 Fax 08 8266 5149
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
--
Andrew N. Shrosbree B.Sc, B.Ec
Technical Director
ArgusConnect Pty Ltd
http://www.argusconnect.com.au
Suite 4, Greenhill Centre, Mt Helen
Victoria, Australia
Tel: +61 (0)3 5335 2214
Mob: +61 (0)415 645 291
Skype: andrewshroz
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
