Agenda Aug 4 HL7 RDF / W3C COI: FHIR RDF - xsd:decimal and precision

Next Topic
 
classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

Renato Iannella-6

> On 27 May 2016, at 11:09, David Booth <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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&q=Physician+
https://github.com/schemaorg/schemaorg/issues/1114
etc..

Kind Regards,

Marc Twagirumukiza




From:        Renato Iannella <[hidden email]>
To:        "[hidden email]" <[hidden email]>, w3c semweb HCLS <[hidden email]>
Date:        27/05/2016 09:13
Subject:        Re: FHIR on schema.org





> On 27 May 2016, at 11:09, David Booth <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

David Booth-6
In reply to this post by Renato Iannella-6
On 05/27/2016 03:10 AM, Renato Iannella wrote:
>
>> On 27 May 2016, at 11:09, David Booth <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

Grahame Grieve-3
In reply to this post by Renato Iannella-6

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

Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

Renato Iannella-6
In reply to this post by Marc Twagirumukiza

On 27 May 2016, at 17:31, Marc Twagirumukiza <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

Renato Iannella-6
In reply to this post by David Booth-6

> On 28 May 2016, at 00:56, David Booth <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

HL7/W3C Agenda Tue May 31: ShEx validation of FHIR RDF and FHIR on schema.org

David Booth-6
In reply to this post by David Booth-6
Agenda:

  - ShEx validation of FHIR RDF (Harold / Grahame)

  - ShEx validator service (EricP)

  - FHIR on schema.org (Harold)

We have two teleconferences each Tuesday:

  - Tuesdays, 11:00am Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=mcb82c729c6b6de936cf8c7eb3854fdd6
Meeting number: 644 184 695
Teleconference: +1-617-324-0000 Access code: 644 184 695
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

  - Tuesdays, 5:00pm Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=m5cd1bd8bb36825b9c4b369fd664bbb62
Teleconference: +1-617-324-0000 Access code: 645 777 110
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

Agenda page:
http://wiki.hl7.org/index.php?title=ITS_RDF_ConCall_Agenda

Thanks!
David Booth




































Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

David Booth-6
In reply to this post by Renato Iannella-6
Hi Renato,

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

>
>> On 28 May 2016, at 00:56, David Booth <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

Renato Iannella-6

> On 2 Jun 2016, at 12:55, David Booth <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

HL7/W3C Agenda Tue Jun 7: ShEx validation of FHIR RDF and FHIR on schema.org

David Booth-6
In reply to this post by David Booth-6
Sorry to get this out so late!

Agenda:

  - ShEx validation of FHIR RDF (Harold / Grahame)

  - ShEx validator service (EricP)

  - FHIR on schema.org (Harold)

We have two teleconferences each Tuesday:

  - Tuesdays, 11:00am Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=mcb82c729c6b6de936cf8c7eb3854fdd6
Meeting number: 644 184 695
Teleconference: +1-617-324-0000 Access code: 644 184 695
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

  - Tuesdays, 5:00pm Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=m5cd1bd8bb36825b9c4b369fd664bbb62
Teleconference: +1-617-324-0000 Access code: 645 777 110
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

Agenda page:
http://wiki.hl7.org/index.php?title=ITS_RDF_ConCall_Agenda

Thanks!
David Booth






































Reply | Threaded
Open this post in threaded view
|

Fwd: HL7/W3C Agenda Tue Jun 7: ShEx validation of FHIR RDF and FHIR on schema.org

David Booth-6
Agenda:

  - ShEx validation of FHIR RDF (Harold / Grahame)

  - ShEx validator service (EricP)

  - FHIR on schema.org (Harold)

We have two teleconferences each Tuesday:

  - Tuesdays, 11:00am Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=mcb82c729c6b6de936cf8c7eb3854fdd6
Meeting number: 644 184 695
Teleconference: +1-617-324-0000 Access code: 644 184 695
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

  - Tuesdays, 5:00pm Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=m5cd1bd8bb36825b9c4b369fd664bbb62
Teleconference: +1-617-324-0000 Access code: 645 777 110
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

Agenda page:
http://wiki.hl7.org/index.php?title=ITS_RDF_ConCall_Agenda

Thanks!
David Booth








































Reply | Threaded
Open this post in threaded view
|

HL7/W3C Agenda Tue Jun 21: ShEx validation of FHIR RDF and FHIR on schema.org

David Booth-6
Agenda:

  - ShEx validation of FHIR RDF (Harold / Grahame)

  - ShEx validator service (EricP)

  - FHIR on schema.org (Harold)

We have two teleconferences each Tuesday:

  - Tuesdays, 11:00am Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=mcb82c729c6b6de936cf8c7eb3854fdd6
Meeting number: 644 184 695
Teleconference: +1-617-324-0000 Access code: 644 184 695
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

  - Tuesdays, 5:00pm Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=m5cd1bd8bb36825b9c4b369fd664bbb62
Teleconference: +1-617-324-0000 Access code: 645 777 110
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

Agenda page:
http://wiki.hl7.org/index.php?title=ITS_RDF_ConCall_Agenda

Thanks!
David Booth










































Reply | Threaded
Open this post in threaded view
|

Re: HL7/W3C Agenda Tue Jun 21: ShEx validation of FHIR RDF -- AGENDA CORRECTION

David Booth-6
Correction to today's agenda:

On 06/20/2016 08:51 PM, David Booth wrote:
> Agenda:
>
>   - ShEx validation of FHIR RDF (Harold / Grahame)
>
>   - ShEx validator service (EricP)
>
>   - FHIR on schema.org (Harold)

We will wait until at least next week to discuss FHIR on schema.org,
since I have not yet notified Renato.

If we have extra time today, we will go over more of our issues list
backlog:
https://github.com/w3c/hcls-fhir-rdf/issues

thanks,
David Booth

>
> We have two teleconferences each Tuesday:
>
>   - Tuesdays, 11:00am Eastern US (Boston) time zone
> Webex:
> https://mit.webex.com/mit/j.php?MTID=mcb82c729c6b6de936cf8c7eb3854fdd6
> Meeting number: 644 184 695
> Teleconference: +1-617-324-0000 Access code: 644 184 695
> Meeting password: 4257 ("HCLS")
> IRC: irc.w3.org port 6665 channel #hcls
>
>   - Tuesdays, 5:00pm Eastern US (Boston) time zone
> Webex:
> https://mit.webex.com/mit/j.php?MTID=m5cd1bd8bb36825b9c4b369fd664bbb62
> Teleconference: +1-617-324-0000 Access code: 645 777 110
> Meeting password: 4257 ("HCLS")
> IRC: irc.w3.org port 6665 channel #hcls
>
> Agenda page:
> http://wiki.hl7.org/index.php?title=ITS_RDF_ConCall_Agenda
>
> Thanks!
> David Booth
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

HL7/W3C HCLS 5pm ET call on FHIR RDF CANCELED today

David Booth-6
In reply to this post by David Booth-6
Not enough people could make it.

David

-------- Forwarded Message --------
Subject: HL7/W3C Agenda Tue Jun 21: ShEx validation of FHIR RDF and FHIR
on schema.org
Date: Mon, 20 Jun 2016 20:51:36 -0400
From: David Booth <[hidden email]>
To: [hidden email] <[hidden email]>, w3c semweb HCLS
<[hidden email]>

Agenda:

  - ShEx validation of FHIR RDF (Harold / Grahame)

  - ShEx validator service (EricP)

  - FHIR on schema.org (Harold)

We have two teleconferences each Tuesday:

  - Tuesdays, 11:00am Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=mcb82c729c6b6de936cf8c7eb3854fdd6
Meeting number: 644 184 695
Teleconference: +1-617-324-0000 Access code: 644 184 695
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

  - Tuesdays, 5:00pm Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=m5cd1bd8bb36825b9c4b369fd664bbb62
Teleconference: +1-617-324-0000 Access code: 645 777 110
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

Agenda page:
http://wiki.hl7.org/index.php?title=ITS_RDF_ConCall_Agenda

Thanks!
David Booth












































Reply | Threaded
Open this post in threaded view
|

HL7/W3C Agenda Tue Jun 28: ShEx validation of FHIR RDF and FHIR on schema.org (REALLY!)

David Booth-6
In reply to this post by David Booth-6
Agenda for 11am Eastern US:

  - ShEx validation of FHIR RDF (Harold / Grahame)

  - ShEx validator service (EricP)

Agenda for 5pm Eastern US:

  - FHIR on schema.org (Harold)
We would particularly like anyone with views on the idea of putting the
FHIR vocabulary on schema.org to join the 5pm ET call to discuss it.

We have two teleconferences each Tuesday:

  - Tuesdays, 11:00am Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=mcb82c729c6b6de936cf8c7eb3854fdd6
Meeting number: 644 184 695
Teleconference: +1-617-324-0000 Access code: 644 184 695
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

  - Tuesdays, 5:00pm Eastern US (Boston) time zone
Webex:
https://mit.webex.com/mit/j.php?MTID=m5cd1bd8bb36825b9c4b369fd664bbb62
Teleconference: +1-617-324-0000 Access code: 645 777 110
Meeting password: 4257 ("HCLS")
IRC: irc.w3.org port 6665 channel #hcls

Agenda page:
http://wiki.hl7.org/index.php?title=ITS_RDF_ConCall_Agenda

Thanks!
David Booth












































Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

David Booth-6
In reply to this post by Renato Iannella-6
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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

RE: FHIR on schema.org

Michael Miller-13
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:[hidden email]]
> Sent: Monday, June 27, 2016 11:43 AM
> To: Renato Iannella
> Cc: [hidden email]; 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 <[hidden email]> 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
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

David Booth-6
In reply to this post by David Booth-6
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 <[hidden email]> 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
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

Renato Iannella-6

> On 29 Jun 2016, at 08:12, David Booth <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: FHIR on schema.org

Renato Iannella-6
In reply to this post by David Booth-6

> On 28 Jun 2016, at 04:42, David Booth <[hidden email]> 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



12345