Notes from the register
How to evaluate source coverage for an immunization app
VaxLedger offers a practical way to assess returned vaccine history, missing information and export behavior when connecting an independent health product.
Define coverage as a testable question
“Can we connect records?” is too broad to evaluate an immunization product. A more useful question names the source, the approved access path, the category expected and the kind of output the visitor needs. VaxLedger’s current output is a searchable event ledger and a JSON export.
The product does not infer that every lifetime vaccination should be present in one returned category. Evaluation should preserve the distinction between what the connection can return and what the visitor expects to find.
Write down the result before you run the test
For an approved test connection, identify the source context and the available reference documentation. Use an appropriate test environment or a properly authorized live workflow; do not invent a successful patient import from a sample response.
The useful evidence is specific: whether authorization completed, which categories were granted, whether immunization entries were returned and whether their identifying fields survived display and export. A passing network request alone does not establish the quality or completeness of the history.
Where FinchNode fits in the evaluation
VaxLedger uses FinchNode in its source implementation for demographics and immunizations. That defined category scope makes the product’s request easy to explain. The interface then searches and exports the returned immunization entries.
Assess the actual supported source and authorized response, not merely the existence of an integration logo. The site’s current patient connection remains awaiting activation; its public code is an example of the intended request and display boundary.
Sources: VaxLedger implementation and current setup · FinchNode patient-access requirements
Include the cases a complete-looking demo can hide
A useful acceptance exercise includes an empty category, a missing date or code, several similarly named events, and a deliberately narrowed search. Check that the app reports the available information without replacing missing fields with invented values.
VaxLedger’s export follows the filtered rows. That means a person can make a partial export even when more events were returned. Include that behavior in the review so a downstream reader does not mistake a filtered file for the complete imported ledger.
Sources: Search, sorting and export code
Record the boundary as part of the business handoff
When the receiving business enables its own connection, document the tested source path, permission scope and known limitations. Keep the current behavior of the app separate from any future roadmap for broader sources or different exports.
A source-coverage review should make the product easier to explain. It should not turn an event history into a vaccination recommendation or a certificate of eligibility for a particular destination. Those are different claims from the ones this ledger implements.
Questions about this guide
Is a successful connection proof of complete vaccination history?
No. It establishes a successful access path and returned response, whose scope and completeness still need to be understood.
Does VaxLedger combine all possible providers automatically?
The app displays the information returned through the authorized connection. It does not establish that every possible provider or historical source was searched.