Another possibility for circumventing the need for a BAA, for bottom-up distribution of provider workflow tools: go on-prem, to start.
Create a desktop app, or Chrome plug-in, that stores state and processes data on users’ local machines. When PHI is disclosed in an existing web app at the customer (such as with certain EHRs), it could be extracted by crawling the web app DOMs from Chrome plug-ins. The same with RPA, for desktop apps (but the need here is declining, with each passing year).
You could then enable shared PHI state, between users within the same Covered Entity, on their local machines, using a decentralized ledger (I won’t say b***kc***n, given it’s 2023 😂). Non-PHI state, such as user authentication/authorization, could still be stored in the cloud.
Sounds like a developer platform someone should create!
stay tuned for part 2, where i touch on a variant of this! :)
the crypto approach is fascinating, certainly one i haven’t thought through in depth
there’s also the classic problem of ensuring similar quality of experience at scale, especially considering the long tail of providers might have outdated machines
Re: outdated machines, that's where Windows' backwards compatibility (https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42163) can come in handy. Even with outdated machines, this should be doable—but it would likely require a dedicated company to build this, as a developer platform.
Agreed. I was going to add a comment along these lines, since I have a friend who is doing this (bootstrapped) and seeing very nice grow. It took him an number of iterations to hit upon the use case (basically, better PCP notation, which sounds mundane and moat-less but you have to meet physicians where they are and not with innovative fandangles).
Yeah, all the technically innovative work is under the hood, to sidestep the regulatory challenges associated with low-friction adoption of new provider workflow tooling.
Given how much friction has traditionally existed in the adoption of new provider workflows, because of all these regulatory barriers, the actual workflow improvements are likely to be pretty mundane, at least to start.
Tnx. Very thorough! A couple of additional thoughts.
1. PLG, at least according to friends in DevOps, etc. seems to have hit a bit of a snag. Mostly due to belt tightening on the customer side that leaves less room for bottom up.
2. Re the consumer aspect, I wonder how much of it relates to not understanding the problem (e.g. some estimates claim that up to 80% of celiac sufferers are not diagnosed). So if you don’t think you have a problem it doesn’t exist. This is compounded by how much you value a solution (willingness to pay). If that is below the cost of delivering a solution you have a problem.
Another possibility for circumventing the need for a BAA, for bottom-up distribution of provider workflow tools: go on-prem, to start.
Create a desktop app, or Chrome plug-in, that stores state and processes data on users’ local machines. When PHI is disclosed in an existing web app at the customer (such as with certain EHRs), it could be extracted by crawling the web app DOMs from Chrome plug-ins. The same with RPA, for desktop apps (but the need here is declining, with each passing year).
You could then enable shared PHI state, between users within the same Covered Entity, on their local machines, using a decentralized ledger (I won’t say b***kc***n, given it’s 2023 😂). Non-PHI state, such as user authentication/authorization, could still be stored in the cloud.
Sounds like a developer platform someone should create!
stay tuned for part 2, where i touch on a variant of this! :)
the crypto approach is fascinating, certainly one i haven’t thought through in depth
there’s also the classic problem of ensuring similar quality of experience at scale, especially considering the long tail of providers might have outdated machines
Re: outdated machines, that's where Windows' backwards compatibility (https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42163) can come in handy. Even with outdated machines, this should be doable—but it would likely require a dedicated company to build this, as a developer platform.
Agreed. I was going to add a comment along these lines, since I have a friend who is doing this (bootstrapped) and seeing very nice grow. It took him an number of iterations to hit upon the use case (basically, better PCP notation, which sounds mundane and moat-less but you have to meet physicians where they are and not with innovative fandangles).
Yeah, all the technically innovative work is under the hood, to sidestep the regulatory challenges associated with low-friction adoption of new provider workflow tooling.
Given how much friction has traditionally existed in the adoption of new provider workflows, because of all these regulatory barriers, the actual workflow improvements are likely to be pretty mundane, at least to start.
Tnx. Very thorough! A couple of additional thoughts.
1. PLG, at least according to friends in DevOps, etc. seems to have hit a bit of a snag. Mostly due to belt tightening on the customer side that leaves less room for bottom up.
2. Re the consumer aspect, I wonder how much of it relates to not understanding the problem (e.g. some estimates claim that up to 80% of celiac sufferers are not diagnosed). So if you don’t think you have a problem it doesn’t exist. This is compounded by how much you value a solution (willingness to pay). If that is below the cost of delivering a solution you have a problem.