Earlier last week, my colleague , in which he proposed the idea of "embedded keys" at 01:45 How would James, the fictitious forms designer, do to build a data capture form with these embedded keys?
Let's use the same vital signs example. First, we have a few widgets for the physical layer, i.e., variables. Together they form a wireframe of a vital signs data collection module. Each variable has a NCI c-code, a name, and a definition:
Next, we have several widgets for the medical concepts surrounding blood pressure. Similar to the variable widgets, they also have a NCI c-code, a name and a definition.:
In the above diagram, motice how the c-code for Blood Pressure and Vital Signs begins with CUI, or Concept Unique Identifier. The fact is, in the NCI Metathesaurus, these concepts come pre-assembled with relationships, such that:
The last set of widgets are the controlled terminology.
We have all the widgets, allowing us to assemble a well-defined capture form with all necessary "embedded keys".
In conclusion, the "embedded keys" will not only serve as the conduit to the healthcare link side of interoperability, they can also be used to tie conceptual ideas (knowledge) to the physical implementations (SDTM). This way, it doesn't really matter the verbiages used on a CRF because the c-codes uphold the underlying semantics.
References:
- CDISC Variable Terminology on NCI Thesaurus: http://ncit.nci.nih.gov/ncitbrowser/ajax?action=values&vsd_uri=http://evs.nci.nih.gov/valueset/C83187
- NCI Metathesaurus: http://ncimeta.nci.nih.gov/ncimbrowser/
- Blood Pressure concept and relationships on NCI Metathesaurus: http://ncimeta.nci.nih.gov/ncimbrowser/pages/concept_details.jsf?dictionary=NCI%20MetaThesaurus&code=C0005823&type=relationship
Overview
Content Tools