- From: Lloyd McKenzie <lloyd@lmckenzie.com>
- Date: Mon, 22 Dec 2014 10:02:12 -0700
- To: "Timothy W. Cook" <tim@mlhim.org>
- Cc: Anthony Mallia <amallia@edmondsci.com>, Vipul Kashyap <kashyap.vipul@gmail.com>, David Booth <david@dbooth.org>, w3c semweb HCLS <public-semweb-lifesci@w3.org>, HL7 ITS <its@lists.hl7.org>
- Message-ID: <CAJ860JKGz2mGAPp+JxGymaF=1dXnhAaENrPGr13-HNdbOZVeHg@mail.gmail.com>
The reference ranges would be declared as part of the observation instance - that information can change from measurement to measurement if the lab has multiple machines going, so it's not just an issue for data 10 years back. -------------------------------------- Lloyd McKenzie +1-780-993-9501 Note: Unless explicitly stated otherwise, the opinions and positions expressed in this e-mail do not necessarily reflect those of my clients nor those of the organizations with whom I hold governance positions. On Mon, Dec 22, 2014 at 9:50 AM, Timothy W. Cook <tim@mlhim.org> wrote: > > > On Mon, Dec 22, 2014 at 2:36 PM, Lloyd McKenzie <lloyd@lmckenzie.com> > wrote: > >> Hi Tony, >> >> The RDF instances would always reference the standard resource and data >> type profiles. They wouldn't ever reference narrower profiles, except >> possibly at the top level. I.e. If I've got an address, the instance will >> always refer to that as hl7:Address, never hl7NL:postalAddress, even if the >> hl7NL:postalAddress constraints apply. The knowledge that it's an >> hl7NL:postalAddress will be specified in the class ontology based on a >> profile declared by the instance. The only profiles receivers ever need to >> understand are the universal resource and data type level profiles. You >> don't need to know the specific narrow profile used by the author in order >> to parse an instance. >> >> > Interesting. So how then does a (for example) receiver of lab data 10 > years from now know what reference ranges were in place at the time the > data was recorded? This is most certainly a requirement for longitudinal > clinical decision support. > > Thanks, > Tim > > > > > > >> Business and resource identifiers in the instance data are unique >> globally (though we may have some fun dealing with the notions of "base" >> and "local" identifiers inside a bundle. . .) I don't understand how using >> RDF can aid in identity resolution given that we're not conveying any more >> information in RDF than we are in XML or JSON. (Nor are we conveying any >> more information in OWL than we are in the JSON or XML representations of >> Profile.) >> >> >> Lloyd >> >> -------------------------------------- >> Lloyd McKenzie >> >> +1-780-993-9501 >> >> >> >> Note: Unless explicitly stated otherwise, the opinions and positions >> expressed in this e-mail do not necessarily reflect those of my clients nor >> those of the organizations with whom I hold governance positions. >> >> On Mon, Dec 22, 2014 at 7:25 AM, Anthony Mallia <amallia@edmondsci.com> >> wrote: >>> >>> Hi Lloyd, >>> >>> I see the miscommunication. OWL ontologies can contain individuals, >>> classes, object properties etc. they are not just the model or metadata. >>> >>> >>> >>> I am referring to an ontology which contains only the individual data >>> and refers to types in the Profile ontology. The Profile would be another >>> ontology and would not be sent. >>> >>> So the identifiers in the instance data are unique within the ontology >>> and it is therefore like the namespace of the source system. The total >>> ontology of the source system is their EHR without considering records >>> imported from other sources. >>> >>> >>> >>> I have assumed that Profiles are created and shared between system >>> owners who want to interoperate. There must be some governance to them. >>> >>> >>> >>> Tony >>> >>> >>> >>> *From:* Lloyd McKenzie [mailto:lloyd@lmckenzie.com] >>> *Sent:* Sunday, December 21, 2014 11:28 PM >>> >>> *To:* Anthony Mallia >>> *Cc:* Vipul Kashyap; David Booth; w3c semweb HCLS; HL7 ITS >>> *Subject:* Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / >>> W3C HCLS COI call -- Review of FHIR ontology approaches (cont.) >>> >>> >>> >>> Hi Tony, >>> >>> >>> >>> I don't think I'm following. There should be no need for >>> custodian-specific ontologies. The sender never needs to identify a >>> profile in the instance. Some senders may choose to specify a profile in >>> the instance (or even 20 different profiles in the instance), but the >>> sender isn't required to pay any attention to any of them. >>> >>> >>> >>> I'm not sure how any FHIR-based ontology would help to support >>> de-duplication. >>> >>> >>> >>> Profiles aren't just created by WGs. Profiles are any statement of >>> restrictions and extensions that can be associated with a resource or data >>> type - they can be created by anyone. >>> >>> >>> >>> The FHIR RDF message will have to contain *exactly* the same information >>> that is in the JSON and XML instances - no more, no less. Otherwise we >>> can't properly round-trip. If you want to use the SNOMED ontology with an >>> instance, then you can import it yourself - it doesn't need to be imported >>> by the instance. >>> >>> >>> >>> >>> >>> Lloyd >>> >>> >>> -------------------------------------- >>> Lloyd McKenzie >>> >>> +1-780-993-9501 >>> >>> >>> >>> Note: Unless explicitly stated otherwise, the opinions and positions >>> expressed in this e-mail do not necessarily reflect those of my clients nor >>> those of the organizations with whom I hold governance positions. >>> >>> >>> >>> On Sun, Dec 21, 2014 at 11:19 AM, Anthony Mallia <amallia@edmondsci.com> >>> wrote: >>> >>> Hi Lloyd, >>> >>> >>> >>> It will be worth more discussion on the ontology structures. >>> >>> >>> >>> At the profile instance level (the FHIR RDF message) the ontologies are >>> probably associated with the custodian of the record – they assigned the >>> identities (unique within their ontology). When you query and aggregate >>> FHIR RDF records from multiple custodians you know where the record came >>> from and may have the same subject due to equivalence of the patients in >>> the different ontologies (patient matching). A custodian based ontology >>> allows the recipient to perform efficient de-duplication if they are >>> caching the records. >>> >>> >>> >>> The Profile ontology has been negotiated in a WG (the custodian) and has >>> its own ontology (and version). I am not sure if this needs to be single >>> FHIR Resource or can be across many Resources. >>> >>> >>> >>> The Terminology ontologies come from the terminology custodians. E.g. >>> IHTSDO and WHO >>> >>> >>> >>> If you don’t use the ontologies outside the FHIR RDF message then >>> redundant information needs to be put into the FHIR RDF message to be able >>> to round trip with the XML. If you are using OWL tools then importing the >>> other ontologies makes a more comprehensive view and graph aggregation is >>> natural. >>> >>> >>> >>> I don’t see why we can’t have it both ways. >>> >>> >>> >>> Tony >>> >>> >>> >>> *From:* Lloyd McKenzie [mailto:lloyd@lmckenzie.com] >>> *Sent:* Sunday, December 21, 2014 12:31 PM >>> *To:* Anthony Mallia >>> *Cc:* Vipul Kashyap; David Booth; w3c semweb HCLS; HL7 ITS >>> >>> >>> *Subject:* Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / >>> W3C HCLS COI call -- Review of FHIR ontology approaches (cont.) >>> >>> >>> >>> Hi Tony, >>> >>> >>> >>> Every profile instance will be its own ontology and will import the >>> "base" ontology it's built on top of. All instances will be bound to the >>> base resource profile, but I think we should be cautious about importing >>> referenced profiles. >>> >>> >>> >>> In FHIR you don't need to reference a profile in order to understand >>> meaning (unlike with something like CDA). If you stripped out all profile >>> references from an instance, you'd be able to reconstitute them (though in >>> some cases, doing so might be computationally intensive). Certainly in the >>> instance you would generally indicate what terminologies were used for >>> coded elements, but that doesn't mean you want the ontologies for all of >>> those terminologies to be present when you're trying to reason about an >>> instance. As Peter pointed, out, some ontologies are rather large, so you >>> should only bring them in if you need them. And there will certainly be >>> terminologies referenced in instances for which the receiver doesn't have >>> an ontology at all, so presuming to include an import just because the code >>> system was referenced would actually often break things. >>> >>> >>> >>> >>> >>> Lloyd >>> >>> >>> -------------------------------------- >>> Lloyd McKenzie >>> >>> +1-780-993-9501 >>> >>> >>> >>> Note: Unless explicitly stated otherwise, the opinions and positions >>> expressed in this e-mail do not necessarily reflect those of my clients nor >>> those of the organizations with whom I hold governance positions. >>> >>> >>> >>> On Sun, Dec 21, 2014 at 10:09 AM, Anthony Mallia <amallia@edmondsci.com> >>> wrote: >>> >>> Lloyd, >>> >>> Each Profile ( or group of profiles) would be in its own ontology which >>> might import the raw FHIR type ontology and restrict/extend it. This means >>> that when we bind from the instance to the type, the type is in the named >>> profile ontology (unambiguous). >>> >>> All importing in my approach is done by off the shelf OWL tools which >>> are an additional layer I guess. >>> >>> I don’t understand how you can be interoperable if you don’t know the >>> profile being used and the terminology terms referenced. >>> >>> >>> >>> Tony >>> >>> >>> >>> *From:* Lloyd McKenzie [mailto:lloyd@lmckenzie.com] >>> *Sent:* Sunday, December 21, 2014 12:00 PM >>> >>> >>> *To:* Vipul Kashyap >>> *Cc:* David Booth; w3c semweb HCLS; HL7 ITS >>> *Subject:* Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / >>> W3C HCLS COI call -- Review of FHIR ontology approaches (cont.) >>> >>> >>> >>> Hi Vipul, >>> >>> >>> >>> Yes, we'll be creating two different forms. Instances will be expressed >>> in RDF - and round-trippable between the JSON and XML syntaxes. At that >>> level, all you'll have is data - no "knowledge". Profiles we will also >>> convert to RDFS/OWL/something which will reflect things such as constraints >>> on instances, vocabulary bindings, etc. We may even define extensions on >>> Profile which allow us to capture additional information (e.g. hierarchy) >>> and represent that in our semantic web expressions as well. (We should >>> never include anything in our OWL expressions that isn't derivable from a >>> Profile instance because it's the Profile that is the source of truth.) >>> >>> >>> >>> @Tony: Definitely agree they'll be separate ontologies. The instance >>> ontology might import the profile ontology if the instance happens to be >>> tagged with a given profile, but my recommendation would be to leave the >>> importing to be done by an additional layer - one that knows what profiles >>> and code systems you actually care (and have access to). Relevant profiles >>> may not be referenced and not all referenced code systems will be known. >>> >>> >>> >>> >>> >>> Lloyd >>> >>> >>> -------------------------------------- >>> Lloyd McKenzie >>> >>> +1-780-993-9501 >>> >>> >>> >>> Note: Unless explicitly stated otherwise, the opinions and positions >>> expressed in this e-mail do not necessarily reflect those of my clients nor >>> those of the organizations with whom I hold governance positions. >>> >>> >>> >>> On Sat, Dec 20, 2014 at 4:35 PM, Vipul Kashyap <kashyap.vipul@gmail.com> >>> wrote: >>> >>> Thanks for the feedback and clarification – Looks like we will have to >>> work at two different layers: >>> >>> >>> >>> 1. The syntactic translation from FHIR XML/JSON to RDF/OWL – >>> >>> 2. Enrichment of the RDF/OWL representation via ontologies and >>> OWL axioms.. which is where I believe would provide the value due to >>> inferencing in a wide variety of applications –e.g., CDS, Clinical >>> Documentation, Quality Metrics, etc. >>> >>> >>> >>> Am I correct in assuming that we are focusing on (1) in this group – >>> Shouldn’t we try to do (2) as well? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> ---Vipul >>> >>> >>> >>> *From:* Lloyd McKenzie [mailto:lloyd@lmckenzie.com] >>> *Sent:* Saturday, December 20, 2014 6:15 PM >>> >>> >>> *To:* Vipul Kashyap >>> *Cc:* David Booth; w3c semweb HCLS; HL7 ITS >>> *Subject:* Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / >>> W3C HCLS COI call -- Review of FHIR ontology approaches (cont.) >>> >>> >>> >>> Well, for FHIR at a minimum, you must be able to round-trip instances. >>> And what will appear in the JSON and XML instances is the code + code >>> system (and often multiple code-code system pairs). Often, the code + >>> code system won't even link to an ontology that's known by the receiver. >>> And if we want to be able to convert v2 or v3 instances, what appears over >>> the wire there is the code + code system too. All knowledge of what the >>> binding is for an element is carried outside the instance. >>> >>> >>> -------------------------------------- >>> Lloyd McKenzie >>> >>> +1-780-993-9501 >>> >>> >>> >>> Note: Unless explicitly stated otherwise, the opinions and positions >>> expressed in this e-mail do not necessarily reflect those of my clients nor >>> those of the organizations with whom I hold governance positions. >>> >>> >>> >>> On Sat, Dec 20, 2014 at 4:07 PM, Vipul Kashyap <kashyap.vipul@gmail.com> >>> wrote: >>> >>> Not clear about the reason for this design decision – Has it been >>> discussed and agreed upon by the members of this group? >>> >>> Or is it the case that if we adopt a different approach – it will not be >>> accorded official status by the FHIR folks? >>> >>> >>> >>> BTW – It might turn out that code system + code approach is indeed >>> better – but I would love to see use cases and examples illustrating this… >>> >>> >>> >>> Thanks, >>> >>> >>> >>> ---Vipul >>> >>> >>> >>> *From:* Lloyd McKenzie [mailto:lloyd@lmckenzie.com] >>> *Sent:* Saturday, December 20, 2014 6:00 PM >>> *To:* Vipul Kashyap >>> *Cc:* David Booth; w3c semweb HCLS; HL7 ITS >>> >>> >>> *Subject:* Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / >>> W3C HCLS COI call -- Review of FHIR ontology approaches (cont.) >>> >>> >>> >>> From a FHIR (or v2 or v3) perspective, the linkage will *have* to be by >>> code + code system. That's what appears in the instance and the RDF >>> representations will need to be driven purely based on what appears in the >>> instances. The code + code system can be used to infer the concept >>> represented by the code - with all of its associated properties and >>> relationships. Essentially "all v2/v3/FHIR elements with a code = [SNOMED >>> Code X] and a code system of SNOMED_CT are specializations of the SNOMED >>> Concept X". >>> >>> >>> -------------------------------------- >>> Lloyd McKenzie >>> >>> +1-780-993-9501 >>> >>> >>> >>> Note: Unless explicitly stated otherwise, the opinions and positions >>> expressed in this e-mail do not necessarily reflect those of my clients nor >>> those of the organizations with whom I hold governance positions. >>> >>> >>> >>> On Sat, Dec 20, 2014 at 3:33 PM, Vipul Kashyap <kashyap.vipul@gmail.com> >>> wrote: >>> >>> >>> >>> VK> Partially agree with you. Another reason for taking up RDF/OWL >>> representation is to make these descriptions (business, clinical) user >>> friendly. I have added this requirement to the wiki page. >>> >>> Then we have a different notion of "user friendly" :> The RDF syntax >>> will almost certainly be less friendly for consumption than the XML >>> syntax. And in the end, the users shouldn't be consuming any of the >>> syntaxes directly - they'll be consuming interfaces that systems use to >>> expose the content, not the syntax directly. >>> >>> >>> >>> VK> I think one of the key goals of a semantic representation is to make >>> the content user friendly and also “executable” at the same time. Whereas >>> it definitely doesn’t make sense to expose the underlying RDF/XML >>> serializations to the business/clinical users, there has been work e.g., >>> triples, Manchester OWL syntax which can be leveraged to make the OWL >>> expressions understandable to informatics users. >>> >>> >>> >>> I don't expect we'll see broad uptake of the RDF syntax. It will remain >>> a specialized syntax for those wishing to use SPARQL, make inferences, >>> etc. That's a small fraction of the overall community. However, if we >>> build it into the reference implementations, it'll be straightforward for >>> most servers to expose the RDF to those clients that actually need it. >>> >>> >>> >>> So, we should definitely enumerate some of the use cases and perhaps >>> flesh them out – so that they can be used to motivate the requirements – >>> e.g., Clinical Decision Support, Quality Metrics, Clinical Trial Protocols, >>> etc. >>> >>> Especially for folks who are not familiar with FHIR – the requirements >>> focusing on the RDF syntax are rather opaque and the value for the broader >>> community is not evident. >>> >>> VK> I am in agreement with your first approach. One approach is to >>> model both FHIR Resources and Terminology Concepts as classes. For e.g.., >>> we could model “Condition” as a class with “Diabetes” as a subclass with >>> some kind of relationship (sameAs, subClassOf) between FHIR:Diabetes and >>> Snomed:Diabetes, MedDRA:Diabetes, ICD11:Diabetes >>> >>> The relationship would be that the concept represented by >>> Condition.code was a specialization of Snomed:Diabetes, etc. (though it's >>> unlikely the name would be that user-friendly). It certainly wouldn't be a >>> link to the overall class. >>> >>> >>> >>> VK> I think one of the design choices we have to make is whether Snomed >>> is a collection of codes or whether it’s better modeled as a set of classes >>> with properties and relationships and perhaps instances as well. >>> >>> I understand that the HL7 efforts have historically looked at the >>> Information Model and Terminology as two different artifacts that can be >>> “bound” together – but viewing both Terminological concepts and Information >>> Model >>> >>> Entities as classes provdes a common meta-model to facilitate the merge. >>> >>> >>> >>> Just my 2 cents. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> ---Vipul >>> >>> >>> >>> >>> >>> ---Vipul >>> >>> >>> >>> (Feel free to add your thoughts to the wiki page.) >>> >>> >>> >>> >>> >>> Lloyd >>> >>> >>> >>> >>> -------------------------------------- >>> Lloyd McKenzie >>> >>> +1-780-993-9501 >>> >>> >>> >>> Note: Unless explicitly stated otherwise, the opinions and positions >>> expressed in this e-mail do not necessarily reflect those of my clients nor >>> those of the organizations with whom I hold governance positions. >>> >>> >>> >>> On Wed, Dec 10, 2014 at 2:59 PM, Vipul Kashyap <kashyap.vipul@gmail.com> >>> wrote: >>> >>> Good list, Lloyd. Would like to suggest some more additions (apologies >>> if these have already been suggested). >>> >>> >>> >>> · Clearly articulate the value of the new RDF/RDFS/OWL >>> representation over the current XML/JSON representation >>> >>> · Enablement of OWL/RDFS inference – so we could identify use >>> cases that cannot be easily done based on the XML/JSON representation >>> >>> · A common OWL/RDFS representation for information model >>> elements *and* medical terminology concepts. >>> >>> >>> >>> Thoughts. Suggestions? >>> >>> >>> >>> ---Vipul >>> >>> >>> >>> *From:* Lloyd McKenzie [mailto:lloyd@lmckenzie.com] >>> *Sent:* Monday, December 08, 2014 1:36 PM >>> *To:* David Booth >>> *Cc:* w3c semweb HCLS; its@lists.hl7.org >>> *Subject:* Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / >>> W3C HCLS COI call -- Review of FHIR ontology approaches (cont.) >>> >>> >>> >>> I think we need to define our objectives for the RDF representation. >>> Mine are as follows: >>> >>> >>> >>> 1. It must be possible to round-trip from XML/JSON through RDF >>> representation >>> >>> * This includes retaining information about order of repeating elements >>> >>> * Needs to allow for extensions where-ever they can appear, including >>> simple types (date, boolean, etc.) >>> >>> 2. We want to be able to represent instances as RDF and Profiles as >>> OWL/RDFS >>> >>> 3. Syntax needs to be "safe" when dealing with modifier extensions >>> >>> 4. Syntax should support vocabulary bindings to code, Coding and >>> CodeableConcept - including dealing with extensible value sets and >>> multi-code system value sets >>> >>> 5. Syntax should enforce constraints that are representable in RDF (i.e. >>> schema constraints, regular expressions, etc.) >>> >>> 6. In the RDFS/OWL, should expose at least minimal annotation >>> information for display >>> >>> >>> >>> >>> >>> Lloyd >>> >>> >>> -------------------------------------- >>> Lloyd McKenzie >>> >>> +1-780-993-9501 >>> >>> >>> >>> Note: Unless explicitly stated otherwise, the opinions and positions >>> expressed in this e-mail do not necessarily reflect those of my clients nor >>> those of the organizations with whom I hold governance positions. >>> >>> >>> >>> On Mon, Dec 8, 2014 at 11:11 AM, David Booth <david@dbooth.org> wrote: >>> >>> I'm so sorry I forgot to send these out last Tuesday, but here are draft >>> minutes from our call, with Eric Prud'hommeaux reviewing his FHIR ontology >>> approach: >>> http://www.w3.org/2014/12/02-hcls-minutes.html >>> and below in plain text. >>> >>> Also, as a reminder, tomorrow's call (Tuesday) will continue with Claude >>> Nanjo reviewing his FHIR ontology approach. >>> >>> Thanks, >>> David Booth >>> -------------------------------------------------------- >>> [1]W3C >>> >>> [1] http://www.w3.org/ >>> >>> - DRAFT - >>> >>> Semantic Web Health Care and Life Sciences Interest Group Teleconference >>> >>> 02 Dec 2014 >>> >>> See also: [2]IRC log >>> >>> [2] http://www.w3.org/2014/12/02-hcls-irc >>> >>> Attendees >>> >>> Present >>> Bryn_Rhodes, Cati, Claude_Nanjo, David_Booth, EricP, >>> Guoqian, Hans_Cools, Ingeborg, Joshua_Phillips, >>> Kerstin_Forsberg, Marc_Twagirumukiza, Neda, Paul_Knapp, >>> TimW, Tony_Mallia, Charlie_Mead, egonw_(IRC_only?), >>> Scott_Marshall, Patricia, Rob_Hausam, Vassil_(IRC_only?) >>> >>> Regrets >>> Chair >>> David Booth (and Paul Knapp) >>> >>> Scribe >>> dbooth >>> >>> Contents >>> >>> * [3]Topics >>> 1. [4]Approve Minutes of previous meetings >>> 2. [5]Action Review >>> 3. [6]FHIR Ontology Review >>> * [7]Summary of Action Items >>> __________________________________________________________ >>> >>> <trackbot> Date: 02 December 2014 >>> >>> <ericP> trackbot, start meeting >>> >>> <trackbot> Meeting: Semantic Web Health Care and Life Sciences >>> Interest Group Teleconference >>> >>> <trackbot> Date: 02 December 2014 >>> >>> <ericP> oops >>> >>> <TimW> TimW is from +1.919.767... >>> >>> <RHausam> RHausam is 801.949.1556 >>> >>> <Claude> [8]https://global.gotomeeting.com/join/157514853 >>> >>> [8] https://global.gotomeeting.com/join/157514853 >>> >>> <Claude> Please join our GoToMeeting >>> >>> Approve Minutes of previous meetings >>> >>> Nov 18: >>> [9]http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_ >>> 20141118 >>> >>> [9] >>> http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20141118 >>> >>> Nov 25: >>> [10]http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes >>> _20141125 >>> >>> [10] >>> http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20141125 >>> >>> Nov 18 minutes unanimously approved. >>> >>> Nov 25 minutes unanimously approved. >>> >>> Action Review >>> >>> <scribe> ACTION: ericP to set up tracker [recorded in >>> [11]http://www.w3.org/2014/11/25-hcls-minutes.html#action01 -- >>> PENDING >>> >>> [11] http://www.w3.org/2014/11/25-hcls-minutes.html#action01 >>> >>> <trackbot> Created ACTION-2 - Set up tracker [recorded in >>> [12]http://www.w3.org/2014/11/25-hcls-minutes.html#action01 -- >>> pending [on Eric Prud'hommeaux - due 2014-12-09]. >>> >>> [12] http://www.w3.org/2014/11/25-hcls-minutes.html#action01 >>> >>> <scribe> ACTION: Tony to find out more details about how iCat >>> handles ICD-11 ont and report back [recorded in >>> [13]http://www.w3.org/2014/11/18-hcls-minutes.html#action01 -- >>> PENDING >>> >>> [13] http://www.w3.org/2014/11/18-hcls-minutes.html#action01 >>> >>> <trackbot> Error finding 'Tony'. You can review and register >>> nicknames at <[14]http://www.w3.org/2014/HCLS/track/users>. >>> >>> [14] http://www.w3.org/2014/HCLS/track/users >>> >>> <scribe> ACTION: Guoqian to figure out whether he can share URI >>> conventions for ICD-11 [recorded in >>> [15]http://www.w3.org/2014/11/25-hcls-minutes.html#action07 -- >>> PENDING >>> >>> [15] http://www.w3.org/2014/11/25-hcls-minutes.html#action07 >>> >>> <trackbot> Created ACTION-3 - Figure out whether he can share >>> uri conventions for icd-11 [recorded in >>> [16]http://www.w3.org/2014/11/25-hcls-minutes.html#action07 -- >>> pending [on Guoqian Jiang - due 2014-12-09]. >>> >>> [16] http://www.w3.org/2014/11/25-hcls-minutes.html#action07 >>> >>> <Claude> For those who just joined IRC, we also have a >>> GoToMeeting at: >>> >>> <Claude> [17]https://global.gotomeeting.com/join/157514853 >>> >>> [17] https://global.gotomeeting.com/join/157514853 >>> >>> <scribe> ACTION: Kerstin and Ingeborg to prepare a status and >>> future state ideas for PhUSE-FDA work [recorded in >>> [18]http://www.w3.org/2014/11/18-hcls-minutes.html#action05 -- >>> PENDING >>> >>> [18] http://www.w3.org/2014/11/18-hcls-minutes.html#action05 >>> >>> <trackbot> Error finding 'Kerstin'. You can review and register >>> nicknames at <[19]http://www.w3.org/2014/HCLS/track/users>. >>> >>> [19] http://www.w3.org/2014/HCLS/track/users >>> >>> <scribe> ACTION: Eric to establish/make a wiki page for C-CDA >>> RDF representations work [recorded in >>> [20]http://www.w3.org/2014/11/18-hcls-minutes.html#action06 -- >>> PENDING >>> >>> [20] http://www.w3.org/2014/11/18-hcls-minutes.html#action06 >>> >>> <trackbot> Created ACTION-4 - Establish/make a wiki page for >>> c-cda rdf representations work [recorded in >>> [21]http://www.w3.org/2014/11/18-hcls-minutes.html#action06 -- >>> pending [on Eric Prud'hommeaux - due 2014-12-09]. >>> >>> [21] http://www.w3.org/2014/11/18-hcls-minutes.html#action06 >>> >>> <scribe> ACTION: Eric and Joshua to report on C-CDA RDF >>> representations work plan [recorded in >>> [22]http://www.w3.org/2014/11/18-hcls-minutes.html#action07 -- >>> PENDING >>> >>> [22] http://www.w3.org/2014/11/18-hcls-minutes.html#action07 >>> >>> <trackbot> Created ACTION-5 - And joshua to report on c-cda rdf >>> representations work plan [recorded in >>> [23]http://www.w3.org/2014/11/18-hcls-minutes.html#action07 -- >>> pending [on Eric Prud'hommeaux - due 2014-12-09]. >>> >>> [23] http://www.w3.org/2014/11/18-hcls-minutes.html#action07 >>> >>> Joshua: Sent email describing a use case. Will add to wiki >>> page. >>> >>> <scribe> ACTION: Tony and Rob to report their plan on >>> High-level concept mapping to RDF work [recorded in >>> [24]http://www.w3.org/2014/11/18-hcls-minutes.html#action08 -- >>> PENDING >>> >>> [24] http://www.w3.org/2014/11/18-hcls-minutes.html#action08 >>> >>> <trackbot> Error finding 'Tony'. You can review and register >>> nicknames at <[25]http://www.w3.org/2014/HCLS/track/users>. >>> >>> [25] http://www.w3.org/2014/HCLS/track/users >>> >>> <scribe> ACTION: Tony and all to decide on a wiki for Term Info >>> work [recorded in >>> [26]http://www.w3.org/2014/11/18-hcls-minutes.html#action09] -- >>> PENDING >>> >>> [26] http://www.w3.org/2014/11/18-hcls-minutes.html#action09] >>> >>> <trackbot> Error finding 'Tony'. You can review and register >>> nicknames at <[27]http://www.w3.org/2014/HCLS/track/users>. >>> >>> [27] http://www.w3.org/2014/HCLS/track/users >>> >>> <scribe> ACTION: Guoqian to figure out whether he can share URI >>> conventions for ICD-11 [recorded in >>> [28]http://www.w3.org/2014/11/25-hcls-minutes.html#action07] >>> >>> [28] http://www.w3.org/2014/11/25-hcls-minutes.html#action07] >>> >>> <trackbot> Created ACTION-6 - Figure out whether he can share >>> uri conventions for icd-11 [recorded in >>> [29]http://www.w3.org/2014/11/25-hcls-minutes.html#action07] >>> [on Guoqian Jiang - due 2014-12-09]. >>> >>> [29] http://www.w3.org/2014/11/25-hcls-minutes.html#action07] >>> >>> <scribe> [PENDING] >>> >>> FHIR Ontology Review >>> >>> <Claude> Please use GoToMeeting only for video >>> >>> [30]https://global.gotomeeting.com/join/157514853 >>> >>> [30] https://global.gotomeeting.com/join/157514853 >>> >>> Access Code: 157-514-853 >>> >>> Eric's slides: -> >>> [31]http://www.w3.org/2014/Talks/1125-fhir-rdf-egp/ FHIR-RDF >>> >>> [31] http://www.w3.org/2014/Talks/1125-fhir-rdf-egp/ >>> >>> Eric: Our goal was to let anything in FHIR XML be translated >>> into RDF. >>> ... We wrote something that read the XML definition files and >>> produced something that maps the XML to RDF. >>> ... Python code reads the json definition files and spits out >>> XML, being the parts that we need of the FHIR spec. >>> ... "subs" is what is allowed inside a FHIR resource. >>> ... effectively the attributes of a resource. >>> ... Then we embedded that in an XSLT script, and hand edited >>> the foot of it. >>> ... The stuff we wrote into the footer of the XSLT says that >>> for a particular construct in the XML instance data, there's >>> special handling, such as URLs for identifiers. >>> >>> David: How does the fact that it is an atom feed affect the >>> interpretatinon of the XML? >>> >>> Eric: It leaves some other graph stuff superimposed on it. >>> >>> Marc: Re datatypes, you used FHIR value, but the value itself >>> looks like it is a string. >>> ... If it is a string, then reasoners cannot do much with it. >>> >>> Eric: Datatype values are showing up as literals. >>> >>> Marc: Another is that a date is just a string, not an xsd:date. >>> ... On slide 2 >>> >>> Eric: Ideally it should have the datatype stuck on the end of >>> it. There's a tension between having the datatype on the >>> fhir:value and having it on a blank node. >>> ... The natural RDF-ish way to do it would be using >>> xsd:datetime. >>> ... Need to decide which of these ways will be most palatable >>> to RDF folks versus native FHIR folks. >>> ... Sometimes these things are not just datetimes in FHIR. Need >>> to make it as simple as possible and no simpler. >>> >>> Guoqian: Is a different URI being used for the namespaces? Will >>> it cause problems when you use SPARQL across different models? >>> >>> Eric: I tested some of this. I stuck a bunch of these >>> namespaces together, and I believe we've addressed your >>> concern. >>> >>> David: Is the datatype issue due to the fact that datatypes are >>> extensible in FHIR? >>> >>> Eric: Maybe. RDF needs to be monotonic. >>> >>> Paul: Modifying extensions can appear only in the roots of >>> classes (considering the complex type as a class) >>> >>> Eric: The XSLT footer has the custom code for extensions. >>> >>> Paul: We did that to limit what you need to examine, to find >>> out if there is a modifying extension. >>> >>> Claude: I think you can have modifying extensions on the root >>> type and anything that is defined from the root type. >>> >>> ISSUE: FHIR Modifying extensions and monotonicity >>> >>> <trackbot> Created ISSUE-1 - Fhir modifying extensions and >>> monotonicity. Please complete additional details at >>> <[32]http://www.w3.org/2014/HCLS/track/issues/1/edit>. >>> >>> [32] http://www.w3.org/2014/HCLS/track/issues/1/edit >>> >>> Eric: Example here may not be up to date. Anyone know? >>> >>> Paul: the dev site has DSTU 2. >>> >>> Eric: Another script generates the ShEx definitions from the >>> FHIR spec. >>> ... and the ShEx is used to generate FHIR XML back again from >>> FHIR RDF. >>> ... Slide 7 is showing how to take C-CDA in RDF and producing >>> FHIR RDF. >>> >>> Guoqian: The result prefix is fhir but should be patient. >>> >>> Eric: Yes, you're right. That can be fixed in the ShEx. >>> >>> Tony: Sort of verbatim translation. The difference is maybe >>> target audience style -- a style that is good for the general >>> tools used in RDF. Only difference is the end style of RDF. >>> ... Establishing closure between FHIR ontology and SNOMED-CT >>> would need to happen. Main difference is in the final RDF >>> style. >>> >>> <pknapp> Zakim: Have to leave for another meeting, thx, great >>> work. >>> >>> Eric: Will need to need to be a balance. >>> ... Once we have transliterated, what we map to our dream >>> ontology. May want to balance how much is wedged into the XSLT >>> and how much into the interpretive dance later. >>> >>> Claude: Might want a low level FHIR ont and a higher level FHIR >>> ont both. >>> >>> David: I kind of like the auto-generated aspect of this >>> approach. >>> >>> <vassil> чуит >>> >>> ADJOURNED >>> >>> <vassil> quit >>> >>> <ericP> [33]coding mapping example >>> >>> [33] >>> https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FDATherapeuticAreaOntologies#codeAndSystemToIRI >>> >>> <ericP> (for next week) >>> >>> <vassil> exit >>> >>> Summary of Action Items >>> >>> [PENDING] ACTION: Eric and Joshua to report on C-CDA RDF >>> representations work plan [recorded in >>> [34]http://www.w3.org/2014/11/18-hcls-minutes.html#action07] >>> [PENDING] ACTION: Eric to establish/make a wiki page for C-CDA >>> RDF representations work [recorded in >>> [35]http://www.w3.org/2014/11/18-hcls-minutes.html#action06] >>> [PENDING] ACTION: ericP to set up tracker [recorded in >>> [36]http://www.w3.org/2014/11/25-hcls-minutes.html#action01] >>> [PENDING] ACTION: Guoqian to figure out whether he can share >>> URI conventions for ICD-11 [recorded in >>> [37]http://www.w3.org/2014/11/25-hcls-minutes.html#action07] >>> [PENDING] ACTION: Kerstin and Ingeborg to prepare a status and >>> future state ideas for PhUSE-FDA work [recorded in >>> [38]http://www.w3.org/2014/11/18-hcls-minutes.html#action05] >>> [PENDING] ACTION: Tony and all to decide on a wiki for Term >>> Info work [recorded in >>> [39]http://www.w3.org/2014/11/18-hcls-minutes.html#action09] >>> [PENDING] ACTION: Tony and Rob to report their plan on >>> High-level concept mapping to RDF work [recorded in >>> [40]http://www.w3.org/2014/11/18-hcls-minutes.html#action08] >>> [PENDING] ACTION: Tony to find out more details about how iCat >>> handles ICD-11 ont and report back [recorded in >>> [41]http://www.w3.org/2014/11/18-hcls-minutes.html#action01] >>> >>> [34] http://www.w3.org/2014/11/18-hcls-minutes.html#action07 >>> [35] http://www.w3.org/2014/11/18-hcls-minutes.html#action06 >>> [36] http://www.w3.org/2014/11/25-hcls-minutes.html#action01 >>> [37] http://www.w3.org/2014/11/25-hcls-minutes.html#action07 >>> [38] http://www.w3.org/2014/11/18-hcls-minutes.html#action05 >>> [39] http://www.w3.org/2014/11/18-hcls-minutes.html#action09 >>> [40] http://www.w3.org/2014/11/18-hcls-minutes.html#action08 >>> [41] http://www.w3.org/2014/11/18-hcls-minutes.html#action01 >>> >>> [End of minutes] >>> __________________________________________________________ >>> >>> >>> Minutes formatted by David Booth's [42]scribe.perl version >>> 1.140 ([43]CVS log) >>> $Date: 2014-12-02 17:30:25 $ >>> __________________________________________________________ >>> >>> [42] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm >>> [43] http://dev.w3.org/cvsweb/2002/scribe/ >>> >>> Scribe.perl diagnostic output >>> >>> [Delete this section before finalizing the minutes.] >>> This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 >>> Check for newer version at [44]http://dev.w3.org/cvsweb/~checkout~/2002/ >>> scribe/ >>> >>> [44] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ >>> >>> Guessing input format: RRSAgent_Text_Format (score 1.00) >>> >>> No ScribeNick specified. Guessing ScribeNick: dbooth >>> Inferring Scribes: dbooth >>> Default Present: DBooth, +1.919.767.aaaa, ericP, rhausam, TimW, Joshua_P >>> hillips, +1.202.528.aabb, charlie, +1.469.226.aacc, Tony, Neda, patricia >>> , Mark_Twagirumukiza, Kerstin_Forsberg, Cati, Kerstin, +1.801.368.aadd, >>> +1.604.250.aaee, Bryn_Rhodes, +31.62.427.aaff, mscottm, Guoqian, +1.608. >>> 310.aagg, vassil, +41.78.847.aahh, [IPcaller] >>> >>> WARNING: Replacing previous Present list. (Old list: Bryn_Rhodes, Cati, >>> Claude_Nanjo, David_Booth, EricP, Guoqian, Hans_Cools, Ingeborg, Joshua_ >>> Phillips, Kerstin_Forsberg, Marc_Twagirumukiza, Neda, Paul_Knapp, TimW, >>> Tony_Mallia, Charlie_Mead, egonw, (IRC, only?), Scott_Marshall, Patricia >>> , Rob_Hausam, Vassil, (IRC, only?)) >>> Use 'Present+ ... ' if you meant to add people without replacing the lis >>> t, >>> such as: <dbooth> Present+ Bryn_Rhodes, Cati, Claude_Nanjo, David_Booth, >>> EricP, Guoqian, Hans_Cools, Ingeborg, Joshua_Phillips, Kerstin_Forsberg >>> , Marc_Twagirumukiza, Neda, Paul_Knapp, TimW, Tony_Mallia, Charlie_Mead, >>> egonw_(IRC_only?), Scott_Marshall, Patricia, Rob_Hausam, Vassil_(IRC_on >>> ly?) >>> >>> Present: Bryn_Rhodes Cati Claude_Nanjo David_Booth EricP Guoqian Hans_Co >>> ols Ingeborg Joshua_Phillips Kerstin_Forsberg Marc_Twagirumukiza Neda Pa >>> ul_Knapp TimW Tony_Mallia Charlie_Mead egonw_(IRC_only?) Scott_Marshall >>> Patricia Rob_Hausam Vassil_(IRC_only?) >>> Found Date: 02 Dec 2014 >>> Guessing minutes URL: [45]http://www.w3.org/2014/12/02-hcls-minutes.html >>> People with action items: all eric ericp guoqian ingeborg joshua kerstin >>> rob tony >>> >>> [45] http://www.w3.org/2014/12/02-hcls-minutes.html >>> >>> >>> [End of [46]scribe.perl diagnostic output] >>> >>> [46] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm >>> >>> >>> >>> *********************************************************************************** >>> Manage subscriptions - http://www.HL7.org/listservice >>> View archives - http://lists.HL7.org/read/?forum=its >>> Unsubscribe - >>> http://www.HL7.org/tools/unsubscribe.cfm?email=lloyd@lmckenzie.com&list=its >>> Terms of use - >>> http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules >>> >>> >>> >>> >>> >>> > > > -- > > ============================================ > Timothy Cook > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > MLHIM http://www.mlhim.org > >
Received on Monday, 22 December 2014 17:03:06 UTC