RE: FHIR on schema.org

hi david and renalto,

it's been an interesting, and good, discussion.

> Some common reasons why health data is legitimately published:
i just wanted to add one more reason that has occurred often for me, and
that is with-in an organization health data can be exchanged, and, more
importantly, with-in a collaboration, health data can be published
privately.

cheers,
michael

> -----Original Message-----
> From: David Booth [mailto:david@dbooth.org]
> Sent: Monday, June 27, 2016 11:43 AM
> To: Renato Iannella
> Cc: its@lists.hl7.org; w3c semweb HCLS
> Subject: 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 19:05:21 UTC