One HTML file compared with a web application: sample intake without the long IT approval process

2026-07-14

A web application can collect sample requests or show clients the results of their analyses. Such an application is easier to build now than at any time before. The code was never the difficult part. The difficult part is to make IT approve any type of systems development: a server, a login, a database. At a public research organisation, IT does not give that approval easily. For that reason, good tools stay in the approval queue and no person uses them.

Thus the step from a PDF form or an Excel form to a web application looks large. But there is an intermediate step: an HTML file. It costs nothing. It is not necessary to ask a person for permission to run it.

The intermediate step

Almost all computers have a modern web browser. You can open an HTML file as a file: double-click it. Then its code and its data have no contact with the internet. There is no server and no connection, and there is nothing to serve that IT must approve. But in that sandbox you have real tools: JavaScript, the Web Crypto API of the browser, and a full SQLite database. A PDF or an Excel sheet can do much less.

The most important function is this: the file can compose the data that you enter into a QR-code label that a scanner can read. When the lab scans the QR code, the lab receives the request as structured data. Transcription is not necessary. When a lab request arrives as a document, a person must type it into the system again. The QR code removes that cost fully.

A QR code for an example request — This QR code holds one complete request for two samples and multiple tests. The lab scans the QR code or pastes the same string (the two inputs are identical). Then the data is in the system, and no person types it. ⬇ Download this QR code

Excel does a part of this. An Excel workbook holds structured data and moves as a file. But people continue to send it by email and to enter the data again. The QR code removes that last manual step.

The file that the client fills

Here is an example: Juárez Research Centre. The Centre has environmental and geoanalytical labs with ISO/IEC 17025 accreditation. These labs receive work through documents. A client opens this HTML file to make a request. An installation and an account are not necessary. The client uses only a browser.

The screen of the HTML file where the client selects a form type — Open the file, then select a form type. Each form type matches one of the real intake forms of the Centre.

The filled request form in the HTML file — The filled form. The file checks the necessary fields and the formats while you type. The invoice block and the report block can each hold multiple contacts. Each sample has a multiselect list of test panels from the services schedule of the Centre. Thus one screen shows several tests for each sample.

One filled form, three outputs

After you fill the form one time, the file exports the request in three formats. The PDF and the Excel workbook are for people. The QR code (above) is for the machine.

The PDF export of an example request — PDF export — a clean form that is ready to print. It opens in any browser. Acrobat is not necessary. ⬇ Download this PDF

The Excel export of an example request — Excel export — a real .xlsx workbook (the sheets Request and Samples). One sample can have multiple tests. ⬇ Download this Excel file

How the file operates

The cryptography uses only the Web Crypto API of the browser. It uses no libraries. The algorithms are in the approved set of CSE (AES-256-GCM, PBKDF2-SHA-256, ECDH/ECDSA on P-256, SHA-256).

Structured and validated at the source. Thus a machine can read the output, and no person types the data again.
DEFLATE compresses the QR data. The data becomes approximately 40% smaller. A full request with multiple samples fits in a version-18 code. A phone scans that code without problems.
Content-addressed sample IDs. Each ID is a hash of the data of that sample. Thus the IDs are tamper-evident. IDs from different devices do not collide. A central counter is not necessary.
Encrypted at rest with a PIN. The supplied page has a Content-Security-Policy. The most important directive of the policy is connect-src 'none': the page cannot open a network connection. The data that you type can go only into the file that you export.
The lab can seal the results for the client. The request contains the public key of the client. The lab encrypts the report to that key. Thus only the requester can open the results.

Why approval is easier for a downloadable file

Here is the argument again in plain words. When an organisation serves a web application, all of the institutional governance applies:

an IT security / threat-risk assessment
a privacy review against the access-and-privacy law of your jurisdiction
questions about data residency and retention
vendor onboarding and procurement
continuous work to operate the system, and continuous liability

This takes months, not days.

When an organisation posts an index.html as a download, the act is fully different. The file is on a page. The user clicks it and opens it in the browser that the user already has. These items are not there:

software that the user must install
a server to assess
data that leaves the device and that a person must review
an account
a vendor that operates a system for the organisation

It is the same as when you give a person a PDF. The file is a tool that a person runs, not a system that the institution operates. That is the difference between "interesting demo" and "in use next week."

Figure 1. Institutional governance applies to a served web application. A downloaded HTML file has no server to assess.

When you use real custody records, governance continues to apply. This text is not legal advice. But it is much easier to start with a file than with a web application, because there is no system to set up.

A first step, without a server, to a real web application

The file can be more than a form for one request. The user can keep a local history file: export the encrypted database, then import it before the next session. With the history file, the same downloadable file does the work that people usually set up a web application to do:

a dashboard of previous requests
the results that came back for each request
simple analysis and charts of those requests and results

All of this operates with no web server. The history stays in a file that the user controls.

The file is also a clean prototype. Possibly, the Centre will decide to build a hosted client portal with real accounts, a shared dashboard, and cross-request analytics. Then this file is the point to start from: the same data model, the same forms, the same exports, all already validated end-to-end. Start with a download. Change to a web application only if, and when, the value justifies the approval process.

How to use the files

Client (the requester):

Open the client file.
Select a form.
Fill the form. The file checks the formats while you type.
Add the samples and select their test panels.
Export the request as a PDF, an Excel workbook, or a QR code.
If you want to save requests and use profiles again, sign in with a PIN. This step is optional.

Lab (intake):

Open the lab file.
Scan the QR code of the request, or paste the string.

The request then shows on a kanban board. The board has columns by sample type, and you can filter by client. Each request moves through these stages: Received → Prep → Analysis → Reported → Complete.

You can export the data to Excel or JSON. To transfer all the data, export the full encrypted database. Two stations can each export, and then merge the exports with no conflicts.

Figure 2. The client file exports a QR code. The lab scans the QR code, and the request shows on the kanban board.

The code

The code is open source. It has two Vite/TypeScript applications (client and lab). Each application builds to one self-contained HTML file. The code also includes the offline chain-of-custody and crypto core:

github.com/rheophile10/sample-forms

Where to start

Do not start with the senior executives. Start with the person who already moved the sample intake toward digital tools: the owner of the Geoanalytical "Request for Laboratory Services" form. This is a person who moves a form from PDF to Excel on personal initiative. A person with that attitude will adopt the next step. Give this person the client file, configured for the real form that this person owns. A trial costs nothing and uses no institutional system.

Note from the author: I built the tool and verified it end-to-end before I wrote one word of this post. The sequence was: form → QR → lab kanban → sealed report → decrypt → visualise.