Why open source ITSM for healthcare starts with the device and patient-care inventory
GLPI is the usual starting point for a health system's service desk, asset records and CMDB, and iTop fits where the CMDB model must be heavily customized. GLPI covers tickets, assets, CMDB, contracts and data center infrastructure in one platform under GPL-3.0, which suits a team that needs to bring its workstations, servers and network gear under one record set before it reaches clinical equipment. iTop becomes the stronger candidate when the organization needs many custom classes for medical devices, their clinical owners, and the links between a device, the EHR services it supports and the network segment it sits on. Either way, the typical reader is a CIO or head of IT running a service desk in its own data center or cloud account, with EHR, identity and clinical device systems that must be recorded and changed under control. Healthcare ITSM differs because the HIPAA Security Rule applies to every system that creates, receives, maintains or transmits electronic protected health information, and the service desk touches many of those systems through tickets, changes and asset moves. The rule's audit controls in 45 CFR 164.312(b) expect activity in ePHI systems to be recorded and examined, so ticket histories, change approvals and asset assignments become part of the evidence. HIPAA has no certification. HHS states that no Security Rule standard requires certifying compliance, so the organization's case rests on what it can show an OCR investigator or its own auditor: a current inventory, documented changes and retained records.
Confirm early which devices and systems hold or transmit ePHI, because that list defines the scope of your inventory and change control. Ask your clinical engineering, biomedical and security teams who owns each device record and how medical devices that cannot run a standard agent will be captured, such as through network discovery or manual entry. Check with your EHR vendor and your security team which GLPI or iTop fields, relationships and approval steps your auditors will expect to see, and which data must be retained and for how long under your own policy. Decide who approves changes to patient-care systems before you configure any workflow, since that approval record is the piece an assessor will ask for first.
Which HIPAA technical safeguards an ITSM build must support
This table maps the HIPAA technical safeguards in 45 CFR 164.312 and the business associate terms in 164.314 to specific decisions in an ITSM build on GLPI or iTop. Read each row as a build requirement, what it means for ticket data, asset records and admin access, and what evidence an assessor would expect to see. The main takeaway is that the ITSM platform itself holds ePHI references and access paths, so it belongs inside the risk analysis rather than outside it.
| Requirement | What it means for the ITSM build | Evidence to keep |
|---|---|---|
| Unique user identification (164.312(a)(2)(i), required) | Every technician, requester and admin account is individually named. Shared service desk logins are avoided. Ticket and asset changes trace to one person. | User account register, role assignments, periodic review of active accounts |
| Emergency access procedure (164.312(a)(2)(ii), required) | A documented break-glass path lets authorized staff reach ticket and CMDB data during an outage, with logging and later review. | Written procedure, sample emergency access log, test record |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Idle sessions in the web console and mobile access end after a defined period. Decide the timeout for technicians on shared clinical workstations. | Configured session timeout setting, documented rationale if an alternative is chosen |
| Encryption and decryption (164.312(a)(2)(iv), addressable) | Database, backups and attachments that hold ticket notes or device owner data are encrypted at rest, or the reason for not doing so is documented with compensating controls. | Encryption configuration, key custody record, documented decision |
| Audit controls (164.312(b)) | Logins, ticket edits, asset moves, CMDB changes and admin actions are logged. Logs cover ePHI-bearing tickets, not only configuration changes. | Log sources list, retention settings, sample review record |
| Integrity controls (164.312(c)(1)) | Protect ticket history and CMDB records from unauthorized alteration. Keep change history so an entry cannot be silently overwritten. | Integrity mechanism description, history retention settings |
| Transmission security (164.312(e)(1)) | Web console, agent-to-server inventory traffic, email notifications and integrations with monitoring or identity use encrypted channels. Notifications should not carry patient details. | TLS configuration, agent transport settings, notification template review |
| Business associate terms (164.314(a)(2)(i)) | A hosted ITSM vendor or managed support provider that can access ePHI needs a business associate contract that requires Security Rule compliance, flow-down to subcontractors and incident reporting. | Signed business associate agreement, subcontractor list, incident notice terms |
| Scope of the Security Rule (164.302) | Ticket attachments, device records linked to patients and remote support sessions may bring the ITSM platform into scope as a system that creates or maintains ePHI. | Data flow diagram and data inventory entry for the ITSM platform |
Which platforms fit a hospital service desk and why
A hospital service desk usually needs one platform for tickets and assets and a second for a detailed clinical device model, with patient-facing channels handled separately. The cards below set out where GLPI, iTop and the helpdesk tools fit and what each buyer must confirm before choosing.
GLPI as the default ITSM core
GLPI covers ITIL tickets, asset management and a CMDB under GPL-3.0, which suits a hospital that wants one service desk for incidents, requests and inventory. Authentication tries the internal database first, then LDAP, then IMAP mail servers, so the order should be set to match the directory the hospital already trusts. Confirm the PHP and MariaDB or MySQL versions your hosting supports before planning the build.
GLPI 12.0.0 admin controls
The 12.0.0 release adds a view of active user sessions with the ability to revoke them, plus step-up authentication for certain administrative actions. For a hospital these controls matter because shared workstations and privileged service desk accounts are common sources of unauthorized access. Test how step-up prompts work with your identity provider and confirm which actions the release covers before writing them into access procedures.
GLPI Network managed options
Teclib' offers GLPI Network as a self-hosted subscription and as public and private cloud services. Public cloud is priced at 19 euros per user per month and private cloud at 21 euros per user per month with a 25-user minimum, according to the GLPI Network subscriptions page. Self-hosted subscriptions start at 100 euros per month for the Basic tier. Ask whether patient-related data would sit in a hosted environment and what support level each tier includes.
iTop for a detailed clinical CMDB
iTop, licensed under AGPL-3.0, suits hospitals that need a customizable CMDB model to link clinical and medical devices to the clinical services and applications they support. Model the relationships between infusion pumps, imaging equipment, networks and care services before go-live, since changing the model later is more costly. Confirm with the vendor how the current 3.3.0 release supports your data model and whether your team can maintain it.
Zammad or osTicket for external help
Zammad (AGPL-3.0) and osTicket (GPL-2.0) are helpdesk tools suited to patient-facing or external help channels, such as a portal for patient billing questions or a vendor-facing intake. They are separate from the internal ITSM core, and mixing them into clinical service management can blur access control and retention rules. Confirm channel integrations, data residency and how patient-identifying information is handled before choosing either tool.
Deployment patterns for clinical and corporate networks
A single hospital usually runs one GLPI instance in its own data center or private cloud, reachable from corporate and clinical workstations but kept off the medical device segments. The design is simpler, but the web server still needs careful setup. The GLPI installation docs require the web server's document root to point to the public directory inside the GLPI installation, not the installation root, with URL rewriting that routes requests through index.php. Teams that skip this expose configuration and source files to the web.
- Document root: Point Apache, Nginx, lighttpd or IIS at the public directory and enable URL rewriting, then test that application files are not served directly.
- Database: Use MySQL 8.0 or MariaDB supported by the release you choose. The GLPI 12.0.0 README lists MariaDB 10.11 or later or MySQL 8.0 or later, and the installation docs for GLPI 11.0 list lower minimums, so confirm the version against the release you plan to deploy.
- Key files: Back up
glpi.keyandglpicrypt.keywith the database and files. Without them, encrypted data cannot be recovered after a restore. - Updates: Follow the update procedure in the installation docs, which requires backing up first, replacing application files and running
php bin/console db:update. Plugins are suspended after a new version is detected and must be reactivated after major updates, so schedule that step into the change record. - Agents: Keep GLPI Agent inventory traffic on the corporate segment and document which device classes are excluded.
Before go-live, confirm the document root, backup restore test and plugin reactivation steps with your own platform team and your biomedical engineering owner.
A health system with several hospitals and separate clinical network segments usually needs a clear split of duties. Clinical device records often belong to biomedical engineering, which may own the medical device inventory and its lifecycle. The service desk then consumes those records for incidents, requests and changes, rather than maintaining them. Network segmentation also affects where GLPI Agent discovery can run, so the design must state which segments receive agents, which use scheduled network discovery and which are inventoried by biomedical staff.
- Ownership model: Record in the CMDB which team is the system of record for each device class, and restrict edit rights to match.
- Segmented discovery: Place a collector or agent path in each segment that policy allows to report, and document any segment that cannot be scanned actively.
- Central or federated instances: Decide whether one GLPI instance serves all hospitals with entities, or whether each hospital runs its own. Consolidation simplifies reporting, while separate instances can reduce the blast radius of an incident.
- Access control: Use the authentication order in the GLPI user documentation (internal database, LDAP, IMAP or external methods) and connect it to the directory used for clinical staff.
- Change control: Route changes to systems that touch patient care through a separate approval path with testing and back-out evidence.
Ask your partner to show the segment map, the record owner for each device class and the approval path for changes to clinical systems.
A hospital may prefer that a partner operate the platform. Options include GLPI Network, which Teclib' offers as a managed service in public or private cloud, or a partner-operated deployment in the hospital's own cloud account. Under HIPAA, a service provider that creates, receives, maintains or transmits ePHI for the covered entity is a business associate. A business associate contract under 45 CFR 164.314(a)(2)(i) must require compliance with the Security Rule, flow the same terms to subcontractors that handle ePHI, and report security incidents to the covered entity.
- Contract first: Confirm that the business associate agreement is in place before any ticket or asset record containing patient information is created.
- Data location: Ask where tickets, attachments and inventory records are stored, and whether backups leave the agreed region.
- Subscription pricing: GLPI Network publishes per-user prices for public and private cloud and self-hosted tiers, according to the GLPI subscriptions page. Confirm current terms with the vendor, because these figures change.
- Support boundaries: Define who responds to patient-facing incidents out of hours, and who holds the keys and recovery procedures.
- Exit plan: Require an export of tickets, assets and attachments in a documented format.
Review the business associate terms, the data residency commitments and the exit export with legal and privacy counsel before signing.
How a healthcare ITSM rollout moves from device inventory to 24/7 support
This sequence takes a hospital from an unverified mix of IT and clinical device records to a reconciled CMDB, governed change control and a staffed support model. Each phase ends with a named output that the next phase depends on.
Scope systems and assess ePHI risk
The project lead and privacy and security officers agree which systems create, receive, maintain or transmit ePHI, which clinical and medical devices are in scope and which business associates touch those systems. Inputs include the existing risk analysis, network diagrams and the list of patient-care applications. The output is a signed scope statement and a register of ePHI systems that defines the boundary for every later phase. Confirm with your compliance lead that the risk analysis is current before scope is locked, because the HIPAA Security Rule applies to electronic protected health information wherever it is held.
Discover and reconcile device inventory
Agent-based discovery, for example GLPI Agent on Windows, macOS and Linux endpoints, runs alongside network discovery to collect hardware and software records. Biomedical engineering then reconciles these records against its own device registers, covering devices that cannot host an agent, such as infusion pumps, imaging systems and monitors on segmented clinical networks. The output is one inventory where each device has an owner, location, clinical department and a flag for ePHI relevance. Unresolved records go to a named exception list rather than being silently dropped.
Model the CMDB and configure ITIL processes
The team defines CMDB classes for clinical devices, clinical applications, interfaces and network segments, then links each class to owners, support groups and service levels. Incident, request, change and problem workflows are configured with categories that reflect clinical impact. The output is a documented data model and a process configuration that a reviewer can trace from a device record to the change and incident history behind it. Confirm the CMDB model with clinical engineering and the application owners before migrating historical records.
Define change control for patient-care systems
Change categories are set for patient-care systems, with approval paths that include clinical application owners, security and the on-call clinical engineer for any change that could affect patient monitoring or medication workflows. Emergency change steps are defined separately, with after-the-fact review and recorded justification. The output is an approved change procedure, sample change records showing approvals, test evidence and back-out plans, and a list of systems placed under the stricter path. Vendor-maintained devices may need separate handling, so confirm each vendor's change requirements in writing.
Integrate identity and audit logging
The ITSM platform authenticates staff through the hospital directory, using LDAP or the identity provider already in use, with role mapping that reflects the need-to-know access rules the team has defined. Administrative actions and access to ePHI-linked records are sent to central logging so that activity can be examined. The output is a tested login path, a role matrix reviewed by the security team and a log feed with a documented retention period. This phase supports the audit controls expected under 45 CFR 164.312(b), and access reviews should be scheduled in writing.
Migrate records and cut over with a support model
Historical tickets, assets and contracts are migrated in tested batches, with reconciliation reports that compare counts and sample records before and after each batch. Cutover is scheduled outside clinical peak periods and includes a rollback decision point. The support model defines the 24/7 on-call rota, escalation to clinical engineering and vendors, and the severity categories that page on-call staff. The output is a signed cutover report, a published support runbook and a tested on-call escalation path. Confirm whether your staffing covers nights and weekends in-house or through a partner.
Maintain the platform and apply GLPI updates
After go-live, the team runs scheduled reviews of inventory accuracy, open changes, access rights and log integrity. For GLPI, each update starts with a backup of the database, the files and the config directory including glpi.key and glpicrypt.key. Application files are replaced, then php bin/console db:update is run. Because plugins are suspended after a new version is detected, they are reactivated and tested after major updates. The output is a dated update record, a test result for clinical integrations and an updated inventory baseline that the next audit can review.
How change control around patient-care systems changes the design
Change control for patient-care systems needs documented approval, testing and back-out for every change that touches an EHR-connected system, an interface engine route or medical device software that the organization is permitted to modify. The ITSM change record is where that evidence should live, so the design starts with the change template: a required field for clinical impact, named approvers from clinical engineering or the application owner, a link to the test evidence, and a back-out plan that someone has actually rehearsed. In GLPI or iTop, the change record can be linked to the affected configuration items, which lets a reviewer see which interfaces and devices a change touched without reconstructing that map from memory. Confirm with your clinical engineering team which device changes are performed by the vendor under its own service process and which stay inside your change board, since the vendor's records may need to be referenced rather than duplicated.
Whether 21 CFR Part 11 applies depends on whether the system holds electronic records that support FDA-regulated activities, such as clinical trial data or certain quality records. It is not automatic for every hospital system, so confirm the scope with your quality and regulatory teams before you design the change workflow around it. Where it does apply, the expectations for audit trails, access control and electronic signatures on change approvals will shape the ITSM configuration, and that should be decided before go-live rather than retrofitted.
The CNIL fined Hopital Prive de la Loire EUR 500,000 on 3 September 2026 under GDPR Articles 32 and 34, finding that external access to its patient record system lacked VPN and multi-factor authentication. The same reasoning applies to the ITSM platform itself, because administrators, change approvers and vendor engineers with access to CMDB and change data can reach configuration details of clinical systems. Treat privileged ITSM access as in scope for the same network and authentication controls, enforce multi-factor authentication for admin and approver roles, and log administrative actions so that HIPAA audit controls under 45 CFR 164.312(b) can be evidenced.
Audit and risk management evidence an ITSM platform produces
This table maps the evidence a GLPI or iTop deployment can produce to the component that generates it and the HIPAA provision it supports. Read each row as a question an auditor or HHS investigator may ask, then confirm with your own configuration what the record actually shows. HIPAA has no certification, so the goal is evidence you can produce on request during a complaint, compliance review or audit.
| Evidence item | Produced by | HIPAA provision it supports |
|---|---|---|
| Asset inventory with owner and location for workstations, servers and network devices | GLPI Agent inventory plus GLPI asset records with assigned owner and location fields | 164.310(d)(1) device and media controls; 164.308(a)(1)(ii)(A) risk analysis inputs |
| Inventory of clinical and medical devices with ePHI exposure flags | GLPI or iTop CMDB classes populated manually or by network discovery, reviewed by biomedical engineering | 164.308(a)(1)(ii)(A) risk analysis; 164.310(d)(1) device and media controls |
| Unique user records linked to directory identities | LDAP-backed user accounts in GLPI, with the directory as the source of truth for joiners and leavers | 164.312(a)(2)(i) unique user identification |
| Change approvals for systems that create, receive, maintain or transmit ePHI | GLPI or iTop change records with approver, implementation and back-out fields | 164.308(a)(1)(ii)(D) information system activity review; 164.308(a)(8) evaluation |
| Incident tickets with timestamps, classification and resolution notes | GLPI or iTop incident records, exported with audit history for review | 164.308(a)(6) security incident procedures; 164.308(a)(1)(ii)(D) activity review |
| Access and administrative activity logs for ITSM and clinical-adjacent systems | Application audit logs and web server logs forwarded to a SIEM for retention and review | 164.312(b) audit controls; 164.312(a)(1) access control |
| Business associate contracts and vendor records linked to supported systems | Contract and supplier records in GLPI or iTop, linked to the CMDB items they support | 164.308(b)(1) business associate contracts; 164.314(a)(2)(i) contract terms |
What do hospitals ask before hiring an ITSM partner?
What drives the cost of an open-source ITSM implementation in a hospital?
The main cost drivers are device count, integration scope, migration volume and the support hours you need. GLPI itself is licensed under GPL-3.0, so the software license is not the line item to focus on. The paid work is planning, configuration of the CMDB and clinical device classes, agent rollout, migration of existing records, integration with identity and monitoring, and testing. Ask any partner for a quote that separates one-time implementation from recurring support, and that states which devices are in scope and how many integrations are included. Ask whether the price assumes a single site or several campuses, since each one adds discovery and process work.
How long does a hospital ITSM rollout usually take?
The duration depends on the number of sites, the size of the device estate, how many integrations are in scope and how many change approvals must be coordinated with clinical teams. A single-site deployment with a limited integration set is simpler than a multi-campus rollout with clinical device inventory. Ask a partner to show the phases, the change freeze windows they must respect and the points where your biomedical engineering and clinical staff must sign off. Any timeline should be written into the agreed scope before work starts, and it should name the dependencies that could move it.
How much time must our biomedical, clinical engineering and security teams commit?
Expect real involvement from three groups: biomedical or clinical engineering for device classes, asset owners and maintenance windows, security for access control, logging and integration design, and the change advisory board for approval rules around patient-care systems. The commitment is not fixed, but it is front-loaded during design and testing. Ask the partner to list the specific decisions each group must make, who signs off on the CMDB model and what the change board needs to see before it approves a production cutover. Agree on these named contacts in the written scope.
Can our IT team run a GLPI deployment alone using the documentation?
A capable team can install GLPI from the project documentation and the README, but a hospital deployment usually needs more than an installation. The documentation covers prerequisites, web server configuration, updates and authentication options such as LDAP. It does not design a clinical device CMDB, define change rules for patient-care systems, plan migration from older records or build audit evidence for a risk assessment. Be realistic about staff time, and ask whether your team will own ongoing administration, plugin reactivation after updates and backups of the configuration keys. Many hospitals split the work: internal staff own operations, and a partner handles design, hardening and documentation.
What do GLPI Network subscription tiers tell us about recurring cost?
The GLPI Network subscription page shows that recurring costs are priced in several ways: a public cloud option at 19 euros per user per month, a private cloud option at 21 euros per user per month with a 25-user minimum, and self-hosted subscriptions from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), which includes level 3 support. These figures are list prices from the GLPI project and may change. The key lesson is that the core software is free, while support, managed hosting and marketplace plugins are the recurring costs to compare. Ask your partner which tier they assume, how it maps to your agent and asset counts, and whether it is included in the quote.
Does HIPAA compliance certify our ITSM platform or our organization?
No. There is no HIPAA certification. 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. For an ITSM project, the practical question is what evidence you can produce: audit controls under 45 CFR 164.312(b), access controls and unique user identification, and the risk analysis that covers systems holding ePHI. Ask a partner to show how their work prepares that evidence, and to explain which parts remain your responsibility and that of an independent assessor. Also check whether a business associate contract applies if a vendor hosts or supports the system.
What should a hospital ask a partner about support hours and clinical change control?
Ask how the support model handles 24/7 coverage for clinical incidents, who is on call, how severity is defined for patient-care systems, and how emergency changes are approved and documented afterward. Confirm which hours are covered by the fixed scope and which require a retainer. The partner should explain how change records link to asset and CMDB entries so you can show who approved a change and what was affected. Get written answers on response expectations and escalation paths, and do not accept a general statement as a substitute for a service description.
Questions to put to an implementation partner before signing
Start with the CMDB model, because every later answer depends on it. Ask how the partner represents clinical and medical devices: whether they sit in a separate class or are tagged within the standard hardware class, which owner field records the clinical engineering or biomedical team, and how the device's location, network segment and patient-care service are linked to it. Ask who maintains the vendor, model and firmware data, and how a device that is reclassified from an IT asset to a clinical asset is handled in the record history. Request a sample configuration of the GLPI or iTop asset types, relationships and fields before scope is agreed, and confirm whether the partner will document each custom field in writing as a deliverable.
Next, ask how discovery works on medical device networks. Many clinical devices cannot run a software agent, and some vendors prohibit one, so ask which assets will be inventoried by GLPI Agent, which by network discovery, which by manual import from biomed or vendor lists, and which by reconciliation with monitoring data. Ask who approves any agent or scan on those segments, what traffic the scans generate, and whether testing happens outside clinical hours. Then ask how the partner handles 24/7 support: who is on call for the service desk, how severity is defined for patient-care systems, which escalation path reaches clinical engineering and the vendor, and how after-hours changes are logged. Ask for the written runbook and the named roles that will sign it.
Third, ask how the partner documents business associate responsibilities. Under 45 CFR 164.314(a)(2)(i), the business associate contract must require Security Rule compliance and incident reporting, and the partner's own work may make it a business associate or a subcontractor. Ask whether they will sign a business associate agreement, how their access to ePHI in tickets and logs is limited, and where support sessions are recorded. Finally, ask how they will handle GLPI updates. The GLPI update procedure requires backing up the database, files and the glpi.key and glpicrypt.key files, and since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates. Ask for the test plan, the plugin inventory and the reactivation steps. Also confirm what the fixed scope and written deliverables include: configuration documentation, the CMDB data dictionary, migration reports, training, acceptance criteria, and what a support retainer covers after go-live.
How DeployOpen scopes and supports healthcare ITSM
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted GLPI or iTop inside your own infrastructure, whether that is your cloud accounts, your data center or a segmented clinical network. The work starts with a written scope that names the processes in play (incident, request, change and problem), the asset classes to be modeled, including clinical and medical devices alongside workstations and network gear, the identity source for technicians and requesters, and the systems that must exchange data with the service desk. Scope, deliverables and timelines are agreed in writing before work begins, so a hospital can see what it is buying, what its own staff must provide and which decisions remain with the clinical engineering and information security teams.
DeployOpen also prepares the evidence that an assessment will ask for. That means configured change approval workflows, asset records with ownership and location, incident timestamps, backup and restore records and documented administrative settings for the platform. DeployOpen does not issue audit reports, attestations or certifications, and HIPAA has no certification to obtain; the HHS guidance on certification is worth reading with your compliance lead. Your privacy officer, security officer and counsel decide what the service desk must hold, and independent assessors decide whether the controls are sufficient. Before go-live, confirm with your security team whether the ITSM platform itself should receive security testing, which DeployOpen offers as a separate scoped option.
After go-live, ongoing support, upgrades and continuous testing are available as retainers, which suits a service desk that must stay on supported releases and carry its database, configuration and plugin changes through maintenance windows. Ask any partner, DeployOpen included, to state in the written scope who performs patching, who is on call for a platform outage, how plugin reactivation after a major update is handled and what happens to the platform during a clinical system change freeze. Those answers belong in the contract before the first ticket is opened.
