Is there any current up-to-date Meteor/Galaxy usage stats? Number of orgs hosting on Galaxy? Millions of users? Or millions of API calls per day? GBs of DDP data transferred each day? Estimated community/user size?
The homepage has the following stats. But I’d be interested in any additional stats or estimates that people may have.
13,937
PACKAGES
226
PROFESSIONAL SERVICE PROVIDERS
28,278
STACK OVERFLOW QUESTIONS
508,000+
UNIQUE INSTALLS
Hi Abigail, how are you doing?
What questions are you trying to answer with this data? Maybe thinking about the questions, we could come up with some numbers for you.
Hi Filipe! Doing pretty great, actually. New job at a federal R&D laboratory, working with the US federal government on a number of national healthcare initiatives
So, we’re using Meteor.js on projects, right? Using it as a rapid-prototyping platform to create reference implementations (RI) and implementation guides (IG) with. The implementation guides are submitted to HL7, an ANSI accredited standards development organization (similar to W3C or IEEE) where they’re balloted and voted upon to become standards.
So, for instance, the medical healthcare community might want to say ‘hey, we’d like to standardize how home blood pressure monitors send data to hospitals and patient health records’. We’d then define a data schema (usually using Fast Healthcare Interoperability Resources, i.e. FHIR Observation in this example). Then we’d write up an implementation guide, which is basically just a tutorial in a standard format, and a reference implementation (now using Meteor.js). The healthcare community then nitpicks what should go into the tutorial, and votes on it. If it goes through the balloting process and gets approved, the IG becomes an ANSI standard. That, in turn, can be picked up by the ONC and Medicare/Medicaid and other federal organizations for use in certification process, because the government can rationalize their decision as being based on community standards. So, Medicare might say they’re only going to reimburse for blood pressure monitors that are certified to use the FHIR Observation resource specified in the Blood Pressure Implementation Guide (IG). And if any vendors object, hey, here’s a reference implementation to help you implement the standard yourself.
Unfortunately, this whole process has a tendency towards pay-to-play, and the standards have historically been skewed by first mover advantage. EMR vendors, pharmaceutical companies, state Health Information Exchanges, and others come to the table with deep pocketbooks, and sort of game the system by voting on standards first. They’ll create a process that is niche to the healthcare industry, but may not be used outside it. So, if they all vote on exchanging blood pressure data by PDF, then that is what gets standardized, because outside parties aren’t sitting at the table.
So, for the past 5 or 6 years, I’ve been trying to bring open source Node/Javascript to the HL7 table, and say “hey, Microsoft and Oracle and Epic aren’t the only ones playing in this space, and there’s this huge community of developers and startup organizations who are using Node and Javascript; and maybe look beyond the PDF, and consider what’s going on in the Javascript community as part of the standards development; because the Internet is the maybe the most ubiquitous standard in existence.”
I’m the co-chair of the HL7 Patient Empowerment workgroup, so advocating for patient access rights to their own health data; personal health records, quantified self, medical homes, etc. And trying to say “don’t just embrace Alexa as the default for medical home digital scribes, but maybe also look at these NPM speech-to-text libraries also”. That sort of thing.
Anyhow, to the immediate concern. I’m currently working on a national directory of healthcare providers. Basically a giant phonebook of doctors, nurses, hospitals, clinics, nursing homes, etc. Part of the implementation guide has a Subscription API model. I’ve been using FHIR-over-websockets via Meteor’s DDP pub/sub model for the past 5 or 6 years, but the healthcare organizations are just now looking at the problem space, and reasoning through things the same way MDG did 7 or 8 years ago. The developers new to the problem area suggest a polling architecture. Then somebody suggests there’s a lot of overhead and repeat data being sent. Then someone suggests maybe using websockets. And once that’s in place, how do you merge and deduplicate records on the other side? Oh, maybe we need a mergebox. But all of that is difficult, so maybe we should just stick to polling. And then we go around in circles.
So, anyhow… I’m in the position of working on this implementation guide and reference implementation, and I’m trying to tell them… look, you’re reinventing the wheel here. The Javascript/Node community has had this already figured out for 7 or 8 years now, and it’s in use by X number of users, and Y installs, and Z gigabytes of data. The healthcare community is actually in the minority by suggesting a a new Subscription API that uses polling, and not embracing community standards. Instead of reinventing the wheel, we should be adding DDP to the Subscription API standard, thereby strengthening both the Node (Meteor) community and the healthcare community.
It’s all a little bureaucratic and tedious. But that’s how standards get made. And having some stats on Meteor/DDP usage could really help right now. 
Never mind the ask - the back story here is sorta fascinating - thanks for sharing.
Hi @awatson1978, an interesting number we could get here is the number of times Meteor runs in a dev environment which is 200k runs/day.
If there is a specific metric you would like to see please let us know so we can try to get it.