Digital Data Flow

CDISC is collaborating with TransCelerate, Microsoft, and Accenture as a part of TransCelerate’s Digital Data Flow Project to develop a Study Definition Reference Architecture that will serve as a standard model for the development of a Study Definitions Repository. The Repository is a novel central component aimed at facilitating the exchange of structured study definitions across clinical systems using technical and data standards. Additional information can be found in the Digital Data Flow (DDF) Press Release. 

Project Deliverables

The Reference Architecture (RA) will provide solution architects with a common vocabulary, reusable designs, industry best practices, standards, and general implementation guidance. The RA is not a solution architecture and is not implemented directly but constrains concrete solution architectures with the purpose of promoting the development of conformant solution architectures that enable interoperability across multiple systems in a clinical study, improve efficiency and data quality, and reduce cycle times. 

Project deliverables that will become official CDISC standards include:

Unified Study Definition Model (USDM) Class Diagram

The USDM Class Diagram is a UML Class diagram that functions as the Study Definitions Logical Data Model (LDM). The class diagram as LDM depicts the classes and attributes that represent data entities and the relationships between those entities that are needed to support a conformant Study Definitions application. The class diagram includes a data dictionary that defines each of the classes and attributes to provide the semantics needed to implement the model consistently.

The purpose of the LDM is to provide guidance to the solution implementer. It does not attempt to be inclusive of every class, attribute, and relationship implemented by any given solution. Instead, the LDM describes all elements for a conformant solution based on the Minimal Viable Product. It provides input into the solution architecture with the expectation that every effort will be made to ensure the solution architecture aligns with the RA LDM. The LDM represented by the class diagram may be implemented in a variety of physical data stores, including relational databases, property graph databases, RDF triple stores, document databases, and others. The semantics represented in the LDM and data dictionary support a uniform understanding of the Study Definition data elements to improve interoperability. The LDM will be used to define the resources available in the API specification; these resource definitions represent the data exchange format for applications implementing the API.

The class diagram references industry standards and terminology systems where relevant. For example, the Study Definition class diagram includes references to CDISC Biomedical Concepts,  Foundational Standards, and Controlled Terminology. The data dictionary accompanying the class diagram will include references to the CDISC Library for retrieval of all CDISC content. Content from other standards and terminology systems (HL7, LOINC, CPT, ICH M11, et al) may be incorporated into the LDM, with the intention of extending interoperability to data exchange standards, such as FHIR. The class diagram also depicts essential elements of a study protocol including study objectives, endpoints, and the schedule of activities.  

CDISC Controlled Terminology to Support USDM

The use of standardized terminology is an essential element of interoperability. To support the Study Definition LDM, CDISC will develop new Protocol Controlled Terminology, including code lists and terms as well as changes to existing terms, if needed. Terminology for SDTM Trial Design domains will also be covered in this project.

Application Programming Interface (API) Specification

A standardized API provides a standard interface for a common set of core services that must be supported by all conformant solutions. A standard API will enable application developers to build solutions that can use the core services of any conformant Study Definition. Data standards, controlled terminology, data exchange standards, and APIs work together to create an optimal environment for interoperability between conformant systems.

A Study Definition REST API will be specified using the OpenAPI Specification (OAS) version 3.0. As a machine-readable format, OAS can be used to generate not only interactive documentation but also source code to aid developers creating software implementing the specification. The CDISC Library also publishes API specifications using these formats. The CDISC Library, HL7 FHIR, and the DDF Study Definition API form a growing set of standard APIs to improve interoperability and automation in clinical trials. Much like the CDISC Library API, the Study Definition API will support a range of media types, including JSON and XML.

The Study Definition API enables clients to create, update, and remove Study Definition content assuming the user’s role permissions support the activity. Accordingly, the API provides access to Study Definition services so that alternative user interfaces and applications can be developed to extend or exchange information with any given Study Definition tool.

Reference Architecture Conformance Tests

Conformance tests will be used to ensure that any given Study Definition solution conforms to the DDF Study Definition RA. These Conformance tests will aid implementers in ensuring solutions conform with the RA, assist purchasers in ensuring products procured meet requirements, and help collaborating organizations in ensuring their study builds are interoperable in terms of the scope of the RA. The conformance tests will be automated to ease the ability to execute them quickly and consistently as well as to report the results. Automated conformance tests provide a clarifying interpretation of the RA that supports the RA documentation and aids solution architects and implementers. The API conformance rules will test for conformance with the OAS 3.0 specification. Since the OAS 3.0 specification is a complete, machine-readable specification of the API, automated tests can be generated and maintained using the specification.

Additional deliverables include:

Essential User Stories

The essential user stories document key features expected in a conformant Study Definition and aid in defining the scope of the project deliverables. The intention is to highlight basic Study Definition features as they pertain to the RA deliverables without including the precise detail needed for the RA deliverables. This deliverable may include use cases that further define the context of a given user story. The essential user stories will aid in the development of the class diagram, API specification, and conformance tests and clearly articulate the baseline functionality required in a Study Definition application, which conforms to the RA without restricting additional features an implementer might opt to implement. The RA project user stories will be created by CDISC working with input from all stakeholders and will be reviewed by the RA team during backlog grooming sessions. Draft deliverable essential user stories will be reviewed as part of the Internal and Public Review periods.  

Architecture Principles

The architecture principles aim to help implementers understand how to create conformant solution architectures through the implementation of the DDF Study Definition Reference Architecture. They inform solution architects of the approach expected by the RA stakeholders to ensure consistency across Study Definition implementations and to ensure alignment with the business and technology objectives. Architecture principles define the fundamental assumptions regarding the RA and aid in developing a framework for decision making by solution architects implementing the RA.

Project Timelines 

The anticipated timeline is 11 months and follows the CDISC Standards Development Process. This approach employs an agile methodology allowing draft standards to be provided to fellow stakeholders on an ongoing basis during development.

How to Participate 

We invite your organization to participate in this exciting new project. Please visit the DDF Project Participate tab to learn more. 

DDF Project Call-for-Participation Webinar 

CDISC held a Project Information and Call for Volunteers webinar 5 October 2021 to provide a deeper understanding of the DDF project, share the “ask” of participants, and answer questions from attendees. We invite you to listen to the webinar recording to learn more. We are looking for targeted reviewers of the draft deliverables throughout the development phase with particular expertise in the following areas:

  • CDISC Protocol-related Controlled Terminology
  • UML model review in relation to study/protocol concepts
  • Technical skills to review API specifications in relation to study/protocol concepts
  • Experience of this type of project within your own organization

Targeted Reviewers for Internal and Public Reviews

There are four, one-week Internal Reviews planned for this project (Note: Deliverables will be cumulative; reviewers will have the opportunity to review all new and previous content during each Internal Review).

  1. 4th October 2021
  2. 15th November 2021
  3. 10th January 2021
  4. 7th February 2021

Public Review is planned to start March 2022.

Internal and Public Review time is estimated to be 10-20 hours depending on experience with the four areas mentioned above. We encourage reviewers to also reach out to colleagues who may also have experience in reviewing these types of deliverables or have business experience with this type of project. Please get in touch using the sign-up instructions below.

Participate

  • If you would like to participate in this exciting effort, please follow the instructions below: 
    • Targeted Internal and Public Reviewers: Sign up on the CDISC Volunteer page and indicate DDF as the Standards Development team. Please enter Targeted Internal and Public Reviewer in the box "Specify in which capacity you want to participate."
    • Participation in Standards Development: Sign up on the CDISC Volunteer page and indicate DDF as the Standards Development team. In the specify box enter in what capacity you feel you can contribute to the team and the amount of time you can contribute to the project.

CDISC and TransCelerate held a Project Information and Call for Volunteers webinar on 5 October 2021. We invite you to watch and learn more about this important initiative.
 


Volunteering

I work with CDISC Foundational Standards, but am unfamiliar with deliverables for this project apart from Controlled Terminology, can I still get involved?
  • Yes, we welcome a variety of feedback from the user community.
  • The deliverables for this project are technical automation standards. CDISC is providing workshops during Internal and Public Review to assist in review of the standards.
  • We also recommend reaching out to colleagues within your organization who may have expertise in this area from a business and technical perspective.
What are the volunteer activities you're looking for besides review?
  • This project uses a strict agile methodology. As such, involvement as part of the development team requires significant time commitment (FTE 40% plus). 
  • Some organizations may already have experience in this type of project and individuals may want to volunteer in a supportive capacity to the standards developers (e.g., performing weekly reviews of the deliverables from each sprint).
  • If you are interested in serving on the development team, please visit the Participate tab and follow the sign-up instructions. 
What is the time commitment for volunteers?
  • Targeted Reviewer (Internal/Public): 10-15 hours per review.
  • Supporting the development team (in a review or protocol SME capacity): FTE 20% or more.
  • Participate as a developer: FTE 40% or more.
Is it expected that volunteers should have any specific technology/programming skills as well?
  • Targeted Reviewers do not require specific technical skills.
  • Supporting roles for the development team do not require specific technical skills but do require experience working in trial design.
  • The Development Team require specific technical skills in the area (for example UML diagram creation in Enterprise Architect, API specification development using SwaggerHub) and preferable experience working in the trial design area.
When I signed up for volunteering at CDISC, I had initially picked ADaM as the interest area. Can I change it to DDF for participating in this?
  • Yes, please follow the instructions on the Participate tab.
Where can I go if I have questions about DDF outside of the CDISC standards work?
  • For questions about the TransCelerate DDF initiative outside of the work that CDISC is doing, you should contact TransCelerate using the Digital Data Flow Feedback Form.
Do I have to be a CDISC member to volunteer?
  • No, volunteers on all CDISC teams are welcome from both member and non-member organizations.

Relationship to other Standards

Where do these new standards fit into the current CDISC standards landscape?
  • These standards support the CDISC vision of supporting the implementation of standards.
  • These technical standards will be open source and available for all users with alignment with current CDISC standards.
Is the Unified Study Definition Model (USDM) using an existing or new standard?
  • The USDM is a new technical automation standard, re-using existing standards where applicable.
Will this impact the Foundational Standards (CDASH, SDTM, ADaM)?

The new standards will support the development of a Study Definitions Repository. Existing standards will be reused where appropriate; the new standards will not replace existing Foundational Standards.

Are the standards using the terminology developed by the CDISC Protocol Entities team?
  • Yes. The Controlled Terminology developers for this project are also part of the CDISC Protocol Entities team.
  • Existing terminologies are leveraged where applicable.
  • New terminology developed for this project will follow the standard CDISC Controlled Terminology process.
What is the relationship of the Unified Study Definition Model (USDM) to the BRIDG model?
  • Both BRIDG and the USDM are logical data models.
  • The USDM is a more practical and implementable model. CDISC is delivering a reference architecture that can immediately be implemented in a reference implementation.
Is this project linked to the CDISC 360 initiative? What are the connections?
  • There are team members involved in the development of the USDM that were also part of the CDISC 360 project.
  • The USDM will provide links to future biomedical concept development.
Does the scope of DDF also cover development of biomedical taxonomies and ontologies as well?
  • The USDM will be supported by CDISC Controlled Terminology and external ontologies where appropriate (e.g., study indication).
What is the plan to ensure that the study definition will encompass all study designs, including oncology and immunology?
  • The first release of the USDM will focus on the general cross-cutting concepts related to study definitions to be as flexible and useful for all study types.
Will standard CRFs be created as a result of this project?
  • No, discussions are ongoing about how the Study Definition Repository will interact with company-specific eCRFs.
  • Independent of this project, CDISC offers the eCRF portal that is freely available for organizations to download eCRF content. eCRFS are added on an ongoing basis.
Interoperability is the ultimate goal. Is the integration of clinical studies with Electronic Health Records (EHRs) planned in the future with enhanced data exchange security?
  • Integration with EHRs is not in scope for the initial version of the Study Definition Repository. It will be discussed for future iterations.
Are you all using the PRM in any way?
  • Yes, a list of CDISC, including PRM, and non-CDISC assets related to study design were evaluated as inputs during the scoping process.


Scope

Where can I find more information on TransCelerate's DDF project?
  • Additional information on the DDF Project is available on the TransCelerate DDF website.
Is this project for clinical data only or will it include nonclinical studies?
  • The main focus of the initial version will be related to clinical study designs; additional study design aspects, such as nonclinical, will be discussed for future iterations of the USDM.
Is the USDM intended for RCTs only, or are you considering observational studies within the initial, or later, scope?
  • Discussions on the different types of studies are currently ongoing.
Would this project deliver a standard protocol template which can be machine readable?
  • The intent is that the SDR will hold those common protocol elements that can be used by other systems or tools such as a digital protocol creation tool and the TransCelerate Common Protocol Template (which is part of the TransCelerate Clinical Content & Reuse Initiative).
How will contents of the individual elements within the USDM be authored/reviewed/approved? (e.g., Endpoints or Inclusion Criteria)
  • The development of the standards will follow the CDISC Standards Development Process and the governance process defined in the process. CDISC will work with TransCelerate and volunteer Protocol subject matter experts to develop the concepts for the CDISC deliverables.
  • TransCelerate will be creating a multi-stakeholder governance model that is focused on sustainability with the changing technological landscape, once the Study Definition Repository is up and running. For additional information please visit the TranCelerate DDF webpage.

 

Technology

What kind of technology recommendations is the effort going to publish? Is there a concern that any technology recommendation will bias towards one implementation or another and ultimately hurt the ability to innovate?
  • The Study Definition Repository reference implementation will be cloud agnostic and open-source; the aim is not to select a particular technology to influence users. The Study Definition Repository will act as a template for use in other technologies.
  • Upstream and downstream connecting vendors will be involved to provide their input into the deliverables so that the DDF solution can be implemented with connections to many upstream and downstream systems.
Has the Open Source License been picked?
  • The open-source license will be selected at a future date.
Is there any specific link to check on what is actually happening or any standards available as a part of TransCelerate?
  • The standards developed will be using the CDISC WIKI; volunteers will have access to this area.
  • Additional information on the DDF Project is available on the TransCelerate DDF webpage.
What about something like RESTFUL versus GraphQL? That selection has particular implementation implications.
  • The original rationale for choosing REST over GraphQL is that we're creating a standard API specification that all conformant systems must implement. We anticipate REST will be simpler to produce and govern as a standard specification. It should also allow for the broadest range of implementation support since REST is mature and widely supported across most technology stacks. The decision to use REST also came from early discussions with TransCelerate. CDISC isn’t suggesting that a server can't implement GraphQL, just that the standard API is RESTful. There are pros and cons to each alternative.
Will the model or the reference implementation be tested through some form of connectathon, such as the TransCelerate DDF hackathon which ran two years back now?
  • CDISC will deliver a set of conformance tests to ensure that any given Study Definition solution conforms to the DDF Study Definition RA.
  • Anyone in the technology community interested in becoming involved in the reference implementation testing should contact TransCelerate using the Digital Data Flow Feedback Form.