12:02:44 <RRSAgent> RRSAgent has joined #hcls
12:02:44 <RRSAgent> logging to http://www.w3.org/2016/07/05-hcls-irc
12:02:46 <trackbot> RRSAgent, make logs world
12:02:46 <Zakim> Zakim has joined #hcls
12:02:48 <trackbot> Zakim, this will be HCLS
12:02:48 <Zakim> ok, trackbot
12:02:49 <trackbot> Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference
12:02:49 <trackbot> Date: 05 July 2016
12:05:52 <renato_> renato_ has joined #hcls
12:06:10 <Grahame_Grieve> Grahame_Grieve has joined #hcls
12:06:28 <alex_> alex_ has joined #hcls
12:06:50 <dbooth> Topic: FHIR on schema.org
12:06:58 <dbooth> Last week's discussion: https://www.w3.org/2016/06/28-hcls-minutes.html#item06
12:07:36 <dbooth> marc: started 2012 discussing the schema, EU-funded SALUS project
12:08:13 <dbooth> ...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.
12:08:47 <dbooth> ... 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
12:09:10 <dbooth> ... It was adopted and very flexible, but the initial purpose of schema.org was to help web indexing.
12:09:41 <dbooth> ... We kind of hijacked it for this purpose, to express healthcare data and exchange it.
12:10:03 <dbooth> ... Cleveland Clinic is putting data on the web this way, marking up web pages of disease, and beyond.
12:10:21 <dbooth> ... Not all data that are marked up with schema.org are exchanged of course, much is private.
12:10:58 <dbooth> ... 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.
12:11:35 <alex_> David where can I see the data that CC is putting on the web marked in this way
12:11:43 <dbooth> ... 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.
12:12:11 <alex_> where is the salus extension?
12:12:18 <dbooth> ... First step is almost finished, extracted all medical terms in schema.org and make a baseline extension.
12:12:29 <dbooth> ... Next step is to fine-tune the definitions.
12:12:36 <dbooth> q+ alex
12:12:54 <dbooth> ... Then we want to extend the vocab to add new terms and types based on use cases.
12:13:35 <dbooth> ... 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.
12:13:58 <renato_> q+
12:14:08 <dbooth> ack alex
12:14:28 <dbooth> alex: where can I look at the SALUS extensions?
12:14:57 <dbooth> ... The ones done for schema.org?
12:15:28 <Marc_Twagirumukiza> http://health-lifesci.schema.org/
12:16:06 <dbooth> marc: This is a hosted extension, by schema.org, but the content is maintained by W3C community
12:16:17 <Marc_Twagirumukiza> content maintained by : https://www.w3.org/community/schemed/
12:17:17 <renato_> Yahoo!
12:17:18 <dbooth> ... Hosted by google, ms, yanni, etc.
12:17:42 <dbooth> ack renato_
12:18:03 <dbooth> renato: I've been the most vocal about this issue.  Want to give my background.
12:18:23 <Marc_Twagirumukiza> It is was initiated and supported by the Google, Microsoft, Yahoo and later on joined by Yandex.
12:18:30 <dbooth> ... My concern is the FHIR ont being republished on schema.org, primarily because I still don't understand the purpose for doing that.
12:18:42 <dbooth> s/yanni/Yandex/
12:19:23 <dbooth> ... 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.
12:19:59 <Marc_Twagirumukiza> q+
12:20:08 <dbooth> ... 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?
12:20:14 <dbooth> ack Marc
12:20:21 <Grahame_Grieve> q+
12:20:36 <dbooth> marc: Was also discussing this with Harold.  He started making FHIR on schema.org.
12:21:01 <dbooth> ... The purpose was to find use cases where having data expressed in FHIR should also vice versa keeping it into the schema.org format.
12:21:23 <ericP> q+ to mention the value of reusing the publication tooling
12:21:23 <renato_> q+
12:21:24 <dbooth> ... Not yet to duplicate the ont -- helping exchanging data into schema expressions.
12:21:41 <dbooth> ... How we do it is not yet defined.   Need to discuss it.
12:22:00 <dbooth> ... maybe map the concepts in FHIR to schema.org vocab or vice versa.  Need to discuss it.
12:22:34 <dbooth> ... 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
12:22:41 <ericP> ack next
12:23:12 <dbooth> 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.
12:23:33 <dbooth> ... Anytime you map from one thing to another, you live in either or a third.
12:23:44 <dbooth> ... FHIR is quickly making backward incompatible changes.
12:23:54 <dbooth> ... Publishing anything on schema.org is problematic.
12:24:04 <Marc_Twagirumukiza> q+
12:24:55 <dbooth> ... 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.
12:25:10 <dbooth> ... Not clear which version of FHIR is on schema.org.
12:25:19 <dbooth> ... What is the policy?
12:25:24 <ericP> ack next
12:25:25 <Zakim> ericP, you wanted to mention the value of reusing the publication tooling
12:25:31 <dbooth> ... Like to have the uses first, then discuss how.
12:26:33 <dbooth> 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.
12:26:54 <dbooth> ... COuld use existing terms that others are using -- familiarity.
12:27:27 <dbooth> ... 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?
12:27:38 <ericP> ack next
12:27:40 <dbooth> ... That motivates the process.
12:27:42 <dbooth> q+
12:28:09 <dbooth> renato: Trying to understand, what marc said earlier, about expressing stuff in fhir making it easier to express in schema.org.
12:29:02 <dbooth> ... 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.
12:29:12 <dbooth> ... What are you trying to exchange, in actual data?
12:29:18 <Marc_Twagirumukiza> schema.org is available in both format: rdf/turtle (unofficial yet) /json and of course RDFa and Microdata
12:29:20 <Marc_Twagirumukiza> http://topbraid.org/schema/
12:29:42 <dbooth> ... Vocab has been defined in OWL.  When you exchange data you need to use microdata or RDFa, or JSON-LD.
12:29:57 <ericP> ack next
12:29:59 <dbooth> ... Confused about why, if you have FHIR data, would you express it in schema.org?
12:30:07 <dbooth> q-
12:31:34 <dbooth> 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?
12:31:55 <dbooth> ... Already tools can be used.  Why not use them?  Why use another tool that uses FHIR?
12:31:58 <renato_> q+
12:32:36 <dbooth> ... We now have schema.org in Turtle and JSON, and FHIR also is in Turtle now.
12:32:46 <dbooth> ... Huge opportunity to converge those two.
12:33:13 <dbooth> ... People who have their data in FHIR, two doctors exchanging using PDA, allow them to use FHIR [without forcing a new app]
12:33:20 <dbooth> ack renato
12:33:27 <ericP> ack next
12:33:51 <dbooth> renato: Exchanging data is one thing, but understanding it is totally different.
12:34:22 <dbooth> ... 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.
12:34:32 <dbooth> ... I don't see how that can even work.
12:34:58 <dbooth> marc: We had this problem in the SALUS project.
12:35:30 <dbooth> ... The machine should understand not only the syntax, but that is done.  We need not to express the data semantically.
12:35:47 <dbooth> ... Schema.org is added on top, to express the semantics.
12:35:59 <renato_> q+
12:36:01 <dbooth> ... using schema.org
12:36:21 <dbooth> ... We added the semantics and linked to SNOMED  CT.
12:36:41 <dbooth> ... as equivalent class.  Then the machine understands.
12:37:02 <dbooth> renato: Need to understand what you mean by "adding semantics to schema.org".
12:37:05 <Grahame_Grieve> q+
12:37:15 <ericP> ack next
12:37:15 <dbooth> ... Why is schema.org enabling you to add semantics, and not FHIR?
12:37:28 <ericP> ack next
12:37:46 <dbooth> marc: How we do that is to be discussed.  Either from FHIR itself, or through schema.org..
12:38:02 <dbooth> ... But the important point is the utility of doing that.
12:38:14 <ericP> q+
12:38:38 <ericP> q+ to ask if there's actual harm in doing a strawman
12:38:40 <renato_> q+
12:38:55 <dbooth> 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.
12:39:16 <dbooth> ... We have a lot of impetus around FHIR.  But it is for the EHR data we have, not what we wish we had.
12:39:38 <ericP> ack next
12:39:39 <Zakim> ericP, you wanted to ask if there's actual harm in doing a strawman
12:39:41 <dbooth> ... If you work inside the framework it is harder work, but you get more done.
12:40:09 <dbooth> eric: Is there actual harm in trying this as a straw man?   Use it as bait to draw out use cases.
12:40:33 <dbooth> ... Concerned that endorsement might encourage communities to drop FHIR in favor of schema.org?
12:40:45 <dbooth> ... But if it is just a straw man, would it seem harmful?
12:40:57 <ericP> ack next
12:41:15 <dbooth> renato: problem with the web is that once yoiu publish it is hard to get rid of it.
12:41:39 <dbooth> ... If we decided later to get rid of them all 6 months later, there could be harm.
12:41:55 <dbooth> ... But I'd rather see, where would be the best place to do this work?
12:42:29 <dbooth> ... If you use schema.org and experiment over there?  Or step inside the FHIR ont and see if you can use that?
12:42:40 <dbooth> ... I.e., work on improving that?
12:43:10 <dbooth> ... I would think that, given scarce resources, would be better to play with FHIR ont for experimentation.
12:44:13 <ericP> q+ to ask about semantics
12:44:14 <dbooth> ... I don't see a lot of work being done on FHIR ont from semantic viewpoint.
12:44:29 <dbooth> ... I would rather see us work more on that than spreading our resources out.
12:44:32 <ericP> ack next
12:44:33 <Zakim> ericP, you wanted to ask about semantics
12:45:13 <dbooth> eric: This was not a diversion of resources from the FHIR ont work, it was something harold was doing for a Mayo deliverable.
12:45:29 <Grahame_Grieve> "got all harold about it" - rofl
12:45:37 <dbooth> ... Not really a diversion.
12:46:38 <ericP> for future readers, note that "got all harold about it" was conveyed as a complement
12:47:34 <dbooth> 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.
12:47:50 <ericP> q+ to mention e.g. CDC use cases scraping twitter for bio surveillance
12:47:55 <dbooth> ... But Cleveland Clinic is doing it, and clinicaltrials.gov is doing that.
12:48:22 <ericP> ack next
12:48:22 <dbooth> ... But publishing the data on the web is not the primary purpose, it is to make the data more easily exchangeable.
12:48:23 <Zakim> ericP, you wanted to mention e.g. CDC use cases scraping twitter for bio surveillance
12:48:39 <dbooth> renato: That's fine, but why can't you do that using FHIR ont?
12:49:07 <dbooth> marc: We can, but we are afraid that people would rather use schema.org than FHIR
12:49:23 <ericP> q+ to mention e.g. CDC use cases scraping twitter for bio surveillance
12:49:29 <renato_> q+
12:49:49 <dbooth> ... Most APIs will not consume FHIR directly.
12:50:14 <dbooth> ... To help consume that data, the tools will be extensive [using schema.org]
12:50:23 <ericP> ack next
12:50:23 <Zakim> ericP, you wanted to mention e.g. CDC use cases scraping twitter for bio surveillance
12:52:06 <dbooth> eric: CDC looking at twitter, and lots of people sharing data on the web.
12:52:08 <dbooth> marc: Currently have openclinicaltrials, to put that data on the web.
12:52:12 <dbooth> ... BioCaddy, part of BD2K effort.  DataMed also.
12:52:23 <ericP> biocaddie
12:52:30 <dbooth> s/Caddy/Caddie
12:52:51 <ericP> ack next
12:52:55 <dbooth> ... In hospital we are using web-based clinical decision support.
12:53:15 <dbooth> renato: To the next level, if the vocab is not on schema.org then people won't use it?
12:53:40 <dbooth> ... e.g., mobile phone APIs won't handle it if it isn't on schema.org
12:54:04 <dbooth> ... But still trying to understand why FHIR would stop those use cases.
12:54:20 <ericP> q+ to say that CDC use case involves people sharing structured data
12:54:37 <dbooth> ... 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?
12:54:56 <dbooth> ... We should promote FHIR for that use.
12:55:00 <ericP> ack next
12:55:01 <Zakim> ericP, you wanted to say that CDC use case involves people sharing structured data
12:55:43 <dbooth> 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.
12:56:21 <dbooth> ... 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
12:56:41 <ericP> dbooth: next steps?
12:57:15 <renato_> +1
12:57:16 <ericP> ... should we try to schedule another call at this same time?
12:57:33 <dbooth> Topic: Next Steps
12:57:42 <dbooth> dbooth: Meet again next week, same time?
12:57:54 <dbooth> grahame: would like to see more mapping work
12:58:35 <dbooth> marc: Suggest harold to find a clear use case.  He was looking at CLeveland Clinic.
12:59:04 <renato_> 2 weeks time is good
12:59:40 <dbooth> dbooth: July 19, 8am?
13:00:22 <dbooth> eric: Tempted to wait for Harold and then schedule followup call
13:00:24 <renato_> Work on FHIR Onto first ;-)
13:02:51 <dbooth> dbooth: Okay, we'll wait on scheduling until we hear from Harold.  :)
13:03:39 <dbooth> ADJOURNED
13:09:14 <dbooth> Present: David Booth, EricP, Marc T, Renato Iannella, Alex Garcia
13:09:46 <dbooth> Present+ Grahame Grieve
13:13:09 <TallTed> TallTed has joined #hcls
13:21:16 <ericP> RRSAgent, please draft minutes
13:21:16 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/05-hcls-minutes.html ericP
13:26:05 <dbooth> Chair: David Booth
13:26:31 <dbooth> s/Grahame Grieve/Grahame_Grieve
13:26:45 <dbooth> rrsagent, draft minutes
13:26:45 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/05-hcls-minutes.html dbooth
15:14:01 <Zakim> Zakim has left #hcls
21:06:12 <RRSAgent> RRSAgent has joined #hcls
21:06:12 <RRSAgent> logging to http://www.w3.org/2016/07/05-hcls-irc
21:06:14 <trackbot> RRSAgent, make logs world
21:06:14 <Zakim> Zakim has joined #hcls
21:06:16 <trackbot> Zakim, this will be HCLS
21:06:16 <Zakim> ok, trackbot
21:06:17 <trackbot> Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference
21:06:17 <trackbot> Date: 05 July 2016
21:06:24 <dbooth> Topic: ================ 5pm Call ===================
21:06:31 <dbooth> Issues list: https://github.com/w3c/hcls-fhir-rdf/issues
21:09:57 <dbooth> Topic: hould a type arc be required on the target of a FHIR reference?
21:10:02 <dbooth> s/hould/Should/
21:10:09 <dbooth> https://github.com/w3c/hcls-fhir-rdf/issues/25
21:11:36 <dbooth> 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.
21:13:15 <dbooth> ... 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.
21:13:37 <dbooth> dbooth: would that require all of shex to be loaded?
21:14:24 <dbooth> 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.
21:14:57 <dbooth> dbooth: How do you resolve the problem of requiring the target resource in shex?
21:15:13 <dbooth> eric: We'll need two different forms of shex.
21:17:09 <dbooth> bob: when you say schema, do you mean RDF schema?
21:17:14 <dbooth> eric: No, shex.
21:22:39 <dbooth> dbooth: We should be able to tell people how to validate, if they have a Medication loaded, but not the referenced Patient.
21:24:41 <dbooth> Bob: recommend spark schema language
21:26:08 <dbooth> 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.
21:28:17 <dbooth> eric: i.e., if you have anything in addition to a type arc Patient, then it must match the patient shape.
21:28:44 <dbooth> dbooth: That sounds like it would address both needs.
21:29:31 <dbooth> eric: That's done by declaring it CLOSED if it is only the type arc.
21:30:27 <dbooth> eric: We might also want CLOSED in the case of the full Patient record, for restrictive validation.
21:32:14 <dbooth> Topic: FHIR Extensions
21:32:39 <dbooth> 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.
21:33:07 <dbooth> ... Both are doable in shex.
21:34:27 <ericP> -> https://github.com/jmandel/fhir-rdf/tree/master/generic/tests generic tests
21:34:55 <dbooth> dbooth: would be good to be able to round-trip arbitrary extra RDF to FHIR JSOn/XML as FHIR extensions.
21:36:22 <ericP> -> https://github.com/jmandel/fhir-rdf/blob/master/generic/tests/medicationprescription-nested-nonmon.ttl#L28 dosage instruction with modified schedule
21:38:59 <dbooth> eric: Harold's technique moves the modified timing inside.
21:40:59 <dbooth> ... 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.
21:41:09 <dbooth> ... Extremely rare to have to code around two modifiers at once.
21:41:25 <dbooth> ... But could say "modifiedModifiedTiming"
21:43:04 <dbooth> eric: You're using the mutability of types for nonmonotonicity.
21:44:07 <dbooth> bob: Domain and coding knowledge should be done by different people.
21:44:27 <dbooth> ... Would be nice to bring these languages together.
21:46:29 <dbooth> bob: looking for guidance on how to code XML to be reasonably usable by you people.
21:46:57 <dbooth> ... Trying to get these systems to work together.
21:47:56 <dbooth> ... On v3 I got turned off with two letter abbreviations and UPPER/lower case distinctions.
21:48:04 <dbooth> ... Readibility is important.
21:48:44 <ericP> -> http://www.w3.org/2016/FHIR-tutorial/Constellations Constallations doc
21:49:07 <dbooth> eric: If you look at that doc, you'll see 4 columns.
21:52:24 <dbooth> rrsagent, draft minutes
21:52:24 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/05-hcls-minutes.html dbooth
21:55:55 <dbooth> Present+ 5PM_CALL: David Booth, EricP, Brian_Scheller, Craig_Parker, Robert_Leif
22:02:34 <dbooth> rrsagent, draft minutes
22:02:34 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/05-hcls-minutes.html dbooth