This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

ITS WGM Minutes 2019 Jan

From HL7Wiki
Jump to navigation Jump to search

Return to: WGM Minutes > 2019 > January San Antonio

Return to: ITS Main Page > WGM Minutes

ITS - San Antonio, TX - January 2019

Tuesday, January 15


chair: Paul Knapp scribe: Andy Stechishin

Motion: Recirculation ballot on FHIRPath Bryn/Vassil 7-0-0

Review of FHIRPath showed 39 new comments, Vassil raised that perhaps a new ballot could be performed rather than a recirculation ballot. Many of the new items are enhancements and corrections to the test specification. There was also discussion about the de-scoping from normative portions of the specification that likely should not be considered as normative content.

An exercise to identify sections that should be down-scoped to STU which would help resolve some of the outstanding normative contents. The decision on needing a new ballot or proceeding to publication with down-scoping will be passed to the CTO and TSC Chair. the identified sections are:

  • convertTo operators
  • 7.1 Aggregate
  • 10.2 Reflection

Motion: Reconsider the recirculation ballot for FHIRPath durint Q4 Vassil/Bryn 8-0-0

Motion: table the recirculation ballot motion until Q4 Andy/Brian 8-0-0


chair: Andy Stechishin scribe: David Booth

RDF Sub-Group


  • <inserted> Axel Reichwein: Eng background, interop and integration, using RDF. Curious to see what healthcare is doingn with RDF. Could be collab opportunities.
  • <inserted> Ian Braun: Bioinformatics student, Iowa State, works in Carolyn Lawrence-Dill, using ont to rep phenotypes. Undergrad biochem, minor CS.

Minutes Review

Motion: Approve Nov 13 ( and Jan 8 ( minutes as posted Harold/Brian 5-0-1

Background and status of FHIR/RDF

harold: Some links need to be updated on FHIR/RDF page, including updating link to C3C CG instead of IG. ... to date we have been making an official RDF representation for FHIR. ... All of the examples and resources in the FHIR build are available in RDF.

Ian Braun: Bioinformatics student, Iowa State, works in Carolyn Lawrw, using ont to rep phenotypes. Undergrad biochem, minor CS.

<vassil> Vassil Peytchev for the record FHIR "ontology" (though Harold doesn't like calling it that) is here:

michael: Restarted effort to put RDF into .NET API for FHIR.

harold: Slide shows ... Why RDF and FHIR? Provenance for FHIR text. FHIR requires a narrative section for human reading. No way to easily trace that to find out where they got it. ... RDFa could be used to do that. ... Another is markup for personal device. ... CCD , markup for blogs, medical knowledge, reasoning about stuff in FHIR. ... An interesting example is shown on the Yosemite Project site.

harold: FHIR/RDF allows reasoner to find cases diagnosed with kinds of cancer.

harold: Also working w bioinformatics group that is using knowledge graphs to work with phenotypical, environmental, etc data and figure out interesting things. Weak spot right now is observations, which are in FHIR. So they're excited about that.

eric: Re attaching types to connect SNOMED terminology to FHIR types, which allows you to do reasoning that gets around the terminfo problem. ... FHIR in Solid? For small scales FHIR could be used for EMR. Easy to map it to a file system. ... Linked Data Platform provides easy way to store and access things.

paul: FHIR is intended for transmission, not storing.

harold: RDF seems to have real potential as a backing store. Other interesting thing: triple soup. FHIR has chosen to partition the info certain ways, with links between them. If you start storing them as triples, the RDF is designed (patient & observation), when you're browsing them through SPARQL you don't know when you have crossed the boundary, and this is pretty interesting for secondary use. ... Looking at aggregating and reshuffling clinical info into de-identified and aggregated form, and that requires transform and mapping and RDF seems to be a real possibility.

eric: Nice thing about RDF -- no compositional models for XML or JSON (gotta define it for every app) -- but for RDF it is so simple we forget to mention it. ... Easy to query. In XML yuou neeed special code when you cross the resource boundary. But in RDF it is just a big graph.

harold: But we don't have a lot of demos. ... BTW, for servers that do not read/write RDF, there are servers that can do the conversion.

david: Need help on some of the FHIR servers to add full support for RDF.

axel: We would be interested in helping with that.

michael: VONK (FHIR .NET server) we are adding RDF support using .Net standard and .Net core.

harold: One of the platforms for secondary use is I2B2. They are approaches for querying data for secondary use. There's huge interest in mapping them to FHIR. ... I2B is built on a slim metamodel. Similar to subject-predicate-object. We took fhir.ttl and represented it in the I2B2 ont, and demonstrated that you could move data from FHIR into I2B2.

eric: Significant: You're loading it non-arbitrarily. Two people entering the data would give you interop.

harold: Common problem w I2B2 is that two people cannot share their data because they are modeled differently. ... FHIR already does a whole lot of these models done. Want to reuse them. And RDF depends on that.

david: Anyone specifically interested in FHIR for aggregate / secondary use?

paul: Maybe CDC would be interested.

harold: Fundamental issue. RDF in a grant proposal doesn't win you favors. There's some pushback. But in the translator community, we deal with RDF concepts but represent it differently, calling it knowledge graphs.

paul: such is marketing!

harold: When someone gets a DB running you forget that it exists. E.g., wikidata is RDF-backed. ... It's a combination of digesting the wikipedia data. ... Interestingly, they've been heavily in the medical domain, such as pubmed and genomic ontologies.

(harold shows slide from Life Sciences RDF conference)

harold: We've built FHIR/RDF, and waiting for people to come.

michael: Dutch channel was just asking about FHIR/RDF. ... There is interest!

eric: People I'm working with on FHIR/RDF cannot talk publically about it yet. ... Also was just at a mtg on the Personal Health Train, and people said that it is still in its infancy, and people said they'll be using FHIR/RDF. But again, they're not ready to deploy.

axel: In engineering there is an effort using RDF, but not attractive to majority of developers and REST APIs, but when they talk to their internal dev teams they get a negative response because RDF is not attractive enough. Competing with other graph technology, for example, that are more cool. Need to present RDF use cases in an objective way.

harold: RDF is a means to an end. Yosemite Project website does a great job of talking about that. ... One unfortunate thing, looked at using a JSON-LD @context for FHIR, but JSON-LD did not have the features we needed to do that. ... Should we push the FHIR feature that we need to the JSON-LD 1.1 work?

david: Yes, absolutely.

eric: Need context-sensitive properties. Are they in there?

david: IDK, but we should push it.

harold: In my community, JSON is dead, everyone is moving to YAML.

andy: YAML and JSON are compatible. YAML is a subset.

(harold shows slide about grahame's statement)

harold: Should FHIR/RDF continue to exist? If so, how do we convince grahame that there are 30 people rather than 3 people interested?

andy: Grahame needs to focus on things where he will get 1000 small teams or 2-3 big teams implementing it.

paul: tell grahame there are more people doing RDF than Delphi Pascal. :)

andy: People writing in JSON or YAML are in their home base, not XML.

harold: The python rdflib has made RDF relatively popular also, because it is easy to use.

eric: Solid folks are developing a large toolkit around RDF in JavaScript. ... So hopefully the stuff will look sexier soon.

andy: For quick-and-dirty languages, need to have a framework available. ... There are more than 3 people interested. But just because there aren't yet a lot of people now, there could be next year.

eric: grahame may have been hoping for RDF to do things that it is not (yet) doing. ... We have not delivered what he was hoping we would deliver, but it is useful to us.

harold: status of FHIR Python?

andy: For big-enterprise languages (e.g., java), there is an official framework. But not for Ruby. ... But there is a testing framework for FHIR in Ruby. How? They wrote their own!

harold: I have extensive FHIR librarys for python. ... These days Java is not a big RDF language.

david: But the most mature RDF library is probably jena, under apache, in java.

andy: If grahame needs somethign that hasn't been delivered. Delivering it may re-invigorate his interest. Like open source working for the company: You convince the company that the open source work benefits the company. Same situation may apply to grahame.

harold: Chicken-and-egg problem: grahame's comment prevented me from getting funding for the HAPI server.

paul: maybe trying to find the FHIR/RDF people in HL7 is the wrong place to look, like Axel on today's call.

harold: translator community is interested in FHIR because of the RDF format available.

brian: Contractors to VA may also be interested. Keith Campbell might be interested. Or Ken Rubin.

Next steps

harold: One key is to work on the HAPI server, to add RDF support. ... Also clean up the issues list. Need to get all the HL7 terminologies to OWL. ... They are the ones made by HL7. ... Code systems. They're enumerations.

david: Suggest we review next week what is needed on HL7 terminologies, to see if Ian might want to help on that.

michael: In HL7 Netherlands meeting we discussed the need for FHIR/RDF.

<scribe> ACTION: Michael to find out if someone from Maastrech could talk about FHIR/RDF need. ADJOURNED

<scribe> ACTION: David to follow up with Axel about adding RDF to HAPI server Summary of Action Items

NEW ACTION: David to follow up with Axel about adding RDF to HAPI server

NEW ACTION: Michael to find out if someone from Maastrech could talk about FHIR/RDF need.


chair: Paul Knapp scribe: Andy Stechishin

HL7 Cross Paradigm project status, Sean reviewed progress and goals of the project

Might have further progress for May although September more reasonable

There was considerable discussion on how this approach could be applied to meet the mapping requirements of FHIR resources to the RIM.


chair: Paul Knapp scribe: Andy Stechishin

The TSC Chair and CTO have determined to send thed FHIRPath descoping issue to ArB for recommendation. Following this decision the work group will choose the best path forward.

Motion: Retract the motion for the recirculation ballot Bryn/Vassil 3-0-0

Next WGM - will book the same quarters (Tuesday Q1, Q2, Q3, Q4), teleconferences will be scheduled for January 29 and February 6 and then return to the monthly schedule.


Name Init. Affiliation Email Tuesday
Q1 Q2 Q3 Q4
STECHISHIN, Andy AS CANA Software & Services Ltd. × × × ×
KNAPP, Paul PK Knapp Consulting Inc. × × × ×
PEYTCHEV, Vassil VP Epic × × × ×
PECH, Brian BP Kaiser Permanente × × ×
DONNELLY, Michael MDo Epic ×
MUIR, Sean SM JKM Software, LLC × ×
ETTEMA, Richard RE, Inc. ×
KRAMER, Ewout EK Furore ×
RHODES, Bryn BR Database Consulting Group × ×
SOLBRIG, Harold HSb Mayo Clinic ×
BRAUN, Ian IB Iowa University ×
VAN DER ZEL, Michael MV HL7 Netherlands ×
BOOTH, David DB Hokukahu ×