The meaning of "Unit"

Last week, I worked on a mapping between the CDISC-CT [UNIT] codelist, and UCUM. For every "unit" published by CDISC (there are about 550 of them), I tried to find an appropriate UCUM notation. Then I used the mapping (which was done using extending the Excel worksheet provided by CDISC) to generate a relational database and also generated a RESTful web service.
So, when you make an HTTP request "http://www.xml4pharmaserver.com:8080/CDISCCTService/rest/getUCUMFromCDISCUnit/BEATS/MIN" the corresponding UCUM notation {beats}/min will be returned. Similarly, if you submit "http://www.xml4pharmaserver.com:8080/CDISCCTService/rest/getUCUMFromCDISCUnit/mmHg", then "mm[Hg]" will be returned.

I then implemented this web service in the Smart Dataset-XML viewer: when the user right-clicks a cell with a unit (e.g. --ORRESU or --STRESU value), the web service is triggered and the UCUM notation is shown (when the cell value is a valid unit from the [UNIT] list). A few screenshots are shown below:

 

In some cases, the CDISC notation follows the UCUM notation, but this is surely not always the case, especially for non-SI units the deviations are considerably.

What difficulties did I encounter during the mapping exercise?
Quite a few ...
Some CDISC "units" are not units at all. For example "Virtual Pixel" (NCI C71620).
Other "units" are mixing up objects "what it is about" and units. For example "g/mol Creatinine". UCUM has recognized that this bad habit exists and has solved this by so-called "annotations" (see the UCUM specification). So the UCUM notation for this is "g/mol{creatinine}.
In my opinion, CDISC should control annotations for use in clinical research, not the units themselves.
A difficulty that arose, and costed me quite an amount of time is the "unit" "U/kg". The CDISC definition is: "An arbitrary unit of substance content expressed in units of biological activity per unit of mass equal to one kilogram. Unit per kilogram is also used as a dose calculation unit expressed in arbitrary units per one kilogram of body mass". This sounds like a dual definition, i.e. "U" is used for two different things. When it is a unit of biological or catalytic activity the UCUM unit "U" can be used which is equal to 1 umol/min:

 

So when a biologial activity is meant, the corresponding UCUM notation for "U/kg" would then simply be "U/kg" which is equal to 1 umol/min/kg.

When "arbitrary units per one kilogram of body mass" is meant (second part of the CDISC definition), then it is something arbitrary, and depending on what is measured. In such a case, an annotation must be used. So, in the second case, the UCUM notation must be {Unit}/kg.

It is OK that a "CDISC unit" means completely two different things depending on the use case? I don't think so. Is "arbitrary unit" a unit anyway? Isn't the wording "arbitrary units" a "contradictio in terminis" anyway?

Do you also think CDISC should stop developing controlled terminology for "units" and use UCUM?

You reactions are as always highly appreciated.

 

SDTM: let the service do the work - not the dataset

This week, I found some time to continue working on SDTM. Or better: on services for SDTM. In my previous blog entry, I already showed how web services can help working with controlled terminology such as the LOINC codelist for laboratory tests.
I know extended this for CDISC controlled terminology (CDISC-CT) in general, based on the work of my student Wolfgang Hof. First, I download the latest CDISC-CT (june 26) from the NCI website as a set of XML files. Starting from these, I generated and populated a database with about 6 tables. I then wrote some RESTful services so that remote applications can retrieve information for answering questions like:

• what is the test name for test code XYZ?
• what is the NCI code for test code or test name XYZ (or the other way around)?
• what is the CDISC definition of controlled term ABC?
• are there any synonyms for controlled term ABC?

I hope to make these services available for the general public in the next few weeks.

Then I implemented a good number of these services in the "Smart Dataset-XML Viewer". Here is a screenshot as an example:

What you see that is when the user hovers the mouse over a test code (in this case a LBTESTCD: SPGRAV), the web service is triggered, the test name and NCI code is retrieved from the remote server/database and displayed as a tooltip on the cell contents.
When the user right-clicks the LBTESTCD cell, the web service is triggered and looks up the "CDISC definition" for the given test code and displays it in a separate window (left upper corner).
When the user right-clicks the LOINC code for this test (in this case 2965-2) a request is send to the RESTful web service of the "National Library of Medicine", returning the address of a website with explanations about the test, which is then displayed in a browser window that pops up.

On the right, you also see some yellow-colored cells. These indicate that there is something special with the data. In the current case, the cell is colored because its value is lower than the low normal range limit. This is not done by a web service, but by the viewer software itself. Thus, when using this feature, the SDTM variable LBNRIND is superfluous and can be removed from the SDTM specification ("let the service do the work - not the dataset"). Other such features that are already present in the "Smart Dataset-XML Viewer" are:

• show date of first and last exposure in the DM dataset (retrieved from EX)
• show --DY value on any --DTC value (calculated from difference with RFSTDTC in DM)
• show visit name on VISITNUM (retrieved from TV)

Essentially this means that many of the SDTM variables (all the ones that are "derived") are superfluous. We estimate that about 1 in 3 SDTM variables could be removed from the SDTM-IG as they can be calculated "on the fly" from the data that are already present in the datasets, or being retrieved by a web service. For example, all --TEST variables are superfluous, as their value can be obtained from a web service.

Now, this is just the tip of the iceberg. So many other things are possible which can considerably contribute to data quality in SDTM submissions. A few examples:

• the web service informs about what the usual units for the test or observation are. For example: mm[Hg] for SYSBP and DIABP, cm and [in_i] (inches) for WEIGHT, no units for SPGRAV. This can be used to test whether the combination of ORRES and ORRESU is reasonable and acceptable
• if it were allowed to use UCUM notation for ORRESU/STRESU (unfortunately it is not yet, although all EHR systems and Hospital Information Systems work with UCUM - it is even mandated by Meaningful Use), then the value of --STRESN could be automatically calculated. The combination of the value of --TESTCD with --ORRES and --ORRESU could be send to the web service with the request "please calculate the standardized numerical value", as the web service already knows to what unit the value must be standardized to for the specific test. This would even enable to have such normalizations as some of the values for blood pressure are e.g. in [psi] (pounds per square inch)

In my opinion, these are the kind of features and services people will expect from SHARE in the future. SHARE should be more than a repository of standard specifications, it should behave as an semi-intelligent system that help sponsors and reviewers improve data quality of electronic submissions.

For those who like these features of the "Smart Dataset-XML Viewer" and these web services, I am still working on improving the features and extending them, and I hope to make a new (branched off) version of the Viewer available on the Sourceforge website within the next 1-3 weeks. So please remain a bit patient ...

Comments are of course always welcome!

LOINC Web Services

In my previous post, I showed how a simple web service (using REST) can be used to retrieve information about a LOINC code from a remote public server. In the "Smart Dataset-XML Viewer", when the user hovers the mouse over a LOINC code, additional information about that LOINC code is displayed as a tooltip. I now extended this principle to connect to a webservice from the National Library of Medicine, named MedLinePlus Connect. What the webservice is however returning is snippet of XML containing a reference to a website that contains a lot of explanation about the given test. The way I implemented this is such that when the user right-clicks a LOINC code in the "Smart Dataset-XML Viewer", the MedLinePlus webservice is called, the website reference is retrieved, and the user's default browser is opened with the given URL. So when I right-click "3094-0" in the viewer, a new browser window pops up, giving me the MedLinePlus information about the corresponding "Blood Urea Nitrogen" (BUN) test:

 Cool isn't it?

Is this rocket science? No, not at all, it only costed me 3 hours (including writing this blog) to implement this in the "Smart Dataset-XML Viewer".

MedlinePlus also has similar web services for SNOMED-CT, ICD-9 and ICD-10, and medications (RXCUI).So what I want to do in the next few days is to see whether we can implement more of these web services in the "Smart Dataset-XML Viewer".

Why LBLOINC is so important - web services

LOINC is a worldwide recognized coding system for laboratory tests. It contains over 72,000 codes for lab and vital signs tests, and is used in almost every hospital in the world.
The use of LOINC coding is mandatory in most electronic health record systems and standards for exchange of them, like HL7 CDA. Also, in order to achieve semantic interoperability, the US "Meaningful Use" programm mandates the use of LOINC coding (see e.g. http://blog.healthlanguage.com/blog/bid/220742/LOINC-and-Meaningful-Use).

Still, CDISC refuses to mandate the use LOINC in SDTM LB (laboratory) datasets. Instead, it has developed its own controlled terminology for lab tests,  and has published this on the NCI vocabulary website. The latest version of CDISC-CT for lab tests has somewhat more than 2,200 test codes, so it is considerably less detailed and less granular than LOINC. Even worse, the CDISC-CT is just a list, whereas LOINC is a 5-dimensional system.

Essentially, this means that sponsors or their service providers must map whatever they get from the labs to CDISC-CT, which is not only laborious, but also prone to error. A few years ago, a "CDISC LOINC most used codes" list has been published, but is does not contain the CDISC-CT codes, and  is also not maintained anymore. Since then, the number of CDISC-CT codes has multiplied.

In the SDTM domain, there is a variable LBLOINC (LOINC code) but is marked as "permissible" and the explanation is: "Dictionary-derived LOINC Code for LBTEST" meaning that the LOINC code should be derived from LBTESTCD/LBTEST, and not the other way around.
So we have the ridiculous situation that the recommended workflow is to derive LBTESTCD/LBTESTD from what the lab is delivering (although the lab itself is using LOINC internally) and then derive LBLOINC from LBTESTCD/LBTEST. You can already guess what will come out of such a workflow.

The fact that LBLOINC is "permissible" has led to the praxis that LOINC codes are omitted from SDTM submissions. I only have seen a small fraction of SDTM submissions where they are provided. This also means that the FDA cannot compare lab test results between different studies and sponsors, as LBTESTCD is not sufficiently granular and is ambiguous.

One of the arguments that people have used against the use of LOINC codes in SDTM is that FDA reviewers cannot deduce information about what the test exactly is just from the LOINC code, which is 4-5 digit number + 1 check digit. Better said: the review tools of the FDA are not connected to a LOINC database for LOINC-code lookups.

Therefore, we have developed a LOINC lookup "RESTful" web service and implemented it in the "Smart Dataset-XML Viewer". It's all still a prototype, but I would like to present the first results anyway.

The development of the prototype took me 3 evenings and a saturday afternoon: one evening for installing the LOINC database on my application/web server, 2 evenings for programming the web service (server side), and one evening for implementing the client side in the "Smart Dataset-XML Viewer". So this is not "rocket science" and I wonder why NCI has not yet implemented such web services for their vocabularies.

Here is a snapshot of a first result:

This is a snapshot of the view of an SDTM-LB dataset using the "Smart Dataset-XML Viewer", containing a LBLOINC column (remark that I moved it to the left just after the LBTESTCD column).
When the user hovers the mouse over an LBLOINC cell, the webservice is triggered, and the code (in this case 26515-7) is send to the LOINC terminology server, and as well the short LOINC name (showing the 5 dimensions), the LOINC "common" name (for "normal" people well- understandable short description) and the example UCUM unit or units that are given in the LOINC database are returned by the web service. This information is then combined, and showed as a tooltip on the cell.
It is important to note that the "Smart Dataset-XML viewer" does NOT have a LOINC database, but it uses a "web service" on a remote server that is generally available to anyone or any application that is connected to the internet. 

We are currently developing a series of such web services and will make them generally available. One my my students has already developed a --TESTCD lookup service (see http://cdisc-end-to-end.blogspot.co.at/2014/04/submissions-in-xml-next-step-web.html and http://cdiscguru.blogspot.co.at/2014/07/why-sdtm-should-not-contain-test-as.html) which I still need to implement on a public server, and we will also develop a "UCUM conversion" web service, that e.g. allows to calculate a blood pressure in mm[Hg] from a blood pressure in [psi] "pounds per square inch).

Such web services will hopefully trigger CDISC to adhere to worldwide healthcare accepted semantic standards for laboratory tests and for units, instead of developing their own controlled terminologies for these.

If you would like to try out our LOINC webservice, just send me an e-mail, and I will provide you with the details how to query it.

Submissions in XML - the next step: web services

In one of my previous entries, I showed how some SDTM variables are essentially superfluous as they are derived and the derivation can as well be done by the tool that reads the data, such as a viewer. Such features were already implemented in the "Smart Dataset-XML Viewer" (freely available from SourceForge). Using this viewer, the user can get values for all "--DY" variables calculated "on the fly", as well as the values for RFXSTDTC (first date of study treatment exposure) and RFXENDTC (last date of study treatment exposure) which are automatically retrieved from the "EX" dataset and displayed in the "DM" dataset.

One of my students (Wolfgang Hof) has taken the idea a step further and has developed a web service (using RESTful web service technology) for retrieving information about test codes (like LBTESTCD, VSTESTCD, ...). He developed a simple database and server software, and also generated a few test clients. He also implemented the service in the "Smart Dataset-XML Viewer". So if the user hovers the mouse over a cell containing a LBTESTCD value, the web service is triggered, a request send to the server, and the received information about the test code is displayed as a tooltip:

Now, what are the consequences of this?

First of all, it means that we could get rid of the variable "LBTEST", as there is a 1:1 relationship between LBTESTCD and LBTEST and the web service takes care of retrieving the value of "LBTEST" anyway. So essentially we could remove the variable LBTEST from the "required" variables in the SDTM-IG, also meaning that our LB submission files will decrease in size by something like 10-20%. That is surely something the FDA will like.

But take it another step further and imagine that we could query SHARE using a web service asking for additional information about the "CHOL" test code, returning information like which are the "preferred standardize units", what the FDA regards as being the normal range, and much much more, and use that information in the viewer, like marking values the FDA regards as being "out of range". Also SHARE already "knows" that "CHOL" is a test in the category "chemistry" so that we also can get rid of LBCAT.

A review environment using web services like the one our student Wolfgang Hof developed and using SHARE, wouldn't this be a great step forward?

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.