How self-hosted file sharing supports HIPAA for ePHI
A covered entity or business associate that shares ePHI internally and with partners needs a file platform it controls, and HIPAA has no certification for that platform or for the organization. HHS states that no Security Rule standard requires certification and that it does not recognize private certifications, so the work is building and evidencing the technical safeguards in 45 CFR 164.312: encryption and decryption (164.312(a)(2)(iv)), transmission security (164.312(e)(1)) and audit controls (164.312(b)). Hosting choice does not change these obligations. A self-hosted Nextcloud deployment must meet the same standards as a cloud service, and the organization carries the evidence burden directly. Encryption and integrity controls are addressable, not optional. For each addressable specification, the organization must assess whether it is reasonable and appropriate. If it is, the control is implemented. If it is not, the organization must document why and implement an equivalent alternative measure where that is reasonable and appropriate (45 CFR 164.306(d)). In practice, this means a written decision record for each one: for example, whether server-side encryption at rest and TLS for every client connection are reasonable for the data flows in scope, and what compensating control applies if a particular path cannot be encrypted. The risk analysis should drive these decisions, and HHS guidance on risk analysis is the natural starting point. For transmission security, confirm which TLS versions and cipher suites the deployment accepts, and check that the reverse proxy, Nextcloud settings and any sync client policies enforce them. Confirm that the audit log captures file access, sharing link creation and admin changes, and that someone is assigned to review it. NIST SP 800-66 Rev. 2 maps these activities to sample questions for each standard and is a useful checklist for the evidence file. Ask your implementation partner to show you where each control is configured and where its evidence lives.
Mapping the Security Rule technical safeguards to Nextcloud configuration
This table maps each HIPAA technical safeguard that applies to ePHI sharing to what the function must do and to the Nextcloud settings that typically support it. Use it as a starting checklist for your design review, then confirm exact settings, menu paths and app names against the Nextcloud version you install. The main takeaway is that most technical safeguards depend on the surrounding stack (reverse proxy, directory, logging, backups), not on Nextcloud alone.
| Requirement | What the function must do | How to configure it in Nextcloud |
|---|---|---|
| 164.312(a)(1) access control | Allow access only to users and systems that have been granted it, with unique user identification and role-based limits on who can see ePHI. | Connect users through LDAP, OpenID Connect or SAML, group-based sharing rules, and restrict sharing to internal users for ePHI folders. Confirm which access control app and version your release supports. |
| 164.312(a)(2)(iv) encryption and decryption (addressable) | Provide a mechanism to encrypt and decrypt ePHI at rest, and document the key custody model and who can recover data. | Evaluate server-side encryption with a master key. Note that the server can read the data, so this trades administrator separation for search, preview and recovery. Confirm the current encryption module status and key management options. |
| 164.312(e)(1) transmission security | Guard against unauthorized access to ePHI in transit, including client sync, browser sessions, federation and sharing links. | Enforce HTTPS with a current TLS configuration at the reverse proxy, aligned to NIST SP 800-52. Disable plain HTTP, restrict external sharing and set link passwords and expiry. Confirm the TLS versions and cipher settings for your version. |
| 164.312(c) integrity (addressable) | Protect ePHI from improper alteration or destruction, and decide whether an integrity mechanism is needed and how it is verified. | Enable file versioning and trash bin retention, restrict delete rights on clinical folders, and use checksums or integrity checks offered by your storage layer. Document why any alternative is chosen. |
| 164.312(b) audit controls | Record and examine activity in systems that contain ePHI, including logins, file access, sharing changes and admin actions, with retention that matches your policy. | Enable the audit logging app and send logs to a central SIEM or log store with restricted access. Confirm which events are captured, the log format and retention settings for your release. |
| 164.312(d) person or entity authentication | Verify that a person or system seeking access is who it claims to be, with strong factors for remote access. | Require multi-factor authentication through the identity provider, set session timeouts, and disable legacy app passwords where possible. Confirm the second factor apps and enforcement options available. |
| 164.306(d) addressable decision | For each addressable specification, record whether it is reasonable and appropriate, implement it if so, and document an equivalent alternative if not. | Keep a decision log per specification for the ePHI deployment, linked to the risk analysis. Name the Nextcloud settings used as evidence, and the reviewer and date for each decision. |
| Antivirus on uploads (supports integrity and malware protection) | Scan files entering the platform to reduce the chance that ePHI is altered or spread by malicious content. | Configure the antivirus integration (ClamAV is bundled in Nextcloud All-in-One) and set scan actions for uploads. Confirm the scan mode, quarantine behavior and signature update process. |
What changes when no cloud vendor is a business associate
A hosted SaaS file platform would normally be a business associate that stores or processes ePHI on your behalf, so you would need a business associate agreement with it and the vendor would itself be bound by the Security Rule. When you run Nextcloud in your own cloud account or data center, the question changes. The first decision is whether any third party that can reach ePHI, such as an IaaS provider, colocation facility, managed database host or backup vendor, is a business associate, and that must be evaluated for each deployment rather than assumed. Some providers will not sign a BAA for certain services, and some services that store only encrypted data may still be in scope depending on the arrangement. Confirm the contract terms, including subcontractor flows and breach notice duties, with counsel before any ePHI is loaded.
Where no vendor is a business associate, the organization carries the full administrative, physical and technical burden itself. That covers the risk analysis, workforce access rules for administrators who can read storage or the database, physical controls over hypervisors and backup media, and the technical controls behind the encryption and audit logging covered elsewhere on this page. The Security Rule applies to covered entities and business associates alike, so a self-hosted deployment does not remove any obligation. It moves every control to your side of the shared responsibility line, where it must be documented with evidence that an auditor can test. Plan the policy set, named owners and the access review cadence before go-live, not after.
Practically, write down the boundary for each deployment: which hosting entity holds the hardware or virtual machines, who can open the hypervisor console, who holds the database and object storage credentials and where backup copies are kept. Ask each hosting provider in writing whether it will sign a BAA for the services you use and what it excludes. Treat any provider you cannot bind contractually as a reason to keep ePHI out of its environment, or to change the design. Counsel should review this analysis, since whether a given arrangement creates a business associate relationship is a legal conclusion specific to your facts.
Which open-source platforms fit a HIPAA file sharing design
A HIPAA file sharing design is only as strong as the components that touch ePHI. The cards below cover the file platform, its installer and backup tooling, the office editing layer, and the alternatives and adjacent services that must meet the same transmission, encryption and audit expectations.
Nextcloud Server as the file platform
Nextcloud Server is licensed under AGPL-3.0 and gives you sync, sharing, encryption options and audit-relevant logging on infrastructure you control. The community edition and Nextcloud Enterprise share the same core, but Enterprise adds paid support tiers and a maintenance lifecycle. Confirm which edition your risk owner expects to buy, who answers security incidents, and how long each major release stays supported. Nextcloud 35 was released on September 16, 2026, with end of life in September 2027, so plan the upgrade path before go-live.
Nextcloud All-in-One installation
Nextcloud All-in-One is the official installation method and bundles PostgreSQL, Redis caching, ClamAV antivirus, full-text search and BorgBackup-based backups. These bundled components reduce the number of separate systems your team must harden, patch and document. Check whether the bundled database, cache and backup targets meet your encryption and retention design, and whether your container platform is approved for systems holding ePHI. Backups hold ePHI too, so their encryption and access controls belong in the risk analysis.
ONLYOFFICE Docs for office editing
ONLYOFFICE Docs is a browser-based office suite that edits documents, spreadsheets, presentations, forms and PDFs, compatible with Office Open XML formats, and is licensed under AGPL-3.0. Editing means the document server receives and renders ePHI, so it sits inside your transmission and audit scope, not outside it. Confirm the connection between Nextcloud and the document server is encrypted, that document server logs are retained, and that temporary conversion files are cleaned up. Version 10.0.0 was published on October 12, 2026.
Collabora Online as the editing alternative
Collabora Online is an alternative for browser-based editing with source code licensed under the Mozilla Public License 2.0. It is a different license family from ONLYOFFICE, which matters if your legal team reviews copyleft obligations for each component separately. The editing service still receives ePHI when a user opens a file, so the same encryption, access and logging expectations apply. Ask your partner to document which editor handles which file types, and test the editor with the file formats your clinicians and billing staff actually use.
Seafile as an alternative file platform
Seafile is an alternative file sync and share platform, and its server is released under GPLv2 with an additional permission to link with OpenSSL. The license wording matters for teams that bundle the server with other components, so have counsel review it before adoption. Compare Seafile with Nextcloud on the controls that matter for ePHI: audit logging depth, external sharing restrictions, directory integration and the support model you can buy. Whichever platform you choose, the HIPAA risk analysis must cover it before any ePHI is loaded.
Adjacent ePHI services need the same controls
Mail, chat and video services often carry ePHI when users attach a file, paste a patient detail or join a clinical call. Stalwart and mailcow for mail, Mattermost and Rocket.Chat for chat, and Jitsi Meet or BigBlueButton for video each need transmission encryption, access control and audit logging if they touch ePHI. Inventory every integration that moves files between these tools and Nextcloud, because a link pasted into chat can expose a file that the file platform protects. Put each service in the HIPAA risk analysis, not only the file platform.
Evidence auditors and OCR ask for, and which component produces it
This table maps the evidence an assessor or OCR investigator is likely to request to the Nextcloud or surrounding component that generates it, and to the documents the organization must own. Read it as a list of what the organization should be able to show on request, not as certification output, since HHS does not issue or recognize HIPAA certifications. The main takeaway is that the risk analysis, its remediation plan and the NIST SP 800-66 Rev. 2 mapping are organizational records, and no platform produces them on its own.
| Evidence item | What it demonstrates | Component that produces it |
|---|---|---|
| Nextcloud audit log of ePHI file access | Who opened, shared, changed or deleted ePHI files and when, supporting the audit controls standard in 164.312(b) | Nextcloud audit logging, forwarded to a central log store that the organization controls |
| Web server TLS configuration | EPHI in transit is protected by current encryption settings, supporting 164.312(e)(1) and the encryption implementation specification | Reverse proxy or web server (Apache or nginx) TLS configuration and scan output retained with change records |
| Encryption at rest and key custody records | Where encryption keys are held and who can manage them, supporting the encryption and decryption mechanism in 164.312(a)(2)(iv) | Nextcloud server-side encryption settings, key storage configuration and key management procedure |
| Identity provider sign-in logs | Authentication events, failed logins and MFA use for every account that reaches ePHI | Directory or identity provider connected through Nextcloud LDAP, OpenID Connect or SAML backends |
| Access review records | Periodic confirmation that only current, authorized staff hold access to ePHI folders and external shares | Group and share exports from Nextcloud reviewed and signed by the data owner, with directory exports |
| Backup job records and restore test results | Backups exist, run on schedule, and have been restored successfully, supporting contingency planning | Backup tool job logs (for example, BorgBackup where deployed) plus documented restore test reports |
| Upgrade change records | Each major version was applied in sequence with pre-upgrade backups and third-party app review, keeping the platform supported | Change tickets, Nextcloud upgrade logs and backup confirmations kept by the operations team |
| Risk analysis and risk management plan | The organization identified threats to ePHI in the platform and tracked remediation, which is the core Security Rule expectation | Organization-owned documents, not produced by Nextcloud; confirm the method with counsel and the HHS risk analysis guidance |
| NIST SP 800-66 Rev. 2 control mapping | How each standard and implementation specification is met, and which evidence supports it | Organization-owned mapping workbook, built by the compliance lead; NIST describes the guide as informational, not binding |
Documenting addressable decisions for encryption and integrity
Encryption and integrity controls under the HIPAA Security Rule are addressable, so the decision you record matters as much as the control you pick. Under 45 CFR 164.306(d)(3), you must assess whether each specification is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you document why and implement an equivalent alternative measure, provided that alternative is reasonable and appropriate. For a self-hosted Nextcloud deployment, the two specifications in scope are encryption, which sits under 164.312(a)(2)(iv), and integrity controls for ePHI in transit and at rest. Start by listing each one, the Nextcloud or infrastructure component that covers it, and the owner who signed the assessment.
The encryption decision is where most teams need a written record. Under 45 CFR 164.304, encryption is an algorithmic process that makes data unreadable without a confidential process or key. In practice, the main choice is between server-side encryption, where the server holds the keys and administrators can still read data, and end-to-end encrypted folders, where clients hold the keys. Illustrative record: a clinic chooses server-side encryption with keys held in its own key store, because end-to-end folders would stop full-text search, break web editing in ONLYOFFICE or Collabora, and make recovery depend on each user's key. The record states the residual risk that administrators can read ePHI and the compensating controls, such as audit logging and restricted admin roles. Confirm current behavior of each encryption mode in your Nextcloud version before you sign the record.
A decision record is only defensible if it is reviewed. Re-open each addressable entry when Nextcloud changes major version, when you add an app that touches file content, or when the HHS proposed Security Rule revision moves forward. HHS proposed that revision on January 6, 2025 (90 FR 898), and no final rule had been published as of October 2026, so confirm its status with counsel before relying on it. Keep the assessment, the alternative measure and the sign-off in the same repository as your risk analysis. NIST SP 800-66 Rev. 2 offers sample questions you can use to test whether each record is complete.
What Nextcloud tooling alone does not satisfy
Nextcloud can enforce encryption, access and audit settings, but the Security Rule also expects an organization to run a risk program, train and discipline its people, plan for recovery, secure the facility and contract with its vendors. The cards below cover the controls a file sharing project has to document alongside the platform.
Risk analysis and risk management
The Security Rule expects a documented, enterprise-wide risk analysis of every system that touches ePHI, including the Nextcloud server, database, backup targets and sync clients, followed by a risk management plan that addresses what the analysis finds. A configured instance is an input to that analysis, not a substitute for it. Check that the analysis names the ePHI flows, the threats to each, the current controls and the owner of each treatment decision.
Workforce training and sanctions
Administrators, help desk staff and clinicians who share files all need security awareness training, and the organization must show that training happened. A written sanctions policy for workforce members who violate access rules is also required. Confirm who trains administrators on Nextcloud-specific risks, such as external share links and third-party apps, and how training records are kept.
Contingency planning and recovery testing
Backups of the Nextcloud data directory and database only count if restores are tested. The contingency plan must define data backup, disaster recovery and emergency operating procedures, and the plan must be tested and revised on a schedule the organization documents. Ask your partner for restore test records that include the database, the data directory and the configuration, with measured recovery results.
Physical security of the hosting facility
When the organization runs Nextcloud in its own data center or a colocation facility, physical safeguards for servers, storage media and workstations become its responsibility. Controls cover facility access, device and media disposal, and workstation placement. In a cloud account, the provider's shared responsibility documents shift part of this work, so confirm exactly which physical controls the provider covers and which the organization must evidence.
Business associate and vendor agreements
Any vendor that creates, receives, maintains or transmits ePHI on the organization's behalf needs a business associate agreement, and self-hosting does not remove that need for every party. Nextcloud GmbH support, a managed hosting provider, an implementation partner and a cloud infrastructure provider each need a documented role. Confirm with counsel whether each party handles ePHI in a way that requires an agreement before work begins.
Policies, access reviews and the 2025 revision
Written policies, periodic access reviews and documented review of audit logs are needed to keep the controls working. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), which would add more prescriptive requirements. It was not final as of October 2026, and the Unified Agenda projects final action for July 2027. Confirm the final rule status before planning, and build the control set so new requirements can be added without rearchitecting the platform.
How much work and cost does HIPAA file sharing take?
What drives the cost of self-hosted HIPAA file sharing with Nextcloud?
Most of the cost sits in people and hosting rather than the software itself, because Nextcloud Server is licensed under AGPL-3.0 and can be installed without a license fee. The recurring costs you should expect to price are the infrastructure you run (servers, database, storage, backups, and the separate environments for testing and recovery), a support subscription if you want one, and the staff time to administer, patch and document the platform. The one-time costs are the risk analysis, the policies and the initial configuration and migration. Ask any partner to split the quote into these components so you can see who is paid for what and what recurs each year.
What do Nextcloud Enterprise subscriptions cost and what is the minimum?
Nextcloud Enterprise is sold in Standard, Premium and Ultimate tiers with a 100-user minimum. According to Nextcloud's pricing page, list prices start at 71.29 euros, 104.99 euros and 204.75 euros per user per year respectively for 100 or more users, with lower rates from 200 users. Standard includes one year of maintenance, Premium adds a maintenance lifecycle of five or more years plus extended support hours and clustered instance support, and Ultimate adds support up to 24/7 with response times down to one hour. Confirm current figures on the vendor page before budgeting, and decide whether a support tier is required by your own risk analysis rather than by default.
How long does it take to deploy HIPAA file sharing on Nextcloud?
No supplied fact gives a reliable deployment duration, so treat any timeline as something to agree in writing rather than assume. The duration depends on how many users and systems are in scope, whether you need Active Directory or SSO integration, how much data must be migrated from existing shares, and how quickly your team can complete the risk analysis and policy work that the Security Rule requires before go-live. Ask the implementation partner for a phased plan that separates the pilot, the controls validation and the production cutover, and for the dependencies that could extend each phase.
What must our organization supply before a partner can build the platform?
The partner can install and configure the platform, but several inputs must come from your organization. You need a current risk analysis of ePHI, because the Security Rule requires an accurate and thorough assessment as the basis for your controls, and HHS guidance on risk analysis explains the expected approach. You also need written policies for access, encryption, audit review and retention, a decision on the identity source (for example, LDAP or Active Directory, OpenID Connect or SAML, as documented by Nextcloud), and named data owners who can approve who may access which folders. NIST SP 800-66 Rev. 2 provides sample questions you can use to check readiness.
Can our internal IT team run HIPAA file sharing without an outside partner?
Yes, an internal team can operate a self-hosted Nextcloud if it has the skills and time, but the operating load is continuous. Nextcloud publishes a new major version every four months and supports each for one year through monthly maintenance releases, and it does not allow skipping major releases during upgrades. Each upgrade requires a backup and a check that third-party apps are compatible, so your team must maintain a predictable upgrade calendar and test restores. Assess whether you have that capacity for the full life of the system, and consider a retainer for upgrades and support if you do not.
What does a HIPAA audit or enforcement action look like?
The HHS Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits. Its 2024 to 2025 HIPAA audits reviewed 50 covered entities' and business associates' compliance with provisions most relevant to hacking and ransomware. In an enforcement review, OCR expects evidence that you assessed risk, implemented addressable specifications or documented an equivalent alternative, and recorded and examined activity in systems containing ePHI. The penalty table in 45 CFR 102.3 sets inflation-adjusted civil money penalties that range from $145 per violation with no knowledge to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294, for penalties assessed on or after January 28, 2026.
Is there an official HIPAA certification for our file sharing platform?
No. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private organizations' certifications, and that such certifications do not prevent HHS from later finding a violation (HHS FAQ 2003). Be cautious with any vendor or consultant who sells a HIPAA certificate. What you can produce is evidence: your risk analysis, the configuration of encryption and transmission security, audit logs, access reviews and business associate agreements where a third party is involved. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications.
Will the HIPAA Security Rule change, and should we wait?
Do not wait for the change before building. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22) with comments due March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. The current rule in 45 CFR Part 164 Subpart C still applies. Design your platform so that encryption, access controls, audit logging and documentation can be tightened later, and ask your partner how they will track the proposal's status and reflect any final changes in your evidence.
How a HIPAA-aligned rollout is sequenced
The sequence turns a Nextcloud deployment into a documented ePHI environment where every encryption, transmission and audit decision has an owner, a record and a test. Each step produces evidence that the next step depends on, so the rollout can be reviewed by your compliance lead and by an independent assessor.
Map ePHI flows and data inventory
Before any server is built, your security and compliance leads list where ePHI is created, stored, synced, shared and deleted today, including desktop sync folders, mobile devices, email attachments, patient portal exchanges and partner transfers. DeployOpen facilitates the workshops and writes the inventory, and your privacy officer approves it. The step is done when every flow has a named data owner, a source system, a destination and an identified risk, and those entries feed directly into the risk analysis that HHS guidance describes.
Complete the risk analysis
Your organization performs or updates its enterprise risk analysis against the Security Rule, with the new file sharing service treated as a system that contains ePHI. Threats such as unauthorized external sharing, stolen credentials and ransomware are rated against the controls you plan to use. NIST SP 800-66 Rev. 2 provides sample questions for each standard, which helps structure the review. The step closes when the risk register lists accepted risks and the owner who accepted each one.
Record addressable decisions in writing
For each addressable implementation specification in the technical safeguards, including encryption, integrity controls and the audit control design, the team records whether the measure is reasonable and appropriate for this environment. If a measure is not adopted, the record explains why and names the equivalent alternative. Your compliance lead signs off the decision log, and it becomes part of the policy set. The step is done when no addressable specification lacks a documented decision.
Design identity, TLS and access boundaries
DeployOpen designs how users authenticate, typically by connecting Nextcloud to your existing directory through the LDAP user backend or to an identity provider using OpenID Connect or SAML, with multi-factor authentication enforced at the identity layer. The design covers TLS for all client, web and database connections, certificate management, and group-based sharing and external sharing rules. Your team reviews a configuration baseline and a test plan. The step is complete when the baseline is approved and the transmission controls can be shown working in a lab build.
Run a pilot with audit log review
A limited group of users works in the environment with real but non-production-approved data handling rules that your compliance lead defines. During the pilot, the team confirms that file access, sharing actions, login events and administrative changes appear in the audit log, and that someone is assigned to review them on a set schedule. Gaps in logging or retention are fixed before expansion. The pilot is done when the review procedure has run, its findings are documented and the audit controls behave as the design states.
Migrate data with access checks
Migration moves approved content from existing shares, cloud drives or legacy tools into the new platform in waves, with permissions mapped to the groups defined in the design. Each wave is checked for ePHI that should not be copied, for orphaned or over-shared folders, and for files that fail integrity checks. Your team signs off each wave and keeps the source systems in read-only state until the wave is confirmed. The step is complete when every wave has a reconciliation record and the legacy source is retired or access-restricted.
Test restores and document recovery
DeployOpen runs restore tests from the backup set, covering the database, the data directory and the configuration, and measures whether a restored instance returns to a known state with files, permissions and audit records intact. The results are written into a recovery runbook that your operations team can execute without the original builders. The step is done when a restore has been completed from backup, the runbook has been reviewed, and the open issues are assigned.
Schedule one-version-at-a-time upgrades
The operating model adds a recurring upgrade plan, because Nextcloud does not allow skipping major releases. Each upgrade is planned to move one major version at a time, with a backup taken before every step, third-party apps checked for compatibility and disabled until confirmed, and a rollback path defined. Your team confirms the support tier and maintenance window it expects, and the plan is added to the risk register and change records. The step is done when the first upgrade calendar is approved and the change process has been tested in a non-production copy.
How DeployOpen scopes and supports HIPAA file sharing
DeployOpen plans, implements, hardens, documents and supports self-hosted Nextcloud inside your own infrastructure, with the HIPAA Security Rule controls mapped to the configuration and evidence your team will keep. We prepare the systems and evidence for your compliance assessment, but we do not issue audit reports or certifications, which remain the work of independent auditors.
How we scope
- Written scope lists which ePHI workflows, user groups and external sharing paths the Nextcloud deployment will cover.
- Scope records where covered entity and business associate roles sit, and which hosting boundaries the Security Rule analysis must include.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- Configure encryption in transit and at rest, access controls, and audit logging against the 164.312 technical safeguard specifications.
- Integrate directory login through LDAP, OpenID Connect or SAML so access follows your identity lifecycle.
- Test access rules, external link controls, log capture and backup restores before the platform is accepted.
How we hand over
- Deliver configuration documentation, the control-to-setting mapping and the evidence each control produces.
- Provide an operations runbook covering upgrades one major version at a time, pre-upgrade backups and app compatibility checks.
- Brief administrators and security staff so your team can operate the platform and answer assessor questions directly.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover monthly maintenance review, log and access reviews, and re-testing after configuration changes.
- Support scope, response expectations and included hours are confirmed in the written agreement, not assumed.
