Category: Software Development

One of my customers, a large dental practice, had a problem from time to time when reading Krankenversicherungskarten (German health insurance card, KVK). The insurance number got all garbled up, which led to problems when reading the patient’s insurance data into the health care application. After their sysadmin and I analysed the situation it seemed that the application reading the data from the card and writing it to a file in a custom format was to blame. This program (KVKTool) was included with the Cherry card reader and had been modified by another consultant to write the read data to a file rather than displaying it on the screen.

This C++ program was a huge stinking pile. All card reading was done in a method called CKVKToolDlg::Onreadcard. The name CKVKToolDlg hints at it: This is the class responsible for showing the dialog. (Yes, it had been left in the program by the previous consultant. Only the dlg.DoModal() call had been commented out.) The method was a gigantic 837 lines long and features all kinds of goodies such as lots of copied-and-pasted code that had been modified in some instance to fix bugs, but not in others.

After a long refactoring session (which turned into a rewrite), I was able to spot the problem: a wrong workaround to bugs in a sizable amount of KVKs. Normally, the data on KVKs is structured into fields in an arbitrary order. These fields consist of a one-byte tag to identify the field, a one-byte length marker, and then n bytes of data, where nis the length. All KVK fields are identified by tags between 0x80 and 0x92. But all KVK fields are wrapped by a super-field called the “Versichten-Template” (insurant template, VT) with tag 0x60. Thus, data on a typical (non-buggy) KVK card would start like this:

Now, buggy cards seem to insert a stray 0x81 byte after the 0x60 tag:

This code in the KVKTool was supposed to handle this problem:

// skip tag 60 and length
int i=2;

// some cards seem to have a damaged tag 0x89 after 0x81
if (responsearray[1] == 0x81)
    i++;

(Snipped the huge indentation.)

responsearray is a buffer that contains the KVK data and i is an index into that buffer. This code works fine in most circumstances. It works around cards with the stray byte. But there is one situation where it utterly fails: On correct cards where the Versichten-Template is exactly 129 bytes long. In this case, the first tag is skipped entirely, which usually is the insurant’s number. Since it was not, junk (random memory content) was written to the file in place of the insurant’s number. Not good, but hopefully fixed now.