Re: [COAS-List] tentative model of CEN PT27

[Gunther Schadow <gunther@aurora.rg.iupui.edu>]

Tom, Angelo,

> Thank-you for the model I will look at it and try to further
> understand it and where CEN is.

I believe, CEN's medical record architecture is pretty close to what
you are doing in COAS. CEN's basic architecture distinguishes Record
Elements and Link Elements. Thus CEN's record is a graph with nodes
and arcs. Your model (without the Qualifiers, and with an association
class between CompositeObservation and Observation :-) is basically
the same thing.

>...
> be frustrating. People often react to a simple model by saying, "Oh
> yes, that's obvious" and thinking "So why did it take so long to
> come up with it?" But simple models are always worth the effort. Not
> only do they make things easier to build, but more importantly they
> make them easier to maintain and extend in the future."

I like simple models too. However, simplicity of the model can result
in a hard life with the model, if the model fails to cover essential
complexity of the domain. I mean, everything in life can be broken
down to things and relationships between things (nodes and arcs),
however, it might be useful to state a little bit more concrete stuff
in the model --- that's not a critique of your model in particular,
it's just the downside of any simplistic model. 

The advantage of the simple model is that you don't have to have
consensus whether qualifiers exist and what they are :-) We just had a
similar experience in the HL7 Observation and Patient-Care
committees. We thought we knew what the difference between an
observation and a so called "health issue" was, but we fooled
ourselves -- we just could not agree. So, the only way to move on was
to merge both classes into one. Now health_issue is folded into
Clinical_observation and everyone is happy ... at least so far.

> The following is a start of outlining the differences in the two
> paradigms. I am still a bit hesitant to catagorize CEN.

I have some comments on your list ... but I have to reformat it to
understand it.

For every of your "properties", I first repeat your assessment and
then I give my comment.


Property 1: Basic paradigm

CORBA: Object-orientation, management of distributed objects

HL7: Messaging concept

COMMENT: that was true for HL7 version 2, but it is definitely no
longer that simple for version 3 of HL7. I suggest that CORBAmed
should no longer consider HL7 version 2, but you should look only at
what we do for version 3. Most of your assessments will come up very
different with regard to HL7 version 3.

It is still true that messages are our main concern. However, we are
already watching out, and working on, documents and the so called
"components" (i.e. distributed objects.) Furthermore, if you look at
what a message is, you find out that the difference is even less
relevant: A message basically is a remote procedure call protocol
(RPC). A message is nothing else than a distributed calling convention
of a remote procedure. This is quite near to CORBA, given that CORBA
is basically an object oriented extension of the RPC idea.

Furthermore, HL7 v3's design is fully object oriented. We are using
UML as our information model tool. All the messages are derived from
that object oriented information model. We do full UML, including
state-transition models (and all the other less important UML stuff.)
Theis idea is still a sleeping beauty in HL7, but, you could use the
same information model, represent all the transitions as operations in
the class diagram, from which you can readily derive IDL for
distributed objects at once.

We are not so far appart, the old stereotyical conception of HL7 does
no longer apply!


Property 2: Architectural concept

CORBA: Object management Architecture (OMA)

HL7: No

COMMENT: This assessment is true, at least the raw facts are true. But
you could state it in another way: While CORBAmed is an outgrowth of
OMA/CORBA, and can not exist without CORBA, HL7 (version 3!!!) is
technology-neutral. I am a strong believer in technology-neutrality as
a cornerstone of HL7's success and future. As noted above, we *can*
fully embrace OMA/CORBA (much more than we are currently willing to
see). But we can also define messages, documents, even user-interface
transactions could be developed based on the HL7 v3 information and
process models. Our main concern is the healthcare domain---technology
is secondary. However, some of us love technology, and we are quite
proud of the technological ramifications of HL7's technology-neutral
way of life.


Property 3: Middleware of common services

CORBA: Yes, generic healthcare specific facilities can be developed

HL7: No

COMMENT: this is the same property as the above on "architecture". I
hate the term "Middleware" for its uselessness in any discussion. It
is weak and amorphic.

Does HL7 have common services? Oh, yes it does! The whole Idea of the
multiple technical committees in HL7 is to provide common
services. Examples are patient management services, MPI services,
observation access services, ordering services, etc.


Property 4: Interoperability

CORBA: Yes

HL7: No

COMMENT: I guess you know pretty well that this is an unfair
assessment. What do you mean by "Interoperability"? Some people think
that CORBA is interoperability by definition. But that's wrong. Sure,
an IDL interface might be superficially interoperable, i.e., you can
invoke an object's method and you get a response. But CORBA IDL does
not specify what exactly happens with each call of an object, and what
the caller can expect the callee to do with the request.

IDL is a formal contract between caller and callee. But IDL only
specifies signatures of interfaces, not the procedural aspects of the
services. For rather basic techology-oriented services, the procedural
aspects might be straight forward. But for health care,
interoperability means much more than just common interface
signatures. Just take the vocabulary problem as an example: if you use
different terms for you observations than I do, CORBA's technical
interoperability is relatively worthless.

The bottomline is, HL7 v2 used to have *LOTS* of interoperability
problems, but the core momentum of the v3 movement is our plan to get
rid of those interoperability problems. HL7 v3 is going to be
interoperable. HL7's specification will be (and already is) much more
rigorous and well defined.


Property 5: Level of standardization

CORBA: Standardized architecture and common object services

HL7: Standardized messages

COMMENT: We start repeating ourselves. HL7 v3 will have not only
abstract syntax for messages. The so called "Implementable Technology
Specifications" (ITS) will tell you exactly what the technological
protocols are to actually make the messages work. Standardization will
thus cover everything. However, we are still technology neutral, and
thus standardization---understood as exclusion of alternatives---can
be done less radically in HL7. We have no preemptive committment to
any technology, thus, for any technology you can write a good ITS and
HL7 will work on that technology---of course, including CORBA.


Property 6: Adding new applications

CORBA: Partial development, using excising objects

HL7: To be developed independently, using standardized messages

COMMENT: I don't understand the term "excising objects". The
difference between CORBAmed and HL7 v3 might be that HL7 starts out
with an all-encompassing Reference Information Model (RIM), and all
the services are derived from the RIM. However, that doesn't mean that
adding applications would just mean adding new messages. Every new
project will start fitting itself into the RIM, thereby causing minor
or major shifts and drifts in the RIM structure. We call this process
"Harmonization", i.e. fitting in the requirements into the big
picture.

As soon as the information model captures the aspects of the new
application, state-transition modeling will discover the
procedures/methods and their signatures. Comming up with messages is a
semi-automatical downstream process, once you have defined the
procedures and their signatures. (We use slightly different
terminology here, but I try to point out our similarities by the terms
I use here. We call the procedures "events" and their signatures
"MODs" or "HMDs"---but who cares how we call them as long as we know
what they are!)


Property 7: Support

CORBA: Limited, but increasing

HL7: Many suppliers

COMMENT: This is nicely stated in favor of HL7, however, it is true
mainly for v2 of HL7. As I said above, let's not consider v2 any more,
since this only obscures our common goals and opportunities to
cooperate. With HL7 v3 "the cards will be mixed again", i.e. we will
slowly get vendor support. The opportunity to leverage existing v2
support exists, but is limited, if v3 is going to be a real
improvement over v2 of HL7, mainly in terms of interoperability. So,
we both look pretty similar with regard to support.


Property 8: Future developments

CORBA: New services and facilities, healthcare specific

HL7: New messages

COMMENT: This is just a coda of the old but useless
services-vs.-messages dichotomy. Again, a (pair of) message(s) is
nothing else than a calling convention for a remote procedure.

My own hope for the future of HL7 v3 and CORBA is that both HL7 and
CORBA may blossom through effective cooperation and use of each
other's strengths. I know there are a lot of political issues that
define and devide organizations in the field of standardization. But
those political issues should not be our main concern. For me, HL7 is
it's methodology and the people; for me, HL7 is not its brand name, or
its budget, or its "Inc."-ness.

I am with HL7 mainly because HL7 is relevant for my application
domain, and because it is open to, and actually welcomes, my
participation.  From this perspective---focussing on the goals and
disregarding the "Inc."-ness---I truly believe that CORBAmed should
become part of HL7---I do NOT suggest that HL7 should simply swallow
CORBAmed. But, technically, I see no reason, why HL7 should pursue its
own ways to using CORBA independent from CORBAmed. On the other hand,
I see no reason why CORBAmed should "reinvent the wheel", where HL7 is
already pretty far, i.e. in health care information and process
modeling.


One good model is what we all need. Two or more good models will be
harmful in the long run. And the perfect can be the enemy of the
good. The key strength of the HL7 RIM is its foundation in
consensus. I have posted on my office wall my favorite model (which is
quite different to the RIM). But I stand by the RIM, since it is a
workable consensus. I carry my ideal model in my mind while arguing
about the RIM. And I learn from that consensus process as much as I
can influence it.


With regards to your remarks about CEN, I believe that every form of
organization has its advantages and its disadvantages. I know some CEN
people and I always enjoy meeting them. HL7 has learned a lot from
CEN, our methodology and our goals are quite similar in many
respects. I am very hopeful that we will make major progress in
harmonization with CEN. I am hopeful, because it seems like the time
has finally come, where real people meet real people.

Brian Love from the U.K., who is associated with CEN *and* is a
regular attendee and contributor to HL7 meetings, said it this way: As
long as organizations meet through mere representatives, the chances
for harmonization are limited. This is because representatives brought
their agenda with them from home, they can not easily change their
minds without risking to betray their people, by whom they were
sent. By contrast, when real people meet as mere collegues, there is
much more opportunity to come together. Luckily, now is the time where
finally people meet and organizational doctrines become secondary.

In the same sense, I wish, and I am hopeful, that the ice between
CORBAmed and HL7 will break again. One indication of this is that you
(CORBA), Angelo (CEN) were at our (HL7's) last meeting, and that we
are still talking.

best regards
-Gunther

Gunther Schadow ----------------------------------- http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
schadow@aurora.rg.iupui.edu ---------------------- #include <usual/disclaimer>