

Sep 23, 2026
Hospitals welcome patients and visitors every hour, yet many doors behind reception must remain restricted. A nurse moving between wards, a pharmacist collecting medication, a technician servicing plant equipment, and a visitor looking for a patient cannot all receive the same access rights. Their routes change with shifts, appointments, emergencies, and temporary assignments.
Traditional keys, shared PINs, and broadly issued staff cards make those changes difficult to manage. A lost card may still open a sensitive room until it is revoked. A delivery may arrive after the team responsible for that entrance has left. At a busy clinical threshold, an authorized person can also hold the door for someone who has not presented a credential.
A Healthcare Access Control System should therefore do more than verify a card at the main entrance. It should connect each hospital zone to an approved user group, a credential method, a time policy, and a practical response to exceptions. The terminal at the door is the visible part of that process; the hospital and its integrator define permissions, door hardware, monitoring, and emergency behavior.
CIVINTEC develops and manufactures access control hardware for this kind of multi-zone design. Its CT11, CT10, and CT9 PRO terminals offer different combinations of face verification, RFID, NFC/BLE mobile credentials, QR code options, PIN, camera, and audio assistance. The choice depends on the boundary being protected, not on selecting one model for every door. The following framework shows how to evaluate those boundaries, connect the hardware, and test the complete system before a wider rollout.
A hospital has open areas that must be easy to navigate and restricted areas where an inappropriate entry can disrupt work or expose sensitive resources. The central design task is to distinguish them without creating a maze of permissions that staff cannot maintain. This is the foundation of a hospital access control system.
Zone 1: Public entrances and reception. Patients and visitors need a clear route to registration and assistance. The question is where public circulation ends, including outside staffed hours.
Zone 2: Patient-care corridors and wards. Staff may need frequent movement, while visitors may be limited to a destination or visiting period. Access rules should reflect the hospital's own care and visitor procedures.
Zone 3: Pharmacy, medication stores, laboratories, and records rooms. These doors call for narrower permissions and a clear owner for temporary exceptions. The credential check should match the level of restriction selected by the hospital.
Zone 4: Engineering spaces and equipment rooms. Facilities staff and contractors may need episodic access to plant rooms, communications rooms, or device stores, often with a defined service window and escort policy.
Zone 5: Service entrances and deliveries. Suppliers arrive at different times from clinical staff. Their access should reach the intended receiving route, not every internal corridor.
These categories are a planning tool, not a preset clinical policy. A room's classification, the person who approves entry, and the response to an urgent request should be agreed by security, facilities, clinical operations, and the relevant hospital owner. CIVINTEC's healthcare access control solution describes the broader application; the zone map turns it into door-by-door decisions.
At a staff-only passage where the hospital has decided to use face verification, the CIVINTEC CT11 access control terminal is a model to evaluate. It combines facial recognition capability with RFID, NFC/BLE mobile credential options, a touch screen, and VoIP audio intercom. It can support a verification workflow at a selected door, but it does not decide independently who is qualified to enter a ward or who is on duty.
The value of face verification is the ability to check a person against an enrolled identity where the hospital's privacy and operating rules permit it. Before specifying that method, decide who is enrolled, how enrollment is approved, how an identity is removed, and what alternative is available when face verification is inappropriate or unsuccessful. A corridor with masks, protective equipment, or unusual lighting requires a site test; the product's face capability should not be turned into a claim that every person will be recognized in every condition.
CT11 also supports other credential approaches. That matters for a hospital with different staff populations or visitor processes: one door may use a protected RFID card application, while another uses an NFC/BLE mobile credential. The supported options do not automatically create multi-factor authentication. If the project requires two checks at a restricted opening, document the actual sequence, software rule, and authorized fallback.
The hospital's management process or connected software grants and withdraws permission. The access control terminal verifies the configured credential or identity and participates in the door-control response. A new clinician's access should follow approval, not appear merely because the device recognizes a face. The same distinction applies to temporary staff, visiting specialists, and contractors. This separation makes it possible to review who approved a permission when the person's assignment changes.

Not every person arriving at a hospital door has a pre-issued credential. A visitor may reach a controlled ward entrance after the desk closes. A technician may arrive for an urgent repair outside the usual service window. A locked portal needs a way to route those cases to a responsible person without making a shared PIN the default answer.
CT11 and the CIVINTEC CT10 access control terminal provide VoIP audio intercom capability for an integrated assistance workflow. The receiving team can speak with the person at the door and apply the hospital's verification and approval procedure. The call does not by itself establish identity, grant rights, or replace a clinical or security decision. The project must specify who receives calls, when the service is staffed, and how an approved exception is recorded.
This is audio assistance, not a built-in video call. CT10 has a camera for supported photo capture associated with RFID card and QR code reads, subject to configuration; that does not make it a facial-recognition terminal or a video intercom. If the hospital needs visual verification, the integrator should specify and validate the separate equipment and process.
A useful medical facility access control design accommodates permanent staff, rotating teams, visitors, and service personnel without giving every group a permanent general-purpose badge. CIVINTEC terminals support several credential technologies, while the hospital's software and procedures determine who receives one, where it is valid, and when it expires.
For an RFID deployment using MIFARE DESFire EV1, EV2, or EV3, the high-security question is how the card is authenticated. With an AES-protected application, correctly provisioned keys, and a configured authentication workflow, the system can reject misuse based only on a copied public card identifier. Reading the card's UID alone does not activate that protection. The integrator should verify the protected application at a sample door rather than treating “DESFire compatible” as the acceptance test.
This is a card-to-reader security decision, not a blanket guarantee against credential sharing, tailgating, or mistakes in the access list. Terminal-to-server and external-reader links need their own security review. CIVINTEC's RFID access control reader overview explains the reader, controller, credential, and software components that must be connected in the finished design.
The CIVINTEC CT9 PRO access control terminal is a credential-based option for restricted hospital doors. Its CT9 PRO specification includes a Secure Access Module, or SAM, provision. A SAM can form part of the key-handling design for a supported DESFire application. Confirm the ordered CT9 PRO submodel, whether the module is installed, how keys are managed, and which protected card operation the reader performs. A SAM slot alone does not mean the hospital has deployed AES-protected authentication.
NFC/BLE mobile credentials can be considered where the hospital has a managed issuance process. QR code access can fit a controlled visitor or contractor workflow when the customer platform checks the destination, validity period, cancellation, and reuse rule. A static QR image is not secure simply because it appears on a phone. For more on visitor planning, see CIVINTEC's visitor access control article.
Basic PIN settings can be handled at the terminal. Per-person PIN allocation or dynamic PIN workflows need the corresponding customer software and integration. Use PIN only with an explicit rule for issue, reset, revocation, and exception handling; a permanent code shared among departments can defeat the purpose of dividing the site into zones.
[block1]
Credential verification answers whether the presented credential is authorized. It does not prove that only one person crosses the threshold. Tailgating becomes most visible at staff-only corridors, pharmacies, equipment rooms, and other openings where a valid user can hold the door for someone else.
To reduce that risk, pair the selected CIVINTEC terminal with a suitable physical portal, door-position monitoring, and a response procedure. Depending on the entrance, that may mean a controlled turnstile, an interlocked vestibule, an appropriate sensor or camera, and a team that can investigate an alert. A stretcher route or accessible entrance cannot be treated like a narrow staff turnstile; clinical movement and emergency egress must be reviewed before any passage-control equipment is selected.
Anti-passback, if configured, checks credential entry and exit sequence. It is not a headcount or physical tailgating detector. A door-held-open event can indicate an exception, but the event alone does not identify everyone who passed. The hospital should test the actual doorway with normal staff movement and a defined alarm response. Security language in the project specification should describe the installed combination, not promise that a terminal alone “prevents tailgating.”
Once the zone rules are defined, the integrator can map each door to a credential approach, a model for evaluation, and the external elements required to complete the workflow. The table is a discussion guide; each recommendation is conditional on the room, door hardware, privacy requirements, and ordered terminal configuration.
Hospital zone | Access decision | CIVINTEC model to evaluate | Required system boundary |
Staff-only clinical corridor | Verify enrolled or issued staff credentials while keeping an exception route | CT11 where face verification is appropriate | Hospital permission source, door hardware, staff fallback, and site test |
Ward visitor entrance | Limit a visitor to an approved destination and period | CT10 with the relevant credential option | Customer visitor workflow, validity and cancellation rules, and audio-response team |
Pharmacy or controlled store | Apply narrower authorization and a reviewed card-security mode | CT9 PRO for a specified DESFire and SAM design | Protected application, keys, submodel confirmation, and physical door monitoring |
Engineering or plant room | Admit approved facilities staff and supervised contractors | CT9 PRO or CT10, after door review | Service approval, time policy, door status, and contractor closure process |
Service entrance | Separate supplier deliveries from clinical circulation | CT10, after site and workflow review | Receiving-team procedure, credential validity, and any external barrier control |
The choice of terminal does not make a room compliant with a particular hospital policy or local code. The matrix is most useful when every row becomes a testable door schedule: which reader is installed, what the server sends, what the lock does, what the operator sees, and who resolves an exception.
Hospital facilities managers and integrators need a product comparison that separates terminal capability from software and door-system functions. The three CIVINTEC models below share multi-credential access control foundations, but they should not be described as interchangeable.
Selection point | |||
Main role | Face-capable access control terminal for a configured identity workflow | Credential-based access control terminal with camera | Credential-based access control terminal |
Interface | 3.5-inch touch screen; Linux | 3.5-inch touch screen; Linux | 3.5-inch touch screen; Linux |
Credential options | Face; RFID (125kHz and 13.56MHz); NFC/BLE mobile credentials; optional QR code; PIN | RFID (125kHz and 13.56MHz); NFC/BLE mobile credentials; optional QR code; PIN | RFID (DESFire with SAM provision on the specified CT9 PRO model); NFC/BLE mobile credentials; optional QR code; PIN |
Camera and assistance | Facial recognition capability; VoIP audio intercom | Supported photo capture on RFID card and QR code reads, subject to configuration; VoIP audio intercom | No built-in camera or VoIP audio intercom |
Typical review point | Confirm enrollment, privacy, and face-verification conditions | Confirm capture triggers and audio-response workflow | Confirm submodel, SAM installation, protected application, and keys |
Integration boundary | Customer software, door hardware, and policies determine the finished workflow | Customer software, door hardware, and policies determine the finished workflow | Customer software, door hardware, and policies determine the finished workflow |
For CT10, confirm which RFID card and QR code events trigger still-image capture in the selected configuration. Do not describe that camera as face recognition or video intercom. CT11 provides VoIP audio assistance; CT9 PRO has neither a built-in camera nor VoIP audio intercom. No model should be credited with a hospital-wide function until the relevant software, configuration, and external equipment have been specified.
Restricted access and safe movement must be considered together. A staff-only door can be secure during routine operation yet poorly designed for a clinical emergency, network outage, or loss of power. The hospital's life-safety engineer and integrator should review each opening's lock behavior, fire-alarm interface, accessibility, and applicable approval process.
Where a door-position sensor and the chosen integration support it, the system may report a door that remains open beyond the configured threshold. Assign an operator to that alert and test the actual signal path. Do not infer that a camera automatically records every event or that an alert proves who crossed the doorway. An access log records a credential event; it is not a count of people or an immutable record of clinical activity.
For a supported local configuration, a terminal may continue using previously available authorization data when the network is interrupted. It cannot receive a new server-side revocation while disconnected. Backup power is a separate design decision. Commissioning should test valid and revoked credentials, stored events, time stamps, duplicate events, and reconnection behavior, rather than assuming that “offline mode” covers every function.
Emergency release must not be claimed from a terminal input or relay alone. The finished door, controller, alarm system, power arrangement, and local requirements determine how an exit behaves. The project team should demonstrate that behavior with the relevant stakeholders before the entrance goes into service.
CIVINTEC terminals can participate in server-managed access control designs, while supported configurations also have local operating options. The network interface and communication protocol must be distinguished: TCP/IP Ethernet is a connection method, whereas HTTP/HTTPS relates to application communication. Options such as Wi-Fi, 4G, or LoRaWAN depend on the ordered model and configuration; do not assume each is present on every terminal.
The hospital's HR, visitor, facilities, or other management system may supply approved identities and permission changes through customer software integration. CIVINTEC's SDK and device interfaces can support that work, but they do not themselves provide a complete hospital information system, clinical authorization service, or visitor-management platform. Define which system owns a person's status, which system grants door rights, and how changes are delivered to each terminal.
The CIVINTEC cloud centralized access control article describes the connected-management concept. For a hospital, a useful integration test is concrete: move one approved user to a new ward, revoke one lost credential, disconnect one door, and confirm what each operator can see and change at every step. CIVINTEC's access control hardware overview provides the broader terminal context.
A practical rollout starts with a door schedule and a small pilot rather than a hospital-wide assumption that one credential rule will work everywhere.
Map public, clinical, restricted, and service routes. Record the owner of each door and the person authorized to approve exceptions.
Define user groups and validity periods. Include rotating staff, visiting specialists, contractors, suppliers, and visitors; avoid broad permanent access where a narrower grant will work.
Select the credential and model for each boundary. Test CT11 face verification where appropriate, CT10 credential and configured photo workflows, and CT9 PRO with the specified SAM and protected RFID design where selected.
Complete the physical installation design. Specify the lock, controller or relay interface, door sensor, possible anti-tailgating equipment, alarm response, accessible passage, and emergency egress behavior.
Connect and test the customer platform. Check authorization updates, lost-card revocation, after-hours exceptions, network interruption, power failure, and event handling after reconnection.
Pilot a busy staff transition and a restricted room. Observe real use with security, facilities, IT, and clinical operations before copying the design to other buildings or departments.
This sequence gives the procurement team a practical acceptance standard. A terminal's feature list matters, but the hospital should sign off on the configured door and the workflow around it.
[block2]
A well-planned Healthcare Access Control System gives each hospital zone an access rule that staff can understand and administrators can maintain. CIVINTEC's CT11, CT10, and CT9 PRO offer distinct verification and control options. AES-protected DESFire authentication, CT9 PRO SAM provision, VoIP audio assistance, and physical anti-tailgating measures each solve a different part of the problem when correctly selected and integrated.
Initiate Technical Consultation: Contact CIVINTEC Project Engineers
Explore Product Specifications: Browse CIVINTEC Access Control Hardware Line
