RE: HL7/W3C FHIR/RDF properties

Hi João,

Your first issue is entirely correct.
Part of the charter of the fhir/rdf project is that we would not diverge from the implied ontology of FHIR (iso-morphic) unless there was significant reason and it did not preclude round trip functionality.
There has been much discussion about the implied ontology of FHIR and how properties should be declared.
However FHIR has not adopted reusable properties and they are identified within the namespace of the entity as in UML.

The second issue is a general one facing ontologists - which is the dominant ontology?
Some discussion occurred on the use of BFO but this is a FHIR decision not ITS/RDF as in issue 1.

Tony

From: João Moreira (UTwente) [mailto:j.luizrebelomoreira@utwente.nl]
Sent: Monday, February 19, 2018 1:40 PM
To: Eric Prud'hommeaux
Cc: Anthony Mallia; public-semweb-lifesci@w3.org
Subject: Re: HL7/W3C FHIR/RDF properties



On 15 February 2018 at 19:39, Eric Prud'hommeaux <eric@w3.org<mailto:eric@w3.org>> wrote:
* João Moreira (UTwente) <j.luizrebelomoreira@utwente.nl<mailto: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<tel:%2B1.617.599.3509>
mobile: +33.6.80.80.35.59<tel:%2B33.6.80.80.35.59>

(eric@w3.org<mailto: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.