The last two-three weeks were difficult ones for the CDISC end-to-end cause.
There was a lot of discussion within the volunteer team that is developing define.xml 2.0 whether elements like "MeasurementUnit" should be allowed in define.xml 2.0. The reason is that some of the team wanted to discourage (or even forbid) the use of "MeasurementUnit" in define.xml 1.0 and future 2.0 files, as "MeasurementUnit" is not explicitely stated in the define.xml specification. Others were of the opinion that "MeasurementUnit" has always been allowed in define.xml, as define.xml is an extension of the ODM standard. Also, several vendors of software for generating define.xml files do use "Measurement" as it is the most natural way to attach information about which units were used in which tests.
The discussion however has a deeper origin. The real question is whether define.xml is part of the chain in end-to-end (i.e. is the "last mile" to the FDA), or is just something totally different for which (unfortunately?) ODM was used (or abused?). Or as one participant stated "define.xml is another animal".
The discussions were heavy: some of the team were of the opinion that (as define.xml is totally something different) not a single element or attribute of the core ODM should be allowed in ODM if not explicitely mentioned in the define.xml spec (and also refusing to have "MeasurementUnit" in the new define.xml spec), others were of the opinion that define.xml is an important part in CDISC end-to-end, and that people should be allowed to provide additional information (such as MeasurementUnit, Question, RangeCheck etc.) to a define.xml and so to the FDA, supported by an appropriate stylesheet. This information would just come from the original protocol in ODM format without needing transformations.
At the moment that a "groaning teeth" compromise was in sight, allowing people to use define.xml either way ("strict" or "loose"), everything was questioned again by a member stating "a standard that has such compromises is not a standard".
So instead of coming to an end, the heavy discussions started again.
My personal opinion (which you may have guessed already) is that define.xml is an important link in the end-to-end chain, and using ODM elements and thus information coming from the original study design has a tremendous value.
I do not know how the discussion will further evolve. The best I think is that the compromise that was ultimately reached (but gives stomache aches to almost all of us) is implemented. If not, I am afraid that the discussions will go on, and a release of define.xml 2.0 is out-of-sight for several more months.
To better explain the (visionary? although already used by several vendors) idea of end-to-end (i.e. using one transport format from protocol design to submission to the FDA) I have decided, together with a few others, to start a new blog site, which you will soon find at http://cdisc-end-to-end.blogspot.com.
It will be open to anyone having a good heart for the CDISC end-to-end case.
Saturday, December 10, 2011
Saturday, December 3, 2011
A glimpse of hope
A few days, Becky Kush (president of CDISC) informed me that the FDA recently appointed a new CIO who has a track record of success in science in pharma industry.
I do not know Eric Perakslis personally, but I heard some very good things about him. Eric launched the TranSMART project at J&J, so he surely is a visionary IT guy.
The one million dollar question will be if he will really get the empowerment that is needed to structurally change something at the FDA, and bring their IT (which is currently in a desperate state - see the previous blog entry) on such a level that it can cope with the IT level on which the industry is acting.
Already more than a year ago at the Baltimore Interchange, I heard Theresa Mullin of the "Office of Planning and Informatics" (i.e. the CIO's department) telling us about all the plans she had for improving things at CDER. More than a year later still nothing seems to have changed: CDER does not have any servers, databases, good viewers, XML or database knowledge ...
The problem is that (which she told us herself) is that she cannot force any department to develop or implement something (advisory role only).
Will Eric Perakslis also be chained into such an "advisory role" as all his predecessors were? Or will he get the power, people and financial means to really change things? Will he be able to force departments like CDER to bring their IT into the 21st century?
I really hope so ...
I do not know Eric Perakslis personally, but I heard some very good things about him. Eric launched the TranSMART project at J&J, so he surely is a visionary IT guy.
The one million dollar question will be if he will really get the empowerment that is needed to structurally change something at the FDA, and bring their IT (which is currently in a desperate state - see the previous blog entry) on such a level that it can cope with the IT level on which the industry is acting.
Already more than a year ago at the Baltimore Interchange, I heard Theresa Mullin of the "Office of Planning and Informatics" (i.e. the CIO's department) telling us about all the plans she had for improving things at CDER. More than a year later still nothing seems to have changed: CDER does not have any servers, databases, good viewers, XML or database knowledge ...
The problem is that (which she told us herself) is that she cannot force any department to develop or implement something (advisory role only).
Will Eric Perakslis also be chained into such an "advisory role" as all his predecessors were? Or will he get the power, people and financial means to really change things? Will he be able to force departments like CDER to bring their IT into the 21st century?
I really hope so ...
Friday, November 18, 2011
The FDA and the "Standard Issues Document"
A week ago, I had a teleconf with a number of people of a department of the FDA regarding the "CDER Common Data Standard Issues Document".
The FDA itself had asked readers of the document to provide/send comments, so I did.
In my comments, I protested against (amongst others) the additional requirement that variables such as EPOCH, ELEMENT, ECTD must be added for each observation domain.
My comment was that this is ridiculous, as this information is already in the study design domains, and can easily be looked up easily e.g. though the visit number. A simple "table join" suffices.
In my classes on databases to undergradute (Bachelor) students, I learn them that redundant data in tables (of databases in this case) should always be avoided, as this easily leads to inconsistency (violation of the "ACID" properties).
With their additional requirements, the FDA is massively introducing redundant data in the SDTM tables, which I consider very bad practice.
But back to the teleconference: it was set up by the FDA represenatives to explain to me the "why" of these additional requirement. It looks as I am sufficiently influencial that they decided I should be talked to.
They explained to me that the reason for these additional (redundancy creating) requirements is that they do not have any mean of joining two tables. So they use the SDTM tables both for storage AND for presentation, as is. They do not load the tables into a database, as they haven't got one, nor the knowledge to create one, nor a server to put them on. They have SAS, but no people that can uses it. That is what they told me.
I was shocked!
Creating databases, populating them, and generating views of them (with joins) is something I learn my undergraduates, and which they pick up quickly, as it is not difficult.
But, the FDA people told me, they hope they will be able to do so in about 1-2 years.
They however appreciated my comments, and told me that they expect a lot of the new cooperation with Phuse, especially with the results of the (now yearly) "FDA/Phuse Computational Science Symposium". So they asked me to attend the next one (in Silverspring, March 2012). I objected that I live in Europe and so would need at least compensation for travel and accomodation, which they can't provide me. I can hardly imagine that the university provides me the necessary funds to attend that symposium. After all, as a professor I am expected to do innovative work, and not to teach the FDA how they can make a join or view on two tables.
So unless someone provides me the funding, I will not attend that symposium.
My personal opinion is that the FDA (i.e. the department I was speaking to) should first get things straight: start hiring people that can install databases, populate the latter with SDTM tables, and create views on them based on the requirements and requests of the reviewers, and make these available to them.
It is all a question of priorities: do I hire an extra reviewer or do I invest in IT (hardware, software and people)? Personally I am convinced that such investment would pay itself back in less than a year.
This teleconf has, unfortunatey, confirmed my feelings about the current state of IT at the FDA (at least as this department is concerned). It is even worse than I expected.
I was feeling very depressed after this teleconf: more than five years after the introduction of SDTM (and the commitment of the FDA was given), they are still not able to do anything with the datasets than just looking at them.
This is not very encouraging for the so many volunteers that have put so much time and effort in the development of the standards and formats, and makes me doubt whether we should put any more effort in projects such as define.xml 2.0, or in an XML format for SDTM submissions, this as long as the FDA is not able implement these within a reasonable period of time.
The FDA itself had asked readers of the document to provide/send comments, so I did.
In my comments, I protested against (amongst others) the additional requirement that variables such as EPOCH, ELEMENT, ECTD must be added for each observation domain.
My comment was that this is ridiculous, as this information is already in the study design domains, and can easily be looked up easily e.g. though the visit number. A simple "table join" suffices.
In my classes on databases to undergradute (Bachelor) students, I learn them that redundant data in tables (of databases in this case) should always be avoided, as this easily leads to inconsistency (violation of the "ACID" properties).
With their additional requirements, the FDA is massively introducing redundant data in the SDTM tables, which I consider very bad practice.
But back to the teleconference: it was set up by the FDA represenatives to explain to me the "why" of these additional requirement. It looks as I am sufficiently influencial that they decided I should be talked to.
They explained to me that the reason for these additional (redundancy creating) requirements is that they do not have any mean of joining two tables. So they use the SDTM tables both for storage AND for presentation, as is. They do not load the tables into a database, as they haven't got one, nor the knowledge to create one, nor a server to put them on. They have SAS, but no people that can uses it. That is what they told me.
I was shocked!
Creating databases, populating them, and generating views of them (with joins) is something I learn my undergraduates, and which they pick up quickly, as it is not difficult.
But, the FDA people told me, they hope they will be able to do so in about 1-2 years.
They however appreciated my comments, and told me that they expect a lot of the new cooperation with Phuse, especially with the results of the (now yearly) "FDA/Phuse Computational Science Symposium". So they asked me to attend the next one (in Silverspring, March 2012). I objected that I live in Europe and so would need at least compensation for travel and accomodation, which they can't provide me. I can hardly imagine that the university provides me the necessary funds to attend that symposium. After all, as a professor I am expected to do innovative work, and not to teach the FDA how they can make a join or view on two tables.
So unless someone provides me the funding, I will not attend that symposium.
My personal opinion is that the FDA (i.e. the department I was speaking to) should first get things straight: start hiring people that can install databases, populate the latter with SDTM tables, and create views on them based on the requirements and requests of the reviewers, and make these available to them.
It is all a question of priorities: do I hire an extra reviewer or do I invest in IT (hardware, software and people)? Personally I am convinced that such investment would pay itself back in less than a year.
This teleconf has, unfortunatey, confirmed my feelings about the current state of IT at the FDA (at least as this department is concerned). It is even worse than I expected.
I was feeling very depressed after this teleconf: more than five years after the introduction of SDTM (and the commitment of the FDA was given), they are still not able to do anything with the datasets than just looking at them.
This is not very encouraging for the so many volunteers that have put so much time and effort in the development of the standards and formats, and makes me doubt whether we should put any more effort in projects such as define.xml 2.0, or in an XML format for SDTM submissions, this as long as the FDA is not able implement these within a reasonable period of time.
Wednesday, November 9, 2011
A new challenge
I have recently obtained a professorship in "Medical Informatics and Documentation" at the eHealth department of the "University of Applied Sciences FH Joanneum" in Graz, Austria.
This will enable me to continue my work on the development of CDISC standards (and even being paid for it), but also to do exciting projects in the area of e-healthcare and its integration with clinical research.
My company XML4Pharma will also further exist in the future, but will concentrate more on software development (for CDISC implementation) and less on consultancy and training.
At the university, I am teaching "databases" and "medical informatics", the latter concentrating especially on hospital information systems, their architecture, standards in healthcare (HL7, DICOM, semantic standards like SNOMED, ICD-10, LOINC...).
Austria is currently, slowly but steadily, rolling out a nationwide system for electronic health records (ELGA) and I hope to also contribute to that. For example, I am currently discussing a project with 3 Master students in which they will develop an XForms implementation of the Austrian "elektronische Arztbrief", a letter that is send from one physician to another physician when the latter takes over the care of the patient. When submitted to the server, the form will then be converted into HL7-CDA format.
But I also will work on the further development of the CDISC standards. One of the teams I am in recently published the "Study Design Model in XML" (SDM-XML), an extension to the ODM standard. But that does not finish the work: we need to develop an implementation guide, and provide samples. We need to demonstrate the usefulness of the standard and convince the vendors to implement it in their tools.
I did already take some steps in that direction: the "ODM Designer" now implements SDM-XML, and I also demonstrated (also see previous posts) that an SDM-XML study design can easily be transformed in a "caBIG Patient Study Calendar" (PSC), and its workflow and timings part into a BMPN-2 workflow XML document, that can easily be read into a hospital information system.
That brings us back to the topic of integration between healthcare and clinical research, which is also taken care of by a number of IHE-profiles. So also there, I will be contributing, as I already did in the past (RDF and RPE profiles).
Of course there are already thoughts about the further development of the ODM standard (version 1.4). If you have some things that you think should be added to the "user requirements", please let us know, and we I will add them.
What I will probably discontinue, are my contributions to the further development of CDISC submission standards, such as define.xml and the "MetaData Submission Guide". Reason is that as a professor, I need to do innovative work. My strong impression (confirmed yesterday in a teleconference with people of the FDA - but that's another post) is that, even more than five years after SDTM and define.xml were first introduced (because the FDA wanted to standardize), the FDA is still not able to work with SDTM nor define.xml - the review environment is still completely absent.
So as long as the FDA is not modernizing their IT (to my opinion they are 20 years behind with respect to industry), it may be a waste of time spending time on the further development of formats for submission standards. On the other hand, proving that e.g. an XML format for SDTM submissions (NOT based on HL7-v3) is a giant step forward (which would also enable the FDA to come to a great review environment without high costs - especially statistical software licenses), might boost the modernization of IT at the agency.
But that's another story...
This will enable me to continue my work on the development of CDISC standards (and even being paid for it), but also to do exciting projects in the area of e-healthcare and its integration with clinical research.
My company XML4Pharma will also further exist in the future, but will concentrate more on software development (for CDISC implementation) and less on consultancy and training.
At the university, I am teaching "databases" and "medical informatics", the latter concentrating especially on hospital information systems, their architecture, standards in healthcare (HL7, DICOM, semantic standards like SNOMED, ICD-10, LOINC...).
Austria is currently, slowly but steadily, rolling out a nationwide system for electronic health records (ELGA) and I hope to also contribute to that. For example, I am currently discussing a project with 3 Master students in which they will develop an XForms implementation of the Austrian "elektronische Arztbrief", a letter that is send from one physician to another physician when the latter takes over the care of the patient. When submitted to the server, the form will then be converted into HL7-CDA format.
But I also will work on the further development of the CDISC standards. One of the teams I am in recently published the "Study Design Model in XML" (SDM-XML), an extension to the ODM standard. But that does not finish the work: we need to develop an implementation guide, and provide samples. We need to demonstrate the usefulness of the standard and convince the vendors to implement it in their tools.
I did already take some steps in that direction: the "ODM Designer" now implements SDM-XML, and I also demonstrated (also see previous posts) that an SDM-XML study design can easily be transformed in a "caBIG Patient Study Calendar" (PSC), and its workflow and timings part into a BMPN-2 workflow XML document, that can easily be read into a hospital information system.
That brings us back to the topic of integration between healthcare and clinical research, which is also taken care of by a number of IHE-profiles. So also there, I will be contributing, as I already did in the past (RDF and RPE profiles).
Of course there are already thoughts about the further development of the ODM standard (version 1.4). If you have some things that you think should be added to the "user requirements", please let us know, and we I will add them.
What I will probably discontinue, are my contributions to the further development of CDISC submission standards, such as define.xml and the "MetaData Submission Guide". Reason is that as a professor, I need to do innovative work. My strong impression (confirmed yesterday in a teleconference with people of the FDA - but that's another post) is that, even more than five years after SDTM and define.xml were first introduced (because the FDA wanted to standardize), the FDA is still not able to work with SDTM nor define.xml - the review environment is still completely absent.
So as long as the FDA is not modernizing their IT (to my opinion they are 20 years behind with respect to industry), it may be a waste of time spending time on the further development of formats for submission standards. On the other hand, proving that e.g. an XML format for SDTM submissions (NOT based on HL7-v3) is a giant step forward (which would also enable the FDA to come to a great review environment without high costs - especially statistical software licenses), might boost the modernization of IT at the agency.
But that's another story...
Sunday, September 4, 2011
HL7-v3 thoughts
I was less than 3 weeks on vacation with my 20-year old son, doing some fine mountaineering in the neighbourhood of Chamonix at the foot of the Mont Blanc. Together, we climbed his second 4000 meter peak, for me it was probably my last (getting older ...).
But in these 3 weeks a lot seem to have happened in the HL7 world.
First there was the announcement that the UK is scrapping its National Health IT Network, which did run for 9 years and costed 18.7 billion dollars (about 360$ per resident). You can find the article here. The program has for many years been criticized, including for its choice of HL7-v3 as the basis for electronic health records (EHRs) and the false belief that this standard would solve all problems at once.
Then there was the series of blog articles of Graham Grieve, titled "v3 has failed?". For your reference, Graham is one of the main contributors to the HL7-v3 standard. HL7-v3 has always been criticized to be overcomplicated and difficult and expensive to implement, and also I (as an XML specialist) have a lot of comments on the clumsy way it has been implemented in XML.
But now HL7 has started the "fresh look task force", so there is some hope that within a number of years (I guess 5 at minimum) there is a standard for exchange of health care data that is easy to understand, clear, and easy to implement (the latter also meaning "cheap" to implement).
Now, I will soon start working in a number of projects where CDA (which is based on Hl7-v3) is the basis of everything (more about that in a future post). CDA is there and is being successfully used in EHR systems, though it is not at all perfect (the XML is still very clumsy) and not easy to implement either. But it works, somehow.
I then also hope to be able to contribute, as an XML specialist, to the "HL7 fresh look task force", so thus starting contributing positively rather than critisizing this standard.
But in these 3 weeks a lot seem to have happened in the HL7 world.
First there was the announcement that the UK is scrapping its National Health IT Network, which did run for 9 years and costed 18.7 billion dollars (about 360$ per resident). You can find the article here. The program has for many years been criticized, including for its choice of HL7-v3 as the basis for electronic health records (EHRs) and the false belief that this standard would solve all problems at once.
Then there was the series of blog articles of Graham Grieve, titled "v3 has failed?". For your reference, Graham is one of the main contributors to the HL7-v3 standard. HL7-v3 has always been criticized to be overcomplicated and difficult and expensive to implement, and also I (as an XML specialist) have a lot of comments on the clumsy way it has been implemented in XML.
But now HL7 has started the "fresh look task force", so there is some hope that within a number of years (I guess 5 at minimum) there is a standard for exchange of health care data that is easy to understand, clear, and easy to implement (the latter also meaning "cheap" to implement).
Now, I will soon start working in a number of projects where CDA (which is based on Hl7-v3) is the basis of everything (more about that in a future post). CDA is there and is being successfully used in EHR systems, though it is not at all perfect (the XML is still very clumsy) and not easy to implement either. But it works, somehow.
I then also hope to be able to contribute, as an XML specialist, to the "HL7 fresh look task force", so thus starting contributing positively rather than critisizing this standard.
Saturday, September 3, 2011
Snapshot versus Transactional for ODM metadata import
CDISC has an excellent ODM Certification system. As one of the developers of different versions of the standard, and as an independent consultant, I regularly help (EDC) vendors with getting their systems certified.
One of the questions that comes back over again is about the difference between "snapshot" and "transactional" for import of metadata only (columns 1 and 3 of the table of the certification webpage). I recently had a chat with Dave Iberson-Hurst (who is doing the certification testings) and he told me there isn't a difference:
"The Transactional metadata import is no different from the Snapshot metadata import. It is an implication of the table layout because it is there for data import. In theory there is nothing in the spec to say the FileType attribute should be set to snapshot or transactional for a metadata import so you could set it to either, I would use snapshot but some people dont. So if you tick one of the boxes you tick both".
One of the questions that comes back over again is about the difference between "snapshot" and "transactional" for import of metadata only (columns 1 and 3 of the table of the certification webpage). I recently had a chat with Dave Iberson-Hurst (who is doing the certification testings) and he told me there isn't a difference:
"The Transactional metadata import is no different from the Snapshot metadata import. It is an implication of the table layout because it is there for data import. In theory there is nothing in the spec to say the FileType attribute should be set to snapshot or transactional for a metadata import so you could set it to either, I would use snapshot but some people dont. So if you tick one of the boxes you tick both".
The most craziest forms on the world
Within clinical research, we try to make our forms (CRFs) clear, easy-to-use, and clever (the latter especially in the case of eCRFs).
In Germany, we have the "Deutsche Rentenversicherung" (DRV - German state pension fund), which is also responsible for paying out pensions to orphans. Both my children get such a (very small) pension as they lost their mother some years ago.
So every few months, we get a set of forms to fill in, so that the DRV can judge whether my children are still eligible for payments. You can find one of such forms (although not exactly the one I got today) here.
If you try it out, you will get a message that you cannot save the form to your hard disc, but only fill it out using your computer, and then PRINT it out. The reason seems to be that the DRV does not have any mean to receive forms electronically. They only accept paper!
But now back to the forms I have to fill in for my children. These have some pecularities:
- the name, address and date of birth, and insurance number are preprinted on page 1 (fine!).
- on page 2 (the backside of page 1) you MUST fill in ... name, address, date of birth of the submitter (which is of course the same as the receiver data preprinted on page 1).
- if your bank account number has changed, you must give it as an international bank account number (IBAN and BIC), even if the account is in Germany
- if you live abroad, you should give it in the same way (which makes sense) AND additionally fill another set of forms (why???)
- on page 3, the insurance number is preprinted
- on page 3, you you MUST fill in ... name, address, date of birth of the submitter (why, as the preprinted insurance number is the unique identifier anyway?)
- if the orphan is in education (school, high school, university, in education at a company...) you have to fill in when the day, month, and year that the education will finish.
Do I have a crystal ball to see when this will be the case?
- on page 4 (backside of page 3), you have to provide some details about the education. In case it is university, you have to give the current semester (makes sense), and once again (why?) when the orphan will get his/her diploma (again you need the crystal ball here).
- on page 5, the insurance number is preprinted
- on page 5, you you MUST fill in ... name, address, date of birth of the submitter ... Getting frustrated ???
- many of the forms contain a large number of references to law paragraphs, e.g. (translated):
"the DRV is obliged by §48 of the 10th book of the social security law book in connection with §100 part 3 of the 6th book of the social security law book (DGB VI) to regularly test ..."
Got it?
Each time (about twice a year) I have to fill in these forms. Each time, I guess this shortens my life with about a week. These forms should get a header "these forms endanger your health"!
Yes, I know, I live in the BRD (Burokratische Republik Deutschland - Burocratic Republic of Germany)
Maybe one day (e.g. if they pay me for that), I will make an XForms form sample showing how this form can be provided electronically in a smart way ...
Hope we do better in clinical research ...
In Germany, we have the "Deutsche Rentenversicherung" (DRV - German state pension fund), which is also responsible for paying out pensions to orphans. Both my children get such a (very small) pension as they lost their mother some years ago.
So every few months, we get a set of forms to fill in, so that the DRV can judge whether my children are still eligible for payments. You can find one of such forms (although not exactly the one I got today) here.
If you try it out, you will get a message that you cannot save the form to your hard disc, but only fill it out using your computer, and then PRINT it out. The reason seems to be that the DRV does not have any mean to receive forms electronically. They only accept paper!
But now back to the forms I have to fill in for my children. These have some pecularities:
- the name, address and date of birth, and insurance number are preprinted on page 1 (fine!).
- on page 2 (the backside of page 1) you MUST fill in ... name, address, date of birth of the submitter (which is of course the same as the receiver data preprinted on page 1).
- if your bank account number has changed, you must give it as an international bank account number (IBAN and BIC), even if the account is in Germany
- if you live abroad, you should give it in the same way (which makes sense) AND additionally fill another set of forms (why???)
- on page 3, the insurance number is preprinted
- on page 3, you you MUST fill in ... name, address, date of birth of the submitter (why, as the preprinted insurance number is the unique identifier anyway?)
- if the orphan is in education (school, high school, university, in education at a company...) you have to fill in when the day, month, and year that the education will finish.
Do I have a crystal ball to see when this will be the case?
- on page 4 (backside of page 3), you have to provide some details about the education. In case it is university, you have to give the current semester (makes sense), and once again (why?) when the orphan will get his/her diploma (again you need the crystal ball here).
- on page 5, the insurance number is preprinted
- on page 5, you you MUST fill in ... name, address, date of birth of the submitter ... Getting frustrated ???
- many of the forms contain a large number of references to law paragraphs, e.g. (translated):
"the DRV is obliged by §48 of the 10th book of the social security law book in connection with §100 part 3 of the 6th book of the social security law book (DGB VI) to regularly test ..."
Got it?
Each time (about twice a year) I have to fill in these forms. Each time, I guess this shortens my life with about a week. These forms should get a header "these forms endanger your health"!
Yes, I know, I live in the BRD (Burokratische Republik Deutschland - Burocratic Republic of Germany)
Maybe one day (e.g. if they pay me for that), I will make an XForms form sample showing how this form can be provided electronically in a smart way ...
Hope we do better in clinical research ...
Subscribe to:
Comments (Atom)