USING IRON SUITE

How a Healthcare Platform Built a Scalable Document Conversion and PDF Generation Pipeline

Updated:

How a Healthcare Platform Built a Scalable Document Conversion and PDF Generation Pipeline

Healthcare-adjacent software lives or dies by its documents. When an enterprise platform in the medical-device space needed reliable RTF-to-PDF conversion and server-side PDF generation on AWS-hosted Linux containers, it built a five-stage asynchronous pipeline around IronPDF, licensed within IronSuite for broader document-processing coverage. This walkthrough reconstructs the entire architecture.

TL;DR: Quickstart Guide

  • Who this is for: Solution architects and senior .NET engineers evaluating a document-processing library for healthcare-adjacent or otherwise regulated platforms, where conversion fidelity must be proven on real documents, on the target infrastructure, before any license commitment is made.
  • What you'll build: A five-stage document pipeline (ingest, convert, generate, validate, and deliver) with IronPDF embedded in asynchronous workers that handle RTF-to-PDF conversion and HTML-templated PDF generation behind a thin document API.
  • Where it runs: AWS-hosted Linux containers with rendering dependencies baked into the image. The same architecture applies to any server-side .NET environment, but Linux dependency handling is treated as a first-class design input here.
  • When to use this approach: When document handling underpins your application's core processing, inputs arrive as legacy RTF alongside HTML and images, and output PDFs feed both internal systems and customer-facing portals that cannot tolerate silent conversion failures.
  • Why it matters technically: Conversion and rendering are CPU-heavy, IO-heavy, and bursty. Isolating them in horizontally scalable workers protects API latency, and fail-closed validation stops low-fidelity output before it reaches downstream systems.

The pipeline's primary entry point is RTF conversion through ChromePdfRenderer. The simplest meaningful invocation, one source document in and one PDF out, looks like this:

using IronPdf;

var renderer = new ChromePdfRenderer();

PdfDocument pdf = renderer.RenderRtfFileAsPdf("discharge-summary.rtf");

pdf.SaveAs("discharge-summary.pdf");
using IronPdf;

var renderer = new ChromePdfRenderer();

PdfDocument pdf = renderer.RenderRtfFileAsPdf("discharge-summary.rtf");

pdf.SaveAs("discharge-summary.pdf");
Imports IronPdf

Dim renderer As New ChromePdfRenderer()

Dim pdf As PdfDocument = renderer.RenderRtfFileAsPdf("discharge-summary.rtf")

pdf.SaveAs("discharge-summary.pdf")
$vbLabelText   $csharpLabel

Everything else in this article is about making that call safe, observable, and scalable inside a healthcare-grade pipeline.

Set your license key once, before the first render: IronPdf.License.LicenseKey = "KEY";

Start using Iron Suite in your project today with a free trial.

First Step:
green arrow pointer

Table of Contents

Problem and architecture

Lifecycle walkthrough

Decisions and operations

The healthcare document problem

Healthcare-adjacent platforms move a constant stream of clinical and administrative documents: discharge summaries, lab reports, referral letters, statements, and interface exports. A large share of that content originates in older clinical and EHR-adjacent systems as RTF, while everything downstream (customer portals, partner integrations, archival stores) expects PDF. The conversion sits directly in the application's core processing path: if a document fails to convert, an internal team or a customer-facing system notices the same day. Governance runs alongside the engineering problem. Retention, audit logging, and access-control expectations mean document handling gets reviewed by compliance and procurement as well as engineering, with EULA and Trust Center materials feeding that review.

A naive implementation breaks down in three predictable places. Synchronous conversion inside the request path couples bursty, CPU-heavy rendering to API latency, so month-end and interface-driven spikes degrade the whole application. Linux dependency gaps surface at runtime in containerized deployments: the library renders correctly on a developer's Windows machine and fails inside the AWS container image. And RTF fidelity edge cases (fonts, tables, nested formatting) only appear on real production documents, which is why this platform treated conversion fidelity as an evaluation gate to clear before committing, not a bug class to discover afterward.

Solution architecture overview

API surface: A thin document API accepts source documents (RTF, HTML, images) plus the metadata needed to produce output. It validates the request, writes the source to storage, enqueues a conversion job, and returns. It never renders anything itself, so the API tier scales for request volume rather than rendering load.

Async workers: Conversion and rendering workers consume the queue and host IronPDF within IronSuite. They are the only tier with rendering dependencies installed, they scale horizontally and independently of the API, and a slow or failing document occupies a worker slot rather than a request thread.

Storage boundary: Source documents and rendered output live in object storage; a metadata database tracks job state, validation outcomes, and delivery status. Workers stay stateless, which keeps retries and horizontal scaling straightforward.

Observability: Every stage emits logs, metrics, and traces keyed by document ID: conversion success rates, render latency, and validation pass rates. In a workflow where a failed document is customer-visible, conversion outcomes are product metrics, not just infrastructure telemetry.

Lifecycle walkthrough

Stage 1: Ingest

The pipeline accepts source documents and the data needed to produce output, then turns them into queued conversion jobs.

Iron products used:

  • IronPDF worker bootstrap and environment configuration: IronPdf.License.LicenseKey at startup, and Installation.LinuxAndDockerDependenciesAutoConfig for containerized Linux hosts

Inputs: RTF, HTML, and image sources, plus document data and metadata.

Outputs: A validated, queued conversion job with the source persisted to storage.

Validate formats at the outset to ensure unsupported or corrupt sources are rejected at the API boundary, rather than during downstream processing. Capture routing metadata, such as document type, tenant, and priority, at ingest, since later stages rely on this information for validation and delivery. Decoupling ingest from conversion with a queue helps the system manage traffic spikes without impacting the entire pipeline. For platforms serving multiple consumers, isolate each customer's document flow from ingest onward. Maintaining multi-tenant separation at the queue stage is more cost-effective than implementing it at the storage layer.

→ Full tutorial: Installing IronPDF on Linux

Stage 2: Convert

This stage converts RTF and other source formats into normalized PDF content. It is the capability this platform gated its entire evaluation on.

Iron products used:

  • ChromePdfRenderer RTF surface: RenderRtfFileAsPdf and RenderRtfStringAsPdf

Inputs: RTF (and other) source documents from the ingest queue.

Outputs: Converted, normalized PDF content ready for generation.

RTF-to-PDF fidelity is the primary evaluation criterion. Use representative real documents for testing, as issues often arise with fonts, tables, and legacy formatting. Verify conversion results on Linux with all required dependencies installed. If a conversion works on Windows but differs in the container image, treat this as an evaluation blocker rather than a post-deployment issue. This platform identified such a concern during evaluation and escalated it to Iron Software support and technical resources. Address conversion edge cases proactively and communicate them clearly.

→ Full tutorial: Convert RTF to PDF in C#

Stage 3: Generate

This stage produces final PDF documents from converted content, templates, and document data. Generation is kept distinct from conversion.

Iron products used:

  • ChromePdfRenderer.RenderHtmlAsPdf for HTML-templated generation
  • RenderingOptions for page setup, with HtmlHeaderFooter for headers and footers

Inputs: Normalized content, HTML templates, and document data.

Outputs: Generated PDFs.

Maintain a clear separation between templates and conversion logic. Templates follow the product release cycle, while conversion logic aligns with the engine release cycle. Coupling these components increases the risk that template changes will disrupt the conversion process. Since rendering uses Chromium-based HTML-to-PDF, treat templates as web pages designed for print: use deterministic fonts, specify page sizes explicitly, and avoid external resources you do not control. Always verify rendering on the Linux/AWS target environment, as fonts on the build machine may not be present in the container image. Font substitution is a common cause of discrepancies between local and production output.

→ Full tutorial: Convert HTML to PDF in C# with Chrome Rendering

Stage 4: Validate

This stage verifies conversion fidelity and output correctness before anything is delivered.

Iron products used:

  • PdfDocument inspection surface: PdfDocument.FromFile, ExtractAllText, and page-level checks via PageCount

Inputs: Generated PDFs.

Outputs: A validated PDF plus an explicit pass/fail signal recorded in the metadata database.

Automate checks for the conversion cases that matter most, which for this platform meant RTF-derived documents: page counts within expected bounds, extracted text containing required fields, and no empty renders. Fail closed. A document that fails validation is quarantined for review and never delivered, because in a healthcare-adjacent context an incorrect document reaching a customer-facing system is a governance incident, and the pipeline prefers a held document plus an alert over a silently wrong delivery. Validation pass rate is also your earliest regression signal when upgrading the rendering engine or the container base image.

→ Full tutorial: Extract Text and Images from PDFs in C#

Stage 5: Deliver

The final stage returns finished documents to internal and customer-facing systems.

Iron products used:

  • PdfDocument output surface: SaveAs for file targets, with BinaryData and Stream for object storage and HTTP responses

Inputs: Validated PDFs.

Outputs: Documents delivered to downstream systems or end users, with delivery outcomes recorded.

Separate delivery from generation to allow independent retries. If a downstream endpoint is unreliable, only the delivery step should be retried, not the document rendering. A single validated document may be sent to multiple destinations, such as a customer portal, partner endpoint, or archival store. Each destination should have its own retry policy and failure handling. Ensure deliveries are idempotent by document ID to prevent duplicate entries in customer-facing systems. Monitor delivery outcomes as rigorously as conversion outcomes. The "converted but never delivered" failure mode can persist undetected unless delivery status is tracked alongside job state in the metadata database.

→ Full tutorial: Export and Save PDFs in C#

Design rationale

  • Async conversion over synchronous: Rendering workloads are resource-intensive and unpredictable. Isolating them helps maintain API latency and allows conversion to scale independently. However, this approach requires queue infrastructure and introduces eventual consistency, as callers must poll or subscribe for completion instead of waiting for an immediate response.
  • Linux-first images: Rendering dependencies are baked into the container image rather than installed at runtime. Images get larger and engine upgrades force rebuilds, but "missing dependency" stops being a runtime failure mode.
  • Conversion fidelity gated early: RTF-to-PDF was proven on real documents before commitment. That slows the start of an evaluation and requires representative samples, but it converts the scariest unknown into tested behavior.
  • Unified suite over multiple vendors: One licensing relationship and consistent APIs simplify both engineering and procurement. The tradeoff is single-vendor coupling, mitigated here by the storage and queue boundaries that keep the engine swappable in principle.
  • Right-sized licensing: An unlimited suite license fits broader team usage and future projects. A per-developer license is cheaper on day one and more constraining every year after, which is exactly the wrong direction for a platform expecting wider document-processing use.
  • Fail-closed validation: Held documents need a triage path and add operational work, but silent low-fidelity delivery is the more expensive failure in a regulated context.

Operational reality

Scaling: Conversion and rendering workers scale horizontally; the API tier stays light. Scale workers on queue depth and render latency rather than CPU alone, because RTF conversion cost varies widely per document. Reuse renderer instances within a worker where the workload allows, and size worker memory for peak concurrent renders rather than the average case.

Bottlenecks: RTF and complex-document conversion plus PDF rendering are the primary CPU and IO hot spots. Expect a long tail: most documents render quickly, while a minority dominate worker occupancy. Use retries with idempotent conversion, and isolate persistently failing documents in a dead-letter path so they do not block the queue.

Pitfalls: Missing Linux dependencies, absent fonts, and RTF formatting edge cases are the most common sources of surprise. All three appear only on the target environment, which is why the trial ran on the real AWS/Linux infrastructure rather than a developer workstation.

Next steps