@kaiyes and @davidvm and @hamzamu and @medihack and @fridag great to see your huge ideas! More please 
@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
@dpdonohue nice to see you here after a while !!
@awatson1978 yep, would love monthly hangout calls.
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.
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/
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! 
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.
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.
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
@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.
@dpdonohue hardware based clinical software is the way forward. One issue though. Instead of handling all the headache of logistics and shipping & maintenance (let alone hardware issues) I reckon connecting with existing hardware will reduce a lot of pain. The partnership is good for all those hardware companies as well.
I need abigail’s advise on this. If, after careful examination, we see that React has significant benefit over Blaze, only then I want to change. But mongo will stay. I want to connect data science to our data later. Here is what I am thinking:
Example : Is Flux useful for us ?
Are their better times you can suggest? There’s some flexibility. I’m simply trying to figure something that works among different hemispheres.
Alternatively, I’d suggest that it’s exactly the right time, and wasn’t possible previously, because MDG kept repeatedly breaking the build. We *want Blaze in containment. As far as I’m concerned, React integration is only half-implemented, and still lacking a Spacebars API. I’ll be happy to migrate Clinical Meteor to React once its in containment. Until then, other people can be responsible for dealing with breaking builds on the bleeding edge. I’m concentrating on bringing things into production, thanks.
I estimate Meteor v1.4 or v1.5 is when all the reference apps will move over to something React based.
ps. More thoughts on the way, regarding kaiyes’ questions. First I need to draw a diagram though.
agreed.
Agreed. And to be honest, I rather build my apps with existing tech than look for the next hype. I am the ‘if it doesn’t break, don’t change it’ type 
. Most apps in our industry is made with something else and way old and it still runs. So we do not NEED to change anything. Maybe we WANT. Thats different. Thats why I have those questions so that I understand if I should concentrate on React / Flux integration with Meteor. And true, the current implementation is still shaky.
The questions cover a larger spectrum though. It is same for every new hype that comes. And the bottom line should be, if we are fine with what we have, there is no need to change anything.
@dpdonohue, @awatson1978 whats the status for weekly calls ? Are we in ? Who else is coming? What app we are going to use ? Lot to talk 
Hi @kaiyes I think meetings are still being planned. Will definitely let you know if I hear anything. In the meantime I am curious what you are up to? Any projects afoot? Feel free to reply or message me directly.
hey @dpdonohue thanks. I am currently working a non-medical project. As soon as that ends, I will start working on porting my drug compendium android app to meteor. It is pretty simple and plan is to sell it as mobile apps in google play & IOS. We have some other medical mobile apps in planning stage as well.
Apart from that, Me and my doctor friend are trying to leverage the 'inexpensive labour ’ situation we have here and come up with a bigger healthCare product. Possibly hospital management related as the hospital he works for has a bad+old system. We might think about replacing it.
Hi. Was derailed a bit the past two weeks with poor internet connection, and some headaches with a rather obscure Autoforms implementation. Anyhow, just released RC6, and am surfacing and trying to take care of various other organizational stuff.
As for weekly calls, lets open a new thread where we can post the latest dial-in info each week. I’m thinking Google Hangouts to start, because it supports multiple users.
Listen up, Healthcare Working Group!
Morton is deprecating CollectionFS. This is a community concern if you’re in the healthcare space.
What Does CollectionFS Do?
It stores binary blob files in the mongo database. It can be used to store PDF images and DICOM images in the database, rather than on a filesystem or a 3rd party cloud.
How Does This Impact You?
Have you ever considered adding Radiology/Pathology images or PDF reports into your application? CollectionFS lets you store those images in the Mongo database. We use CollectionFS to store images and content we upload. Without it, we don’t have file uploads, image archives, or PDF reporting.
How Big of an Issue Is This?
Comparable blob-storage technology from IBM or the big document management companies is often licensed around $50K or more. CollectionFS easily represents 3 years of community development effort. If someone had to privately develop what CollectionFS provides, it would cost easily cost $250K to $500K to accomplish in-house. We need somebody on this problem for like 3 months, just to manage the deprecation, change of ownership, and get QA tests on this package. So, that’s probably $20K worth of time needed right there.
What Can We Do About This?
A) We need to identify a new maintainer.
B) We need to figure out if it stays in the same namespace; or if we open up a dicom or imaging or pacs namespace, maybe.
C) Get it under QA. I’ll help get this set up using the same system we’re using for Clinical Meteor. It will take probably a month to set up before we can even begin writing tests.
D) Donate money; help us find some grant funding to get somebody working on this.
E) Speak up; and spread the word.
Hi everyone, my name is Gregory. I’ve worked with 2 Digital Health Startups, been through 2 Digital Health Accelerators, and worked on several Digital Health projects (mostly in UX). I co-organize Meteor Miami meetups.
I’d like to help out with growing the community and getting more businesses to adopt Clinical Meteor. I believe it has the potential of being like WordPress for Digital Health apps.
Hello,
For 2018, we’re trying to get a biweekly conference call scheduled. We’re tentatively planning Tuesday mornings Chicago time (10am). Details should be below (although I’m still figuring out how best to publish a public Hangout).