Re: HL7/W3C FHIR/RDF properties

On 15 February 2018 at 19:39, Eric Prud'hommeaux <eric@w3.org> wrote:

> * João Moreira (UTwente) <j.luizrebelomoreira@utwente.nl> [2018-02-15
> 11:28+0100]
> >  Dear,
> >
> > I've been studying the current version of FHIR RDF ("Structural
> Ontology")
> > serialized as TTL ( http://build.fhir.org/fhir.ttl ) and I identified
> two
> > issues regarding the properties:
> >
> > (1) I wonder why each object property was specialized according the
> source
> > "concept" (term)? For example:
> > - "fhir:AllergyIntolerance.reaction.description"
> > - "fhir:Account.description"
> > - "fhir:ActivityDefinition.description"
> >
> > In my opinion, this has the advantage of organizing and specializing the
> > property for each concept, i.e. the "description" property of
> > ActivityDefinition has different semantics (meaning) of the "description"
> > property of Account. On the other hand, with this approach we make the
> > ontology more complex (bigger), lose extensibility and knowledge
> discovery.
> > A simple example: if you want to query all objects that has description
> > "XPTO" you'll need to specify each ".description" in the SPARQL (as
> > commonly done in relational DB/SQL).
> >
> > This is not limited to the properties ".description", there are plenty of
> > other examples, e.g. location, note, created, comment, identifier, etc.
>
> I completely agree with your appraisal; the schema would be much
> better if "we" took the time to come up with the minimal set of
> properties to capture the semantics and share those properties between
> different resources. The problem that the current editing mechanism
> doesn't capture this.
>
> You may think of the FHIR/RDF task force as being responsible for
> minting predicates and imposing a sensible model. In fact, resource
> authoring happens by task forces composed of domain experts who think
> in terms of FHIR ElementDefinitions. There is currently no process for
> getting the clinical observation folks together with the clinical
> procedure folks to decide that they have certain properties in common
> and we are NOT invited to make those calls on our own. So in effect,
> we have a very conservative (in that it conserves everything) mapping
> from pairs of a class and locally-scoped property to global URLs which
> preserve both elements of that pair. (IIRC, this mapping pretty
> closely mirrors the model used in OMG's ODM, which you can also see in
> the BRIDG model.)
>
> I believe Tony Mallia (Cc'd) reviewed the bulk of the resources to
> see what date-like predicates there were and found ~ six different
> semantics spread across I don't know how many unique property names.
> Dropping the domain name from the property would have the unfortunate
> affect of merging those together.
>
> There is hope, however. FHIR architects want to raise the bar in order
> to capture the fact that multiple resources have properties with the
> same semantics. The W5 vocabulary represents a start on this but I
> don't believe a significant fraction of the task forces have reviewed
> those properties enough to say that "yes, that's what we meant; the
> common term should be used instead of ours."
>
>
I think I understood the problem, so maybe it is better to break this
effort in some steps.
First of all, the conservative approach doesn't seem to employ best
practices of ontology engineering, it sounds more engineering of
XSD/relational DB and, as a consequence, impacts on the benefits of an
ontology. If this is a rigid procedure that can't be changed, then it is
better to not go on with this effort. Otherwise, I'd suggest to "start
small" by grouping the most "straightforward" properties, as the ones I
mentioned (description, link, url, name, title), e.g.:
.
description: fhir:CapabilityStatement.rest.security.description,
fhir:CodeSystem.description, fhir:CodeSystem.property.description,
etc.
>From this inventory, the task force can analyze whether the properties
really share the same semantics and, then, discuss the impact on changing.
I think W5 is indeed a nice starting point, but it is difficult to see
the equivalent
properties with this format.
In general, I recommend to re-analyze all properties towards a more concise
and "semantically-rich" list of properties, I think this has a high
importance for a better acceptance from ontologists. I propose adapting the
current methodology with the so-called "ontological analysis" and
"ontology-driven conceptual modelling" (from the researches of Nicola
Guarino and Giancarlo Guizzardi).



> It's worth noting that since all the juicy semantics are in the
> terminologies, reuse or subsumption in the information model won't
> enable many clinical use cases. Ontologies like SNOMED-CT and HPO
> already do a good job with those. I think the biggest ROI on a
> better-engineered FHIR/RDF vocabulary will be in abstracting (and
> ideally simplifying) some workflow use cases, e.g. employing generic
> tracking for fulfillment of medication orders and procedure orders.
>

I agree with you and I think that it worth investing in (stress) examples
reusing controlled vocabularies as SNOMED-CT and ICD with FHIR/RDF.
Regarding the idea of simplifying workflow use cases, I strongly recommend
a recent PhD thesis from the group of Frank van Harmelen (VU Amsterdam):
"Zamborlini, V. (2017). Knowledge Representation for Clinical Guidelines -
with applications to Multimorbidity Analysis and Literature Search":  public
<http://dare.ubvu.vu.nl/handle/1871/55356> (some of the chapters are
published papers with embargo)


>
>
> > (2) A common approach in ontology engineering is to reuse predicates from
> > other ontologies, as in [1], especially the ones that are standardized
> > (e.g. from W3C, RDFS, Dublin Core, etc). For example, "description",
> > "title", "issued", etc are properties already standardized within DC
> terms (
> > http://dublincore.org/2012/06/14/dcterms). Why not reusing these
> properties
> > instead of creating new ones? Ultimately, this can improve the
> > interoperability capability of the ontology. I understand when we need to
> > specialize a property for something specific of the health domain, but
> > anyway, in this case we can still use a standardized property and
> > specialize it, e.g. if there is the specific limit of text length of
> > "fhir:DocumentReference.description", we can specialize it as a
> > "dc:description" and add an axiom limiting the text size.
>
> Many organizations feel more comfortable owning their vocabulary so I
> don't know how this will shake out. That said, if we factor some or
> all of the resource-specific properties into generic properties, it
> shouldn't matter if a few (very few, I expect) come from outside
> vocabularies. Once again, use cases will likely affect these decisions
> as much as aesthetics will.
>
>
I can understand, but this behavior can lead to ontologies that don't
represent common understanding.
However, I think that if we can deal with the #1, this will come almost
naturally.


>
> > - ACTION:
> > I propose to: (a) make a list of the properties that have the same
> meaning
> > in FHIR; (b) check whether these properties are already provided in other
> > standardized ontologies; and (c) discuss how to change the FHIR RDF
> > ontology, i.e. exchange the existing properties for the ones found.
>
> I think w5 is a great place to start.
>   <http://build.fhir.org/w5.html>
> and look for "identity": "w5" mappings in e.g.
> <http://build.fhir.org/observation.profile.json.html>
>
>
> > Best regards,
> >
> > João Moreira
> > University of Twente
> >
> >
> > [1]
> > https://github.com/DTL-FAIRData/FAIRDataPoint/wiki/
> FAIR-Data-Point-Specification
> >
> >
> > >
>
> --
> -ericP
>
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
>
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
>
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
>