- From: <Peter.Hendler@kp.org>
- Date: Tue, 21 Aug 2012 08:47:52 -0700
- To: mscottmarshall@gmail.com
- Cc: helena.deus@deri.org, kerstin.l.forsberg@gmail.com, LINMD.SIMON@mcrf.mfldclin.edu, meadch@mail.nih.gov, public-semweb-lifesci@w3.org, ratnesh.sahay@deri.org
- Message-ID: <OFD512AFF6.01D84937-ON88257A61.0054FDC7-88257A61.0056C880@kp.org>
Sorry I didn't make the meeting but just looked at the minutes. We (Kaiser) do use the Ontology features of SNOMED extensively and have a different take on how it should be done. Specifically we would not advocate for example, putting FHIR in RDF or OWL. What we've fount to be simple, useful, and very clean is to recognize the two different kinds of logic involved. And keep them isolated to different parts of the model. Intensional (like OWL, Open World, Reasoners and inferences) Extensional (like HL7 openEHR all Object Oriented models, all databases) The base of a clinical model is always extensional Object Oriented, but there are nodes (attributes in the classes) that can take the data type Coded Data CD) For example the "code" of an Observation class takes a code. You can then designate that the code must be filled with only SNOMED or a SNOMED extension term that follows the same ontological scheme as SNOMED. If you do this, then you can safely use a reasoner on the "code" for any Observation. For example you can ask for codes that represent "a disease with finding site lung structure with morphology fibrosis and disease process autoimmune". Once you get this list of SNOMED codes then you iterate through them using Extensional logic (SQL) and then you have your list of patients. This is the clear separation of the intensional and extensional parts of the model. It is not the representation of the entire model in RDF or OWL. We are just finishing a second white paper on a suggestion of how to extend this principle. The basic idea is that clinical models, like HL7 are primarily at the base Extensional OO models and should not be represented as OWL or RDF. But where it makes sense, you pick particular nodes like the "code" value of the Observation class, and then you add some meta information that indicates the following. Intensional TRUE/ FALSE (the default is FALSE, you can not use a reasoner or SPARQL, this is an extensional OO node) If TRUE then you supply the following additional meta tags. logic (for example OWL-DL, EL+ "same as SNOMED", RDF etc) ontology (for example SNOMED-CT) post_coordinated_experessions_allowed (TRUE/FALSE) hierarchies (for example Clinical Findings, Observables) Now any user or receiver of a model can scan the nodes for these tags. If they find any with intensional="true" then they can inspect the other associated meta tags and know if they can use reasoners or SPARQL. For the huge numbers of instances of these artifacts (messages or documents) that would be in the millions, you don't want to use reasoners but something faster like SQL. But for the nodes where it makes sense you can use OWL or some other reasoner dependent intensional logic. In summary, it probably isn't a good idea to just move the model (for example FHIR) completely over to RDF or OWL. Rather keep it an OO model but then use "Semantic Node Labeling" to designate particular nodes that you are allowed or expected to take advantage of SPARQL or OWL-DL or SNOMED NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Attachments
- image/jpeg attachment: 01-part
Received on Tuesday, 21 August 2012 15:48:39 UTC