On Tue, 15 May 2001, David W Forslund wrote:
...
> I don't see the OIO system as being "portable". I can't get it to
> "interoperate" with other systems, can I?
Hi Dave,
Excellent point! Although the OIO system can import/export its data and
metadata in XML, it still does not "interoperate" with other systems. At
least one additional step is necessary to "interoperate": knowing what the
second system can import/export.
> A lot more than "easy-to-use import/export" is needed. It is a
> terminology service to translate between different terms and their
> varying definitions, it is an integration of data between multiple
> sources without having to pull all external data into ones own system.
Yes, but we have to start somewhere. You have seen my proposal - I am most
willing to consider an alternative plan.
We need to have a terminology server so that I can determine the "meaning"
of terms you use and know how to translate them into terms I understand, and vice
versa. Is this in your proposal? This amounts to some kind of ontology and the
ability to translate between ontologies. This is absolutely necessary if we are
going to export/import. Second, we need some kind of templates or archetypes so that
we can properly exchange data structures (once we know what they mean).
> The copy-left license isn't the issue. It is who owns the content.
For the specific purpose of exchanging the contents of the "projects
database", the copy-left license is sufficient.
I'm more interested in the exchange of clinical information. The projects
database has already been handled through much of the RDF/DAML work.
Go to http://www.daml.org or http://www.semanticweb.org for example.
Whatever we do ought to be compatible with that work, I think.
> Is
> this the patient? Open-source systems should be interoperable with
> proprietary systems. But the ownership of the data is unrelated to this.
I agree. Patient data cannot be distributed under copy-left license,
therefore it will be more complicated to setup a test bed that exchanges
real patient data.
This isn't too hard to do if we create test data. For example, we have a
sample PIDS server that has been running for more than 3 years at Los Alamos,
that allows one to add users and look up people using the CORBA PIDS specification.
We also have a pure web interface to that.
...
> > I agree. This is exactly analogous to the requirement for medical record
> > systems where clinicians and patients need to be able to move data from
> > one information system to another. If we cannot support this for the
> > projects database, we might as well forget about it for medical reoords.
> >
> As I said above we need a lot more than the ability to be able to move
> data from one information system to another. We should be able to have
> a distributed set of resources that can be integrated on the fly as
> needed.
All true. But if we cannot even move data from one information system to
another, then IMHO a federated system is also be out-of-reach.
I agree. And we need to be able to properly translate meta-data from one system
to another, using some kind of terminology service. The design should be done
with the eye on linking the sources, not just exchanging data.
> Nothing less than this will really benefit the patient, IMHO.
O.K., but lets get started with step 1.
> This is what we have been trying to do for the past 5 years. But our
> success in getting people to understand what we are proposing has been
> poor.
This is valuable information Dave. I can't impose my interpretation of
your results on you but I really think "virtual" medical records is too
radical a step for most clinicians to take all at once.
Having their records made readily available to another appropriate user, is
all that is needed to begin this step. If we have standards, "my client" could
access your data repository with only the need for you to authenticate me and
give me permission to see the data. The step of linking them because simple
allowing for simultaneous viewing of multiple repositories. The idea of a
web client doing this is attractive, but it can't be done unless we have the
same underlying semantics of what we are doing. It is this underlying semantics that
we have been concerned about.
> We are not claiming "our" system should have all the data or that
> people need to do what we are doing. We only claim that people should
> be trying to agree on providing integrated information following the
> various international standards. We have attempted to demonstrate a
> way to do this. Most systems that have been developed appear to want to
> handle all of the patient data, not be a component of a distributed
> medical record system.
I don't think the problem is technology because you have already
demonstrated feasibility.
How about starting with a viable local system and then becoming a node in
a distributed system?
Yes, but the local system must be designed with distribution in mind. Otherwise,
we usually find that the step to a distributed system means a total reengineering
and never gets done. This is why I advocate the use of international standards within
a system (between components) so that when distribution is desired, it is simply a
matter of configuration and adding permissions.
> Beyond the political problem of sharing data, there is the security
> problem of sharing data and the HIPAA regulations in the US, which make
> this very challenging.
No kidding! How about tackling one little piece of the problem at a time?
If you are going to export/import data electronically between systems, you will
need to deal with HIPAA.
...
> I think everyone is interested in participating. GEHR, in
particular,
> has been working hard on archetypes which are crucial for the success of
> what I'm suggesting.
How would you envision OpenEMed participating in the "projects database"
testbed?
I need to understand the meaning of the projects database. I could provide and RDF
description of the data we are dealing with, if necessary. OpenEMed already has
a specification for interoperability. It consists of the IDL from the OMG (PIDS, COAS, RAD, TQS).
I can make this available in an Interface Repository if any one is interested, so that you can
discover how to talk to our system totally automatically (modulo security).
The ideal way for this to work is for systems to be registered in the Meta Object Facility. Short
of that we could have a UDDI registry and all the terms in a common TQS repository so that we
could do an easy translation between systems. These are just suggestions to think about.
Dave
Best regards,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
TxOutcome.Org (hosting OIO Library #1)
Assistant Clinical Professor
Department of Psychiatry, Harbor-UCLA Medical Center
University of California, Los Angeles
Computer and Computational Sciences
Los Alamos National Laboratory
505-665-1907
