markolschesky

At least in the case of subscriptions I looked at:

1) It's a continually updated file, so if you didn't subscribe you wouldn't get new data weekly/monthly. Likely the subscription aligns with the data refreshes for most products.

2) It's a one-time fee with a hefty cost attached (I saw some healthcare data sets that were $100K+). You are paying for that in its entirely and just have data rights to it.

It's rough. We thought about switching to Microsoft Teams and we realized that so many decisions about our relatively young company were tucked in DMs and private channels in Slack that we couldn't leave.

Email is non-sticky (just take your emails/save them on client and leave) Files storage is non-sticky (just move your files from OneDrive to GDrive) Chat/Collaboration is sticky as mud.

I agree that some folks often exaggerate the danger in HIPAA, especially for someone like OP with a relatively small operation. But, for companies with larger operations and reach it's definitely a non-trivial problem. Our relatively small organization has two people dedicated to compliance (and plenty of ancillary support) and goes through hundreds of audits a year. Not having a locked down well thought out solution, both technical and operational, can really put growth at risk in healthcare. Of course, that's not "HIPAA compliance", but it is "what it takes to reach scale in healthcare".

Our company had early access to this product and I was impressed by it. Our company had built our own FHIR datastore and I can attest to the fact that it's a more complex endeavor than it seems externally.

The killer feature of the product is its simple connectivity to other Google Cloud products for ML/Analytics purposes. Being able to receive a large quantity of radiology images (DICOM) or clinical data (using tools like Epic Kit/Caboodle) and immediately _do something with it_ is pretty impressive and hopefully lowers the burden for innovators in the space.

Of course, there are other options if you are looking for them, namely:

1) Azure API for FHIR: https://azure.microsoft.com/en-us/services/azure-api-for-fhi... -> Focused a bit more on application-workflows currently than ML/Analytics. Also has an open-source version: https://github.com/Microsoft/fhir-server

2) HAPI FHIR: http://hapifhir.io/doc_intro.html Open-source library from the makers of the most popular HL7v2 parser library. We run a bit of this today and it works smoothly. There's unofficial commercial support (same creators, different effort) from https://smilecdr.com/.

3) Vonk: Made by a company that has focused alot on FHIR based tooling. https://fire.ly/vonk/

It's not necessarily liability, but it is shared responsibility. Someone validating that they will take responsibility for parts of your stack can be very important, especially at scale.

I love Mirth and the community that's built around it. Thank you very much for all the work you did on the project.

HL7v2 was invented in 1989. It was invented to meet the needs of then intra-operability between existing HIS systems. HL7 itself is a open organization comprised of a variety of members from vendors to health systems to life sciences/pharma.

HL7v2's problem is that it is 30 years old and probably should have been replaced by something earlier. Then again, so should most X12, mainframes, COBOL, etc. etc. FHIR is good, but the challenge is that the incentives for interoperability are much lower than those for intra-operability.

Is this not the full version? https://itunes.apple.com/us/app/microsoft-onenote/id78480155...

It's not quite as feature complete if you're not using Office, but it's still pretty handy.

Of course. I mostly wanted to get something out quickly. Those are all a bunch of small snippets of ROS and Physical Exams which demonstrate many of the things which the article discussed, notably finding Dx, Medications and whether or not they were negative or not.

I didn't know that there was a database of notes like MIMIC! I'll have to check it out.

The textbook answer is typically that there is exponentially more data in unstructured data, but I agree with you. I thought about the unmodified use cases for this tooling for awhile and the major use case that I could come up with was finding unknown interactions or side-effects for medication and treatment combination regimens. That's all tracked very poorly in discrete fields today, especially with the nightmare that is cross-organization problem list management. Most drugs are approved by the FDA with the understanding that there will be post-marketing research (read this: https://undark.org/article/fda-drugs-post-marketing-research...), which this could hypothetically streamline.

If you want to play with this and you're looking for a decent sample exam note, I grabbed some pieces of standard looking notes (Physical, ROS, Hand exam) and tossed them into a gist here: https://gist.github.com/molsches/32fcec2499e95b5b23bc268800e...

Mostly impressive in how it parses the data and can find conditions and tests in the unstructured data. Handles a few things strangely, but I imagine that gets better over time as it continues to be trained.

I think for it to truly be useful it needs some layer of semantic data mapping to something to standards like IMO/SNOMED/LOINC/RxNorm etc but I could see that being where other companies build their "products" on top of AWS vs. AWS competing with other Healthcare ML vendors in the space.

That's actually pretty common, especially for older physicians or high-volume specialists. There are also some companies working on solutions to automate this using in-room speech recognition technologies like https://iscribes.co/.

De-identified data and data contributed by people (read, not Covered Entities) is not covered by HIPAA. Someone could build a database of procedure cost comprised of these data sets, but price transparency isn't so easy due to the nuances of the problem (See Castlight Health).

> Sounds like they didn't buy the database.

RxNorm (the codes discussed) is wholly open source. You can download weekly and monthly updates for free. Just pure laziness/avarice. https://www.nlm.nih.gov/research/umls/rxnorm/docs/rxnormfile...

The developer loaded the hard-coded data to evade detection and the PM oversaw the process where the data was validated against the government's test harness for Meaningful Use. I suppose you could argue that those people would have pushed back on the lack of ethics in the situation and halted the process to prevent their certification.

SiriKit only supports a limited number of domains and intents, of which playing music is not one of them.

No Spotify, no buy. Being locked into Apple Music is a non-starter for me. It's still mindboggling to me that Siri can't/won't interface with my Spotify account. My lowly Amazon Echo supports this just fine. In fact, I prefer it to the spotify UX/UI.

Not at all. There are APIs and also a data transfer protocol called Direct that can facilitate that data exchange in healthcare. You've just got to follow the rules of the road wrt to compliance.

HIPAA doesn't care about the logistics of whether or not the intermediary can/cannot decrypt the data. If the intermediary touches the data and it's not exempt by the conduit exception, then there has to be a BAA in place. It's why even though FaceTime hypothetically has E2E encryption and Apple claims to not have the capability to decrypt the data, it's still inappropriate to use for patient-doctor communication due to the lack of that BAA being in place.

Phone carriers are exempted under the carrier exception of HIPAA. Same thing with phone calls. API transactions are not exempted, even when encryption is used or data is not persisted in the middleware.

http://www.hitechanswers.net/when-does-the-hipaa-conduit-exc...

I wouldn't think that a Fax API provider would be exempt under the conduit exception of HIPAA/HITECH. You couldn't guarantee that the API vendor wasn't sniffing/storing/protecting data while transmitting the data between entities. You can read more about this exception here: http://www.hitechanswers.net/when-does-the-hipaa-conduit-exc...

You would facilitate that transfer by having both parties of business associates/covered entities entering a legally binding business associates agreement to outline how PHI would be protected.

Scrypt is a company that does faxing in the health tech space today and they sign BAAs and went through a HITRUST assessment.

EDIT:

So, maybe let me clarify what I mean about facilitating that transfer of data.

So, let's say there is:

Vendor ----> Health Care Provider

Even if you are sending data over TLS or some other encrypted protocol, the Vendor and the Health Care Provider need to have an agreement to protect patient data and which restrict what can be done with the PHI being transmitted. If you add a new party to this equation, like:

Vendor ----> Twilio ----> Health Care Provider

Even if you encrypt the data to Twilio and Twilio "promises" to not store the data and promises to encrypt the data when sending it down stream, promises aren't good enough in the eyes of HIPAA/HITECH. You need to have an agreement in place like a Business Associates Agreement in which all parties agree to protect PHI. You can read more about what these agreements commonly outline here: https://datica.com/academy/business-associate-agreements/

There are exceptions to this referred to as the "Conduit Exception" of HIPAA which were clarified in 2013. This doesn't really apply to API vendors or someone like cloudflare. It applies more to phone carriers, postal services and ISPs.

It's a complex topic, but I can keep jamming to discuss some of the nuances.

We open-sourced all of our docs where I work. As previously noted, it's no substitute for a lawyer if something serious is really on the line, but it's probably a good place to get started. If you're not selling B2B you probably don't need to get mired down on the specifics of legality or need to have a framework to negotiate terms and policies. The biggest thing you'll want to do is set limitations on liability for usage. You'll save money giving a lawyer 80% of T&C to tune vs. having a lawyer start from a boiler plate T&C. Especially if you need to manage any vertical-specific nuances that a biz lawyer may not be specifically attuned to.

Legal: https://github.com/catalyzeio/legal Policies/Compliance: https://github.com/catalyzeio/policies

I thought that the Carvana trade-in onboarding was pure magic. A "custom" video that described the valuation of my car was so cool that even though I ended up trading in my car with a car I bought at a dealership I really wanted to be a Carvana customer.

https://www.carvana.com/trades

Does anyone know if there is support for CTIA headphones on the OnePlus Two (and Three?).

I really loved my OPO, but not having Mic support on existing headphones I already owned was a dealbreaker for calls and audio support.

Had no idea that WhatsApp was even a Twilio customer let alone one of its largest.

>We currently generate significant revenue from WhatsApp and the loss of WhatsApp could harm our business, results of operations and financial condition.

>In 2013, 2014 and 2015 and the three months ended March 31, 2016, WhatsApp accounted for 11%, 13%, 17% and 15% of our revenue, respectively. WhatsApp uses our Programmable Voice products and Programmable Messaging products in its applications to verify new and existing users on its service. We have seen year-over-year growth in WhatsApp's use of our products since 2013 as its service has expanded and as it has increased the use of our products within its applications.

>Our Variable Customer Accounts, including WhatsApp, do not have long-term contracts with us and may reduce or fully terminate their usage of our products at any time without penalty or termination charges. In addition, the usage of our products by WhatsApp and other Variable Customer Accounts may change significantly between periods.

I recently helped a research group at a healthcare organization build a HIPAA-compliant version of mixpanel into their application to help patients with CBTi.

The app used this XML-based framework to manage the formatting of the questions so that the researchers (who were pretty tech savvy) could manipulate the questions. The XML-framework itself was a bit of a mess, but it got the job done. However, as new iOS releases passed, this XML-based framework slowly became outdated and required some extra work to maintain as time went along. Having an Apple-approved way to build surveys seems like it is the solution to that problem.

I could see a researcher who was technical enough being able to extend CareKit to be able to manage their own study without the help of a dedicated iOS dev everytime they needed to make a change to a question or survey. Part of that is CareKit, part of that is the fact that Swift seems more approachable than Objective-C. This was included in ResearchKit, but CareKit provides a way to track if people have completed daily steps and visualizing that for end users. It only took me 5 minutes from cloning the demo app and plugging in my HealthKit Entitlements that I was able to extend the sample app to track Asthma Inhaler Usage.

EHR integration will still be a challenge, but these are the type of things that my team working on Redpoint at Catalyze will work on like we did with HealthKit on it's release.

If you want to check out how I extended the sample project to include a new activity to track, you can check out my fork here: https://github.com/molsches/CareKit

For an American, it's easy to blame this on HIPAA compliance, but IMHO it has just as much to do with the speed/method in which medical malpractice suits are managed in Brazil. NPR had an article in which it took 17 years for a family to finally collect payment for medical malpractice. I also read a legal brief on the topic which indicated how this is slowly changing in Brazil.

On the other hand, in the US, many physicians are afraid to push the limit from the norm because they are afraid of being sued. That's not an unwarranted fear.

Some links on medical malpractice in Brazil:

http://www.npr.org/sections/parallels/2014/11/05/359830235/b...

http://scholarship.kentlaw.iit.edu/cgi/viewcontent.cgi?artic...

I'm totally on board with FHIR. I just don't think we're there yet. I've talked with 3 of the Argonaut sites and real-life, production ready FHIR capabilities are lacking. There aren't many useful provider-facing applications that you can built with just GET requests. Most applications require real-time pushing and pulling of data. As sad as it is, until FHIR as implemented (not theoretically) that way, we'll still be plugging HL7v2 together. I, as an HL7v2 slinger myself, hope that goes away soon.

That's true on the one hand. On the other hand, Athena wants a significant chunk of your profits to connect to their API. At least HL7v2 interface were one-time, scale everywhere from a cost model.

I think it's interesting that this article is being written in a time when more Digital Health startups are surviving than ever before. It doesn't take being an insider to succeed in healthcare anymore; there's better options for hosting and information is no longer hidden or sold on how to integrate with EHRs and payors.

As someone who has spent the majority of my career working in Digital Health (née Health IT) and helping people get data in and out of EHRs, I think any assertions that we're about to enter a new era of magical integration efforts are usually off base. There's no magic bullet to solve digital health integrations. It takes:

- Defining the value proposition of integrations for your market (Meets regulatory concerns, reduces double documentation, saves time and money)

- Knowing what the playbook for integrations looks like for your industry. What does it mean to be an integrated telehealth vendor? An integrated cancer analytics platform?

- Having a team that know how to operate in the space. EHR and HL7 vets are hard to find, recruit and retain. I think this is particularly true in the Bay Area. Expertise here is crucial.

I know alot about this and this is what our team at Catalyze has focused on solving NOW, not whenever the magic solution arrives. Looking for help on keeping your Digital Health startup alive? Let me know. I’d love to help you out. Email me -> mark <at> catalyze.io