+10 on Peter's comments! Agree completely with his rationals
Erich Gombocz
"Life is always live - no rehearsal, no cuts, no replay"
Sent from my HTC
- Reply message -
From: "peter.hend...@kp.org"
Date: Sat, Dec 20, 2014 17:23
Subject: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup
Dear all,
I have hardly participated in any of the calls lately and am coming at
this as a bit of an outsider. From my reading it indeed seems that any
officially accepted RDF version of FHIR data would use a code + code
system representation of 'concepts' from controlled vocabularies /
ontol
I can think of two reasons why (except maybe in an academic paper or PHD
thesis) we would not put SNOMED and the information model in one RDF/OWL
Ontology.
One is the idea of keeping the information model, specifically FIHR, very
small. The goal is to keep it under 200 resources, closer to 100
Hi Vipul,
On 12/20/2014 06:35 PM, Vipul Kashyap 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.. wh
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 t
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 w
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 appro
Thanks for the clarification below – The word “Condition” is an overloaded one
– and as described below is an N-ary relationship between a “Clinical
Condition”, Patient, Physican, etc.
---Vipul
From: Lloyd McKenzie [mailto:ll...@lmckenzie.com]
Sent: Saturday, December 13, 2014 6:56 PM
To
I think using a concrete example helps. One thing which is becoming clear it
that we are perhaps modeling Snomed in different ways.
ok, well, how it works is that FHIR has a resource called "condition", which is
a record keeping construct people use to exchange information about proble
>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
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 l
Hi Peter,
Thanks for your email below – If I may summarize:
Clinical Models capture the “who, when, where, why”
Snomed/Medical Terminogies – capture the “what”
Agree with your suggestion that Snomed should not be used for the former –
The underlying motivation for my suggestion – as
12 matches
Mail list logo
