Portfolio / Case study

Case study · Legal and healthcare AI

An AI assistant is only as good as what it reads.
We built what it reads.

An AI platform for lawyers and clinicians needed each practice’s own records: clients and patients, cases, notes, test results. They lived in systems that were never designed to talk to each other, let alone to an AI. We built the layer that brings them in, makes them consistent, and makes them safe to act on.

Legal services · AI systems · Platforms & migrations

Domains

Legal + health

Case-management, practice, health-record and wellness systems, each with its own idea of a contact, a note or a result.

Plus CRM data.

Protocols

REST · SOAP

JSON and XML, OAuth2, API keys and webhooks, each kept behind its own adapter.

The rest of the platform never needs to know which system a record came from.

Data model

One

One typed, validated model for practices, people, notes and results, checked on the way in.

A malformed record fails loudly instead of quietly polluting the assistant’s context.

Client, product, systems and vendors withheld, and no client figures. Our part was the integration and data layer. The assistant, its agents, orchestration, search and retrieval belonged to the platform team, and we worked within them.

How we built it

Five stages,
the same on every project.

Ingestion

Get the real data in, from where practices actually work

The challenge

  • Every practice kept its records in a different system
  • Each system spoke its own dialect: REST here, SOAP and XML there
  • Authentication differed everywhere: OAuth2, API keys, webhooks

What we did

  • One adapter per source system, handling its authentication, paging and quirks, and nothing else
  • Ingestion of contacts, cases, patients, notes and test results
  • Every call logged with a correlation ID

The starting point was each practice’s real records, not a demo dataset.

Normalization

Make incompatible records mean the same thing

The challenge

  • A “contact”, a “note” or a “result” meant something different in every system
  • Identifiers, formats, timestamps and terminology didn’t match
  • Bad data would have reached the assistant silently

What we did

  • One typed, validated model for every kind of record, enforced at the boundary
  • Resolvers that map each source’s fields and identifiers into it
  • Records that don’t fit are rejected and logged, never passed on

Sophisticated AI on unreliable context still gives unreliable answers. This layer is where that is prevented.

Trust

Make the data safe to act on

The challenge

  • Legal and health records are among the most sensitive data there is
  • A successful API call is not the same as correct data
  • Downstream teams needed to know they could rely on every record

What we did

  • Validation on the way in, and structured errors when something is wrong
  • Access control, credential handling and separation between practices
  • End-to-end tests across the integration paths

HTTP 200 doesn’t mean the result can be trusted. The checks do.

Value

Give the assistant context worth answering from

The challenge

  • The assistant’s answers depend on the quality of what it retrieves
  • Practitioners act on what the assistant tells them

What we did

  • Clean, consistent, current records, delivered in one shape to the platform’s search, retrieval and agents

The goal was never “connect to everything”. It was answers a lawyer or clinician can rely on.

Production

Keep it working when the other side doesn’t

The challenge

  • External systems throttle, time out, change without notice and return inconsistent data

What we did

  • Retries and timeouts on every call
  • Circuit-breaker and rate-limit patterns, so one failing source can’t take the rest down
  • Structured logs to follow any record from source to assistant

Built for the day a source fails, because that day always comes.

Who owned what

Our part,
stated exactly.

The platform

A wider product, one clear layer.

LayerWhat it doesOwned by
IntegrationsConnects to each practice’s legal, health, wellness and CRM systemsEVDevs
Ingestion and normalizationBrings records in and turns them into one validated modelEVDevs
ReliabilityRetries, circuit breakers, rate limits, traceable logsEVDevs
Search and retrievalFinds the right context for each questionPlatform team
Assistant and agentsAnswers practitioners and orchestrates the workPlatform team

Everything above the data layer depends on it. That is why we treat it as the foundation, not plumbing.

What it proves

Trustworthy AI starts
below the model.

Failure

Contained

One slow or failing source can’t take the others down.

Retries, timeouts, circuit breakers and rate limits on every call.

Traceability

End to end

Any record can be followed from its source system to the assistant’s context.

Structured logs with correlation IDs.

Sensitive data

By design

Access control, credential handling and separation between practices were engineering requirements, not paperwork.

Built to HIPAA, SOC 2 and GDPR expectations.

How we work

  1. Start from the real data

    We work from the systems where the business actually operates, not from a clean sample.

  2. Normalize before you model

    One validated shape for every record, so the AI never has to guess what a field means.

  3. Check, don’t assume

    Validation, tests and traceable logs, because a successful request is not a correct answer.

  4. Build for failure

    Every external system will fail one day; the platform has to keep working when it does.

Building AI on data
you don’t fully trust yet?

Tell us where your records live and what your AI needs to answer. We will tell you what it takes to make that data trustworthy, and what the next practical step could be.

Prefer to write directly? enable JavaScript to see the address

Talk to an engineer

No sales theater. Tell us where your operation feels slow, repetitive, or difficult — an engineer reads every message.

Your message goes straight to our engineers at our address.