Flowable for healthcare: why process and case engines fit clinical operations
Referral, prior authorization and care coordination often run across shared mailboxes, spreadsheets, task queues and EHR screens, which makes it hard to see where a patient request stands or who owns the next step. Flowable answers this with three engines in one Java stack: BPMN for the fixed steps of a referral or authorization path, CMMN for care coordination where the sequence depends on the patient, and DMN for eligibility and routing rules that clinical and revenue staff need to read and change. The engines run inside infrastructure your organization controls, and Flowable open source is licensed under Apache 2.0, so the platform itself does not add a per-patient license decision to the design.
The build changes once ePHI is involved. Process variables are the first place it shows up: a patient identifier, a diagnosis code or a payer reference copied into a variable is ePHI that the engine persists in its database and may expose through the REST API and history tables. Decide early which data stays in the clinical system and which identifiers the process carries, encrypt the database and backups, and confirm how the history retention settings in your version handle those variables. The HIPAA Security Rule applies to covered entities and business associates for all ePHI they create, receive, maintain or transmit (45 CFR 164.302), so the engine, its database and any integration broker belong in the risk analysis. Clinical systems usually exchange messages through a broker, so the integration pattern, message retention and replay behavior need the same review. Ask your compliance lead which controls the platform owner, the hosting team and the Flowable application each must evidence, and note that there is no HIPAA certification to buy.
Which HIPAA Security Rule requirements shape a Flowable build
This table maps the HIPAA Security Rule standards and implementation specifications that most affect a Flowable build to the design decisions they force on process variables, identity, logging and vendor terms. Read the Required column first, since those specifications apply without exception, then treat Addressable items as decisions you must assess and document. The Security Rule has no certification, so the evidence you produce is what an OCR review or auditor will examine.
| Requirement | What it means for a Flowable build | Evidence to keep |
|---|---|---|
| Unique user identification (164.312(a)(2)(i), required) | Every task claim, case action and API call should trace to a named person or service identity, so Flowable identity service integration must map to your directory rather than shared engine accounts. | Identity mapping, task and claim history, and removal of default accounts |
| Emergency access procedure (164.312(a)(2)(ii), required) | Define how clinicians reach in-flight referrals or authorizations when the normal identity path is down, and how that access is logged and reviewed afterward. | Written break-glass procedure, test records, and post-event review |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Session timeouts apply to any custom front end or REST-based task console that displays ePHI from process variables, and the decision not to implement must be documented. | Session configuration, or a documented rationale and alternative |
| Encryption and decryption (164.312(a)(2)(iv), addressable) | Process variables, history tables and job data hold ePHI, so decide how database storage, backups and transport are encrypted, and document the reasoning for each addressable choice. | Encryption configuration, key management records, and assessment memo |
| Audit controls (164.312(b), required standard) | Flowable history and audit data can show who acted on which referral or authorization, but you must confirm what the engine records by default and what your application adds. | Sample audit trail reports and log retention settings |
| Minimum necessary and process variables (164.502(b) and access control safeguards) | Store identifiers or references in variables where possible, and avoid copying full clinical records into process state, since variables persist in the database and history. | Variable inventory per process and data flow diagrams |
| Business associate contracts (164.314(a)(2)(i), required) | Hosting, support or integration partners that can reach ePHI in the engine or database need contract terms requiring Security Rule compliance, subcontractor flow-down, and incident reporting. | Signed business associate agreements covering each vendor and subcontractor |
| Documentation of addressable decisions (164.306(d)) | For each addressable specification you do not adopt as written, record why it is not reasonable and appropriate and which equivalent measure you implemented. | Dated decision records tied to the system design |
| No HIPAA certification | No product, partner or Flowable release certifies HIPAA compliance, so a vendor statement is not evidence. Assessors look at your risk analysis, configuration and operating records. | Risk analysis, configuration baseline and operating evidence, confirmed with your counsel |
How referral, prior authorization and care coordination differ as Flowable models
Referral routing is usually the most structured of the three workflows. A referral arrives, is validated, is matched to a receiving service or clinician, and is accepted, returned or escalated when no one picks it up. That sequence fits a BPMN process with service tasks, user tasks for the receiving office, and timer events for acceptance deadlines. The routing choice itself (specialty, urgency, network status, location) is better held in a DMN decision table, so the rule set can be reviewed by clinical operations without changing the process model.
- Process shape: a BPMN process with a start event at intake, a gateway on validation outcome, and boundary timers that trigger escalation if the referral is not accepted in time.
- Decisions: a DMN table that takes specialty, urgency and network status and returns a destination queue, with a hit policy you document and test.
- Human tasks: triage and acceptance tasks assigned to a queue or group, not to a named person, so work continues during absence.
- Data in variables: referral ID, specialty code, urgency category and destination ID. Keep the referral document, diagnoses and identifiers in the source system and pass a reference.
- Data to avoid: free-text clinical notes or full demographic records copied into variables, which then appear in history tables and logs.
Confirm with your clinical and privacy teams which fields the routing decision truly needs, and check how history retention applies to any variable you do store.
Prior authorization combines two shapes. The payer's criteria for a service are often rules that can be expressed as a decision table, while the review itself is open-ended: a request may need additional clinical documents, a peer-to-peer call, a second reviewer or a appeal. A BPMN process handles the fixed steps, and a CMMN case handles the review, where stages, sentries and milestones react to what arrives. Keeping payer criteria in DMN lets the team show exactly which rule produced an outcome.
- Process and case split: a BPMN process for submission, eligibility checks and final notification, with a CMMN case for the review stage, where information requests and reviewer tasks can occur in any order.
- Decisions: a DMN table for criteria such as service code, site of care and documentation present, with the rule version recorded against each decision.
- Human tasks: nurse or medical reviewer tasks with defined completion criteria, plus a separate four-eyes or medical director task for denials.
- Data in variables: request ID, service code, criteria outcome codes and decision version. Clinical attachments stay in the document store, referenced by ID.
- Data to avoid: diagnosis narratives, imaging or lab results and member identifiers beyond what routing needs.
Ask your payer partners and compliance team which decision outcomes must be retained and for how long, since that determines how much of the decision history the engine must keep.
Care coordination is the least predictable of the three. A care plan for a patient may involve primary care, a specialist, social work, pharmacy and a discharge planner, and the order of their actions depends on the patient's condition. That makes it a natural CMMN case: a case plan with stages for assessment, planning and follow-up, and plan items for tasks that become active when a milestone or event occurs. Individual steps that repeat in a predictable way, such as scheduling a follow-up call, can still be BPMN subprocesses called from the case.
- Case shape: a CMMN case with stages per care phase, sentries that open tasks when a clinical event arrives over messaging, and milestones for goals such as completed medication reconciliation.
- Decisions: a DMN table for escalation triggers, such as missed follow-up or a risk score band supplied by another system, so the thresholds are visible to clinical leads.
- Human tasks: role-based tasks for each team, with due dates set by the case, and an owner field that the application enforces against the care team membership.
- Data in variables: case ID, patient reference, care team role codes and task status. Assessments and notes belong in the EHR or care record.
- Data to avoid: the full clinical picture copied into case variables, because case variables are visible to everyone who can open the case.
Check whether your application's authorization model limits who can read case variables, since the engine does not enforce that for you.
Which Flowable modules, settings and integrations matter in healthcare
Healthcare workflows touch patient data, clinical systems and staff identities, so several Flowable settings carry compliance weight from the first design. The cards below cover the decisions that shape access, availability, evidence and data exposure. Each one should be settled with your security, privacy and clinical informatics teams before build starts.
Identity through IdmIdentityService
Flowable lets you replace its identity management by overriding IdmIdentityServiceImpl or implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Use this extension point to tie task assignment and candidate groups to the same directory that governs clinical roles, such as care team membership. Confirm how deprovisioned staff lose open task access, since the engine will not decide that for you.
Async executor and cluster locks
The async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database. Expired locks are recovered and picked up by other nodes, which matters for referral deadlines and prior authorization timers during a node failure. Test failover with realistic timer volumes and confirm that no timer fires twice or silently stops.
History and audit retention
Process history records who did what and when, and it often becomes the evidence trail for access and decisions about patient care. Decide retention periods, archival and deletion rules before go-live, and document them against your record retention policy. Confirm with your legal and privacy teams whether history rows containing ePHI can be purged, and how that purge is audited.
Database choice and encryption
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and the process database holds variables and history that may contain ePHI. Choose a supported database your operations team can back up, restore and encrypt at rest. MySQL versions below 5.6.4 lack millisecond precision, which affects timer and audit ordering.
REST access controls
The Flowable REST application exposes engine operations over HTTP, so every endpoint needs authentication, role checks and network restriction in front of it. The engine leaves authorization decisions for data such as a patient's referral to your application. Verify which endpoints are reachable from clinical networks and which are internal only, and test that a user cannot read another patient's tasks through the API.
Messaging connectors to clinical systems
Referral, result and scheduling events usually reach Flowable through a message broker or integration layer, not through named EHR connectors that Flowable provides. Design message schemas that carry identifiers rather than full clinical payloads where possible, and confirm how failed deliveries are retried and dead-lettered. Confirm with each EHR vendor which interfaces and terms your deployment is permitted to use.
Connecting Flowable to clinical systems over messaging
A Flowable process typically reaches a clinical system through a message broker or integration layer rather than a direct call, so the design question is how a process instance sends and receives messages reliably. In practice, a service task or delegate publishes an outbound message (for example, a referral request to an EHR interface engine), and the process waits at a receive task, intermediate message catch event or boundary event for the reply. The integration layer owns delivery to the clinical system, while Flowable owns the correlation of the reply to the right process instance through a business key or correlation variables. Decide early which identifiers travel with each message and which are stored only in Flowable's database, because that choice determines how a reply finds its instance after a restart.
Message payloads should carry references, such as a patient identifier, referral identifier or document identifier, rather than full clinical records. Process variables are persisted in the Flowable database and appear in history, so copying a discharge summary or lab result into a variable spreads ePHI into a second store with its own retention, backup and access questions. A payload that holds only a reference lets the receiving system fetch the record under its own access controls and audit trail. Confirm with the EHR vendor which identifiers the interface accepts and whether the reference lookup is available through a supported API, and confirm with the integration team which messages the broker logs in full.
Retries and duplicate handling interact with the async executor, which runs timers and asynchronous jobs from a thread pool and recovers expired locks so other nodes can pick up work. If a send step succeeds but the job fails before it commits, the executor may retry it and the clinical system may receive the same referral twice. Make outbound calls idempotent by sending a stable message identifier that the receiver checks, and make inbound handlers tolerant of a reply arriving more than once or after a boundary timer has fired. Agree with the EHR vendor and integration team the retry limits, dead-letter behavior, how failed messages surface to care coordinators, and which team reprocesses them. These answers should be written into the design before build starts, because they define what the process must record for HIPAA audit controls.
How a healthcare Flowable rollout is phased
The sequence moves from data classification and legal terms to a single live referral or authorization path, so each phase closes with evidence a security, compliance and clinical reviewer can check before the next one starts.
Classify data and fix the scope
Map which workflows touch electronic protected health information, which process variables and history records would hold it, and which clinical systems each path reads from or writes to. Your privacy and security leads confirm the classification, and the scope document names the in-scope referral, prior authorization or care coordination paths. Done means every variable in the planned models has a documented classification and an owner.
Assess risk and confirm business associate terms
Your compliance team and DeployOpen review the Security Rule standards that apply to the in-scope paths, record how each addressable specification is handled, and confirm that contracts with any vendor or subcontractor that handles ePHI meet the requirements of 45 CFR 164.314. This is also where you decide who hosts the engines and backups. Done means a signed risk assessment and executed agreements exist before any production data enters the environment.
Design processes, decisions and clinical sign-off
Model the BPMN processes, CMMN cases and DMN decision tables with clinical and operations owners, who approve the referral routing, authorization criteria and escalation paths. Keep clinical content in decision tables that name their owner and version. Done means the clinical owner has signed off each model version and the test cases that prove the routing rules match the approved policy.
Build identity, access and audit logging
Connect the engines to your identity provider so users are authenticated by your existing directory, and limit access to process data by care team role and need to know. Configure history and logging so that who acted on which task, and when, is recorded without writing unnecessary clinical detail into logs. Done means access tests confirm that users outside a care team cannot read or act on a case, and that audit records can be retrieved for a sample of activities.
Test integrations over messaging
Connect the workflows to clinical systems through your message broker or integration layer, and test message ordering, retries, duplicate delivery and failure handling against realistic but non-production data. Confirm how a failed message is surfaced to an operator and how it is replayed without creating duplicate referrals or authorizations. Done means the integration test plan has passed, with failure scenarios documented and reviewed by the operations team.
Pilot one referral or authorization path
Run a single referral or prior authorization path with a limited set of users, clinical monitoring and a defined rollback procedure. Track failed jobs, stuck tasks, timer behavior and user-reported issues, and review the audit history for a sample of cases with the compliance team. Done means the pilot exit review records the defects fixed, the open risks accepted by a named owner, and the go or no-go decision.
Expand in controlled steps
Add further care paths, sites or user groups one at a time, each with its own model review, access check and integration test. Keep the process and decision versions in a controlled deployment pipeline so changes to running instances are approved before release. Done means each expansion has its own signed change record, and the operations runbook covers monitoring, backups and the upgrade plan for the engines.
Compliance evidence Flowable can help produce, and what it cannot
Flowable history, task controls and documented decisions can support the evidence a HIPAA Security Rule review asks for. None of it is a certification, and the engine does not decide whether your program complies. The cards below separate what the platform records from what your organization must still prove.
Audit history of who acted and when
Flowable history records process and task events with timestamps and the user who completed each human task, which can answer who accessed or changed a referral or authorization and when. Check that the history captures the user identity from your directory rather than a shared service account, and that it records the variables changed at each step. Confirm the history level you configure actually records the events an auditor will ask about, since some detail is only kept at higher levels.
Access controls for human tasks
The engine does not enforce who may claim or complete a task on its own. Candidate groups and assignees must be mapped from your identity source, and your application or API layer must check each action against the patient care relationship. A common gap is a task visible to a whole group when only the treating care team needs access, which is the kind of need-to-know failure regulators have cited in other jurisdictions. Test these checks with negative cases.
Retention of process history
Retention of Flowable history is a configuration and operations decision, not a default you can rely on. You need a written schedule for how long referral and authorization history is kept, how it is purged, and how backups are handled so deleted records do not persist unmanaged. Ask your compliance lead to set the period from your own retention obligations and state laws, then confirm the purge jobs run and are logged.
Documented decisions for addressable specifications
Many technical specifications are addressable, meaning you must assess whether each is reasonable and appropriate and document why, and implement an equivalent measure if it is not. Flowable can help by keeping the configuration and deployment record for measures such as audit logging and automatic logoff, but the assessment itself is a written decision your team owns. Keep it with the system's risk analysis so a reviewer can trace the reasoning.
Business associate contract flow-down
When a vendor or hosting partner handles ePHI in or around your Flowable deployment, the business associate contract must require Security Rule compliance, flow the same terms to subcontractors that touch ePHI, and require incident reporting. The engine has no role in this, so confirm that any managed hosting, support or DeployOpen engagement is covered by an agreement that meets these terms before work begins. Contract terms are a legal review, not an engineering deliverable.
NIST SP 800-66 Rev. 2 as a working guide
NIST SP 800-66 Rev. 2, published in February 2024, gives key activities and sample questions for each Security Rule standard and is a useful map for a Flowable control matrix. HHS treats it as informational rather than binding, so it helps structure evidence but does not define compliance. Use it to choose which Flowable records, configurations and tests answer each standard, and state in your own words what each one shows.
What healthcare teams ask before hiring a Flowable partner
What drives the cost of a Flowable healthcare implementation?
Scope, the number of clinical and administrative integrations, identity design and validation work drive most of the cost. A referral or prior authorization workflow with one EHR connection and a single payer rule set is a different job from a care coordination platform that touches scheduling, messaging, billing and external referral partners. Costs fall into two groups: the build (process and case models, decision tables, custom delegates, integration adapters, tests) and the controls work (access design, audit logging, backup and restore testing, documentation for assessors). Ask any quote to itemize both, to state which integrations are included and which are assumed to exist, and to separate one-time delivery from recurring support, upgrades and hosting, which you run in your own infrastructure.
How is the scope of a fixed-scope Flowable engagement defined?
Scope is set by the processes in the first agreed release, the systems they call, the roles that act on them and the evidence you need at the end. Before work starts, the written scope should list each BPMN process, CMMN case and DMN decision table in play, every messaging topic or API the workflow depends on, the identity source for clinicians and staff, and the environments to be delivered. It should also name what is out of scope, such as changes inside the EHR itself. Duration follows from that list. Ask for milestones tied to deliverables, and for a clear rule on how changes to the scope are priced and approved in writing.
Can our in-house team build a Flowable healthcare application without a partner?
Often yes, if your team already runs Java services in production and has people who understand both clinical workflows and the HIPAA Security Rule. Flowable's engines are open source under Apache 2.0 and run embedded in Spring applications, so the core skills are Java, Spring Boot, relational databases and BPMN modeling. The harder parts tend to be the healthcare-specific ones: mapping referral and authorization rules into DMN tables that clinicians can review, designing message-based integration with clinical systems, and producing the access, logging and backup evidence an assessor will ask for. Decide early which of these your staff can own, and which need outside help for a set period. Document the decision so that ownership after go-live is clear.
What do clinical and compliance staff need to contribute to the build?
They need to supply the process knowledge and the rules that the software enforces, and they need to review the results before go-live. Clinical leads should walk through referral, authorization and care coordination steps, including exceptions and escalations, and approve the wording of tasks that staff will see. Compliance and privacy staff should confirm which roles may see which data, how long records are kept, what audit events must be retained and who handles a breach report. Expect review sessions on each decision table, because payer and referral rules often change. Agree on named owners and sign-off points in the scope, or the schedule will slip waiting for answers.
Can ePHI be stored in Flowable process variables?
Process variables can hold ePHI, but you should not assume the engine protects it. Flowable stores variables in the database and records them in history tables, so any value written to a variable may persist in several places, including backups. The HIPAA Security Rule applies to electronic protected health information wherever it is created, received, maintained or transmitted. A safer pattern is to keep identifiers and clinical detail in your system of record, pass a reference or case number through the process, and retrieve data only when a task needs it. Where a variable must carry PHI, confirm the database encryption, history retention, access to the history API and the deletion approach with your security team before build starts.
What do the HIPAA penalty ranges mean for planning a Flowable project?
The ranges set the financial exposure your controls need to prevent, so they belong in the risk register next to the scope decision. The inflation-adjusted HIPAA civil money penalty for penalties assessed on or after January 28, 2026 runs from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294, according to 45 CFR 102.3 as amended at 91 FR 3666. The amount depends on the level of culpability, so the practical lesson is that documented, tested controls and prompt corrective action reduce the risk. Do not read the figures as a budget. Ask your counsel how they apply to your organization and which of your Flowable data flows fall under the Security Rule.
Does a Flowable healthcare implementation make us HIPAA certified?
No. HIPAA has no certification, and HHS states that no Security Rule standard requires an entity to certify compliance. Private certifications do not stop HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. What a partner can deliver is a built system, documented controls, configuration evidence and test results that your compliance team and any independent assessor can review. Ask any partner to be precise about this distinction in writing. If your organization also pursues a third-party assessment framework, confirm with the assessor which of your controls and evidence they will accept.
How do Flowable workflows connect to clinical systems over messaging?
Usually through a message broker or integration layer that carries events between Flowable and clinical systems, so each side stays independent. A referral might start a process when an event arrives, wait on a timer or a message for the response, and send a result back. Design decisions include the message schema, how the process correlates a reply to the right instance, what happens when a message is lost or duplicated, and how failed jobs are retried and surfaced to operators. Confirm the messaging and integration points your Flowable version supports and test failure paths, not only the happy path, before any patient-facing use.
What to ask a partner before signing a Flowable healthcare scope
Put the ePHI question in writing first: which process variables may carry patient identifiers, and which should carry only an opaque reference that resolves inside the clinical system. Ask the partner to list every variable, form field and history entry that could hold clinical content, and to show how each is encrypted at rest, masked in the Flowable REST responses and excluded from logs. Ask whether the Flowable history tables, which retain variable values by default under the configured history level, will be scoped or purged, and who approves that retention setting. The answer determines how much of the HIPAA Security Rule's technical safeguards in 45 CFR 164.312 the engine itself must satisfy.
Next, ask how access and audit events will be produced and who owns them. Request a written description of which events are recorded for each task claim, variable read and administrative change, where they are stored, and how the identity service, such as an LDAP-backed implementation of the Flowable identity interface, ties each action to a named user. Ask who signs the business associate terms under 45 CFR 164.314(a)(2)(i), and whether a subcontractor that can reach ePHI during implementation or support is covered by the same flow-down. Confirm that the partner will not issue a HIPAA certification, because none exists; ask instead which controls and evidence the scope prepares for an independent assessment.
Ask how the scope handles addressable implementation specifications. For each one, the partner should document whether it applies, the reasoning for that conclusion and any equivalent alternative measure, as 45 CFR 164.306(d) requires. Finally, ask how an upgrade to Flowable 8.0.0 on Spring Boot 4 is planned, since the release notes state there is no backward compatibility for Spring Boot 3 and that Jackson 3 is the default JSON library. Require a written upgrade test plan covering the async executor, the REST API responses and the audit output, plus a rollback path. Confirm the sign-off roles for each change.
How DeployOpen scopes and delivers Flowable healthcare implementations
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports Flowable engines inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. Each healthcare engagement starts from a written scope that sets out which referral, authorization or care coordination workflows are in scope and how they connect to your clinical systems.
How we scope
- Map the referral, prior authorization or care coordination workflows you want Flowable to run, with the teams who own each step
- Record which process variables could hold ePHI and where they would be stored, logged or exported
- Agree in writing which integrations, identity sources and audit evidence are in scope before work starts
How we build
- Model BPMN processes, CMMN cases and DMN rules for the agreed workflows, with human tasks and timers tested against your care rules
- Build custom delegates and message-based integrations to clinical systems, and document each interface contract and failure path
- Harden the deployment with access controls, encryption settings and logging configured to your organization's safeguards
How we hand over
- Test workflows, integrations and access rules, then deliver test results and records of what was verified
- Document the architecture, deployment steps, configuration, runbooks and the control evidence your compliance team asked for
- Train your engineers and administrators on operating, deploying and troubleshooting the engines on your own
How we support
- Support engines after handover through a retainer, covering upgrades, patching, backups and monitoring as agreed in the scope
- Plan Flowable version upgrades with your change control process, including testing against your clinical integrations
- Run security testing on the deployed workflows and APIs when your risk assessment calls for it
