SDTM --ORRESU and controlled terminology

A very interesting discussion (partially by e-mail, partially on the web) has been taken place in the last weeks on the question on whether --ORRESU ("Original Units") must be under control of terminology or not.

The question arose from another discussion on why there is a CDISC codelist for units, although there is already an international standard for that (UCUM), which is well used by the hospital world, and for which the use is mandatory in exchange standards for electronic health records (EHRs) such as HL7-CCD and CDA and ISO-21090.
As I was informed by someone from the FDA, the use of UCUM is also mandatory in SPL (Structured Product Labeling).

The discussion was also triggered by the observation that when one extracts lab data from EHRs and use that in clinical research and it leads to an SDTM submission, the value in LBORRESU in some cases leads to a validation error when using OpenCDISC. A typical example is "mm[Hg]" which is the international symbol (UCUM) for "millimiter mercury" as a unit for the property "pressure". OpenCDISC throws an error as "mm[Hg]" is not in the "UNIT" controlled terminology codelist.
Other people remarked that when using paper case report forms, the way the unit is written on the CRF varies very often (when not preprinted). For example, for a mass concentration, they found it written as "Gr/dl", "Gramm per deciliter", "Gramm/dL", "g/dL" etc.. Only the latter is correct CDISC controlled terminology.
So if I find "Gramm per deciliter" on the CRF, what must go into LBORRESU?
The SDTM-IG for LBORRESU states "original units" for the variable label, but the column "Controlled Terms, CodeList or format" states "(UNIT)", meaning that the value must come from the "UNIT" codelist.
Whether this codelist is extensible (by the sponsor) is not mentioned in the SDTM-IG.
In my opinion, the wording "original units" contradicts with the statement that the "UNIT" codelist must be used.
Only in an ideal world, every researcher would exactly use what is in the CDISC "UNIT" codelist when writing (as narrative text) the unit on the paper CRF.

A response came from a distinguished SDTM pioneer stating that one needs to distinguish between the "actual unit" that came from the CRF, and the way it is represented in SDTM, and which needs to come from the UNIT codelist.
So that would mean that if the researcher had written "mill.Hg" on the CRF, this would never appear in VSORRESU, but needs to be "translated" into "mmHg".
Similarly, when the data comes from an EHR, the UCUM unit "mm[Hg]" will never go into VSORRESU but needs to be translated into "mmHg" again.

If we do so, how much is ORRESU then still "original unit"? Isn't such a translation a "derivation"?
What about "translation errors"? Can we trust that the unit is always translated correctly into one from the UNIT codelist? I (and a lot of other in the discussion) have some serious doubts.

What about tests for which there is a unit available, but for which there is no unit present yet in the UNIT codelist for that property? Do we need to wait submitting to the FDA until the moment that our "new term request" is approved?
And isn't it a bit strange that CDISC just choose to ignore/exclude a standard (UCUM) that is very well used, and choose to develop its own list for units? One statement in the discussion was that UCUM is not well known in smaller labs and by a number of LIMS systems, but is that a reason to develop a whole new list, and then to say that the labs and LIMS should learn that new list, instead of stating that they should learn UCUM? It reminds me about the cartoon that you can find at http://xkcd.com/927/.

One very good suggestion was given by a representative of a biotech company, proposing to have two variables for the "original" units, one named e.g. --RPRESU (new), the "reported result unit" which is "as collected", so not under controlled terminology, and --ORRESU (existing), which is the translation into something that is in the "UNIT" codelist. As such, the "as collected" unit would not be lost, and the reviewer at the FDA can use the (--ORRESU) term that is under CDISC controlled terminology because that is familiar to him/here.

So, when the information comes from an EHR, e.g. "mm[Hg]" (UCUM) would go into VSRPRESU and would then be "translated" into "mmHg" (CDISC-CT) which then goes into VSORRESU.
Which of the two (if not both) would then be made "expected" is also an interesting discussion.

Though this doesn't take away my objections agains "the reinvention of the wheel", I think it could be a very good compromise.

Whether derived variables should go into SDTM at all is another discussion. For example, we must submit "AGE" in the demographics domain although that is usually never collected, but derived from BRTHDTH (birth date) and RFSTDTC (reference start date). Whether such derived variables should be in SDTM is surely related to the question "Is SDTM a database (design), and if so - is it a good one?" which I discussed in a previous blog entry.
My next blog entry will probably go about why SDTM has more and more derived variables.

Another copy-and-paste frustration

Yesterday and today, I worked on implementing the new SDTM oncology and a number of the new draft SDTM-IG 3.1.4 domains in my SDTM-ELT(TM) software. For each new domain, I created a template define.xml file that can be read by the software.

It was so frustrating!

The new domains come as a PDF file with tables and additional information. During creation of the templates I continously needed to switch between the PDF and between the (smart) XML editor I am using. I needed to copy the variable name, role and datatype and then paste it into the template. I then also needed to add whether the variable is mandatory (required/expected) or not (permissible).

The validation whether everything was correctly implemented was purely visual, comparing a view of the machine-readable template with the tables in the PDF file. Another frustrating task...

In earlier days, the SDTM team also published these tables in an Excel file. Although not a vendor-neutral format, this Excel file at least allowed to automate some things. The way I proceeded was as follows:
First I read the Excel file into OpenOffice Calc (a competitor of Excel). Then I exported the tables as an OpenOffice "odf" file, which is essentially a zip file containing a set of XML files. After renaming and unzipping, one needs to take one of these XML files, and transform it to CDISC define.xml using a stylesheet.
Although each new publication of the SDTM team had differently formatted Excel files, meaning that I needed to adapt the stylesheet to transform to define.xml each time, it was a very good way, and I could generate the templates in a few hours.

The CDISC SDTM team does not publish their tables in a machine-readable format anymore. I do not know why, because I cannot imagine that the team is not using any computer tools to help in generating the tables. So why not publish them in a machine-readable format?

SDTM table definitions in a machine-readable format - that would be cool!

SDTM Supplemental Qualifiers

From the document "Proposal for Alternate Handling of Supplemental Qualifiers" of the CDISC SDTM Team:
"The vision at the time the Supplemental Qualifiers structure was created was that standard review tools used at the FDA would automatically display the Non-Standard-Variables (NSVs) together with the parent data in tabular views. The reality, however, is the representation of NSVs in separate SUPP-- datasets has resulted in increased effort by reviewers to prepare for and perform reviews of SDTM datasets.
The end result is that a data structure that was created to provide a standard method for representing NSVs has not been the best structure for the viewing and analysis of SDTM data by FDA reviewers. This document describes a proposed method by which NSVs and standard variables could be represented together in the parent datasets".

Or in other words: FDA reviewers are uncapable of merging/combining datasets (tables) so that the non-standard variables appear in their original table!

Oh my God: even my undergraduate students would be able to do that!

But why haven't the non-standard-variables not always be kept in their original table? Because they would then not be distinguishable from the standard variables? Yes, it is true that SAS Transport 5 does not have the capability of keeping metadata so that standard-variables and non-standard-variables can be distinguished, except for by naming conventions.

Wait a minute!
Metadata belong in the define.xml isn't it?
So why not just state in the define.xml that a variable is a non-standard variable? For example, suppose we have a non-standard variable "QSLANG" ("Question Language") in the QS (Questionnaires) domain. In the current SDTM implementation it is "banned" to the SUPPQS dataset.

We just keep that variable in the QS dataset and write in the define.xml:

<ItemGroupDef OID="QS" Name="QS" ... def:Label="Questionnaires" ...>
    <ItemRef ItemOID="STUDYID" Mandatory="Yes" OrderNumber="1"/>
    <ItemRef ItemOID="DOMAIN" Mandatory="Yes" OrderNumber="2"/>
    <ItemRef ItemOID="USUBJID" OrderNumber="3"/>
    ....
    <ItemRef ItemOID="QS.QSLANG" OrderNumber=".." def:IsNonStandardVariable="Yes"/>
</ItemGroupDef>

and of course define the corresponding ItemDef with OID "QS.QSLANG":
<ItemDef OID="QS.QSLANG" Name="QSLANG" def:Label="Question Language" DataType="text" Length="2"/>

DONE!

Does this help the reviewer in distinguishing between standard variables and non-standard variables?
Of course not very much. The FDA reviewers usually print out the define.xml (using the stylesheet view) and then inspect the XPT datasets in parallel. Not very modern isn't it?
The simple reason is that the viewer cannot read define.xml files.

Suppose however that the datasets do not come as XPT files, but as CDISC ODM (XML) files.
In CDISC ODM there is always a strong relation between the variable definition (ItemDef) and the data value (ItemData) over the OID. So for example, we would have (extending the above example):

<ItemDef OID="QS.QSLANG" Name="QSLANG" def:Label="Question Language" DataType="text" Length="2"/>

and the value:
<ItemGroupData ItemGroupOID="QS">
    <ItemData ItemOID="STUDYID" Value="STUDYX"/>
    <ItemData ItemOID="DOMAIN" Value="QS"/>
    <ItemData ItemOID="USUBJID" Value="P0001"/>
    ...
    <ItemData ItemOID="QS.QSLANG" Value="en"/>
</ItemGroupData>

This allows us to create software that tabulates the data and e.g. colors it depending whether it is a standard variable or a non-standard variable. This is very easy. It even can be done using an XSLT stylesheet when one wants to display the data in a browser.

It even creates new opportunities, such as:
- the software/stylesheet can easily validate the data, and e.g. color cells in the table (with an additional tooltip) for which there is an SDTM rule violation. For example an empty "QSREASND" can be colored red when the value of "QSSTAT" is "NOT DONE", this as the rule is that QSREASND may not be empty when QSSTAT is populated.
- In the LB (Laboratory) domain, values of "LBSTRESN" can be colored when the value is outside the reference range, i.e. lower than the value from LBSTNRLO or higher than the value of LBSTNRHI.
- rows that contain baseline data (--BLFL=Y) are colored differently
- data is sorted based on more than one criteria

All this is currently NOT possible using the SAS XPT Viewer, because it cannot read the define.xml containing the metadata.

There are much more opportunities: the number of them is only limited by your creativity.

Once we know how the future(?) ODM-based XML format for SDTM (and SEND and ADaM) data will look like, we will pilot such software and demonstrate it.
So ... keep tuned!

SDTM databases and the FDA

Two days again, my (first year) bachelor students had their "Introduction to Databases" exam.

When looking for a good question on "CREATE VIEW" (or joins in general) I was thinking again about SDTM and whether it is suitable as a database. After all, the FDA has done several attempts to create an SDTM datawarehouse, and as everyone having some database skills knows, you cannot (or almost not) create a datawarehouse without having one or more databases.

So I came to the following exercise:

"Given the following tables:

write an SQL statement to generate the following result table:"

and then I gave them a picture of the result SDTM table for the Laboratory "LB" domain.

(P.S. a correct answer is: "
CREATE VIEW Laboratory AS
SELECT t.STUDYID, t.DOMAIN, t.USUBJID, t.LBSEQ, t.LBREFID, t.LBTESTCD, tc.LBTEST, tc.LBCAT, v.VISITNUM, v.VISIT, v.VISITDY FROM Laboratory_test t, Testcode tc, Visit v WHERE t.LBTESTCD = tc.LBTESTCD AND t.VISITNUM = v.VISITNUM; "  )

This brought me to the following thoughts: "if we submit our SDTM datasets as essentially being a "View" on an SDTM database (see a previous contribution), how can the FDA reconstruct a database from this?"

After all, they want to use this kind of data in a datawarehouse, so they need to start from databases. If they would like to reconstruct the database from the (sas transport) tables, they do need to split the "view" (e.g. the LB sas dataset) into 3 or more tables.
Or can one start from the "view" to populate a datawarehouse?

Splitting up a "view" table into 3 (or more) tables so that the first, second and third normal forms are obeyed, and doing this in an automated way, does not look to be very simple to me.
Just suppose that there is one inconsistency in the "view" (sas dataset) e.g. that for the same LBTESTCD (e.g. "BILI") there is more than one corresponding value for LBTEST (e.g. once "Bilirubin" and one "Billirubin"). What would then happen?

But we do not know whether the FDA really tries to reconstruct the original database, or that it just uses the SDTM (sas) tables "as is".

Any comments (especially from FDA people) are of course very welcome.

Some comments on the "Pink sheet" article

The pink sheet, a well-known online journal on regulatory, legislative, legal and business developments, published an article on October 23 titled "FDA Data-Standards Landslide: "CDISC’s Model Wins Docket Comment Contest".

Here are some of the highlights followed by my personal comments (which are not necessarily those of the CDISC XML Technology Team - IMPORTANT):

"... Therefore, the agency wishes to replace it with an open set of standards “that will support interoperability,” and FDA asked for comments  on CDISC/ODM versus a competing set of standards from Health Level 7."

The question here is whether the ancient SAS-XPT transport format currently used for electronic SDTM, SEND and ADaM submissions should be replaced by either a CDISC ODM based format or by an HL7-v3 based one (probably CDA-similar, or a totally new HL7 XML-based format). Please remark that the discussion is about a transport format, i.e. the SDTM standard itself would not necessarily need to change. Or in other words, the SDTM domains and variables would remain the same, it is just the way they are formatted and transported (the transport format) that would change.

"Pharma and bio industry majors, including Novo Nordisk AS, Novartis AG,Sanofi,Amgen Inc.,Merck Sharp & Dohme Ltd., Astellas Pharma US Inc., BioClinica andBiogen Idec Inc., lined up behind CDISC."

That is of course good to hear. Sponsor companies in the past did not matter too much about transport formats, they just concentrated on semantic standards like the SDTM standard. But they did realize that the XPT format was a "dead end", with very many disadvantages leading to a lot of problems. They now do also realize that CDISC ODM maybe an excellent modern replacement, and that HL7-v3 is not a suitable format for submissions to the FDA (see e.g. my article "Ten good reasons why an HL7-XML message is not always the best solution as a format for a CDISC standard (and especially not for submission data").

"Amgen’s comments  were typical of the tenor of the support: “CDISC ODM is already well integrated into clinical data systems and there is a broad knowledge of this standard within the BioPharma industry already. It supports both metadata and data exchange, was developed for the exchange of clinical research data and is 21 CFR Part 11 compliant.

However, the company added, it will be necessary to anticipate and deal with variations in interpretation by different industry users of the standard and between sponsors and FDA, as well as “handling multiple versions within and across submissions for the same compound.”

 

The latter is of course correct. We will need to extend the ODM standard or develop an extension for it (as we did for define.xml) and we will need to publish an implementation guide. We will also develop an ISO-Schematron to clearly define most of the business rules such as the rules for the use of --STAT and --REASND. So we will not allow that there are different interpretations and "dialects" of the standard.

 

"Novartis' comments  argued that 'given that CDISC ODM is kept closer in synch with the CDISC standards themselves and the industry has been watching and moving towards being able to provide CDISC SDTM [CDISC’s Study Data Tabulation Model]-compliant submissions, it would seem to make sense that using CDISC ODM as an exchange standard makes more sense than any other'. Novartis added that work remains to be done on ODM to bring it into compliance with the widespread pharma industry use of relational technology for data storage and analysis, as well as on ODM’s extensions."

 

Of course, we also realize that work still needs to be done on ODM. Some of us are already inventorizing what should be done better in a next version of ODM, or what should be added. For example, we need even more support for data points coming from electronic health records (see some of my articles in another blog), this although ODM does already have such support through its extension mechanism.

 

"Merck’s backing of ODM was more conditional. The company said it currently uses ODM for third-party data but prefers to keep using SAS version 9 or an ASCII file format “because the ODM is ‘performance heavy,’ meaning that it slows system performance.” Therefore, Merck’s comments  suggested FDA use the “Define.XML” subset of ODM, although elsewhere in its comments it cautioned against using XML (extensible markup language) itself as a submission standard, since translating all study data into this format would be time-consuming and overly demanding of FDA system resources."

 

The remark that ODM is "performance heavy" is not entirely true. I admit that this was the case 5-10 years ago, but since then, XML parsing software and libraries have evolved enormously and show much much better performance. My own observation is that reading and displaying a very large SDTM dataset in XML (given well written software) is as performant as with the SASViewer for XPT files.
Furthermore, some new technologies such as VTD-XML allow to minimize the memory usage when parsing very large XML files, such that files that have a disk size up to about 50% of the memory size can still be parsed and displayed.
Also here, my own experience is that for the same content, XML files with their tags do not have to be larger than SAS-XPT files, as the latter wastes a lot of disk space due to the fix-length records.

 

Merck's comment on the use of define.xml builds further on this. My answer is that of course the new ODM-based format for electronic submissions will be based on define.xml!
Just as for collected data the ODM element "MetaDataVersion" contains the metadata and the element "ClinicalData" contains the actual data (and which have to match each other), the new format (although very little will be really new) will have the define.xml for the metadata and another (maybe  new element) will contain the actual submission domain data (and which have to match the metadata in the define.xml).

 

"Commenters also pointed out that clinical trials typically last so long that the data standards may change while the study is under way, creating a big problem for sponsors; that data standard disharmony creates problems for “secondary data re-use” in future studies; and that therapeutic area data standards are desperately needed".

 

The ODM team has always been very keen on taking care that ODM is "downwards compatible", i.e. that a valid ODM file of an earlier version is (except for the namespace usage) also a valid ODM file in the new versions. When we do deprecate an element or attribute, we always further support it for two intermediate versions. This is in huge contrast with HL7, where versions 2 and 3 of the standard are totally incompatible (0% reuse possible).

And even then. E.g. for define.xml we will provide an XSLT transformation stylesheet that transforms define.xml v.1.0 files into define.xml v.2.0 files.

 

"Several commenters noted that there is a need for international harmonization of clinical data standards, a fact highlighted even by groups that oppose CDISC/ODM. The Vereniging EN13606 Consortium, a Dutch group that backs a European communication standard called ISO 13606 EHR, and a group at Oxford University that backs other international standards development initiatives both called for better harmonization."

 

As I already showed in a previous contribution, it is now already possible to include data points from electronic health records (EHRs) in ODM. In that blog contribution, I demonstrated how that can be done for data points from CDA EHRs, but the same is equally true for data points coming from EN13606-based EHRs (such as OpenEHR).

The commenters are right about international harmonization, but what they point to is essentially the "EHR standards war" between HL7 on one side and OpenEHR/ISO13606 on the other side.
It should not be the task to CDISC to solve this conflict, but our submission standard should be able to support both, which it does already do now.

 

Your comments are as always highly appreciated.

Define.xml draft 2.0 is out

The long-awaited version 2.0 of the define.xml standard has now been published for public review by CDISC. It can be downloaded from the CDISC website at: http://www.cdisc.org/define-xml. If you are interested in define.xml, please download the distribution, review it and send your comments not later than October 1st. There is a separate file in the distribution explaining how to submit your comments.

Version 2.0 (draft) is based on the latest version of the ODM standard (v.1.3.1) taking away many of the limitations of v.1.0 of define.xml.
I am currently writing up my comments (good and bad) and already have more than 10 pages. The overall impression is however good - I think we are again taking a major step forward.

Some things I liked especially in the draft v.2.0:

- the "WhereClause" allows to define which units of measurement and categories (--CAT variables) for which cases (based on ValueLists e.g. for --ORRES).
- the "MethodOID" - "MethodDef" pair allows much better to add mapping information.

Things I did not like:

- "MeasurementRef" - "MeasurementDef" pairs are not supported. They are regarded as extensions to the standard. This is a bit stupid, as it breaks "end-to-end" processing. Instead the "WhereClause" needs to be used, which means an extra processing step.
The "WhereClause" is more general and is also applicable to other variables (such as --CAT). The problem however is not a define.xml or ODM problem, it is an SDTM problem!
Stupidly enough, variable qualifiers such as --ORRESU have been defined in SDTM as extra variables, i.e. extra columns in the SDTM table, instead of defining them as attributes (so a third dimension) to the parent variable (--ORRES). The consequence is that there is no way in SDTM to check whether the pair --ORRES / --ORRESU really matches and makes sense. The same applies to the --TESTCD (test code) / --TEST (test name) pair (also see my previous post)
Had ODM been used for transporting SDTM data, then everything would have been much more simple.
So the current "WhereClause" mechanism must be regarded as the best possible solution for supplying metadata to variables of a badly designed SDTM.

- "SASFormatName" is mandatory for CodeLists. Why? "SASFormatName" is not vendor-neutral! My personal opinion is that such an attribute should go into a "vendor" extension. However, it is traditionally already in ODM for a long time (SAS is a market leader in our industry). The fact that it has been made mandatory in define.xml 2.0 draft seems to have to do with that FDA reviewers want to have the ability to automatically create SAS tables for codelists. But why can't FDA reviewers assign SAS format names for codelists if they want to?

Things I suggest for improvement:

- explicitely allow "FormalExpression" as child of "MethodDef". The draft define.xml allows to add a reference to an external file with the calculation or imputation (source) code. However, it makes much more sense to allow to have the code within the define.xml itself. ODM 1.3.1 has an excellent, existing mechanism for that: FormalExpression.

Is SDTM a database (design), and if so - is it a good one?

SDTM 1.3 and SDTM-IG 3.1.3 have just been publised. A good time to review and discuss what SDTM iin fact is. SDTM consists of related tables, so is it a database (design)?

At the university I am teaching databases and database design, so I do have some authority to make an analysis from a theoretical point of view.

Let us take a typical table from the SDTM: the Vital Signs table. A snapshot view is shown below.

First of all the keys: the combination of STUDYID, USUBJID, VSSEQ can be defined as the primary key. Although the latter is an artificial key, usually generated in the very last stage of the generation of the table.
USUBJID is certainly a foreign key to USUBJID in the DM table, and VISIT a foreign key to the TV (Trial Visits) table. Or is VISITNUM the foreign key to the TV table?
Here is where the problems start ...

In our first database course (second semestor bachelor) we teach the students about the first, second and third "normal forms" (usually abbreviated as NF). A good database design is in the third NF. A bad database design in the second NF, and a very bad database design in the first NF. A database that doesn't obey the first NF is not worth the designation "database".
The difference between a database design in the third NF and one in the second NF is that the former does not have any "transitive dependencies" anymore. A transitive dependency is an A -> B -> C dependency. Let me explain a bit.
Suppose a table with customer number (primary key), first and family name, postal code (zip code) and city.
When I do know the customer number, I do immediately know his first and family name by a simple lookup (that is what we call a dependency). I do also know his postal code. So we have two dependencies:
CUSTOMERNUMBER -> FIRSTNAME,FAMILYNAME and
CUSTOMER -> POSTALCODE

There is however still another dependency which is not on the primary key, i.e.
POSTALCODE -> CITY
as if I do know the postal (zip) code, I do automatically know the name of the city.
So we have:
CUSTOMER -> POSTALCODE -> CITY
This is what is exactly meant with a "transitive dependency", and the third NF states that these should be avoided.

Why?

Let us take an example again: I have a customer John Smith with customer number 12345 with zip code 10001, living in Manhatten, New York, all in the same table. Everything OK.
I now add a new customer (I do an insert into the database table) with customer number 23456 with name Mary Poppins, and postal code 10001 (again) and city Chicago. Agree?
Most of you will immediately protest, as the postal code 10001 does not belong to Chicago! It belongs to Manhatten, New York!
However, a database management system will approve such an insert as it has no way of knowing that there is a relationship between postal code 10001 and Manhatten. If I do know "10001" I do immediately know that the customer is living in Manhatten (remark here that I assume that this is a database of customers living in the USA only).

So, what does the theory of the third NF learn us to do in such a case? It learns us that we should split the table into two tables: The "customer" table will contain the postal (zip) code along with some other information (but not the city), and the postal code should be a foreign key to another table which contains the postal codes and their corresponding cities. When adding a new customer, it is then not possible anymore to create an invalid postal code / city pair, which increases the probability of keeping a consistent database.

Let us know return to our SDTM VS table. Obviously it is a hypervertical table (more or less according to the so-called Entity-Attribute-Value (or EAV) model). Does it obey to the third NF? Or does it have transitive dependencies? Let us have a look.

We immediately see that there is a 1:1 relationship between VSTESTCD and VSTEST: if I do know the value of VSTESTCD, then the value of VSTEST is fixed. For example, when VSTESTCD has the value "SYSBP", the value of "VSTEST" MUST be "Systolic Blood Pressure". It cannot be e.g. "Hearth Rate".
If I do have such a case (combination of VSTESTCD=SYSBP and VSTEST=Hearth Rate) tools like OpenCDISC will give me an error. If I build up a database with such a discrepancy however, the database management system will not protest at all.

The same is true for VISITNUM and VISIT in the VS table. They are dependent on each other: if VISITNUM is given, VISIT is fixed, and vice versa.
If I generate a database and do an insert into the VS table with a value of "1" for VISITNUM and "Visit 1" for VISIT, and then do (for example for another subject) an insert with "1" and "Visit 7", the database management system will not protest at all as it cannot know that there is this 1:1 relationship.

So: SDTM cannot be considered as a good database design, as it does not obey the third NF!

So what is SDTM? Why did the designers of SDTM allow that VSTESTCD and VSTEST have a dependency but are in the same table, and that VISITNUM and VISIT are columns in the same table although that violates the rule of the third NF?

The reason is simple: because the reviewers wanted this so.
A reviewer wants to see VSTESTCD and VSTEST at the same time because he/she maybe doesn't know that "HR" means "Hearth Rate". You might think this is a stupid argument, but think about the LB domain with its large numbers of test codes: a reviewer cannot know them all.
So, essentially, SDTM is a VIEW on a database, as we would implement it for end users that only have read access. For those not common with the concept of database views, here is a link to the Wikipedia entry.
So now you might ask: why don't we send the FDA the SDTM database (tables) that has a correct design (third NF - meaning minimal risk of inconsistencies) and then the FDA loads it into the data warehouse and then provides views on that to the reviewers. That would be ideal, wouldn't it?
The reason is that the FDA does not have a functioning SDTM data warehouse (there have been several attempts/versions of JASON but none of them were really of any use, and the project has now been outsourced to NCI), and that the reviewers use the SDTM tables "as is", i.e. just using the SAS viewing tools (SASViewer).
As far as I know, the received SDTM tables are never used to populate a reviewers database, and where there is no database, views can of course not be provided.

Conclusions: SDTM is not a database (design), it is a VIEW on a database. However, most people (including the FDA reviewers) use it as a database, and do not try to recover the (or a) database from the view.