| I saw your blog, did a Google search, and found that you'd posted here.
Anyhow, I agree with the other person's assessment -- it's not an SHA-1 (secure hash), since a hash can only go in one direction.
That said, a few things that make even more questions:
<DatabaseRecords Size="65536" CompressedSize="7028"...>
That size does not seem by chance, since it is 2^16 (16 bits) in length. When taking the ASCII text data of that XML node, I get a file that is 9,373 bytes long. I would have hoped it equaled 7028 bytes...
It's even less promising with the mention of the "RSAKeyValue" and exponent. I am taking a guess that they are performing RSA encryption on the data before doing anything else, since the record size should be 7,028 (I think the extra bytes that make it go up to 9,373 bytes are due to the added encryption padding; base64 decoding results in a string that may be readable by decoding with RSA -- or perhaps, I'm completely wrong, and they've got an efficient way of using those bits to record the numeric data in regular time intervals).
The only way to reverse that is to know their private key. And I'm sure that private key is somewhere not very obvious (or maybe it is...argh!). While the program is bad, they seemed to really be good at hiding stuff. Or maybe we're just looking too hard!
I find it also interesting that they have a "Signature value" -- I wonder why they would sign that data.
It would be interesting if you modified a single byte of that Signature to see if the program crashes. Or modify the modulus of the RSA key to see if it hurls. If it does, we know that decryption must be performed first. If it doesn't, we'll know that we can ignore that info.
So if you can be so kind as run those experiments, maybe we could get a bit further.
The next problem is that if it does turn up to be a string that has been encrypted with RSA, then if we were to find the private key and break it (which might take the effort of a cluster of key-breaking computers), we won't even know what we're looking for.
The decryption key could even be different for each device, depending on the serial number stored in the flash.
They're really covering their assets, if this is the case. Why, though? It's a frustrating mystery.
My thoughts are perhaps they think they need to encrypt it for patient privacy. Or maybe they want a piece of the money if someone takes their invention and does something with it?
One other trick might be to play with modifying some of the other data in the XML file to see how the program reacts. If you change a bit of that 9K data string, does the program fail upon discovering the error?
Someone probably got their hands on a toolkit that let them do this kind of encoding, and they got excited and really made it worse to figure out for those who need that info.  | 
