CDISC Therapeutic Areas and LOINC

In a recent discussion with an important CDISC representative (well, they are all important), I heard the remark that the therapeutic area user guides (TAUGs) may be the perfect forum to introduce people to LOINC coding for lab tests. So I downloaded them all, and searched them for:

• whether LOINC is mentioned at all
• whether there are lab tests described which are / maybe important for the specific therapeutic area
• whether the important lab tests that are described come with their LOINC code
• whether example of LB domain tables have the LOINC code (in LBLOINC) included

So, let's go!

TAUG multiple sclerosis

•  mentioned that --LOINC variable is not to be used in domains NV and OE
• no lab tests described

TAUG virology

• LOINC mentioned many times as standard reference technology for tests in the domains VR, PR.
• Shows up in many of the example tables, for example PFTSTRCD=48005-3, PFTSTRNM=LOINC
• No specific laboratory tests described

TAUG Influenza

•  LOINC not mentioned at all
• A few lab tests are described (e.g. nucleic acid amplification techniques - NAAT) for which LOINC coding exists (e.g. 68987-7, 38270-5), but the LOINC codes are not provided

TAUG Cardiovascular Studies

•  LBLOINC field and values provided in all LB example tables
• Not further explained what LOINC is, supposed to be known by the users

TAUG Asthma

• LOINC not mentioned at all
•  Different lab tests extensively described (e.g. Leukotriene E4, Immunoglobulin E) but no LOINC codes provided, though they exist (e.g. 33344-3, 62621-8, ...)

TAUG Alzheimer (2.0)

•  Mentioned as standard technology for genomic tests (PFTCVNM, PFTTESTCV)
• No specific laboratory tests described

TAUG Diabetes

•  LOINC not mentioned at all
• A good amount of proposed lab tests is defined in detail, but no LOINC codes are given, although they exist for each of the described test

So, the use of LOINC seem to be very different: in some cases, LOINC is used all the way (even expected to be known by the user - cardiovascular), and in other cases, the authors of the TAUG seem even not to be aware of LOINC as a coding system for the exact identification of lab tests.

In the case of the TAUG diabetes, I added the LOINC codes myself to one of the tables describing a set of lab tests. It took me less than 10 minutes to do so (thanks WWW!). Here is the result:

Personally, I strongly believe that providing/suggesting LOINC codes for lab tests in a TAUG is a very good thing, as it can be copied into the protocol, so that the protocol writers / investigators / SDTM generators do not need to interprete / guess which test exactly must be done or was done.
 


 

The power of UCUM: unit conversions using web services

Yesterday, one of my smaller dreams came true.

Some years ago, when I started working with electronic health records (EHRs), I discovered UCUM, the "Unified Code for Units of Measure"  which is used for all quantitative data in them. So I started teaching UCUM to my students. UCUM also publishes an XML file, the "ucum-essence.xml" file, which in principle should allow to do automated unit conversions, as it allows to decompose each string that is in UCUM-notation into the base units (m,g,s,...).

So I found a student, Milos Ilic, who agreed to develop a Java programm for unit conversion with a nice graphical user interface, as part of his Bachelor thesis. He succeeded doing so (well done!) - here is a snapshot of his application:

It allows the user to select a property (pressure in this case), and then allows to select a source unit plus a prefix for it (cm water column in this case) and a target unit plus a prefix (mm mercury column in this case), and then do the unit conversion.
Just to be clear, the application does not use a conversion table, it decomposes both cm[H2O] and mm[Hg] into its base units (m,g,s) allowing to generate the conversion factor "on the fly".

But this was just a first step, as the Java application (though excellenly made) still has a number of disadvantages:

• it requires a human to use it
• you can't call it from within your own application e.g. saying "please let me know how many mm mercury column 100 cm water column is"
• it does not support more complex, composite UCUM strings like "mm[Hg]/min pressure decrease"
• it does not support annotations, like in mmol{creatinine}/ml

So a "web service" was due.

And yesterday, I finally could finalize writing (and especially testing) the code. The service is a RESTful web service, allowing any modern computer application to ask the service questions like: "please let me know how much 0.25 pounds per square inch per minute" is in "millimeter mercury per hour". Here is the result when displayed in a browser:

You can find all the details about the web service at:
http://xml4pharmaserver.com/WebServices/UCUM_webservices.html

So how could this web service be used in healthcare and in clinical research? Here are a few possibilities:

• allow EHR implementations to do unit conversions automatically
• if CDISC would allow / mandate UCUM units (it only very partially does so for lab units), automate the process of converting original results (--ORRES) to standardized units (--STRESN)
• allow the FDA tools to validate whether a conversion between original result and standardized has been done correctly
• allow the FDA to compare lab results across studies and sponsors (they can't right know) - another requirement for this is that they use LOINC for lab test codes
• and much much more

The web service is not perfect yet, there still are a small number of limitations which we are working on.
But I do encourage you to at least use this web service in your pilot applications!

ValueList Web Services in the "Smart Dataset-XML Viewer"

I now also implemented these services into the "Smart Dataset-XML Viewer". I still need to QC it and will then make the new version available through SourceForge.

Here is a snapshot of a VS dataset. It validates with no errors nor warnings in OpenCDISC (2.0).

 See something special?

Now I let the "Smart Dataset-XML Viewer" validate the data using the following web services:

• check whether a CDISC unit is a correct unit for a given (VS) test code
  (http://www.xml4pharmaserver.com:8080/CDISCCTService/rest/ValidCDISCUnitForCDISCTestCode/{testcode}/{cdiscunit} )
• check whether a Vital signs "position" (VSPOS) is a correct "position" for a given (VS) test code
  (http://www.xml4pharmaserver.com:8080/CDISCCTService/rest/ValidPositionForCDISCTestCode/{testcode}/{position} )

Here is the result:

 The "Smart Dataset-XML Viewer" finds the following problems:

•  mm[Hg] is not a valid unit for VSTESTCD=SYSBP (second row)
  (remark that this data point came from an EHR, where UCUM notation is mandatory, but CDISC still does not allow UCUM...)
• cm is not a valid unit for VSSTRESU with VSTESTCD=SYSBP (same row)
• cm is not a valid unit for VSORRESU with VSTESTCD=SYSBP
  obviously a data management error (although a mapping error cannot be excluded)
• SITTING is not a valid VSPOS ("position") with VSTESTCD=HEIGHT

Once again, this dataset passed without errors/warnings through OpenCDISC.
The reason is that the latter does not implement this kind of plausibility rules. It e.g. just checks whether "cm" is a valid member of the [UNIT] codelist (which it is). But of course it is not applicable to a blood pressure.

Now, one could implement such plausibility rules in software (hardcode it as OpenCDISC mostly does for other rules), but why do that (with zero transparency) when a web service is available?

I must explicitely thank Anthony Chow (CDISC) who published these rules in the form of an Excel worksheet (see "CT Mapping/Alignment Across CodeLists" at the CDISC-CT website).
All I did was move this information into a database and write the RESTful web service for it.

This kind of functionality is exactly what CDISC users want to see in SHARE. My implementation is just a prototype of "proof of concept", and of course I am talking with CDISC about how this kind of web services can be provided by the real SHARE.

ValueList web services for SDTM

Today, I added three more web services, which have to do with SDTM value lists:

• Validate whether a CDISC unit is a correct unit for a given (VS) test code
• Validate whether a Vital signs "position" (VSPOS) is a correct "position" for a given (VS) test code
• Validate whether a Character Result/Finding in Standard Format text value (EGSTRESC) for a given ECG Test code (EGTESTCD) is a valid value

These web services are based on the excellent work of Anthony Chow (CDISC), who published these lists (as Excel) on the CDISC website under "CT Mapping/Alignment Across CodeLists". 
All I did is generate a relational database from these lists, and then writing the new web services using RESTful technology.

For example, when you submit:
http://www.xml4pharmaserver.com:8080/CDISCCTService/rest/isValidCDISCUnitForCDISCTestCode/DIABP/mmHg
meaning "validate whether 'mmHg' is a valid CDISC unit for the vital signs test 'DIABP') to the web service, the string "true" is returned, but  when you however submit http://www.xml4pharmaserver.com:8080/CDISCCTService/rest/isValidCDISCUnitForCDISCTestCode/HR/mmHg,
the string "false" will be returned.

This is not "rocket science" at all - it took me one evening to create and add the tables to an existing relational database, and about 3 hours to develop, test, and roll out the web services (and write this blog ...).

This is just a first simple example of what is possible, one can easily do similar things for more or even extremely complicated domains such as the LB domain (laboratory) - however in my opinion, we should have a complete rewrite of the LB domain, and use LOINC for the tests, and UCUM for the units.

The complete list (for the new ones, look near the bottom) of the available web services can be found at:
http://www.xml4pharmaserver.com/WebServices/index.html

Are these the kind of web services you would like to see implemented with SHARE? Please let me (and CDISC) know ... 

More web services

In the last weeks and months, with help of my students at the university, I developed some more web services for use with CDISC standards, especially for use with SDTM and CDISC controlled terminology. Almost all of these have been implemented in the "Smart Dataset-XML Viewer".
I got very enthusiastic reactions about these web services, especially during a demo for CDISC officials, for the Japanes CDISC User Group (CJUG) and yesterday during a "Dataset-XML CDISC Training" in Copenhagen, Denmark. As I could also nicely test the services during the last weeks, and found no major issues, I decided today to make the specification of these web services publicly available. You can find them at:

http://xml4pharmaserver.com/WebServices/index.html

These are all RESTful web services, so extremely easy to implement in your own applications, and as RESTful services are based on HTTP, you can even test them in a browser.

Suggestions for new services and for improvements are as always very welcome. Please just contact me at info@xml4pharma.com.

Bringing SUPPQUALs back to their parent dataset

In CDISC SDTM, values for non-standard variables (i.e. sponsor-defined variables) need to be submitted in separate data sets, the so-called "supplemental qualifier" or "SUPPQUAL" data sets.
So for example, if you have a variable "ENDPOINT" in your lab data, you do not submit these in your LB data set, you submit them in a SUPPLB data set.
The reason for this is an historical one: in the past, there was no way to "mark" non-standard variables in the data sets, as these needed to be provided in SAS Transport 5 format. You could of course mark them as such in the define.xml file, but as the define.xml format and the SAS Transport 5 format are pretty incompable, tools like the SASViewer could not elaborate this meta-information. So you could indeed put values for non-standard variables in the parent data set, but the viewer would not e.g. color them differently, unless of course you wrote a special viewer. No one however wanted to invest in such a venture, for understandable reasons.

Everything changed when the Dataset-XML format was published. It replaces SAS Transport 5 and is based on as well CDISC ODM, as define.xml, and perfectly aligns with the latter. So you can now just put the values of non-standard variables (like the "ENDPOINT" variable in our case) in the normal data set, and just tell that this is a non-standard variable in the define.xml. As Dataset-XML and define.xml perfectly work together, tools extract the metadata from the define.xml and apply this to the variable values when loading the values themselves from the Dataset-XML files.

This allows to e.g. do data validation during loading, like checking whether the to-be-loaded value is of the right data type, whether it obeys to its associated codelist, and so one (I could write several pages about this ...).

For non-standard  variables, if you add 'Role="SUPPLEMENTAL QUALIFIER"' to your non-standard variable's ItemRef, then the system knows that this is a non-standard variable and can e.g. color it differently in the viewer. That is how we implemented it in the "Smart Dataset-XML Viewer".

Now, keeping the non-standard variable in the parent data set instead of "banning them" to a SUPPQUAL data set is not yet allowed by SDTM. This might change once the FDA starts accepting Dataset-XML as an exchange format.
Currently, the FDA is piloting the use of Dataset-XML, but still wanted the participants of the pilot to submit their data in almost exactly the same way as when using SAS Transport 5, i.e. with non-standard variables in SUPPQUAL datasets, which I think is a lost opportunity.

So I was looking into a way to bring non-standard variables back to their parent data set during loading in the "Smart Dataset-XML Viewer". When you have a SUPPLB however with 65,000 records, this would not be easy (i.e. it would be time consuming), as for each SUPPLB record, you need to find the parent record in the parent LB data set, which itself also has over 60,000 records. So I started thinking about a "smart" solution.
This weekend I found it. I observed that in most SDTM datasets, the records are more or less ordered by USUBJID. So if you first do a quick scan over all the records of the LB data set, and for each unique USUBJID keep the first and last occurrence row number, and keep this information in an "hashmap", you later only need to search for the parent record within this limited range.
To my surprise, generating the hashmap only took 25 milliseconds, although the 60,000 records need to be scanned. Merging the non-standard variable values back into their parent data set then became very efficient, a speed increase by a factor of over 20 was observed. As such, it took less than 2.5 minutes to merge the 65,000 SUPPLB records back into the 60,000 LB records. Here is a screenshot:

The variables "ENDPOINT" and "LBTMSHI" are the non-standard ones, and although they were loaded from the SUPPLB data set, they nicely show up in the LB table (I moved the columns to the left for better visibility).

The "trick" that made this possible was essentially creating sort of an index on USUBJID.

So I wonder whether the reviewers at the FDA create indexes on their (SAS?) tables in their review systems to be able to easily combine information from different tables. Do they?

P.S. I will release this new version of the "Smart Dataset-XML Viewer" on Sourceforge in the next few days. In that release, "bringing back SUPPQUAL data to their original data set" will be an optional feature (it still takes extra time). So you will have a checkbox for switching the feature on or off (default is off):

It would be great if someone would then try out this new feature on data sets that have millions of records, and then report back to me!

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.