Linked Data and Graph Database

2018: DIA Poster Presentation: The Clinical Development Design (CDD) Framework-Assisting and Improving Decision-Making for Product development

2017: Applied Clinical Trials Paper: Barriers and Solutions to Smart Clinical Program Designs

2016: White Paper: Introduction to the Clinical Development Design (CDD) Framework

2016: CSS Hirschfeld Clinical Trial Design Process. An Introduction

2015: Three Ws of Ontology

2015: Drafting the Information Model

2015: Draft version of model

SPIRIT Statement Website

Project Rationale:

• ADaM standard includes validation rules
• Identifying all validation rules associated with a SDTM (ADaM) domain or variable is a non-trivial, manual task
• Vendor-agnostic representation of SDTM validation rules

Project Deliverables:

• Define ontology for validation
• Identify version(s) of SDTM/ADaM validation rules for representation
• Represent SDTM/ADaM validation rules in RDF
• Link the RDF representations to CDISC Standards represented in RDF

2013: Project Related Documents:

• Validation Rules - Compiled list of validation rules for SDTM IG v3.1.2, SDTM IG v3.1.2, SEND IG v3.0 and ADaM IG v1.0

Proposed Ontology:

• Classes
  • ValidationRule
  • ValidationRuleCategory (as a sub-class of mms:Classifier)
  • Research documentation
• Predicates (of ValidationRule Class)
  • checkID: String literal
  • documentReference: Resource
  • documentReferenceText: String literal (this is the specific text in the document reference to which the rule refers. May need to think about a better way to model this
  • mms:dataset: Represent the Structural Group in the ADaM validation rule documentation
  • validationRuleCatergory
  • mms:variableGrouping: Note, the wording in the ADaM validation rules differs slightly from ADaM IG. This predicate may need to be re-evaluated during the modeling
  • failureCriteria: String literal
  • failureMessage: String literal (remove)

ADaM Checks in TopBraid Upload Format (Draft)

1. Are the BRIDG extensions for the PRM included in the newer versions of the BRIDG Model?
   1. Yes, and more concepts
2. EPOCH vs Period - A treatment EPOCH can include multiple periods - can this be handled with visit (StudyEventDef) Types (eg Washout, Baseline, etc)
3. Alignment between PHUSE and CDISC
4. Does/Should the RDF version include concepts of changes and roles?
5. Need a selection of schedule of events to model
6. What is the alignment of the odm:MetadataVersion to the sdm:Protocol - different versions of the schedule of assessments?
7. What about modelling the actual text of the protocol?

Each activity as defined by the SDM may have some associated sub-activities; as an example the Activity of measuring a blood chemistry value could have the associated sub-activities

* Subject at site
* Blood draw taken from Subject
* Date and time of Sample taken
* Blood sample labelled with a unique reference id
* Blood sample sent to lab
* Lab technician records comments on state of sample
* Blood sample analysed (multiple subsequent activities lie here)
* Result logged to Lab Information System
* Result shared or entered into CRF
* Result value checked against defined validation rule
* Comment entered on clinical significance of lab result 
* ....

Each of these sub-activities could enter in a study workflow system, and be useful for trial scheduling, etc.

Representation:

The representation of Roles in ODM is not expansive enough for a full workflow. BPMN heavily uses swim lanes for representation of workflows, but there is no way to catch the full gamut of requirements using the current SDM. Roles may apply to Organisms (such as Site Staff), but can also apply to non-Organisms (such as a machine). Indication of a Role of MRI Machine would provide valuable insight for study site selection or protocol planning; as an example say the executable SoA is entered into a workflow system, but the site knows that an important piece of equipment is out of service for scheduled maintenance at some point, then recruitment could be influenced by following the workflow back to the start.

Overview:

The goal of the keyCRF project is the creation of a semantically annotated electronic Case Report Form (eCRF) that can enable the pre-population of the eCRF from linked data elements in an EHR summary document, HL7's Continuity of Care Document (CCD). The project will draw on prior work of the Semantic Technology Work Group, specifically the RDF representation of the CDISC CDASH standard. The project will use the IHE Data Element Exchange (DEX) specification to create the annotated eCRF, the keyCRF, by drawing on metadata in a metadata repository (MDR) such as CDISC's SHARE or the SALUS MDR. The keyCRF can be used to create an extraction specification that pulls instance data from the CCD to pre-populate the eCRF.

Rationale:

The following use case describes the use of keyCRF through the eyes of an end user.

A research forms designer is building a case report form for a particular research study. The designer refers to an on-line metadata registry of research data elements, e.g. SHARE, and selects the desired data elements from a set of research friendly elements such as CDASH, and, using a unique identifier for that data element, retrieves the metadata defined by the metadata registry into an annotated case report form. The metadata includes the exact specification, using XPath, to find the corresponding data element in the HL7 specification Continuity of Care Document (CCD) as extended in the IHE Clinical Research Document (CRD) profile. Using the XPath statements, the research system creates an extraction specification for all elements to be extracted from the CCD. This extraction specification provides a map that enables re-use of the proper data within a CCD with precision and without inappropriate access to extraneous information. The extraction specification could then be used with RFD and Redaction to pre-populate the case report form.

Resources:

keyCRF webinar

The keyCRF team will present a webinar in February of 2015 with the following agenda:

1. An animated illustration of how an application of keyCRF will transform data capture processes at a healthcare site conducting a clinical study.
2. A walkthrough of the steps of the keyCRF process showing the role of the 'smart form', the metadata repository, and how the extraction specification applies to the electronic record's export document. XML snippets will explain the technical behind the scenes work.
3. A discussion of future directions for the keyCRF work. How might RDF change the concept of an extraction specification?

Mapping of HITSP C154 Data Dictionary Data Elements to RDF and XML Representation of CCD

HITSP C32 (http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=32 ) describes the HL7/ASTM Continuity of Care Document (CCD) content “in order to promote interoperability between participating systems", in this case between an EHR and research data capture systems.

HITSP C32 marks the elements in CCD document with the corresponding HITSP C154 data elements from HITSP Data Dictionary (http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=154) to establish common understanding of the meaning of the CCD elements.

The native representation format of CCD documents are XML, while there are efforts to provide an RDF representation of HITSP C32 for enabling semantic interoperability across systems. The RDF model of HL7 CDA schema provided by SALUS Project is available from: http://www.salusproject.eu/ontology/hl7-cda-ontology.n3. In addition to this, there is a parallel effort to provide an RDF representation of FHIR (Fast Healthcare Interoperability Resources -http://hl7.org/implement/standards/fhir/index.html) Resources (http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR).

We will maintain the data elements in HITSP C154 Data Dictionary in a metadata repository in conformance to ISO/IEC 11179 meta-model. In this metadata repository the extraction specifications of each HITSP C154 data element from CCD documents will also be stored: XPATH expressions will be given for XML representation of CCD documents, while SPARQL queries will be defined for being able to retrieve the data element instances from a medical summary in CCD RDF model. Through DEX profile, these extraction specifications will be retrievable in a machine processable manner as a part of data element metadata.

Linkage of HITSP C154 Data elements to CDASH RDF

This deliverable, the guts of the project, draws on the team's experts in both research and healthcare. The CDASH RDF model will be imported to a metadata repository, then the semantic links between the CDASH data elements and HITSP C154 Data elements will be defined and maintained in the metadata repository. This mapping will enable creation of an extraction specification from CCD documents which can be used to pull instance data into a waiting eCRF. We will also investigate to define and maintain the extraction specifications of HITSP C154 Data elements from XML and RDF serializations of FHIR Resources in the metadata repository.

Demonstration of pre-population of an eCRF from a CCD

An end-to-end demonstration of keyCRF creation, extraction specification creation, and pre-population of an eCRF will show industry the value of the approach. The demonstration will employ the well-known mechanism of RFD to define the necessary transactions between the EHR and the research system.

2015: Key CRF Demo

2015: Key CRF