Yes, we built a separate simple DB with the PHI and tokenized it. There was a lengthy review by the internal compliance department but as a lawyer it’s pretty easy to demonstrate it’s compliance.
Maybe educate yourself on what HIPPA requires before making such bold and rash statements.
It wouldn’t be a cash cow as it has limited applicability and there’s already a great plugin that assists with such compliance.
That’s why I’m making those statements…
I am a dev with a masters degree in behavior analysis. With 7 years in the field as a practicing behavioral psychologist I have learned more about hippa than I care to.
I also pay attention.
Good job, I suppose. More power to you. 
2 Likes
I can raise you on those supposed credentials but there wouldn’t be any point.
The bottom line is that even without a legal analysis, HIPPA is clearly only triggered upon storing PHI. The bubble app has absolutely ZERO PHI for its patients (as opposed to aides).
For future use, in the right set of circumstances (where there’s other app involved and bubble doesn’t need PHI), consider Strac
Even if tokenized it has to eventually be untokenized and if that happens on bubble at all you’re out of compliance. Even if your lucky enough to have that over looked bubble won’t sign a BAA agreement even on a dedicated plan which automatically puts you out of compliance for a second time. Anyone who MAY come in contact with any PHI must sign a BAA. That includes tokenized or encrypted data.
2 Likes
It never ever has to untokenized. Bubble CANT come into contact with any PHI → no BAA needed.
token != PHI
to clarify, I have no affiliation with strac and, in fact, didn’t use them for the app as there was no need to collect any PHI as patients were being directed from the company’s app which already had the patient’s info. However I spoke with Aatish and was impressed by strac and his expertise regarding HIPPA and tech.
I would love to see those HIPAA acceptance docs that had it pass through bubble bc we’ve got denied on a few clients even with fully encrypted and tokenized data simply bc bubble wouldn’t sign a BAA.
Only way around it is not having any PHI ever touch bubble to collect or display which makes the point of a hipaa argument pointless…
3 Likes
That is the only way with the notable exception of using strac or the like to collect PHI.
However, that doesn’t make the HIPPA argument pointless - only when PHI would be needed in Bubble which many times, especially in my use case, it isn’t needed. Literally the only usage I would have for PHI would be the user’s first name for welcome info and to display on their account but I just omitted it there.
dude, go back to watching Mr. Mahomes work his magic 
…
So if you needed no PHI in your app how do you even consider that a HIPAA accepted app in bubble 
because no PHI = no hipaa requirement…
Still would love to see those acceptance docs 
1 Like
First you list off the multiple times I am out of compliance.
Then you insist that I still need a BAA and that you would love to see it.
Then you say the whole argument is pointless if you can’t have any PHI touch bubble.
Then you ask how I consider it a HIPPA-accepted app if no PHI = no HIPPA - which was my whole point but still want to see docs.
What on earth are you talking about???
Did you bother reading what I said or is HIPPA just a trigger word for you?
As I said:
To repeat: I never said it was a HIPPA-accepted app or that any BAA exist. It’s not and there aren’t any.
It is however, HIPPA-compliant, as it doesn’t touch PHI. It is still not pointless, as there are many use cases of interacting with a patient without requiring PHI (likely for certain features within a application especially for spinning up a MVP of the feature.) and this instance was one of them.
You’ve said this in your first message:
Which makes me think you are interacting with PHI in Bubble and are trying to walk it back… what substantial work is required if you’re not interacting with any PHI…
Good to know my Hello World application in Python is HIPAA compliant though!
4 Likes
Anyway, back to the discussion at hand…
Some fair points. Do you have a client account which tells them how many more days worth of their $999 they have left to use if they continually pause it after their features are delivered?
Are there any opportunities of follow-up tweaks following feature implementation and are these delivered within the scope of the initial feature request? For example, if you implement a new page displaying some data from their database as part of a new feature, and they come back to you wanting it formatted or have it displayed another way, would that additional work further eat into their allocated purchased time? Using this as an example, the tweak might only take one or two hours (maybe even a lot less), but if it’s ‘delivered’ 24 hours later (although it was done much sooner) wouldn’t the client end up losing quite a lot of useable hours because the minimum time of delivery is 24 hours, even though you finished it at a fraction of the time?
I think if I was coming on as a client, the grey area for me (as an experienced Bubbler) is knowing how long it might take to implement a certain feature or a tweak to something you’ve already implemented or is already there. Knowing something might have taken one or two hours to implement, but a whole day was debited from my allowance of a months subscription means that after 4 or 5 small ‘24 hour’ tasks that might have collectively taken 6-8 hours to implement (let’s say a full working day), I’ve been debited for 5 days worth of time (or 4 days if you were to minus the actual complete day it’s taken to implement the changes).
I’d need a bit more clarification on time taken to deliver and how exactly will the client be ‘billed’ or time debited from their subscription based on the above. It seems like irrespective of how small the task might be, there is a very generous lead time buffer which can very quickly eat away at their allocated time they’ve purchased with small requests. I’m not saying a lead time is a bad idea (it’s important for expectations for the client), but I think there’s a difference between lead time and what is being debited from the client’s allowance. If they’re used interchangeably then that could create the above issue.
3 Likes
No (unless of course I didn’t fulfil the original request correctly). This is why it’s essential that clients write their requests in detail and that I understand their vision and goals correctly so I can make reasonable assumptions if necessary
A lot of it is within my control and will to be reasonable. If something takes two seconds, I do it. I’m not religiously enforcing time frames - 24 hours is the average. Often it’ll be done in 10 minutes. Me being ‘reasonable’ is something that some prospective clients struggle to grasp, but the clients I work with long term all know exactly how I operate and love it. The main thing is that if I’m not reasonable, clients choose to stop working with me. It’s mutually beneficial and in both myself and my clients’ interests to be reasonable and make sure they get value out of their subscription.
The main thing is that I deliver enough (and quickly enough) such that the client is satisfied. If the client is unsatisfied, they can just unsubscribe with no questions asked. It’s up to me to ensure that enough progress is made that they’re happy with their service. The clients I work with aren’t interested in micro-accounting. They want to pay a fixed amount a month and get a predictable level of service whenever they want it. If a client wants me to manually override three user’s subscriptions from the data tab, and then modify the homepage text, I’ll do it all in one day even if it’s two requests.
Running this model requires working with the good character of both the developer and the client, which is why it won’t work for every dev/client!
1 Like
The theory makes sense, but I feel the practicalities and logistics on how you keep track of time against someone’s monthly quota is where the proof will be on how well this works. Making a change that takes a few minutes and not starting their ‘subscription-clock’ is reasonable. But if they make a request that takes you a few hours to complete and you deliver it in exactly the number of hours it takes you to complete, and that’s what the client is debited for then that’s great for the client, but not you because the hourly rate on that approach to billing is peanuts.
I’m asking these questions as a prospective client because I want to take on someone long term that can implement changes, make improvements, add features, and generally be the technical point of contact in the start up I am working on - but I want it in a subscription model just like you describe as there will always be some development work going on. From my client lens then, it would be a good idea to have some examples of apps you’ve built that you can showcase on your site and maybe some examples of iterations you’ve done on this subscription model. I think that would help add some flesh to the bone and set the scene of what to expect and reinforce the subscription model works.
That’s the thing… there’s no tracking… you pay up front for a month of development time and we fit in as much as possible. If you’re not happy, you wouldn’t continue, but if you are (as the client testimonials will show) then it removes so much of the admin that I don’t care for because I’d rather be building apps.
I meet the obligations I commit to in the subscription and then offer more as I feel that my time allows to make sure that if a client has a shed load of tiny requests then they’re not losing out.
Haha - I exaggerate, but any developer worth their salt should be able to test their own work effectively. I agree that there’s the ‘second pair of eyes’ benefit as it’s sometimes easy to lose the forest for the trees, but particularly for small agencies, having one dedicated person for QA is an expense that shoots the price up too much. I’m almost done choosing the second team member for NQU and will sometimes ask them to look over stuff but really it’s something that a developer should be able to do. The worst case is that a small bug is delivered and then fixed quickly (i.e a couple of days) if it’s not identified before delivery.
George, this has been a really informative post for me to read through. Thanks for sharing!
@boston85719, your info was really insightful for me as well.
I would love to start offering a service to build MVPs for clients, and the info on what you offer, from upfront costs to ongoing subscriptions is really helpful for me in considering my own model.
This is what I love most about your model. This is a true win-win for everyone; you have more time to focus on the smaller number of clients, and they can appreciate that you’re not wasting time on other unreasonable/low-budget clients.
I have only been building with Bubble since February, but I’ve worked for 7 years doing tech support for an enterprise software company, and have dabbled in building iOS apps on my own here and there.
I’d say I have intermediate full-stack and database management knowledge, which has really helped me get up-to-speed quickly with building with Bubble.
I’m ready to start taking on clients, but I’m having trouble finding them.
Can you share how you landed your first few clients, or any tips on how you offer your services and get clients in your local region?
1 Like
Forum and referrals. I was pretty active in the ChatGPT posts and also posted free web browsing + long term memory resources. Referrals are king so do a great job for your clients and they’ll be your own marketing department.
I’m trying to collect testimonials from the early clients and permission to use their projects in my portfolio. Obviously the main problem new people have is the chicken egg problem of no clients if no social proof and no social proof if no clients. You overcome that by providing an unbeatable, low risk offer, even if it’s less than what you what you’d want to work for.
1 Like
It’s exactly what I said.
Since there’s a lot of misconception amongst Bubblers about what HIPAA compliance means, here’s a brief summary: (Disclaimer: Although I am a lawyer, this in no way constitutes legal advice or creates a lawyer-client relationship with anyone who interacts with it.)
Summary: When dealing with patient data, you can be HIPAA compliant by 1) properly securing the data and all transmissions of it across environments, OR 2) tokenizing the patient data and not interacting with the PHI (or unmasking the token).
Obviously, in Bubble, the only option in terms of HIPAA compliance is #2. I assumed that everyone understood that #1 wasn’t an option in Bubble , so I used HIPAA compliance to refer to #2 - tokenizing the patient data and not interacting with the PHI.
I now see that using the term HIPAA compliant in a general sense was confusing and vauge, but it wasn’t incorrect, as #2 is a viable approach to make an app HIPAA compliant and in fact, the only route to do so in Bubble…
“what substantial work is required”
To be HIPAA compliant the app has to use a token and not unmask it. If it’s not obvious, there’s a lot of work necessary to not need the app to interact with PHI , including:
- a separate HIPAA acceptable app that has the PHI and handles SSO,
- generalizing the patient’s address so it no longer qualifies as PHI, and
- pinging the other app to send out texts and emails to the patient.
All of this, of course, while using Bubble for storing the aide’s data and communicating with the aides directly.
Hope this clarifies HIPAA compliance and the broader point of the amount of development needed to make a true MVP in this scenario.
Yep of course, testing is one part of QA but developers in small agencies must be able to do both (as for small agencies there just is no alternative) 
That’s at least something that’s not constrained particularly to this development model and still applies for more traditional agencies/freelancers.