Automating medical data processing with N8N & AI (PoC)

1. Business Context: What Does the Client Do?

The client acts as an intermediary for law firms and insurance companies. Its main task is to manage the collection of complete medical and legal records.

What does their day-to-day work look like? The client’s process includes coordinating and monitoring external companies. It works like this:

1. Order Intake: Our client receives a task from its client (e.g., an insurer or a law firm) to collect the medical documentation of a specific individual.

2. Task Delegation: The client identifies potential data sources and commissions specialized copy services companies to acquire them.” It is the copy service companies that are responsible for directly contacting hospitals or clinics to actually get the documents.

3. Monitoring and Follow-up: The key, ongoing task for our client’s employees is to constantly monitor the status of orders and regularly contact copy service companies to get updates and speed up the process.

4. Finalization: After receiving the documents from the document retrieval companies, our client verifies them and delivers them to its client (as mentioned earlier, for example, an insurer or a law firm).

The entire process is then largely based on relationship management and intensive communication with external vendors.

2. The Problem and Project Context

The Process Bottleneck. The client came to us with a fundamental problem – their operational process was manual, slow, and difficult to scale. The biggest “bottleneck” was the stage of managing communication with multiple copy service companies and constantly monitoring for responses (follow-up). Employees spent most of their day performing the same, repetitive tasks, which generated a risk of errors and limited the number of cases they could handle.

Four Key Stakeholders. Within the context of the entire business process and the project itself, there four key stakeholder groups:

• End Client (A): Our client – the company that commissions and coordinates documentation acquisition – is the target user and main beneficiary of the automation.

• Intermediary Client (B): The company that commissioned the project to us and managed the relationship with End Client (A).

• Vendor (us – Pragmatic Coders): The development team responsible for creating the solution.

• Copy service companies: External entities collect documents from medical facilities and send them to End Client (A). Our automation focused on improving how End Client (A) communicates with them.

  • In American medical industry practice, the term “copy service” is used as industry slang for companies specializing in obtaining and copying medical records — typically on behalf of healthcare providers, law firms, insurance companies, and patients. The official term for such companies is Medical Record Retrieval Service and derivates, but we’ll stick to copy service for the sake of clarity.

The agreement didn’t allow direct contact with the End Client (A). Later, this was fully blocked, becoming a key challenge.

3. Project Objective

The objective was to create a Proof of Concept (PoC) – a working prototype to prove that intelligent automation could eliminate the bottlenecks.

Anticipated outcomes:

• Technical validation: Integration with Quickbase and email, and the automation of key steps.

• Demonstration of business value: Showing the benefits that a full implementation would bring.

The declared benefits (if the company chose to turn the PoC into a real product) were faster email and reminder handling, better efficiency, fewer data entry errors, and a solid base for further automation.

4. Proposed Solution and Architecture

We proposed creating an intelligent automation agent using technologies that allow for rapid prototyping and secure data processing.

Solution Architecture

• Process Orchestration (n8n): A self-hosted n8n instance for modeling and running workflows.

• Natural Language Processing (LLM): A locally hosted LLaMA model (via Ollama). Using a small model (~10B parameters) helped reduce server costs.

• Infrastructure (AWS): Two EC2 instances – one for n8n and one for the LLM.

• Integrations: Quickbase API as the central database and Microsoft Graph/Outlook API (OAuth2) for email handling.

• UI and Testing: A dedicated tab in Quickbase for manually triggering actions, monitoring errors, and statuses; a 1:1 copy of the Quickbase application for testing.

Scope of Automation

• Downloading data from Excel files and saving it to Quickbase.

• Sending emails to the copy service companies to acquire documents.

• Monitoring responses approximately every 2 weeks, classifying statuses (duplicate, no records, docs received).

• Email follow-up if documents are not received.

• Using the LLM to extract the unique case number (Work Order Number) from unstructured emails.

5. Challenges

Communication and Ownership:

The setup with the intermediary didn’t allow direct contact with the end client, which slowed down decisions Later, a new Product Owner and technical manager joined on the client’s side, and priorities had to be set again.

Technology and Licenses:

• The project revealed that for a collaboration model involving an intermediary → end client, a commercial n8n license is necessary, which we included in our further recommendations.

• The need to process medical data required local hosting of the LLM and rigorous security controls.

Automation Specifics: The lack of a classic frontend/backend separation required a non-standard approach to test environments and error handling on our side.

6. Conclusions (Lessons Learned)

• Direct communication is essential. Without it, delays and confusion are almost unavoidable.

• The value of a PoC. The PoC proved low-cost automation was possible and showed key risks: communication, organization, and licensing.