One of the first questions clinical informatics teams ask when we describe what Enrollvue does is: where does the patient data go? The question is exactly right, and the answer matters for whether a site's compliance and IT teams will even allow the integration conversation to proceed.
This post describes the architectural pattern we built to run protocol matching computations in a way that keeps protected health information (PHI) local to the site. We are not claiming this as the only valid approach, and we are not describing it as a compliance certification of any kind. What we can describe is the design reasoning and the tradeoffs we made.
The Core Constraint: PHI Must Stay Local
Under the HIPAA Privacy Rule, a covered entity, which includes healthcare providers and health systems, can share PHI with a business associate under a Business Associate Agreement (BAA). That creates a legitimate path for patient data to move to a vendor's infrastructure, provided the BAA is in place and the data is handled according to the required safeguards.
The practical challenge is that this path, while legally available, creates friction in site adoption. Hospital IT departments have review processes for any system that touches PHI. Those reviews take time, involve security assessments, and require organizational sign-off that can take months at large academic medical centers. For a small bootstrapped company trying to deploy quickly with early clinical partners, waiting six months per site for an IT security review is not a viable model.
The architectural answer we arrived at was: what if the matching computation runs locally, and the only thing that leaves the site is a result set that does not contain PHI? That shifts the classification from "PHI leaves the site" to "de-identified outputs leave the site," which is a fundamentally different compliance posture.
How the Local Computation Pattern Works
The matching process in Enrollvue proceeds in three stages. The first stage is protocol parsing: we take the eligibility criteria document and produce a structured representation of each criterion, including its data type requirements, logical conditions, and temporal qualifiers. This happens on our infrastructure, with no patient data involved. The output is a criteria specification object, not a patient list.
The second stage is local execution. The criteria specification is sent to a lightweight process running within the site's network perimeter, behind their firewall. That process queries the site's EHR data, applies the criteria logic to patient records, and produces a candidate list with internal patient identifiers. This is where PHI is involved, and this is where it stays. The matching computation runs entirely within the site's controlled environment. The software we ship for this is designed to operate with read-only database access, and we work with site IT to scope the permissions appropriately for each EHR integration.
The third stage is result reporting. What leaves the site is a candidate list that contains only the site's internal patient identifiers, a set of boolean or categorical flags indicating which criteria each candidate satisfies, and aggregate counts that summarize the candidate pool. Individual patient identifiers are replaced with site-assigned internal tokens before transmission. The mapping between those tokens and actual patient identity never leaves the site's network.
The coordinator sees a candidate list in the Enrollvue interface that shows how many patients matched, which criteria they satisfied or failed, and a priority ordering based on the matching logic. To see the actual patient name and contact information, the coordinator uses a lookup table that exists only within their own EHR system.
EHR Integration Approaches
The practical challenge in making this architecture work is that EHR data is not uniform across systems. We have worked with sites running Epic, Cerner, and a smaller number of other platforms, and the data structures are different enough that the local execution layer has to be adapted per environment.
For sites with HL7 FHIR APIs enabled, we can use standardized resource queries for a significant portion of the criteria data requirements. Structured data like lab results, medication orders, diagnosis codes, and demographics are generally accessible through FHIR endpoints with reasonable completeness for common data elements.
For criteria that depend on clinical notes, the FHIR DocumentReference resource can surface note content, but note extraction adds a natural language processing layer to the local computation. We run that processing within the local execution environment as well. The NLP models themselves are deployed locally, not calling out to an external API with note content. This is a deliberate choice: sending clinical note text to a cloud NLP endpoint, even without attached patient identifiers, creates a data governance question that site compliance teams would need to evaluate separately. Keeping it local avoids the question entirely.
Where This Architecture Has Limits
We are not saying this approach is universally superior to cloud-based PHI processing with a BAA. There are real tradeoffs.
Local execution requires deploying and maintaining software within the site's infrastructure. That means the site's IT team needs to be involved in the installation, and updates require coordination. For sites with understaffed IT departments, that is a real friction point. Cloud-based models where the vendor manages all infrastructure can be easier to maintain once the BAA and security review are complete.
The local pattern also means we have less visibility into the matching results than we would if the full candidate data were in our system. We see aggregate statistics and anonymized flag patterns, but we cannot directly audit or debug a specific matching result without working through the site's coordinator. That slows down quality improvement cycles compared to having the data centrally available.
And finally, the local execution layer is only as good as the data in the local EHR. If a patient's relevant history is incomplete in that system, which is particularly common for prior therapy documented at other institutions, the local matching will miss it. A cloud model that aggregated data from multiple sources before matching could theoretically produce better candidate recall, though it would require a significantly more complex data sharing and governance structure to be HIPAA-aligned.
Why This Matters for Site Adoption
The practical impact of this architectural choice is visible in how quickly we can move from a site's first call to a working integration. Sites where we can frame the deployment as "nothing leaves your firewall except de-identified outputs" typically move through their internal review process faster than sites that need to evaluate a full PHI-sharing arrangement.
That speed advantage matters early in a company's life, when the ability to demonstrate value at real clinical sites is what determines whether the product actually gets used. We made this tradeoff deliberately, knowing it would create some constraints on our analytics capabilities. The compliance posture and the adoption speed it enables were worth those constraints, given where we are.
The architecture will evolve as we grow. But the core principle of keeping identifiable patient data local to the site is one we intend to maintain, not as a marketing claim, but because it reflects how we think the trust model between clinical software vendors and healthcare institutions should work.