Correct calculation of document hashes in MHD

[Andreas Schnabl]

Hello everyone,

I have stumbled upon some unclarity regarding the calculation of document hashes in MHD (e.g. in ITI-65 transactions).
By my simple understanding so far, I would expect the hash to be calculated like this:

raw document bytes -(SHA-1)-> 160 hash bytes -(base64-encode)-> hash attribute string (28 characters)

However, at the currently ongoing EU connectathon, I have also encountered the following calculation method with a test partner, which, of course, leads to a different result:

raw document bytes -(SHA-1)-> 160 hash bytes -(hex-pretty-print)-> hex string (40 characters, encoded as 320 bytes in standard encodings) -(base64-encode)-> hash attribute string (56 characters)

This seems rather unnatural to me, since the hex formatting of the hash seems to fill a similar role as the base64 encoding already does:
making binary data human-readable and easily transferrable over many media. In examples provided by MHD, such as [1], hashes have been
calculated using the hex-display step. However, in the actual standard text of MHD, I haven't found any hints regarding the use of this
hex-display step, and in the only example with a hash in the base FHIR specification [2], no hex-display step has been inserted.

Can you advise me which of these two ways of calculating a document hash is the correct one?

Best regards,
Andreas

[1] https://profiles.ihe.net/ITI/MHD/Bundle-ex-minimalProvideDocumentBundleSimple.json.html
[2] https://hl7.org/fhir/R4/documentreference-example.json.html

[qligier #]

Hi!

The intent of the FHIR specification is to base64-encode the raw bytes, not the hex representation: https://chat.fhir.org/#narrow/channel/179166-implementers/topic/Attachment.2Ehash.20and.20hash.20representation

Kind regards,
Quentin

[John Moehrke]

The hash in mhd is the same for xds. It can't be reformed or recalculated or reencoded.

John Moehrke - Architect: Standards - Interoperability, Privacy, and Security for Bylight.com
https://healthcaresecprivacy.blogspot.com

   

--
You received this message because you are subscribed to the Google Groups "IHE MHD Implementors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-mhd-implemen...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ihe-mhd-implementors/3a0080f4-a0ae-44ca-813f-93bd30349c72n%40googlegroups.com.

[qligier #]

Hi John,

This is not about modifying the hash in MHD, this is about encoding it correctly in the FHIR resource.

Grahame said the intent was to base64-encode the hash raw bytes, vs the base64-encoding of the hex representation of the hash in the MHD examples. It's trivial to go from one to the other.
Right now, the MHD way is inconsistent with the official FHIR example: https://hl7.org/fhir/R4/documentreference-example.xml.html

Kind regards,

Quentin