On Sun, 28 Dec 2003, Thomas Beale wrote:
...
> >Those who paint "converters" as evil are likely responsible for
> >"standardization" failures of our past. Any information system that does
> >not fully support "converters" cannot provide extensible semantics
> >support.
> >
> well, I don't think that's true - consider the 'information system'
> represented by a set of class texts in some library; for these to
> interoperate with the class texts of another programmer, there are
> various possibilities:
> - programmers A and B can collaborate to produce new or changed classes
> which work for both of them
Thomas,
In this context, "collaborate" is a out-of-band translation effort.
> - programmer B can inherit from a class of programmer A
"Inherit" is a special form of A-to-B translator.
> - programmer B can use a class of programmer A (i.e. use its interface)
This is re-use, not extension. Also, programmer B's ability to locate and
retrieve A's class also requires translation (of B's intention mapping to
A's published description).
> - the system built by programmer B, having no prior knowledge of the
> system built by programmer A, might try to talk to it and use a dynamic
> invocation interface to ask it what its operations are and then try and
> make sense of them and call them
>
> I suggest that converters are analogous to the last category here; the
> first three categories represent some kind of a priori collaboration.
If you insist, you can call them "a priori collaboration" but they should
be modeled as "translators" if we wish to eventually automate much of it
in-the-band.
...
> >As I pointed out repeately, a "constraint language" is not sufficient. We
> >also need a "translation" infrastructure. This is exactly why OpenEHR, in
> >its current form, is inadequate.
> >
> >
> as I have pointed out a number of times in the past, there is room for
> 'translation' of data via archetypes; all I have said is that it is not
> the front line approach in achieving interoperability.
I differ in this assessment. Interoperability through re-use of OIO forms
or OpenEHR archetypes is trivial. Our research and development focus will
be on translation services.
> it would be interesting to see:
> - the constraint language definition that you propose
This is the forms-metamodel, for example.
> - a description of the translation tools
1) Pick 2 forms, 2) define mapping between question items, 3) define
re-coding/transform functions, if any.
> - the OIO equivalent of a "systemic arterial blood pressure
> measurement", an "Apgar result", a "glucse tolerance test result", a
> psychiatric note, ....
These are all single data items. They will just be Question items on
OIO forms. For example (blood pressure),
<form>
<item>
<name>sBP</name>
<description>systemic arterial blood pressure, supine</description>
<prompt>sBP?</prompt>
<itemtype>pressure</itemtype>
</item>
<itemtype>
<name>pressure</name>
<description>mmHg</description>
<action>number</action>
<choice></choice>
</itemtype>
</form>
...
> >A classic case of blaming human users for inadequate information
> >systems!!! Now, let's whip the human end-users into submission so that
> >they won't dare question the wisedom of the perfect machines :-).
> >
> >
> Getting out of the sea of incompatible data means some kind of
> cooperation.
Cooperation is one thing. Having no other option (to agree to disagree and
then use translators) is quite another thing.
...
> >Sure it does. What if computer software can create these data converters
> >without human intervention?
> >
> if that's true, then you in fact have some kind of systematically
> computable compatibility between forms, and they are not in fact
> completely independently created.
Appearance of intelligence comes from the ability to discover non-obivous
relationships between concepts :-).
"Completely independently created" does not necessarily mean zero
"computable compatibility".
...
> Can you show how you came to these conclusions?
1) OpenEHR lacks a fully functional, open-source implementation
--> No code to download.
2) OpenEHR has no translation facility (and no recognition that a
translation infrastructure is central to its professed "future-proof"
goal)
--> Per OpenEHR design documents and recent discussion
3) Target audience is not "any willing physician" - thus it is not capable
of supporting a grass-roots build-out.
--> No end-user tools that support deployable archetypes/templates for
data collection and reporting
4) Overly complex archetype model - unnecessarily hard to understand,
needlessly difficult to implement
--> why archetype model cannot be simpler is unclear
--> archetype model did not come from incremental development based on
real implementation experiences (that drove incrementally
complex model)
--> use of much jargon in documents that describe OpenEHR archetype
model. If it is easier to understand, it may be easier to
implement.
> Perhaps we should publish a comparative analysis of a very simple
> archetype/form such as BP measurement. Others can then judge.
Great idea.
Best regards,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org
