Looking for turn-up assistance for FreePBX

Jobs
1

Hi All,

I’m sure most of you have seen my posts from time to time and might have even wanted to toss me out the nearest window every once in a while, but this is a completely serious request for proposal, no fun and games.

CODA Inc. is an addiction recovery non-profit located in Portland, OR (Pacific Time Zone) with 14 remote sites and approximately 300 Cisco 8845/7821 desk telephones on a Cisco UCM running version 10.5 UCM code. It’s fed from a PRI with 23 trunks on it. There ARE some SIP trunks coming into the network via a Cisco CUBE/ISR4321 that handle 911 for ONE site for unnecessarily complicated and ridiculous historical reasons I won’t waste time explaining here.

The WAN is a layer 2 metroE network that has a layer 3 routed network basically superimposed on it - the benefit of this being we have complete control over QoS packet prioritization for VoIP traffic.

The Cisco UCM is at max licensing and because it is out of support from Cisco we can no longer buy licenses for it. We do have a Cisco servicing company we have been working with for the last couple years that handles support for that system, but they are not interested in supporting any other telephone system than the Cisco UCM or Cisco Cloud Calling. (which we are not interested in due to the cost, plus we have existing PRI/SIP trunk contracts)

We are opening a new site in the fall at another location that will need around 80 extensions, almost all of them single extension number/line appearance. This is a controlled medical facility with residential treatment, no public access. It’s kind of like a jail but not a jail.

Cisco’s “by the book” solution is to migrate customers like us into their Cloud Calling. That’s a non-starter for us for a variety of technical plus some legal reasons (look up 42 CFR part 2 if you are curious)

I want to bring up the new site on it’s own FreePBX PBX, tie it into the existing UCM for inbound and outbound calls, then in a few years take a very serious look at moving the entire Enterprise over to FreePBX.

I’m going to need someone or a company who can consult on the back end stuff - the inter-PBX trunking, dialplan, trunk, and so on, and work with our existing Cisco phone vendor running the UCM, my tech, and Sangoma on any issues that might arise during the time the new site is being brought up. We are building a prototype of all of this right now in our test lab, and intend to get it all working months before GoLive date for the new site - it’s halfway done now actually - but I know from experience that if something is going to go sideways it will do it right in the middle of GoLive and I won’t have time to manage it.

I’m expecting that after a few months the excitement and changes to the PBX and the new site will die down and it will just settle down to Move/Add/Change work that we can do.

Anyone who is interested in helping us, please contact me at the following:

Ted Mittelstaedt
IT Director
1027 E. Burnside St.
Portland, OR 97214
Direct: 971-202-7783
Main: 503-239-8400
Cell: 503-867-6993
E-mail: [email protected]
www.codainc.org

2

Cisco and Webex is more 45 CFR part 2/HIPAA compliant than FreePBX will ever be. Unfortunately, moving to FreePBX in this use case will remove compliances. So if moving to WebEx is a non-starter for legal reasons, FreePBX leaves you in a worse spot.

3

Ah, no.

42 CFR Part 2 requires, among other things, that the organization providing the service sign a document with the government that permits the government to come in and audit them. No cloud calling provider out there will do this.

There is NO commercial cloud calling product including Webex, Microsoft’s product, Ring Central’s product and all it’s OEM customers who are reselling it, and any other one you can name, that is compliant. Plenty of them are HIPAA compliant - but HIPAA isn’t enough. 42 CFR Part 2 is sort of a super-HIPAA requirement because to put it flatly HIPAA is routinely ignored and reinterpreted by regular medical providers like hospitals and their regulatory bodies.

For example take the issue of medical faxes. Go to the doctor and they write out a prescription then send it to your pharmacy. 99 times out of 100 this is done via a fax, and faxes are not encrypted, and HIPAA actually spells out that patient data must be encrypted when transmitted from one medical provider to another. But when the auditors come - they turn a blind eye to faxes. They turn a blind eye to a LOT of legal law requirements that the law spells out must happen but because hospitals and doctors have “always done it that way and there hasn’t been a problem” they pretend that things like a regular phone call or a fax is compliant when it’s not.

Medical providers have always had on-premise phone systems in the past. The reason the auditors give those systems a pass and not the cloud systems is because if a doctor makes a phone call to a nurse and discusses patient data, that call stays within the building if the PBX is on-prem. That is, it stays under the control of the network admin, the unencrypted packets are on a network that is physically secure. (HIPAA actually has a carveout for this) If that call is relayed from the building to the cloud then back again, then it’s not secure (unless the phone is encrypting RTP which practically none do) and can be tapped at the cloud provider. In fact the government has another regulation that REQUIRES the cloud calling provider to run what’s called “intercept code” that has an API in it specifically for tapping calls.

If a medical provider initiates a call to a patient through the PSTN and asks about a medical condition, that’s a HIPAA violation because such calls are not encrypted. But, if that happens in reverse, the patient calls in, then starts talking about their aches and pains, then the regulators and the medical establishment have this unwritten understanding that the patent is giving implied permission for their medical condition to be public, because they are choosing an insecure communication channel. Despite the fact that virtually 100% of the general public all thinks a “phone call” is “secure” When in reality, it’s not.

Think about that the next time you call your doctor, LOL.

So far the industry has never seemed to face an actual serious test case that has run all these de-facto understandings through the court system. I suspect it’s because anyone smart enough to file a lawsuit claiming the hospital let their personal medical data be leaked via an insecure HIPAA violating unencrypted phone call has been quickly paid off to STFU because nobody in the business wants to tear into all of this. And like I said 99% of the general public doesn’t understand any of this stuff and wouldn’t BE smart enough to file such a lawsuit. Not to mention nobody really gives a damn about anyone else’s medical conditions so proving you got damaged by such a leak would be a really high bar in the first place.

So in summary, moving to an on-prem system, whether it’s FreePBX, or Cisco UCM, or someone else’s system - is ALWAYS the safer and better option for any medical provider of any kind. Even though, to the general public, it SEEMS like the opposite is true.

4

I think you missed the overall point, FreePBX (or even Sangoma I believe) is not HIPAA compliant. While you could make FreePBX HIPAA compliant it would require a lot of work to do so. To make it 42 CFR Part 2 compliant is going to require even more overhauling of the system. That is going to require time, expertise and money.

Despite being a zealot, I can say that FreePBX might not be the best choice for this unless you going to roll over your sleeves and put the work in.

5

And I think you missed the point that NO system INCLUDING Webex cloud calling is 42 CFR Part 2 compliant. Not at the current time, at least. Therefore, the regulation that requires us to be 42 CFR Part 2 compliant is impossible to meet based on the fact that no product producers that sell products that are needed will guarantee such compliance. And because it’s impossible to meet - the regulators don’t require us to meet it.

As for HIPAA compliance, since no on-premise phone systems offer HIPAA compliancy, once more we aren’t required to meet that for an on-premise phone system, for the same reasons. (one isn’t available)

You are conflating the idea of making a telephone call with a PBX. There is no regulation requiring us to move to a HIPAA compliant cloud phone system from our on-premise non-HIPAA compliant Cisco UCM system because the regulations apply to systems, not the actions of those systems. HIPAA applies to phone systems not phone calls.

The government does not force you for example to stop using FAXes and start using encrypted PDFs that are HIPAA compliant just because no FAX machines have HIPAA compliance and encrypted PDFs do have HIPAA compliance.

I realize this probably looks like a loophole, and possibly it is. But the people who created HIPAA discussed this. They crafted these regulations NOT to force hospitals to give up insecure faxes, give up insecure phone calls over the PSTN and so on, they crafted them so that when providers moved from older insecure systems to newer systems, that they would not choose newer systems that were as equally insecure as the older systems.

Consider for example that even if a provider uses a HIPAA-compliant cloud phone system (like webex/secure calling) that if the telephone number that is called is on Grandma’s Land Line that she’s had for 50 years and she answers on a Princess Phone from Western Electric, then the portion of the call that traverses the copper lines from the CO to her phone - is unencrypted - thus is in HIPAA violation.

So the reality is - that even for cloud phone systems that claim HIPAA compliance - they AREN’T actually, compliant. At least, not the portion of the call that exists from the POTS gateway in Cisco’s server farm through the PSTN. If one portion of the system is not compliant then the entire system is compromised and the entire system isn’t compliant - so Cisco is, in effect lying. Only a webex-to-webex phone call would truly be HIPAA compliant.

6

HIPAA doesn’t require encryption over a POTS/PRI/T1 that is on a circuit-switched network (ala TDM). They are considered private lines, POTS even more so since it’s analog. So yes, the portion of that call going over the analog POTS line from a circuit-switch network is allowed by HIPAA.

Let me add a clarification, if the PRI/T1 is using data (IP) to send the call…the call is not circuit-switch or private and falls under VoIP which is another ball of wax.

7

That would be an interesting argument in a court test. I don’t think it would hold up however since when the subscriber orders their analog line from the phone company, they don’t sign a contract with the phone company guaranteeing the line is HIPAA compliant. And such agreements have become standard now when customers buy HIPAA-compliant services.

You’re making an interesting argument because you are claiming the line is a private line, you’re expanding the definition of a private telephone subscriber line to include HIPAA compliance. I think if you tried that in a court the phone companies would come out of the woodwork to assure the court that no, they DO NOT imply HIPAA compliance for private lines.

8

Hi Ted,

I’d like to chat about your needs. I will give you a call today if you are free.