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

Peter - as an FYI, the system at this end point (
http://vista.caregraf.org/rambler/2 ) is running a "flavor" of SPARQL (more
here: http://www.caregraf.org/semanticvista ) that returns triples from
VistA and RPMS (both of which are built around the MUMPS based FileMan).

The idea was to treat these existing stores as triple stores, in the raw -
there's no caching or clever mapping. Every statement embedded in the MUMPS
arrays is treated a triple. We go from VistA based RDF to RIM based RDF and
then make CCDs (among other things).

The patient extraction process (through to CCDs) has been certified for
meaningful use and is running on a VistA (MUMPS store) with 200K patients,
10M+ documents, 10M+ vitals, ... and on an RPMS with 50K patients. Because
querying is light and native, it's fast and flexible. You avoid all the
middleware layering commonly used in these situations. We do CCDs because
that's what the federal government want on the NHIN, but that XML only comes
at the edge of the process and is merely one "report", not intrinsic to the
process itself.

I'm just in the middle of something now but I'll mail some RDF around
tomorrow.

Conor

On Fri, Dec 17, 2010 at 4:12 PM, <Peter.Hendler@kp.org> wrote:

>
> I would love to see some of this in RDF triples.  Personally I've had
> experience with RIM and relational DBs but not much at all in healthcare
> with triples.
> My real concern, is that people will go off and re model healthcare from
> scratch without taking the RIM into consideration.
> If someone has a RIM based triple store or representation of clinical data
> I'd love to see it.
> I'm from Kaiser where we have about 9 million members and tons of data on
> most of them. We have Epic which uses Cache database, and we have lots of
> relational databases (mainly Teradata and Oracle).  We don't have any triple
> stores.  I'd love to see an EHR like system based on triples.  I wonder how
> it would perform with so much data?  In the meantime, we, as well as the
> majority of big players, are looking into health information exchanges using
> CCD (based on HL7 RIM and CDA) structures.  Parsing them into RIM objects
> and persisting them in RIM databases.
>
> If there is a non RIM based, brand new canonical model for healthcare, it
> will set the clock way back to where we were in the 1990s.
>
>
>
> *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.
>
>
>
>  *Michael Miller <mmiller@systemsbiology.org>*
>
> 12/17/2010 09:23 AM
>   To
> Peter Hendler/CA/KAIPERM@KAIPERM
>  cc
> conor-dowling@caregraf.com, public-semweb-lifesci@w3.org,
> public-semweb-lifesci-request@w3.org
> Subject
> RE: Wait a sec...What about the HL7 RIM An Universal Exchange Language
>
>
>
>
> hi peter,
>
> "You don't gain anything by decomposing it and recomposing it into RDF."
>
> the scenarios where i have seen this work is where the data itself isn't
> touched, the application makes the transformation to RDF in memory then
> applies semantic tools.  so if i want to see if there are patients suitable
> for a clinical trial, a sparql query might describe the criteria quite
> nicely.  then i could run over EHR records, translating to RDF triples in
> memory then applying the query.
>
> depending on the backing store, i've also seen this done successfully by
> translating the query to sql then turning the query result into rdf triples
> to answer the SPARQL query.
>
> cheers,
> michael
>
> *From:* *Peter.Hendler@kp.org* <Peter.Hendler@kp.org> [mailto:*
> Peter.Hendler@kp.org* <Peter.Hendler@kp.org>] *
> Sent:* Thursday, December 16, 2010 4:37 PM*
> To:* *mscottmarshall@gmail.com* <mscottmarshall@gmail.com>*
> Cc:* *conor-dowling@caregraf.com* <conor-dowling@caregraf.com>; *
> mmiller@systemsbiology.org* <mmiller@systemsbiology.org>; *
> public-semweb-lifesci@w3.org* <public-semweb-lifesci@w3.org>; *
> public-semweb-lifesci-request@w3.org*<public-semweb-lifesci-request@w3.org>;
> *twclark@nmr.mgh.harvard.edu* <twclark@nmr.mgh.harvard.edu>*
> Subject:* Re: Wait a sec...What about the HL7 RIM An Universal Exchange
> Language
>
> Just want to be clear about when we use the word HL7.  In the USA when you
> just say HL7 it is assumed you mean Version 2 which is in very wide use and
> is not OO at all.  You almost have to say RIM based or V3 before people
> assume you mean the OO model (RIM).
>
> There is a specific XML serialization of the V3 RIM called the XML ITS.  It
> generates the XML elements, attributes and the order that they must be
> serialized in. When you are dealing with a CDA document, then in addition to
> these rules there are "templates" that are mostly just verbal human readable
> rules that you must follow for a given template.  Templates refer to each
> other, so the C32 document mentioned in the Meaningful Use rules of the
> HITECH part of the ARRA act is made from HL7 and IHE and HITSP templates all
> referring to each other.  These templates specify many things including
> which vocabularies must be used (SNOMED for example for coding the
> diagnosis).
>
> For a C32 templated CDA you have no wiggle room. The XML is defined.  You
> don't gain anything by decomposing it and recomposing it into RDF.
> There is nothing to say that you couldn't come up with different ITS's  For
> example you could come up with a JSON ITS and I suppose you could also come
> up with another RDF ITS. I'm just not convinced it would add anything to the
> understandability and I think it would add a heck of a lot of size to the
> representation.
>
>  Because the diagnosis and much of the clinical data contained in a CDA is
> in SNOMED, I do see the benefits of using subsumption on the SNOMED codes.
>  For example you could ask for all the patients that had any form a diabetes
> or heart disease and then use subsumption to get the lists of possible
> SNOMED codes that would be in the records of the target patients.  What I
> don't see is the advantage of using RDF instead of the standard RIM XML
> syntax.
>
> You could come up with an entirely new model for healthcare not based on
> the RIM and based on RDF, but much of the world (outside the USA) is already
> using the RIM.
>
>
>
>
>
> *
> 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.
>
>
>
>   *"M. Scott Marshall" <**mscottmarshall@gmail.com*<mscottmarshall@gmail.com>
> *>*
>
> 12/16/2010 03:47 PM
>
>   To
> conor dowling <*conor-dowling@caregraf.com* <conor-dowling@caregraf.com>>
> cc
> Michael Miller <*mmiller@systemsbiology.org* <mmiller@systemsbiology.org>>,
> Peter Hendler/CA/KAIPERM@KAIPERM, *twclark@nmr.mgh.harvard.edu*<twclark@nmr.mgh.harvard.edu>,
> *public-semweb-lifesci@w3.org* <public-semweb-lifesci@w3.org>, *
> public-semweb-lifesci-request@w3.org*<public-semweb-lifesci-request@w3.org>
> Subject
> Re: Wait a sec...What about the HL7 RIM An Universal Exchange Language
>
>
>
>
>
>
>
>
> I like Eric Neumann's description of RDF as "recombinant data".
>
> Agreed. Choosing something other than HL7 as the lingua franca for
> assertions doesn't devalue HL7! We can be happy that we got the information
> from one machine to another! It's a long haul from the days of big-endian,
> little-endian. The value is not in the messages (or message syntax) but what
> is in them (the cargo, the payload). But how will we interoperate between
> HL7 and CDISC? I suppose that an ontology will help.. BRIDG anyone ;) Cecil?
>
>
> The way that XML quietly infiltrated all our computer systems was by making
> it easy to describe and parse data of all shapes and sizes. Will OWL/RDF do
> the same by making it reasonably easy to describe the meaning of messages
> and documents?
>
> HL7 isn't going away. It is the standard. So, how can its users take
> advantage of other (non-HL7) sources of information that are related to the
> contents of its messages? And how can other systems, for example, clinical
> research systems relate their information and constraints to HL7 data? See
> *http://hcls.deri.org/coi/demo/* <http://hcls.deri.org/coi/demo/> (makes
> use of pseudo-CDISC and HL7, and Drug Ontology), presented at AMIA. There
> should be machine-readable and reason-able links from one set of assertions
> to the other, that can make use of context (read: provenance). Could the HL7
> provenance help us make use of the 'cargo' in another context? i.e.
> assertion came from message issued by..
>
> -Scott
>
> --
> M. Scott Marshall, W3C HCLS IG co-chair, *http://www.w3.org/blog/hcls*<http://www.w3.org/blog/hcls>
> Leiden University Medical Center / University of Amsterdam*
> **http://staff.science.uva.nl/~marshall*<http://staff.science.uva.nl/%7Emarshall>
>
> On Thu, Dec 16, 2010 at 11:06 PM, conor dowling <*
> conor-dowling@caregraf.com* <conor-dowling@caregraf.com>> wrote:
>
>
> On Wed, Dec 15, 2010 at 8:47 AM, Michael Miller <*
> mmiller@systemsbiology.org* <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*<public-semweb-lifesci-request@w3.org>[mailto:
> *public-semweb-lifesci-request@w3.org*<public-semweb-lifesci-request@w3.org>]
> *On Behalf Of **Peter.Hendler@kp.org* <Peter.Hendler@kp.org>*
> Sent:* Wednesday, December 15, 2010 8:18 AM*
> To:* *markw@illuminae.com* <markw@illuminae.com>*
> Cc:* *public-semweb-lifesci@w3.org* <public-semweb-lifesci@w3.org>; *
> public-semweb-lifesci-request@w3.org*<public-semweb-lifesci-request@w3.org>;
> *twclark@nmr.mgh.harvard.edu* <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* <markw@illuminae.com>*>*
> Sent by: *public-semweb-lifesci-request@w3.org*<public-semweb-lifesci-request@w3.org>
>
> 12/14/2010 06:44 PM
>
>
>
>  To "Tim Clark" <*twclark@nmr.mgh.harvard.edu*<twclark@nmr.mgh.harvard.edu>>
>  cc *public-semweb-lifesci@w3.org* <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....
>
>
>
>
>
>
>