Sarah Kliff and Margot Sanger-Katz have an article in todays NYT describing the ways that the humble Fax machine is gumming up processing of COVID test results.
This is an example of what I call a ‘downgrade bottleneck’ that forces everyone to comply with the lowest common denominator. It isn’t a problem of software or technology, its institutional inertia that is the prime cause.
The Web began as a solution to a similar problem: CERN computing was dominated by a mainframe mafia that hoarded power by hoarding the information. The Web allowed CERN scientists to get access to the data they needed without having to (directly) interact with CERN-VM.
The problem here isn’t Alice and Bob, the technicians who are performing and analyzing the tests. It’s Fayette who prints out the results and feed them into a fax machine and and Frannie who collects the faxes in the mail room and delivers them to the technicians. Fayette has absolutely no interest in learning new technology: he will be retiring in five years time. Frannie has no time because this is only one of the three minimum wage jobs she works to make ends meet.
The key to transitioning from a paper based work flow to an electronic one is to provide a mechanism that allows the electronic workflow to ‘recover’ even if the communication path forces a downgrade to paper at some point.
The technical details of this scheme are set out in my Internet Draft.
First let’s look at the problem:
The problem isn’t the lab technicians who perform and analyze the tests, it’s the office managers and processes in-between. The machine-readable data is lost as soon as the report is scanned into a Fax machine. A bitmap image of a test result is nowhere near as useful as an XML document with the machine readable results.
This process is security theatre rather than security. If Internet security is poor, telephone system security is laughable: Anyone who knows their way round SS7 can redirect any call. That’s how ‘Lawful Intercept’ takes place. And these days almost all the ‘telephone’ traffic goes over the Internet in any case.
The problem then is to provide a means of bridging the ‘Fax Gap’ so that Alice can send her test results to Bob such that we achieve ‘end to end’ machine readability while complying with HIPAA/GDPR/etc.
Insecure Solution: QR Code
The simplest solution to the ‘end to end’ machine readability problem is to write the results out to a Web server in an electronic format. It is not necessary to choose a single format at this point. There could be one or a dozen. Provided that the format itself is sufficiently well documented, we can write tools that convert between the formats. In current circumstances, this can be crowdsourced.
So at this point we have a URI that Alice could include in her report which she prints out and gives to Fayette to fax to Frannie who hands the printed paper to Bob. At the other end, Bob sees there is a URI and enters that into his system to recover the machine readable data.
For added convenience, the report generator can present the URI as a QR code. So Bob can just scan the fax with his phone and he has the full electronic data.
Securing the data
The problem with the solution above is not that it is insecure, it is that it is not compliant. The Web server communication is encrypted (https = TLS) but the data itself is sitting on the server in plaintext. And it isn’t very difficult to guess there will be a patient-02313 file, patient-02314 file, etc.
TLS doesn’t work for this application because it is designed to provide a means that allows the person initiating a communication to establish a secure channel to the responder. Our communication is going in the opposite direction and so TLS doesn’t work unless there is some sort of credential involved. Deploying credentials is a really hard problem. Alice isn’t really interacting with Bob, she is interacting with an institution.
What we need to do is to encrypt the document and turn the Faxed document into the credential that allows Bob to decrypt it. If the Fax channel is HIPAA compliant, this approach is also compliant as access to the decrypted document is precisely the same as access to the decryption credential.
Instead of the URI above, we encrypt the document using AES-256 and encode the following information in the QR code:
As with any URL this contains a statement how://where/what
how: Is the UDF data resolution scheme.
where: Is the Web service for https://example.com/
what: Is a locator string determined from EBBB-…-YS using cryptography.
After retrieving the data, it is authenticated and decrypted using keys derived from EBBB-…-YS.
The above scheme is entirely unencumbered as far as I am aware. I proposed a similar scheme together with Rohit Khare when we worked together at the MIT Web Consortium in 1995 and published a variant of the basic mechanism with another group ten years ago.
The original purpose for which this was designed was to enable people to securely exchange credentials needed to support end-to-end secure messaging by bumping smartphones at all the business conferences we won’t be having for the next few years because of COVID.
Bonus: Signing contracts
The EARL scheme is particularly useful for signing large contracts without the need to autograph every page. It is sufficient to autograph a single page with a QR code on it to authenticate the entire document.