Hi,
I’m building an app that may contain some sensitive information about people and I’m trying to use the Data Privacy rules but I can’t figure it out how to make it work for what I need.
I just want to say upfront that the data displayed in the user interface is already showing correctly only to people who should see it. I got all UI and workflows working. This is just to prevent hackers or unauthorized users from snooping in, as privacy is of great importance for this app. (So I’m trying to use the Data Privacy rules).
I’ll try to simplify what I’m trying to do to illustrate it.
In my app, I have a few Types and example fields:
User (the usual user fields - can be doctors, patients or admin staff in a medical practice)
Patient (User, Name, BloodType, DOB, Allergies… - with patient-specific info. Some patients can be users but most are not as they are just created by the practice for internal use)
Doctor (User, Credential, Speciality… - with doctor-specific info)
PatientDoctor (Patient, Doctor - this creates a many-to-many relationship as one doctor treats many patients and one patient can be treated by many doctors)
ExamResults (Patient, Type, Score, Comments… - exam results related to a single patient. One patient can have many ExamResults records)
What I am trying to do is to create a rule in the ExamResults type that will allow only users who are either the Patients themselves or Doctors who are linked to the Patient to see the data in the ExamResults table.
When I go create a rule, I can easily create one for the User who is a patient, as the relationship is directly linked by one to one relationships. However, I can’t create a rule for doctors, as I would need to do a search in PatientDoctor for doctors who can see the Patient related to the data in this table. I can’t use search in Privacy Rules and I can reference PatientDoctors from there.
I will also need a similar rule for Doctors seeing info in the Patients table related to their patients only.
Any ideas on how to make that info private only to the people I want?
Is it too late to make data structure changes, eliminating the PatientDoctor thing, and having a many-to-many relationship on the Patient and Doctor things themselves?
The check for is not empty, is just in case you end up with a User with an empty patient record, that would then match to any ExamResults that also do not have a patient attached.
Now unfortunately, for the doctors permission, you can’t use the searches (as noted in the screenshot,) but it still might work for you. For example, if a doctor user searched for a patient, then all the patient’s ExamResult’s would be still visible to the doctor.
Thanks, @mebeingken,
That does give me some insights.
I’ll try it out.
Thanks for the note @mishav.
The results will basically be the results of a mental health self-reporting questionnaire.
I don’t know if that will classify as health records but I’ll keep that in mind.
If any of you want to check the app, version 1 is ready and launched.
Check it here:
The app, in the current version, is designed for 2 publics in mind:
For people who want to check their level of stress, anxiety and depression and, if high, to urge them to seek medical help.
For doctors and mental health professionals to use the tool to automatically calculate the results and keep historical patient data for future reference.
Check it out and let me know what you think.
I have been looking at a lot of these same challenges. If you are storing patient info on behalf of doctors, HIPPA would apply in the US and you would need a HIPPA-compliant system, which Bubble specifically states it is not. Might be worth looking into before you launch.
@mebeingken - Ken, thanks for the explanation. Could you explain how you use the “list of doctors” data type on the patient type? I watched the Bubble tutorial on using lists, but when I tried to use it, I got an error that a “doctor” (name) couldn’t be entered in the input text field because type was “list” not “text.”
Assuming you have set up your patient as you described above, how to do you populate that patient’s “list of doctors”?
Thanks!
Can a USA company, that is storing patient info on behalf of non USA clinics and non USA doctors not in the USA, Canada, or Europe (e.g. Mexico, Thailand, Bali, Africa, etc), still use Bubble.is? What if a USA patient uses a clinic in Mexico?
I wouldn’t keep anything worth suing me over on Bubble.
@2morses is right about HIPPA.
There are compliant off-site solutions you could integrate with an API. That way you would only keep the off-site IDs on Bubble.
As for the original question, it’s less stress on resources to put a “doctor list” field on the patient (user) table.
@carlos1 - From what I understand, HIPPA applies to patients receiving care in US only as it is part of US law (telemedicine makes this a bit fuzzy). As far as a USA company storing info on behalf of non-USA doctors located in clinics outside the US, I don’t think HIPPA compliance could be required as it is beyond the jurisdiction, but you should probably confirm this with an expert.
The bigger question is what your clients expect: anyone can choose to be HIPPA compliant, even if they aren’t required to. A clinic in Mexico that caters to a lot of “medical tourists” and expects to have a lot of USA patients, may want to be able to advertise they are HIPPA-compliant as a business decision rather than a regulatory one. So, you may want to check with your potential customers on their needs.
I feel like this thread pointed out a major gap in bubble that still doesn’t seem to be filled to this day. Privacy for many-to-many relationships SHOULD be supported as part of privacy rules. While @mebeinken 's solution works, it quickly becomes an issue at larger scales. Imagine designing a social media site, for instance, where a person’s privacy is controlled by followers. If a person has 100,000 followers, not only would that cause major performance issues, but I don’t even think it would be supported at bubble’s current list length maximums.
@josh is there any way we could get more advanced privacy rules for these kinds of situations?
I’d like to see this too. I’ve had corporate clients refuse to consider Bubble because the Privacy Rules are not robust enough for their overarching security policies - even if the purpose of the proposed app doesn’t require many-to-many rules right away.
As of my last touchpoint, they were considering MS Power Apps (not functional enough yet) and Outsystems, both of which cater more to enterprise clients. Outsystems is a great tool but it is a heavyweight and was overkill for this particular case aside from the security benefits. I really wish they had gone with Bubble! The project would have been done by now instead of watching the client continue to spin their wheels.
Interesting. When corporate IT rejects a platform for security reasons, I often wonder if that’s truly the issue, or if their view is colored by a bias to build in-house or use a tool from one of their existing enterprise vendors like Microsoft. And how much of it is a cultural thing of corporate teams reacting better to platforms that sell exclusively to enterprises, vs. tools like Bubble that work for entrepreneurs.
Bumping this again over a year later because, unfortunately, I’ve run into the issue yet again.
Many-to-many relationship data items (like PatientDoctor here) are a very common database design choice which bubble effectively prevents you from using because you can’t effectively make privacy rules to support them without using lists, which defeats the purpose of them to begin with.
I mentioned a social media example earlier, but here’s another huge one: enterprise software access control roles. For example, a company has many employees, each with different permissions. You create a Role data type to match each pairing of User, Company, and permissions. However, you can’t effectively create privacy rules to restrict access to the company data and data of your coworkers based on these roles, you have to user lists.
@josh@tj-bubble would really appreciate a way to do this, it seems like a major limitation in using bubble at scale.
Thank you so much for flagging this! I understand that you are aware of the workarounds (readjusting the database structure, using lists, etc.), and I see why they are not ideal given particular use cases. The ability to have many-to-many relationship data items would certainly be a useful capability and I’m sure our users would appreciate it as well. For this reason, I’ve gone ahead and submitted your suggestion as a feature request to our Product team. We are constantly making changes to the Bubble platform based on our users’ feedback, so I really appreciate you bringing this to our attention.
I sincerely apologize for the limited action I am able to take at this time, but I hope this helps. Please don’t hesitate to reach out to our team at support@bubble.io if you have any other questions/concerns and our team would be more than happy to assist!
I am a new Bubble enthusiast trying to build a Micro SaaS solution and ran into the same limitation of requiring Many-to-Many relationship data relationships for Privacy Rules.
@bhavika.kaneria requesting you to kindly post if there is any update on the roadmap.
