Re: FHIR on schema.org

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 <david@dbooth.org> 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
>
>

Received on Monday, 27 June 2016 18:43:16 UTC