Good to hear from you again. These are great questions, so lets get a FAQ started:
Q: Since this is a boilerplate, looks like I would fork it to use it. Correct?
Not necessarily. Meteor on FHIR is designed like Wordpress and Mirth, and supports a plugin architecture and fairly robust configuration file. The intent is that basic FHIR queries, data caching, data-relaying, and PHR functionality will be available without the need to fork the project. And we hope to have a stable enough core that people can build modules using the plugin architecture.
Generally speaking, it helps to think of Meteor on FHIR as being a combination of Wordpress and Mirth. You could certainly fork either project. But they’ve both grown to the point that most people find it perfectly serviceable to simply write a plugin and adjust the config files. We’re increasingly finding that when we consult with clients, that’s all we need to do.
Q: Is there a best practice for customizing meteor-on-fhir, to permit pulling future updates & ability to contribute future enhancements?
Going forward, the best practice will be to use a plugin. We’ve only recently implemented the plugin architecture, so there’s only four plugins so far and it’s not been documented yet. But I think it’s safe to say that should be part of the go-live documentation. I’m going to publish a reference plugin ASAP - probably be the Continuity of Care Document plugin; but I’m still debating how it’s going to get licensed.
Q: I see you use publication & subscription a lot in meteor-on-fhir. As I recall, we learned in 2015 or so, that pub-sub does not scale well. Has that issue been solved? Or is it best practice to inactivate it?
Scaling is a complicated question; and really dependent upon one’s use case. The pub-sub architecture works just fine for departmental apps, where the overall user base is anticipated to only be in the hundreds or thousands of users. In general, there’s a lot of anecdotal support that a well designed Meteor app can support 100 to 1000 users per Node instance via DDP. That being said, the FHIR standard has added stateless REST endpoints to Meteor; which can support upwards of 40,000 connections per Node instance via OAuth/REST; as long as reactivity is not required.
The default use case that Meteor on FHIR is designed for is an Accountable Care Organization, such as a Medical Home or Clinic; which supports 100 to 10,000 active users. If you imagine more users or a different usage pattern (such as a public landing page, or government sponsored service), you may need to inactivate DDP and query the FHIR endpoints using polling.
Q: When would one use the SDK vs the meteor-on-fhir?
Q: What version of FHIR standard do you support?
The short answer: We started with v1.6.0 (DSTU2), and are aiming for v3.0.1 (STU3) for the 13 Argonaut resources that are included in Meteor on FHIR by default.
Longer answer: The Argonaut Project - which is what Epic, Cerner, and Allscripts support - was originally based on DSTU2; while the latest version of the standard has moved to STU3. Our goal with the end-of-year launch is to have STU3 coverage of all the resources that are shared by Epic and Cerner. If/when we get support to take projects into the Epic App Orchard or Cerner App Store, we’ll add DSTU2 legacy support as needed (if the resource doesn’t already have it).
tl;dr Answer: I’ve got a spreadsheet tracking the versions on different packages; trying to standardize on v3.0.1, but it’s a bit of a mess.