4 ms·
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 l
by pptr1 12y ago
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?
- specialist 12y agoI 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.
- angersock 12y agoShoot me an email--let's talk.
- nradov 12y agoLucene 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.
- specialist 12y agoProbably. 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.