Why FHIR is so cool - also for clinical research

Last week I took an "HL7 FHIR" course under the motto "life long learning".
I became enthusiastic about FHIR as it takes away many of my concerns about HL7-CDA.


FHIR (pronounce "fire") has been developed by software people, so by "ordinary" IT people, and in such a way that it can be used by people like you and me without needing to learn every detail of the HL7-v3 RIM.
I have been teaching HL7-CDA at companies, and am teaching CDA at the university. It is extremely hard to explain. When doing so I get questions like "why is a medication an Act?" or even worse "why is a medication an observation?", or "why is a document an Act - that simply cannot be true".


When using FHIR however, you do not need to know about the RIM, acts and observations or roles and entities. In FHIR a medication is called a "Medication" - that's it! Furthermore FHIR is about RESTful web services, which is a modern way of exchanging information. Furthermore, FHIR is about snippets of information (named "resources") and not necessarily about complete documents.


Why is this also so important for clinical research?


When an investigator for example wants to know about all the medications that were subscribed to a subject in the last five years by different healthcare providers, he can either query all these systems which have different interfaces (I suppose here he is allowed to do so and has access), or ask these systems to generate a standardized document like a CCD or CCDA in the USA, or an "Arztbrief" or "Entlassungsbrief" in Austria (which is a kind of discharge letter). All these are "documents", meaning that one first need to find the right section in the document (probably by OID), and then inspect the "code" and "codeSystem" to be sure the entry is really about a medication, and then extract the information. As a medication is just an "observation", this is not very easy to automate.
Also, will a hospital be willing to generate a CCD either "on the fly" or in "off line mode" for a medication that was prescribed 5 years ago? And will it want to reveal information about the patient that is needed to make the document valid, but has nothing to do with the request?


When using FHIR, a medication is a "Medication" and the investigator can query the systems where the subject has records using a RESTful web service and a standardized FHIR interface, returning snippets of information (FHIR resources) instead of a whole document. So only the relevant information is provided.


Also for the patients themselves, FHIR is or will be a huge improvement. For example, if a patient wants to make a plot of all his/her cholesterol values of the last years as function of time, he cannot easily do so from a set of CDA documents, as CDA was never developed for such a use case. He/she will probably need to copy-past the values from the CDA document (or from the HTML view of it) into an Excel worksheet or other application, and then try to generate the plot.
With FHIR, the patient just can use a tool that uses a RESTful web service to query the system with the LOINC code of the cholesterol test (or tests), and get a list of values back with the test dates. Making the plot from this list is then probably a piece of cake (generic software for patients can become available).

So if FHIR with its web services is made available for use by patients, it could also be used for clinical research (of course only with authorization of the subject). Getting all the medications of the last five years would then become much easier as it is now by extraction from CDA documents (which were never designed for such a purpose), if the latter can be obtained from the different providers at all.


Your comments are very welcome as usual!

Submissions in XML - Supplemental Qualifiers

Maybe you will say: "Wait a minute Jozef, it is not allowed by the SDTM Standard to leave the supplemental qualifiers in the original domain!".
You are right - it is not allowed YET.
 So sponsors will probably continue to generate Suppqual datasets for some time, and also this is supported by SDS-XML, as SDS-XML can contain any tabular clinical data.

One of the major problems reviewers had is that when looking at a supplemental qualifier datapoint, it was (using the SASViewer) not easy to quickly find the record in the parent dataset.

So how does the "Smart SDS-XML Viewer" deal with this?

Below you find a few screenshots of the example files that came with the define.xml 2.0 specification (but now formatted as SDS-XML). It has 10 supplemental qualifier datasets, of which 3 are for the QS domain only (SUPPQSCG, SUPPQSCS and SUPPQSMM).

Let us now look at the SUPPAE dataset. For a good number of the subjects, it has one or more records.

So how can we now quickly see the parent record in the parent dataset?
The "Smart SDS-XML-Viewer" easily allows this using the menu "Tools - Show parent record of SUPPQUAL record". Just select a record (or single cell) in the SUPPAE table and then use that menu. A message shows up:

saying that it found a parent record in the AE dataset (remark that there can be more than 1 parent records, e.g. in case IDVAR is a --CAT). Now just click OK or just hit the return button. The software automatically selects the AE table, and selects and highlights the parent record:

 

This can also easily be achieved using the keyboard shortcut CTRL-S ("S" standing for SUPPQUAL). One can then easily toggle between the SUPPAE table and the AE table either using the mouse and clicking the tab, or using the menu using "Tools - View - Last selected table", or even very simple using the keyboard shortcut CTRL-B ("B" for back). So using CTRL-B just toggles between the two tables.

The sample file also contains SUPPQUAL datasets for which the records do not point to an individual parent record, but to a set of records in the parent dataset. For example, the SUPPQSCG dataset for which IDVAR has the value "QSCAT", meaning e.g. for the first record that the supplemental qualifier refers to all records in the QS dataset for which QSCAT is "CORNELL SCALE FOR DEPRESSION IN DEMENTIA (CSDD)". 

Selecting the fourth record and then using CTRL-S (or using the menu), then gives:

stating that there are 78 parent records, i.e. 78 records for that subject for which the QSCAT applied.

Hitting the OK button then brings us to the QS table and selects and highlights these 78 parent records:

Cool isn't it? Try to do this using the SASViewer ...

Submissions in XML - first results

As already stated in my previous post, creating SDTM/SEND/ADaM datasets has a considerable number of advantages. Today I want to demonstrate a few of them as implemented in the "Smart SDS-XML Viewer", a software tool that we will make available as "open source" when the final specification is published by CDISC. The first advantage I want to demonstrate is real linking between data sets (also known as "joins"). For example, the FDA has insisted that the DM domain contains the information about the first and last treatment date/time, this although this information is already present in the EX dataset (first record of EXSTDTC and last record of EXENDTC). So the variables RFXSTDTC and RFXENDTC were created in the DM domain. That this violates the third normal form for good relational database design was obviously not taken into account. The reason the FDA wanted this is that their tools (SASViewer) was not able to link records in the EX and the DM datasets. The SASViewer can only read SAS-Transport-5 files but has no idea what they mean. With the new XML-based format, linking between datasets becomes very easy. I took me less than an hour to implement such a lookup for date/time of first and last treatment, so that this information appears as a tooltip on USUBJID in the DM table. Here is the screenshot:

Both the dates were taken from the EX dataset and are displayed in a very user friendly format.
One thing that could easily be added (I haven't done so) is the number of days between both days, and add this as a fourth line in the tooltip. Programming this would take me about 15 minutes I guess. If I had to do this from the SAS-Transport-5 however, I don't think I would have a chance (at least not without having to use SAS).

A second advantahe I would like to demonstrate is that supplemental qualifiers can now easily be kept in the parent domain. Most tools that generate SDTM datasets keep the supplemental qualifiers in the parent domain until the very last moment before the SAS-Transport-5 datasets must be generated. At that moment they are split of and "banned" to a separate SUPPQUAL domain such as the SUPPDM domain in case these are additional qualifiers for DM. The reason (I guess) that this was a requirement in SDTM is that there was no way to indicate in the dataset itself that a variable is a supplemental qualifier.
With the new format however, this is not necessary at all anymore. If the supplemental qualifier is marked as such in the define.xml, there is no reason anymore to "ban" it to another dataset. Software can then take care that these variables are marked as being supplemental. e.g. by a different color.

The following screenshot shows how this has been done in the "Smart SDS-XML Viewer". In our study, there are 6 supplemental qualifiers for DM. Instead of "banning" them to a SUPPDM dataset, they simply were retained in the DM dataset. In the define.xml, they have been marked as supplemental by setting the value of the "Role" attribute to "SUPPLEMENTAL QUALIFIER". As the software also reads the metadata, it knows what to do with these variables, in this case it colors them blue.

A third advantage I would like to demonstrate is the lifting of the 8-, 40-, and 200-character limitations, which caused so much pain in the past. In the following screenshot, the label for the variable COMPLT16 is displayed as a tooltip when the user hovers the mouse over the column header. In SAS-Transport-5, there was a 40-character limitation for labels, which we can  now get rid of.

Similarly, we can now get rid of the 200-character limitation. The SDTM forces us to split values with more than 200 characters into different variables and even different datasets (also here, there is a "banning" to a SUPPQUAL dataset). The splitting even has to be done in such a way that it is done between words, and not in the middle of word. In the CO domain (Comments domain), comments values have to be split and distributed over different variables, e.g. over COVAL, COVAL1 and COVAL2.
None of this all when using the new format. We do no split anything, as there is no reason anymore to do so.
The following snapshot shows a record in the CO dataset as displayed by the "Smart SDS-XML Viewer":

Submissions in XML

The CDISC XML Technologies Team is currently working on an ODM-XML based format for SDTM, SEND and ADaM submissions (or exchange). This format is envisaged to replace the old SAS Transport 5 (SAS-XPT, .xpt) format. The immediate advantages are obvious:

• no more 8-, 40-, and 200-character limitations 
• limitations on test codes disappear (this e.g. hindered us to use a LOINC code for LBTESTCD, as the LOINC code starts with a number, like 1234-5) 
• supplemental qualifiers can remain in their parent domain/dataset. All that needs to be done is to flag them as such in the define.xml file (e.g. using Role="SUPPLEMENTAL QUALIFIER")
• no more splitting of information over different fields (the COVAL1, COLVAL2, ... disaster) or even datasets ("banning" of information with over 200 characters to supplemental qualifier datasets)
• perfect fit with define.xml 1.0 and 2.0: validation of SDTM/SEND/ADaM datasets against the define.xml now really becomes a piece-of-cake. Both the metadata (define.xml) as well as the data (the new format) now use the same format - both are extended ODM. 

These are the advantages for the use of the standard (SDTM, SEND, ADaM) themselves. Further great advantages are:

• we can now really obtain end-to-end as we now have one format to transport information from study design to submission. Of course the contents will differ, but at least we do not need to switch between formats (and technologies) during the process 
• XML is the format of choice for exchange of information in the modern world. This also means that an enormous amount of software programs and software libraries are available for working with XML
• real vendor-neutrality: As ODM is an open standard (SAS-XPT was semi-open, it was very hard to implement in software) anyone with some basic XML knowledge can now develop great software with great features that work with SDTM/SEND/ADaM datasets. In the >20 years of SAS-XPT for SDTM, I haven't seen a single successful third party software programm using it. 

As the industry will need a transition period, the XML Technologies Team will also provide some tools like:

• tools to transform existing SAS-XPT datasets into the new format 
• tools to transform files in the new format to the old SAS-XPT format (but who would like to do so?) 
• tools or scripts for loading the datasets in popular statistical software packages 
• a viewer for inspecting datasets in the new format 

Development of that viewer is my task in the team. I called it the "Smart SDS-XML Viewer" as the name of the new standard will probably be "SDS-XML" and "smart" as the viewer will have capabilities and features that will go far beyond what the SASViewer could do.
The latter was just a viewer for SAS-XPT files, it was not "SDTM-savvy", it even did not understand what SDTM is about or how it works.

The picture below shows a few of the first features that were implemented sofar:

• simple SDTM/SEND/ADaM validation such as uniqueness of the USUBJID in the DM dataset
• check whether the subject is really present in the DM dataset
• validation whether all required/expected fields really have a value 
• validation of dates: is the date a real existing date (2013-03-32 is not), does RFENDTC really come after RFSTDTC? 
• calculation of age from BRTHDTC (when present) and RFSTDTC and checking against the value given in AGE 
• display of "date of first study medication exposure" and "date of last study medication exposure" as retrieved from the EX dataset in the DM dataset. The latter means that we can now remove RFXSTDTC and RFENDTC from the DM domain - they should never have been there as they are copied from EX

The second screenshot shows how easily supplemental qualifiers can now be visualized: the picture shows the right side of the DM table where the supplemental DM qualifiers are shown.

The columns containing these are colored somewhat differently (that information is retrieved from the define.xml). For ease of use, the USUBJID column has been shifted.

Other features that have been implemented, but which can be better demonstrated using a movie (soon to come, stay tuned) are one-click "jumping" to the corresponding record in the DM dataset (and back), one-click jumping from a comment record in CO to its parent record in another dataset and few-click jumping from a RELREC record to its parent records.
Of course the software also allows sorting and filtering. For example, one can first load the DM dataset and e.g. filter all subjects above a certain age, and than load other datasets for those subjects only. This feature will probably make life of reviewers much much easier.

Another small feature I implemented is highlighting of values (--STRESN) that are outside the reference range (defined by --STNRLO and --STNRHI) for all findings datasets.

Now you will probably ask what the cost of this viewer software will be. The answer is "nothing". It will become available for free as "open source" with a license similar to that of OpenCDISC. So reviewers at the FDA will be able to use it for free from day 1, and users at sponsor companies will have the same tool available as what the FDA reviewers are using. Even more important: as the tool will be open source, everyone can extend it, add great new features, for example for analysis, visualization, etc.

Stay tuned for more information and the public release announcement!

Electronic Health Records within ODM

One of the arguments that some at the FDA have for choosing HL7-v3-CDA as a future format for SDTM submissions is that CDA can carry electronic health records (well, that's the only use-case HL7-v3 has been successful in). As SDTM is clinical information is medical information these persons (who are not experts them selves, but who listen to hear-say) believe that CDA is also a suitable format for SDTM data.

CDISC ODM has already been proven to be able to carry submission (SDTM) data: at least 3 vendors of mapping software use CDISC-ODM to store SDTM data, and only in the very last step of their transformation process, they "downgrade" it to SAS Transport 5.

But let's have a look whether CDISC ODM is capable of containing information from health records.
This becomes more and more important due to the upcome of "single source", the technology to capture data only once and store it as well in the EHR system as in the EDC system simultaneously. Another reason is that within the FDA there is a "vision" that reviewers in future should not only have access to the collected data from the study, but also to (some of) the electronic health record data of the subject.

So how can we incorporate EHR data into an ODM?

Let us start with a simple ODM file containing the study definition. One ItemGroup (subform, page) may look like this:

and one the corresponding ItemDef is:

[as you see, this is an international study, running in the US, France, Germany and Korea]

The ItemDef contains a good amount of additional information, such as that the height can either be measured in inches (for the US) or in centimeter (in the other countries).
Also the edit checks in the form of allowed ranges (both for inches and for centimeter) is added.
Last but not least, it is stated that this data point will later go into the value for the SDTM variable VSORRES for the case that VSTESTC is "HEIGHT". We call this "SDTM annotation in ODM".

The data points themselves in the "ClinicalData" section of the ODM then look like:

stating that the collected value for the "height" is 193 and the unit is "cm".

Now we also want to include the original source of the data, which is a data point in the EHR.
How can this be done?

The ODM has an excellent "extension mechanism", allowing to add extension elements and attributes which "live" in another namespace and come from other standards, and still have the possibility to validate such "mixed" files against the XML-Schemas of both standards.
HL7-v3 does not have such an extension mechanism: although you can add elements and attributes from other standards, you loose the ability to validate mixed instance files.

As the information from the EHR "lives" in the HL7 namespace you first need to declare that namespace, which is usually done at the top level element of the XML document.
In our case:

stating that all elements prefixed by "cda:" (which is an arbitrary choice) live in the namespace "urn:hl7-org-v3" which is "owned" by the HL7 organisation.

We can now generate an "extension" XML-Schema according to the rules given by the ODM standard (I can send a copy of that to those that are interested), in which we describe that the HL7-v3 element "observation" (corresponding to a single observation in the EHR) is a legal child element of the ODM element "ItemData".

Piece of cake!

This now allows to incorporate the source data point of the EHR into the ODM data point. For example:

In the EHR, "height" was coded using the SNOMED-CT coding system, the data point was collected on 13 March 2010 (remark the stubborn refusal of HL7 of using ISO-8601 format), the value was "193" and the unit (which is a UCUM unit as always used in HL7-v3) was "cm".

So we now have the source data point within the ODM file within the ODM data point itself!

What can of course also be done additionally is to add a reference (e.g. using an "href") to the location of the EHR of this specific subject in the EHR system.

Some people will immediate ask: "what about ISO-21090" datatypes?
ISO-21090 datatypes are envisaged to become the "datatypes" (i.m.o. the name is inherently wrong) or better "data objects" of the future for the healthcare world. They have been developed as a joint effort between different standardization organizations (well, sort of - essentially only HL7 and ISO were involved. Others such as CDISC and OpenEHR were not asked).
CDISC uses ISO-21090 in BRIDG. However, until now there is no real XML implementation of BRIDG. ISO-21090 also violates ISO-86012, but that is another story I need to write a separate blog entry about.
Another problem is that implementing ISO-21090 is extremely expensive. If you want to obtain a copy of the specification, you need to pay ISO the humble amount of 238 Swiss Francs (about 200€ or 250US$). If you pass that specification to your colleague, he/she also needs to pay that amount, as the document is copyrighted. Not a good way to promote a standard isn't it?
Furthermore noone is actually using ISO-21090 yet. HL7 plans to implement it in the future release 3 of the CDA standard. Release 3 however is currently only in the mind of some persons, even not on the drawing board yet. Some people have criticized ISO-21090 to be too complex to be implemented in any standard anyway.

So, if you would like to implement ISO-21090 data (types) points in ODM, what needs to be done?
Essentially, through the ODM extension mechanism, this is a piece of cake again. One just needs to write a simple "envelope" XML-Schema, and a small "extension" schema, in which you define that "ItemData" is allowed to contain ISO-21090 data points. That's it. In principle, the ISO-21090 elements and attributes will then "live" in the namespace "uri:iso.org:21090".
Again, if you need any technical details or an example set of file, just send me a mail.

What ODM (and SDTM) can learn from HL7-CDA

There has been a lot of discussion about using HL7-v3 messages in XML for submissions to the FDA. Especially some people at the FDA (who are not XML experts at all) are in favor of this: they expect better integration with EHRs from this. But they do forget that HL7-v3 messages is not about EHRs at all: they mix up between HL7-v3 and CDA (the latter using a subset of HL7-v3).
Their logic is similar to: "If I have a truck (transport format) that can carry cows, and the same truck can carry oranges, than I will be able to breed cows that can produce orange juice".
More reasons for not choosing for HL7-v3 for (SDTM) submissions can also be found in my old article "Ten good reasons why an HL7-XML message is not always the best solution as a format for CDISC standard - and especially not for SDTM data". Also the recent postings from Gartner have indicated that HL7-v3 messages have been a big failure.

I am getting currently getting training from HL7 Austria, which will (hopefully) make me an HL7-standards experts and especially make me even more better in working with CDA. If all goes well, this will also deliver me HL7 certification.

As I also am teaching CDA at the university (as the Austrian EHRs system "ELGA" will be based on CDA), I do see more and more clearly (also technically) how information from EHRs can be used in clinical research: the answer is NOT in using HL7-v3-XML for FDA submissions, nor in data collection: we do have CDISC ODM for that.

However, there are a few things we can learn from CDA, and which we may want to introduce in ODM, or at least allow it (though standardized extensions). Here is a first list:

- use of universal Object Identifiers (OIDs). These are not the current OIDs of ODM, but the one used in CDA and ISO-21090. For example:

The "Object Identifier" here is "2.16.840.1.113883.6.1" which is the worldwide recognized identifier for the LOINC controlled terminology for lab tests, which is used by almost every hospital in the world that has computers. "8480-6" is the LOINC code for "systolic blood pressure".

In ODM, we would probably use an "Alias" for this, e.g.:
<Alias Contexrt="LOINC" Name="8480-6"/>  
or  <Alias Context="2.16.840.1.113883.6.1" Name="8480-6"/>

But better would be that we could incorporate this into the ItemDef, e.g. using:

Don't pin me on the "cda:" prefix for the extension namespace: it was arbitrarily chosen.
Also remark that I additionally added a "MeasurementUnitRef" and an "Alias", the latter to indicate that this data point should later be mapped to SDTM "VSORRES" for "VSTESTCD=SYSBP" (the latter belonging to the CDISC controlled terminology.

Also remark that this snippet contains all necessary information to enable that information from an EHR (in CDA or CCD) is automatically retrieved into a CRF in case the systolic blood pressure in the EHR is coded using LOINC (it can also have been coded in SNOMED-CT, which would just add another line to the above snippet)

Though CDA-R2 is not using ISO-21090 datatypes (yet - it is envisaged for CDA-R3), many people have been asking or even demanding that ODM replaces its own datatypes by ISO-21090 datatypes. We must however take into account that currently ISO-21090 datatypes can only be used in captured data, not in definitions of to-be-captured data. So it currently not possible (without adding new stuff to ODM the standard) to define that "the systolic blood pressure will be captured as a "physical quantity' (PQ datatype)". One can only state that "the systolic blood pressure has been captured as a 'physical quantity'".

So for example, in CDA-R2, a systolic blood pressure observation is written as:

whereas in ODM it would be written as:
<ItemData ItemOID="IT.SYSTOL" Value="132">
    <MeasurementUnit MeasurementUnitOID="MU.mmHg"/>
</ItemData>

Remark that CDA/ISO21090 is using the code and codeSystem (in this case SNOMED-CT) which is more or less equivalent to the use of a reference to the ODM-OID of the ItemDef in "ItemOID". I say more or less, as each has its advantages and disadvantages.
The CDA/ISO-21090 "notation" has the advantage that it is universal, as a machine will immediately understand, that the data point is about  a systolic blood pressure.

The disadvantage is that there will not always be a test code available for a (new?) test in a clinical study.

Also remark that the CDA/ISO21090 "notation" contains more information, such as the capture date and time, which would be a separate data point in ODM.

So why not combine best of both worlds?

Consider the construct:

Not valid ODM you say!?

This is valid ODM, using a "vendor" extension, allowing elements from the CDA-R2 standard or ISO-21090 standard to appear within the "ItemData" element.

Using this simple and valid construct, it is possible to combine the best of both worlds, and even to directly insert a data point from an EHR into a CRF.

Now, I am not an absolute supporter of ISO-21090, for at least two reasons:

• you have to pay in order to obtain a copy of the specification - and it is not cheap: ISO will charge you 238 Swiss Francs (currently US$ 250 or € 200). The document is copyrighted, so if you pass a copy to your colleague, it's either illegal unless you pay another 238 Swiss Francs.
  Therefore, I do not really consider ISO-21090 an open standard.
• The XML is bad: have a look again at the last snippet. Did you notice something weird?
  Have a look at the date "19990229". This is not an ISO-8601 date in the XML sense. It is even not a valid date: there has not been a "february 29th in 1999.
  But if you validate against the schema or the schematron, this error will go unnoticed.
  CDISC uses ISO-8601 in its XML (but also in SDTM), and if you would validate some CDISC XML in which the (now with the correct XML notation) "1999-02-29", the validation engine would immediately and loudly protest. So the HL7 people made a big mistake here!

Another thing you might have noticed is the use of the "mm[Hg]" in the "unit" attribute. This is UCUM notation (Unified Code for Units of Measure). Although healthcare all over the world uses UCUM units, CDISC decided to develop its own controlled terminology for this. In my opinion, it would be better if also CDISC would only use UCUM units.

So what we still need to do to be able to currently better use EHRs in clinical research, is a mapping between CDISC controlled terminology for units of measure, and UCUM units. Of course it would be better if we deprecate our own controlled terminology for that, and only use UCUM units.

But for the moment, we could use the following construct in ODM:

<MeasurementUnit OID="mmHg" Name="millimeter mercury"
     ucum:unit="mm[Hg]">...</MeasurementUnit>

which again defines the link between the CDISC controlled terminology and UCUM.

So, though CDA is not perfect (and HL7-v3 messages are a disaster), there still are a few things we can learn from CDA. Most of it can already be implemented (due to the "vendor" extension mechanism), as well in ODM as in a future SDTM-XML.

Our truck can then carry types of clinical and healthcare information at the same time, even linking both of them perfectly.

That is what we "CDISC end-to-end" is really about!

SDTM in XML - the data themselves

No that we made the define.xml more logical (and much more end-to-end-friendly), we can do the same for the data themselves.
We do not need VSTEST anymore (as it is a "synonym" or "display" variable, and listed in the metadata),so I commented it out, and we also can move the units of measurement to where they belong, i.e. as an attribute to the data point rather than as an attribute to the record.

This leads e.g. to the following SDTM-XML:

Remark that there is no explicit VSORRESU, nore VSSTRESU anymore, but the units have been attached directly to VSORRES and VSSTRESN.

When going from the "flat" SDTM-XML representation (see post of xxxx-xx-xx), I would call this "minimal-invasive multidimensional SDTM in XML" (the world is not round!).

There is some similarity with how HL7-v3, HL7-CDA/CCD and ISO-21090 is handling such information, e.g.:

We see that the unit of measure ("unit" attribute to "value" element)  is directly attached to the datapoint itself.
There are however also some main differences with ODM:

• HL7-v3 (as far as I know) does not have a construct for isolating the metadata. It does not know about planning a visit, planning which forms are used in a visit, which questions to ask etc..
  In HL7-v3 every data point is an "observation", and one cannot see whether that "observation" was planned or "ad hoc", i.e. the physician spontaneously decided to do a specific test or to make a specific observation.
  Therefore, there is also no referencing to a specific metadata section.

Also remark in the above HL7-v3 snippet (it comes from a CCD document) the use of "xsi:type" which is currently disputed within HL7 as it is not well validatable and essentially has nothing to do with XML-Schema types.

Remark also the bad usage of date formats (in element "effectiveTime") which does not follow the ISO-8601 rules for XML dates. The disastrous effect is that e.g. a date "2011-02-29" (which does not exist) is a vaid date in HL7-v3.

On the other hand, HL7-V3 uses a lot of "code" and "codesystem" with OIDs (unique object identifiers). In the snippet the codesystem "2.16.840.1.113883.6.96" stands for SNOMED-CT, and the code "271649006" stands for "systolic blood pressure" (NEVER trust what is in "DisplayName"!).
CDISC however decided to generate its own controlled terminology (unfortunately without OIDs), which means that we urgently needs mappings between CDISC-CT and coding systems used in healthcare such as SNOMED-CT, ICD-10 and LOINC, if we really want to enable integration between healthcare and clinical research.

Another very nice thing in CDA is the use of UCUM units of measurement (http://unitsofmeasure.org/) which I could recommend highly. There is currently no good placeholder in ODM for adding UCUM units of measure (except maybe for the "Alias" element), so I think we should have an additional attribute in the next version of ODM to allow to give the UCUM code for each unit of measure that we use in the study. The great advantage is that the use of UCUM codes easily allows for transforming one unit in another (e.g. from pounds to kilogram).
But that's another topic for one of the next blog entries.

Back to our SDTM-XML data snippet. I call it minimal-invasive because it only deviates in a small amount from a two-dimension representation of the data.

But if we look more careful, we can see a lot of things we can further improve:

• do we need the datapoint (SDTM variable) "DOMAIN"?. The fact that we have ItemGroupOID="MyStudy:VS", which is a reference to the "ItemGroupDef" with OID "MyStudy:VS" and which has the attribute "Domain" with value "VS" already gives us that information

Other strange things in define.xml

Although some people will protest, I am still stating that the SDTM standard has been written with SAS XPT in mind. The 8-character, 40-character and 200-character limitations in SDTM do have a source: the ancient SAS XPT format.
Another major problem of SAS XPT is that it essentially describes two-dimensional tables, similar to tables in relational databases. But even if the SDTM is a blueprint for databases, database specialists will still find a lot of strange things in the specification and implementation guide.

"The world is not flat" has been preached by Armando Oliva from the FDA, stating that also the FDA would like to go to a multi-dimensional model for SDTM submissions. Unfortunately, what they are proposing is a set of HL7-v3 messages, not really knowing what they are talking about.

Multi-dimension models for SDTM would make life (and CDISC end-to-end) considerably more easy, and it would us allow to get rid of many of the strange and illogical constructs in define.xml.

Let us e.g. have a look at the pair VSTESTCD and VSTEST.
According to the SDTM standard, VSTEST is a "synonym" qualifier to VSTESTCD (the standard speaks about "equivalent terms for a --TESTCD". So VSTEST is NOT an attribute of the SDTM record, it should be an attribute to VSTESTCD.
But how is this made visible in SDTM datasets and in define.xml?
It isn't.

Even worse, both VSTESTCD and VSTEST have controlled terminology, i.e. there is an associated CodeList in define.xml for each of them. Let's have a look:

Here is the codelist for VSTESTCD:

and here the one for VSTEST:

We see that define.xml uses CodedValue = Decoded Value.

But how do we now know that "BMI" corresponds to "Body Mass Index"?

These are related 1 to 1 isn't it?
Maybe we know, but there is no way a machine can understand this.

So, what's wrong?

The reason for all this is the flatness of the SDTM, due to the choice of SAS XPT as a transport format.

For me, VSTEST (i.e. test name) is just  a "display variable" to VSTESTCD, i.e. it is not really necessary, and when using XML, one could just display it when necessary, i.e. as a tooltip in the HTML that is generated by the stylesheet.

I will soon write a separate blog about how this can be done and how it could look like.

So, ideally, in the define.xml there should NOT be a variable VSTEST, only a VSTESTCD, and the ItemDef for VSTESTCD should look like:

Remark the use of SDSVarName to keep the SDS (SDTM) Variable name, and the correct use of the "Name" attribute containing the test name (description), so that we do not need VSTEST anymore.

Here is the associated codelist:

It clearly shows that "Adipose Tissue" is the vital sign test name for the vital sign test code "BODYFAT", a relation that cannot be found out with the current SDTM constructs.

Next time, we will see how this can be further extended for units of measurement (--ORRESU, --STRESU) and valuelists.

SDTM in XML - the metadata

The previous post showed a snippet of ODM-XML that could be used (and is used by a number of vendors) to store SDTM data in an XML format.
Now, we do already have the metadata for this set of SDTM data in XML format: it is the define.xml.
For example for the VS domain we may find:

(P.S. The order of the attributes is unimportant in XML, the browser just lists them in alphabetical order)

I have set Mandatory="Yes" for those variables that are "required", and to "No" for those that are expected or permissible. The reason is that ODM has the rule that a data point MUST have a value when Mandatory="Yes", and because a data point can be null (or absent) in SDTM even when the variable is expected, we need to set Mandatory="No" for expected variables. A typical example is VSORRES which can be null if the test was not done.
In my personal opinion, it was a design error in SDTM to have "expected" variables. In my opinion, they should have been called "conditionally required", and the rules should have been stated.
But I must also admit that also ODM does not have a good construct for "conditionally required" data points.

The careful reader will already have noticed that the SDTM data in XML format in the previous post do not have an entry for VSSTAT and VSREASND.
There is a very good reason for that: in ODM, only the data points for which there is a value are listed within an "ItemGroupData". Only when one explicitely wants to state that a data point has been set to NULL, one can use the "IsNull" attribute (for further details, see the ODM specification).

One thing I have never liked in define.xml is the "abuse" of the "Name" attribute to keep the SDTM domain name or SDTM variable name (the latter in ItemDef). In ODM the "Name" attribute is used to keep a short description (for display) of the variable, as free text (so not enumerated). This short description is kept in def:Label in define.xml. In my opinion, it shouldn't. That the developers of define.xml have chosen to have an extra (def:Label) attribute is strange, as in ODM, there is already an attribute to keep the domain name, i.e. "Domain" in the case of an ItemGroupDef, and to keep the SDS Variable name, i.e. "SDSVarName" in the case of the SDS/SDTM variable name. So the better solution would e.g. have been:

<ItemGroupDef OID="MyStudy:VS" Name="Vital Signs" Domain="VS" Repeating="Yes">...</ItemGroupDef>

which I think would make more sense, especially as it makes end-to-end easier (less transformations necessary). Probably (but I am not 100% sure) the developers of define.xml did not choose for this solution because "Domain" is not a mandatory attribute in ODM.

One step further - SDTM in XML

We do already submit the metadata of our SDTM submission in XML format (define.xml).
So why not submit the SDTM/SEND/ADaM data themselves as XML?
It would have so many advantages!
Only a few ones (I could name about 100):

• really vendor-neutral (SAS XPT is not vendor-neutral at all)
• vendors can much easier develop tools for working with the submissions, as there are so many libraries for working with XML in Java, C#, C++, Python, PHP, Perl, ... (I do not know of a single library in any of these languages to use with SAS XPT).
• easier to validate (e.g. using XML-Schema and Schematron)
• easy to display (through XSLT stylesheets)
• easy to develop different "views" on the data (through stylesheets)
• extremely easy to combine different datasets / studies etc.
• display stylesheets can mark (e.g. by background color) violations to the SDTM-IG rules
• much more compact than SAS XPT (one of the major complaints of the FDA is that they cannot open large SAS XPT files)
• ...

But how could such an SDTM dataset look like?
Here is an example:

This is just simple ODM, and can be generated from the source ODM "ClinicalData" that every modern EDC system generates by a simple transformation - no expensive statistical software necessary. It can however also be generated very simply by using statistical software (if that is your preference).

Just a few remarks about the advantages (I will discuss many more in later posts):

• the first line states 'TransactionType="Insert"'.
  One of the FDA complaints is that they obtain updates of submissions and then must load the complete data sets again into their tools, without any possibilities to compare the old data sets with the new ones. The "TransactionType" mechanism of ODM however allows to only send the updates themselves, i.e. only the data points that were changed, and it is always clear what the status of each data point is.
• this is human-readable! Did you ever try to open SAS-XPT files with another tool than from SAS? SAS XPT is binary and so one needs to write special software (writing software is always expensive), or use SAS to be able to inspect the contents of the file
• one can easily develop different stylesheets to get different "views" on the same set of data. With the conventional tools (SASViewer, JMP, ...) you get only one view: the tabular view.

You may see redundant information in the XML snippet. But these are due to the SDTM standard itself, as a result of the restrictions of the SAS XPT format itself: due to these restrictions, the developers of the SDTM standard had to add additional variables to make some information visible.

So the next step could be to write an extension (similar to define.xml) for submission data in XML that allow to get rid of much of the redundant information that is now present. This would further enable to reduce the file size of SDTM submission data sets.
But that is new material for another post.

Now that we talk about file size, it was the FDA that made the choice for SAS XPT in the past (although there were alternatives). SAS XPT format wastes enormous amounts of (disk) space. And now the same FDA is complaining about file size of SDTM submissions! Well, they got what they wanted (i.e. trouble) isn't it?
So, it is high time that the FDA starts investing in XML knowledge, as it is the standard for exchange of information worldwide, not only in the healthcare world, but also in the financial world, the travel world, in bioinformatics, in chemical research, in astronomy, etc. etc..

One could now state that a good alternative may be HL7-v3 messages (which are also based on XML, though more a "rape" of the XML standard). I wrote already about why that is not a good idea, and will also write some more about that in one of my next posts.