ITS WGM Minutes 2017 May
Return to: WGM Minutes > 2017 > May Madrid
Return to: ITS Main Page > WGM Minutes
ITS - Madrid, Spain - May 2017
Tuesday, May 9
Q1
chair: Paul Knapp scribe: Paul Knapp
- Request the extension of the CDS vMR STU XML DTSU for another year to allow further implementer testing.
- Request a progress report to understand the nature of the delay and how that will improve the likeliness of a successful outcome at the end of the requested extension.
- Motion to accept: David/Grahame: 5-0-0
- FHIR intends to publish some of the specification as normative in the May 2018 ballot cycle:
- XML, JSON and the RESTful spec
- Motion: ITS approves the plan to have XML and JSON as normative in the next release. Grahame/David 5-0-0
- Motion: ITS approves the plan to have the RESTful specification as normative in the next release. Grahame/Robert 5-0-0
- Some members of the community which exchange very large numbers of instances at a time have requested that a Bulk data exchange format be recommended, such as Avro and Parquet, for the more efficient exchange of data. This would be included in R4.
- Grahame presented JSON Manifest solution as a means to simplify FHIR Parameters and extensions in JSON. To date the solution has received little support from the community. The committee reviewed and discussed the solution and Paul saw potential value in this strategy and asked from Grahame to not discard it yet while Paul explored and reviewed with the ITS co-chairs. This may become a subject of testing at the September connectathon. If so Paul will post a comment on the Zulip stream to invite further discussion.
Q4
chair: Paul Knapp scribe: David Booth
No Quorum, no ITS co-chair presiding, discussion only
Grahame's FHIR server
grahame: Implemented, but I'll turn it on next week.
JSON-LD format -- keep or drop?
grahame: ballot status discussion. planning to ballot the next round of FHIR for normative content. XML and JSON formats are part of what we are taking normative. We do not propose to take the RDF to normative.
AGREED: RDF format for FHIR is not ready for normative release
grahame: We published the JSON-LD format, asked at connectathon, and did not find implementers that were aware of it. They wondered why it existed. FHIR Core asked me to convey that existence of JSON-LD format is a negative because of potential for confusion, so we're asking the committee to remove it. ... Paul thought that it's too early to decide. David thought it would not be effective until release 4. Under what criteria should we keep it?
harold: I can see non-value in it. If the JSON-LD exists we need to keep it synchronized with the Turtle, which seems counter productive.
grahame: the code for both is similar.
eric: Bigger danger is that you end up being . . . . ... Value that could come of JSON-LD would come if you were using it sometimes as JSON and sometimes as RDF. But that's a long shot. Also, JSON-LD 1.1 is likely to address content model issues that prevented us from simply putting a @context on FHIR JSON to make JSON-LD.
michael: We did round-trip test to test the sync.
grahame: One other issue that Josh asked: what is valid JSON-LD if it looks like that JSON and has the correct @context , or has the same triples?
dbooth: The answer has to be "same triples", otherwise we're going in a very dangerous direction.
eric: I think the value of JSON-LD is that it can be processed as JSON.
grahame: If the JSON matters, then you might as well use FHIR JSON.
dbooth: There is purely marketing value in JSON-LD --- that it is familiiar. ... I agree with dropping it. Also would be better to do conversion to JSON-LD using a standard RDF tool such as Jena instead of building it into a FHIR referenceimplementation,
<inserted> AGREED: Drop FHIR JSON-LD format Status of C# implementation of FHIR RDF - Michael van der Zel
michael: .NET API is now updated to STU3. Now working on adding the RDF to STU3. Also tested running under Mono. Created a console app to do FHIR format conversion to/from RDF.
grahame: Planning to add to standard .NET FHIR API?
michael: Not sure. Ewout is not sure of including the dependency on the RDF library.
christiaan: dependencies are easier now in .NET
michael: Plan is to release it as a separate release, but will discuss with Ewout. ... But there are some RDF changes that I have not yet made.
dbooth: ETA?
michael: Before September.
Mini-ontology generation for status codes and other codes (Harold Solbrig)
harold: No more progress yet.
Example of connecting to external ontology -- OBO? BFO? Dublin Core?
grahame: As product director, I set the overall agenda for FHIR -- big picture changes. I've published things I want the product to improve. One item: get better ontology bindings at the base of FHIR. ... Originally I saw FHIR as a set of resources and supporting plank: conformance, REST API, ont bindings, implementation support around libraries/packaging. ... We've nailed all those except the ont part. ... Want to bind all of our definitions to underlying ont. ... Added RDF format. Two kinds of lower ont: methodology ont, like Dublin Core, for mapping definitions. ... The other is content -- clinical ont, to enable reasoning. Because we have not done any mappings to those, there is only so much we can achieve with the RDF. ... Want the community to pick an example ont and produce a good set of bindings as an example of what we want to do. ... Want to do a useful ont mapping, both methodological and clinical. Want them expressed in RDF.
harold: My demo is a start. It's taking fhir.ttl and classifying them using SNOMED, with interesting examples. That's square 0. ... Need to open to more things than SNOMED. Need to publish all the built-in FHIR valuesets in OWL so that instead of dealing with data properties we can deal with object properties. ... E.g., DiagnosticReport has several data properties that could count as Final, but aren't currently as data properties. ... Also the work with Linda Bird on FHIR templates is related, but has a drawback. ... The drawback is that the SNOMED templates can map to a limited set of OWL, but not into the disease onto or gene ont or any non-SNOMED resource that is OWL-able. ... The other thing that needs discussion: There's a huge difference between fhir.ttl, which deals with FHIR clinical records, and what the clinical records are about.
grahame: I was hoping we would target something other than SNOMED, because it isn't what they think of when they think of ont. ... What you identify as the limit to fhir.ttl is exactly what I want to change -- want to have those mappings that allow you to cross those bridges.
harold: We've been discussing where to put those bridges.
eric: Harold's SNOMED demo shows a really big win. ... If we wanted to capture W5 in a FHIR info model ont, that would enable a few use cases around processing, saying that there is a generic handler for all orders. ... If you want to bind to disease ont or something like that, SNOMED will have by far the most description of properties that appear in SNOMED resources, such as body site, laterality, etc. ... FMA might have some of those. We could bind them individually to FHIR, but we'd be saying at the same time that they corresponded between FMA and SNOMED.
grahame: Work is happening around SNOMED, and it has a habit of diappearing down a rabbit hole of complexity. ... Perhaps we want to try to represent what is being said in the templates as triples.
harold: NOt sure that a set of triples is the right idiom, but we need to be able to state it in OWL. We may have a good use case at Mayo. ... Davide Sottaro has a good use case. ... Keith Campbell gripe about SNOMED is that they do their own stuff instead of using what exists. I'd like to encourage convergence. ... I'd like to fire up a parallel project for this. ... Only one example in FHIR core of FHIR compositional grammar, and we converted it to OWL. I'd like to have an automatic conversion to turtle. ... Does the code system necessarily determine the compositional grammar? Or do we need to include a marker in it?
grahame: The pattern we have is that we have a coding (system + code) and a URL representation, which links directly into the coding system. ... Where's that example?
ken: Would SOLR work be of interest?
grahame: Harold is saying that SNOMED is sufficient.
harold: No, but it's a start. ... As soon as you get into genetics and all, SNOMED isn't used.
grahame: That's why I was hoping to jump beyond SNOMED.
harold: At the moment we're only generating URIs for LOINC and SNOMED.
grahame: I looked in Barry Smith's work, but could not find matching concepts. It's so different.
<ericP> 71341001:272741003=7771000 harold: Olivier Bodenreider has done a good write-up on the difference between SNOMED and the disease ont. ... Exmaple of observation: http://build.fhir.org/observation-example-bmd.ttl.html ... Here is the use of observation: https://github.com/BD2KOnFHIR/BLENDINGFHIRandRDF/blob/master/observation-example-bmd.ttl
grahame: I've screwed up the representation of the SNOMED expr.
harold: Michael Lawley proposed URI expression for compositional grammar -- microparsable. ... To process that in SNOMED, it needs to be in the form I posted in the URI above. ... Here is the relevant fragment:
[[
fhir: Observation.bodySite [ fhir:CodeableConcept.coding [ fhir:index 0; a sct:71341001, rdfs:subClassOf [a owl:Restriction; owl:onProperty sct:272741002; owl:someValuesFrom sct:7771000]; fhir:Coding.system [ fhir:value "http://snomed.info/sct" ]; fhir:Coding.code [ fhir:value "71341001:272741003=7771000" ] ]; fhir:CodeableConcept.text [ fhir:value "Left Femur" ] ] .
]]
grahame: SNOMED expression is discussed in zulip.
harold: Laterality is one of the few things in SNOMED that is sensible, but most things get stuck in the role-group world, which really adds problems. ... I'll talk with Quogian to see what ideas he has. Finishing getting the FHIR internal valuesets into OWL will help also. ... Working on non-SMOMED templates is interesting also.
grahame: Vocab group agreed to move everything into FHIR valuesets, including v2 v3 CDA.
harold: For folks to see, was going to generate a separate codesystem.owl to put them into a reasoner. ... Also considering an OWL format for the terminology services.
grahame: Let's start with the first step.
harold: Need to set up content negotiation also, to avoid .ttl suffix on the ont name.
grahame: Content is hosted on a server that only does conneg based on file extensions.
harold: If we had no extension, can it redirect?
grahame: Yes, with 302. I already do that depending on the content requested. I can extend that for turtle. ... Need the canonical URL to get it right the first time.
harold: We want to drop the .ttl extension.
<scribe> ACTION: Eric will work out canonical URIs and content types with Grahame, to redirect to Turtle. [recorded in http://www.w3.org/2017/05/09-hcls-minutes.html#action01] <trackbot> Created ACTION-85 - Will work out canonical uris and content types with grahame, to redirect to turtle. [on Eric Prud'hommeaux - due 2017-05-16]. FML and FTE for FHIR translation - Robert (rpworden)
robert: Have mapped to OpenEHR, but not to RDF. ... Wanted to show you mappings from OpenEHR to FHIR. ... FML is "push" style. ... FTE maps both source and target to a common class model, and then you can get bidirectional transforms. ... That's more 'pull' in character. ... FTE mappings are more fine-grained than FML. ... But they are interconvertable between FML and FTE mappings. ... Now want to show you how a FHIR transform engine has been applied to convert OpenEHR to FHIR. ... You have a source structure, and you get down to substance, for example, in allergyIntolerance. ... I mapped it to a FHIR bundle. ... You get the source and target models by reading in files, then manually map between them. ... It's a visual mapping editor that allows you to pick equivalent nodes. ... Once you have made mappings, you can test them easily. ... And you can test round-tripping. ... Synergy between FML and FTE? FML to FTE is easy; FTE to FML is harder, but I have a demo. ... The ability to convert between them allows for lots of possibilities in tools.
grahame: FML is declarative presentation of a process. You could represent that process as RDF, but that's very different from representing the relationships between them.
eric: want to understand the differences between what can be done with ISO 11179, RDF, Concept Maps, etc.
<inserted> christiaan: Licensing? robert: Free for open source efforts, but paid for commercial efforts. ADJOURNED
Summary of Action Items
[NEW] ACTION: Eric will work out canonical URIs and content types with Grahame, to redirect to Turtle. [recorded in http://www.w3.org/2017/05/09-hcls-minutes.html#action01]
Attendance
| Name | Init. | Affiliation | Tuesday | ||||
|---|---|---|---|---|---|---|---|
| Q1 | Q2 | Q3 | Q4 | ||||
| KNAPP, Paul | PK | Knapp Consulting Inc. | pknapp@pknapp.com | × | |||
| GRIEVE, Grahame | GG | Health Intersections Pty Ltd | grahame@healthintersections.com.au | × | × | ||
| WORDEN, Robert | RPW | rpworden@me.com | × | × | |||
| HAY, David | DHa | david.hay2@gmail.com | × | ||||
| SILVER, Elliot | ES | McKesson Corporation | elliot.silver@mckesson.com | × | |||
| RYZHIKOV, Nicola | NRy | Nicola@gmail.com | × | ||||
| KNAAP, Christian | CKn | Furore | c_knaap@furore.com | × | × | ||
| VAN DER ZEL, Michael | MV | HL7 Netherlands | m.van.der.zel@umcg.nl | × | |||
| BOOTH, David | DB | Hokukahu | david@dbooth.org | × | |||
| PRUDHOMME, Eric | EPr | × | |||||
| SOLBRIG, Harold | HSb | Mayo Clinic | solbrig.harold@mayo.edu | × | |||
