Vaccine Credentialing Activities: It’s All About the Rules!
In my previous article, I wrote about the World Health Organization’s Interim guidance describing its technical approach to Smart Vaccination Certificates. What the WHO is doing is the first step. In this article, I would like to address the next steps that need to be taken. Specifically, how are organizations going to use the Smart Vaccine Certificates. This issue boils down to the rules that are going to be developed and adopted to make the SVC’s usable. Many of these rules currently don’t exist so we will start by analyzing some key factors.
In our previous blog post, we wrote about the Interim guidance for developing a Smart Vaccination Certificate (SVC) released by the World World Health Organization (WHO). WHO is an influential world body and many countries and national health organizations follow the guidance of the WHO. There are already several proposals similar to the guidance being offered by WHO. For example, the European Union (EU) has proposed the establishment of a “Green Passport” for its member nations through a proposal submitted to the European Parliament. This proposal is based on technical guidelines very similar to what WHO is proposing.
The Challenges Inherent in Implementing Smart Vaccine Certificates
At the core of both the WHO and the European Smart Vaccine Certificates is the notion that the SVCs are proof of vaccination for medical purposes – no more, no less – consistent with other major SVC initiatives. For example, the Vaccine Credential Initiative (VCI) is actively working on developing prototype software that implements a set of features based on the SMART Health Cards Framework and drawing on W3C standards. The COVID-19 Credential Initiative (CCI) strives to develop open source solutions for vaccine credentialing.
Creating the SVCs is one thing, but creating the rules that need to be applied when SVCs are actually used is quite another. For example, a TSA agent at an airport may be trying to access and verify the medical information found in a traveler’s SVC. The agent’s software application applies whatever business rules that are appropriate to determine whether the individual can (in this case) travel. But if the rule being applied is incorrect, it does not matter how pristine the SVC may be: the passenger still won’t be able to board the flight. These applications are being designed to require very little knowledge on the part of the verifier: just a “thumbs up” or “thumbs down” assessment is usually desired.
There is little attention paid in any of these planning documents to just how these rules will be developed, maintained, or validated. The public will likely not be well served by having each verifier develop their own rules and maintain them, especially if the use of the SVC expands over time beyond COVID. The Good Health Pass Interoperability Blueprint Outline recognizes this as a key challenge to SVC implementation.
Models from the US Public Health System
There are good examples of rules systems that have been developed to support this type of decision making. In the US, these examples often come from the public health system. In a previous blog, we offered some initial recommendations for SVC policy in the US.
A key element of public health surveillance in the US is the reporting of infectious and certain non-infectious conditions to state, local, and tribal public health agencies (PHA). COVID-19 cases are reported by clinical sites to public health agencies in this way. As the use of electronic health records (EHRs) becomes more widespread in hospitals and doctors’ offices, and the quality and completeness of data improves, electronic case reports have begun to replace the manual, paper case reports that have dominated the past; COVID-19 case reporting requirements have spurred this new use of electronic case reporting (eCR).
An important component of the eCR strategy in the United States is the use of the Reportable Conditions Knowledge Management System (RCKMS), an open source application that HLN develops and maintains for the Centers for Disease Control and Prevention (CDC) as well as the Council of State and Territorial Epidemiologists (CSTE). RCKMS provides a shared Authoring Tool that allows public health agencies to author rules that determine whether a patient’s current medical condition is reportable to public health. An EHR electronically submits clinical data for an individual patient to RCKMS securely over the Internet to determine if the patient has a reportable condition. Most importantly, the rules are maintained and accessed centrally but developed locally by each jurisdiction according to their requirements.
The Added Challenge of Different Immunizations
Predicting what vaccinations are due for a patient now or in the future based on their past vaccinations can be quite complex, even just for a single vaccine series like COVID-19. The spacing of different doses must be correct, as well as the proximity of some vaccinations to others. Clinical decision support (CDS) is the use of computer software to assist clinicians in providing better care for their patients by bringing relevant medical knowledge to bear. Clinical decision support for Immunizations is the application of this technology to vaccination practice.
As more COVID-19 vaccines become available and the risk of mixed vaccine use in a single patient increases, the need to follow more complex clinical guidelines increases. It would be unwise to leave this clinical decision making to SVC verifiers (or their applications) who are non-clinical and are presented only with the clinical facts by an SVC.
In fact, a clinically invalid dose would likely only be recognized with the application of CDS logic. This leaves the potential that a verifier may naively accept an SVC with an invalid dose because the evaluation of the validity of the dose is not done.
HLN develops and maintains, for instance, an open source Immunization Calculation Engine (ICE) which is a clinical decision support tool that can be deployed locally or in the cloud and evaluates a patient’s immunization history and based on his/her age determines what vaccines are clinically valid and which vaccines are due. COVID-19 support was added to ICE when the first vaccine was approved for trial use by the Federal Drug Administration (FDA) and each subsequently approved vaccine was quickly added.
It’s All About the Rules!
To help address this risk, a repository of SVC “rules” and rule templates could be developed and maintained for access by authorized verifiers. We noted above how RCKMS provides rule “templates” to make it easy for jurisdictions to either adopt standard rules or use them as a basis to “tweak” rules for their own needs. For COVID, an SVC rule repository could also provide standard templates so that verifiers could not only apply similar rules to similar situations but could also implement them quickly with little or no modification in most cases. Rules could also be potentially exported from the repository should offline use be required, or if dependence on a centralized repository is not desired. CDS for immunizations might be a key component of an SVC rule repository.
The repository could be supported by an automated rules “service” to which someone sends an SVC, invokes the rule requested by the verifier, and returns the evaluation (“thumbs up” or “thumbs down”). Verifiers could either download or access and incorporate the rule definitions from the repository into their applications or send requests to the rules service directly over the Internet.
The development of SVCs is not enough. The infrastructure to support the effective use of SVC needs to be complete enough to support the entire process end-to-end. This involves not only the end user’s experience (be they a consumer/”holder” or a “verifier”) but also the appropriate source(s) of the data and especially the rules being applied to the data to make verification meaningful. There has been very little attention paid to verification rules but a solid strategy is required or the verification process itself will be suspect. A repository and the rules contained within it could be developed as an open source collaboration or by a government authority and made available to anyone who wants to use it.