Re: FHIR on schema.org

> 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.

(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?

> 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 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.

> 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)?

> 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).

Cheers - Renato

Received on Friday, 3 June 2016 03:53:24 UTC