Clinical/Healthcare Working Group

Oh. Business side? Yeah, I can talk on that more if people would like.

The important numbers are that annual US healthcare spending is nearly $3.8 trillion, and the Electronic Medical Records market is nearly $25 billion.

A good comparison to understand the scale of those numbers is to look at cataract surgeries (the single largest segment payout that Medicare makes), which we perform 2 million of per year, with $16.2 billion in direct medical costs, but which saves $123 billion in indirect costs. Cataract surgery in one eye or both is a billion dollar a year issue.

Oh, for sure. They’re buckling under the weight of all the data. The systems they’re built on simply weren’t designed for the data loads of biometric wearables and genomic analysis.

But I do think that for Meteor to succeed, it’s going to have to be a Google or Facebook to the IBM/Microsoft that Epic and Cerner represent. They’re too entrenched, and Meteor isn’t going to be able to compete by building a better EMR. But if Meteor can carve out the PHR market and handle biometric wearables? And can handle genomic datasets? Or provide easy-to-deploy solutions for the underserved nursing home market? It will be about using the strengths of Meteor to solve problems the current EMR systems can’t handle; and to open up entire new markets.

If we keep on message about Meteor being the 21st century version of M/MUMPS, and keep referring to Epic and the Veterans Administration, I see no reason why not.

As far as UI goes, there’s a huge need for airline style kiosks and displays, for both patients and employees. If you look at all the medical hardware on the market, very few of them expose a windowing system… they’re all kiosked with dedicated workflows, if they’re not locked down entirely to a single screen. So, I’m betting on a Card UI inspired by the Day Made of Glass videos will sell like hotcakes.

But the real question of whether the industry will accept us boils down to HIPAA compliance and FDA regulatory approval (Code of Federal Regulations Title 21, § 820.75, in particular.).

We’re making good progress (I think) with HIPAA compliance, by way of the clinical:hipaa packages and the HIPAA Policy Generator. We’re seeing companies in the Meteor ecosystem successfully use these packages to navigate due-diligence reviews; which is the first step to a full audit.

I’d say the single biggest challenge at this point is getting the testing story sorted out for FDA regulatory review. We’ve had the Validation testing infrastructure for two or three years now, with the Nightwatch framework. Unfortunately, the team members of the Velocity project actively rejected nearly $15K of contributions we tried to make to the project. So Velocity is pretty much dead-in-the-water as far as CFR 21, § 820.75 Validation testing goes.

But the good news is that the StarryNight utility is working like a champ; and we have an integration path to getting the Nightwatch launcher incorporated with the meteor tool. Validation testing will probably eventually look something like:

meteor --release clinical:METEOR nightwatch

Of course, there’s still the Verification testing story which needs to be sorted out. Recently, the lead Nightwatch dev managed to add full Mocha integration to Nightwatch, which lets us use the describe/it syntax in Validation testing. So that’s becoming an isomorphic API. And we’re making some progress with a fork of mUnit called clinical:verification, which lets us describe/it syntax. Unlike the mike:mocha package, by using a mUnit derivative, we are able to include core TinyTest packages in an FDA audit.

So, if we can get that all sorted out, we should have a testing utility/infrastructure that’s compliant with CFR 21, § 820.75.

That’s… actually, pretty close to what I’m aiming for. Maybe with a bit more airline kiosk and augmented reality look and feel. But generally pretty close.

Well, right now it’s still sort of a thesis project for me. There are the demo apps which will be released later this year, and I have a couple of apps I want to get into the iTunes AppStore. Once one or two of those get released, I think it will be easier to sit down and think about business structure(s). I would anticipate having more of those kinds of conversations in Q1 2016.

I don’t think there’s any community guidelines that would prevent you from simply opening up a new thread on the forum, and we can do it here. If we get enough of these kinds of threads, who knows? They might even make a ‘clinical’ category.

Have you spoken to the company ‘Corning Incorporated’ about the glass? I know a company here that can build us kiosks for cheap. They already have a project that incorporates ERP with IOT. And they are selling it cheap, the whole system. Insane value proposition. I can talk to them about building kiosks. Also, previously I worked making Human-Machine-Interfaces for factories. Those were touch screens really. So with the present tech, either cheap micro controllers or even the raspberry pi, traditional kiosks will not be a problem coupled with normal touchScreens, I can do it. But for time restriction, say I delegate the kiosk to this company, this will become a reality sooner than you think. Also we have whole community of designers here in my hometown who can design the UI for you.

Great news , I am Medical doctor also coding with meteor for sometime now ( social media monitoring and analytic app for some local companies ) … finished some projects with it but Not medical or health-care products yet , but planning to port my Django EMR ( EMAD EMR ) to Meteor with Visualizing Medical Records concepts with Meteor soon .

I would like to be involved .

I think i will write a topic about this in medevel.com soon .

Best regards.

2 Likes

It’s good to see more coding doctors :wink: I am a radiologist in Germany who worked as web developer before becoming a medical doctor. I still love to code and do it a lot in my free time (and every now and then for a science project).
I am interested to contribute, too. Especially in the imaging part of such a project.

3 Likes

Just curious: why is Meteor better suited for this job? It doesn’t seem to have much in place to handle big data.

Welcome! Looking forward to seeing it! :smile:

Hello!
We’re going to be using the cornerstone DICOM viewer. There’s an alpha version of it packaged up, which isn’t on Atmosphere quite yet; but we’ve confirmed that it works with Meteor quite well. I need to speak with the project leads on that, and see if we’re using that version, or if Clinical Meteor will need to package it’s own copy. I’ll keep you posted once we figure those details out.

1 Like

Because it’s based on Mongo. :slight_smile:

Big Data Explained
An Introduction to NoSQL and MongoDB

Mongo is optimized for horizontal scaling of the database layer, and can just add server after server to the cluster. Plus some basic map-reduce functionality, and the ability to handle schemaless datastructures. (Healthcare data is notoriously denormalized and fuzzy; just like biology).

Meteor isn’t just a reactive web application framework; it’s a big-data application framework. It’s just too bad that they took the data-visualization library D3 out of core. (But we’ll get it added back to the clinical release!)

1 Like

Yeah, but that’s more a Mongo feature than it is a Meteor feature, so this would be true for every framework that supports Mongo (or any of the Apache big data stuff). If you also want to publish all of this data reactive to clients, than I can imagine Meteor’s mergebox eating up way too much resources. I’m curious because we spend a lot of time thinking about our data model in order to reduce the amount of data we need to send to the client because of this. But we never did a lot of tests to see how far this reasoning holds up, so maybe it’s not that big of an issue as we think.

Yeah, I found this out the hard way, I did my MsC thesis on hyperheuristics to optimize occupancy of operating theaters. First tried to model all of the data in an sql database, not my biggest success :p.

Oh, sweet; job-shop scheduling problem. Yeah, I’m a fan of P. Maes and Z. Michalkiewicz approach using GA/EP algorithms for those kinds of problems.

Keep in mind that when Meteor was first released 3 years ago, it included D3 and was pretty much the only open-source, full-stack Data Visualization platform available for NoSQL/Mongo. We wound up implementing a bunch of realtime analytic pipelines; as did UCSC and various other groups. If you add those data visualization and pipelining technologies back into the mix, then Meteor has quite a few advantages over, say, Lithium/PHP on Mongo.

Speaking of pipelining, we’ve not had problems with mergebox being overloaded. If you have a cascading workflow pipeline, where collection A handles receiving the firehose of data, and your Meteor app is only connected to collection C… then all is well.

A -> B -> C -> D -> E

1 Like

Do you mean like Practise Fusion? Ad based free service??

@kaiyes and @davidvm and @hamzamu and @medihack and @fridag great to see your huge ideas! More please :grinning:

@awatson1978 what is the status of hangouts/conference calls? Anything planned for the near future? Kindly let me know if I can help set anything up
Dave Donohue

3 Likes

@dpdonohue nice to see you here after a while !!

@awatson1978 yep, would love monthly hangout calls.

1 Like

How does OpenMHealth fit into this picture?

They have a good new JS visualization library

And Shimmer looks pretty useful. It appears to be a server-side integrator with different tracking APIs (FitBit, Withings, etc) plus an infrastructure for adding more connectors.

Maybe we could have a Meteor package to incorporate their web-visualizations, and another to interoperate with a Shimmer server.

2 Likes

What is the deal with HIPAA-compliant hosting? Only certain hosting providers are HIPAA compliant? Is it possible to have a HIPAA-compliant application running on say DigitalOcean?

@awatson1978, I read your terrific post here
https://github.com/awatson1978/meteor-cookbook/blob/master/cookbook/healthcare/hipaa.md

Here is another “HIPAA-compliant hosting” vendor: https://www.aptible.com/compliance/

1 Like


work in progress ! Currently empty. But She does have a plan to integrate them later. These were made I think 2 years ago. We gotta get together on Hangout doctor.

@awatson1978 any update on a hangout with all of us?

Yeah, let’s do it! Now that I’m relocated out to the west coast, I’m even thinking of doing weekly calls.

Thursday mornings (Pacific time) seem like a likely candidate; as well as Monday late afternoons/evenings. I’m trying to figure out how best to handle time zone differences, and folks who are in Asia. My hunch is that there’s enough interest that we might be able to handle weekly calls… maybe every-other-week Thursday mornings around 10:00/11:00am Pacific for North/South America; and every-other-week Monday evenings around 9:00/10:00pm for Asia/Australia?

Let’s do it! :slight_smile:

1 Like

Yeah, they’re definitely emerging as a real player in this space. They’ve obviously got a long-term strategy, and have been investing in the right next-gen technologies, and I’d say they’re likely to survive the upcoming EMR shakeout/merger/consolidation that’s beginning in the industry.

So, a little backstory: 3 years ago, when I first started using Meteor, I did a survey of existing APIs using http://www.programmableweb.com, which is focused on web-based APIs. From it, I generated a short list of JSON formatted APIs.

Cigna
Stripe
Dossia
mHealth
CarePass
FitBit
HealthJibe
VitaDock
Withings

My thought 3 years ago was simply “this list is sufficient to build a business on”. It’s worth making a deep investment in JSON and a pure-Javascript strategy.

3 years later, and CarePass is considered a failure, but mHealth seems to be thriving. And FitBit and Withings are going strong, but with competitors like iHealthLab, which is using Meteor as their app frontend.

But long story short… I started out doing a FitBit and Stripe integration, and then realized that we needed to get the HIPAA, FDA, and shared components figured out before worrying about data integration. So, I shelved writing integration adapters for those APIs until I got other things sorted out.

Now that we’ve got HIPAA and FDA figured out, and have a release track published (in beta), it’s an excellent time to revisit data integration APIs. If anybody wants to contribute to the overall Meteor ecosystem, writing packages that connect to mHealth and various other APIs is an absolutely fantastic contribution that people could make.

1 Like

Rumor on the street is that Digital Ocean won’t sign Business Associate Agreements (BAA), which makes them not HIPAA compliant. Same with Joyent.

http://www.cloudreviews.com/digitalocean.html

Happy to add Aptible along with Catalyze and Azure as HIPAA compliant Node/Meteor hosting providers.

1 Like

knew about catalyze. They even have a HIPAA compliance guide.

I’m okay with whatever timing you have as the time difference is nice for us. I don’t think there is any need for 2 sessions every other week. Once a week will do it I guess. So when is the next one?

Also, after the recent hub-bub of Mitar’s thread, and faceyspacey’s proposal and all that… Though I think clinical has a TON to do rather than think about React…I am starting to give this a bit more thought.

I am concerned about blaze after carefully seeing everything MDG is saying & doing, though they are not saying it in public. I think they won’t develop Blaze any more.

Since we are in healthcare industry, once made, the software do not change a lot over time. What happens after 3 years later when we suddenly don’t have any more support for Blaze ? We end up with TON of code written in Blaze that we will have to support ourselves. Though we can always hack blaze and add various packages & maintain it ourselves, isn’t it better to switch to React now ? It will easy to hire devs and its fairly simple to learn. Not to mention the the intro to the functional programming. React seems like the best way for javaScript world to get the test of What Clojure , Elm have been doing.

now that this issue has become apparent, this might be high time to think about it

1 Like

@awatson1978 Glad you plan to start up calls. I have conflicts those times but will stay plugged in to any minutes you produce.

I was interested in trying out iHealthLabs as a home monitoring solution for my practice, toward keeping patients out of the hospital and toward letting them age in the home. Neat that they are Meteor-based. Maybe they can incorporate elements of the Clinical Meteor Track in their software. I hope they release some of their packages to the Clinical Meteor Track.

@kaiyes good thoughts on React. Yes it would be a shame to announce production-ready Clinical Meteor Track just as MDG announces Blaze is in containment. Also so very hard to find stability among these technologies. 3 years ago Meteor barely existed. So hard to predict 3 years into the future but I agree right now it looks like React + Meteor is a good bet.