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.

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".

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 ...