Renato requested through private email that I respond to this message on
these lists, so . . .
On 06/02/2016 11:52 PM, Renato Iannella wrote:
On 2 Jun 2016, at 12:55, David Booth <[email protected]> wrote:
To my mind, the publication of a *vocabulary* is completely
different from the publication of data that is expressed using that
vocabulary. I am not understanding why you are concerned about the
publication of a *vocabulary*. What harm do you think would be
caused by the publication of a healthcare vocabulary on schema.org
that is fully aligned with a widely used healthcare standard?
The understanding is clear if you understand the *purpose* and scope
of Schema.Org (see https://schema.org/docs/faq.html#0) Vocabs are
published there to create instance data for markup on public webpages
(for search engines and others to use, if at all). The publication of
a schema.org vocab is saying to the web community…here is how you
publish data about this area on public web pages. (and typically, the
community publishing the vocab does not have its own infrastructure
and governance.)
By HL7/W3C publishing the FHIR Ontology on Schema.Org we are saying
that it is now possible to publish personal eHealth records on public
web pages. For example, you can publish a FHIR Procedure resource
with the (mandatory) subject/patient as part of the markup data on a
webpage.
Correct. Again: what harm do you think is caused by that?
Giving people a vocabulary for publishing eHealth records is *not* the
same as publishing those records. It simply provides a consistent
*vocabulary* for publishing data *when* it is appropriate to do so.
Teaching someone how to drive a car does not mean that we are
encouraging them to drive off of a cliff.
(Also, as an aside, the *FHIR Ontology* is *not* "a widely used
healthcare standard”…yet :-)
The schema.org vocabulary already allows phone numbers to be
expressed: https://schema.org/telephone Phone number can be
intentionally or unintentionally made either be public or private,
just as healthcare data can.
Yes, but what is the *purpose* of the telephone property Versus the
*purpose* of the FHIR Procedure? Why would you publish a person's
(FHIR) Procedure on a web page?
The issue here is not the choice of information, since medical
procedures and phone numbers can already be published in plain English
prose, without the use of a controlled vocabulary. What's new is that
we are considering the use of particular controlled vocabulary -- FHIR
-- that is likely to be widely used in healthcare. The reason for using
this vocabulary is the exact same reason for publishing anything with a
controlled vocabulary: to accurately convey the information in machine
processable form.
Some common reasons why health data is legitimately published:
- It is test data.
- It is de-identified data, for research.
- The individual it's about wants to publish it. For example, he/she
may have a rare disease and wants others to help seek a cure for it.
No, exactly the opposite. The point is to *not* make a new
vocabulary.
But you are. The second you mint the schema.org/fhir/* URIs for the
vocab terms…you just created *another* vocabulary (to maintain,
govern, etc).
The point is to make them synonyms -- not to define or maintain them
independently.
There are pros and cons of creating alternate URIs in schema.org for
existing FHIR concepts.
Some pros:
- They become easy for users of schema.org, many of whom are unlikely
to know or use any other vocabulary.
- They get a broader audience using the *same* concepts, which will
hopefully prevent that audience from creating new concepts with
inconsistent, overlapping meanings.
Some cons:
- They require two URIs to be recognized for a concept, instead of one.
- They must be maintained, as synonyms, without diverging. (This
should probably be done through a semi-automated process.)
The point is to make the vocabulary in schema.org exactly match the
vocabulary in FHIR -- not have schema.org use a different and
conflicting vocabulary of its own. The schema.org URIs would be
synonyms for FHIR URIs.
My point is that you *do not* need to do that. We already have the
HL7 FHIR URIs for the vocab. Use that.
I will, thank you. But you are unlikely to get people who *only* use
the schema.org vocabulary to use the FHIR vocabulary. And there are
likely to be far more of them than FHIR users.
Agreed, and it may not be the best choice. But to my mind there
can only be benefit in encouraging the used of *shared* concepts
rather than having each new vocabulary inventing its own concepts
that overlap and conflict with existing concepts that are already
defined in other standards.
We both agree then, schema.org is not a vocab mapping tool/service.
Broadly, semantic interoperability: enabling the exchange of data
with shared meaning.
Sure, that’s a goal. But what is/are the use case(s)?
Quoting from the wikipedia entry on Semantic Interoperability:
https://en.wikipedia.org/wiki/Semantic_interoperability
[[
Importance
The practical significance of semantic interoperability has been
measured by several studies that estimate the cost (in lost efficiency)
due to lack of semantic interoperability. One study,[4] focusing on the
lost efficiency in the communication of healthcare information,
estimated that US$77.8 billion per year could be saved by implementing
an effective interoperability standard in that area. Other studies, of
the construction industry[5] and of the automobile manufacturing supply
chain,[6] estimate costs of over US$10 billion per year due to lack of
semantic interoperability in those industries. In total these numbers
can be extrapolated to indicate that well over US$100 billion per year
is lost because of the lack of a widely used semantic interoperability
standard in the US alone.
]]
Above I mentioned three common reasons for publishing healthdata (test
data, de-identified data for research, individuals who wish to publish
their own data). I think it is also important to look in the aggregate
a the problem of achieving semantic interoperability. As explained here
http://yosemiteproject.org/2015/webinars/standardize/
one of the key things needed in the long run is semantic convergence of
concepts across vocabularies, i.e., to converge on a common set of
concepts that are used by all healthcare vocabularies.
But alignment with existing standards whenever possible is still
beneficial.
Which exisiting standards do you want the FHIR Ontology to align to?
To summarise, if the purpose is to map the FHIR Ontology to other
related concepts in exisiting ontologies, then we can do that either
in the FHIR Ontology (or the others can refer to the FHIR ontology
URIs)…or we can create a new SKOS ontology that maps between them
(and hosted/governed by HL7).
No, I don't think that is the purpose in this case. The purpose is to
align *other* vocabularies with the FHIR vocabulary, in this case the
schema.org vocabulary.
I hope that helps, and I hope you will be able to join tomorrow's call
to discuss views, possibilities, pros and cons.
Thanks,
David Booth
Cheers - Renato
