Clinical Meteor API

announce
1

So. Here’s a few little questions to think about. What if…

  • a different development direction had been taken with Meteor?
  • and that the real value in Meteor wasn’t viewed as realtime reactivity, but in the curation and integration of community packages?
  • and a router had been pulled into core?
  • roles had been pulled into core?
  • simple schema and autoforms had been pulled into core?
  • and user models were in core?
  • and all those API pull-requests that had been made over the years had been accepted?
  • and it was assumed that Blaze would stick around (or at least the Spacebars API)?
  • and a more Cathedral .Net approach had been taken, rather than the Bazaar free-for-all of NPM?
  • What would Meteor look like at this point? On a pragmatic, day-to-day basis?
  • What resources would devs go to on a daily basis to look up API definitions?

Well… it might look a little something like this:

http://clinical-docs.meteor.com

Yeah, it’s still a little rough around the edges. Entry has a lot of functions that aren’t documented yet; HipaaLogger needs to be moved to Hipaa.Logger; the SchemaHydrator probably needs to be attached to SimpleSchema, which isn’t added yet. etc. etc. etc. But those are all sort of tactical things that can and should be discussed.

The real point here, is that we managed to:

  1. get a bunch of packages that people have been asking to go into core into a release distro;
  2. we’ve got JSDoc formatted comments and documentation on the major API objects and functions;
  3. we managed to clone the JSDoc site for the Clinical Meteor release; and
  4. we have a reference version of Meteor that has all of these pieces working together.
  5. by the end of the year, we should have integration tests on all of these packages as well.

So that’s pretty exciting.

And icing on the cake is this: we’re going to add an addition 100 API objects from the HL7 Argonaut FHIR project in addition to the 16 objects we’ve just released. It may take another year to work through those 100 new objects. But if anybody want’s a roadmap of what we’re doing… well, there ya go!

Happy Holidays!

17 Likes
2

Very nice project. I like! Now, how about a HIPAA audit log backed up by blockchain snapshotting?

1 Like
3

monumental work. Look at that ha ?

1 Like
4

Well, we have the HIPPA audit log.

As for the block chain snapshotting, that’s considerably above-and-beyond what HIPAA requires. But if any community members want to piece it together, we’d be awfully curious to see an implementation.

5

Yeah, I might tackle that sometime next year…

Thanks

David Mondrus

6

Really great work on this! I will do what i can to contribute! Thanks!

1 Like
7

I recognize and appreciate your commitment to this Abigail :slight_smile:

1 Like
8

I started working on a project recently & for obvious reasons I wanted to use packages that I worked with previously. I was surprised to see how many simple things didn’t work with 1.2.1 while it worked with 1.2.0.2 . I downgraded & it started to work immediately.

I instantly appreciated Clinical-Meteor. High quality Packages in a separate release guaranteed to work together every single time. I realised the need of that on a grand scale project. In time we could decide to upgrade or not in our own time while having a build that doesn’t fail !! Awesome

10

Meteor ecosystem has got your back, courtesy of chafey’s generosity. :slight_smile: