4 ms·

I've had this exact idea. I made it as a hackathon project but haven't worked on it ever since. One of the things I wanted to do was to use publicly-available t

I've had this exact idea. I made it as a hackathon project but haven't worked on it ever since. One of the things I wanted to do was to use publicly-available treatment cost data (I think states like California require reporting of this) and aggregate it by type of treatment to allow users to comparison-shop between medical providers in their area. The issue I was facing (and the reason I stopped working on this project) was the lack of standard, openly-available medical codes, since most hospitals mark treatments with CPT codes, which are proprietary and require a license to use in software. If anyone has any solutions to translate these codes to human-readable names without licensing the entire set of codes from the American Medical Association, I'd be open to hearing those ideas.

brundolf 6y ago
My (possibly naive) thinking was to have people just enter the human-friendly name for each item from their invoice as-is. A data-cleanup stage would then be necessary to reconcile these names across entries, but: - The same provider will presumably use the exact same name for the same item across invoices, reducing the subsets of values that will need to be matched up (similar to the way services like Mint make sense of transaction names) - Some automated "fuzzy matching" could be applied; keywords, off-by-one-letter checks, etc - Human curation, amplified by the above two factors, might be feasible - Maybe someone could even do something fancy with a neural-net, who knows ¯\_(ツ)_/¯ But yeah, data reconciliation is definitely one of the main challenges here. If you want to brainstorm/discuss more directly, you can email me at mail[at]brandonsmith[dot]ninja
- adventured 6y ago
  It's a good idea overall. My suggestion is to absolutely under no circumstances attempt to cover all (or a large number) possible medical codes in the first few years. Do not spend any mental energy on that, it will bury you, it will rob your motivation, it will waste your time and make you wish you never considered the service. Do the opposite, start very stupid simple, knock down one bowling pin. Pick a small selection of the most common medical codes or those most in need of this service (the treatments that can benefit most from this). Roll the complexity gradually from there. You will be aided by resources as you scale, in many ways, which you will lack in the beginning. Your expanding userbase can also assist you immensely as you go along (in the beginning they won't exist); but you first need to have a very useful service to get those users, and to do that you have to be good at something; narrow, narrow, narrow; you'll expand outward later. And frankly if you can't make it work for a small group of medical codes, you are not going to make it work for a much larger & complex context. Again, whatever you do, do not attempt to run before you crawl with this. You don't need to do that. Just offering this for small selection of medical codes could be hugely valuable, then slowly expand it. Make it work super well for that small group first. Make it clear what your service focuses on, and keep that list short. Reject any attempts by users to expand the system to cover all medical codes in the beginning. It's no different than going from Harvard.edu, to Stanford.edu as in the Facebook bowling pin strategy, and then building up some demand from users to see you add more medical codes (the userbase will help inform you which to do next). Do not try to go wide in the beginning, it's a guaranteed path to failure. Plus, if you start with a small selection of medical codes, you can better focus on your outreach / marketing to just those people and their circumstances. It will drastically simplify your attempts to find the first 100 / 1000 / 10000 users, and those early users will all be able to coordinate on the same narrow medical code/s, which will build the initial community foundation you require. If you try to go wide initially, covering a lot of medical codes, you'll get stray users that won't be able to coordinate with the other users who all have different medical codes (ie it's better to have 1,000 users with the same single medical code, than 1,000 medical codes each with one user).
  - brundolf 6y ago
    Thanks for the feedback. I think you're right; my thinking was to eagerly gather as much data as possible even if not all of it is useful immediately, but it's true that it might dilute the experience when the person entering the info doesn't yet benefit from most of what they've entered.
    - adventured 6y ago
      Absolutely. You risk an endless cycle of the ghost town effect in that scenario (people floating on an island by themselves, to zero benefit). I'd wager it's better to have only 100 users with one medical code, than 10,000 users all with different codes. Those 100 users ignite the function of the system, its desired feedback mechanism. I suspect there are some large, very common targets you can choose from to get started. Your challenge is probably deciding whether to target a more common medical code, or one with greater user intensity (people that are more frustrated; a higher intensity factor might be ideal for starting the system around; it's an interesting trade-off).

brundolf 6y ago

My (possibly naive) thinking was to have people just enter the human-friendly name for each item from their invoice as-is. A data-cleanup stage would then be necessary to reconcile these names across entries, but: - The same provider will presumably use the exact same name for the same item across invoices, reducing the subsets of values that will need to be matched up (similar to the way services like Mint make sense of transaction names) - Some automated "fuzzy matching" could be applied; keywords, off-by-one-letter checks, etc - Human curation, amplified by the above two factors, might be feasible - Maybe someone could even do something fancy with a neural-net, who knows ¯\_(ツ)_/¯ But yeah, data reconciliation is definitely one of the main challenges here. If you want to brainstorm/discuss more directly, you can email me at mail[at]brandonsmith[dot]ninja

adventured 6y ago
It's a good idea overall. My suggestion is to absolutely under no circumstances attempt to cover all (or a large number) possible medical codes in the first few years. Do not spend any mental energy on that, it will bury you, it will rob your motivation, it will waste your time and make you wish you never considered the service. Do the opposite, start very stupid simple, knock down one bowling pin. Pick a small selection of the most common medical codes or those most in need of this service (the treatments that can benefit most from this). Roll the complexity gradually from there. You will be aided by resources as you scale, in many ways, which you will lack in the beginning. Your expanding userbase can also assist you immensely as you go along (in the beginning they won't exist); but you first need to have a very useful service to get those users, and to do that you have to be good at something; narrow, narrow, narrow; you'll expand outward later. And frankly if you can't make it work for a small group of medical codes, you are not going to make it work for a much larger & complex context. Again, whatever you do, do not attempt to run before you crawl with this. You don't need to do that. Just offering this for small selection of medical codes could be hugely valuable, then slowly expand it. Make it work super well for that small group first. Make it clear what your service focuses on, and keep that list short. Reject any attempts by users to expand the system to cover all medical codes in the beginning. It's no different than going from Harvard.edu, to Stanford.edu as in the Facebook bowling pin strategy, and then building up some demand from users to see you add more medical codes (the userbase will help inform you which to do next). Do not try to go wide in the beginning, it's a guaranteed path to failure. Plus, if you start with a small selection of medical codes, you can better focus on your outreach / marketing to just those people and their circumstances. It will drastically simplify your attempts to find the first 100 / 1000 / 10000 users, and those early users will all be able to coordinate on the same narrow medical code/s, which will build the initial community foundation you require. If you try to go wide initially, covering a lot of medical codes, you'll get stray users that won't be able to coordinate with the other users who all have different medical codes (ie it's better to have 1,000 users with the same single medical code, than 1,000 medical codes each with one user).
- brundolf 6y ago
  Thanks for the feedback. I think you're right; my thinking was to eagerly gather as much data as possible even if not all of it is useful immediately, but it's true that it might dilute the experience when the person entering the info doesn't yet benefit from most of what they've entered.
  - adventured 6y ago
    Absolutely. You risk an endless cycle of the ghost town effect in that scenario (people floating on an island by themselves, to zero benefit). I'd wager it's better to have only 100 users with one medical code, than 10,000 users all with different codes. Those 100 users ignite the function of the system, its desired feedback mechanism. I suspect there are some large, very common targets you can choose from to get started. Your challenge is probably deciding whether to target a more common medical code, or one with greater user intensity (people that are more frustrated; a higher intensity factor might be ideal for starting the system around; it's an interesting trade-off).