On Tue, 15 May 2001, David Forslund wrote:
> 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?
Yes, my idea is to do this at a local level during phase 1. The "projects"
data is simple enough so that a "static" or custom-made translator will be
sufficient.
In phase 2, we will automate this process by using a terminology server.
> This amounts to some kind of ontology
> and the
> ability to translate between ontologies.
Yes. My idea is to build the ontology and "inter-ontology translators" as
we go. Maybe Philippe's free ontology of 35000 terms will be translated
into English when we are ready to go into phase 2 :-).
> This is absolutely necessary if
> we are
> going to export/import.
This is true if we want fully automated importing/exporting of medical
information. If we want semi-automatic import/export of project
description etc, then a very very small ontology and a very very simple
translator will work.
Again, one tiny little step at a time.
> Second, we need some kind of templates or
> archetypes so that
> we can properly exchange data structures (once we know what they mean).
Yes, something like: project name, submitter, description, home_page_url.
...
> I'm more interested in the exchange of clinical information.
Me too. But we need to consider the steps that will lead us to achieve
that ultimate goal.
> The projects
> database has already been handled through much of the RDF/DAML work.
Perhaps... Just like CORBAMed has already handled much of the medical
systems interoperability 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.
I looked over the ontologies repository at www.daml.org and inspected all
10 "project" classes in the repository. Of course, none included all the
properties that we are currently using for the projects database at OIO
Library. So, should we submit our own "class" - it will be #11? Or what?
...
> >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.
Test data can only provide proof of "feasibility". Selling a new type of
medical information "infrastructure" requires proof of "reliability" and
"usability". This may mean using the same infrastructure for non-patient
data and gaining experience->usability and trust->reliability in the
technology.
Of course, it will also give us opportunities to iron-out any kinks before
affecting actual patient care.
IMHO, your accomplishments (PIDS server x 3 years) and my work with the
OIO system (OIO Server + OIO Library) have demonstrated feasibility. The
next step is to convincingly demonstrate usability and reliability to a
wider audience that is not yet ready to entrust their patient data to our
next generation systems. Of course, we still have lots to do with certain
things like the inter-ontology translators.
...
> >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.
Yes, I completely agree. A big part of moving data between systems is to
properly translate the meta-data. This "translation" task, however, need
not be done through a terminology server for phase 1 of the testbed.
Once we are able to import/export data and metadata manually, then we can
move to a terminology server so that we can scale-up the complexity of
metadata without overwhelming administrative burden. How does that sound
to you?
...
> > > 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.
IMHO, the appreciation for the advantages of a federated system over a
centralized system is still quite limited. Federation, I think, will come
only after centralized systems' limitations are appreciated.
Using the convenient example of the projects database, many participants
on this mailing list including Ignacio, Joseph, and others in charge of
the SPIRIT project really do not agree with my view that running the
Projects database as a federated system vs. a centralized system will be
to their benefit.
Now, if these top information systems experts, well-educated software
engineers, and promoters of information about open source projects do not
appreciate federation, how can we expect clinicians in solo practice to
buy into the nice federated design?
Fear, Uncertainty, and Doubt (FUD) are what we have to overcome. The OIO
Library is currently operating as a centralized/local system and I think a
good next step is to turn it into a node within a federated "projects"
information system.
> 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.
I disagree. Standards are not sufficient. We need implementations and
opportunities to test, validate, and gain experience with these
implementations.
> The step of linking them because simple
> allowing for simultaneous viewing of multiple repositories.
Simple techically but very difficult psychologically (i.e. FUD).
> 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.
You have seen my proposal for the piece-meal construction of
semantics/ontology via my discussion with Philippe. We can either decide
to do nothing until we are satisfied with the ontology or we can build as
we go.
I am taking the later approach which incidentally does not preclude
incorporating large segments of existing ontologies (e.g. Philippe's) when
they become available.
...
> >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.
Yes indeed. The OIO system has been designed with distribution very much
in mind and I hope you will find our collaboration meaningful.
> Otherwise,
> we usually find that the step to a distributed system means a total
> reengineering
> and never gets done.
I am not sure whether FreePM will require complete reengineering or not
but maybe Tim Cook will address that. I don't know Jeff from FreeMed is on
this list and whether he is interested. Thomas from GEHR is traveling and
I am not sure whether he will have time to make an archetype to support a
projects database.
> 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.
Even if that were so, a nice publicly accessible testbed will help
convince some potential adopters.
> > > 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.
Yes, I would argue that this is yet another reason to build a testbed.
These security mechanisms must interoperate between systems and be
convincingly reliable and usable.
...
> >How would you envision OpenEMed participating in the "projects database"
> >testbed?
> I need to understand the meaning of the projects database.
A database that allows submission and retrieval of information pertaining
to software projects. If you go to the OIO Library, you can open a listed
project (e.g. OpenEMed at
http://www.txoutcome.org/scripts/zope/library/files/browse/show_contents?objectid=134)
and then click on <Download as XML> or directly view it as XML using this
link:
http://www.txoutcome.org/scripts/zope/library/files/browse/xml/project_xml?objectid=134
It gives the list of properties that are part of the "project" ontology.
If you think the format or tags would be better if they are done
differently, I will be happy to change them.
The current description is project-data-item-(name, value) where
name={submitter, submitter_email, time, description, requirements,
license, homepage_url, documentation_url, screenshot_url, download_url}
> I could provide
> and RDF
> description of the data we are dealing with, if necessary.
If you think RDF is better, maybe you can tell me how best to structure a
RDF for the projects data and I will implement it.
> OpenEMed
> already has
> a specification for interoperability. It consists of the IDL from the OMG
> (PIDS, COAS, RAD, TQS).
Will it be able to import the projects database if I export data from the
OIO Library as XML?
> 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).
Implementing a real testbed and application is the step that I think we
need to take. If I can take data from the OIO Library and import into
OpenEMed - and users are able to see their submission to the OIO Library
become viewable in OpenEMed (and vice versa), then the goals of Phase 1
would have been achieved.
> 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.
I am most willing to do all of these if you are interested in working
together. I will need your help in discovering how to register in the
Meta Object Facility etc. However, these sound like Phase 2 tasks which we
don't have to do yet.
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
