markolschesky

Agreed. I was previously a founder with a company in an incubator in which we were able to negotiate the terms of the deal. One founder spent 3 months basically trying to negotiate the terms and at the end we didn't take that funding and it was like lighting 3 months of time of fire on equity discussions that didn't matter if we weren't successful. If you only have 2-3 founders, it's a major distraction/waste of time up front when you really need to be taking advantages of whatever the incubator provides (connections, mentorship, pilots, etc.) and executing. If there are no advantages, don't join the incubator. If you don't want to take VC funding, you probably shouldn't join an incubator/accelerator since VC connections are usually the few consistent things the incubator can provide.

"I'm pretty sure AWS has a package for HIPAA compliance that will checkmark most of the required fields outside of the application."

Not quite, in fact, the first thing you need to do to meet a BAA with many cloud vendors is terminate SSL locally. This means no using things like ELBs. What about if you need a VPN? How do you guarantee that traffic is still encrypted (let's say TCP) once it hits the VPC VPN to your application server. These are very real healthcare compliance scenarios which you would need to figure out a solution for on the infrastructure side which you would need to build buy. I'm sure there are similar things that need to be handled WRT PCI.

Application security is important (of course). I used to work on application security with hospital organizations at an EHR vendor, so even though we sell infrastructure I can help customers out when it comes to this topic. The reason why there isn't really an "Application Security checkbox" is because the question? "What is the correct amount of access to patient data" is a hard one. Prestigious healthcare organizations all the way down to startups struggle with it, so it's usually a more involved process.

Much like how 95% of brewing beer involves cleaning, 95% of compliance involves paperwork and audits. A ton of it. In a world where setting up a VPC (or its equivalent) is the table stakes for compliance, achieving the rest of your compliance takes a lot more work than setting up a private VPC. That's true on Amazon or any other service.

The biggest thing to consider when adding another layer onto your compliant stack is how easily you can prove compliance when your customers ask. Whether it's BAAs, SSAE 16 documentation or access to HIPAA or HITRUST audits, you need your partners to be able to provide you with not only the documentation but the expertise to discern what that documentation needs. When your partner decides to build something as an add-on to a stack like `Your product > Heroku > AWS`, you need to guarantee that the middle man can either answer all of your questions or can find the person downstream who can when it's relevant. As we've needed to work with partners and considered doing add ons with compliance, this has been the #1 question we've needed to answer first. In a world where your customers should be willing to pay for compliance, the person you call on the phone with questions about what it takes to achieve compliance on their stack should be able to tell you from experience what it's like going through a HIPAA, HITRUST or PCI audit.

Most of the documentation we've provided where I work on the subject is free online: http://catalyzeio.github.io/policies. You can see through the forks that folks have used the documentation to prove compliance not only on our platform at Catalyze but also on other stacks like AWS.

To me, it's the fact that Mirth nickel-and-dimes users for "premium" features and has pretty poor documentation to push people towards support plans. It's an open source platform "kind of", which rubs some folks the wrong way.

However, the functionality of the engine itself is top notch. We've had some Mirth servers running for a year at this point without incident. It handles alot of things around the nuances of HL7 nonchalantly, which has usually been my hang-up with non-healthcare specific toolsets like Mule or Camel.

If you haven't checked out Mirth in it's v3 format, it's not terrible. I find that alot of the hold-up with HL7 setup in regards to logic involves VPN setup and cloning/maintaining different channels that basically do identical things. We've built some tooling on top of Mirth to do this where I work and I think it's a better approach than black box integration solutions.

That being said, I'll definitely be checking this out.

Wow. I'm not OP but I'm really amazed to see a story about the Johnstown Flood on the front page of Hacker News. I'm originally from the area and I even wrote a large research paper about this when I was in college.

The short story is that many of the rich elite of the late 1880s would vacation near a man made dam in South Fork PA. The hills of the Alleghenies are ominous with a water migration route that leads straight into downtown Johnstown, which was then a bustling steel town. On May 31, 1889 a historic rain caused the dam to fail. This caused a wall of water to crash upon Johnstown, leading to 2209 deaths and what was effectively the destruction of the city. It was one of the first big stories in the post-antebellum nation and also was one of the first disasters which the American Red Cross and Clara Barton were onsite to help with.

The common story and moral derived from said story is that the rich patrons that owned the South Fork Fishing and Hunting Club did not maintain the dam which caused the dam to fail which was responsible for the fatalities caused by the flood. Lawsuits were dismissed as the flood was thought to have been an "act of God". It could be seen today (and was when now-famous historian David McCullough wrote his book about this 1968) as being indicative of how rich and the 1% lead to the direct damage and destruction of the lower class.

As someone who has researched it, there is far more to it than that. But, kinda cool to see it posted here.

I don't know if this is true. Epic has already implemented large parts of FHIR and Cerner has also committed to it as well. You can even play around with Epic's implementation on FHIR here: http://open.epic.com/Interface/FHIR. I'll admit. I was shocked when I found out it connected to a real Interconnect engine.

This makes a lot of sense. IHE profiles and CCDAs are suboptimal ways in 2015 to transfer data between HIEs and Epic/Cerner/Allscripts along with every other EHR vendor either sell them or need to connect with them. It would behoove them to embrace this support in the same way it behooved hospitals to embrace HL7v2 in 1990: it saves them alot of work and money.

Of course, this doesn't help the average patient or app developer. How users will interact with these APIs and whether or not hospitals will have a standard and easy way to open them up is still yet to be seen. I imagine there will still be some work involved there, but I'm optimistic for the future.

I wrote up a project plan that details the players and some of the steps to get HL7 data through the traditional integration methods that exist today. Check it out: https://catalyze.io/learn/how-to-integrate-with-epic-or-any-...

I think FHIR only helps this process if it standardizes/centralizes security. So much of the process of setting up integration is getting whitelisted by an organization and setting up VPNs and other security measures that have nothing to do with HL7 or FHIR or IHE profiles. If startups have to establish credibility and integrity at each hospital they go to, the cycle will continue even with a public API.

That's interesting since e-prescribing through Surescripts requires what's known as a "Discrete Sig", i.e some measurable type of dose, whenever possible. I know of one major health system that still does things the "old way", but discrete sigs are pretty common in 2015 (at least amongst Epic customers).

I gave this a spin. The entire setup was pretty buggy for me with 500s frequently being thrown.

I do want something like this, though I would be hesitant to use something this buggy.I also don't really want to tell professionals to meet with me using a product with the word "ninja" in it.

How long do companies have to utilize the $500K?

In the BizSpark Plus days, your company would receive $60K of hosting but could only use it to pay 100% of your bill in the first year of BS+. In the second year, you could use it to pay 50% and then in the third year you were paying full price for Azure. It was a pretty good deal, but if you are already spending $30-60K (or $250-$500 K) on infra in your first year or two, you're in a select breed of companies.

Hopefully this means that CyanogenMod will get more bug fixes and resources so that it feels like a truly native Android experience. I didn't even know there were two different types of headphone microphone jacks (CTIA vs. OMTP) until I hit this fun limitation on my new OnePlus: https://jira.cyanogenmod.org/browse/BACON-133

There's a bit more to HIPAA than signing a BAA with your infrastructure vendor. I agree that you currently aren't storing PHI, so you're in the clear for now. I imagine that in the future your business would require you to. There's a bunch of things like auditing, logging, vulnerability scanning, disaster recovery, training and having policies in place when you do need to fully account for protecting PHI.

We open-sourced our HIPAA policies where I work at Catalyze recently. Check 'em out and good luck! http://catalyzeio.github.io/policies/

The user's IP address (which I imagine gets collected by doubleclick) is one of the 18 identifiable attributes which makes data PHI. But, I don't think that healthcare.gov needs to comply by HIPAA.

While the data itself would fit the description of PHI, I don't know if healthcare.gov itself qualifies since it isn't a "health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse". That doesn't mean that it's against best practices. I built an analytics platform for a project with the VA on https://catalyze.io/baas (I also work there), so their are some alternatives to analytics when HIPAA is a concern.

I used to work at Epic (the Health IT company), which is known for its interesting office design and giving its staff individual offices [1]. Now that I've been working for startups, I've worked in more bullpen-type offices.

A few things:

1) Having my own office did not mean that there weren't distractions. It's impractical to build sound-proof walls between offices and the guy across from me loved to try to sing opera for hours a day. I eventually moved offices to another part of campus for that reason.

2) Likewise, I've worked in open offices that were pretty monastic. Engineers are quiet, everyone is wired in and most people talk on Slack/HipChat. The only interruption was when the mailman would drop off the daily mail.

3) I think the worst thing about open offices are the logistics of staff that need to take phone calls. As a customer-facing programmer that does sales support and configuration assistance it's sub-optimal not having a dedicated space for phone calls. When the perfect storm arises of too many people needing to take calls, everything flies into anarchy where I'm forced to take a call in a common space and try to be quiet. A bullpen that has some separation and accommodation for those needs is ok. A bullpen that doesn't have that is not.

[1] http://www.xconomy.com/wisconsin/2014/09/19/epic-hopes-wi-ca...

How did you manage support during the hackathon?

I liked that you mentioned that everyone had to contribute and no one got a "hall pass" to do real work, but I often need to manage our customer requests and it's difficult to say "I can't help you for 1-3 days because we're focusing on team building".

We do one of these quarterly and I'm trying to think how I can avoid being the worst hackweek teammate ever next time around. Maybe it is saying that we'll have limited availability for 1-3 days to some customers.

Can I sign up for something to see when the results are released?

SOAP is still common in healthcare as many IHE profiles rely on SOAP for Cross-community document/data exchange. They are a pain to work with if you don't have a toolset that handles it well.

For some context -> The MVC Music Store was the default project that you would build to learn ASP.NET and EF concepts. You can build these projects yourself with the tutorials here:

http://www.asp.net/mvc/overview/getting-started/introduction...

It's not exactly a guide about our work culture, but "Xenophobe's Guide to the Americans" does a pretty good job at succinctly describing some of our cultural quirks.

http://www.xenophobes.com/the-americans/

Maybe it's where you are located. In WI, after my LTE/3G throttling ran out, my EDGE was basically not internet. My phone was only useful as a cell phone at that point.

Wrote an answer on this on Quora last week ->

http://www.quora.com/Where-is-the-dividing-line-in-building-...

I just sent you an email too. Hopefully I can help out a bit.

Just did. Thank you!

Just updated that too. Should be BY-SA 4.0 across the board now. Thanks!

I just did a bunch more reading here on the topic in this article: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3234435/

We removed the license restriction and changed it to CC BY-SA 4.0. Thank you for the feedback!

We're going to re-license and release these with CC BY-SA 4.0. Just updated the github repo. Let us know if you need any help!

Mark from Catalyze. We picked non-commercial as the CC license type simply so that people wouldn't modify and then resell the documentation itself. From my understanding, the license allows users to use our docs for your company policies, but you can not resell the content itself. That would be against the spirit of what we are trying to accomplish with releasing the documentation. If you think that the license is prohibiting this, let me know. We want to make sure that we strike a happy medium of usage/keeping the policies "free".

EDIT: Yeah, it seems like there are some far reaching not-understood legal implications of the "NC" license. Ok, we're going to re-commit and re-issue these with the BY-SA. Should be up in a few minutes.

Someone recently asked me what country our company that had an .io domain was located in. Explaining that it was shorthand for input/output and that it was a tech thing was lost on them.

Many of our customers do (I work in HIPAA-compliant hosting), so I can tell you it's an alive and well thing. Many forms of patient data don't really fit well into relational data structures, so it's not surprising that Mongo (as the most "popular" non-relational db) is common in healthcare apps now.

Most healthcare apps are not "large" in nature and often have way more writes than reads, so many of Mongo's weaknesses don't show themselves in those applications.