Great idea, but I presume there was a reason why Google Health was shut down and abandoned this space in 2013. How will PicnicHealth avoid this?
“When you’re dealing with potentially the hardest moments of your life, you don’t have to worry about these other logistical tasks and the feeling of confusion on what’s exactly going on,” Leviner said.
True, but I sat down and uploaded most of my data to Google Health when I wasn't sick, and I've been wishing for a simple replacement ever since it shut down. This is a nice-looking project but it appears to leave users with little to no input of their own into their clinical record-keeping. I also wonder (based on previous experience with obtaining my own medical records) how they intend to deal with the fees imposed by medical service providers for the collation and administrative release of the data. I paid about $100 a few years ago for the records of a brief hospital stay, which ran into hundreds of pages (much of it duplicative, and with much of the salient information being in handwritten form).
In another case, my doctor worked for a multi-doctor practice that went out of business, and it was claimed all records were lost due to "computer problems". Nothing really valuable there, but with so much chaos in the US medical systems, where I have and see lots of doctors giving up independent practice and going to work for "the man" ... well, at the very least PicnicHealth should allow a client to send them paper copies or scans of records.
Hi, one of the PicnicHealth founders here. It's great that you were motivated enough to upload your data to Google Health! Unfortunately for Google Health, most people weren't as motivated as you. We believe that Personal Health Records haven't yet been successful because they require users to manually upload their data, and most people just aren't willing to do this. That's one of the reasons why we take care of collecting and organizing records for our users.
About fees, you're right: one of our users would have had to pay over $700 in fees if he had tried to get the records from just one of his hospitalizations on his own! We have relationships set up so that we avoid fees almost 100% of the time, and when we can't avoid a fee we cover that ourselves. Our job is also to sort through the mess and pull out the salient information so that you don't have to.
Very true, people generally take their health for granted until they experience an adverse event. Expecting people to take it upon themselves to handle their own medical records is wishful.
Large doctor practices sometimes have 2 or even 3 people just dedicated to fulfilling medical record requests. That's a huge expense. I help run a home health company that is constantly requesting medical records. We still receive most records by fax! Our receptionist spends a good bit of her day handling this process. It's a huge waste on both ends. If you could make that process easier I think a lot of providers would be willing to pay... Regardless, best of luck! So much opportunity in this space, keep pushing.
Would love to talk offline and hear more about how you're handling this. I'm only just learning about home healthcare deals with this stuff. I'm noga at picnichealth if you have a minute to chat at some point.
Is PicnicHealth a non-profit (although it doesn't appear to be)? If not how is the market willing and able to pay for such a service? (considering that users, not institutions are charged)
> We personally make sure your doctor has updates before you get to the office.
This is huge. With all the different record systems, many of which still use physical paper, this seems like a massive expense. Unless my physicians also have to use a piece of PicnicHealth software?
edit: It looks like this works by integrating with a patient portal provided by the healthcare institution.
how can you even consider launching a service like this without being fully audited for HIPPA and ISO 27001. all i see on their site is boiler plate sec that in no way addresses the reality of the business domain they want to operate in.
you'd be insane to put your data into something like this without those controls in place. moreover, they are asking for serious regulatory trouble launching without it.
this one business challenge that will not be solved in the valley. this problem will eventually be solved by the large industry players in insurance and hospital management in a model similar to that of the DTCC..
This business challenge is only going to be solved by startups, because all of the existing players rely on it being such a fucked system. They're not going to fix anything.
This is absurd. So rdxm is a "shill" merely because he or she pointed out some very real and important issues surrounding this sort of technology, and then also pointed out the fact that established players are best prepared to handle such challenges? Huh?
If you're going to make such accusations, or even just hint at them, please provide us with at least some real evidence to show that rdxm is being directly compensated by one or more of the industry incumbents for posting that comment. Since I doubt very much that you can provide that evidence, I think it would be appropriate for you to apologize to rdxm and to the rest of the community here.
Eh, I'd expect somebody shilling for Epic or any of the other major vendors to sound the same way--which is exactly what I said, no more no less. I'm not going to apologize.
The problem with bandying about "HIPPA [sic]" and random ISO security standards is that it only serves to dampen enthusiasm for fixing the staggeringly pervasive issues of mismanagement and technological obsolescence.
Anybody can come up with a "no" or a problem--"but but but HIPAAaaaaa" is a common refrain from people who want to sound like they know something but who lack the talent or skill to fix the fucking thing.
I used to work at Epic. I don't think that we had shills. I think we had more farmers employed than marketing staff when I was there, honestly.
All jokes aside, I think the passing of the ACA has changed things drastically. With insurance companies no longer able to make more money by charging more money/denying coverage to the sick, they are slowly becoming more active on coming up with ways to be innovative on making patient care more streamlined and affordable. Sometimes they'll work with startups (Aetna CarePass comes to mind), and they definitely should. But, sometimes they'll go it alone as well. It's exciting to see it all play out right now in the industry.
Hey I don't work at Picnic but I do work at Prime.
Picnic and Prime do similar things. I've met the Picnic team. They're great, and so is Picnic. They understand HIPAA. I'll let @nogaleviner speak to the specifics of their HIPAA considerations but I do want to clear up some general things up about HIPAA since we've (as has Picnic) been working on this for a year or two now.
1. It's HIPAA, not HIPPA.
2. The "P" in HIPAA stands for Portability (h/t @katgleason). The salient parts of HIPAA for this conversation are:
a. HIPAA makes what Picnic does possible. The overall point of HIPAA is to open up data, to let patients say to their doctor "I want my medical record" and require doctors to fulfill that request. The September 2013 update to HIPAA even said that if a patient asks for their records electronically, their doctor has to provide them electronically. Without HIPAA, Picnic probably wouldn't exist.
b. HIPAA does stipulate two Rules: the Security Rule and the Privacy Rule. In a nutshell, these rules don't prescribe specific implementations but do require general considerations. The high-level overview is: data has to be encrypted in transit and at rest, all data access has to be logged (for auditing), and employees have to be HIPAA-trained. Generally speaking if you build something that meets a decently high level of conventional web security standards, you could probably meet the technical requirements for HIPAA.
Now this is important: while b) is true, this actually only applies to entities who are required to be HIPAA-compliant, i.e., medical care providers. Technically Picnic isn't a care provider and therefore does not need to be HIPAA-compliant.
That doesn't mean Picnic doesn't take security and privacy very seriously. And I can tell you they do: their site is SSL-enabled and they know what they're doing.
Again, just speaking to the HIPAA points here, not the business considerations. Hope that helps clear some things up.
Although they may not technically have to be HIPAA compliant, they certainly have to allow some of their clients - specifically medical providers - maintain HIPAA compliance.
In general, with respect any health tech startup that stores or transmits personal health information, if you try to tell a client that you don't technically have to be HIPAA compliant, it's gonna raise red flags. Assuming you are following the appropriate HIPAA rules, it's best to just say you are HIPAA compliant.
even if they only are going to function as what's referred to in HIPAA as the "Business Associate" standard, if you really dig into it they'll essentially need the same level(s) of control as a straight-up HIPAA compliant business would. that is if they want to be in a defensible position when they get breached...
additionally, the reason that I mentioned ISO 27001, is that it's not just HIPAA, it's also all of the other controls both internal and external you must have in place. if your assertion is that they have sec dialed because their site is SSL enabled, well, that's frankly a little scary and somewhat naive.
Blue Shield of CA and Anthem announced a health exchange to store patient info a few days ago...
Obviously PicnicHealth is onto something but they will have some challenges as they don't have massive relationships with providers. At launch it will have 9 million patient records without even blinking
Founder here again. This is super cool. I haven't been able to get too much detail on it yet. Most of the health exchanges haven't gone far because they start with government of foundation funding and then have no business model, but with these guys behind it, they actually make sense.
We'd be thrilled if we could focus on building a really good product for making medical data useful for patients instead of building infrastructure for moving it around.
Very true, execution of a health exchange infrastructure has been riddled with troubles in the past.
Interfacing with patient data is still a great idea, practically nonexistent today. a central location for data will only make your service more robust and require less integration.
One of the things that keeps me out of the healthcare space is that you could build the most amazing tool, yet it wouldn't catch on because no one has enough time or incentives to start using it (and you're not playing golf with the right people).
That said, PicnicHealth looks nice, and I wish them best luck! The pricing seems a bit high for someone who doesn't have health issues and just wants to keep track of regular tests, but I find it easier to trust a paid service than a company with a surprise business model.
Another problem is that doctors and health in General is highly specialized. So a doctor needs a set of options while the next needs another, etc.
So it's kind of hard to fit everything in one basket. There is HL7 that should a sort of golden standard but many programmers on the field totally ignore it.
Urk. I'm not impressed--it's already shaping up to be super-enterprisey and architecture-astronauty, and supporting binary stuff means folks will keep smuggling in HL7 v2.
HL7 isn't a single standard; it's a standards body which publishes many different standards each with multiple versions. And it's not really practical to fully implement them all. So if you want to interoperate with an external system first you have to find out which flavors of HL7 they support and then build around that.
Some people criticize HL7 for being overly complex. And there is some truth to that due to legacy issues. But the reality is that healthcare is tremendously complex and so that drives a certain level of unavoidable complexity in the standards.
Besides, Comprehensive health records as well as yearly physicals are meaningless for healthy people.
I also found that people don't trust paid services either, when it comes to their health (at least when provided by companies other than their health provider)
I like the idea behind Zenobase.
Aurametrix explored relationships between many different sources of data that could be related to health. It is not public now, but would be happy to share the insights.
Founder here - Thanks for the good wishes! I totally agree that lots of people don't have the time or inclination to worry about this stuff. I used to be just like that, and then I got sick. That changes everything. When you're ability to function, feel good, and even live hinges on this stuff, you start paying attention real fast.
For the moment we're focused on folks with serious illnesses, but we've got plans down the road for pricing and a product geared more toward the casual user. Thanks again!
One of the things that keeps me out of the healthcare space is...
I dropped out, after implementing five exchanges, because it became obvious to all of us doing the work that single payer was the only correct answer. All of our customers and partners were competitors and had no incentive to share data.
I didn't anticipate consolidation of providers, perhaps accelerated by the passage of ACA. Babysteps, eventually leading to single payer? I don't know.
The medical space is so FUBAR'd that I don't see any value in trudging in there as a startup. It's just asking for pain. The industry is not ready for this kind of thing yet, and won't be for the indefinite future.
The whole way we do medicine just needs to be nuked from orbit. The current system we have is one of the most grotesque and tangible examples of human exploitation in modern times. This applies outside America too; your problems don't go away just because your government has given the industry a blank check.
Source: I was a long-term contractor who had options in a medical imaging startup.
This is a hard space to be in. I am glad ycombinator is funding startups like this. To survive in this space you need to be profitable early on and it looks like you guys are already focusing on that business wise.
The challenge for your business is the various Emr/EHR systems that you have to pull data from. Some of these vendors might not be so friendly, has data lock in is a business strategy. Some systems might not have HL7 or some other type of known integration; the interfaces could be proprietary. Some systems might use their own custom database. Getting out EHR data even in known databases (MySQL , SQL server, etc) could be challenging if integration doesn't work and you have figure out the schema mapping, as the vendor has no incentive to give you the schema.
I am not sure your one price fits all can work well. It seems like it would work for known systems you know you get data accurately out of. What about all those one off deeply proprietary systems; it might take allot more time. I guess getting EHR printouts and manually entering in data is one strategy, but it's quite error prone. Accuracy means everything here. On top of that some of these doctors might not have any incentives to let your team figure out how to pull data from their system.
I know this because I use to do data migrations for a top EMR company. Medical records migrations are considered the most complex.
I would also add that how would your customers know you won't lock in their data. Will you publish your data format?
I implemented the backend for a few early health exchanges (BHIX, NMHIC, NYCLIX, etc). Things change, my observations are a few years old, so YMMV.
#1 - Players are loathe to share their data. Much integration is now occurring because of consolidation, vs interchange.
#2 - Patient privacy can only be protected one of three ways.
a) globally unique identifiers which are then used to hash / encryption the data (translucent database style).
b) centralized storage, ala thumb drive or dropbox.
c) better laws with real teeth.
I don't see a, b, or c on the horizon.
People freaked over RealID. Medicare for All isn't in the cards yet. So no GUIDs.
Centralized storage ala UK's NIH is contingent on single payer, aka Medicare for All. Not in the cards at this time.
As for privacy protections in the law with some real enforcement, well, that'd require consensus that our government should protect the rights of humans.
#3 - I worked very hard on ETL (extract transform load), atomizing HL7 into RDBMS and then back out again. Here's a free idea:
Don't bother. Just log the incoming HL7 (2.x, 3.x, misc other formats like CCA). Then index it with Lucene or equiv. Finally, map/reduce it to process queries.
I was very proud of our backend datastore. I could go on and on about auditing, making various queries performant, modeling, etc. Alas, every player wants to see their data their way, and canonical strategies just aren't feasible across multiple customers.
Lucene works well enough for indexing textual reports (chart notes, discharge summaries, etc) but doesn't do too much for coded discrete lab results. I've found it works better to transform HL7 V2 messages into the XML encoding and then store the entire XML document into a relational database XML column. Then you can find what you need with XQuery.
44 comments
[ 4.7 ms ] story [ 98.6 ms ] thread“When you’re dealing with potentially the hardest moments of your life, you don’t have to worry about these other logistical tasks and the feeling of confusion on what’s exactly going on,” Leviner said.
True, but I sat down and uploaded most of my data to Google Health when I wasn't sick, and I've been wishing for a simple replacement ever since it shut down. This is a nice-looking project but it appears to leave users with little to no input of their own into their clinical record-keeping. I also wonder (based on previous experience with obtaining my own medical records) how they intend to deal with the fees imposed by medical service providers for the collation and administrative release of the data. I paid about $100 a few years ago for the records of a brief hospital stay, which ran into hundreds of pages (much of it duplicative, and with much of the salient information being in handwritten form).
In another case, my doctor worked for a multi-doctor practice that went out of business, and it was claimed all records were lost due to "computer problems". Nothing really valuable there, but with so much chaos in the US medical systems, where I have and see lots of doctors giving up independent practice and going to work for "the man" ... well, at the very least PicnicHealth should allow a client to send them paper copies or scans of records.
Also, how does this product compete against Health Vault?
About fees, you're right: one of our users would have had to pay over $700 in fees if he had tried to get the records from just one of his hospitalizations on his own! We have relationships set up so that we avoid fees almost 100% of the time, and when we can't avoid a fee we cover that ourselves. Our job is also to sort through the mess and pull out the salient information so that you don't have to.
Large doctor practices sometimes have 2 or even 3 people just dedicated to fulfilling medical record requests. That's a huge expense. I help run a home health company that is constantly requesting medical records. We still receive most records by fax! Our receptionist spends a good bit of her day handling this process. It's a huge waste on both ends. If you could make that process easier I think a lot of providers would be willing to pay... Regardless, best of luck! So much opportunity in this space, keep pushing.
> We personally make sure your doctor has updates before you get to the office.
This is huge. With all the different record systems, many of which still use physical paper, this seems like a massive expense. Unless my physicians also have to use a piece of PicnicHealth software?
edit: It looks like this works by integrating with a patient portal provided by the healthcare institution.
you'd be insane to put your data into something like this without those controls in place. moreover, they are asking for serious regulatory trouble launching without it.
this one business challenge that will not be solved in the valley. this problem will eventually be solved by the large industry players in insurance and hospital management in a model similar to that of the DTCC..
This business challenge is only going to be solved by startups, because all of the existing players rely on it being such a fucked system. They're not going to fix anything.
If you're going to make such accusations, or even just hint at them, please provide us with at least some real evidence to show that rdxm is being directly compensated by one or more of the industry incumbents for posting that comment. Since I doubt very much that you can provide that evidence, I think it would be appropriate for you to apologize to rdxm and to the rest of the community here.
The problem with bandying about "HIPPA [sic]" and random ISO security standards is that it only serves to dampen enthusiasm for fixing the staggeringly pervasive issues of mismanagement and technological obsolescence.
Anybody can come up with a "no" or a problem--"but but but HIPAAaaaaa" is a common refrain from people who want to sound like they know something but who lack the talent or skill to fix the fucking thing.
All jokes aside, I think the passing of the ACA has changed things drastically. With insurance companies no longer able to make more money by charging more money/denying coverage to the sick, they are slowly becoming more active on coming up with ways to be innovative on making patient care more streamlined and affordable. Sometimes they'll work with startups (Aetna CarePass comes to mind), and they definitely should. But, sometimes they'll go it alone as well. It's exciting to see it all play out right now in the industry.
Picnic and Prime do similar things. I've met the Picnic team. They're great, and so is Picnic. They understand HIPAA. I'll let @nogaleviner speak to the specifics of their HIPAA considerations but I do want to clear up some general things up about HIPAA since we've (as has Picnic) been working on this for a year or two now.
1. It's HIPAA, not HIPPA. 2. The "P" in HIPAA stands for Portability (h/t @katgleason). The salient parts of HIPAA for this conversation are: a. HIPAA makes what Picnic does possible. The overall point of HIPAA is to open up data, to let patients say to their doctor "I want my medical record" and require doctors to fulfill that request. The September 2013 update to HIPAA even said that if a patient asks for their records electronically, their doctor has to provide them electronically. Without HIPAA, Picnic probably wouldn't exist. b. HIPAA does stipulate two Rules: the Security Rule and the Privacy Rule. In a nutshell, these rules don't prescribe specific implementations but do require general considerations. The high-level overview is: data has to be encrypted in transit and at rest, all data access has to be logged (for auditing), and employees have to be HIPAA-trained. Generally speaking if you build something that meets a decently high level of conventional web security standards, you could probably meet the technical requirements for HIPAA.
Now this is important: while b) is true, this actually only applies to entities who are required to be HIPAA-compliant, i.e., medical care providers. Technically Picnic isn't a care provider and therefore does not need to be HIPAA-compliant.
That doesn't mean Picnic doesn't take security and privacy very seriously. And I can tell you they do: their site is SSL-enabled and they know what they're doing.
Again, just speaking to the HIPAA points here, not the business considerations. Hope that helps clear some things up.
In general, with respect any health tech startup that stores or transmits personal health information, if you try to tell a client that you don't technically have to be HIPAA compliant, it's gonna raise red flags. Assuming you are following the appropriate HIPAA rules, it's best to just say you are HIPAA compliant.
HIPAA is not a big deal, and even more entertainingly, mostly only covers identifying information:
http://www.hipaa.com/2009/09/hipaa-protected-health-informat...
even if they only are going to function as what's referred to in HIPAA as the "Business Associate" standard, if you really dig into it they'll essentially need the same level(s) of control as a straight-up HIPAA compliant business would. that is if they want to be in a defensible position when they get breached...
additionally, the reason that I mentioned ISO 27001, is that it's not just HIPAA, it's also all of the other controls both internal and external you must have in place. if your assertion is that they have sec dialed because their site is SSL enabled, well, that's frankly a little scary and somewhat naive.
Obviously PicnicHealth is onto something but they will have some challenges as they don't have massive relationships with providers. At launch it will have 9 million patient records without even blinking
https://www.calindex.org/
We'd be thrilled if we could focus on building a really good product for making medical data useful for patients instead of building infrastructure for moving it around.
Interfacing with patient data is still a great idea, practically nonexistent today. a central location for data will only make your service more robust and require less integration.
That said, PicnicHealth looks nice, and I wish them best luck! The pricing seems a bit high for someone who doesn't have health issues and just wants to keep track of regular tests, but I find it easier to trust a paid service than a company with a surprise business model.
So it's kind of hard to fit everything in one basket. There is HL7 that should a sort of golden standard but many programmers on the field totally ignore it.
As for docs, the main problem is that they've spent the last century or two training snowflake workflows and vocabularies. :(
Some people criticize HL7 for being overly complex. And there is some truth to that due to legacy issues. But the reality is that healthcare is tremendously complex and so that drives a certain level of unavoidable complexity in the standards.
I also found that people don't trust paid services either, when it comes to their health (at least when provided by companies other than their health provider)
I like the idea behind Zenobase. Aurametrix explored relationships between many different sources of data that could be related to health. It is not public now, but would be happy to share the insights.
For the moment we're focused on folks with serious illnesses, but we've got plans down the road for pricing and a product geared more toward the casual user. Thanks again!
I dropped out, after implementing five exchanges, because it became obvious to all of us doing the work that single payer was the only correct answer. All of our customers and partners were competitors and had no incentive to share data.
I didn't anticipate consolidation of providers, perhaps accelerated by the passage of ACA. Babysteps, eventually leading to single payer? I don't know.
Maybe I should have stuck it out.
The whole way we do medicine just needs to be nuked from orbit. The current system we have is one of the most grotesque and tangible examples of human exploitation in modern times. This applies outside America too; your problems don't go away just because your government has given the industry a blank check.
Source: I was a long-term contractor who had options in a medical imaging startup.
The challenge for your business is the various Emr/EHR systems that you have to pull data from. Some of these vendors might not be so friendly, has data lock in is a business strategy. Some systems might not have HL7 or some other type of known integration; the interfaces could be proprietary. Some systems might use their own custom database. Getting out EHR data even in known databases (MySQL , SQL server, etc) could be challenging if integration doesn't work and you have figure out the schema mapping, as the vendor has no incentive to give you the schema.
I am not sure your one price fits all can work well. It seems like it would work for known systems you know you get data accurately out of. What about all those one off deeply proprietary systems; it might take allot more time. I guess getting EHR printouts and manually entering in data is one strategy, but it's quite error prone. Accuracy means everything here. On top of that some of these doctors might not have any incentives to let your team figure out how to pull data from their system.
I know this because I use to do data migrations for a top EMR company. Medical records migrations are considered the most complex.
I would also add that how would your customers know you won't lock in their data. Will you publish your data format?
#1 - Players are loathe to share their data. Much integration is now occurring because of consolidation, vs interchange.
#2 - Patient privacy can only be protected one of three ways.
a) globally unique identifiers which are then used to hash / encryption the data (translucent database style).
b) centralized storage, ala thumb drive or dropbox.
c) better laws with real teeth.
I don't see a, b, or c on the horizon.
People freaked over RealID. Medicare for All isn't in the cards yet. So no GUIDs.
Centralized storage ala UK's NIH is contingent on single payer, aka Medicare for All. Not in the cards at this time.
As for privacy protections in the law with some real enforcement, well, that'd require consensus that our government should protect the rights of humans.
#3 - I worked very hard on ETL (extract transform load), atomizing HL7 into RDBMS and then back out again. Here's a free idea:
Don't bother. Just log the incoming HL7 (2.x, 3.x, misc other formats like CCA). Then index it with Lucene or equiv. Finally, map/reduce it to process queries.
I was very proud of our backend datastore. I could go on and on about auditing, making various queries performant, modeling, etc. Alas, every player wants to see their data their way, and canonical strategies just aren't feasible across multiple customers.
Our physician facing portal didn't allow searching on lab results, e.g. show WBC below 4,000.
We'd just show graphs of a patient's lab history, with filters for types of labs, date ranges, etc.