Sunday, February 5, 2012

Study Design in XML (SDM-XML): what is still missing?

Last year, our CDISC volunteer team published the "Study Design Model im XML", an extension to the ODM standard, filling some functionality gaps (i.e. study design features I was already asking for for years) of the existing ODM standard.
We are now almost a year further, and have had the time to implement the SDM-XML in our tools (such as the ODM Study Designer). We also tested the model against many use cases (even as a possible replacement for submitting study design information to the regulatory authorities).
So it is now time to make an inventory.

We found that the model is already used (or has been prototyped) intensively for searching for possible subjects for studies using patient information such as from EHRs (from the inclusion/exclusion part of the model). We also found that our "workflow" model of SDM-XML can easily be transformed in BPMN-2-XML, which is the generally accepted standard for workflows. This e.g. allows to import a clinical workflow into a hospital information system (HIS) and integrate it with the workflow of the patient care.

There are a few things however that are still failing in our model:
- subactivities: i.e. activities within activities. For example, there can be an activity "place an ambulatory ECG device", which itself consists of a number of subactivities. In ODM/SDM-XML this is not supported (yet). This also has to do with the lack of support for subworkflows.
- subworkflows: i.e. workflows within workflows. Building on the previous example, the activity "place an ambulatory ECG device" will consist of a number of subactivities which need to be executed in a certain order, and maybe with some forking or branches, so needing a subworkflow.
- swimlanes. Those knowing a bit about workflows do also know the concept of "swimlanes". For those who don't, I could try to explain, but wikipedia does a much better job  here.

In order to implement swimlanes, we do however need "roles", such as "primary investigator", "study nurse" or "monitor". We don't have this in ODM, we only have the concept of "user" (which is in priciple a person) with a "UserType" attribute. The latter could be used for "role", but this could better be avoided as its current enumerated list is just too limited and not adequate.

So we would need to extend the ODM further than we already did.
At the same time, we have the problem that "StudyEvent" (for a visit) is not a good concept anymore. In SDM-XML, a visit is essentially a container for a number of activities, which can be datacollection activities or activities in which no data is captured (such as placing the ambulatory ECG device). If we allow activities to have subactivities (and subworkflows) isn't a StudyEvent nothing more than an Activity?
Also (in my opinion) we should introduce an element "Role" in the "AdminData section" of the ODM, and allow to assign roles to "Users" (P.S. A person can have one or more roles).
This could then allow us to introduce the concept of "swimlanes" in the workflow part of ODM/SDM-XML.

I do already have a list of other wishes I have for ODM.
If we find the necessary (human) resources, wouldn't it be time to start thinking about a future ODM Version 1.4?

Let me know what you think!


  1. I am very interested in the SDM-XML model. I saw the LZZT trial example but I wish there were a lot more.

    Other the XML4Pharma, do you know about any other adopters?

  2. Subactivities are well treated by a workflow standard called XPDL. See several publications about that:

    What are some forums where SDM-XML developers discuss new features for the future versions?

    Also, the notion of screening epoch as being the first epoch and an entry condition of "informed consent signed" (it somewhat implies a "pre-screen" epoch and "present consent" activity.)

  3. The merger of Activity and StudyEvents should also include the concept of Triggers. They are "events" as well.

    (previous post under name A were also mine)
    (commenting as I read the SDM-XML documentation and documentation of a software implementing SDM-XML

  4. The resulting SDM-XML should also store the X and Y coordinates of an activity on a flowchart. XPDL standard had the same problem in version 1 where the position of a node in a flowchart was not being stored but later versions did store it. All flowchart/workflow developers wanted to store these since loading a flowchart and auto-generating positions produces a bad result graphically. Naming, conditions and branches stayed, but the flow looked ugly when the coordinates were not stored in the resulting XML serialization format.


    Also, the fragmentation of the forms (ODM) and activities and epochs (SDM-XML) into two standards (ODM and SDM-XML) may be a problem in the future.

    1. Well, we envisage that SDM-XML will become part of core ODM in a next version of ODM. This will however also require some work on ODM itself, so that it will not be downwards compatible any more. I.e. an ODM 1.3 file will (after adapting the namespace declaration) not automatically a valid ODM 1.4 file anymore.

      Concerning keeping X and Y coordinates, I have some mixed feelings. They are part of the "presentation" of the workflow, not of the workfklow itself. As we always want to separate presentation from content, this would mean that the coordinates would be stored in a separate section of the XML file (using references). How does XPDL deal with this?

  5. Thank you for replies. Nice discussion.

    XPDL deals with it this way:

    See my XPDL file from here:

    They got over their separation rigor. Imaging arranging a flower set for your wife in a vase and then somebody reducing your work into just a list of flowers. The whole beauty of the look is ruined :-)

  6. XML paste got filtered out


    Coordinates XCoordinate="205" YCoordinate="20"

    end of xpdl:NodeGraphicsInfo