Moodle for healthcare training

Moodle for healthcare training: why hosting decisions come first

Moodle fits healthcare training when the team controls where it runs, who can sign in and what evidence it keeps. Those three conditions decide whether the platform can support a compliance review or only hosts courses. A clinical or compliance training team usually needs course content for infection control, medication administration or sterile technique, competency records that show who was signed off for which task and when, and certificates that staff can present to managers or assessors. These records rarely sit alone. They sit beside HR systems that hold employment dates and roles, and near patient-facing systems that staff use daily, so the LMS is connected to more of the organization than its users tend to assume.

Identity is the first area where a healthcare build departs from a generic LMS. A default install that accepts local accounts and open self-registration is acceptable for a conference course but weak for records that prove a nurse was competent to perform a procedure. Plan for the workforce identity provider to be the source of truth, with account creation and suspension driven from HR. Moodle core ships authentication plugins for LDAP, OAuth 2 and external databases, and the SAML2 Single sign on plugin (auth_saml2) is commonly used for SAML 2.0. The HIPAA Security Rule requires unique user identification as a technical safeguard (45 CFR 164.312), so shared logins for clinical staff should be ruled out before rollout. Decide which roles can view competency data across departments and who can override completion, before the first course is built.

Logging and retention are where the build differs most from a standard deployment. Confirm which events are recorded for sign-ins, role changes, grade overrides and certificate issuance, where those logs are stored, and how long they are kept under your retention schedule. Certificates need a defined lifecycle: who may reissue one, whether a revoked certificate stays visible in the record, and how long completion data is kept after an employee leaves. Moodle's privacy tooling and the reporting plugins you choose will shape these answers, so test them in a non-production copy before relying on the defaults. Also confirm that your Moodle release is within security support. Moodle 4.5 LTS has security support until 4 October 2027, and the next LTS release is 5.3.

Draw the boundary with clinical systems on paper before the build starts. If training records link to patient identifiers, or if Moodle sits on the same network segment as the electronic health record, the scope of the HIPAA Security Rule may extend to the LMS. Whether training records are electronic protected health information depends on their content and how they relate to care, so confirm that position with your privacy and legal advisers. There is also no HIPAA certification: HHS has stated that no Security Rule standard requires an entity to certify compliance. DeployOpen can prepare the hosting, identity configuration, logging and documented controls that assessors will review. We do not issue certifications or audit reports; independent auditors and certification bodies do that work.

What HIPAA, NIS2 and GDPR expect from the training platform

This table sets out the HIPAA, NIS2 and GDPR obligations that can reach a Moodle deployment when training records sit next to regulated clinical systems. Read each row as a question the build must answer with an account model, a configuration, a log or a contract. The main takeaway is that identity, access and encryption settings in Moodle may fall inside the same assessment scope as the patient-data systems they connect to.

Requirement	Source	What it means for the Moodle build
HIPAA Security Rule scope	45 CFR 164.302	Applies to covered entities and business associates wherever ePHI is created, received, maintained or transmitted. Confirm with counsel whether learner records hold ePHI.
Unique user identification	45 CFR 164.312, required specification	Every learner, instructor and administrator needs an individual account. Remove shared logins and generic instructor accounts.
Emergency access procedure	45 CFR 164.312, required specification	Document how authorized staff regain access to courses and records during an outage, and log and review any break-glass account use.
Automatic logoff and encryption	45 CFR 164.312, addressable specifications	Set session timeouts, enforce HTTPS, and encrypt the database, backups and file storage, or document the alternative and the reason for it.
Business associate contract terms	45 CFR 164.314(a)(2)(i)	Hosts, support providers and subcontractors that touch ePHI need terms covering Security Rule compliance, flow-down and incident reporting.
Health sector coverage	NIS2, Directive (EU) 2022/2555, Annex I	Annex I covers healthcare providers. Confirm with your national authority whether the training environment is in scope and what incident reporting applies.
Security of processing and access control	GDPR Article 32, as applied in CNIL decision of 3 September 2026	Require VPN and multi-factor authentication for remote access, and limit access to course and learner records to a documented need to know.

Which training records count as ePHI, and who decides

Whether a Moodle course, quiz result or certificate is electronic protected health information depends on what it contains and how it links to patient care or billing, not on the fact that it lives in an LMS. The HIPAA Security Rule (45 CFR Part 164 Subpart C) applies to covered entities, meaning health plans, health care clearinghouses and covered health care providers, and to their business associates, for all ePHI they create, receive, maintain or transmit. A training platform run by a covered entity is therefore in the rule's reach only if the information in it is individually identifiable health information tied to care or payment. Your team should make that call record by record category before the first course goes live, because the answer changes the hosting, logging and access design that follows.

Training content most likely to touch patient data includes case studies or simulations built from real encounters that retain identifiers such as names, dates of service, record numbers or images. Login and activity logs deserve close attention when they can show that a named staff member opened a specific patient record, for example when a Moodle course launches a link into an EHR or when a block or LTI tool passes a patient identifier. Integrations that push data from clinical systems into Moodle, such as rosters derived from scheduling or competency records tied to a patient-facing role, also need review. Each of these can be made to fall outside scope with de-identification, separation of identifiers or by keeping clinical systems out of the integration, but that work has to be verified, not assumed.

Examples that usually do not carry patient data include generic policy modules, infection prevention videos without case details, anatomy or equipment handling quizzes, and certificates that show only a staff member's name, course title and completion date. Even these can become sensitive once they are combined with other records, so the classification should consider the whole dataset a reviewer could assemble from Moodle reports, exports and backups. Completion data for a clinical competency sign-off is a useful edge case: it is an HR and quality record in many organizations, but it may still be held alongside ePHI in a shared database or report.

Do not decide this alone in the project team. Ask your privacy officer or legal counsel to classify each data category in writing, covering course content, quiz and grade records, certificates, logs, reports and any integration payloads, and record the reasoning, the date and the reviewer. Ask them also whether any business associate agreement is needed with the hosting provider, managed Moodle service or integration vendor that will handle those categories, and what security incident reporting terms apply. The Security Rule does not require a formal certification of this decision, so the documentation itself is the evidence you will show an auditor or the HHS Office for Civil Rights if questions arise.

Plan to revisit the classification whenever the platform changes. New case study content, a new SSO or HR connector, a reporting plugin that exports user-level data, or a move to a different hosting environment can each shift a record from out of scope to in scope. Store the classification alongside the data inventory and the role-based access model, and name an owner who re-checks it at each Moodle upgrade and each major content release. Keeping this decision current is part of the ongoing operating work, and it is easier to sustain when the course design team knows which content needs a review before publication.

Moodle modules, settings and integrations that matter for clinical training

Clinical training in Moodle depends on a few build decisions that produce records an auditor, regulator or clinical lead may later inspect. These cards cover the identity, enrolment, competency, evidence and reporting parts that carry the most weight, and each one needs confirming against your target Moodle release before the design is final.

Identity sources for clinical staff

Moodle core ships authentication plugins for LDAP, OAuth 2 and external database sources. SAML 2.0 is usually added with the auth_saml2 plugin maintained by Catalyst IT, which creates users with field mapping configured in Moodle. Decide which directory is the source of truth for staff accounts, map the attributes Moodle needs such as employee ID and role, and confirm that the plugin version supports your target release, since its directory listing covers Moodle 2.7 through 5.1.

HR-driven enrolment and role mapping

Training records are only as reliable as the enrolments behind them. Map job role, department and location from the HR system to cohorts, groups and course enrolments, so staff who change roles lose access to courses they no longer need. Define who approves exceptions and how leavers are handled. Enrolment without a removal path leaves training records attached to people who should no longer hold them, so test both joiner and leaver cases before go-live.

Competency and learning outcome structures

Clinical competencies usually need a framework that links each skill to the courses and assessments that evidence it. Agree on competency names, levels and sign-off rules with clinical educators before building anything in Moodle. Learning outcomes arrived in Moodle 5.3, so check whether that feature matches the competency model your clinical governance requires before you commit to a structure, and confirm the exact behavior in your target release.

Completion and certificate records as evidence

Completion tracking and certificates are usually the first records reviewers ask to see. Decide which record is the evidence of record: the completion timestamp, the grade, or an issued certificate file. Confirm how each is retained, whether it can be exported with the learner identifier, and whether a certificate can be regenerated from stored data after an upgrade. Check whether your chosen certificate approach is in core or a plugin for your release, and record that decision.

Course and category structure for recertification

Recertification repeats the same content on a fixed interval, so the category and course layout should separate the core curriculum from annual updates and from each cycle's enrolments. Use one course per cycle or a shared template with cycle-specific cohorts, and set completion conditions so each cycle produces its own record. Plan how past cycles are archived and kept accessible for the retention period your policy sets, because reusing one course across cycles can blur the evidence trail.

Reports and admin tools for audit exports

Audit requests usually need a fixed export with learner identifier, course, attempt number, timestamps and grade, which the standard views may not produce on their own. Report plugins and admin tool plugins are the plugin types that typically hold these custom exports, so define the export fields, schedule and access rules before the build starts. Include quiz and assessment attempt logs in the design, test each export against a sample audit request, and confirm which plugins your release supports.

Hosting choices when staff records sit next to regulated systems

The hosting decision turns on one question: will a third party create, receive, maintain or transmit electronic protected health information (ePHI) on your behalf? The HIPAA Security Rule applies to covered entities and to their business associates for all ePHI they handle. If the Moodle site holds only course content and completion records with no patient data, the analysis is short. Staff training records are different. Clinical competency, license and recertification data can sit beside systems that do hold ePHI, so whether those records are ePHI is a determination to make with your privacy counsel before you choose a host. Self-hosting in your own cloud account, data center or private network keeps the platform inside arrangements you already manage, but it moves operating duties to your team. Moodle 5.1 requires 64-bit PHP 8.2 or later and one of PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. From 5.1, the web server document root must point to the /public directory. Confirm that your engineers can patch these components, keep backups tested and manage the upgrade path. Managed options, MoodleCloud or a Moodle Partner, shift those duties to the provider, and you must then confirm what the provider can see and do. For any managed host that handles ePHI, a business associate contract is required under 45 CFR 164.314(a)(2)(i). The contract must require the provider to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents to you. Ask each provider whether it will sign one, which subcontractors touch your data, and where logs, backups and replicas are stored. HIPAA has no certification to request. Ask instead for the provider's risk analysis, the scope of any independent report and the controls behind it. For each hosting option, confirm who holds the encryption keys for disks, databases and backups, and whether the provider can read plaintext. Encryption is an addressable implementation specification under 45 CFR 164.312, so document your decision either way. Define a network boundary for clinical sites, using allowlisted address ranges and a VPN for remote staff, with multi-factor authentication on every remote login. Unique user identification is a required safeguard, so Moodle accounts should map to individuals, not shared logins. In 2026, the French data protection authority, CNIL, fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34 after finding that external access to a patient record system lacked a VPN and multi-factor authentication. If staff or data subjects are in the EU, confirm where data is stored and processed for each option, and whether your organization falls under NIS2. Annex I of Directive (EU) 2022/2555 lists health as a sector of high criticality, including healthcare providers and medical device manufacturers, but whether a training function is in scope depends on your entity's status. Before requesting quotes, write a one-page hosting decision record with the answers for each option: business associate status, log and backup locations, key custody, network access model, MFA coverage and data residency.

Moodle version and server requirements to plan for

This table compares the Moodle releases a healthcare training platform is likely to run in the next planning cycle, with support end dates, minimum PHP and database versions, and the earliest version each upgrade can start from. Check each support window against your own validation and change cycle, because security support can end before a migration and its testing are complete. The main takeaway is that Moodle 5.1 and 5.3 change server requirements and web root layout, so a move to those releases usually includes PHP and database upgrades alongside the Moodle upgrade.

Release	Support dates	Minimum server software	Upgrade entry point
Moodle 4.5 LTS	Security support until 4 October 2027	Confirm in the Moodle 4.5 release notes before planning	Confirm the supported upgrade start in the Moodle 4.5 release notes
Moodle 5.1	General support until 5 October 2026; security support until 19 April 2027	64-bit PHP 8.2 or later; PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later	Start from 4.2.3 or later. From 5.1 the web root must point to /public.
Moodle 5.2	Security support until 4 October 2027	Confirm in the Moodle 5.2 release notes before planning	Confirm the supported upgrade start in the Moodle 5.2 release notes
Moodle 5.3 (next LTS)	General support until 4 October 2027; security support until 1 October 2029	64-bit PHP 8.3 or later; PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later	Start from 4.4 or later. The Classic theme is removed from core.

Compliance evidence a training platform can support

A Moodle site that holds training records for clinical staff can produce evidence for HIPAA Security Rule controls, but no certificate proves compliance. The cards below cover the settings and records to produce, the frameworks that may apply and where an independent assessor takes over. DeployOpen prepares controls and evidence, and independent auditors or certification bodies assess them.

Technical safeguards mapped to Moodle

The HIPAA technical safeguards in 45 CFR 164.312 require unique user identification and an emergency access procedure, and treat automatic logoff as addressable. In Moodle, map unique user identification to one account per person with no shared logins, and check how your authentication plugins create and disable accounts. Set session timeouts for shared workstations in clinical areas, and document a break-glass administrator procedure with named custodians and a logged review. Confirm each setting on your own site before you cite it as a control.

Encryption and external access controls

Encryption in transit and at rest are both addressable specifications, so the evidence is your documented decision and its implementation. For Moodle, that means HTTPS on every route, encrypted database connections where your database supports them, and encrypted backups and file storage. France's CNIL fined Hopital Prive de la Loire EUR 500,000 on 3 September 2026 under GDPR Articles 32 and 34, after finding that external access to its patient record system lacked VPN and multi-factor authentication. Apply the same test to remote learner and staff access to your Moodle site.

No certification, so keep evidence

HHS states that no Security Rule standard requires certifying compliance, and a private certification does not stop HHS from later finding a violation. Enforcement runs through complaints, compliance reviews and audits, so dated configuration records, access reviews and training logs are what you will show. Under 45 CFR 102.3, penalties assessed on or after 28 January 2026 range from $145 to $2,190,294 per violation. The proposed Security Rule revision of 6 January 2025 had no final rule as of October 2026, so map controls to the rule in force.

HITRUST as an optional assessment

HITRUST is a voluntary assessment, not a HIPAA requirement. CSF v11.9.0, available from 24 September 2026, is structured in 14 control categories with 49 control objectives and 156 control specifications. Its e1 and i1 certifications last one year and r2 certifications last two years, so plan for recurring assessment work. Ask which assessment type your customers or partners expect before you scope the Moodle site and its hosting.

NIST SP 800-66 as a mapping aid

NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule (February 2024), helps link Security Rule standards to practical controls. Use it to build a crosswalk from each technical safeguard to the Moodle setting, server control or procedure that proves it. The guide adds no requirements and certifies nothing, so record where your interpretation differs from it. Ask your assessor which crosswalk format they accept before the evidence pack is built.

21 CFR Part 11 for regulated training

21 CFR Part 11 covers electronic records and electronic signatures in FDA-regulated work. Training records fall under it when they support regulated research or manufacturing, such as proof that a person was trained on a validated procedure. Where it applies, check audit trails, signature controls and retention in Moodle and in any connected system. Confirm the scope with your quality function before you add the requirement to the build.

How a healthcare Moodle rollout moves from scoping to recertification

This sequence takes a healthcare training program from a defined regulatory boundary to a Moodle platform that issues auditable completion evidence, recertifies staff on schedule, and stays on a supported upgrade path. Each step closes with a check that compliance and clinical leads can verify.

Scope the data and regulatory boundary
DeployOpen works with your compliance, privacy and clinical education leads to define which staff, credential and training records will sit in Moodle, and which regulations apply to them. The team maps where those records came from, who needs to read them, and whether any health information is stored in course content or user profile fields. Your compliance staff confirm whether the HIPAA Security Rule applies to the workload, including any business associate contracts that would flow down to a hosting or support provider. The output is a written scope document listing in-scope data, excluded data, governing rules and named owners. Scoping is complete when those owners have signed off on the boundary, because every later decision depends on it. Timeline is driven by how many departments hold training records and how quickly they agree on ownership.
Decide hosting and identity
Using the boundary from the previous step, DeployOpen and your infrastructure team choose where Moodle runs, such as your data center, a private cloud account you control, or a managed provider, and how staff authenticate. Moodle core includes authentication plugins for LDAP, LTI, OAuth 2 and Shibboleth, and SAML 2.0 is commonly handled through the auth_saml2 plugin maintained by Catalyst IT, which you should verify against your identity provider's version. Decisions cover network placement, database engine, backups, encryption, logging and how external learners or contractors reach the site. The deliverable is an architecture record and identity design approved by security. The step closes when a test sign-in succeeds through the chosen identity path and the architecture record is accepted by your security team. Hosting cost and effort depend on user volume, integration count and how much of the stack your team already runs.
Design the competency and recertification structure
DeployOpen maps your clinical and compliance requirements into a competency framework: competencies, the courses or activities that build them, the assessments that prove them, and the rules that trigger renewal. Clinical educators supply the source requirements and renewal intervals, and DeployOpen translates them into Moodle structures such as competency frameworks, completion rules and certificate templates. The design also states what each certificate is evidence of, who can issue it and how an expired credential is flagged. The output is a structure document and a test course that demonstrates one full cycle from enrolment to renewal. This step is complete when clinical education leads confirm the framework matches their policy and the test cycle produces the expected records. Effort rises with the number of professional roles and the number of distinct recertification rules.
Configure courses and integrations
DeployOpen builds the production courses, enrolment rules, certificate templates and reports from the approved design, and connects Moodle to the systems that supply or consume training data, such as the HR system for enrolment and the identity provider for accounts. Integrations are scoped at this point rather than deferred, because enrolment feeds determine which records exist. Custom plugins or themes are added only where the design requires them, and each one is documented with its owner and update path. The deliverable is a configured build in a non-production environment, with a change log and integration specifications. The step closes when a sample of users moves through enrolment, completion and certificate issue without manual edits. The number of integrations and custom components is the main driver of effort here.
Test access and evidence exports with compliance staff
Compliance and privacy staff test the configured system as the people who will rely on it: learners, managers, clinical educators, auditors and administrators. The test script covers role-based access to records, the principle that staff see only the training data they need, audit logging of changes, and whether certificates and completion reports can be exported in a form that a regulator or accreditor would accept. DeployOpen records each test, the expected result, the actual result and the fix. Where an export does not meet a requirement, the team adjusts reports or retention settings and retests. The output is a signed test record and a list of accepted residual risks. The step is complete when compliance leads sign the test record. Your compliance team should confirm which evidence standards apply, since DeployOpen prepares evidence but does not issue audit reports or certifications.
Migrate existing training records
Historical training records usually live in a learning management system, a spreadsheet or an HR database, and they must be mapped to Moodle users, courses and completion states before cutover. DeployOpen profiles the source data, agrees a mapping with your records owners, and loads a sample into a test instance to check that dates, completion status and certificate references survive the move. Where the legacy record has no clean equivalent in Moodle, the team agrees whether to import, summarize or keep the legacy system read-only as an archive. The deliverable is a migration plan, a reconciliation report comparing counts and sample records, and a rollback procedure. The step closes when reconciliation shows the agreed records match and the owners accept the exceptions. Volume, data quality and the number of source systems drive the effort.
Run a pilot with one clinical unit
DeployOpen and your education team launch the platform with one clinical unit, using real staff but a limited set of courses and recertification rules. The pilot tests enrolment feeds, sign-in, notifications, completion tracking and the handling of an expired or incomplete credential under normal working conditions. Feedback is collected from learners, managers and educators, and issues are logged against the design so that changes are traceable. The pilot ends with a go or no-go review against criteria agreed in advance, covering access errors, record accuracy and support load. The output is a pilot report and an updated runbook. The step is complete when the steering group records a decision. Pilot length and unit size are set by your clinical operations, not by the platform.
Move into recertification cycles with a supported upgrade plan
After the pilot, the platform moves to full production and the first live recertification cycle starts. DeployOpen hands over runbooks for backups, restores, monitoring, access reviews and certificate issue, and agrees who handles incidents and changes. The upgrade plan is written now, not later: it names the Moodle release line in use, the support status of that line, the PHP and database versions it requires, and the steps to test an upgrade in a copy of production before applying it. Release timing follows Moodle's published schedule, so the plan should be checked against the current releases page before each cycle. The step closes when the first recertification cycle completes and the operations team runs a rehearsed upgrade or restore test. Ongoing support can be run in-house or through a retainer agreed in writing.

Questions healthcare teams ask before a Moodle build

What drives the cost and effort of a healthcare Moodle build?

Scope drives most of the cost and effort. The Moodle code is licensed under GPL-3.0, so the main spend goes to people and time. The main cost components are discovery and design of the course structure and competency framework, integration work (identity, HR feeds, reporting), custom plugins or theme changes, migration of existing courses and question banks, hardening, testing, documentation and training for staff. Some costs are one-time, such as the build itself. Others recur, such as patching, upgrades, backups, restore tests and support. Costs rise with the number of systems Moodle must connect to, the volume of content to migrate and the amount of compliance evidence you need. Ask for a written scope that lists each deliverable, the assumptions behind it and the work that falls outside it. DeployOpen provides a quote after that scope is agreed.

Are training records in Moodle considered ePHI under HIPAA?

They can be, depending on what the record contains and who holds it. ePHI is electronic protected health information that a covered entity or business associate creates, receives, maintains or transmits, and the HIPAA Security Rule applies to it (45 CFR 164.302). A completion record that identifies a patient, links to a diagnosis or sits inside a clinical workflow is likely in scope. A record that only shows an employee completed infection-control training may be treated differently under the employment-records rules, and your privacy counsel should confirm that. Map each course, report and certificate to a data class, note where patient cases appear in course content, and then decide which safeguards apply to each class.

Does a managed Moodle host need a business associate agreement?

Usually yes, when the host stores, processes or transmits ePHI on your behalf. Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. Ask any managed Moodle provider, including MoodleCloud or a Moodle Partner, whether it will sign such an agreement and which subcontractors touch your data. DeployOpen builds and runs systems inside infrastructure you control. Confirm with counsel whether any DeployOpen access to ePHI during the engagement makes DeployOpen a business associate, and put that answer in the written scope.

How long does a healthcare Moodle rollout take, and what sets the timeline?

The timeline depends on the written scope, so no general duration applies. The main drivers are the number of integrations, such as SSO, HR enrolment feeds and reporting exports, and how long each one takes to test. Migration volume matters too, including how many courses, question banks and certificates move over and how much cleanup they need. Custom plugins or theme work add build and review time. Hosting readiness, change approvals and security review often set the pace on the client side. Validation of certificates and reports needs subject-matter time from your clinical or compliance team. If you are upgrading an existing site, the starting version matters. Moodle 5.1, for example, requires an existing site to be on Moodle 4.2.3 or later. Ask the proposal for milestones, dependencies, owners and acceptance criteria for each phase.

What does our team need to provide before a Moodle build starts?

Plan to provide people, access and decisions before the build begins. Name a product owner who can approve the course structure and competency framework, and a clinical or compliance lead who owns recertification rules and certificate wording. Provide access to your identity source and to each system Moodle must connect to, a test environment with the network paths it needs, your data classification for training records, your security policies, and the course inventory and export files for any migration. Also name who signs the business associate agreement, who approves production changes, and who receives the hardening and backup evidence. Ask that the proposal list each dependency with a named owner and a date you must meet.

Can our staff run a self-hosted Moodle site after go-live?

Yes, if your team has the skills and capacity, but the recurring work is larger than the initial install. Ongoing tasks include security patching, point releases that Moodle ships every two months, major releases every six months, backups and restore tests, plugin compatibility checks, and PHP and database upgrades. Each major version changes server requirements. For example, Moodle 5.1 moved the web server document root to the /public directory, and Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17. Decide which tasks your staff will own and which go to a retainer. Ask for a runbook and a handover session in the written scope. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope.

Can DeployOpen help with HIPAA or HITRUST readiness for our Moodle site?

DeployOpen can help you prepare systems, controls and evidence for a HIPAA or HITRUST assessment, but it does not issue audit reports, attestations or certifications. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, and HHS enforces the rule through complaints, compliance reviews and audits. HITRUST certifications are issued through its assessment process by independent assessors. Readiness work can cover access control, audit logging, encryption settings, backup and recovery, and a gap review against the Security Rule standards, with evidence kept in a form an assessor can test. Agree the control set, the evidence list and the deliverables in a written scope, which is the basis for a quote.

How DeployOpen works on this

DeployOpen starts with a written scope that defines which competency frameworks, recertification cycles and certificate records Moodle must carry for your clinical and compliance training. The build, testing and handover then run inside infrastructure you control, so staff records can sit under the same controls as the regulated systems beside them.

How we scope

Inventory the courses, competency frameworks and recertification cycles your clinical and compliance teams need in Moodle.
Map which staff data Moodle receives from HR or identity systems and which records must stay out of it.
Agree hosting location, Moodle version and database engine in the written scope before any build starts.

How we build

Configure course structure, completion rules and certificate templates so each certificate can serve as training evidence.
Integrate single sign-on and enrolment sources, such as a SAML 2.0 identity provider, under the access model you approve.
Test completion tracking, certificate issuance and role-based access with your training and compliance owners before rollout.

How we hand over

Document the configuration, plugin list, backup schedule and the evidence trail for certificates and completion records.
Walk administrators through enrolment, reporting and recertification reminders so your team can run routine work.
Provide a runbook for Moodle upgrades, including the web server document root change required from Moodle 5.1.

How we support

Offer ongoing support, upgrades and security patching as a retainer if your team wants a partner to keep the platform current.
Plan Moodle release upgrades against the support windows published for each version, reviewed with your change board.
Confirm with your compliance advisers which records, retention periods and access logs your obligations require.

Moodle for healthcare training