Why BPM for healthcare starts with PHI, not with the diagram
A clinical operations leader usually inherits the same problem: a referral starts in a clinic, moves to a scheduler, waits on a prior authorization clerk, and lands with an admissions team, and every step touches a patient's record. For that workflow, the usual short answer is a self-hosted Flowable engine running in the organization's own infrastructure. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license, so it should not be the production choice unless a commercial license is in place. The engine choice matters less than the data model around it, because the diagram is the easy part.
HIPAA applies to this workflow data as soon as it is electronic protected health information. The Security Rule covers ePHI that a covered entity or business associate creates, receives, maintains or transmits (45 CFR 164.302), and a task that carries a diagnosis code, a member ID or an admission date is ePHI wherever it is stored. Process variables are the compliance surface people miss: they are persisted in the engine database, copied into history tables, shown in task forms, written to logs and passed to integrations. Before modeling, ask the clinical and privacy teams which variables must exist, which can be replaced with a reference identifier, and which tables in the Flowable database will hold them. Confirm with the engine and your database administrator how history and audit data are retained and who can read them.
Which HIPAA Security Rule requirements shape the BPM build
This table maps the HIPAA Security Rule standards most relevant to a healthcare BPM build to concrete design decisions in the engine, task UI and vendor contracts. Read each row as requirement, build decision, and the evidence an assessor will ask to see. The main takeaway is that the Security Rule does not require a certificate, so the evidence you keep about each decision carries the weight.
| Requirement | Build decision | Evidence to keep |
|---|---|---|
| Unique user identification (164.312(a)(2)(i), required) | Every human task is claimed and completed under a named identity from the directory, with no shared service accounts for clinical or administrative users | Identity mapping in the task service, task claim and completion logs tied to user IDs |
| Emergency access procedure (164.312(a)(2)(ii), required) | Defined break-glass path that lets a named clinician advance a stalled admission or referral, with the reason captured in the process history | Documented procedure, break-glass event records and periodic review of those events |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Task UI sessions end after an inactivity period set by the covered entity, and in-progress forms are saved before logoff | Session policy configuration and test results from the task UI |
| Encryption and decryption (164.312(a)(2)(iv), addressable) | Process data at rest in the engine database and TLS for calls between engine, FHIR server and task UI, with keys held in the organization's own key management | Encryption settings for each data store and certificate inventory; confirm the exact specification choice with your compliance lead |
| Audit controls (164.312(b)) | Engine history records each task event, variable change and version used, and the history is forwarded to a log store the security team controls | Sample audit trail reconstructing one referral from start to finish, and log retention settings |
| PHI minimization in process variables | Variables carry FHIR resource references or identifiers, not clinical narratives, and sensitive values are excluded from history where the engine allows | Variable inventory per process, with a list of which fields are written to history |
| Business associate contracts (164.314(a)(2)(i)) | Hosting providers, managed database operators and support firms that can reach ePHI sign agreements requiring Security Rule compliance, flow-down to subcontractors and incident reporting | Signed business associate agreements mapped to each vendor with access to the environment |
| Security incident reporting (164.314(a)(2)(i)) | Alerts from the FHIR server and engine logs route to an incident process with a defined path to report breaches of unsecured PHI to the covered entity | Incident runbook and contract clauses on reporting timelines, which the covered entity must confirm with counsel |
| Regulatory status (no certification; proposed revision) | No HIPAA certificate exists, so build the evidence file yourself. The January 2025 proposed revision of the Security Rule is not final, so track it and confirm which requirements will apply | Compliance mapping document with a review date and an owner for tracking the rulemaking |
Which open-source engines fit healthcare workflows and why
Healthcare referral, prior authorization and admission processes need an engine that runs BPMN with human tasks, a FHIR system of record for clinical data, and integration glue that never touches PHI by accident. The cards below cover the engine choice, the licensing constraint that decides whether a build can reach production, and the components that hold and move patient data.
Flowable as the BPMN engine
Flowable is Apache-2.0 licensed and provides BPMN process execution, CMMN case management and DMN decision rules, with Java and REST APIs. For referral and prior authorization flows, the BPMN engine routes human tasks between clinical and administrative staff and keeps timers for response deadlines. Confirm which engine modules and REST endpoints your team will use, and who owns the task UI, since the engine does not ship one for clinical staff.
Flowable 8.0.0 platform requirements
Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and dropped support for Spring Boot 3, so an existing Spring Boot 3 application cannot simply be upgraded in place. The release also makes Jackson 3 the default JSON library, with a Jackson 2 compatibility layer. Check these dependencies against any integration code that serializes patient-related payloads before you commit to a version.
Database choice for the engine
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Healthcare organizations usually standardize on PostgreSQL or SQL Server, and the database holds process variables that may contain PHI, so encryption at rest, backup and access controls apply to it. Confirm the MySQL version you would use, because the configuration docs note that versions below 5.6.4 lack millisecond precision for timers.
Camunda 8 source under a non-production license
The Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. A referral or admission process that handles PHI cannot run on that source in production without a commercial agreement. Ask any partner to show the license terms for each component in the stack, including test environments that hold copies of production data.
HAPI FHIR JPA server as system of record
The HAPI FHIR JPA server is a RESTful FHIR server backed by a database, covering DSTU2, DSTU3, R4, R4B and R5. Keep clinical resources such as Patient, Encounter and ServiceRequest in this server and let the BPM engine hold only references and task state. The starter defaults to an embedded H2 database, supports PostgreSQL and Microsoft SQL Server for production, and does not support MySQL. Plan access control with the AuthorizationInterceptor and BALP audit logging, because HAPI FHIR does not provide a single security layer.
Node-RED or n8n for non-PHI glue
Node-RED is Apache-2.0 licensed, while n8n uses the Sustainable Use License and marks some files as requiring an enterprise license. Either tool can move scheduling notices or status messages between systems, but only where the flow carries no PHI or the data is handled under your own controls. Do not route FHIR payloads through a tool whose execution logs store message content unless you have reviewed that retention setting.
How to keep PHI out of process variables and audit trails
Process variables are persisted, so clinical content should never be one of them. In Flowable, variables are written to the engine database, and history tables keep a record of them for as long as the history is retained. A referral process that carries a diagnosis, a medication list or a clinical note as a variable has copied PHI into a database that the platform team, backup jobs and every reporting tool may read. The safer pattern is to store only the identifiers needed to route work: a FHIR resource reference such as Patient/{id} or ServiceRequest/{id}, a case or request number, and a status code. The clinical content stays in the FHIR server, where the access controls and audit logging of the record system apply. Before build, the design team should list every variable in every process model and mark each one as identifier, status, or clinical content. Any entry in the third group needs a documented reason or needs to move out.
Task visibility and history retention need the same care as the variables themselves. Users who can open a task can usually read its variables, so a prior authorization task visible to a scheduler should not expose the requested procedure or the diagnosis codes behind it. The access model should follow the care team's need to know: a referral coordinator sees the scheduling fields, a clinician sees the clinical reference, and the engine enforces that split rather than relying on the user interface to hide fields. The CNIL's 2026 fine on Hopital Prive de la Loire (under GDPR Articles 32 and 34) is a useful illustration of the enforcement risk: the regulator found external access without VPN or multi-factor authentication and access control that ignored the care team's need to know. Confirm with your identity team how Flowable identity service integration maps roles to task candidates, and set a written retention period for history tables that your privacy and records officers have approved.
How a healthcare BPM rollout moves from scoping to cutover
The sequence turns referral, prior authorization and admission processes into a tested, audited BPMN deployment that clinical and administrative staff accept before any live patient work moves onto it. Each phase closes with a written output that the next one depends on.
Scope processes and classify the data they carry
The team maps the referral, prior authorization and admission processes end to end, listing each handoff, system touchpoint, decision point and deadline. For every process variable, they record whether it contains PHI, which covered entity or business associate owns it, and which roles need to see it. The output is a signed scope document with a data classification register, which later drives access control, logging and retention decisions. The step is done when clinical operations, privacy and IT have each approved the register.
Decide hosting and confirm business associate terms
The organization chooses where the Flowable or Camunda engine, its database and its FHIR server will run, such as its own data center or a cloud account it controls, and documents who has administrative access to each layer. Before any ePHI reaches the environment, business associate agreements covering DeployOpen and any other vendor in the chain must be executed, with the Security Rule terms and incident reporting obligations in place. The output is an approved architecture decision record and a list of executed agreements. Ask counsel to confirm the contract terms against 45 CFR 164.314 for your specific arrangement.
Model BPMN and design human tasks with reviewers
Analysts model each in-scope process in BPMN, with separate lanes for clinical and administrative roles and explicit escalation paths for missed clinical deadlines. Clinical and administrative reviewers walk through the models and mark up task content, so each human task shows only the fields that role needs to act. Process variables are kept minimal, with identifiers passed by reference rather than copied clinical content. The output is versioned process models and approved task definitions. The step is complete when reviewers have signed off on each model and the minimum-necessary field list for every task.
Integrate FHIR servers and identity sources
Engineers connect the process engine to the FHIR server that holds the referral, coverage and encounter resources, typically through service tasks that call FHIR REST endpoints and map results into process variables. Identity is wired to the organization's directory so that task assignment follows real roles and team membership, using the identity service extension points that Flowable documents. Consent, access and audit controls are configured at the FHIR layer and at the engine layer, and tested against the access rules from the classification register. The output is a tested integration with documented resource mappings and role mappings.
Test security and validate audit logs
Security testers review the deployment for access control gaps, including whether a user can reach tasks or FHIR resources outside their care team, and whether task reassignment or variable inspection exposes PHI to unauthorized roles. The team then confirms that engine history, task actions, FHIR access events and administrative changes are captured, stored under the retention period the organization sets, and can be reconstructed for a single patient or case. Results are logged as findings with owners and retest dates. The output is a test report and an audit log validation record that the privacy and compliance leads accept.
Run a pilot limited to one service line
The rollout starts with one service line, such as a single referral pathway or one admitting unit, with real staff handling a bounded volume under agreed escalation procedures. Operations leads track stuck tasks, reassignments, timer behavior and any manual workarounds, and the team fixes model or integration defects before expanding. Support contacts and runbooks are tested during this phase. The pilot closes when the agreed exit criteria are met and the service line owner signs off in writing.
Cut over to production and manage running instances
Before cutover, the team decides which in-flight referrals and authorizations finish on the old process and which migrate to the new model, and rehearses the migration in a non-production copy. On the cutover date, production configuration, change approvals and backups are confirmed, and the old path is closed for new work. Running instances are tracked to completion, with a documented procedure for instances that need migration to a newer process version. The output is a cutover record, a migration log and a decommissioning plan for the legacy path.
Which evidence auditors and regulators ask for, and what produces it
This table maps the evidence a HIPAA assessment or regulator review typically asks for in a healthcare BPM build to the component that produces it. Read each row as a question to answer before go-live: which system generates the record, who owns it, and where it must be retained. DeployOpen prepares this evidence, but auditors and HHS OCR decide whether the safeguards meet the standard.
| Evidence item | Produced by | What the assessor checks |
|---|---|---|
| Access logs for human task routing | Flowable engine history and task audit data, plus the application's login records | Who viewed, claimed and completed each referral or prior authorization task, and whether the access matched the care team's need to know |
| Access logs for FHIR reads and writes | HAPI FHIR AuditEvent logging (BALP-style) and the reverse proxy or gateway logs | Each read or write of ePHI on the FHIR server, with user, time, resource and purpose |
| Role and identity configuration | Identity provider (LDAP or SSO) and the Flowable identity service mapping of groups to tasks | Unique user identification, role assignments, and evidence that terminated staff lost access |
| Authorization rules for FHIR resources | HAPI FHIR AuthorizationInterceptor and partition configuration, exported as versioned config | Rules that limit each role to the resources and partitions it needs, and records of changes to them |
| Encryption and backup records | Database and storage encryption settings, TLS certificates, and backup job logs with restore test results | Evidence that ePHI is encrypted in transit and at rest where addressable specifications apply, and that restores were tested |
| Process change records | Git history of BPMN and DMN models, deployment logs, and Flowable process definition versions | Who approved each process version, when it went live, and which version handled each running case |
| Business associate agreements and subcontractor list | Contract management records kept by the covered entity or business associate, mapped to each component that handles ePHI | Signed agreements that cover Security Rule compliance and subcontractor flow-down, as described in 45 CFR 164.314 |
| Security incident reporting path | Incident runbook, alert rules, and the case or ticket records created when an access anomaly is flagged | A documented route for reporting incidents, including suspected breaches of unsecured PHI, to the covered entity |
What do healthcare teams ask before building BPM in-house or with a partner?
What drives the cost and effort of a healthcare BPM build?
The biggest drivers are the number of integrations, the FHIR version and server you connect to, the complexity of the task user interface, identity integration, where the platform is hosted, and how much validation evidence the process needs. Each integration adds mapping, testing and error handling work. Costs are split between one-time work (modeling, integration build, task UI, validation documentation, migration) and recurring work (hosting, patching, upgrades, support). Ask any partner for a quote that lists each integration, each task screen and each environment separately, and that states which items are one-time and which recur.
Can a healthcare team build BPM with Flowable alone?
A capable engineering team can build with Flowable, since it is an Apache-2.0 engine that runs embedded in Spring applications or through its REST API. The harder parts usually sit outside the engine: a task user interface that clinicians will actually use, FHIR integration, access control around protected health information, clustering of the async executor, and evidence that the system meets your HIPAA Security Rule safeguards. Confirm internally whether your team has these skills, who will own the platform after go-live, and who signs off on clinical and compliance design before deciding between in-house, partner or mixed delivery.
How long does a healthcare BPM implementation usually take?
Duration depends on the number of processes, the systems each one touches, how many clinical and administrative roles approve or hand off work, and how many sign-off cycles your compliance function requires. A single referral workflow with one FHIR integration is much smaller than a prior authorization program spanning payers and admissions. Ask for a timeline tied to a written scope with named milestones, including integration testing with your FHIR server, user acceptance testing with clinical staff and a documented go-live gate. Avoid any plan that does not tie duration to those specific items.
What do clinical and compliance staff need to contribute?
Clinical staff must define routing rules, escalation paths, required fields and what a completed task means in practice, and they must test those rules against real case patterns. Compliance and privacy staff need to review which data enters process variables, how long instances and audit records are kept, who can see them, and how security incidents are reported. Both groups also need to approve the final task forms, since a form that hides required information can create clinical or privacy risk. Plan this time early, because review cycles often set the schedule more than engineering does.
Does HIPAA certification exist for a BPM platform?
No. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Any vendor or partner who claims a HIPAA certification should be asked to explain exactly what was assessed. A HITRUST assessment is a separate, voluntary framework, and DeployOpen does not issue audit reports, attestations or certifications. DeployOpen prepares systems and evidence for assessments that your auditors or certification bodies perform.
How do licenses differ for production healthcare use?
Licensing decides whether you can run the engine in production without a commercial agreement. Flowable open source is licensed under Apache-2.0, so you can run it in production under those terms. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. Check the license of every component you add, including the FHIR server, task UI framework and any analytics tools, and confirm the terms with your legal team. Commercial support, if you want it, is a separate contract with the vendor or a partner.
What should I ask a partner about FHIR and PHI handling?
Ask which FHIR version and server they will integrate with, and how they will keep protected health information out of process variables where it is not needed, using references or tokens instead of full records. Ask how access control is enforced at the process, task and API layers, how audit logs are stored and reviewed, and whether the partner will sign a business associate agreement if they handle ePHI. HAPI FHIR provides building blocks such as an AuthorizationInterceptor and BALP audit logging, but it does not provide a single complete security layer, so ask for a written design that shows how each control is implemented.
What to ask an implementation partner before signing a healthcare BPM scope
Start with the questions that decide whether the scope is safe to sign. Ask how the partner models and tests BPMN for clinical workflows: who reviews the referral, prior authorization and admission models for clinical accuracy, which test cases cover escalation and timer paths, and whether test data is synthetic or de-identified. Ask how running instances are migrated when a model changes. A referral that started under version 1 may be waiting on a clinician for weeks, so the answer should name the migration method, the rollback plan and who signs off each version before it reaches production.
Next, test the task UI and the clustering design. Ask which task UI the partner builds for clinical and administrative staff, and how PHI is masked in task lists, notifications and logs by default, with unmasking limited to users with a documented need to know. On clustering, ask how the partner configures the async executor's lock owners and lock expiration times in the shared database, how expired locks are recovered when a node fails, and how they prove that timers such as prior authorization deadlines fire exactly once across nodes. Request the test evidence, not a verbal assurance.
Finally, settle the legal and data questions in writing. Ask whether the partner will sign a business associate contract under 45 CFR 164.314(a)(2)(i) and flow the same terms to its subcontractors that handle ePHI. Ask how FHIR resource-level authorization is enforced, which HAPI FHIR building blocks such as the AuthorizationInterceptor or consent interceptors are used, and how access decisions are tested. If the organization is moving off Camunda 7 or Activiti, ask how in-flight processes are converted and which licensing terms apply to the target engine, and confirm the answer with the vendor before signing.
How DeployOpen scopes and runs a healthcare BPM engagement
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted Flowable and related platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a healthcare BPM program, the first decision is not the engine but the written scope: which referral, prior authorization or admission processes are in the first release, which FHIR server resources they read and write, which roles can see patient data in task forms, and where the audit trail is stored. Most engagements are fixed-scope, so these boundaries, the deliverables and the timelines are agreed in writing before work starts. Ask any partner to list the process variables that will carry PHI and to show where each one is persisted, logged or excluded from the engine's history.
Security testing covers two layers that clinical teams often treat as one: the workflow layer (the Flowable REST API, task inboxes, the admin console and the database behind them) and the FHIR layer (the HAPI FHIR JPA server and its authorization configuration). HAPI FHIR provides building blocks such as the AuthorizationInterceptor and consent interceptors rather than a single security layer, so the reader should confirm which of these are configured, how they are tested and who signs off on the results. On the compliance side, DeployOpen prepares systems, controls and evidence (role matrices, change records, configuration baselines, backup restore tests and audit log samples) for the assessments your organization already runs. It does not issue audit reports, attestations or certifications, and no HIPAA certification exists. Independent auditors and certification bodies make those determinations.
After go-live, most healthcare programs need upgrades, patch cycles and support for the life of the platform, so ongoing work is usually covered by a retainer rather than a new project each time. A retainer can include engine version upgrades, regression testing of models against the new release, periodic security testing and restore drills. Before signing, confirm with the partner what the retainer covers, how response is handled for incidents involving PHI, and how the partner's own access to your environment is granted, logged and removed. Quotes follow from the written scope, and DeployOpen does not publish a price list, so ask for each cost component (scope, FHIR and database work, testing, evidence preparation and retainer) to be itemized separately.
