However when said paramedic fills out the incident report in an app with an Injury category with a value of "Fracture" and a Location category with a value of "Left Arm", that information goes into a database and becomes ePHI. As a straightforward example - if a paramedic writes free-form notes at the scene of a car accident saying I have a broken arm, that isn't considered to be ePHI. However it's quite clear about what constitutes ePHI, and even the most liberal definition fails to apply to a VOIP conversation. The former has the semi-draconian encryption requirements and applies to electronic Protected Health Information, both for data at motion and data at rest. With HIPAA / HITECH, it's important to remember that there are two rules: the security rule and the privacy rule. I am not some one with any experience in compliance, or law so do not assume my recommendations will keep you hippa compliant. Not to mention the current SDES-SRTP that 99.99% of phones implement is incredibly weak and is being surpassed by better peer based key exchange mechanisms like DTLS-SRTP I would say that if you wanted to do TLS/SRTP you might make people feel warm and fuzzy about your security, but it isn't going to make you more or less hippa compliant to have it.
If you are doing things like "robo calling" with pre-recorded messages, or recording calls, or otherwise making records of the call, or media - those would all be required to meet hippa regulations. The actual phone call it self does not seem to fall under the regulations set forth by hippa.
There are further considerations on the provider side to make sure things like call detail records are secure, so that people can't go and find out what patients you have been calling without being authorized to do so. This was mentioned in an article referenced by the blog you posted. That said I belive hippa is more related to medical records, or digital copies of information. So having encrypted media and signaling to your SIP provider is not going to give you much security as they will be decrypting it to hand off to the pstn. The users are generated dynamic by LUA, although this shouldn't matter as this same box worked with our last testing done with it.Information is not encrypted on the PSTN. This is running against a build of SIP.js that was done a couple of hours ago. What appears to be happening is that SIP.js is not responding to anything being sent to it through WSS, unless it started it, when i switch back to WS, i see that FreeSWITCH sends an Options packet trying to probe for information, where as WSS i do not see this behavior. If i revert back to WS (Normal WebSockets) Inbound/Outbound calls work as expected.
Outgoing calls work flawlessly, Incoming are problematic ONLY when using WSS (Secure WebSockets).
#ONSIP VFAX CODE#
In the mean time, i will start investigating the code to see if i can generate any sort of output.Ĭommit 571cf932dcaa9db96125f2f5a7dcba83d0825bbaĪuthor: Jeff Lenk Sat Aug 16 18:22:41 2014 -0500Ĭurrently updating FreeSWITCH to see if there's any impact/change of behavior. Outbound calling works flawlessly on both WS and WSS. Unfortunately using WS is not really an option because you cannot connect to WS from HTTPS due to security restrictions. What testing has been done against WSS, am i missing something that could potentially be killing me?
#ONSIP VFAX HOW TO#
I would attach JS SIP Traces and wiresharks, but JS SIP traces never show a call attempt, and because its HTTPS/WSS wire shark is pretty much useless (unless someone knows how to decrypt the streams). This is also affecting presence subscriptions (no messages are seen).Ĭhanging over to WS, calls and presence both start working. I can call a regular sip client just fine, and even using SipML5 (which we had been previously using) works without issues.
0 kommentar(er)
