Why embedded analytics over PHI is a different build for healthcare
A provider, payer or patient portal team that must show dashboards to users who should only see their own facility, panel or members faces a access problem before it faces a charting problem. Self-hosted Apache Superset and Metabase can both serve this pattern, but the HIPAA Security Rule applies to the whole stack, and no certification exists that proves compliance. The rule covers electronic protected health information that a covered entity or business associate creates, receives, maintains or transmits (45 CFR 164.302), so the BI layer, its metadata database, caches, worker processes, exports and logs all fall inside the assessment. HHS states that no Security Rule standard requires certification, so the evidence you hand a reviewer is your own documented control set and its test results.
The choice between the two tools turns on three capabilities: row-level security tied to facility or panel identifiers, SSO that carries the portal's identity into the dashboard, and logging that shows who saw which records. Superset is Apache-2.0 with no paid edition, and it supports OAuth2 providers and LDAP with group-to-role mapping through AUTH_ROLES_MAPPING, so the entitlement design sits in your identity configuration and dataset rules. Metabase's pricing page places SSO, row and column level permissions, and usage analytics and auditing in its Pro and Enterprise plans, not in Open Source or Starter, so a Metabase design that relies on those controls carries a licensing decision with it. Confirm current plan contents with the vendor before you commit.
Before scoping, ask the portal team to list every role that will see PHI, the filter key each role needs, and whether any dashboard will be public or shared outside the covered entity. Those answers determine whether you need business associate terms under 45 CFR 164.314(a)(2)(i) with your implementation partner and any hosting provider, because a partner that touches ePHI during build or support is one. Also plan for the proposed Security Rule revision published on 6 January 2025 (90 FR 898), which has no final rule as of October 2026, so design controls that can be documented against the current rule and adjusted later.
Which HIPAA and related obligations shape the analytics build
This table maps each obligation to what it means for an embedded analytics build over PHI, what an assessor will expect to see, and where builds usually fall short. Read it as a design checklist: each row changes a decision about row-level filters, identity, logging or contracts. The main takeaway is that HIPAA does not certify a platform, so the evidence you can produce from your own configuration matters more than any label.
| Obligation | Build consequence | Evidence an assessor expects | Where builds usually fail |
|---|---|---|---|
| Covered entity and business associate scope (45 CFR 164.302) | If the dashboard vendor or hosting partner handles ePHI, it is a business associate and the Security Rule applies to its copies of the data | Written map of which parties create, receive, maintain or transmit ePHI in each dashboard data flow | Teams assume a self-hosted tool is out of scope because it runs in their own cloud account |
| Administrative, physical and technical safeguards (Appendix A to Subpart C: 18 standards, 36 implementation specifications) | Each dashboard function needs a documented control mapped to a standard, with required and addressable specifications handled differently | Risk analysis, control matrix and a documented decision for each addressable specification | Controls exist in the tool but are not written down or tied to a specific standard |
| Unique user identification and automatic logoff (164.312) | Every viewer and embed session needs a traceable identity, and idle sessions need to end | Account list linked to the identity provider, session timeout settings and sample access records | Shared embedding accounts or guest sessions that cannot be traced to a person |
| Emergency access procedure and encryption (164.312) | A break-glass path to dashboards and data must exist, and data in transit and at rest must be encrypted or justified as addressable | Documented emergency access runbook, TLS configuration and storage encryption settings | Emergency access bypasses logging, or database connections use unencrypted links |
| Business associate contract terms (164.314(a)(2)(i)) | Contracts with hosting, support and subcontractors must require Security Rule compliance and incident reporting to the covered entity | Signed agreements with flow-down terms and an incident reporting path | Implementation partner or cloud provider contracts omit subcontractor flow-down |
| Penalty exposure (45 CFR 102.3) | The inflation-adjusted range is from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 for the same penalty category, so design gaps carry financial risk | Penalty table as applied to your organization's counsel review, plus a current compliance review plan | Teams treat the range as theoretical and defer access-control fixes |
| Proposed Security Rule revision (90 FR 898) | The January 2025 proposal is not final, and the Unified Agenda projects July 2027, so build to the current rule and track changes | Dated record of the rule version used for design decisions and a review cadence | Designs are built around proposed requirements that may change, or ignore them entirely |
| No HIPAA certification (HHS FAQ 2003) | No vendor badge proves compliance; assessments come from HHS OCR complaints, reviews and audits | Evidence package from your own configuration and independent assessment where you choose one | Procurement accepts a vendor claim of HIPAA compliance as proof |
| GDPR Articles 32 and 34 (EU organizations) | Access control must follow the care team's need to know, with strong authentication for external access and breach notification duties | Access matrix by role and facility, MFA evidence for remote access, breach response procedure | Dashboard access is granted by broad group membership instead of per-patient or per-facility need |
Who sees which dashboards: providers, payers and patients
Clinicians, nurses and facility managers are the audience with the widest legitimate need for identifiable data, but that need is bounded by the facility they work in and the patients in their care team. Dashboards for this group usually show census, throughput, wait times, medication or quality measures at patient level, so the row-level filter should follow facility and care team assignment rather than a single organization-wide view.
- Row-level filter key: the facility identifier and, for patient-level views, the care team or patient panel assignment. Confirm that the assignment source is maintained by the EHR or the workforce system and not by hand in the dashboard tool.
- Identity source: the hospital directory or identity provider through SSO, with group membership mapped to roles. Metabase's SSO, row and column permissions are available only on Pro and Enterprise plans, so confirm the plan before design.
- Data scope: identifiable only where the role needs it. Aggregate facility-level views should be a separate dashboard for managers.
- Logging expectation: every view and export tied to a user, time and filter value, retained for the period your HIPAA policy sets. Ask the partner which application logs are written to your own storage.
- Session control: automatic logoff and short session lifetimes, since these are addressable implementation specifications under the technical safeguards.
Check whether a "need to know" rule is written as a policy and tested with a sample of accounts that cross facilities.
Payer analysts work with claims, utilization and member-level data for risk adjustment, network analysis and quality reporting. Access should be limited to the minimum necessary for each analytic purpose, which often means pseudonymized member identifiers and member-level detail only in restricted workspaces, with aggregates published to wider audiences.
- Row-level filter key: the business line, plan, contract or analytic project, with member-level tables restricted to named roles. Treat the member identifier as PHI even when it is a pseudonym.
- Identity source: the enterprise identity provider, with group sync from the access review process. Metabase's advanced LDAP group sync and SCIM provisioning require Pro or Enterprise, so confirm this against the role model.
- Data scope: minimum necessary by default. Separate raw claims access from de-identified cohort dashboards used by product or actuarial teams.
- Logging expectation: query and export logs reviewed on a schedule, plus access reviews that remove users who change roles. Confirm which events the tool records and where they are kept.
- Business associate terms: if an external analytics firm or hosting partner touches the data, the business associate contract must flow the Security Rule terms down to subcontractors.
Ask how analysts' exports are controlled, since a dashboard that is safe to view can still leak through a CSV download.
Patient-facing dashboards, such as a personal health summary or a care plan progress view, are the highest-exposure surface because the viewer is outside the organization and authentication strength matters more than in staff tools. The safer default is to publish aggregates or cohort comparisons to patients, and to use per-patient views only where a verified, individual session governs access.
- Row-level filter key: the patient identifier resolved from the authenticated session, never from a URL parameter that a user can edit. Embedded tokens should be scoped to one patient and expire.
- Identity source: the patient portal's own identity system with multi-factor authentication, not an analyst directory. Confirm how the portal passes identity to the dashboard tool and whether the token can be replayed.
- Data scope: individual records for the signed-in patient only, and de-identified aggregates for comparisons, with small-cell suppression applied before display.
- Logging expectation: access events per patient session, retained so the organization can answer which patient viewed which record. Confirm whether the tool or the portal holds these logs.
- Security testing: access control on per-patient views should be tested against cross-patient access attempts before launch.
Review the CNIL enforcement summary of 3 September 2026 in your own risk analysis, since it concerned external access to a patient record system without multi-factor authentication.
Each audience produces a different access record, and HIPAA review depends on whether those records can be produced for a specific patient, user or time window. This tab covers what the logs should capture across all three groups and where they should live, since a dashboard tool's default logs rarely answer a compliance question on their own.
- Event coverage: logins, failed logins, dashboard views, filter values applied, exports, permission changes and administrator actions. Confirm which of these the chosen version records.
- Log integrity: logs written to storage that the dashboard administrators cannot edit, with a separate retention schedule from the analytics database.
- Review cadence: a documented schedule for sampling access, with named owners and a record of findings.
- Central record: logs forwarded into the organization's security monitoring system so they can be correlated with identity events.
- Risk analysis: the Security Rule's risk analysis and risk management specifications should name these logs as a control, and an independent assessor can then test them.
Ask the partner to show a sample log entry for one patient view and one export, so your privacy and security teams can judge completeness before go-live.
Which open source platforms fit a PHI analytics layer
A PHI analytics layer usually needs a dashboard tool, a pipeline that controls what data reaches it, and a catalog that records where data came from and who owns it. The cards below match each open source option to the constraint it addresses and name the points to confirm before any selection.
Apache Superset for role-mapped access
Superset is licensed under Apache-2.0 and has no paid edition, so the license cost is zero, but the operational work is not. It supports OAuth2 providers and LDAP, and maps directory groups to roles with AUTH_ROLES_MAPPING, which suits staff access by facility or care team. Production needs PostgreSQL or MySQL as the metadata database, and alerts, async queries and thumbnails depend on a caching layer and Celery workers. Confirm how row-level filters are applied to each dataset and how the team tests them.
Metabase open source versus Pro
Metabase is AGPL outside its enterprise directory, and the open source edition does not include SSO or row and column level permissions. Those controls require the Pro or Enterprise plan, which is what a PHI layer with per-facility filtering would need. The Pro plan lists $575 per month, or $517.50 per month billed yearly, with 10 users included, and the Enterprise plan is priced by quote from $20,000 per year. Confirm the pricing with Metabase, and confirm which LTS line your team will run, since LTS 64 reaches end of life on 1 December 2027.
Apache Airflow or Dagster for de-identification
Aggregates and de-identified extracts should be produced by a scheduled pipeline, not by analysts querying identified records from dashboards. Airflow (Apache-2.0, 3.3.2) and Dagster (Apache-2.0, 1.13.26) both author, schedule and monitor such jobs in your own infrastructure. The choice depends on whether your team prefers task-based DAGs or asset-based pipelines. Confirm the de-identification method against your privacy officer's standard, including suppression of small cell counts, and confirm that intermediate files are encrypted and access-logged.
DataHub or OpenMetadata for lineage
A HIPAA review often asks where a dashboard figure came from and who owns the dataset behind it. DataHub (v1.7.0.1) and OpenMetadata (2.0.5) are both Apache-2.0 catalogs that record lineage, ownership and classification across sources. Use them to tag which datasets contain ePHI and which are de-identified, so access rules and reviews follow the tags. Confirm that the connectors you need for your EHR, claims and warehouse sources are supported and maintained, and confirm who keeps the classifications current.
How a healthcare analytics rollout moves from data scope to HIPAA review
The sequence turns a set of clinical or operational dashboard requests into a configured, tested and documented embedded analytics service, with each phase producing evidence the covered entity's compliance team can review.
Define data scope and classify each source
The covered entity and DeployOpen list every dashboard audience, data source and field, then mark which fields are ePHI, which are limited data sets, and which can become de-identified aggregates. Patient identifiers, dates of service and facility codes are flagged individually, because each one changes the access rules. The step closes with a signed data inventory and a list of excluded fields. If a source cannot be classified, it stays out of scope until someone with clinical and privacy knowledge decides how to handle it.
Settle business associate and subcontractor terms
Before any production data moves, the parties confirm the business associate contract covers the implementation partner, the hosting provider and any subcontractor that can reach ePHI. Under 45 CFR 164.314(a)(2)(i), the contract must require Security Rule compliance, flow the same terms down to subcontractors, and require reporting of security incidents, including breaches of unsecured PHI. The output is an executed agreement and a subcontractor register. Counsel should confirm the wording, since DeployOpen does not provide legal advice.
Design the identity and row-level access model
Access is mapped from the existing identity provider to the analytics platform. Metabase Pro or Enterprise, or Superset with OAuth2 or LDAP group mapping through AUTH_ROLES_MAPPING, carry facility or patient panel attributes into row-level security rules. Unique user identification, emergency access and automatic logoff are designed here as separate controls. The output is a role matrix, a row-level rule specification for each dashboard, and test accounts that show a user sees only their own panel. Confirm the plan-dependent features with the vendor before choosing the edition.
Build the platform in staging with encrypted connections
DeployOpen deploys the chosen platform in the organization's own cloud account or data center, with a production-grade metadata database instead of the default embedded database. For Metabase, the team moves the application database from H2 to PostgreSQL using the documented load-from-h2 command, run with the same Metabase version that last wrote the H2 file. Dashboards are built against a read replica or aggregate layer so clinical systems are not queried directly. The output is a staging environment with configuration, encryption and logging documented in the system record.
Test upgrades with backup-first procedures
Upgrade testing runs in staging before any production change. For Superset, the team backs up the metadata database, runs the documented database upgrade and initialization steps, and checks the release notes for breaking changes. For Metabase, the team backs up the application database, reviews the upgrade guidance, and plans for the single-node requirement during major upgrades. The output is a tested runbook with rollback steps and a record of the version tested. Procedures are written so the same steps can be repeated on each future release.
Run security testing against access and data paths
DeployOpen tests the application, its APIs, the database connections and the embedding layer for access control failures. Test cases try to reach another facility's or patient's rows through filters, URL parameters, guest tokens and export functions. Logging is checked to confirm that views, queries and exports are recorded with user identity and time. The output is a findings report, remediation tickets and a retest result. Findings that affect ePHI are reviewed with the covered entity before go-live.
Assemble the review package for the compliance team
DeployOpen compiles the evidence the covered entity's compliance team needs for its own HIPAA review: the data inventory, business associate and subcontractor records, role and row-level rule specifications, configuration baselines, logging samples, backup and upgrade runbooks, and test results. The package maps each artifact to the relevant Security Rule standards so reviewers can trace control to evidence. It does not claim certification, since HHS states there is no HIPAA certification. The step closes when the covered entity accepts the package or lists open items.
Confirm go-live conditions and ownership
Before production access is granted, the parties confirm which open items are resolved, who approves each new dashboard, and who owns access reviews, upgrades and incident reporting after handover. The covered entity names its security and privacy contacts, and the incident reporting path is tested against the business associate contract. The output is a signed go-live checklist and a responsibility matrix. Ongoing support, upgrades and testing can be scoped separately as a retainer.
How the embedded layer connects to identity, data and logs
How does SSO and group mapping decide who sees which dashboards?
The identity provider authenticates the user, and the embedded layer maps that user's groups or claims to dashboard roles and data permissions. In Apache Superset, OAuth2 providers and LDAP are supported, and group-to-role mapping is configured with AUTH_ROLES_MAPPING. In Metabase, SSO features such as JWT, OIDC and SAML, along with advanced group sync and SCIM provisioning, require the Pro or Enterprise plan according to the pricing and docs. Confirm with the healthcare organization's identity team which claim carries the facility or care team attribute, because that claim drives the row-level filter. Document the mapping as a controlled artifact, since it is evidence of access control during a HIPAA review.
How is row-level security enforced per facility or patient panel?
Row-level security should be enforced in the database or in a governed semantic layer, not only in dashboard filters that a user can change. Metabase's row and column level permissions are a paid-plan feature, so confirm the plan before design begins. Superset relies on its data source and role configuration, so the filter logic must be tested against each data source directly. Build test accounts for each facility and panel, then verify that a query returns zero rows outside the user's scope. Ask the implementation partner to show these test results as part of the design review.
What does the metadata database and caching layer hold, and where does it run?
The metadata database stores dashboards, users, saved questions and permissions, so it can contain sensitive configuration and, depending on the tool, cached query results. Superset documents PostgreSQL and MySQL as tested options and does not recommend its SQLite default or the Docker Compose PostgreSQL container for production. Metabase recommends PostgreSQL for production and documents a one-time H2 migration. Alerts, async queries and thumbnails in Superset need the caching layer and Celery workers, typically Redis and Celery. Place all of these in the organization's own network zone, encrypt them at rest, and confirm with the security team what PHI, if any, can appear in cached results.
How is query load kept off production EHR stores?
Dashboards should query a reporting copy, such as a read replica, a data warehouse or a de-identified analytics store, rather than the live electronic health record. The data pipeline that feeds this store is a separate design decision that should be documented with the source system owner. Limit the analytics service account to read-only access on the reporting schema, and set query timeouts and caching so that a popular dashboard does not repeatedly scan large tables. Ask the EHR vendor and the clinical systems team what replication options their contracts and licenses permit before any connection is made.
How are dashboard and access logs exported to the organization's SIEM?
Logs from the embedded layer should be forwarded to the organization's SIEM so that access to PHI can be reviewed. Capture user logins, dashboard views, query text where policy allows, export events and permission changes, and keep them in a tamper-resistant store. The HIPAA Security Rule requires audit controls for systems that contain ePHI, and the reviewer will expect to see who accessed which patient panel and when. Confirm which log events each product emits, whether the paid plan includes usage auditing, and how the SIEM ingests them. Retention periods should follow the organization's own policy and legal review, not a default.
Where should the embedded analytics service sit in the healthcare network?
Place the analytics application in an internal application tier, reachable only through the organization's reverse proxy or API gateway, with the reporting database in a segment that the analytics service can reach but that patients and external users cannot. Staff access should pass through the same identity provider and multi-factor controls used for other clinical applications. Partner or patient-facing views need a separate publishing path, such as an authenticated portal that issues embed tokens. Have the network team and the implementation partner write the data flows down before deployment, because this diagram is often requested during security assessments.
What HIPAA reviewers and auditors ask for from the analytics stack
This table maps the evidence a HIPAA reviewer or OCR investigator typically asks for to the component that produces it in a self-hosted Superset or Metabase stack. Read each row as a question to answer before go-live, not as a checklist of certifications. DeployOpen prepares this evidence, but auditors and HHS OCR decide whether it is sufficient.
| Evidence item | Component that produces it | What the reviewer checks |
|---|---|---|
| Access roster of who can view which dashboards | BI application roles and groups, mapped from the identity provider | Roster matches current staff, roles follow the minimum necessary standard, and departed users are removed |
| Unique user identification records | Identity provider (SSO) and the BI application user table | Every dashboard viewer maps to one named account, with no shared logins or generic service accounts used by people |
| Audit logs of who viewed which dashboard | BI application query and usage logs, forwarded to a central log store | Logs record user, dashboard, time and filters applied, and are retained and reviewed on a defined schedule |
| Row-level filter definitions by facility or patient panel | BI application row-level security rules and the metadata database | Filters are tested per role, and reviewers can see which rule applied to which user |
| Business associate contracts for hosting and support | Contracts held by the covered entity or business associate, referenced in the risk file | Terms cover Security Rule compliance, subcontractor flow-down and incident reporting under 45 CFR 164.314 |
| Risk analysis inputs for the analytics stack | Architecture diagrams, data flow maps and pipeline logs from the data source to the BI layer | The analysis lists where ePHI is created, stored, cached and exported, including exports and scheduled reports |
| Backup and restore test records | Metadata database backups and restore test logs | Restore tests were run, the results were documented and the recovery steps match the stated recovery plan |
| Change records for upgrades and patches | Upgrade runbooks, staging test results and BI application version history | Each upgrade has a backup, a staging test, a documented breaking-change review and an approver |
What to ask an implementation partner before signing
Start with row-level security, because it is where a PHI leak is most likely to hide. Ask the partner how filters by facility or patient panel are defined in Metabase's row and column level permissions, who maintains the mapping from the identity provider to those filters, and how the partner tests that a user assigned to one facility cannot see another facility's rows through a dashboard, a drill-down, a saved question or an embedded link. Ask for the test cases, the test data set (synthetic or de-identified, not production PHI), and whether the tests are rerun after each dashboard change. Ask how minimum necessary access is documented: which roles map to which data sets, who approved each mapping, and how access reviews are scheduled. Require a written statement of which row-level and group features are on the plan you intend to run, because Metabase reserves SSO, row and column level permissions and usage auditing for its Pro and Enterprise plans, and confirm current pricing directly with Metabase before the scope is fixed.
Next, pin down business associate terms and logging. Ask whether the partner will sign a business associate agreement that covers its own engineers, support staff and any subcontractors who can reach the environment, and whether that agreement flows down the Security Rule terms as 45 CFR 164.314 requires. Ask how the partner's own access to the metadata database, the application database and server logs is granted, recorded and revoked. For logs, ask what is written, where it is stored, how long it is kept, and how it is exported to your SIEM for HIPAA review. Confirm that Metabase's audit features on your plan cover the viewing evidence you need, and that the partner's log design does not copy PHI into places that lack the same controls.
Finally, check how the written scope protects you after go-live. Ask how upgrades are tested: a staging copy of the application database and a representative data set, the Metabase upgrade steps (backup first, a single node for major migrations, and release-by-release movement from older versions), and a rollback plan tied to the Metabase version support dates. The scope should name each deliverable: the architecture and data flow diagram, the access matrix, the RLS test report, the logging and retention configuration, the backup and restore test, the upgrade runbook and the handover of administrative credentials. Each deliverable should carry an acceptance criterion and a date agreed in writing before work starts. State what is excluded, such as the EHR integration, clinical data quality or any certification, since HHS does not certify HIPAA compliance and no assessor will sign off on your program from a vendor's documents alone.
How much does healthcare embedded analytics cost and how long does it take?
What drives the cost of healthcare embedded analytics?
The cost is driven by scope, not by the software, because the main open-source options carry no license fee for the core product. The components are the hosting infrastructure, the analytics database that serves queries, the identity integration that maps staff and patient roles to filters, the de-identification pipeline that produces aggregates, security testing, and the evidence work that shows how controls operate. Each component is paid to whoever builds or runs it, so ask a quote to list them separately. Patient-facing dashboards, multiple source systems and a larger number of facilities or patient panels usually add scope in each of these areas. Confirm the required number of environments and the data volume before comparing quotes.
Which costs are one-time and which recur?
One-time costs cover architecture, configuration, row-level filter design, identity integration, de-identification logic, hardening, testing and the initial evidence package. Recurring costs cover hosting, backups, monitoring, version upgrades, security retesting and any support retainer. Upgrades matter in this category: Superset documentation says to back up the metadata database, test in staging and check UPDATING.md before each version change, and Metabase requires a backup before migrations run automatically. Metabase Pro or Enterprise subscriptions are recurring and priced per plan, so confirm current pricing directly with the vendor. DeployOpen's ongoing support, upgrades and continuous testing are offered as retainers, and their terms are set in writing per engagement.
Can our internal team build healthcare embedded analytics without a partner?
A capable platform team can deploy Apache Superset or Metabase, but healthcare embedding adds work that is easy to underestimate. The team needs skills in the analytics tool, the source database, the identity provider, HIPAA technical safeguards and security testing, and it must keep the same skills available after launch. Superset is Apache-2.0 with no paid edition, so license cost is not the constraint; staffing and operating discipline are. Ask whether your team has done a business associate review, a penetration test of embedded tokens and a documented upgrade procedure. Where any of these is missing, a fixed-scope engagement can cover that gap, with the handover defined in writing.
What does the client need to provide for an engagement?
The work needs decisions and access from three groups before build starts. Data owners must define which fields are PHI, which roles see which facilities or patient panels, and which aggregates may be shared with minimum counts. The compliance or privacy lead must confirm the minimum necessary standard, logging retention and the terms of business associate agreements with any vendor that touches ePHI. The identity team must provide SSO configuration, group structures and a test tenant. Delays usually come from unresolved access rules rather than from technical work, so ask the implementation partner for a written list of decisions and owners at the start.
Why might Metabase Pro be needed for SSO and row-level permissions?
According to Metabase's pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in the Pro and Enterprise plans, not in Open Source or Starter. Patient or facility-level filtering therefore depends on the plan you select. Metabase's Open Source and Starter plans support Google sign-in and LDAP, while JWT, OIDC and SAML require Pro or Enterprise. Pro is listed at $575 per month, or $517.50 per month billed yearly, with the first 10 users included and additional users at $12 per month. Enterprise is priced by quote starting at $20,000 per year. Confirm the current figures on the pricing page, because plan terms change, and compare them with the Apache-2.0 Superset option, which has no paid edition.
Is there a HIPAA certification that we can buy for this system?
No. HHS states that no Security Rule standard requires an entity to certify compliance, and 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. Some organizations pursue a HITRUST assessment voluntarily, and HITRUST CSF v11.9.0 is available from 24 September 2026, with e1 and i1 certifications lasting one year and r2 certifications two years. Only the assessor or certification body issues those reports. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Ask your compliance lead which evidence your assessors will expect.
How long does a healthcare embedded analytics project take?
The timeline depends on the number of source systems, the complexity of the access model, the identity integration and the evidence required, and no supplied fact gives a standard duration. Most engagements are fixed-scope, so the timeline is written into the agreed scope before work starts. Time is usually spent on four phases: access-rule and PHI decisions, data preparation and de-identification, build and identity integration, and security testing with evidence. Ask a partner to show a phased plan with named client dependencies, and check that it includes a staging environment and a tested rollback. Treat any timeline given without a written scope as an estimate, not a commitment.
How DeployOpen scopes and supports healthcare analytics
DeployOpen plans, implements and hardens self-hosted open source analytics, such as Apache Superset or Metabase, inside the health organization's own cloud accounts, data centers or private networks. For a healthcare dashboard, that means the PHI never leaves the environment the organization already governs. DeployOpen also runs security testing against the finished dashboards, APIs and access paths, and it prepares the systems, configuration records and logs that a compliance assessment will ask for. It does not issue audit reports, attestations or certifications. HIPAA has no certification, so any claim of certified compliance should be treated as a red flag, and the independent assessor or the HHS Office for Civil Rights remains the party that judges the outcome.
Most healthcare analytics engagements are fixed-scope. Before work starts, the written scope should name the dashboards and their audiences (clinical leaders, care coordinators, payer analysts or patient-facing views), the data sources, the row-level filters by facility or patient panel, the SSO and role mapping, the logging design and the environments to be delivered, such as development, staging and production. Each deliverable should have an acceptance check the health organization can run itself, for example a test account that must not see another facility's rows. Ask the partner to list what is out of scope, including any work on the source EHR, data warehouse or identity provider, because those systems often drive the timeline more than the dashboard does.
Ongoing work is usually a retainer. Superset and Metabase both need upgrades, metadata database backups and staged testing, and healthcare teams should agree in advance who performs them, how often security patches are applied and who reviews access changes. Ask for a written support description covering response expectations, change control for filter logic and a periodic access review of who can see which patient panel. Confirm the terms with the partner directly, since the specific response commitments, service levels and retainer pricing belong in the signed agreement and are not published here.
