Semantic Web Health Care and Life Sciences Interest Group Teleconference -- 05 Jul 2016

FHIR on schema.org

Last week's discussion: https://www.w3.org/2016/06/28-hcls-minutes.html#item06

marc: started 2012 discussing the schema, EU-funded SALUS project
... Goal was to exchange healthcare data between 7 universities, to make automated EHR data processing in semantic way, but data was not in the same format.
... When formalizing the data, we found that each institution used local semantics. We said why not use the same predicates and classes, used schema.org
... It was adopted and very flexible, but the initial purpose of schema.org was to help web indexing.
... We kind of hijacked it for this purpose, to express healthcare data and exchange it.
... Cleveland Clinic is putting data on the web this way, marking up web pages of disease, and beyond.
... Not all data that are marked up with schema.org are exchanged of course, much is private.
... But we exchanged between these universities, using strict security policies, but the power of using schema.org in helping people to exchange data and speaking the same way was important.

<alex_> David where can I see the data that CC is putting on the web marked in this way

marc: SALUS project closed in 2015, then we discussed with schema.org the lack of properties and classes. Mapped to SNOMED CT. Decided to make a dedicated extension.

<alex_> where is the salus extension?

marc: First step is almost finished, extracted all medical terms in schema.org and make a baseline extension.
... Next step is to fine-tune the definitions.
... Then we want to extend the vocab to add new terms and types based on use cases.
... When we started working with FHIR, in the schema.org format, I was happy because it was something to show. How we do that is not yet defined. But the purpose itself is the discussion.

alex: where can I look at the SALUS extensions?
... The ones done for schema.org?

<Marc_Twagirumukiza> http://health-lifesci.schema.org/

marc: This is a hosted extension, by schema.org, but the content is maintained by W3C community

<Marc_Twagirumukiza> content maintained by : https://www.w3.org/community/schemed/

<renato_> Yahoo!

marc: Hosted by google, ms, Yandex, etc.

renato: I've been the most vocal about this issue. Want to give my background.

<Marc_Twagirumukiza> It is was initiated and supported by the Google, Microsoft, Yahoo and later on joined by Yandex.

renato: My concern is the FHIR ont being republished on schema.org, primarily because I still don't understand the purpose for doing that.
... When you have an ont an existing community gropu has the resources to publish it, not sure why you would want replicate it on schema.org for the purpose of "semantic interop". I don't see how it helps in that case.
... It causes duplicate URIs to maintain. Public vs private data, etc. Why replicate the same FHIR ont verbatim on schema.org? How does that benefit the community?

marc: Was also discussing this with Harold. He started making FHIR on schema.org.
... The purpose was to find use cases where having data expressed in FHIR should also vice versa keeping it into the schema.org format.
... Not yet to duplicate the ont -- helping exchanging data into schema expressions.
... How we do it is not yet defined. Need to discuss it.
... maybe map the concepts in FHIR to schema.org vocab or vice versa. Need to discuss it.
... Purpose is not to duplicate, but to help interop, to exchange data that you have expressed in FHIR, to easiliy express it in schema.org

grahame: Not clear what are the use cases to map or interop or transform between schema.org frame of reference and a FHIR frame of reference.
... Anytime you map from one thing to another, you live in either or a third.
... FHIR is quickly making backward incompatible changes.
... Publishing anything on schema.org is problematic.
... because if you have a choice of two vocabs, you need to publish in one or another or a third. If you publish in both at the same time, you have a lot of permutations.
... Not clear which version of FHIR is on schema.org.
... What is the policy?

<Zakim> ericP, you wanted to mention the value of reusing the publication tooling

grahame: Like to have the uses first, then discuss how.

eric: Motivation: part is growing commuinty that understands the publication mechanism of schema.org. Cost of diffusion -- two diff schemas. Mitigated by schema.org points to regular FHIR ont, which are canonical URIs, which means schema.org is really only doc.
... COuld use existing terms that others are using -- familiarity.
... Biggest question is if you have google app in your infra and you have clinical records on that private network, using schema.org, would that google appliance give good results?
... That motivates the process.

renato: Trying to understand, what marc said earlier, about expressing stuff in fhir making it easier to express in schema.org.
... When you express in schema.org you're using microdata, URIs with properties and classes. Don't see how it helps, given you have the fhir ont, and you want to exchange that by using schema.org URIs.
... What are you trying to exchange, in actual data?

<Marc_Twagirumukiza> schema.org is available in both format: rdf/turtle (unofficial yet) /json and of course RDFa and Microdata

<Marc_Twagirumukiza> http://topbraid.org/schema/

renato: Vocab has been defined in OWL. When you exchange data you need to use microdata or RDFa, or JSON-LD.
... Confused about why, if you have FHIR data, would you express it in schema.org?

marc: In the coming days, the most extensive ways of using data in mobile phones and APIs, why not express your data in the best way, the right way?
... Already tools can be used. Why not use them? Why use another tool that uses FHIR?
... We now have schema.org in Turtle and JSON, and FHIR also is in Turtle now.
... Huge opportunity to converge those two.
... People who have their data in FHIR, two doctors exchanging using PDA, allow them to use FHIR [without forcing a new app]

renato: Exchanging data is one thing, but understanding it is totally different.
... If there are lots of tools that understand schema.org, and we extend schema.org, and magically those tools now understand it, that sounds scary.
... I don't see how that can even work.

marc: We had this problem in the SALUS project.
... The machine should understand not only the syntax, but that is done. We need not to express the data semantically.
... Schema.org is added on top, to express the semantics.
... using schema.org
... We added the semantics and linked to SNOMED CT.
... as equivalent class. Then the machine understands.

renato: Need to understand what you mean by "adding semantics to schema.org".
... Why is schema.org enabling you to add semantics, and not FHIR?

marc: How we do that is to be discussed. Either from FHIR itself, or through schema.org..
... But the important point is the utility of doing that.

grahame: It would be nice if we did fold the work together, and put a real project together to put semantics into the FHIR framework, so that it comes from the source.
... We have a lot of impetus around FHIR. But it is for the EHR data we have, not what we wish we had.

<Zakim> ericP, you wanted to ask if there's actual harm in doing a strawman

grahame: If you work inside the framework it is harder work, but you get more done.

eric: Is there actual harm in trying this as a straw man? Use it as bait to draw out use cases.
... Concerned that endorsement might encourage communities to drop FHIR in favor of schema.org?
... But if it is just a straw man, would it seem harmful?

renato: problem with the web is that once yoiu publish it is hard to get rid of it.
... If we decided later to get rid of them all 6 months later, there could be harm.
... But I'd rather see, where would be the best place to do this work?
... If you use schema.org and experiment over there? Or step inside the FHIR ont and see if you can use that?
... I.e., work on improving that?
... I would think that, given scarce resources, would be better to play with FHIR ont for experimentation.
... I don't see a lot of work being done on FHIR ont from semantic viewpoint.
... I would rather see us work more on that than spreading our resources out.

<Zakim> ericP, you wanted to ask about semantics

eric: This was not a diversion of resources from the FHIR ont work, it was something harold was doing for a Mayo deliverable.

<Grahame_Grieve> "got all harold about it" - rofl

eric: Not really a diversion.

<ericP> for future readers, note that "got all harold about it" was conveyed as a complement

marc: initial purpose of using schema.org was NOT to publish it on the web, but to use it privately, so that someone else with a mobile phone or laptop can easily use your data.
... But Cleveland Clinic is doing it, and clinicaltrials.gov is doing that.
... But publishing the data on the web is not the primary purpose, it is to make the data more easily exchangeable.

<Zakim> ericP, you wanted to mention e.g. CDC use cases scraping twitter for bio surveillance

renato: That's fine, but why can't you do that using FHIR ont?

marc: We can, but we are afraid that people would rather use schema.org than FHIR
... Most APIs will not consume FHIR directly.
... To help consume that data, the tools will be extensive [using schema.org]

<Zakim> ericP, you wanted to mention e.g. CDC use cases scraping twitter for bio surveillance

eric: CDC looking at twitter, and lots of people sharing data on the web.

marc: Currently have openclinicaltrials, to put that data on the web.
... BioCaddie, part of BD2K effort. DataMed also.

<ericP> biocaddie

marc: In hospital we are using web-based clinical decision support.

renato: To the next level, if the vocab is not on schema.org then people won't use it?
... e.g., mobile phone APIs won't handle it if it isn't on schema.org
... But still trying to understand why FHIR would stop those use cases.
... If CDC were looking on twitter to see if people are coughing too much, would they not do that if they weren't using schema.org? Have they never heard of FHIR?
... We should promote FHIR for that use.

<Zakim> ericP, you wanted to say that CDC use case involves people sharing structured data

eric: I agree. But the use case is not that nobody would use FHIR, but some APIs would be written to use schema.org -- they'll cater to it.
... Also, CDC use case is not that they need a landing pad for their data, but that people sharing structured info will be orders of magnitude more likely to find it if it's on schema.org

<ericP> dbooth: next steps?

<renato_> +1

<ericP> ... should we try to schedule another call at this same time?

Next Steps

dbooth: Meet again next week, same time?

grahame: would like to see more mapping work

marc: Suggest harold to find a clear use case. He was looking at CLeveland Clinic.

<renato_> 2 weeks time is good

dbooth: July 19, 8am?

eric: Tempted to wait for Harold and then schedule followup call

<renato_> Work on FHIR Onto first ;-)

dbooth: Okay, we'll wait on scheduling until we hear from Harold. :)

ADJOURNED

<trackbot> Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference

<trackbot> Date: 05 July 2016

================ 5pm Call ===================

Issues list: https://github.com/w3c/hcls-fhir-rdf/issues

Should a type arc be required on the target of a FHIR reference?

https://github.com/w3c/hcls-fhir-rdf/issues/25

eric: Grahame, harold and I agreed that a type is not needed on a reference target explicitly, because the reference property already tells you that it is a resource, and you'll have the resource type if the resource itself is loaded.
... I.e., removed fhir:PatientReference type arc. And even if you do not include the target patient, you need to have the type for it.

dbooth: would that require all of shex to be loaded?

eric: we're saying that Medication.recipient needs to be a ref to something that is a provider. It kicks the can down the road.

dbooth: How do you resolve the problem of requiring the target resource in shex?

eric: We'll need two different forms of shex.

bob: when you say schema, do you mean RDF schema?

eric: No, shex.

dbooth: We should be able to tell people how to validate, if they have a Medication loaded, but not the referenced Patient.

Bob: recommend spark schema language

eric: We could say, for MedicationDispense, that the recipient must have either a type patient or provider or something that *is* a patient or provider.
... i.e., if you have anything in addition to a type arc Patient, then it must match the patient shape.

dbooth: That sounds like it would address both needs.

eric: That's done by declaring it CLOSED if it is only the type arc.
... We might also want CLOSED in the case of the full Patient record, for restrictive validation.

FHIR Extensions

eric: Harold and I have been working on a couple of forms of extensions. Need to be able to validate it, and turn it back to XML/JSON.
... Both are doable in shex.

<ericP> generic tests

dbooth: would be good to be able to round-trip arbitrary extra RDF to FHIR JSOn/XML as FHIR extensions.

<ericP> dosage instruction with modified schedule

eric: Harold's technique moves the modified timing inside.
... If you have two modifier extensions, one that says something was not asked or N/A. Or "I know it is not X". But it's vanishingly rare to have another modifier ext that will interact with the other modifier.
... Extremely rare to have to code around two modifiers at once.
... But could say "modifiedModifiedTiming"
... You're using the mutability of types for nonmonotonicity.

bob: Domain and coding knowledge should be done by different people.
... Would be nice to bring these languages together.
... looking for guidance on how to code XML to be reasonably usable by you people.
... Trying to get these systems to work together.
... On v3 I got turned off with two letter abbreviations and UPPER/lower case distinctions.
... Readibility is important.

<ericP> Constallations doc

eric: If you look at that doc, you'll see 4 columns.

- DRAFT -

Semantic Web Health Care and Life Sciences Interest Group Teleconference

05 Jul 2016

Attendees

Contents

FHIR on schema.org

Next Steps

================ 5pm Call ===================

Should a type arc be required on the target of a FHIR reference?

FHIR Extensions

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output