Re: Wait a sec...What about the HL7 RIM An Universal Exchange Language

On Wed, Dec 15, 2010 at 8:47 AM, Michael Miller
<mmiller@systemsbiology.org>wrote:

> hi all,
>
>
>
> "unambiguous identifier for "things""
>
>
>
> i agree, this has been a known issue for many years (as you well know, tim)
> but its importance is just now growing as multi-omics studies and sharing of
> EHR records is becoming more common.
>
>
>
> "It is HL7 V3"
>
>
>
> i also agree, in a sense, with this.  HL7 messages capture information as a
> whole, as an entity, so in that representation it is also true that semantic
> web technologies would have a hard time, as is, making sense of them because
> semantic web technologies wants a fact by fact representation, e.g. triple
> store.
>

But turn this on its head. HL7 messages come from "islands of data" which
have undetermined linkage. Think of a lab result that has a local code,
rather than LOINC. LOINC is equivalent to a link to the outside. Effectively
the local code is meaningless outside.

By its nature, linked data should resolve. If there is a url, you should be
able to chase it down. The equivalent of a local code is a resolvable URL
which presumably leads to some sort of description of what that local
concept means, perhaps enough to translate it to a more commonly understood
equivalent.

You ask for any number of triples from a semantic endpoint, enough to
capture what you need - all lab result assertions over a period for
such-and-such a person. That's no different than a query in HL7 (or any
other RPC like mechanism).

The key difference with linked data (specifically) and "islands with
protocol access" is linkage: the idea that links always resolve to something
meaningful as opposed to identifiers that while unambiguous, may lead you no
where. The problem with the old school which Parsa's "30 years of XML and
HL7 experience" captures nicely is wrapped up in this.

I've coded this stuff a good bit and everyone gets fixated on the syntax of
messages/xml blocks. People are happy if a coded element is "correct", that
it "conforms" as opposed to being useful or meaningful. And the problem lies
not with them, but the mechanism. It's put the focus on "truck", not
"cargo".

Conor


>
>
> cheers,
>
> michael
>
>
>
>
>
> *From:* public-semweb-lifesci-request@w3.org [mailto:
> public-semweb-lifesci-request@w3.org] *On Behalf Of *Peter.Hendler@kp.org
> *Sent:* Wednesday, December 15, 2010 8:18 AM
> *To:* markw@illuminae.com
> *Cc:* public-semweb-lifesci@w3.org; public-semweb-lifesci-request@w3.org;
> twclark@nmr.mgh.harvard.edu
>
> *Subject:* Wait a sec...What about the HL7 RIM An Universal Exchange
> Language
>
>
>
>
> The PCAST did not take into consideration (maybe they don't even know)
> there is an universal exchange language for healthcare.  It is HL7 V3.  The
> CDA is merely one of virtually infinite structures that can be constructed
> from the RIM.  The meta information as well as the clinical data is
> unambiguously represented by RIM.  There is no reason to ignore the
> thousands of man years that went into designing the RIM.  The RIM Based
> Application Architecture  (RIMBAA) work group at HL7 has had many
> demonstrations of RIM based applications.  We don't need to re invent the
> wheel.  CDA is only one particular RIM structure designed for one particular
> use case.  Those of us who have been working at HL7 for years are blown away
> by the suggestion that there needs to be a different wheel invented.
>
>
> *NOTICE TO RECIPIENT:*  If you are not the intended recipient of this
> e-mail, you are prohibited from sharing, copying, or otherwise using or
> disclosing its contents.  If you have received this e-mail in error, please
> notify the sender immediately by reply e-mail and permanently delete this
> e-mail and any attachments without reading, forwarding or saving them.
>  Thank you.
>
>
> *Mark <markw@illuminae.com>*
> Sent by: public-semweb-lifesci-request@w3.org
>
> 12/14/2010 06:44 PM
>
> To
>
> "Tim Clark" <twclark@nmr.mgh.harvard.edu>
>
> cc
>
> public-semweb-lifesci@w3.org
>
> Subject
>
> Re: An Universal Exchange Language
>
>
>
>
>
>
> But seriously, Tim, if we were to pursue this problem, we would need some
> form of unambiguous identifier for "things"... and given the distributed
> nature of the biomedical domain, we'd want to make sure that there was
> some way of resolving that identifier to obtain metadata about it from a
> variety of disparate sources who might have very different information -
> clinical, molecular, demographic, etc...
>
> hmmmm....
>
>