Sunday, September 16, 2012

Mind maps just begging for RDF triples and formal models

Earlier this week CDISC English Speaking User Group (ESUG) Committee arranged a webinar: "CDISC SHARE - How SHARE is developing as a project/standard” with Simon Bishop, Standards and Operations Director, GSK. I did find the comprehensive presentation from Simon, and his colleuage Diane Wold, very interesting.

Interesting as the presentation in an excellent way exemplifies how "Current standards (company standards, SDTM standards, other standards) do not current deliver the capability we require" Also, I do find the presentation interesting as it exemplifies mind maps as a way forward as "Diagrams help us understand clinical processes and how this translates into datasets and variables." (Quotes from slide 20 in the presentation: Conclusions.) 

Below a couple of examples of mind maps from the presentation. And also, the background to my thinking that they are Mind maps just begging for RDF triples and formal models of the clinical and biomedical reality to make them fully ready "both for human understanding and for computer interpretation".

High level mind map from the Parkinson's disease example
by Dianne Wold, GSK (slide 14)

Current standards do not current deliver the capability we require 

This conclusion is backed up in the first half of the presentation with exemples from GSK's internal standards and from CDISC's SDTM standards. These are low level data standard specifying data structures and data elements (variables). Standards for exchange of data in bulk (in containers such as SDTM Vital Sign and Lab domains) or standards for exchange of captured data (in specified variables such as a data modules for specific blod pressure and temperature mesurements) . Good exemples in the presentations show the challanges in analysing and aggregating clinical data put into SDTM dataset variables as containers "lacking documented relationships between the variables".

Example from data represented in the proposed
SDTM standard for Parkinson's disease (slide 12)

Diagrams help us understand clinical processes and how this translates into datasets and variables

The value in drawing diagrams to understand the higher level of relationsships in terms of the clinical processes in which clinical data is captured for different diseases. This is nicely illustrated in the presentation with a couple of diagrams, or "mind maps".

Example of a map of the clinical process (slide 15)
And also on the value in drawing diagrams to understand the mid level of relationsships in terms of "concepts" *) and "concept variables" and how these should be put into the SDTM variables (in red). (The example below is unfortunately not the same as the above Parkinson's disease examples.)

Example of a map for the concept of Temperature measurement (slide 28)

Mind maps just begging for RDF triples and formal models

When I see these mind maps I see graphs just begging for RDF triples (subject, predicat, object). That is, the fundemental semantic web standard. See my two earlier blog posts from two presentations at CDISC Interchange Europe: Semantic models for CDISC standards and metadata and Linking Clinical Data Standards

An intersting exercise would be to have the Parkinson's disease exemple completed in the concept mapping tool (CMAP) the whole way down to SDTM. And export the mind maps using as RDF triples. However, this is nice, but not enough ...

When I these mind maps I can also see how easy it is to start drawing such diagrams and exporting them as representations of generic mind maps. However, to fullfill the ultimate goal to have them "captured in a way that these can be used both for human understanding and for computer interpretation" the "mind maps" need underlying formal models of the clinical and biomedical reality.
Therefore, I see an interesting connection between the high level maps for disease and clinical processes to the Ontology for General Medical Science (OGMS). OGMS is an ontology of entities involved in a clinical encounter and provides a formal theory of disease that have been further elaborated by specific disease ontologies. See my blog post from last year on Disease terminologies and ontologies.

*) The CDISC SHARE project talks about scientific, or research, concepts. It has also been called observation concepts. However, the word "concept" is overused and carries challanges in itself, see From concept to clinical reality. 

Kudos to Frederik Malfait, working for Roche and my co-presenter on Semantic models for CDISC data standards and metadata, for pointing me to this presentation.


Frederik Malfait said...

I also asked a few questions at the ESUG meeting where Simon presented this.

Q. The formal model for BRIDG is UML. What is the formal model for SHARE?

A. There is no formal model.

Q. What happened to the OWL model we did for the Scientific Research concepts and BRIDG mappings at the beginning of this year in the Model team?

A. Postponed, as there are other more urgent issues.

[My reading: Noticed that slide 38 (the one that invites people to participate in SHARE) mentions DIH leading the model team to develop an XML schema. This probably means that XML rules and OWL is dead. This would be a huge mistake, so I can only hope to be wrong. If concept maps and BRIDG decompositions are supposed to be at the heart of SHARE, then RDF/OWL/SKOS is the most obvious choice.]

Q. (somebody else) Will there be a dedicated sub-team for the SHARE requirements.

A. No. [This will be done by the CDISC Leadership Team.]

Q. Will the SHARE requirements be reviewed by the CDISC community at large?

A. Good question. Don' know.

Lin said...

Hi, definitely I see the mind map's overlapping with an visualization of an ontology.
It is an excellent idea to use mind map in this way.
I also had a virtual mapping in my mind when I looked at mind map.
I just wonder why not use ontology then? It is so close! The ontology will bring: 1. The formal definition and formal relations of concepts; 2. The integrating with other standards; 3. The automatic classification using reasoner; 4. Avoid future mapping between different systems.

Asiyah Yu Lin