AI Solutions · Legacy Modernization · Healthcare
AI that clears security, privacy, and the compliance review.
We build AI systems for healthcare and other regulated organizations that cannot send PHI or PII to a public API, and we modernize the legacy applications those organizations still run on. Agents grounded in your own data, a governance framework your team can operate, and delivery people who have shipped both.
Recent delivery
In production
AI agents on Snowflake that answer plain-English questions against governed enterprise data, and pull answers out of the documents and datastores behind it. Built, deployed, and running today.
In flight
A legacy on-prem regulated system for a healthcare company, rebuilt on a modern stack and moving to the cloud.
We work inside your boundary: Snowflake Cortex, Azure OpenAI or AWS Bedrock in your own tenant, or open weight models on hardware you control.
What we do
Four things, done properly.
Most AI programs stall in one of two places: the pilot cannot pass a security review, or nobody can say who approved it. We work on both ends.
AI agents grounded in your own data
Ask a question in plain English and get an answer from your own systems. Two halves: the numbers in your warehouse, and the unstructured documents nobody has time to read through — contracts, agreements, policies, protocols, SOPs. Every answer cites the record or the paragraph it came from. The agent inherits your access model, so it cannot surface anything the person asking is not entitled to see.
AI governance and operating framework
The intake process, risk tiering, model and vendor policy, evaluation gates, and monitoring that turn scattered AI pilots into a program your board and compliance team can sign off on. Written so your team can run it without us.
Legacy application modernization
On-prem systems that are expensive to run and hard to hire for: QMS, LIMS, document control, custom Oracle Forms, VB and Access, older .NET and Java. Rebuilt on a modern stack, deployed to AWS or Azure, without a big-bang cutover.
PHI and PII safe architecture
De-identification and tokenization where it fits, private networking and no-retention endpoints where it does not. Every prompt, retrieval, and tool call logged so you can answer an audit question months later with evidence rather than recollection.
PHI and PII
Your data does not have to leave your boundary.
On-prem is a constraint, not a blocker. There are four patterns that work, and the one we pick depends on your data classes and your risk appetite, not on a vendor preference.
Inside your data platform
Models run next to the data in Snowflake Cortex or Databricks. No egress, no new data copy, and your existing row and column level security still applies.
Inside your cloud tenant
Azure OpenAI or AWS Bedrock behind private endpoints in your own subscription or account. Your prompts are not used for training, and the traffic never crosses the public internet.
On hardware you control
Open weight models (Kimi K3, Llama, Mistral, Qwen) served on your GPUs, in your data center or a private VPC. The option that survives the strictest reading of your data policy, including fully disconnected.
De-identified by default
Where the use case allows, PHI never enters the model at all. Safe Harbor or Expert Determination de-identification up front, with tokenized re-identification only where clinical or operational need requires it.
AI governance
A framework you can actually operate.
Not a forty page policy that goes stale in a quarter. A small number of decisions, written down, with the process and artifacts to back them up.
Mapped to NIST AI RMF and ISO/IEC 42001, and aligned to your existing HIPAA Security Rule controls so it fits the governance you already run rather than sitting beside it.
Use case intake and risk tiering
One front door for AI requests, with a short intake that classifies each use case by data sensitivity, autonomy, and clinical or financial impact. Low tier ships fast. High tier gets the full review. Nothing goes live without a tier.
Model, vendor, and data policy
Which models are approved for which data classes, what has to be in the contract (BAA, retention, training rights, sub-processors), and what is simply not allowed. Short enough that people actually read it.
Evaluation gates before go-live
Every use case has an eval set and a pass bar defined before build starts: groundedness, citation accuracy, tool-call correctness, refusal behavior on out-of-scope questions. If it cannot be measured, it does not ship.
Human oversight sized to the risk
Approval steps, confidence thresholds, and reviewer workflows scaled to the tier. Anything touching patient care, billing, or a regulator gets a human decision point, and every override is captured.
Monitoring, drift, and incident response
Production traces, quality metrics that keep running after launch, cost and latency budgets, and a defined path for what happens when an AI system gets something wrong, including who is notified and how it is rolled back.
Audit evidence by default
Use case inventory, risk decisions, eval results, approvals, and production traces are captured as the work happens. When an auditor or your board asks who approved what and on what evidence, the answer is a record rather than a recollection.
Legacy modernization
Off the old system without a big-bang cutover.
The systems that are hardest to replace are the ones nobody fully understands anymore. We start there, and we keep the old system running until the new one has earned the traffic.
- 1
Assess what it really does
Legacy systems rarely match their documentation. We read the code, trace the data, and interview the people who work around the gaps, then write down the actual behavior and the rules worth keeping.
- 2
Rebuild in slices
Strangler pattern. The new system takes over one module at a time behind a routing layer, so users move gradually and you always have a working system to fall back to.
- 3
Migrate data with evidence
Reconciliation counts, checksums, retention rules, and a preserved audit trail. In regulated systems the history matters as much as the current state, and we treat it that way.
- 4
Validate and cut over
Parallel run against the legacy system, documented test evidence (IQ, OQ, PQ where the system is validated), a rehearsed rollback, and hyper-care after go-live.
Where this works
Use cases we deliver against.
- Ask-your-data agents for finance, supply chain, quality, and operations teams
- Policy, protocol, and SOP search grounded in your own document library
- Revenue cycle document work: prior auth packets, denials, appeals drafting
- Chart and record summarization with a clinician or coder in the loop
- Contact center and patient access copilots with human review on every send
- Quality management, CAPA, and document control moved off aging on-prem systems
- Custom legacy apps (Oracle Forms, VB, Access, older .NET and Java) rebuilt on cloud
- AI readiness and governance framework for a first enterprise-wide rollout
Our stack
Vendor neutral, chosen for your constraints.
We pick what fits your data, your controls, and the team that has to run it after we leave.
Models & platforms
- Claude Opus 5 and Sonnet 5 for agents, reasoning, and tool use
- Claude Fable 5 for the hardest long-horizon work
- Azure OpenAI, AWS Bedrock, Snowflake Cortex inside your own tenant
- Kimi K3, Llama, Mistral, Qwen on your GPUs for on-prem or air-gapped
Retrieval (RAG) & data
- Hybrid BM25 plus vector search with cross-encoder reranking
- Snowflake vector, pgvector, and platform-native indexes
- Document parsing for PDFs, scans, and structured forms
- HL7 v2 and FHIR interfaces, DICOM metadata, HIE and claims feeds
Governance & assurance
- Eval harnesses and calibrated LLM-as-judge scoring
- PHI and PII redaction, prompt injection filters, output policy checks
- Model registry, use case inventory, and risk tier records
- OpenTelemetry and Langfuse tracing across prompts, retrieval, and tools
Modernization
- .NET, Java, Python, and React on a supported, hireable stack
- Containers on AKS, EKS, or ECS with Terraform and CI/CD
- PostgreSQL and SQL Server, with migration and reconciliation tooling
- AWS and Azure landing zones built to HIPAA-aligned controls
How we engage
Start small, prove it, then scale.
- 1
Readiness review
A short, fixed-scope engagement: use case inventory, PHI and PII data map, risk tiers, and a prioritized gap list. You keep the output whether or not we do the build.
- 2
Framework
Policy, intake, risk tiering, eval gates, and the committee charter, sized to your organization. Documented so your team can operate it independently.
- 3
Pilot
One high-value use case to production inside your boundary, with evals, guardrails, and audit logging from day one. Weeks, not quarters.
- 4
Scale or modernize
Additional use cases under the same framework, or the legacy modernization program. Runbooks, documentation, and ownership handed to your team.
FAQ
Questions we get first.
Usually from security and compliance, before the business case is even on the table.
Our data cannot leave our network. Does that rule out AI?
No. It rules out a handful of deployment patterns, not the capability. We regularly run models inside the customer's data platform, inside their cloud tenant behind private endpoints, or as open weight models on hardware they control, including fully disconnected. We choose the pattern after we understand your data classes, not before.
We do not have an AI governance framework yet. Where do we start?
With an inventory and a risk tiering rule, not a policy document. Most organizations already have more AI in the building than they realize, in point solutions and vendor features. We start by finding it, classifying it, and putting a single intake path in front of what comes next. The written policy follows from that and is much shorter than teams expect.
How do you stop an agent from surfacing data a user should not see?
The agent runs as the user, not as a service account with broad rights. Retrieval and SQL execution inherit your existing row and column level security, so an unauthorized record never enters the context window in the first place. That is enforced in the data platform rather than in a prompt, because prompts are not an access control mechanism.
Can you modernize a system that is validated or under regulatory scrutiny?
Yes, and it changes how we sequence the work rather than whether we do it. Validated systems need documented requirements traceability, test evidence, preserved audit history, and a parallel run before cutover. We plan for that from the start instead of discovering it during the compliance review.
Do we have to commit to one model vendor?
No, and we would advise against it. We build behind an abstraction so the model is a configuration choice per use case. Some tasks belong on a frontier model, some run better and cheaper on a small open weight model on your own hardware, and the right answer changes every few months.
How do you handle PHI and PII in an engagement?
Under your BAA and your access process, with the minimum necessary standard applied to what our engineers can reach. Wherever the use case allows, we work against de-identified or synthetic data during build and only touch live PHI or PII in your environment, with logging on.
Also from Metanlytics
Need the engineers embedded with your team instead?
Our Forward Deployed Engineers practice places senior Gen AI engineers directly into your team and your repo, working the same delivery standard as the work above.
Let us help you move faster
Need talent, advisory, or a delivery partner? Start a conversation.
Tell us what you are building, hiring for, or still figuring out. We will respond with a clear next step, even if that is a short advisory conversation rather than a project.