> Hi Dave,
>
> Good to see you're still here.
>
> Way back in 2001, I unsubscribed from openhealth (still in Minoru back
> then) because I felt much of the discussions were very theoretical and
> I had not much code/experience to contribute. Well now, we have source
> code (but still not enough experience, I regret).
>
> I'm beginning to see that OSHCA will not really arrive at a point when
> our apps will 'interoperate' (in the ideal sense of the word) *not*
> because it is technically impossible (you have demostrated that it can
> be done already) but rather because of 1) simple 'stubborness' [aka
> 'not invented here syndrome'] or 2) a lack of initiative to study
> what's already out there [aka laziness. Or hiding behind the 'we want
> to get a feel for it ourselves first'].
>
> To a degree, maybe we thought: "Gee, there is no standard. Maybe we
> can publish our own! And we better make it fast because Dave's might
> gain ground before ours does." [thought did not occur, believe me].
What we have done shouldn't be the issue at all. What is important is
that there has been standards
in this area for some time (98-00). I've heard people complain that
they were too complex, but I've not heard
people complain that they are incomplete (although I believe they are).
I claim the specs aren't
too complex for the task that is required of them. Almost all the
things in the spec (particularly
taking into account differing conformance criteria) have to be done anyway.
>
> Personally, I could not understand the interoperability techniques you
> were proposing back then, and to be honest, did not give it enough
> time to be comprehended properly.
One simple one was that the specs were written in UML and they use
component architecture
both of which help the development process rather than hinder it.
>
> I believe in much the same way, this same stubborness will prevent
> many (but not all) to study CHITS in depth. In our local case, it
> doesn't really matter much because our target for the CHITS
> is not OSHCA but rather the Philipine healthcare system or any other
> resource-constrained facility which would like to 'grow' into their
> HIS. CHITS in the end is a methodology with a built-in framework, and
> not a standard. It's made up of the set of capability building
> activities for local personnel to interact with CHITS in various ways.
The target of interoperability isn't and shouldn't be OHSCA. It is much
bigger than this. Systems
can be built on a framework which itself isn't a standard and still have
full interoperability.
I don't expect others to implement persistent store the way we do, but
still expect (hope for?) them to be interoperable
with us.
>
> Maybe the CHITS design/glue is 'proprietary', but since it's open
> source, then it becomes non-proprietary<?>. Will that make for
> inclusion into the OSHCA list of open source health apps ?
It can still be "proprietary" even if it is open source. I don't think
that OSHCA is restrictive
in this sense. Where do I find the specifications for your "glue"? I
would like to do
that without having to download or read your code. Interoperability
specifications
should require one to read implementation code to figure out what it
does and how it works.
That is why interoperability can actually be orthogonal to open source.
>
> If we cannot settle the interoperability question then [been at it
> ever since or maybe like the holy grail, it does not exist?], what
> might be a common concern of all OSHCA members where we can
> demonstrate cooperation and collaboration?
Join the various groups involved with interoperability and standards.
Work in cooperation
with non-open source systems. Contributions to these efforts can be
done with no cost or
minimal cost in some cases. For example, ASTM is involved with
demonstrating CCR
interoperability at TEPR next month. The cost of being involved is
somewhere around $100.
We have an open source implementation of the CCR based on OpenEMed and
hope to
show interoperability with a number of open and closed systems.
My comments are that open source systems should demonstrate themselves
as capable
or more capable than proprietary closed source systems and need to work
side by side
with them. The requirement of interoperability in the US, at least,
has reached a critical
mass, in my opinion. The NHIN is forcing vendors to deal with
interoperability and not
ignore it and hope it will go away. There is no reason why the open
source community
shouldn't be leading in this area.
Dave
YAHOO! GROUPS LINKS
- Visit your group "openhealth" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
