CDISC ODMv2 Development Progress: A 2018 Q1 Update

Since starting work on ODMv2 last year the CDISC Data Exchange Standards Team, formerly known as the XML Technologies Team, has made substantial progress towards completing the backlog tasks and updates planned for ODMv2. Much of this work is progressing concurrently, creating a broad set of ongoing discussions. To follow the ODMv2 development work the best place to begin is the ODM-XML page in the XML Tech space on the CDISC Wiki, where you can find a list of the most recently updated pages, a link to the decision log, and links to other relevant aspects of the project. You can also find the notes from our meetings, and if you miss a meeting, a recording of it is available through the notes for a few weeks after the teleconference. The Data Exchange Standards Team's goal for 2018 is to release a first draft of ODMv2 for trial use by the end of year. We then plan to test and revise the draft for final release during 2019. This post, some of which was included in the Q4 201

A Bit of Git for CDISC

Along with JIRA and the Confluence Wiki, CDISC has added the Atlassian Bitbucket distributed version control system to our online toolset. CDISC finally has a Git-based version control system, and several projects have already started using it. In cases where a standard is under development, the repository may be private to the team and not accessible by others. However, I anticipate a growing number of publicly accessible CDISC Bitbucket projects. The XML Technologies and SHARE teams are using Bitbucket and will have publicly accessible projects. Trace-XML is one such project. More on this in an upcoming post. You can find Bitbucket from the CDISC Wiki or JIRA by selecting the drop-down menu in the upper left-hand corner of either application, as shown in the graphic below. If you haven't used Git or Bitbucket before there are numerous online tutorials to get you started. Most code developed in a project of mine will have a repository on Bitbucket. That said, there are times

ODMv2: Renovating the ODM Standard

  ODM, CDISC's Operational Data Model , version 1.x will be 17 years old in October, making it a mature standard. ODM has come of age , and it's time for ODM to take on a bit more responsibility around here. Toward this end, a new XML Technologies development team has recently started work on ODMv2, a substantially updated version of ODM that breaks backwards compatibility with version 1.3.x to add a number of significant new features. This post highlights some areas of new development for ODMv2. As ODMv2 is still in the early stages of development, the scope of the project and specific features are subject to change. Among the more important new ODMv2 features will be a RESTful API that specifies standard methods of data and metadata exchange. The RESTful architecture uses specific URLs and the HTTP protocol to leverage pervasive, scalable web technologies to simplify data interchange. Lack of a common API for data exchange in clinical research has limited the available

Loading Terminology in SHARE: What's the DIFFerence?

We load the CDISC Controlled Terminology (CT) published by the NCI Enterprise Vocabulary Services (EVS) into the SHARE metadata repository (MDR). When we're through catching up with our backlog we'll have more CT in SHARE than any other type of metadata, and we'll publish the quarterly CT content to the SHARE Exports page on the CDISC web site. One of the main differences in how we load the CT is that we load only the incremental changes. That is, we load the differences by generating diff files that contain only the changes between the packages published in the current quarter and those published in the previous quarter. The diff files are available for download, or they can be generated using the NCI's Diff program . This program is a Java application, and it is simple to set up on most machines. The Diff application is easy to use and can generate diff files for any two versions of a delimited text CT package. The two packages used to generate the diff file do not

Define-XML v2.1 – What do you think?

If you're wondering where the XML standards like Define-XML went on the CDISC website, they've moved. They're now located under Standards/Transport . If you go to the transport page  you can select from a fairly extensive menu of transport standards. There are a few transport options located elsewhere, such as Lab  and the Analysis Results Metadata  Define-XML extension. Our broad list of XML standards is in the process of welcoming a new version of Define-XML to the family. This new version of Define-XML, v2.1, will almost certainly be listed in the standards catalogs of regulatory authorities at some point, so all of you working on regulatory submissions should find this update interesting. There are a couple weeks left in the Public Review period (it ends on May 5th) so there's still time to add your comments. You can find the Define-XML v2.1 Public Review package  along with instruction for adding JIRA comments on the CDISC wiki . While Define-XML v2.1 is a mino

Using the SHARE API to Grab the Latest CDISC Terminology Packages

Keeping your repository up to date with the latest CDISC Controlled Terminology (CT) packages represents a challenge to many organizations. The SHARE API make it easier to retrieve the CT packages and initiate the process of updating your repository. In this post I'll walk through the process of finding and retrieving the CT from SHARE using the API. We'll use the default media type of XML. When requesting a full CT package the XML media-type uses the NCI EVS extended versionof ODM that includes the additional metadata needed to represent the CT content. The following figure provides an overview of the steps taken to retrieve the latest CT packages using the SHARE API. The first step is to determine what CT Packages are available for loading. This can be done by using the Get Standard Terminology List API. The SHARE API is RESTful so this entails requesting the /terminology-packages resource. The default Lifecycle-Status parameter retrieves Approved Final content.