Robotic process automation

RPA imitates structured computer work

The Digital.gov RPA Playbook describes bots configured to automate repetitive tasks. An RPA bot might sign into a portal, read a structured field, copy a value, create a record, download a report, or place an exception in a queue.

RPA is not synonymous with artificial intelligence. A deterministic bot can follow fixed rules without predicting, generating, or interpreting content. Some products combine RPA with optical character recognition, language models, or other AI. Inventory each component because its risks, evidence, validation, and human-review needs differ.

An API integration exchanges data through a supported interface. RPA often works through the same screens a person uses. Screen-based automation can be practical, yet small interface changes may break selectors or put data in the wrong field.

Improve the process before automating it

The GSA Eliminate, Optimize, Automate initiative recommends removing unnecessary work, improving essential processes, and then automating repetitive tasks. That sequence prevents a bot from scaling a broken handoff.

Good candidates usually have stable inputs, explicit rules, adequate volume, low exception rates, clear ownership, and a measurable outcome. Difficult candidates rely on ambiguous documents, frequent policy changes, clinical judgment, negotiation, or several hidden workarounds.

Map the current process with trigger, source, steps, systems, decision points, exceptions, output, owner, deadline, and evidence. Confirm that automation is permitted by each vendor and payer route.

Keep accountable decisions with people

A bot may collect eligibility evidence, compare structured dates, assemble a work queue, or submit an approved packet through a permitted route. It should not independently diagnose, change goals, select dosage, alter clinical rationale, attest for a clinician, choose a billing code from ambiguous evidence, waive a balance, accept a contract, or decide that an authorization guarantees payment.

Define which actions the bot may complete and which require approval. Capture the approver, evidence shown, decision, timestamp, and resulting action. Separate the person who changes a rule from the person who approves production release when risk warrants it.

Credentials need their own control

Give the bot a named service identity where systems permit it. Apply least privilege, strong authentication, approved secret storage, rotation, access review, and immediate revocation. Avoid shared human credentials that hide authorship or violate a portal agreement.

The NIST Cybersecurity Framework offers broad outcomes for governing, identifying, protecting, detecting, responding, and recovering from cybersecurity risk. For a HIPAA covered entity or business associate, 45 CFR 164.308 requires risk analysis, risk management, access controls through administrative safeguards, activity review, incident procedures, and contingency planning. RPA enters those controls when it creates, receives, maintains, or transmits ePHI.

Classify the vendor relationship, approved data, retention, logs, subprocessors, incident duties, and business-associate agreement where required. Minimize PHI in screenshots, logs, prompts, and exception messages.

Design exceptions before launch

For each step, specify success, retryable failure, permanent failure, uncertain result, duplicate, timeout, and unavailable-system behavior. A timeout after submission is not proof that nothing happened. Check status before resending.

Use idempotency or a comparable duplicate control where available. Preserve source evidence and bot activity. Send ambiguous cases to a role-qualified queue with the original data, attempted action, error, and next step.

Maintain a kill switch, rollback plan, manual path, change calendar, and recovery owner. Test interface changes, expired credentials, partial outages, stale rules, duplicate files, and unexpected values.

Use a promotion gate for every bot version. Require locked test cases, source-to-output reconciliation, privacy and security review, least-privilege credentials, exception ownership, monitoring thresholds, rollback evidence, and business-owner approval. Release only the tested version and retain the prior configuration for investigation or recovery.

A fictional eligibility bot

Solace ABA Network has 120 eligibility checks due in a test day. The bot completes 108, routes seven to an exception queue, and records five failures. Completion is 108 of 120, or 90%. Exception routing is 7 of 120, or 5.8%. Failures remain visible at 5 of 120, or 4.2%.

The bot result is evidence retrieval, not a coverage guarantee. Staff verify the payer, product, source, date, limitations, authorization status, and planned service before making a financial representation or release decision.

Measure business outcomes and control health

Track eligible cases completed correctly divided by cases due, false-success events, duplicate actions, exception age, manual rework, rule freshness, credential review, downtime, and hours saved. Validate a sample against the authoritative source and report material errors by type.

An automation can run quickly while creating downstream work. Pair cycle time with accuracy, final outcome, staff experience, client or family burden where relevant, and control failures. Retire the bot when the process changes or its risk exceeds its value.