W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > December 2014

Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / W3C HCLS COI call -- Review of FHIR ontology approaches (cont.)

From: David Booth <david@dbooth.org>
Date: Sun, 21 Dec 2014 11:54:34 -0500
Message-ID: <5496FB4A.5090406@dbooth.org>
To: public-semweb-lifesci@w3.org
Hi Matthias,

You're touching on an important point that I think we have not yet 
articulated well enough.

No *single* ontology will meet all of the diverse use cases that occur 
in healthcare and biomedical applications.  That's obvious at one level, 
but less obvious -- though still true -- even when we look specifically 
at FHIR.  Different ontologies will be needed for different FHIR use 
cases.  This is one of the fundamental reasons that translations will 
always be needed, no matter how good our standardization efforts are. 
(See slides 10-17 of
http://dbooth.org/2014/yosemite/yosemite-project-slides.pdf )  But if we 
acknowledge the inevitable need for model and vocabulary translations 
for specific use cases, and we avoid the trap of deluding ourselves into 
thinking that we *can* create a FHIR ontology that will meet all use 
cases ( see http://xkcd.com/927/ ), then I think we can create a FHIR 
ontology that meets the single most important use case that it MUST 
meet: that it can act as a hub ontology for FHIR within a hub-and-spoke 
collection of *other* ontologies that will better address specific 
diverse use cases.  (See slide 35 of
http://dbooth.org/2014/yosemite/yosemite-project-slides.pdf )

If we think of the FHIR ontology merely as a hub ontology (for FHIR -- 
not for everything) then I think our use of RDF can also help us escape 
the rat holes of the bike shed effect
that result if we tried to make a FHIR ontology that is stylistically 
resonant with different people's favorite use cases.  Standards 
committees can spend endless hours arguing over such "trivialities" as 
syntax and names for things -- matters that are trivial in one sense, 
because those details can be easily and mechanically swapped, but 
non-trivial in another sense if people need to use them directly, 
because of human factors.  For spoke ontologies that will be touching 
end uses of the data, such matters become more important and thus *need* 
to be worked out as well as possible.  But for a hub ontology whose 
primary purpose is simply to faithfully capture all of the semantics to 
support all of those spoke ontologies, those matters become less 
important.  This is why I think we have a good chance of avoiding many 
of those bike shed debates if we think of our FHIR ontology in this way.

David Booth

On 12/21/2014 01:08 AM, Matthias Samwald wrote:
> Dear all,
> I have hardly participated in any of the calls lately and am coming at
> this as a bit of an outsider. From my reading it indeed seems that any
> officially accepted RDF version of FHIR data would use a code + code
> system representation of 'concepts' from controlled vocabularies /
> ontologies. In this case, however, I doubt that the added benefit of
> having an RDF version  is rather minimal and does not outweigh the added
> complexity of an additional representation besides XML and JSON.
> The potential benefit of FHIR over other existing approaches (such as
> some previous HL7 standards) is simplicity and accessibility through
> standard tooling.
> The potential benefits of an RDF/OWL representation of health data are
> bridging the data model-terminology gap, an intuitive representation of
> medical information and easy querying and interlinking of the resulting
> data via intuitive SPARQL queries.
> I hope I'm wrong, but my impression is that a simple, mostly syntactic
> mapping of FHIR in RDF might end up having neither of these qualities,
> combining the worst rather than the best of both worlds. A more
> sophisticated mapping, on the other hand, might not allow round-tripping
> the data and would probably not be accepted as part of the official FHIR
> project.
> Am I overly sceptical here?
> With kind regards,
> Matthias Samwald
Received on Sunday, 21 December 2014 16:55:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:21:45 UTC