Automating Healthcare Procedure Code Selection Through Domain-Specific LLM Platform

hasura_/_promptql · Healthcare · year n/a · source Agentic: yes · promotional bias: high · summary-only (no fetched source) · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Healthcare scheduling automation

A radiology software company needed to reduce appointment-scheduling call time by automating procedure-code selection across complex clinic-, regulation-, and patient-specific rules.

Constraints:

operators had to choose among hundreds of procedure codes
rules vary by clinic, regulations, patient demographics, and visit history
domain experts understand the rules but cannot code automations
developers can code but often lack the operational domain context
healthcare automation needs deterministic, auditable execution

Architecture

PromptQL addresses the healthcare automation paradox with a domain-specific LLM platform. Non-technical administrators express business logic in natural language. The system converts those requirements into a company-specific query language, uses semantic layers and ontologies to ground domain terms, tests the resulting automation against scenarios, and deploys deterministic executable logic through a simplified SDLC designed for non-technical users.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  natural-language-rule-authoring[Natural language rule authoring] --> domain-semantic-layer[Domain semantic layer]
  domain-semantic-layer --> domain-specific-query-generator[Domain-specific query generator]
  domain-specific-query-generator --> scenario-test-harness[Scenario test harness]
  scenario-test-harness --> deployment-workflow[Deployment workflow]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Natural language rule authoring`	Lets healthcare administrators express scheduling and procedure-code rules conversationally.	`Domain semantic layer`
`Domain semantic layer`	Encodes terminology, procedures, entities, and organizational ontologies.	`Natural language rule authoring`, `Domain-specific query generator`
`Domain-specific query generator`	Turns natural language into company-specific executable logic.	`Domain semantic layer`, `Scenario test harness`
`Scenario test harness`	Runs automations across example inputs and supports iterative rule refinement.	`Domain-specific query generator`, `Deployment workflow`
`Deployment workflow`	Provides versioning, staging, production deployment, and troubleshooting for non-technical users.	`Scenario test harness`

Data flow

Healthcare administrators describe procedure-selection rules in natural language. PromptQL maps those statements through a domain semantic layer into a company-specific query language, produces deterministic executable plans, runs test scenarios, and lets users refine or deploy the automation through versioned staging/production workflows.

4 supporting quotes

“Non-technical users interact with models that have been trained on the specific domain language and ontologies of their organization.”summary, stated

“The system converts natural language business rules into deterministic, executable plans written in the company-specific query language.”summary, stated

“• Convert requirements into testable automations with defined inputs and outputs • Run comprehensive testing against various scenarios”summary, stated

“• Iteratively refine rules based on test results • Deploy changes through a simplified interface The testing approach is particularly noteworthy.”summary, stated

Why this architecture

The architecture separates natural-language authoring from deterministic execution. That lets domain experts author changing healthcare rules without making the runtime probabilistic. The semantic layer is the bridge between clinical scheduling language and executable plans, while testing/deployment workflows keep non-technical users inside a production process.

3 supporting quotes

“the people who understand the business rules (healthcare administrators) cannot code the automation, while the people who can code (developers) don't understand the domain-specific rules.”summary, stated

“This creates a crucial abstraction layer that maintains the precision needed for production systems while enabling natural language interaction.”summary, stated

“Deterministic Execution: The intermediate query language ensures that despite the non-deterministic nature of LLM interactions, the final execution is completely deterministic and auditable.”summary, stated

Models used: PromptQL domain-specific LLM platform · domain-specific models/fine-tuned foundation models

Scale

Traditional appointment-scheduling calls took 12-15 minutes.
“The traditional manual process took 12-15 minutes per call, requiring operators to navigate complex UIs and select from hundreds of procedure codes that varied by clinic, regulations, and patient circumstances.”summary, stated
Reducing calls by three minutes was estimated at about $50 million in impact.
“The presenter noted that reducing call times by just 3 minutes could yield approximately $50 million in business impact across their network servicing thousands of clinics globally, primarily in the US and Europe.”summary, stated
The network serves thousands of clinics globally, mostly in the US and Europe.
“The presenter noted that reducing call times by just 3 minutes could yield approximately $50 million in business impact across their network servicing thousands of clinics globally, primarily in the US and Europe.”summary, stated
Mammogram code sets could range from 5 to 250 codes across clinic families.
“Varying procedure code sets across different clinic families (ranging from 5 to 250 codes just for mammograms)”summary, stated

Alternatives considered (roads not taken)

Traditional developer-built configuration systems

Rejected because: The rule space caused configuration explosion and left many rules uncoded.

“The existing solution involved developers creating extensive configuration systems to handle edge cases, leading to configuration explosion”summary, stated

“Many business rules remained uncoded because the cost of encoding them exceeded their perceived benefit. ## LLMOps Architecture and Implementation”summary, stated

General-purpose foundation-model coding

Rejected because: PromptQL invested in domain-specific query languages and semantic layers for healthcare terminology.

“Rather than using general-purpose foundation models, the platform invests heavily in domain-specific model training and fine-tuning.”summary, stated

Let AI operate directly in the data layer

Rejected because: PromptQL runs the query language in user space to maintain security boundaries.

“Security and Authorization Model: The platform addresses security concerns through a multi-tenant architecture where the domain-specific query language (AcmeQL) runs strictly in user space rather than data space.”summary, stated

Patterns

`structured-output-contract` (reliability)

Natural language is compiled into deterministic domain-specific query plans rather than executed directly as free-form model output.

“natural language business rules into deterministic, executable plans written in the company-specific query language”summary, stated

`tool-use-orchestration` (workflow)

The platform combines rule authoring, testing, deployment, version control, and troubleshooting for non-technical users.

“Version control through conversational interfaces”summary, stated

“Staging and production deployment workflows”summary, stated

`fine-tuning-adaptation` (modeling)

The platform uses domain-specific model training and ontologies for healthcare procedure-code logic.

“Model Specialization: Rather than using general-purpose foundation models, the platform invests heavily in domain-specific model training and fine-tuning.”summary, stated

`privacy-preserving-processing` (governance)

The user-space query-language boundary separates AI-authored logic from data-layer authorization.

“maintaining security boundaries and preventing unauthorized data access.”summary, stated

Tradeoffs

Compile natural language into deterministic plans

Chose domain-specific executable query language over direct model execution of business rules.

Rationale: The query layer preserves auditability and precision while allowing non-technical authoring.

“despite the non-deterministic nature of LLM interactions, the final execution is completely deterministic and auditable.”summary, stated

Invest in domain specialization

Chose semantic layers and domain-specific model training over general-purpose coding models.

Rationale: Procedure code selection depends on specialized healthcare terminology and local business rules.

“This specialization is crucial for handling the nuanced terminology and business rules specific to healthcare operations.”summary, stated

Gotchas (what bit them)

Business experts and developers hold different halves of the automation knowledge.

Root cause: Healthcare administrators know procedure rules but cannot code; developers can code but lack domain detail.

Resolution: PromptQL lets administrators author natural-language rules that compile to executable logic.

Domain setup is expensive.

Root cause: The system needs semantic layers, ontologies, model maintenance, and testing infrastructure.

Resolution: The source positions that upfront work as necessary for regulated, complex enterprise domains.

“The system requires extensive upfront investment in creating domain-specific semantic layers and ontologies.”summary, stated

“Maintaining domain-specific models requires ongoing investment in training data curation, model updates, and performance monitoring.”summary, stated

Rule correctness can be hard when business rules interact.

Root cause: Complex healthcare rules may interact in unexpected ways.

Resolution: Scenario testing and iterative refinement are built into the user workflow.

“the case study doesn't deeply address how complex business rules are validated for correctness, especially when they interact with each other in unexpected ways.”summary, stated

“Run comprehensive testing against various scenarios”summary, stated

Evaluation

The summary describes scenario testing and reported business-impact estimates; it does not provide an independent benchmark of rule accuracy.

Metrics: call handling time · business impact estimate · scenario test success · training-cost reduction · deployment workflow adoption

“reducing call times and potentially delivering $50-100 million in business impact”summary, stated