Super cool! Keep up all your great work @awatson1978
We just announced the HL7 Argonaut FHIR subproject in another thread, and as we were deciding it was a good idea to announce a new subproject, it occurred to me that it would maybe be a good time to clarify the existing subprojects:
Multiactor pattern with secure data transmission, data storage, audit logging, and a collection of business policies for your organization.
StarryNight FDA Regulatory Tool
Validation and verification testing of Meteor apps, as per FDA Title 21.
DICOM image viewer for radiology, cardiology, pathology, and clinical laboratory applications.
HL7 Argonaut FHIR
HL7 and OAuth infrastructure for health information exchange and interoperability.
Form builder with integrated autoforms, designed for collecting clinical trials data.
Clinical Data Visualizations
Data analytic pipelines with map/reduce, aggregation, live query, data fusion, and D3 Visualizations.
A card based UI framework, inspired by the Day Made of Glass videos.
I just had someone ask me the following question in an private thread:
Q: How can a beginning developer who knows little but can learn quickly get involved with the clinical meteor projects? One thing I was thinking about was taking a look at some intermediate or difficult projects in relation to the clinical track and learning from them. Anything come to mind?
It was such a great question, that I had to sit down and give it a detailed response. I’ll be cross posting this on the Clinical Meteor Homepage in FAQ during the next big update. Until then, here’s a draft version of ‘How To Get Involved’…
First off, introduce yourself on the Clinical/Healthcare Working Group thread, and post something about your general interests. There’s a half-dozen companies and a couple dozen programmers in the community who are involved; so introduce yourself.
Second, if you’re new to programming for healthcare, clinical, or medical environments, read the FDA’s General Principles of Software Validation; Final Guidance for Industry and FDA Staff, and also read through the HIPAA Policies and Procedures that are listed on the Hipaa Policy Generator site. These are the day-to-day guidelines, policies, and procedures that programmers in the healthcare/medical industry have to deal with.
Third, check out the Clinical Meteor homepage and roadmap, which lists which packages are live, and has a half-dozen demo apps. Feel free to download and tinker. For the most part, the demo apps haven’t been refactored to use the clinical track packages yet; which is what we’re currently working on. We have more reference apps on the way, such as the Medical Illustration Library, and will be expanding this homepage. If you have a reference app, please feel free to contact us about getting it listed!
We have some tutorial walkthroughs for getting started with our FDA testing application. Some of them are advanced walkthroughs, such as the package refactoring tutorial. which is a wonderful skill to be able to contribute to projects.
You can find all of the Clinical Track packages by searching on Atmosphere. The counts for most of the packages are mostly still at/near zero, but don’t read too much into that. A lot of these are getting migrated/renamed from other namespaces, and we’ve only recently started publishing them for public use.
The new Clinical:Hipaa package is almost ready for general use. We’re still putting together some screenshots of the audit log, and rounding out the API, but it’s the new resource for all-things-hipaa. The Hipaa Policy Generator was built using the StarryNight FDA tool and Clinical Hipaa package, and represents where we’re headed with the Card UI.
For data analytic pipelines, you can check out the graphs-dailystats package.
And also take a look at the Clinical Trials application, which we’re currently upgrading with SimpleSchemas and Autoforms. Many groups have expressed interest in it, and we’re getting ready to do another big sprint on it this autumn.
As for specific things to help with…
- Build apps using the Clinical:Hipaa package and/or the StarryNight utility.
- Help us build more data pipelines with D3 graphs. Take a barchart or sinewave or voronoi diagraph, and follow the graphs-dailystats pattern, but make the chart realtime (so it can eventually be used for an ECG monitor or cellular division/cancer model).
- Review the HL7 Argonaut FHIR project homepage, introduce yourself on the HL7 FHIR thread, and help us write an OAuth2 server, and do HL7 testing sprints this autumn.
- The intent is that all of
clinicalpackages are being audited to work together. So, in theory, you should be able to build coherent apps with them. We’re currently working on documentation and making sure they’re production ready. Feel free to build with them, submit bug reports, and help improve their documentation and/or APIs.
We have more examples with regards to Radiology, DICOM, the Cornerstone Image Viewer, User Pick-Lists, ICD10 picklists, and various other components on their way. We’ll update this Getting Started page with those items later this autumn.
@awatson1978 Could you please explain which healthcare software we are including? I guess it will give us a top view of what we are after.
I see we have clinical: barCode package. Is that meant to be used as the ‘Barcode’ medication administration?
Dave was talking about Personal Health Records so we know that can be covered.
I have heard about Electronic Health Records from you, so is that a possibility?
DICOM has been mentioned. So image processing??
So how many of these are we trying to cover ? Should we divide team and concentrate on covering each category ? Each team can contribute to the specific section that designated to so that others won’t have to repeat the same process twice. For example, anyone could fork Dave’s Personal Health Records (lets say Dave represent the PHR section & I EHR section) and modify it, they will not have to do it from scratch. In this way we can probably come up with a ‘Total solution’ combining everyone’s project altogether. Hospitals are inclined towards a company that sells total solution. Isn’t it?
I ask because it is possible for me to hire a meteor developers locally to form a team, should need arises. Also I will be able to offer way cheaper prices than the competition, Guaranteed. On the way to do that, my team can contribute to the specific section that designated to us so that others won’t have to repeat the same process twice.
One of the things I was surprised by when working with the big EMR systems is how they were actually suites of applications. Cerner had nearly 500 total apps; of which our hospital used only about 100 of them. And each module or applet was roughly associated with one job description in the hospital.
So, I’ve been very much programming Clinical Meteor with the assumption that hundreds of different apps, departments, and business will use it; and have been using a sort of venn-diagram, and focusing on the parts that would be common to any of those application categories… login, user accounts, barcodes, medical icons, HL7 interfaces, workflow management, work queues (checklists), ICD10 integration, DICOM image integration, etc.
To date, I’ve worked with clients doing
- Clinical Trials
- Paratransit Fleet Management
- Robotic Pharmacy Dispensary
- Cancer Genomics Research
- IVF Donor Matching
- Telemedicine Video Conferencing
- Multiple Sclerosis Health Planning
- FitBit Biometrics
- Social Health Records
- Health Marketplace
So, I’d suggest that it’s really a matter of finding sponsors for specific categories. Each one of these examples needed a clinical champion who was/is willing to make the case for it’s use in a clinical setting. That’s going to be the limiting factor.
Maybe a build-it-and-they-will-come approach will work. But I’m hedging towards a model which involves finding clinical champions and existing teams to underwrite the work. The reason that Social Health Record, Checklist Manifest, and Clinical Trials are being used as the demo apps, is because I’ve had multiple independent groups approach me about each of those particular topics.
There’s actually been 4 independent attempts at making a “Facebook for health records”. Interestingly, they’ve each gone about it in completely different ways. So, since that’s where the clinical champions are, I’ve been looking at the venn diagram, and which elements are common to each. Which brings us back to the logins, user accounts, hl7 integration, etc.
As for ‘total solutions’, I’m seeing the Radiology sector getting close to having a complete RIS/PACS solution. There are three different groups involved; so they will need to find common consensus and/or somebody will need to buy the others out. But that’s three different teams, in just one subsegment. Plenty of room for lots of people to participate.
Cerner spent nearly $2 billion in research and development for Cerner Millennium EMR. As much as I think the volume of work is there, it’s difficult to plan for a total solution at this point. I think people simply need to find clients who are willing to work with the technology, find the clinical champions, and then bring solutions to market. Once we get a few established players in production; it will be easier to look at building total solutions.
Excited to announce that Clinical Meteor Track now has an API documentation page.
There’s a thread opened for feedback and discussion as well:
Clinical Meteor API Discussion Thread
Clinical Meteor has an updated homepage:
- We’re dogfooding the track, using it for the homepage.
- Synced with Atmosphere, and will have up-to-date info on release track versions going forward.
- Now hosting a collection of whitepapers for the track.
- Much more presentation-friendly for point-of-sales meetings.
Feedback encouraged and appreciated!
I admin that I am not specialist in compliance questions but I have recently engaged on project where FDA approval might be needed not now but in future.
Now a personal health app that has a plans in future to upload data to EHR systems to assist practitioner. Legal views this as it becoming medical device.
I looked at clinical track and I am mostly good with it and the packages it has, however it is a bit lacking in frontend tooling.
How bit of hassle I am getting myself into if I try to use sass , js and html from the existing consumer app. Components are just view without any processing logic or session info do I still need to do the kind of extensive testing against the components?
That’s a really great question. And to be honest, it pushes what I myself know about the process.
The FDA cares that you have a QA process that has multiple testing procedures (to avoid systemic biases); but it doesn’t so much care what those testing procedures are. As long as they judge it to be a sincere and comprehensive effort.
So, components. They might squeak by a review without QA testing results. Just as the web browser itself might. Or the delivery truck might get passed during an inspection of a dairy milking farm. But given the day and mood of the inspector, they could just as easily be flagged.
For my own projects, I’m assuming that they’ll need to be tested. Which is why I’ve been building up many of the components up from scratch; and why the defaults are very minimalist, without the latest Material UI or Polymer or other component libraries. Industrial infrastructure, if you will.
If you want to layer on Material, Polymer, Bootstrap, or other component libraries, it shouldn’t be too much of a problem. The ClinicalMeteor packages all use
less by default, and their CSS rules are scoped to the local components. So, there shouldn’t be much runover; and I’ve been removing any styling left in the global scope as I run across it. The ActiveEntry package, for example, used to have a number of styles in the global scope that was causing problems. But with the QA process, we’ve managed to identify and move them to a locally scoped area. SASS and LESS can run together just fine. So… should be good to go.
You say that the frontend tooling is lacking. Have you been experimenting with the hotkeys on the main clinical.meteor.com site or the any of the demo apps? Resizing the applications and checking the breakpoint behavior? ClinicalMeteor is being built out with inline style helpers, so it’s peppered with animations throughout. It has a minimalist, low-information-density design by default; because it supports animations and cinematic storyboarding between views. My hunch is that you’re not experimenting with the latest animation work, which is why the frontend tooling seems minimal.
But yeah… there’s both a fullscreen mode in the ActiveLayout package (which will soon be renamed to UniversalLayout), or you can just use the SimpleLayout package. Both should get you a pretty typical ‘default’ webpage, that you can add Bootstrap, Polymer, Material, etc to.
So whats the status of this project ? And I was wondering what is the end goal here? To make a new EHR ? Or an EHR making platform. @awatson1978
Hi! Status is that the project is doing great!
We have somewhere between 3 and 6 months of sales pipeline, so it’s become self-financing; and based on its merits, I was able to get into graduate school in a Masters of Biomedical Informatics program. There’s an associated Entrepreneurship and Innovation class that I’m eligible to sign up for, so the project has effectively been accepted into an accelerator program associated with the University of Chicago Hospital.
As for the recent changes… we’ve deprecated the Cookbook, which had become something of a code junkyard, and migrated most of the general Meteor recipes to StackOverflow Documentation. We then renamed the Cookbook as the Clinical Meteor SDK, and will be using it to link to examples and utilities.
The HL7 FHIR project has been an awesome addition, and given us a clear API to implement; and we’re participating in connectathon so trying to bring the FHIR API up to the latest release (DTSU3). Just the past month, we got schema extensions working, so people can use the base resource provided by the clinical track, and define custom application extensions, as per the FHIR spec.
I’ve been contemplating whether to make Blaze/React the officially supported rendering layers, peg them to DTSU2 and DTSU3 respectively, and just ditch Angular. It would make the whole project much more coherent from a support and migration perspective. So that may be in the works. More importantly, we’ve established a pattern for creating React components for the HL7 FHIR resources, and will be extracting a UI framework from the Meteor on FHIR demo.
Some people may have noticed that Tensorflow wound up on the project roadmap. We’re definitely moving beyond core infrastructure, and moving into much more exciting topics, such as integrating machine learning libraries and radiology viewers. I’ll probably also be bringing genetic algorithms and evolution programs into the framework later this winter as part of my Genomics electives.
Apollo is probably going to be integrated this autumn, as part of my Big Data elective. I’d like to put together an implementation that connects to Mongo, Hadoop, Cassandra, RedShift, etc. We’ll see. I’m not convinced whether that would be architecturally coherent, or just appealing to people chasing buzzwords.
There’s probably other stuff that’s going on that I’m forgetting. We presented at the United Nations at OpenCamp. That was sort of neat. It looks like we’re following the general approach of Mantra and NPM based applications; but with caveats. StarryNight will soon be pulled into the updated homepage. We’re preparing for a migration to NPM. Etc. etc.
To answer the last question… the SDK is definitely becoming a framework for writing an EMR… the core libraries of which are Meteor on FHIR and Photonic. The examples will hopefully include sample PHR and EHR apps. However, for the final EMR build, I may set up a separate repository. As much as I like the branding and reputation that stars provide, we may want a clean github history for that final production-ready build that gets sent to the FDA and gets submitted for HITECH Meaningful Use and other regulatory review. That will probably happen next summer, as part of the accelerator.
Awesome ! Good to hear !
I was delighted to discover (after a hiatus due to employment change) that @awatson1978 has pressed forward. Nice!
Check out this project, which is a boilerplate full stack clinical application.
I have cloned this and run it - looks awesome!
It offers a long list of features out of the box, that will let me build a clinical app/prototype:
- schema for many FHIR resources (so we can create and store patients, medications, …)
- back end (Mongo),
- path to HIPAA & security
- theming (Material),
- templating (React),
- routing, navigation
- standard look & feel & widgets for creating tables, lists, forms
- dev environment w/ testing
- video conferencing
I hope to use this as a starting point for a current project.
Question - since this is a boilerplate, looks like I would fork it to use it. Correct?
Is there a best practice for customizing meteor-on-fhir, to permit pulling future updates & ability to contribute future enhancements?
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?
You also offer a new SDK
When would one use the SDK vs the meteor-on-fhir?
What version of FHIR standard do you support?
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.
Good news - Meteor Now Scales!!!
Whatever scaling issues Meteor has with its pub/sub architecture has been resolved by an excellent package Redis-Oplog released by experience community member @diaconutheodor. You can also consider using Grapher also from @diaconutheodor
I tell you what, the Redis-Oplog package is a welcome addition; and likely to make it into the project. It requires the Redis binaries and a Redis server though, correct? Or does it deploy it’s own?
I ask because I’ve been experimenting with a Docker Meteor on FHIR deployment. I’m thinking of adding a Redis server to the
docker-compose.yml file, and then adding Redis-Oplog to the deployment script. I knew that we had
slava's older Redis libraries available as fallback; and I had basically planned to use whatever was the Redis best practice since then. The only think I’m held up on is that I need to figure out the development story, of where it fits in the build/deployment pipeline and how it gets used in local development if the Redis binaries haven’t been installed or running on the local machine.
@awatson1978 thank you for your thoughtful reply!
Wow a plugin architecture are you kidding? That is awesome.
Could you tell me what are the 4 plugins you have built in meteor-on-fhir? Just a little direction would be helpful so I could find the plugins in the codebase and see what you did. Also, which config file is the one that we could customize?
What kinds of things could we add onto the system with a plugin? pages, menu elements?
What kinds of things can we change with change in the config file?
Ooof. Totally legit questions, which I don’t have complete answers for yet. I published a super basic plugin last night, so lets do what we can.
Q: Wow a plugin architecture are you kidding? That is awesome.
Nope, took a while to figure out. Thank you.
Could you tell me what are the 4 plugins you have built in meteor-on-fhir?
plugin-default-landing-page #core symptomatic-videoconferencing #core; incomplete symptomatic-continuity-of-care #core; incomplete symptomatic-landing-page #proprietary symptomatic-neo4j-routing #proprietary uhs-calculator #proprietary; client; incomplete
As you can see, we’re only just now beginning to refactor things into plugins. And we haven’t figured out naming conventions, namespaces, etc. But it does support public/private repositories, and provides a way for people to ‘own’ their workflow while using and supporting a common data layer.
Q: Just a little direction would be helpful so I could find the plugins in the codebase and see what you did.
Pull from the latest
development branch, and look at meteor-on-fhir/webapp/packages/plugin-default-landing-page
Q: What kinds of things could we add onto the system with a plugin?
We’re still in the very early stages of the plugin pattern, so I’ve only got page routes set up so far. But menu elements, action buttons, and more will be coming within the next quarter. If I get funding and support, I’d be happy to roll those features out sooner. And I’ll be happy to accept pull requests.
Regardless, here are the relevant files to that compose the plugin pattern:
With those 3 files, a package can expose React components and routes into the app dynamically.
Q: Pages, menu elements?
Yeah, the idea is that we’ll be using that Package scanning approach, and exposing more components via packages. The plan is to support the following arrays:
Q: Also, which config file is the one that we could customize?
Look in the webapp/configs/settings.dev.json is a good place to start.
Q: What kinds of things can we change with change in the config file?
defaultVideo will override the
backgroundImagePath. Generally speaking I’ll always accept pull requests that expand support for
darkroomTextEnabled. There’s a minimally used
palette field also.
Displays sections on the landing page.
Deprecated in favor of
Shows avatars in Patient and Practitioner menus.
Displays mongo _ids as 3 of 9 barcodes in tables.
Experimental hexgrid gamification menu.
Displays the orbital by default. Will eventually be used to display NFC device proximity.
Displays alerts and notifications in the navbar.
Display the searchbar by default. Sometimes used during mobile app layouts.
Display the header and footer navars by default.
Disable the header navbar. Rarely used.
Disable the footer navbar. Useful for scrolling mobile apps, landing webpages, etc.
Inverts the cards for darkroom usage (i.e. radiology apps).
Enabled the slide-in context frame.
Set the default context URL. Popular entries include Wikipedia, Darmouth Health Atlas, and Zygote Avatar.
How many rows should be showed in tables by default.
How many records should be prefetched to the client by default. Important. Adjust this based on your target audience devices. I.e. set lower on mobile devices and laptops; set higher for workstations).
Set the default card opacity level.
The default outbound interface endpoint. Generally the upstream EHR and default FHIR datawarehouse that Meteor on FHIR will be querying from.
The upstream node that a node should sync with. Right now, only supports syncing Organizations. We plan synchronizing default Medicare/Medicaid data through the mesh network; and will eventually be supporting IPFS.
Right now, set to once daily I think.
Enables the data management page.
Enables the Query Epic buttons on some FHIR resources.
Everything under the modules selection will turn on/off a card and subsequent route in the system. Eventually, this will be hooked into the plugin system. But for now, it’s sort of hardcoded. The items in
fhir are much more active than the
modules directory, which is getting a bit stale. Some of these are effectively deprecated.
Turns on/off the app cards in the main index.
Turns on/off the FHIR cards in the main index. Will also enable/disable FHIR REST endpoints.
Default invite code for enrolling a practitioner.
Default invite code for enrolling an admin.
Disables security for testing REST endpoints. Do not use in production.
Clears the database every 24 hours.
Also, a bit on project governance and how this config file came to exist.
As a general rule, I don’t prefer to delete or remove functionality that has been implemented. I’ve spent a lot of time consulting with physicians, nurses, social workers, and other specialists to come up with the features that are in Meter on FHIR and Symptomatic. What’s in the project is not in there by accident.
I’ve had some very bad experiences in the past with teams in startup accelerators who have asked me to consult on their project, and then have proceeded to rip out large chunks of Meteor on FHIR and asked me to rewrite their custom workflow as work-for-hire. That’s a good way to burn bridges with me.
Rather, it’s far better to ask how to isolate functionality and add a toggle in the config file to enable/disable the feature. This approach respects that other people may have interest in retaining that feature, it respects past contributions to the project, it preserves functionality in case we need to re-enable it, it helps move the entire system towards A/B market testing, and it doesn’t break existing validation/verification tests.
This is not exactly on topic, but this looks like an opportunity to mention my new product.
Clinical Summary Table Validation, runs on Meteor.