Re: FHIR on schema.org

[Renato Iannella]

> On 28 Jun 2016, at 04:42, David Booth  wrote:
> 
> Correct.  Again: what harm do you think is caused by that?

People’s Privacy is harmed. Quite a big issue in some countries ;-)

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

The “when” is the issue. Since schema.org promotes the open HTML page as the 
mechanism to publish schema.org data.
Then FHIR Conformance is completely by-passed [1].

> Teaching someone how to drive a car does not mean that we are encouraging 
> them to drive off of a cliff.

Yes, but those that govern the cliff who *know* it is dangerous will deploy 
mitigation strategies (ie build a rail guard),

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

And all of these can be achieved with the normative FHIR “ontology”.

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

It is far more likely that a “user" who is publishing FHIR data would have 
intimate knowledge of the vocab from the FHIR specs themselves then from 
schema.org. 

It is scary to think that, for example, a user wrote a CDA document, and never 
referred to the CDA specification  :-)

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

So that is easily achievable in the FHIR “ontology” with outgoing references to 
the other vocabs to align to
(and/or the other vocabs can refer to FHIR “ontology" URI concepts).

Renato

[1] http://hl7.org/fhir/2016May/conformance-rules.html

Re: FHIR on schema.org

[Renato Iannella]

> On 29 Jun 2016, at 08:12, David Booth  wrote:
> 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)?

8AM Eastern US would work.

R

Re: FHIR on schema.org

[David Booth]

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

RE: FHIR on schema.org

[Michael Miller]

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:da...@dbooth.org]
> Sent: Monday, June 27, 2016 11:43 AM
> To: Renato Iannella
> Cc: i...@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 <da...@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

Re: FHIR on schema.org

[David Booth]

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

Re: FHIR on schema.org

[Renato Iannella]

> On 2 Jun 2016, at 12:55, David Booth  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

Re: FHIR on schema.org

[David Booth]

Hi Renato,

On 05/30/2016 01:43 AM, Renato Iannella wrote:



On 28 May 2016, at 00:56, David Booth  wrote:

It seems to me that privacy needs to be addressed at the level of
protocols and policies.  What are you suggesting relevant to
vocabularies, such as schema.org?


I am raising the concern that the FHIR vocabulary includes
personal/private details (eg patient etc) which is *not consistent*
with the scope and purpose of Schema.org

Schema.Org has no protocols/policies when it comes to the use of its
vocabularies (and it does not need them, as the intent is to maximise
publication of structured data).

So for privacy/policy sensitive sectors, schema.org is not the right
path.


I am having trouble understanding your concern.  Are you concerned that 
the publication of a *vocabulary* -- in this case, the schema.org 
vocabulary -- will somehow cause private information expressed in that 
vocabulary to be published unintentionally?  If so, please explain how.


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





One step toward standards convergence is to have formal semantic
linkage between vocabularies.  This is essential to prevent
babelization that would otherwise occur when yet another standard
(such as FHIR or schema.org) is defined: http://xkcd.com/927/


This is ironic then? By creating the FHIR Schema.Org vocabulary, you
just created the 101st standard to deal with?


No, exactly the opposite.  The point is to *not* make a new vocabulary. 
 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.





Once concepts from other vocabularies (such as FHIR) are brought
into a vocabulary (such as schema.org) then the overlaps and
differences between concepts become more visible, and it becomes
easier for the community to reconcile them and converge on a set of
shared concepts.


I would argue against that.


I hope you mean that you would argue against the use of schema.org, 
rather than the goal of converging on a set of shared concepts!



Schema.Org was never designed as a
vocabulary mapping tool. By “dumping” all the 101 health vocabularies
into Schema.Org will not address mappings either.


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.




SKOS should be used to express mappings. And should be maintained by
an reputable health/clinical SDO.

Also, what use cases are trying to be solved here??


Broadly, semantic interoperability: enabling the exchange of data with 
shared meaning.





There is a lot of visibility and institutional backing behind
schema.org.  Rightly or wrongly this gives it the possibility of
acting as an uber-vocabulary that spans many domains -- including
healthcare -- and helps toward standards convergence.


A lot of people get captivated by the allure of Schema.Org (must be
good if Google is doing it ;-) Schema.Org is *controlled* by a small
steering committee [1] (Search Engine representatives only). Hence,
it does not represent open consensus in standards - including the
ability to change the schemas without notice [2].


Again, it may not be the ideal choice.  But alignment with existing 
standards whenever possible is still beneficial.


David Booth




Renato


[1] http://schema.org/docs/about.html [2]
http://schema.org/docs/terms.html

Re: FHIR on schema.org

[Renato Iannella]

> On 28 May 2016, at 00:56, David Booth  wrote:
> 
> It seems to me that privacy needs to be addressed at the level of protocols 
> and policies.  What are you suggesting relevant to vocabularies, such as 
> schema.org?

I am raising the concern that the FHIR vocabulary includes personal/private 
details (eg patient etc) which is *not consistent* with the scope and purpose 
of Schema.org

Schema.Org has no protocols/policies when it comes to the use of its 
vocabularies (and it does not need them, as the intent is to maximise 
publication of structured data).

So for privacy/policy sensitive sectors, schema.org is not the right path.

> One step toward standards convergence is to have formal semantic linkage 
> between vocabularies.  This is essential to prevent babelization that would 
> otherwise occur when yet another standard (such as FHIR or schema.org) is 
> defined:
> http://xkcd.com/927/

This is ironic then? By creating the FHIR Schema.Org vocabulary, you just 
created the 101st standard to deal with?

> Once concepts from other vocabularies (such as FHIR) are brought into a 
> vocabulary (such as schema.org) then the overlaps and differences between 
> concepts become more visible, and it becomes easier for the community to 
> reconcile 
> them and converge on a set of shared concepts.

I would argue against that. Schema.Org was never designed as a vocabulary 
mapping tool.
By “dumping” all the 101 health vocabularies into Schema.Org will not address 
mappings either.

SKOS should be used to express mappings. And should be maintained by an 
reputable health/clinical SDO.

Also, what use cases are trying to be solved here??

> There is a lot of visibility and institutional backing behind schema.org.  
> Rightly or wrongly this gives it the possibility of acting as an 
> uber-vocabulary that spans many domains -- including healthcare -- and helps 
> toward standards convergence.

A lot of people get captivated by the allure of Schema.Org (must be good if 
Google is doing it ;-)
Schema.Org is *controlled* by a small steering committee [1] (Search Engine 
representatives only).
Hence, it does not represent open consensus in standards - including the 
ability to change the schemas without notice [2].


Renato


[1] http://schema.org/docs/about.html
[2] http://schema.org/docs/terms.html

Re: FHIR on schema.org

[Renato Iannella]

> On 27 May 2016, at 17:31, Marc Twagirumukiza  
> wrote:
> 
> Some of your thoughts need a deep discussions. Can you attend one of ScheMed 
> or FHIR RDF group meetings and raise such points? This will allow to 
> associate other's views as well. 

Timezones are usually the problem. Great if you are located in the Northern 
Hemisphere ;-)

Renato

Re: FHIR on schema.org

[Grahame Grieve]

>
>
> It seems to me that privacy needs to be addressed at the level of
> protocols and policies.  What are you suggesting relevant to
> vocabularies, such as schema.org?
>

well, the vocabularies often need to support this. The most relevant
thing is to tag the information with consent to share information (an
active top in FHIR right now). And we should not assume that
web = public - access to the content might be gated by Heart based
OAuth, for instance. in this context, consent to share beyond the
immediate context is pretty interesting.


>
> > For example, we already have http://hl7.org/fhir/MedicationOrder We
> > do we now need (and maintain): http://schema.org/MedicationOrder ??
>
> Great question.  There is a huge need for standards convergence, to
> facilitate semantic interoperability


yep, but I think you ducked Renato's question. Where you already
have content, then mapping, ok. but it seems retrograde to clone
content so you can map back to it?

Unless we can set up to auto-generate schema.org content, but that
sounds most difficult to me.

Grahame

Re: FHIR on schema.org

[David Booth]

On 05/27/2016 03:10 AM, Renato Iannella wrote:



On 27 May 2016, at 11:09, David Booth  wrote:



I think it is important to distinguish two separate and orthogonal
concerns:

>> 1. What data should be shared or exchanged?
>> 2. What does the data mean?
>> Security and privacy are all about #1 -- not #2.

Schema.org and healthcare vocabularies address #2 -- not #1.


I don’t think that is the case. Schema.org's dual purpose is to
"promote schemas for structured data on web pages", so this includes
the exchange of such data as a key driver behind creating the terms
on schema.org.


It is, but the purpose of promoting schemas for structured data on web 
pages is to enable shared meaning between data publishers and machine 
consumers (such as search engines), when data is exchanged between them.




Hence, whether we like it or not, just specifying personal data as a
property in schema.org does not mean we can then not address how
privacy is handled. This is especially relevant for healthcare data.


It seems to me that privacy needs to be addressed at the level of 
protocols and policies.  What are you suggesting relevant to 
vocabularies, such as schema.org?




My (other related) point is *why* do we need to create a set of
schema.org URIs for the same FHIR URIs ?

For example, we already have http://hl7.org/fhir/MedicationOrder We
do we now need (and maintain): http://schema.org/MedicationOrder ??


Great question.  There is a huge need for standards convergence, to 
facilitate semantic interoperability.  Standards convergence is the 
ultimate goal of "standardizing the standards", described here:

http://yosemiteproject.org/2015/webinars/standardize/
Standards convergence means converging on a common set of shared 
concepts that are used across standards, so that multiple standards can 
be cleanly used together as a cohesive whole, rather than acting as 
inconsistent competing standards.  (There are currently over 100 
"standard" vocabularies used in healthcare, defining overlapping 
concepts in different data formats and data models.)


One step toward standards convergence is to have formal semantic linkage 
between vocabularies.  This is essential to prevent babelization that 
would otherwise occur when yet another standard (such as FHIR or 
schema.org) is defined:

http://xkcd.com/927/

Once concepts from other vocabularies (such as FHIR) are brought into a 
vocabulary (such as schema.org) then the overlaps and differences 
between concepts become more visible, and it becomes easier for the 
community to reconcile them and converge on a set of shared concepts.


There is a lot of visibility and institutional backing behind 
schema.org.  Rightly or wrongly this gives it the possibility of acting 
as an uber-vocabulary that spans many domains -- including healthcare -- 
and helps toward standards convergence.


David Booth

Re: FHIR on schema.org

[Marc Twagirumukiza]

re:https://schema.org/Physician

Hi Renato, 
Some of your thoughts need a deep discussions. Can you attend one of 
ScheMed or FHIR RDF group meetings and raise such points? This will allow 
to associate other's views as well.

I will just make a small comment on the https://schema.org/Physician.
This need an improvements (in definition I mean) and this on way! This is 
not the only one term/Type/concept to be improved, there are couple of 
such terms under improvements. This is the work being done by ScheMed W3C 
CG.
https://github.com/schemaorg/schemaorg/issues?utf8=%E2%9C%93=Physician+
https://github.com/schemaorg/schemaorg/issues/1114
etc..

Kind Regards,

Marc Twagirumukiza



From:   Renato Iannella <r...@iannel.la>
To: "i...@lists.hl7.org" <i...@lists.hl7.org>, w3c semweb HCLS 
<public-semweb-lifesci@w3.org>
Date:   27/05/2016 09:13
Subject:    Re: FHIR on schema.org




> On 27 May 2016, at 11:09, David Booth <da...@dbooth.org> wrote:

> I think it is important to distinguish two separate and orthogonal 
concerns:
> 1. What data should be shared or exchanged?
> 2. What does the data mean?
> Security and privacy are all about #1 -- not #2. 
> Schema.org and healthcare vocabularies address #2 -- not #1.

I don’t think that is the case. Schema.org's dual purpose is to "promote 
schemas for structured data on web pages", so this includes the exchange 
of such data as a key driver behind creating the terms on schema.org.

Hence, whether we like it or not, just specifying personal data as a 
property in schema.org does not mean we can then not address how privacy 
is handled. This is especially relevant for healthcare data.

My (other related) point is *why* do we need to create a set of schema.org 
URIs for the same FHIR URIs ?

For example, we already have http://hl7.org/fhir/MedicationOrder
We do we now need (and maintain): http://schema.org/MedicationOrder
??

> They are all about creating a shared understanding of what the data 
means, in order to achieve interoperability between parties that have 
already decided to exchange data.

As an aside, look at the schema.org definition for a Physician:
  https://schema.org/Physician
I hope that is not shared too widely ;-)


Renato

Re: FHIR on schema.org

[Renato Iannella]

> On 27 May 2016, at 11:09, David Booth  wrote:

> I think it is important to distinguish two separate and orthogonal concerns:
> 1. What data should be shared or exchanged?
> 2. What does the data mean?
> Security and privacy are all about #1 -- not #2.   
> Schema.org and healthcare vocabularies address #2 -- not #1.

I don’t think that is the case. Schema.org's dual purpose is to "promote 
schemas for structured data on web pages", so this includes the exchange of 
such data as a key driver behind creating the terms on schema.org.

Hence, whether we like it or not, just specifying personal data as a property 
in schema.org does not mean we can then not address how privacy is handled. 
This is especially relevant for healthcare data.

My (other related) point is *why* do we need to create a set of schema.org URIs 
for the same FHIR URIs ?

For example, we already have http://hl7.org/fhir/MedicationOrder
We do we now need (and maintain): http://schema.org/MedicationOrder
??

> They are all about creating a shared understanding of what the data means, in 
> order to achieve interoperability between parties that have already decided 
> to exchange data.

As an aside, look at the schema.org definition for a Physician:
  https://schema.org/Physician
I hope that is not shared too widely ;-)


Renato

Re: FHIR on schema.org

[David Booth]

On 05/26/2016 08:16 PM, Renato Iannella wrote:



On 26 May 2016, at 17:42, Marc Twagirumukiza
> wrote:

However it's the responsibility of every one to make its data public
or not.
This doesn't prevent us to provide a*way of expressing data*(for those
who want to do so) with FHIR standard usingschema.org 


I think the onus is on the spec development side to show how privacy
issues are addressed (mitigated).
Hence, using “Privacy-By-Design” principles [1] (for example).

The current FHIR core spec uses a secure protocol for exchange of data
(ie good design) for XML/JSON.
But if we then say - here is how you encode FHIR data in public web
pages and publish schema.org  URIs - then we must be
able to specifically address these privacy concerns. (I imagine a lot of
Privacy Advocacy groups would be interested if they saw that.)


I think it is important to distinguish two separate and orthogonal concerns:

 1. What data should be shared or exchanged?

 2. What does the data mean?

Security and privacy are all about #1 -- not #2.   Schema.org and 
healthcare vocabularies address #2 -- not #1.  They are all about 
creating a shared understanding of what the data means, in order to 
achieve interoperability between parties that have already decided to 
exchange data.  This is completely orthogonal to the question of whether 
that data should be shared or exchanged.


Privacy-By-Design principles are very relevant to protocol 
specifications, but they are not very relevant to vocabularies whose 
purpose is to enable shared understanding of data meaning.


David Booth





Just for your example, we are already expressing our internal
healthcare data (and EHR data) usingschema.org
(although they are not public).
This has a benefit when we need to share such data with another APIs
and there HL7 FHIR comes in as a standard.


Does that mean you are encoding FHIR Data using RDFa/Microdata? (and
using schema.org  URIs for all the FHIR concepts?)

Cheers - Renato

[1] https://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/

Re: FHIR on schema.org

[Renato Iannella]

> On 26 May 2016, at 17:42, Marc Twagirumukiza  
> wrote:
> 
> However it's the responsibility of every one to make its data public or not. 
> This doesn't prevent us to provide a way of expressing data (for those who 
> want to do so) with FHIR standard using schema.org  

I think the onus is on the spec development side to show how privacy issues are 
addressed (mitigated).
Hence, using “Privacy-By-Design” principles [1] (for example).

The current FHIR core spec uses a secure protocol for exchange of data (ie good 
design) for XML/JSON.
But if we then say - here is how you encode FHIR data in public web pages and 
publish schema.org URIs - then we must be able to specifically address these 
privacy concerns. (I imagine a lot of Privacy Advocacy groups would be 
interested if they saw that.)

> Just for your example, we are already expressing our internal healthcare data 
> (and EHR data) using schema.org  (although they are not 
> public). 
> This has a benefit when we need to share such data with another APIs and 
> there HL7 FHIR comes in as a standard. 


Does that mean you are encoding FHIR Data using RDFa/Microdata? (and using 
schema.org URIs for all the FHIR concepts?)

Cheers - Renato

[1] https://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/ 

Re: FHIR on schema.org

[Grahame Grieve]

thanks. I'll chat to Harold

Grahame


On Thu, May 26, 2016 at 6:31 PM, Marc Twagirumukiza <
marc.twagirumuk...@agfa.com> wrote:

> Hi Graham,
> Thanks for this additional info.
> The topic was discussed in last 'Semantic Web Health Care and Life
> Sciences Interest Group Teleconference' with the ongoing work from Harold
> Solbrig and Quoqian Jiang team wrt FHIR RDF Group. I do not know if there's
> specifically someone from FHIR involved yet.
> See point 3 of the minutes:
> https://www.w3.org/2016/05/24-hcls-minutes.html
>
> From health-lifesci.schema.org side ( extension lead by ScheMed W3C CG
> https://www.w3.org/community/schemed/ & http://health-lifesci.schema.org
> ) I had preliminary discussion with the Harold team and now we have to find
> a way forward.
> There's already very interesting exploration and PoC as you will see in
> pointers from the minutes.
>
> Kind Regards,
>
> * Marc *
>
>
>
> From:Grahame Grieve <grah...@healthintersections.com.au>
> To:Marc Twagirumukiza/AXPZC/AGFA@AGFA
> Cc:r...@iannel.la, "i...@lists.hl7.org" <i...@lists.hl7.org>, w3c
> semweb HCLS <public-semweb-lifesci@w3.org>
> Date:26/05/2016 10:16
> Subject:Re: FHIR on schema.org
> Sent by:graha...@gmail.com
> --
>
>
>
> people are already trying to use FHIR as a standard for sharing their
> healthcare data for research. While organizations can't share other
> people's data in public, there's plenty of anecdotal evidence that the
> people will do it themselves. So the use case isn't impossible, it's only a
> policy question, as Marc says
>
> I'm interested in finding out more about this, how *schema.org*
> <http://schema.org/> works with FHIR - is someone from the FHIR community
> involved in this effort?
>
> Grahame
>
>
> On Thu, May 26, 2016 at 5:42 PM, Marc Twagirumukiza <
> *marc.twagirumuk...@agfa.com* <marc.twagirumuk...@agfa.com>> wrote:
> Hi Renato,
> I quite understand your concern. We need to discuss deeply this esp. wrt
> the requirements of the W3C Privacy review (understand and implications) .
> However it's the responsibility of every one to make its data public or
> not.
> This doesn't prevent us to provide a *way of expressing data* (for those
> who want to do so) with FHIR standard using *schema.org*
> <http://schema.org/>
> Exposing this to public it's another story and we are not constraining
> people to do so. But expressing it (probably share it, under precise
> privacy constrains- between APIs) should be encouraged.
>
> Just for your example, we are already expressing our internal healthcare
> data (and EHR data) using *schema.org* <http://schema.org/> (although
> they are not public).
> This has a benefit when we need to share such data with another APIs and
> there HL7 FHIR comes in as a standard.
>
> Kind Regards,
>
> * Marc Twagirumukiza *
>
>
>
> From:Renato Iannella <*r...@iannel.la* <r...@iannel.la>>
> To:"*i...@lists.hl7.org* <i...@lists.hl7.org>" <*i...@lists.hl7.org*
> <i...@lists.hl7.org>>, w3c semweb HCLS <*public-semweb-lifesci@w3.org*
> <public-semweb-lifesci@w3.org>>
> Date:26/05/2016 02:04
> Subject:FHIR on  *schema.org* <http://schema.org/>
> --
>
>
>
> I would like to raise a concern about the FHIR on Schema.Org proposal [1]
> discussed at the last teleconference [2].
>
> The issue is about the conflicting purposes of the two. Schema.org is
> (primarily) about publishing structured data via public web pages for
> improved search engine experiences. FHIR is (primarily) about healthcare
> data about people.
>
> Clearly, there is a significant Privacy issue with FHIR data, that should
> *not* be made on public web pages (for Goggle/Bing to consume),
>
> How will this issue be addressed?
>
> (As it stands, the proposal would not meet the requirements of the W3C
> Privacy review [3].)
>
> Renato
>
> [1] *http://fhir.fhir-schema-org.appspot.com/*
> <http://fhir.fhir-schema-org.appspot.com/>
> [2] *https://www.w3.org/2016/05/24-hcls-minutes.html#item03*
> <https://www.w3.org/2016/05/24-hcls-minutes.html#item03>
> [3] *https://www.w3.org/TR/security-privacy-questionnaire/*
> <https://www.w3.org/TR/security-privacy-questionnaire/>
>
>
> ***
> *Manage your subscriptions* <http://www.hl7.org/listservice> | *View the
> archives* <http://lists.hl7.org/read/?forum=its> | *Unsubscribe*
> <http://www.hl7.org/tools/unsubscribe.cfm?email=grah...@healthintersections.com.au=its>
> | *Terms of use*
> <http://www.hl7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>
>
>
>
> --
> -
> *http://www.healthintersections.com.au*
> <http://www.healthintersections.com.au/> /
> *grah...@healthintersections.com.au* <grah...@healthintersections.com.au>
> / +61 411 867 065
>
>


-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065

Re: FHIR on schema.org

[Marc Twagirumukiza]

Hi Graham,
Thanks for this additional info.
The topic was discussed in last 'Semantic Web Health Care and Life 
Sciences Interest Group Teleconference' with the ongoing work from Harold 
Solbrig and Quoqian Jiang team wrt FHIR RDF Group. I do not know if 
there's specifically someone from FHIR involved yet.
See point 3 of the minutes:
https://www.w3.org/2016/05/24-hcls-minutes.html

>From health-lifesci.schema.org side ( extension lead by ScheMed W3C CG 
https://www.w3.org/community/schemed/ & http://health-lifesci.schema.org ) 
I had preliminary discussion with the Harold team and now we have to find 
a way forward.
There's already very interesting exploration and PoC as you will see in 
pointers from the minutes.

Kind Regards,

Marc 



From:   Grahame Grieve <grah...@healthintersections.com.au>
To: Marc Twagirumukiza/AXPZC/AGFA@AGFA
Cc: r...@iannel.la, "i...@lists.hl7.org" <i...@lists.hl7.org>, w3c semweb 
HCLS <public-semweb-lifesci@w3.org>
Date:   26/05/2016 10:16
Subject:Re: FHIR on schema.org
Sent by:graha...@gmail.com



people are already trying to use FHIR as a standard for sharing their 
healthcare data for research. While organizations can't share other 
people's data in public, there's plenty of anecdotal evidence that the 
people will do it themselves. So the use case isn't impossible, it's only 
a policy question, as Marc says 

I'm interested in finding out more about this, how schema.org works with 
FHIR - is someone from the FHIR community involved in this effort?

Grahame


On Thu, May 26, 2016 at 5:42 PM, Marc Twagirumukiza <
marc.twagirumuk...@agfa.com> wrote:
Hi Renato, 
I quite understand your concern. We need to discuss deeply this esp. wrt 
the requirements of the W3C Privacy review (understand and implications) . 

However it's the responsibility of every one to make its data public or 
not. 
This doesn't prevent us to provide a way of expressing data (for those who 
want to do so) with FHIR standard using schema.org 
Exposing this to public it's another story and we are not constraining 
people to do so. But expressing it (probably share it, under precise 
privacy constrains- between APIs) should be encouraged. 

Just for your example, we are already expressing our internal healthcare 
data (and EHR data) using schema.org (although they are not public). 
This has a benefit when we need to share such data with another APIs and 
there HL7 FHIR comes in as a standard. 

Kind Regards,

Marc Twagirumukiza 



From:Renato Iannella <r...@iannel.la> 
To:"i...@lists.hl7.org" <i...@lists.hl7.org>, w3c semweb HCLS <
public-semweb-lifesci@w3.org> 
Date:26/05/2016 02:04 
Subject:FHIR on  schema.org 



I would like to raise a concern about the FHIR on Schema.Org proposal [1] 
discussed at the last teleconference [2].

The issue is about the conflicting purposes of the two. Schema.org is 
(primarily) about publishing structured data via public web pages for 
improved search engine experiences. FHIR is (primarily) about healthcare 
data about people.

Clearly, there is a significant Privacy issue with FHIR data, that should 
*not* be made on public web pages (for Goggle/Bing to consume),

How will this issue be addressed?

(As it stands, the proposal would not meet the requirements of the W3C 
Privacy review [3].)

Renato

[1] http://fhir.fhir-schema-org.appspot.com/
[2] https://www.w3.org/2016/05/24-hcls-minutes.html#item03
[3] https://www.w3.org/TR/security-privacy-questionnaire/

***

Manage your subscriptions | View the archives | Unsubscribe | Terms of use



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au 
/ +61 411 867 065

Re: FHIR on schema.org

[Grahame Grieve]

people are already trying to use FHIR as a standard for sharing their
healthcare data for research. While organizations can't share other
people's data in public, there's plenty of anecdotal evidence that the
people will do it themselves. So the use case isn't impossible, it's only a
policy question, as Marc says

I'm interested in finding out more about this, how schema.org works with
FHIR - is someone from the FHIR community involved in this effort?

Grahame


On Thu, May 26, 2016 at 5:42 PM, Marc Twagirumukiza <
marc.twagirumuk...@agfa.com> wrote:

> Hi Renato,
> I quite understand your concern. We need to discuss deeply this esp. wrt
> the requirements of the W3C Privacy review (understand and implications) .
> However it's the responsibility of every one to make its data public or
> not.
> This doesn't prevent us to provide a *way of expressing data* (for those
> who want to do so) with FHIR standard using schema.org
> Exposing this to public it's another story and we are not constraining
> people to do so. But expressing it (probably share it, under precise
> privacy constrains- between APIs) should be encouraged.
>
> Just for your example, we are already expressing our internal healthcare
> data (and EHR data) using schema.org (although they are not public).
> This has a benefit when we need to share such data with another APIs and
> there HL7 FHIR comes in as a standard.
>
> Kind Regards,
>
> * Marc Twagirumukiza *
>
>
>
> From:Renato Iannella 
> To:"i...@lists.hl7.org" , w3c semweb HCLS <
> public-semweb-lifesci@w3.org>
> Date:26/05/2016 02:04
> Subject:FHIR on  schema.org
> --
>
>
>
> I would like to raise a concern about the FHIR on Schema.Org proposal [1]
> discussed at the last teleconference [2].
>
> The issue is about the conflicting purposes of the two. Schema.org is
> (primarily) about publishing structured data via public web pages for
> improved search engine experiences. FHIR is (primarily) about healthcare
> data about people.
>
> Clearly, there is a significant Privacy issue with FHIR data, that should
> *not* be made on public web pages (for Goggle/Bing to consume),
>
> How will this issue be addressed?
>
> (As it stands, the proposal would not meet the requirements of the W3C
> Privacy review [3].)
>
> Renato
>
> [1] http://fhir.fhir-schema-org.appspot.com/
> [2] https://www.w3.org/2016/05/24-hcls-minutes.html#item03
> [3] https://www.w3.org/TR/security-privacy-questionnaire/
>
>
> ***
> Manage your subscriptions  | View the
> archives  | Unsubscribe
> 
> | Terms of use
> 
>



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065

Re: FHIR on schema.org

[Marc Twagirumukiza]

Hi Renato,
I quite understand your concern. We need to discuss deeply this esp. wrt 
the requirements of the W3C Privacy review (understand and implications) . 

However it's the responsibility of every one to make its data public or 
not. 
This doesn't prevent us to provide a way of expressing data (for those who 
want to do so) with FHIR standard using schema.org
Exposing this to public it's another story and we are not constraining 
people to do so. But expressing it (probably share it, under precise 
privacy constrains- between APIs) should be encouraged.

Just for your example, we are already expressing our internal healthcare 
data (and EHR data) using schema.org (although they are not public).
This has a benefit when we need to share such data with another APIs and 
there HL7 FHIR comes in as a standard.

Kind Regards,

Marc Twagirumukiza 



From:   Renato Iannella 
To: "i...@lists.hl7.org" , w3c semweb HCLS 

Date:   26/05/2016 02:04
Subject:FHIR on  schema.org



I would like to raise a concern about the FHIR on Schema.Org proposal [1] 
discussed at the last teleconference [2].

The issue is about the conflicting purposes of the two. Schema.org is 
(primarily) about publishing structured data via public web pages for 
improved search engine experiences. FHIR is (primarily) about healthcare 
data about people.

Clearly, there is a significant Privacy issue with FHIR data, that should 
*not* be made on public web pages (for Goggle/Bing to consume),

How will this issue be addressed?

(As it stands, the proposal would not meet the requirements of the W3C 
Privacy review [3].)

Renato

[1] http://fhir.fhir-schema-org.appspot.com/
[2] https://www.w3.org/2016/05/24-hcls-minutes.html#item03
[3] https://www.w3.org/TR/security-privacy-questionnaire/