Nice.
Items in pink are live and support Meteor 1.0. Items in gray are pre-1.0 and in development. Items in lightgray are in planning stages.
What are the items in green?
Oops. New color scheme. Green are published items. The old color scheme was inspired by nursing scrubs, and was using a dusty pink. Thanks for catching that typo!
Cool, I’m working on a mental health app; was looking at the clinical:hipaa-audit-log package and plan to use it to get us closer to Canada Health approval
What will happen with the pre-Meteor1.0 projects?
Hi!
We’re in the process of converting all the pre-Meteor 1.0 projects to 1.0. It turned out that there was a lot of overlapping functionality in all the early demos… accounts, users, graphing, dashboards, etc. The broader Meteor community has addressed most all of those issues, but we wanted to revisit those components with a testing framework and make sure everything was properly QA tested. So, now that we have a testing framework in place that we’re comfortable with, we’re going through the venn diagram of shared components and converting them to packages. Each of the pre-Meteor1.0 projects is going to get updated with Clinical Meteor packages, which will decrease the overall amount of code in each project.
5 Likes
Hi all,
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:
HIPAA Core
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.
Cornerstone Viewer
DICOM image viewer for radiology, cardiology, pathology, and clinical laboratory applications.
HL7 Argonaut FHIR
HL7 and OAuth infrastructure for health information exchange and interoperability.
Clinical Trials
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.
Card/Glass UI
A card based UI framework, inspired by the Day Made of Glass videos.
2 Likes
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.
6 Likes
@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.
Hi @kaiyes,
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
- Teleradiology
- 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.
3 Likes
Excited to announce that Clinical Meteor Track now has an API documentation page.
http://clinical-docs.meteor.com/
There’s a thread opened for feedback and discussion as well:
Clinical Meteor API Discussion Thread
3 Likes
Clinical Meteor has an updated homepage:
https://clinical.meteor.com/
- 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!
5 Likes
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?
Hi kimmohintikka,
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.
1 Like
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.
I’ve been loath to incorporate ontologies into the project because of licensing issues; but it needs to be done. So maybe ICD10 and SNOMED this year. Hopefully my profs will be able to point me to JavaScript implementations.
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.
2 Likes
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, …)
- authentication,
- menus,
- 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?
Thanks!
1 Like
Hi David,
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?
The SDK is there to address the broader question of tracking healthcare apps that are written in Javascript (now Ecmascript). It’s sort of a junkyard of prototypes. Meteor on FHIR on the other hand, is about integrating as many of these technologies into a coherent whole (with industry standard data models). And Clinical Meteor is an in-between step that takes the junkyard prototypes, and brings them under Q.A.
As such, expect the SDK to have javascript projects that aren’t based on Meteor. There might be a SNOMED server based on an Express app; or a Ruby app with an important database of medications stored in JSON format. It’s much more of a wild-west of healthcare prototypes. Meteor on FHIR is where we’ve been piling everything once it’s gone through the SDK junkyard, through the QA process of the clinical track, and then refactored to use standard data models.
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.
2 Likes
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
2 Likes
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.