Re: FHIR on schema.org

Hi Renato,

We had some very good discussion on today's call on the background and 
uses cases that motivated the idea of putting the FHIR vocabulary on 
schema.org:
https://www.w3.org/2016/06/28-hcls-minutes.html#item05
But we were very much wishing that you could have been on the call also, 
to discuss your concerns.  I took an action to see if there we could 
arrange a special teleconference to better accommodate your timezone. 
Some proposed times:

   6pm Eastern US
   7am Eastern US
   8am Eastern US

Others on the call indicated willingness to accommodate those times if 
one of them would work for you.  Would one of those times work for you 
next Tuesday (July 5)?

Thanks,
David Booth

On 06/27/2016 02:42 PM, David Booth wrote:
> 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 Tuesday, 28 June 2016 22:12:38 UTC