<trackbot> Date: 11 March 2015

Last week's notes: http://www.w3.org/2015/03/04-hcls-minutes.html

Quick hack at a FHIR ontology derived from instance data

Eric: Last week I talked about XSLT, but should have said we looked at XML data and discussed what it should look like in RDF. Then wrote code to generate them.
... Want to talk about the apparent ontology derived from that.

<ericP> goal doc

Eric: That's an example of what we want the system to generate.

<ericP> derived ontology

<ericP> derived ontology on web protege

Eric: My goal was to accept whatever FHIR puts out, and figure out what elements should have the same semantics and should be the same class.

lloyd: two phases: accept what we have; then supplement with additional metadata that helps identify it further and indicate relationships between concepts.

john: I still owe you a CCDA example. :)

<ericP> https://github.com/w3c/hcls-fhir-rdf/blob/master/generic/tests/deviceobservation-referencesToContained-ontology.ttl#L19

http://webprotege.stanford.edu/#Edit:projectId=6532219d-109d-4e7c-a7d4-f3e2b8130bea

Lloyd: There's not a proper hierarchy for resources, and DomainResource defines "contained".
... It's not in the spreadsheets, it's in the profile xml.

eric: The script that we wrote runs on the profile xml.
... Ideally we'd get this looking correct, and then have a script that generates it from the profile xml.

lloyd: From every resource there are tabs for different views, and among them is alternative representations.

eric: We concatenate that into a big doc then run the script.

lloyd: There's a pre-concatenated version available for resources, datataypes and profiles.
... They're inside a zip.

<Lloyd> http://hl7-fhir.github.io/profiles-resources.xml

eric: There are about 8 properties that seem to be shared between resources.

<Lloyd> (That one's not in a zip :))

eric: One could also say resource:...
... The benefit of that is to have a uniform way of lookingn at the data. OWL is all about having general properties that are restricted for use in specific classes.
... If not every resource uses contact or issued the same way, then we can just use resource:issued.
... E.g., if multiple FHIR docs have text properties... are they the same?

lloyd: patient.text and practitioner.text *are* the same, but patient.identifier and practitioner.identifier are not the same thing formally.
... We would have to add more info to infer that they're the same.
... we don't use hierarchy for semantic purposes, because we've been bitten by the complexity that that adds: name them same, put into abstract class, etc.
... Nice thing about RDF and OWL is that you can have two properties that mean the same thing.
... Once we get the RDF working, we can build on top to make assertions like: practitioner.identifiers and patient.identifiers are descendents of the same kind of identifier, or such.
... That's adding info to the reousrces that is not there now.

eric: where are there semantic differences because of real differences, and where are there differences only due to context?
... e.g., hasChild. Any cat that hasChild is a kitten.
... That's available to us if we want.
... I've listed 7 highly controversial things that I think are common across some resources. We can extrtact that from profile.xml once i learn how.
... Llloyd, what's already known to be shared across resources?

<Lloyd> http://hl7-fhir.github.io/resource.html

lloyd: There's the root resource.

<Lloyd> http://hl7-fhir.github.io/domainresource.html

lloyd: The above is descended from that, including narrative and text.
... Then everythign else is below that.
... 3 coding datatypes: Code, Coding, CodeableConcept (wrapper or multiple Codings). Code is for fixed display values, while others exist behind the scenes.
... Our lives would be easier if we treat Code as a Coding rather than as a string.
... Coding is a class that has a property for the code itself, plus properties for the CodeSystem, etc.
... With Code, there are properties that are fixed (and don't appear in the isntance). Display value and Valueset are fixed, and profile declares that binding.
... In the case of Code, the binding is at the resource level.
... Binding between the attribute that is codable and the valueset from which it can be drawn. If its' fixed at the resource level then you can't add any others, and the datatype is Code and System is fixed and redundant.
... But a profile may fix it.

david: How is coding system determined for code?

<Lloyd> http://hl7-fhir.github.io/elementdefinition.html

lloyd: In element definition, every property will be defined using one of these things.

<ericP> { :someNarrative Narrative:status fhir:generated . } <=> { :someNarrative Narrative:status [ CodeableConcept:coding [ fhir:system fhir:sysID, Coding:code "generated" ] ] . }

lloyd: E.g., patient.gender is type Code. Would have a binding strength=required, and a reference to the valueset definition.
... and it defines display name and URLs.
... But only the code goes over the wire.
... The element definition fixes the code system.

<ericP> { :someNarrative Narrative:status fhir:generated . }

<ericP> <=>

<ericP> { :someNarrative Narrative:status [

<ericP> CodeableConcept:coding [

<ericP> fhir:system fhir:sysID,

<ericP> Coding:code "generated"

<ericP> ]

<ericP> ] .

<Lloyd> http://hl7-fhir.github.io/patient.html

http://hl7-fhir.github.io/patient-definitions.html#Patient.gender

http://hl7-fhir.github.io/administrative-gender.html

David: Could a sender transmit a code that is ambiguous?
... due to Coding System not indicated?

lloyd: Yes, it is possible.
... But there are systems that do that.
... Good practice is to avoid it.

tony: I modeled a valueset and its terms being a disjoint union, so you could get URIs for every member of the set. URL points to the term.

<Tony> http://wiki.hl7.org/index.php?title=File:Terminology_binding_in_FHIR.pdf

lloyd: When i did this for v3 I treated codes as instances.

tony: in what i drafted, the code is an instance with a semantic type that points to the class in the valueset,.

lloyd: I treated valuesets as choices of coding instacnes.
... Codings imply concepts, which are classes, because they have hierarchy. But coming over the wire is an isntance of a coding.
... Where it gets fun is where you have equivalent codings (even possibly from the same code system). E.g., canada post: West or (Ouest in French).
... It constrains the instances but not the meaning.

tony: eric's work showed that you can transport data over the wire, and infer the type that points to the terminology class.

lloyd: Need to be careful about doing it with classess. All of your classes would have to be disjoint.

tony: trying to get valuesets kind of in line with SNOMED.

lloyd: I suspect we'll need an intermediate ont that links between SNOMED URL and what appears in FHIR RDF instacnes.

eric: Am i understanding narrativeStatus correctly? Did I map it right to codeable concept and code?

<ericP> { :someNarrative Narrative:status fhir:generated . }

<ericP> <=>

<ericP> { :someNarrative Narrative:status [

<ericP> CodeableConcept:coding [

<ericP> fhir:system fhir:sysID,

<ericP> Coding:code "generated"

<ericP> ]

<ericP> ] .

lloyd: Weird to have Coding:code and fhir:sysID.

Homework from last week

I tried make test:

$ make test

sparql -d diagnostic-report-generated.ttl -q

<scribe> Unknown argument: d

make: *** [t_diagnostic-report] Error 1

$ which sparql

<ericP> dbooth: ran $(make test) and got above error

eric: cd into the "generic" dir first

<ericP> ericP: $(cd generic && make test)

Ingeborg: Tried the homework. Got an error. Run in "generic" dir?

eric: yes. It downloads a zip of fhir definitions.

<hsolbrig> I didn't get the assignment. What is the github url?

<Lloyd> Email title: "Proposed RDF FHIR syntax feedback" Mar 7

eric: There' ssome expected diff output, because the scripts have not been updated for the latest DSTU

<hsolbrig> @Lloyd - there it is. Thnx

<ericP> rm xslt_defs.xml

eric: If you remove that file, everything will be regenerated.

David: Still getting an error:

python generate_xslt_defs.py > xslt_defs.xml

Traceback (most recent call last):

File "generate_xslt_defs.py", line 5, in <module>

from huTools.structured import dict2xml, dict2et

ImportError: No module named huTools.structured

make: *** [xslt_defs.xml] Error 1

eric: Need to figure out how to make sure you have the right python modules.

<hsolbrig> pip install <resource>

<hsolbrig> pip install hutools

<Zakim> dbooth, you wanted to say I think we should separate our task to two steps: deciding basic FHIR RDF (directly corresponding to FHIR XML or JSON) and additional ontology info that

<ericP> dbooth: let's separate into two steps:

<ericP> ... .. what FHIR/RDF do we want?

<ericP> ... .. what additional ontology info do we want?

<ericP> Lloyd: make that three:

<ericP> ... .. what do we want the instance to look like?

lloyd: Three things: what do we want instances to look like? What do we want ont for rep and valuesets? third: what addiitional stuff can we add for more value?
... We
... We'll end up with: 1. transform from FHIR XML to FHIR RDF (resource instances). 2. Conversion of profiles and datatypes, valuesetss to OWL ontology. 3. Add more metadata to make those things more useful.
... profile (now : structure defn) contains Resources, Datatypes, Constraint profiles
... will miss the next two calls.

ADJOURNED

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/valueset/datatypes, valuesets/
No ScribeNick specified.  Guessing ScribeNick: dbooth
Inferring Scribes: dbooth
Present: DBooth lloyd ericP Ingeborg hsolbrig rhausam JohnMattison Tony
Found Date: 11 Mar 2015
Guessing minutes URL: http://www.w3.org/2015/03/11-hcls-minutes.html
People with action items: