The XML4Pharma Application Server

XML4Pharma CDISC SDS Variable Services

A number of web services about CDISC SDS (=SDTM+SEND) variables and versions have been developed.

Depending on what your application requests, text, XML or JSON structures will be returned.

NEW: 2018-12-06: SDTM 1.7 / SDTM-IG 3.3 implemented

The following RESTful CDISC SDS variables services are currently available

  • Get SDS Variable Info
  • With this web service, when you to submit an SDS variable name (e.g. "LBTESTCD"), you will obtain a list of SDS standard versions in which the variable has been defined, together with a lot of information about that variable.

    The request structure is:{sdsvarname}

    where {sdsvarname} is the variable name, like "LBTESTCD" or "AETERM" or "USUBJID". In case the variable is generic and for more than one domain, you can also use it require for it with the domain name replaced by "--", e.g. "--TESTCD" or "--TERM".

    For example, if you use:

    You will obtain the following XML (at least if your application/browser requests to get XML):

    stating that the SDS variable "LBTESTCD" is and can be used in SDS version 1.2, version 1.3, and 1.4

    If your application requests JSON, you will get something like:

    If neither XML nor JSON works, you can also get the result as pure text, which will look like:

    i.e. a list of simple pairs, separated by line feeds ("\n") and using tabs ("\t") for better structuring.

  • Get SDS Variable Info for a specific SDS Version
  • This web service is very similar to the previous one: when you to submit an SDS variable name (e.g. "AETERM") and an SDS Version (e.g. "1.4") you will obtain information about that specific variable in the specific SDS version.

    REMARK: as SEND 3.0 is based on SDS 1.2, use "1.2" for the version in case you are looking for a variable name that is specific to SEND.

    The request structure is:{sdsversion}/{sdsvarname}

    For example, if you use:

    You will obtain the following XML (at least if your application/browser requests to get XML):

    Depending on application request, you will get similar structures as above for JSON and text requests

    Besides getting the information itself, these services are especially useful to test whether a variable was already defined in a specific SDS version.
    For example, the variable "--PORTOT" was defined in SDS Version 1.4, but not yet in version 1.3. So if your application requests:

    and your application requests XML, you will get:

  • Get SDS Variable Info for "generic" SDS Variable
  • The request structure is:{sdsvarname}

    Submit a "generic" SDS variable name (e.g. "--REASND") and a list of SDS variables and versions is returned.
    This service is especially useful to find out in which domains the variable is usually used (as defined by its appearance in the SDTM-IG) and to see what differences there are (in label, CDISC notes, ...) between domains

    For example:

    returns (when XML is requested):

    First, the "generic" implementations are displayed, followed by the "domain implementations":

    Remark 1: In your request, you can as well use "--LOC" as "LOC".

    Remark 2: For variables that have no domain prefix (like "VISITNUM"), just us as is, e.g.:

    The web service will then show you in which domain (and SDS Version) "VISITNUM" is used according to the SDTM-IG.

    The number of results in the set may considerably vary. For example, for "--PORTOT", which is a new variable in SDS 1.4, you will get 7 results (3 generic ones for each of the 3 main classes, for EC, PR, MO and for TU),
    whereas for "USUBJID" you will get 100 results (well, not surprising isn't it). For "--TESTCD" you will obtain 57 results.

    (first 6 XML nodes are collapsed)

  • Get all variables (with detailed info) for a given SDS Model, Version and Domain
  • IMPORTANT: Currently only implemented for SDTM and SEND, not implemented yet for ADaM

    The request structure is:{model}/{version}/{domain}

    For example for SDTM-IG v.3.2 domain:

    returns (when XML is requested):

    Or for a SEND 3.0 domain:

    returns (when XML is requested - some elements are collapsed):

  • Get SDTM variable detailed information for SDTM-IG version, domain and variable name
  • The request structure is:{sdtmigversion}/{domain}/{varname}

    For example:

    returns (when XML is requested):

    This Web Service is also IDEAL to find out whether a variable not directly mentioned in the SDTM-IG (e.g. LBSTDTC) is allowed as a variable in the LB domain. In this case, as --STDTC is a "timing variable" it is allowed in ALL general observation classes.
    We then automatically obtain all necessary information, e.g. for label, data type, ... from the SDTM model (so not from the SDTM-IG) which can be used in e.g. validation.

    Remark that the response is slightly different. There is no "Format" element (as this is only defined in the SDTM-IG, not in the model), but there now is a "CDISC_Notes" element. "Core" is set the "Perm" (permissible), as added non-IG variables are always permissible.
    Very important is that the element "Variable_Label" is replaced by the element "Variable_Label_From_Model". The reason for this is that the latter is only a suggested label, which should not be used for validation.

    If we try the same for e.g. "OCCUR" (which is not allowed in "Findings" domains at all), we will get for "LBOCCUR":

  • Get SEND variable detailed information for SEND-IG version, domain and variable name
  • The request structure is:{sendigversion}/{domain}/{varname}

    For example:

    returns (when XML is requested):

    Remark: The SEND-IG version can currently only be "3.0", as v.3.1 has not gone into production at CDISC yet.

  • Suggest SDTM variable based on the similarity between the SDTM variable label and the provided search string, for a given SDTM-IG version
  • The request structure is:{sdtmigversion}/{searchstring}

    For example:
    will return all variable information about the SDTM variables --HOSP and AEHOSP

    You can also add several words, for example: hospital
    or: event

    The responses are ordered by similarity (highest similarity first).


    Courtesy of XML4Pharma - last update: November 2017