Keymaker
Disease surveillance, modernized
- NBS7 deployed in your Azure tenant
- CDC DIBBs and eCR Viewer
- Data modernization roadmaps
Cloud and on-prem systems for public health, government and research. Built in your environment, documented for audit, then handed to you or run for you.
Every system is built from code you keep and documented to the controls your auditors ask about.
Disease surveillance, modernized
Secure by default, cloud or on-prem
REDCap and 21 CFR Part 11
For counties, health departments, tribal programs and districts. Small enough to buy without a full procurement.
A 30-minute review of your cloud environment. You leave with the top three savings and security fixes.
A full cost and security review with a prioritized fix list. Refunded if we find less than $9,000 in annual savings.
Ongoing cost tuning, security monitoring, patching and a monthly report for leadership.
Each stage is scoped and priced on its own. Take the keys after the build, or keep us on for ongoing support.
Current systems, gaps, security controls, cost model and plan.
2–4 weeksDeployed in your environment from code, tested, then cut over.
6–16 weeksCode, runbooks and working sessions until your team can run it.
2 weeksUpgrades, monitoring, backup tests, monthly cost and security reports.
MonthlyA 30-minute call covers your current systems and where to start.
We deploy NBS7 and DIBBs into your health department's own Azure tenant, built from code you keep, so your epidemiologists get faster, cleaner case data without vendor lock-in.
› Your keys. You drive, or we drive for you.
Everything runs in your Azure subscription, under your sign-in.
Every resource is in Terraform you own. Run it yourself, or keep us on to run it for you.
Documented to HIPAA and NIST 800-53 from day one, so your ATO starts with evidence.
For health departments moving to modern surveillance without a cloud team on staff.
NEDSS Base System 7
CDC Data Integration Building Blocks
Data Modernization Initiative planning
Bolt-ons we deploy alongside NBS7 or DIBBs, in your tenant.
Links records for the same person across labs, eCRs and cases, so investigators stop chasing duplicates.
Turns faxed and scanned case and lab reports into structured data, with a human review step.
Converts, validates and routes messages between your HIE, labs, NBS and CDC.
Hardened SFTP for labs and partners that still send ELR as files.
Built on open source: NBS7, DIBBs and our modules carry no license fees. Your grant money goes to the work, not to subscriptions.
Twenty-five years of infrastructure, the last several inside state public health data modernization.
# state health department · eCR Viewer $ terraform apply -var-file=prod.tfvars ~ azurerm_application_gateway.dibbs ssl_policy = "AppGwSslPolicy20220101" + azurerm_role_assignment.kv_secrets_user Apply complete! Resources: 14 added, 3 changed. $ curl -s https://ecr-viewer/api/health {"status":"OK"} # tenant: state-owned · keys: state-held
References available on request.
Practical writing on patient matching, interoperability, cost and compliance.
Why patient matching quietly fails as systems multiply, and how an EMPI built on OpenCR/HAPI FHIR fixes it without a proprietary license.
HL7v2 isn't dead and FHIR isn't a drop-in replacement. A practical guide to what your interoperability layer actually needs to support.
A practical look at building an OCR/document-intelligence pipeline for lab reports, faxes, and clinical paperwork — without per-page SaaS fees eating the budget.
A grounded, category-by-category cost comparison between commercial healthcare IT platforms and open-source alternatives — including where commercial still wins.
Practical, non-hype guide to where AI genuinely improves healthcare IT operations — document processing, data quality, and automation — and where it doesn't belong yet.
REDCap Cloud's per-project pricing punishes growing research programs. Here's how flat-rate, self-managed infrastructure compares.
A practical guide for nonprofits evaluating REDCap hosting — licensing eligibility, realistic budget ranges, and what actually matters.
Seven concrete questions to ask any REDCap hosting provider before signing — covering compliance, environments, and licensing.
A practical breakdown of what actually makes a REDCap environment HIPAA compliant — infrastructure, agreements, and administrative controls.
A clear walkthrough of how the REDCap consortium license actually works — eligibility, the request process, and common misconceptions.
Duplicate records, fragmented case data, and the real fix behind a properly built Enterprise Master Patient Index.
Every health department eventually hits the same wall: the same person shows up as three, five, or a dozen different "patients" across immunization registries, case management systems, lab reporting pipelines, and surveillance platforms. A name gets misspelled at intake. A date of birth is transposed. Someone gets married and a new last name appears with no link back to their prior records. None of these are exotic edge cases — they're Tuesday.
The cost isn't abstract. Duplicate and fragmented patient records drive bad case counts, missed contact tracing links, redundant outreach, and — in clinical settings — real safety risk when a provider is working from an incomplete history. An Enterprise Master Patient Index (EMPI) is the infrastructure layer that's supposed to solve this: a system that assigns one durable identity to a person and links every downstream record back to it, regardless of which source system it came from.
Simple deterministic matching — same name, same DOB, same SSN — works fine for a pilot with a few hundred records. It falls apart once you're running real volume, because:
What's needed is probabilistic matching — algorithms that score the likelihood two records represent the same person using multiple weighted fields, not a single exact-match rule.
False negatives (real duplicates that don't get linked) fragment a person's history across systems. False positives (different people incorrectly merged) are worse — they can pull one person's clinical or case data into another person's record entirely. A well-tuned EMPI is explicitly tuned to keep both error rates low, with a human review queue for the genuinely ambiguous matches.
Commercial EMPI platforms exist, and for large integrated delivery networks they're often the right call. But for public health agencies and mid-sized health systems, the licensing model — typically priced per managed record or per connected system — gets expensive fast, and the quote is rarely public until you're deep in procurement.
The open-source alternative built on OpenCR (Open Client Registry) paired with a HAPI FHIR server gives you the same core capability — probabilistic matching, a persistent Patient resource per unique identity, and a FHIR-native interface that every modern interoperability tool already knows how to talk to — without the per-record licensing model. You configure the matching algorithm's weights and thresholds to your own data quality, rather than accepting a vendor's black-box tuning.
OpenCR and HAPI FHIR are the software layer, not a hosting decision. Self-managed servers work fine for smaller deployments. For agencies already standardizing on Azure, the same stack runs on Azure Health Data Services (AHDS) — a managed FHIR service that removes the server-patching burden while keeping the same open matching engine underneath, so you're not trading the licensing savings for an ops burden nobody signed up for.
Done right, this isn't a multi-year enterprise procurement project. A properly scoped EMPI build for a health department or mid-sized system is a matter of weeks to a few months, not the 12–18 month timelines commercial vendors often quote — largely because you're not waiting on a vendor's implementation team's calendar.
Working on something like this?
Talk to usNeither standard is going away. Here is what each is actually good at, and where most organizations get the transition wrong.
Ask a vendor sales deck and you'd think HL7v2 is a relic and FHIR has already replaced it. Ask anyone who actually runs interface engines in production, and the picture looks different: HL7v2 still carries the overwhelming majority of real-time clinical messaging traffic — lab results, ADT feeds, orders — in the U.S. today, and it will for years. FHIR is winning the newer ground: APIs, patient access, bulk data exchange, and the CDC's public health modernization push. Any real interoperability strategy has to support both, translating between them, not picking one and hoping the other disappears.
| Dimension | HL7v2 | FHIR |
|---|---|---|
| Transport model | Message-based, typically over MLLP/TCP | RESTful API over HTTP(S), resource-based |
| Data model | Pipe-delimited segments, loosely standardized | Structured JSON/XML resources with defined schemas |
| Strength | Mature, near-universal EHR/lab support, real-time ADT and results | Modern APIs, granular queries, bulk data export, app ecosystem |
| Where it dominates | Hospital ADT feeds, lab interfaces, existing legacy pipelines | Patient access APIs, registries, public health case reporting (eCR) |
The most common mistake is treating a FHIR migration as a lift-and-shift: standing up a FHIR server and expecting existing HL7v2-speaking systems to just start talking to it. They won't. The realistic architecture is a conversion layer — HL7v2 messages get transformed into FHIR resources (and back, when needed) at the interface engine, so legacy systems keep speaking the protocol they already speak while anything new is built FHIR-native.
This is exactly the pattern behind electronic case reporting (eCR), which most public health agencies are now standing up under CDC's Data Modernization Initiative: EHRs generate an eICR (electronic Initial Case Report) as a FHIR/CDA document, it routes through AIMS or a similar platform, and the case data ultimately needs to reconcile against systems that are often still HL7v2 underneath.
Commercial interface engines (Rhapsody, Cloverleaf, and similar) handle this translation well, but license per interface or per connection — and that cost compounds as your integration count grows. The open alternative uses tools like Microsoft's FHIR Converter or open HL7v2-to-FHIR mapping libraries running on Azure Health Data Services or a self-hosted equivalent, giving you the same transformation capability without a per-connection fee attached to every new system you bring online.
If a system already exists and works, leave it speaking HL7v2 and translate at the boundary. Build anything new — patient-facing apps, registries, analytics pipelines — FHIR-native from the start. Don't force a legacy lab interface into a FHIR rebuild just because FHIR is newer; that's cost and risk with no real benefit.
The right answer, for most public health and healthcare organizations right now, is a hybrid pipeline built on open standards and open tooling — not a bet on either format winning outright.
Working on something like this?
Talk to usFaxed lab results and scanned PDFs still run huge parts of public health and clinical reporting. Here is how to actually get structured data out of them.
It's a persistent surprise to people outside public health and clinical operations just how much reporting still arrives as a fax or a scanned PDF. Reportable lab results, especially from smaller labs and clinics without electronic lab reporting (ELR) set up, routinely land as unstructured documents that a human then has to read and manually key into a case management or surveillance system. That manual step is slow, error-prone, and doesn't scale when volume spikes — exactly when you need it to.
This isn't classic OCR that just converts an image to a blob of text. Modern document intelligence — tools like Azure Document Intelligence — combines OCR with layout understanding and field extraction: it recognizes that a document is a lab report, finds the patient name field, the test name, the result value, the reference range, and the ordering provider, and returns them as structured key-value data rather than a wall of unstructured text you'd still have to parse.
The right design isn't "AI extracts everything, humans check nothing" or "AI does nothing, humans key everything." It's a threshold: fields the model is highly confident about auto-populate, fields below a confidence cutoff get flagged for a human to confirm or correct. That threshold should be tunable per field type — a misread patient name is a bigger problem than a misread specimen collection time.
Commercial document-processing SaaS platforms typically price per document processed, often with a platform or per-seat fee layered on top of that. For an agency processing thousands of documents a month, that adds up fast and scales with volume rather than staying flat.
Building on Azure Document Intelligence directly — at published consumption rates, roughly $1.50 per 1,000 pages for prebuilt OCR up to around $30 per 1,000 pages for custom extraction models — means you're paying cloud consumption pricing for the actual processing, with no seat licenses and no platform markup. The tradeoff is that someone has to build and maintain the pipeline logic (validation rules, routing, export mapping) instead of getting it bundled into a SaaS product. For most public health agencies, that build is a matter of weeks, and it's a system you own outright afterward rather than renting indefinitely.
Document intelligence isn't a standalone project — it's most valuable when it feeds directly into the same EMPI and FHIR interoperability layer handling your electronic data. A lab result extracted from a fax should resolve to the same patient identity, and land in the same downstream systems, as a result that arrived electronically. Built in isolation, a document intelligence pipeline is a nice demo. Built as part of the broader data infrastructure, it closes a real operational gap.
Working on something like this?
Talk to usBeyond the license line item — what open-source healthcare infrastructure actually costs to run, and where commercial platforms genuinely earn their price.
"Open source" in healthcare IT conversations tends to get treated as either a magic cost-cutting word or a red flag for organizations worried about support and compliance. Neither reaction is accurate. The honest answer is category-dependent: some parts of the healthcare IT stack have mature, production-grade open-source options that genuinely outperform commercial platforms on cost with no meaningful capability gap. Others don't, and paying for a commercial platform is the right call.
| Category | Typical Commercial Pricing Model | Open-Source Alternative |
|---|---|---|
| EMPI / Master Patient Index | Per-record or per-connected-system licensing, opaque until deep in procurement | OpenCR / HAPI FHIR — self-hosted, no per-record fee |
| FHIR server / repository | Vendor-hosted platform with per-transaction or subscription pricing | HAPI FHIR self-hosted, or Azure Health Data Services (consumption-based) |
| Interface engine (HL7v2/FHIR) | License plus per-connection fee | Custom pipeline on open mapping libraries — you own the pipeline |
| Data lake / analytics platform | Per-seat BI licensing on top of storage/compute costs | Cloud-native data lake (Azure/AWS) with open query tooling |
This matters as much as the wins column. Large integrated delivery networks running enterprise EHR platforms with deep clinical workflow integration are generally better served staying on commercial platforms — the switching cost and clinical risk of replacing a functioning EHR with an open-source alternative almost never pencils out. Similarly, organizations without any internal technical capacity to maintain infrastructure are often better off paying a vendor for a fully managed platform than taking on an open-source stack they can't support in-house.
The honest framing: open source shifts cost from license fees to implementation and operational labor. If you have — or can contract for — that labor, the total cost of ownership usually comes out ahead. If you don't, a commercial platform's support contract is buying you something real.
Commercial healthcare IT quotes rarely include the true multi-year cost: the base license, annual maintenance (typically 18–22% of license cost per year), professional services for implementation, and the "premium tier" upsell that shows up once you're locked in. An honest open-source comparison has to account for its own multi-year cost too — implementation labor, ongoing administration, and infrastructure — not just compare a license fee against "free."
Neither "always open source" nor "always commercial" is a strategy — it's an excuse to skip the analysis. The organizations getting real cost savings are the ones running category-by-category, honest to themselves about their own operational capacity.
Working on something like this?
Talk to usA grounded look at practical AI applications in healthcare infrastructure — no hype, no "AI platform" markup.
Healthcare IT is currently flooded with "AI-powered" marketing attached to products that would have been described the exact same way, minus the AI label, two years ago. That noise makes it harder, not easier, to figure out where AI genuinely improves healthcare infrastructure operations versus where it's a markup on an existing capability. Here's a grounded rundown, organized by what actually holds up in production.
This is the clearest win. Extracting structured fields from lab reports, faxes, and clinical paperwork — patient identifiers, test results, dates — is a task modern document intelligence models handle well, with measurable confidence scores that let you route uncertain extractions to a human rather than guessing. This isn't speculative; it's running in production pipelines today at a fraction of the cost of manual data entry.
Probabilistic patient matching for EMPI systems has used statistical scoring for years. The useful new pattern isn't replacing that scoring — it's layering a smaller-weighted, explainable AI step on top of it. A matching engine we've built runs exact-identifier matching (SSN, MRN, DOB, phone) and fuzzy name/address scoring (Jaro-Winkler, Soundex) as the primary signal, then adds a semantic embedding comparison plus an LLM pass that returns an actual written reason alongside its score — something like "names match exactly, DOB differs by what looks like a transposed month and day." Records scoring above a high threshold auto-link; a middle band queues for a human reviewer who reads the model's stated reasoning instead of a bare number; anything below that stays separate. The AI doesn't get the final word on a merge — it gets a vote and a paper trail a reviewer can actually evaluate.
In practice this shakes out into three bands: a high-confidence tier that auto-links without a human touching it, a middle band that lands in a review queue with the model's reasoning attached, and a low-confidence tier treated as separate records by default. The thresholds are tunable, but the shape — auto-act only at the top, explain-and-defer in the middle, do-nothing at the bottom — is the part worth copying regardless of which specific matching stack you're running.
Routing incoming documents, flagging anomalies in surveillance data feeds, summarizing long case notes for a reviewer, drafting first-pass responses to routine data requests — these are all tasks where AI reduces the volume of low-value manual work without being the decision-maker on anything clinical or high-stakes.
Not "is it AI-powered" — nearly everything claims that now. Ask instead: what specific task does the model perform, what's the failure mode when it's wrong, and what's the human review step before that output reaches a patient record or a compliance-relevant decision. If a vendor can't answer that clearly, the "AI" label is doing marketing work, not engineering work.
Practical AI workflows in healthcare IT need to run inside the same regulatory guardrails as everything else — HIPAA-compliant infrastructure, audit logging on every AI-assisted decision, and a clear human-review checkpoint before AI output becomes an operational action. That's an infrastructure and process problem as much as a model-selection problem, and it's usually the part vendors gloss over in the demo.
The organizations getting real value from AI in healthcare IT right now aren't the ones chasing the newest model — they're the ones that picked two or three genuinely well-suited tasks (document extraction, data quality flagging, operational automation) and built the review workflow around them properly.
Working on something like this?
Talk to usHow to get properly managed REDCap infrastructure without the per-project pricing model that punishes active research programs.
REDCap is free to license through Vanderbilt's consortium for qualifying institutions — but "free to license" doesn't mean "free to run." Someone still has to provision the server, configure SSL, keep PHP and MySQL patched, manage the DEV/TEST/PROD pipeline, and handle the HIPAA-relevant infrastructure controls. That gap is where commercial hosting options like REDCap Cloud step in — and where their pricing model becomes a real constraint for active research programs.
REDCap Cloud and similar platforms typically price per active project, which means your infrastructure cost scales directly with your research output. A program running five studies pays roughly five times what a program running one study pays, even though the underlying server infrastructure required doesn't scale linearly at all. For institutions actively growing their research portfolio, that pricing model works against the exact behavior — launching more studies — that the institution wants to encourage.
The alternative is managed infrastructure priced on server tier and support level, not project count. One properly configured REDCap environment can run unlimited projects at no additional cost, because the constraint was never "how many projects" — it was "how much server capacity and administrative attention." A managed provider handles:
Is pricing per-project, per-server, or flat-rate? What's included in "support" — is it infrastructure only, or does it include REDCap application-level help? Who executes the BAA, and does the provider have zero access to your actual REDCap data, in line with the consortium license terms?
For institutions where REDCap is one piece of a broader research and public health data infrastructure — sitting alongside data lakes, interoperability pipelines, or EMPI systems — the case for flat-rate managed infrastructure gets even stronger: it's one predictable line item instead of a cost that grows every time a new study launches.
Working on something like this?
Talk to usWhat nonprofit research and program-evaluation teams actually need from REDCap infrastructure — and where the budget actually goes.
Nonprofits running program evaluation, grant-funded research, or public health data collection are exactly the kind of organization REDCap was built for — and exactly the kind of organization that gets priced out of commercial hosting options built around enterprise research budgets.
REDCap itself is free for qualifying nonprofit, academic, and government organizations through Vanderbilt's consortium license. Eligibility generally requires a signed institutional agreement and a designated REDCap administrator — it doesn't require an enterprise IT budget to qualify.
The cost isn't the software — it's the infrastructure and administration: a properly configured server environment, HIPAA-aligned controls if you're handling any PHI, and someone who actually understands REDCap administration rather than generic web hosting. Generic shared hosting technically "works" but usually fails HIPAA requirements and lacks the DEV/TEST/PROD pipeline that responsible REDCap administration requires.
Flat-rate managed REDCap hosting for a nonprofit running a handful of active studies typically falls in a modest monthly range — well below what per-project commercial platforms charge once a program has more than one or two active studies running simultaneously. Get an actual quote rather than budgeting off list pricing; provider pricing varies more than the marketing pages suggest.
Research grants commonly include a line item for "data management infrastructure" — REDCap hosting belongs there. Building a realistic infrastructure cost into the grant proposal from the start avoids the scramble later of finding budget for something that should have been planned for at the proposal stage.
For nonprofits doing public health or clinical research work that will eventually need to connect to broader systems — a state immunization registry, a case management platform, an EMPI — it's worth asking a hosting provider upfront whether they can also support that interoperability layer, rather than treating REDCap hosting and everything else as separate procurements down the line.
Working on something like this?
Talk to usThe questions that actually separate a properly managed REDCap environment from a generic web host running REDCap.
Anyone can install REDCap on a server. Whether that server is actually configured for the compliance requirements and operational realities of running research data infrastructure is a different question entirely — and one a sales pitch won't answer for you. Here are seven questions worth asking directly.
Responsible REDCap administration runs at minimum DEV, TEST, and PROD environments, so instrument changes get tested before they touch live study data. A provider offering only a single production environment is cutting a corner that eventually costs you a corrupted live project.
A Business Associate Agreement should be standard, not an add-on. Ask specifically what infrastructure it covers — server, backups, network — and confirm in writing that the provider has zero access to your actual REDCap data, consistent with the consortium license terms.
This phrase gets used loosely. Ask for specifics: encryption at rest and in transit, access logging, backup encryption, and what their incident response process looks like if something goes wrong.
Per-project pricing punishes exactly the growth you want as a research program. Understand the pricing model before you're locked into a study count that determines your monthly bill.
REDCap ships regular updates, some with security implications. Ask how upgrades are scheduled, tested, and communicated, not just whether they happen "eventually."
Get this in writing, not as a verbal assurance. A downed REDCap environment during active data collection is a real operational emergency, not a ticket that can sit for three days.
If your research program is likely to eventually need FHIR interoperability, an EMPI connection, or a data lake feeding downstream analytics, ask whether the provider can support that or whether REDCap hosting is a dead-end silo you'll have to re-architect around later.
Anyone selling REDCap hosting can answer question 1 and 2. Very few can answer questions 6 and 7 credibly, because most REDCap-only hosting providers have never actually built the broader interoperability layer research data eventually needs to connect to.
Working on something like this?
Talk to usInfrastructure, BAA, and administrative safeguards — what real HIPAA compliance for REDCap looks like in practice.
"HIPAA compliant" gets attached to hosting products as a checkbox marketing claim more often than it gets explained as an actual set of technical and administrative controls. For a REDCap environment handling PHI, here's what actually has to be in place.
A BAA between your institution and the hosting provider is not optional if PHI is involved — it's required. It should explicitly define what the provider can and can't do with the data, and under the REDCap consortium license terms, a proper hosting provider should have zero direct access to the actual data stored within your REDCap instance, full stop.
HIPAA compliance isn't purely a technical property of the server. It also requires:
It's rarely the encryption configuration that trips up a compliance review — that part's usually fine. It's stale user access (former staff still holding active accounts), missing or outdated BAAs, and undocumented incident response processes. The technical controls are necessary but not sufficient.
Institutions running FDA-regulated trials need REDCap configured for 21 CFR Part 11 as well — electronic signatures, audit trails on every data change, and validated system documentation. This is a materially higher bar than baseline HIPAA compliance and should be scoped explicitly if any of your studies fall under FDA oversight.
Working on something like this?
Talk to usWhat the license actually is, who qualifies, and how the process works from first inquiry to a working instance.
REDCap is often described as "free," which is true but incomplete — it's free to license for qualifying organizations through Vanderbilt University's REDCap Consortium, not freely available for anyone to download and deploy commercially.
The consortium license is intended for non-profit, academic, government, and healthcare institutions conducting research or related data collection — not for-profit commercial use. Qualifying organizations sign an institutional agreement directly with Vanderbilt, and each institution designates a REDCap administrator responsible for the local instance.
The license covers the software, not the infrastructure it runs on. Vanderbilt doesn't host your instance or provide server infrastructure — your institution is responsible for provisioning, securing, and maintaining the actual server environment, whether that's done in-house or through a managed hosting provider.
Researchers and administrators affiliated with more than one qualifying institution sometimes run into flags around dual REDCap accounts under the consortium's compliance monitoring. If you're supporting REDCap across multiple institutions — as an independent consultant, for example — it's worth proactively clarifying your affiliation structure with the consortium rather than letting it surface as a compliance question later.
Getting the license is the first step, not the whole project. What comes next — provisioning a proper DEV/TEST/PROD environment, HIPAA-aligned infrastructure controls, and (for FDA-regulated studies) 21 CFR Part 11 configuration — is where most of the real technical work happens, and where institutions without dedicated IT capacity typically bring in a managed infrastructure partner.
Working on something like this?
Talk to usBehind every case report is an investigator waiting on data. We build and run the systems that get it to them faster, on infrastructure their own agency owns.
Kapstone is led by a cloud and systems architect with more than 25 years in infrastructure, from building out data centers and running Linux hosting to state public health data modernization on Azure.
Every engagement is delivered by a senior engineer. Microsoft Azure and AWS SysOps certified.
The Rod of Asclepius, one serpent on a staff, is the traditional symbol of medicine. It's here because so much of what we build serves public health: the investigators, epidemiologists and nurses who keep communities safe.