Why an open source phone system for healthcare needs a different build
A health system or clinic group can run clinical and administrative telephony on Asterisk, with FreePBX as the common administration layer, but the build must be designed around healthcare obligations from the start. The HIPAA Security Rule does not itself mandate a specific product. It sets technical safeguards for electronic protected health information (ePHI) that any platform must meet, and the choice of Asterisk or FreePBX is only defensible if the design, configuration and evidence show how those safeguards are met. Healthcare also adds requirements that a generic office PBX project often misses: 911 dispatchable location across large campuses, clinical line availability, and voicemail that may contain PHI. The Security Rule technical standards in 45 CFR 164.312 apply to ePHI transmitted over an electronic communications network, which covers call signaling and media, voicemail, call detail records and any recording or transcription. Practically, that means encrypted SIP signaling and media where the design allows it, unique user identification for every extension and softphone account, automatic logoff on shared endpoints where addressable, and audit controls under 164.312(b) that record and examine activity. Ask your team to map each telephony data flow to these requirements, and to name who reviews call and administrative logs, how often, and where those logs are retained. Confirm with your counsel whether a telephony vendor or hosting provider is a business associate and, if so, whether the contract terms under 164.314 are in place.
Campus geography and clinical workflow change the design in ways a single-site office does not. Emergency calls from fixed and non-fixed phones must reach a public safety answering point with a location that staff can act on, which means mapping every building, floor and wing and testing each path in the dial plan. Nurse call, paging and alarm integrations depend on lines that must stay up during WAN failures, so availability needs its own design, with redundant servers, survivable trunks and documented failover tests. Voicemail deserves particular attention because messages left for clinicians can contain diagnoses or appointment details. Decide whether voicemail is stored on premises, how it is encrypted at rest, who can retrieve it, and how it is purged. Confirm each of these points against your own environment and your compliance advisers before you commit to an architecture.
Which healthcare requirements shape the phone system build
This table maps the healthcare rules and practical obligations that touch clinical telephony to what each one means for an Asterisk or FreePBX build. Read each row as a design input: the requirement on the left, where it comes from in the middle, and the build decision it forces on the right. The main takeaway is that the HIPAA Security Rule sets outcomes, not products, so the evidence proving those outcomes must be produced by your organization.
| Requirement | Source | What it means for the build |
|---|---|---|
| Transmission security for ePHI in calls and voicemail | 45 CFR 164.312(e)(1) | Encrypt SIP signaling and media (TLS and SRTP where endpoints support it), and protect voicemail and recordings in transit and at rest. Confirm each handset and trunk path. |
| Audit controls over systems holding ePHI | 45 CFR 164.312(b) | Log admin changes, call detail records, voicemail access and recording retrieval, and keep those logs centrally with defined review and retention. |
| Unique user identification | 45 CFR 164.312(a)(2)(i) | Give each clinician and staff member a separate extension and login. Avoid shared ward or nurse-station accounts for admin or voicemail access. |
| Automatic logoff | 45 CFR 164.312(a)(2)(iii) | Set idle timeouts on FreePBX admin sessions, softphone apps and shared desk endpoints, and document the chosen interval and why. |
| Business associate terms for hosting and SIP trunk providers | 45 CFR 164.314(a)(2)(i) | Any host, carrier or managed provider that handles ePHI in calls or voicemail needs a written contract requiring Security Rule compliance and incident reporting. Confirm subcontractor flow-down. |
| Direct 911 dialing and dispatchable location | 911 compliance requirements for multi-line systems (see the 911 compliance topic) | Configure direct dialing with no prefix from every handset, and send dispatchable location for each campus building, floor and remote or non-fixed phone. Test and document each site. |
| No HIPAA certification exists | HHS FAQ 2003 | No one issues a HIPAA certificate for the phone system. Your team must produce risk analysis, configuration baselines, test records and access reviews, and an auditor or HHS will judge them. |
How nurse call, paging and after-hours routing change the design
Nurse call systems carry patient-initiated alarms from bedside stations to staff devices, and many hospitals want those alerts to reach nurses' phones or badges through the same telephony estate. The integration point is usually a gateway or a SIP or analog interface that sits between the nurse call server and the PBX, so the phone system never talks to bedside hardware directly. Treat that gateway as a clinical device with its own change control, not as a line item in the phone build.
- Alert path: Map every hop from the bedside station to the nurse's handset, including the gateway, the PBX dial plan and any mobile push service.
- Failure mode to test: Simulate loss of the PBX, loss of the WAN link and loss of the gateway, then confirm which alerts still reach staff and how the nurse call system reports the fault.
- Acknowledgement: Confirm whether an alert is acknowledged on the handset, at the station or in a separate console, and who sees that acknowledgement.
- Decision to make: Decide who owns the alert chain end to end, the clinical engineering team, the nurse call vendor or the telephony partner, and who signs off on changes.
- Vendor confirmation: Ask the nurse call vendor which SIP or gateway integrations it supports and in which versions, and get that in writing before design.
Before approval, confirm with the nurse call and device vendors that the exact integration pattern is supported and that a failed or rebooted PBX does not silence alarms.
Overhead paging and bed management systems depend on zone-based audio and on accurate location data about which bed, room or unit a call relates to. The integration point is typically a paging interface, an audio gateway and a bed management feed that the phone system or a middleware service consumes. Paging is one-way, time-sensitive and often shared across units, so it needs a clear rule for priority and for which zones can be overridden.
- Zone design: Define paging zones by unit, floor or building and decide which zones a single phone or console can reach.
- Bed data feed: Confirm whether the bed management system publishes status and location in a format the telephony layer can use, and how often it updates.
- Failure mode to test: Test paging during a PBX restart, during a bed system outage and during a network segment failure, and confirm that the fallback is audible and documented.
- Access control: Decide who may page all-call or emergency zones, and log every page for later review.
- Decision to make: Choose whether paging stays on existing analog or IP hardware or moves onto the PBX, which changes the support model and the test plan.
Confirm with the paging hardware vendor which audio interfaces and integration methods it supports, and run a live drill on each zone before go-live.
After-hours routing moves calls from the day switchboard to on-call clinicians, an answering service or a nurse triage line. The integration point is the call routing logic in the PBX, combined with schedule data, escalation rules and, for some organizations, a third-party answering service connected by SIP trunk or transfer. Clinical calls routed out of hospital control create records, recording and privacy obligations that must be settled in the contract with the service provider.
- Schedule source: Decide where on-call schedules live and how the routing logic reads them, including holidays and shift changes.
- Escalation: Define ring groups, timeouts and the final fallback so that no clinical call ends in an unanswered voicemail.
- Failure mode to test: Test a missed schedule update, an unreachable answering service and a bad time zone or daylight saving change.
- Voicemail and PHI: Decide whether voicemail is disabled for clinical lines, routed to a secure mailbox or transcribed, since the content may include PHI.
- Decision to make: Decide whether the answering service is a business associate under HIPAA, and confirm that the contract requires the terms in 45 CFR 164.314(a)(2)(i).
Every after-hours path should be tested with a scripted call from each entry point and documented with the times and outcomes.
Clinic satellites often run on small local equipment or on a few trunks linked to a central campus. The integration point is the WAN link and the local survivability design, which decides whether a satellite can still place and receive clinical calls when the central PBX or the link is unavailable. Satellites also tend to have different paging, nurse call and staffing patterns from the main hospital, so one template rarely fits all.
- Survivability: Confirm whether each satellite can run local call control or use a fallback trunk when the WAN fails, and how long calls can be routed locally.
- Local emergency calls: Confirm 911 location for each satellite and each staff phone, since location data must match the building, floor and room where the call starts.
- Failure mode to test: Pull the WAN link at each satellite during business hours and confirm inbound and outbound clinical calls, paging and alerts behave as designed.
- Equipment standards: Decide whether satellites use the same handset, gateway and nurse call hardware as the main campus or a reduced set.
- Decision to make: Decide who supports the satellites after cutover, the internal team, the telephony partner or a managed provider, and what response times the contract requires.
Confirm survivability and 911 location behavior per site with the carrier and with the device vendors, and document the results for each site separately.
Which open source platforms fit healthcare telephony and why
A clinical phone system is a chain of components, and each link carries a different risk: the PBX that routes calls, the administration layer that staff use to change it, the carrier connection that brings calls in, and the voicemail and recording store that holds patient information. The cards below cover each link and the checks to complete before committing to a design.
Asterisk as the PBX engine
Asterisk is the call control engine that handles dial plans, SIP registration, queues and media handling for clinical lines, including ring groups for nurse stations and on-call physicians. Its fit depends on your team's ability to operate it, so plan the build around your own clinical call flows rather than a generic template. Confirm the current Asterisk release lifecycle and the support options before go-live, because a clinical PBX needs security fixes on a predictable schedule. Also confirm that every feature your call flows need, such as paging or nurse call integration, is supported natively or through a tested add-on.
FreePBX as the administration layer
FreePBX provides a web interface on top of Asterisk for managing extensions, ring groups, time conditions, IVR menus and call recording. It lets clinical operations staff make scheduled changes, such as after-hours or holiday routing, without editing dial plans by hand, which reduces the risk of a mistake during an overnight change. Check its licensing terms against the current project documentation, since some modules are commercial and some features may sit behind paid licenses. Confirm which modules your design depends on and whether they are covered by your support arrangement.
SIP trunk and survivability
The SIP trunk connects the PBX to the public network and is the usual point of failure for inbound clinical calls. Survivability means a second route, such as a secondary carrier, a failover SIP provider or a local gateway, so that emergency and nurse lines keep working when the primary path fails. Ask your carrier how failover is triggered, how long it takes, and whether it works for every clinic site. Test failover under load, and document which numbers keep working when the WAN is down.
Voicemail and call recording store
Voicemail and call recordings can contain protected health information, so the storage location, encryption, access list and retention period are part of the design, not an afterthought. The HIPAA Security Rule requires transmission security and audit controls for systems that hold ePHI, so log who listens to recordings and send voicemail notifications without clinical details in the message body. Confirm whether the recording module you choose supports encryption at rest, role-based playback and purge schedules, and whether a commercial add-on is needed for any of them.
How high availability and location tracking are built
Clinical telephony fails in ways that matter at the bedside, so availability, location and security have to be designed together. The cards below cover the decisions that connect a clinical PBX to the campus network, the branch sites and the audit trail that a compliance review will ask for.
Active-passive or clustered PBX pairs
Decide whether clinical lines run on an active-passive pair with replicated configuration and database, or on a clustered design with shared state. Either way, the failover target must hold the same dial plan, extension and paging data as the primary. In the lab, pull power and network from the active node during a live test call, then confirm that inbound calls to nurse lines and emergency-related numbers still route, and measure how long active calls take to recover.
Survivable behavior at clinic sites
Outlying clinics often depend on a WAN link to reach a central PBX, so a link failure can silence every phone at the site. Decide whether each clinic keeps a local survivable component that handles internal calls and local trunk access during an outage. Confirm in testing which features survive (internal dialing, paging, local emergency calling) and which do not, and document that list for the clinic managers who will field questions during an outage.
Location registry for fixed and non-fixed phones
Every extension needs a current civic location record that updates when a handset or softphone moves between wards, floors, buildings or home offices. Decide who owns the registry, how staff update it, and how the system flags phones that have no current location. Confirm that the location shown to the emergency call center matches the room a test call originated from, across every campus building and for any softphone used off premises.
Network segmentation for voice VLANs
Place handsets, paging gateways and PBX servers on dedicated voice VLANs with quality of service applied to signaling and media. Restrict which clinical systems can reach the voice segment, and block general user traffic from reaching PBX management interfaces. In the lab, saturate the data network with traffic and confirm that call audio stays intact and that a workstation on a guest or clinical VLAN cannot reach the PBX admin port.
Encryption of SIP signaling and media
Require TLS for SIP signaling and SRTP for media on every trunk and endpoint that carries patient-related conversations, including paging and nurse call gateways where supported. Confirm the encryption capability of each handset model and each SIP trunk provider before purchase, because some legacy devices and carriers may not support it. Test by capturing traffic on the voice segment and confirming that call content and credentials are not readable in clear text.
Centralized logging for audit controls
Send PBX call detail records, administrative changes, failover events and location registry edits to a central log store with restricted access and retention set by policy. Under the HIPAA Security Rule, audit controls must record and examine activity in systems that contain ePHI, so confirm which telephony events count as ePHI-bearing activity in your environment. Test by making an admin change and a failover, then confirm both appear in the central store with a user identity and timestamp.
How a healthcare telephony rollout moves from assessment to cutover
This sequence turns clinical call flows, PHI handling and 911 location requirements into a tested Asterisk or FreePBX build, then moves departments onto it in controlled phases with evidence kept for each stage.
Map clinical call flows and integrations
Working with clinical operations, nursing leads, facilities and your existing vendors, DeployOpen interviews the teams that depend on the phones and documents every call path: ED and clinic lines, nurse call and paging, overhead announcements, after-hours routing, transfers to on-call physicians and any link to the EHR or scheduling system. Each integration is listed with its owner, protocol and current failure behavior. The output is a signed requirements list that names which lines are clinical-critical and who approved that classification. The step is done when the clinical owners and the telephony lead have both signed it.
Map PHI in voicemail and recordings
Voicemail, call recordings, call detail records and any transcription service can hold protected health information, so each data store is mapped against the HIPAA Security Rule's technical safeguards in 45 CFR 164.312. The mapping covers who can retrieve messages, how mailbox notifications are sent (email or SMS content), retention periods set by your records policy, encryption in transit and at rest, and audit logging of access. Business associate terms under 45 CFR 164.314 are checked for any hosted component. The output is a voicemail and recording data handling standard that your privacy and security officers approve before configuration begins.
Design 911 location and test plan
Each campus building, floor, clinic suite and remote or softphone user is assigned a dispatchable location design that matches the rules that apply to your organization. The design identifies which phones need dynamic location updates, which need off-premises handling and how emergency call routing reaches the correct public safety answering point. A written test plan lists every site and phone class, the test calls to place, the expected location displayed to the dispatcher and the person who witnesses each test. Confirm the current rule text with your telecom counsel. The output is an approved 911 location design and test plan.
Build and test failover in the lab
DeployOpen builds the PBX cluster, trunks, dial plan and integrations in a lab that mirrors production, then runs scripted failure tests: primary node loss, trunk loss, WAN loss to a branch, database failover and loss of paging or nurse call gateways. Each test records the trigger, the observed call behavior, the time to recovery and the fallback that carried clinical calls. Failed tests are logged and retested after fixes. The output is a signed test record for each scenario, and the step is done when every clinical-critical path has a passing test with a named approver.
Pilot on one site
The approved build goes live at a single clinic or ward chosen with clinical leadership, with a rollback plan and a defined support window agreed in the written scope. Pilot users receive training on call transfers, emergency dialing, voicemail retrieval and downtime procedures. DeployOpen monitors call quality, registration, integration events and 911 call handling, and logs every incident with its root cause. The output is a pilot report that compares observed behavior with the lab test record and lists any open defects. Cutover to the next site does not start until the clinical and telecom owners accept that report.
Cut over departments in phases
Remaining departments move in an order set by clinical risk, starting with lower-acuity lines and ending with emergency, critical care and nurse call routes. Each phase has a go or no-go checklist covering number porting status, emergency location records, paging and nurse call tests, staff notification and the rollback trigger. Changes are scheduled to avoid peak clinical periods where your governance allows. The output is a cutover record per department showing the checklist, the approver and the post-move test results. The step is complete when all phases are accepted and the legacy system is retired under a documented decommissioning plan.
Collect post-cutover evidence
After go-live, DeployOpen assembles the evidence pack that your compliance and audit teams will ask for: the signed requirements list, the voicemail data handling standard, 911 design and test records, failover test records, pilot and cutover reports, access control and audit log configuration, and the change history for the dial plan. Ongoing review dates are set for test repetition after changes, and the runbook is handed over. The output is an evidence index that maps each item to the control it supports. This package prepares evidence for your assessors; it does not itself establish compliance with any framework.
What audit and regulator reviews ask for from the phone system
This table lists the evidence items a HIPAA-focused review of a clinical phone system typically asks to see, what each item demonstrates, and which PBX component or operating process produces it. Use it to plan evidence collection before an assessment, not as a checklist of passed controls. The main takeaway is that most of this evidence comes from routine operation and testing, so it must be captured on a schedule rather than assembled at audit time.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| Access control records for PBX administration | Which named staff hold admin, dialplan and provisioning rights, and when those rights were granted, changed or removed | FreePBX or Asterisk admin user accounts, directory integration, and the change ticket system that approves access |
| Call detail and audit logs | Who placed, received and changed calls and settings, with timestamps, supporting the audit controls expected under 45 CFR 164.312(b) | Asterisk CDR and CEL logs, FreePBX admin audit trail, and a central log store with retention set by policy |
| Encryption configuration for SIP and media | That signaling uses TLS and media uses SRTP where supported, and that weak protocols are disabled, supporting the transmission security expectation in 45 CFR 164.312(e)(1) | Asterisk TLS and SRTP settings, certificate inventory, and trunk configuration exported from the PBX |
| Voicemail access and retention settings | Which mailboxes exist, who can access them, how long messages persist and how deletion is enforced, relevant where voicemail may contain PHI | Voicemail configuration, mailbox access policy, retention job settings and deletion logs |
| Business associate agreements with carriers and hosting providers | That each vendor handling ePHI, including SIP trunk providers and cloud hosts, is bound to Security Rule terms and incident reporting under 45 CFR 164.314(a) | Contract file maintained by the covered entity or business associate, with signed BAAs and subcontractor flow-down terms |
| 911 test records | That direct dialing, dispatchable location and central notification worked on each tested line and site, with dated results | Test call logs from the PBX, location database entries per endpoint, and signed test records kept with the 911 configuration |
| Failover test results | That clinical lines and paging routes continue to work after a server, trunk or WAN failure, with recovery times measured | HA cluster or standby PBX test reports, trunk failover logs and monitoring history from the test window |
| Confirmation of scope and evidence owner | Which systems, sites and data are in scope, and who maintains each evidence item, which assessors ask first | Written scope document and RACI maintained by the covered entity, prepared with the implementation partner |
What do hospitals ask before hiring a partner for open source telephony?
How much effort and cost does an open source phone system for a hospital involve?
The cost depends on the scope agreed in writing, and no single figure applies to every campus. The main components are the platform work (Asterisk and FreePBX design, build, dial plans and 911 configuration), trunks and numbers from carriers, handsets and endpoints, integration with nurse call and paging systems, testing, and ongoing support. Asterisk and FreePBX are open-source, so software licensing is usually not the largest line, but commercial modules, carrier fees and clinical testing time can be. Ask each partner for a quote that separates one-time work (design, build, integration, testing, documentation) from recurring items (support, upgrades, carrier charges, hardware replacement). Ask which items are fixed-scope and which are estimated, and what changes the price if the number of sites or lines grows.
How long does a hospital telephony rollout take, and what sets the pace?
The pace is set by the clinical change window, 911 location testing, carrier porting and integration sign-off, not by the build itself. A rollout across several buildings usually moves in phases, starting with a pilot unit and a clear fallback path for each clinical line. Ask the partner to show a written schedule with named milestones, the dependencies on carriers and integration vendors, and the cutover approach for each site. Ask how many weeks the partner assumes for number porting and what happens if a port is delayed. DeployOpen does not publish timelines, so the schedule should come from the written scope for your environment.
What does the hospital need to supply for a telephony project?
The hospital supplies the decisions and access that only it can provide. Typical inputs include:
- Clinical workflow owners for nurse call, paging, after-hours routing and emergency lines, who can approve call flows and downtime procedures
- Contacts at each integration vendor for the nurse call, paging and EHR or messaging systems, with the authority to change interfaces
- Carrier contacts for SIP trunks, numbers and porting, including letters of authorization and account numbers
- Security approvals for network changes, remote SIP access, certificate management and logging
- Facilities contacts who can confirm floor plans, room numbering and dispatchable location data
Ask each partner to list these inputs in writing before the scope is signed, with the owner and the expected turnaround for each.
Can our internal staff run an open source phone system after go-live?
Internal staff can operate many daily tasks, such as adding users, changing routine settings and reviewing call reports, if they receive training and runbooks. Changes to 911 routing, dial plans, failover and clinical call flows carry more risk and usually need a controlled change process with testing before and after. Ask the partner which tasks it transfers to your team, which stay with a support retainer, and what documentation and training it provides. Also ask who responds at night and on weekends for a clinical line outage, and how upgrades are tested before they reach production. Support and upgrade retainers are available from DeployOpen, and the split of duties should be written into the scope.
How is PHI in hospital voicemail handled on an open source PBX?
Voicemail can contain protected health information, so it is handled as ePHI. The HIPAA Security Rule requires technical safeguards that guard against unauthorized access to ePHI sent over electronic networks (45 CFR 164.312(e)(1)) and audit controls that record and examine activity in systems holding ePHI (45 CFR 164.312(b)). For voicemail, confirm how recordings are stored, whether they are encrypted at rest, who can access mailboxes, how email notifications avoid including clinical content, how long messages are kept, and how deletion is logged. Ask the partner to show where audio files sit, which logs record access, and how a mailbox is reviewed after staff leave. Your privacy and compliance office should approve the design.
Is a HIPAA-compliant phone system certified, and what does the partner provide?
No, HIPAA has no 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. A partner can help prepare controls, configuration evidence, logs and documentation for your risk analysis, but it cannot issue a HIPAA certificate. Ask for a list of the evidence the partner will produce, such as configuration baselines, change records, 911 test results and access reviews, and confirm that any business associate contract required under 45 CFR 164.314(a)(2)(i) is in place before work starts. Be cautious with any vendor that claims a HIPAA certificate.
What should a hospital check about high availability for clinical lines?
Clinical lines need a defined failure plan, not only redundant servers. Ask the partner how it designs for node failure, carrier failure, WAN loss at branch sites and power loss, and which lines continue to ring or route during each event. Confirm what happens to emergency calls and nurse call integration during a failover, and how staff are told when the system is on backup. Ask for the test results from failover drills, the recovery targets the hospital must approve, and how monitoring alerts reach an on-call team. Request these details in the quote, because availability design changes both the hardware and the support model.
Which integrations and tests should a hospital require before accepting the system?
Require tests that match each clinical workflow, not only basic call completion. Typical acceptance tests include direct 911 dialing and central notification, dispatchable location for each room and mobile device, nurse call and paging triggers, after-hours routing with on-call fallback, voicemail access and deletion, and failover under controlled conditions. Ask the partner for a written test plan, test scripts, pass criteria and a record of results signed by your clinical and facilities owners. Also ask how regression tests are rerun after upgrades or dial plan changes. The test evidence is often the most useful artifact for later audits.
What to ask a telephony partner before a healthcare build
Start with 911 design for the campus, because a dispatchable location error on a hospital site costs more than any other telephony mistake. Ask the partner how each building, floor and wing is mapped to a location record in the emergency notification design, who maintains those records when wards move or rooms are renovated, and how the partner will test direct 911 dialing and location delivery from representative handsets on every site, including the ones on guest Wi-Fi, clinician softphones and mobile devices. Ask for the test scripts and the evidence pack before cutover. Confirm with your emergency communications lead and local authority which rules apply to your state and campus, since the requirements are set by the jurisdiction and the regulations you operate under, not by this page.
Next, test failure modes for the clinical lines. Ask how nurse call and paging integration behaves when the PBX, the SIP trunk or the paging gateway loses its connection, and who owns the failover path between the telephony platform and the nurse call vendor. Require a written test plan that simulates a failed primary node, a dropped trunk and a broken paging interface, with measured recovery times and the named clinical owner who signs off the result. For voicemail and call recordings, ask where audio is stored, how it is encrypted in transit and at rest under your own key management, who can play it back, and what retention period applies. Voicemail transcripts and recordings can contain protected health information, so ask how access is logged for the audit controls described in 45 CFR 164.312(b) and whether deletion is verifiable.
Finally, settle the contractual and operational terms before the build starts. Ask the partner to confirm in writing whether it will handle ePHI, and if so, to sign a business associate agreement that meets 45 CFR 164.314(a)(2)(i), with the same obligations flowed down to every subcontractor that can reach the environment, including hosting and trunk providers. Request the change control process for clinical configurations, including who approves dial plan and routing changes, how emergency routing is retested after each change, and how changes are rolled back. For after-hours support, ask for the escalation path to a named clinical owner, the response expectations written into the support schedule, and how the partner will notify your security officer of an incident involving telephony records. Keep these answers in the statement of work so they can be checked later.
How DeployOpen scopes and supports a healthcare phone system
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source telephony inside the client's own infrastructure, including healthcare sites where clinical lines cannot fail. Engagements start with a written, fixed scope that sets out what is built, tested and handed over for each campus or clinic group.
How we scope
- Inventory of sites, clinical lines, nurse call and paging systems, and emergency call paths before any design work starts.
- Written scope that names the 911 dispatchable location method, voicemail handling rules and high availability targets agreed with your team.
- Defined boundaries for integrations with existing EHR, paging and nurse call vendors, so responsibilities are clear before work begins.
How we build
- Deployment of Asterisk and FreePBX in your data centers or cloud accounts, with configuration matched to the approved scope.
- Dial plan, after-hours routing and paging integration built and tested against documented call flows agreed with clinical staff.
- Hardening of SIP access, encryption of signaling and media, and access controls for voicemail and call recording where PHI may appear.
How we hand over
- Test records for emergency dialing and location reporting, with each test case, result and retest documented for your compliance files.
- Runbooks for failover, backup restoration, voicemail access requests and change control, written for your operations staff.
- Evidence packages that support HIPAA Security Rule reviews, such as audit logging and access configuration, prepared for your auditors to assess.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing after the initial handover.
- Patch and version planning that tracks Asterisk and FreePBX releases, with test environments used before production changes.
- Periodic review of routing, location data and access controls as clinic sites, staff and integrations change over time.
