@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:
Can Meteor in its current stage or with little bit of tweaking deliver the clinical apps we are going to make? That includes Now and in the foreseeable future.
What is the cost-benefit ratio of adopting any new tech into our stack?
The new tech in question must have benefits that can’t be had with our present tech. Any work around/hack is almost as complex as learning the new tech.
Implementing any new tech in our stack should not create something we already have/don’t need. Example : Is Flux useful for us ?
The tech in question must be well supported by developers and easy to hire devs that know the tech.
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. 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.
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).
. Most apps in our industry is made with something else and way old and it still runs. So we do not 