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
http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality
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.
Thanks,
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
