Hipaa compliance

I’m not aware of any. We have not gone through any process to check our HIPPA compliance.

To make your Jitsy app HIPAA compliant you need to secure the telecommunications.

  • You need to implement multi-factor authentication and encryption
  • Secure Bluetooth devices if involved
  • Create VLANs
  • Monitor data / voice traffic in real time

Here are the government’s guidelines written friendly https://petronellatech.com/the-governments-hipaa-guidelines-decoded/

1 Like

Any changes on HIPAA Compliance since 2018?

Nothing has changed.

We haven’t gone throgh formal audit, but to the best of our non-legally
competent opinion we believe meet.jit.si should be.

thanks!
It will be a great asset to have HIPAA Compliance label - so what would require form your side to get an formal audit?

1 Like

Sorry for the long post, but HIPAA frequently gets misunderstood. I am not a lawyer, but I’ve read the CMS/HHS/OCR site obsessively.

Short answer-If I understand Jitsi correctly, it has true E2E encryption and does not hold sessions anywhere. Thus it falls under the “conduit exception” rule, does not require a BAA, and doctors (Covered Entities-CEs) using it would be able to include Jitsi in the security assessment HITECH requires and would be compliant with HIPAA by doing so.

To record sessions, you would have to use a server you physically control, or where you had a BAA with the CSP.
Whew!


Long answer:
The only software that can be “HIPAA Compliant” (CEHRT) is EMRs. Doctors and hospitals have to comply w HIPAA, but it’s a PROCESS, NOT a certification.

"HHS and OCR do not endorse any private consultants’ or education providers’ seminars, materials or systems, and do not certify any persons or products as “HIPAA compliant.” "
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/be-aware-misleading-marketing-claims/index.html

Since Jitsi only stores encrypted transmissions temporarily for buffering, it falls under the “conduit exception” rule which treats JITSI like the post office or an ISP.
https://www.hhs.gov/hipaa/for-professionals/faq/245/are-entities-business-associates/index.html

" As explained in previous guidance, the conduit exception is limited to transmission-only services for PHI (whether in electronic or paper form), including any temporary storage of PHI incident to such transmission. Any access to PHI by a conduit is only transient in nature. In contrast, a CSP that maintains ePHI for the purpose of storing it will qualify as a business associate, and not a conduit, even if the CSP does not actually view the information, because the entity has more persistent access to the ePHI."
https://www.hhs.gov/hipaa/for-professionals/faq/2077/can-a-csp-be-considered-to-be-a-conduit-like-the-postal-service-and-therefore-not-a-business%20associate-that-must-comply-with-the-hipaa-rules/index.html

This got muddied with the latest announcements from HHS when they were trying to reassure people while demonstrating the director had no clue.



https://www.hhs.gov/hipaa/for-professionals/faq/3024/what-is-a-non-public-facing-remote-communication-product/index.html

If JITSI stored encrypted video for longer than buffering, other than ensuring the quality of the service, then it falls into a different category, (cloud storage) and JITSI/8x8 would have to post a Business Associate Agreement (BAA) which basically would say, “We can’t access any of your protected health information (PHI), so we can’t disclose it to you or anyone else. We keep your transmissions secure.”
Names, phone numbers, emails, etc., are not PHI without a diagnosis or other PHI.
If a doc sets up Jibri on their own server in their own facility it would fall under the general HIPAA regs like record storage. (If you stored chats off site, you’d need a BAA with the CSP, including YouTube.)
The COVID/emergency announcement muddied this because they referred to conduit-type video chat apps which HAD (unnecessary) BAAs as “HIPAA Compliant,” showing the OCR director doesn’t understand HIPAA in at least two ways:

1.OCR and HHS do not certify any persons or products as "HIPAA compliant."
2 an encrypted video chat which does not store sessions on outside servers falls under the “conduit exception rule”

The comment above about requiring 2FA, VLANs, etc, is incorrect. When a CE or BAA does a (required) security assessment, they should consider whether encryption or other measures are needed to secure PHI.

https://www.hhs.gov/hipaa/for-professionals/faq/2001/is-the-use-of-encryption-mandatory-in-the-security-rule/index.html "No. The final Security Rule made the use of encryption an addressable implementation specification."
So, when you do your security assessment, you can “address” 2FA, VPNs, one time keys, armed guards, bank vaults, or storage on an asteroid and decide whether you need them or not. It’s a PROCESS.
https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html

1 Like

I don’t think this is correct unless one gives to E2E the Zoom sense :slight_smile:
For me, E2E is done on Jitsi if and only if:

  1. it’s a one-on-one communication
  2. the server has not disabled p2p.

If the server has disabled p2p (a very easy thing to do), the video data is UNcrypted on the server. No indication of this fact is displayed on the screens of the 2 persons holding a confidential meeting, everything will proceed exactly the same as if it was E2E. This video information is not stored by default, but if the server admin add the recording facility, no indication of this recording of UNencrypted data will appear on the screens of the 2 persons holding the confidential meeting.

1 Like

Thanks for the correction.
If the server is outside the covered entity, then it would fail most HITECH risk analyses. (Although last I looked HHS still had a FAQ saying CEs could use UNencrypted email if it was in their privacy policies.)
Is there some sort of central Jitsi server?
I was thinking of 2 person ‘conferences’, but the lack of easy setup for in-house recording meant I’m looking at other tools. Too bad. OS is cool.

meet.jit.si is a public server managed by the jitsi project - in practice I’d say that the money is provided by the business using the project for its own needs - but for people self hosting with the standard software provided by jitsi project video is not going through other servers (there is a feature that could enable this, turn server, but I don’t know enough to say it’s encrypted or not and if you control the server fully it’s not mandatory anyway)

yes in the open source world I’m sure there are solutions for that but I never looked for them. Jitsi meet is aimed at, well, meetings. For 2 persons with confidential video exchange to do, I’d say that software you actually install on your computer is best

Although there’s no guarantee that just because software is “installed on your computer”, the signalling and/or media are not going through a third party service. In that sense, having a thick client might be helpful for some things, but functionally it’s no different to using a browser-based client.

If you are looking for an end-to-end encrypted which does not make use of a centralised server, I suspect you’re going to struggle.

(FWIW, Apple states that FaceTime uses end-to-end encryption, but traffic still goes through Apple servers. But it’s only available for macOS/iOS clients. Signal also offers e2ee, but I find voice/video performance flaky. I like matrix/riot, but that still uses a homeserver (which you can run yourself (and integrate with jitsi for multi-party video conferencing), and the user experience is not brilliant for non-technical users.)

Well, a browser based client is not a browser, it’s a bunch of javascript that is ‘installed’ on the computer without any control from the user. So there is absolutely no warranty that it’s the same software from a day to the next one. The shining green icon you get in the URL is absolutely no warranty that the code you get is legit. When you install a thick client you can (at least theoretically) take some steps to insure that it’s actually coming from who you want - code signature. Even if the provider of the software is hacked after you download the software, you are not impacted until you choose to update it. If you are really security conscious you can even use a dedicated computer running only this software - something that is absolutely impractical with a browser based solution so you are open to all browsers vulnerabilities.
Yes I am fully ready to concede that such security level is light years beyond what the average professional is willing to do in my country :slight_smile:

If you’re running your own jitsi instance, serving the web client from your own web server, you’d have a pretty high degree of confidence that this was unmodified.

And even if the thick client software is unmodified, unless you’ve vetted the source, you don’t know what it is doing, or what the server is doing with the data it receives. So I wouldn’t see that as a panacea!

I don’t. The word panacea in security matters should be absolutely verboten IMO. It s often used to keep deeply insecure systems until a ‘panacea’ is available. A hosted Jitsi can be a good enough solution but it needs to be secured and it’s not a so common skill.
Installing a downloaded thick client needs much less technical ability for a professional not versed in computer stuff. As of vetting the source, an obviously totally unrealistic goal for professionals, I’d say that a thick client is at least an order of magnitude simpler that Jitsi or any similar meeting server software.

Nothing, with a true peer to peer client there is no server. It’s basically a phone with encryption capability and a big screen. Yes you need to find the partner and get it’s IP address and it’s no panacea. There is no panacea or graal in security.

Which brings it own fun of ensuring that you’ve got the right IP address, and not some man-in-the-middle’s IP address. It’s like PKI all over again :slight_smile:

But anyway — I don’t want to drag this off-topic. Everyone needs to make their own decision as to whether the security afforded by jitsi (and their configuration of jitsi) is suitable for their own needs, or whether other tools are more appropriate.

our positions are totally incompatible so it’s better to agree to disagree.

I just want to correct partially something I said; I was believing that there was no visual difference between E2E mode and standard mode; looking more in depth, the problem was that I was believing to be in E2E mode but because of some obscure problem Jitsi was setting the standard mode even for 2 persons while p2p mode was enabled.

So while there is supposedly an E2E indicator and in E2E mode the thumbnails are hidden, having never seen it I was unaware that it was failing in my case :slight_smile:.

So my bad, but it does not change my mind that the best idea is to use a tool that is actually locked in E2E mode and even better that don’t know how to initiate an exchange that is not E2E.

Have you tried matrix/riot? That’s my preference at the moment for e2ee video/voice/text. It’s not p2p in its current implementation, but everyone can run their own homeserver if they want, and the next iteration of the platform is p2p focussed.

e2ee on it is not currently the default, but that is in the works for - I believe - the next couple of weeks.

It uses (or, rather, can use) jitsi for multi-way conferencing, but works very well on its one for one-on-one voice/video.

I would do thorough due diligence before calling a platform as E2E encrypted; especially in light of FBI and other forensic investigators taking interest in conferencing platform.

I design and build low-end HIPPA-compliant software. A current project involves collecting data for a medical study. The study will be approved by an IRB.
The software uses twilio, which is not HIPPA compliant. As long as we don’t send PII over the channel and restrict the questions to not ask and answers to not expect medically sensitive information, we are ok.
Incorporating jitsi is quite interesting. It will be the next step for this product (assuming it gets uptake from the medical community). To incorporate correctly, you will need (as mentioned below) 2FA and such to start. It gets interesting from there. I haven’t seen the latest guidance, but it’s probably only helpful for existing software product lines. I wouldn’t start a HIPPA-compliant communication tool under the relaxed guidelines.
I’m going to install the jitsi server on osx & debian and give it a shot. Incorporating jitsi in a HIPPA-compliant open-source clinical database is an interesting idea.

2 Likes

Please keep us updated on this , thanks in advance

Good Faith Telehealth Remote Communications During the COVID-19 Nationwide Public Health Emergency

The first Notice of Enforcement Discretion in relation to COVID-19 was announced by OCR on March 17, 2020 and concerns the good faith provision of telehealth services. OCR is waiving potential penalties for HIPAA violations by healthcare providers that provide virtual care to patients through everyday communications technologies during the COVID-19 nationwide public health emergency.

This means healthcare providers are permitted to use everyday communications tools to provide telehealth services to patients, even if those tools would not normally be considered fully HIPAA compliant.

Platforms such as FaceTime, Skype, Zoom, and Google Hangouts video can be used in the good faith provision of telehealth services to patients without penalty for the duration of the public health emergency. However, public-facing platforms such as TikTok and Facebook Live must not be used.

1 Like