Clinical Track - RC6

New version of clinical:METEOR just published.

meteor --release clinical:METEOR@1.1.3-rc6

Release Notes

Reference Implementation
California Kids Cancer Comparison

Pending On Roadmap

  • clinical:active-layout
  • clinical:mobile
  • clinical:offline
  • architectural documentation
  • generator support
  • healthlog reference implementation
  • active entry tests
  • autoform tests

Release Manifest


Really interesting to see what kind of things you build with Meteor, exceptional!

Also your test procedures look very good, seems like a very solid solution.

Are you sure all run? Followed your link in the post.

Running:  A. Signing In UserA
result.value { message: 'Timed out waiting for async script result after 5007ms\nBuild info: version: \'2.45.0\', revision: \'5017cb8\', time: \'2015-02-26 23:59:50\'\nSystem info: host: \'\', ip: \'\', \'Linux\', os.arch: \'amd64\', os.version: \'3.13.0-40-generic\', java.version: \'1.7.0_76\'\nDriver info: driver.version: unknown',
  suppressed: [],
  localizedMessage: 'Timed out waiting for async script result after 5007ms\nBuild info: version: \'2.45.0\', revision: \'5017cb8\', time: \'2015-02-26 23:59:50\'\nSystem info: host: \'\', ip: \'\', \'Linux\', os.arch: \'amd64\', os.version: \'3.13.0-40-generic\', java.version: \'1.7.0_76\'\nDriver info: driver.version: unknown',
   { releaseLabel: '2.45.0',
     buildTime: '2015-02-26 23:59:50',
     class: 'org.openqa.selenium.internal.BuildInfo',
     buildRevision: '5017cb8',
     hCode: 187048467 },
  cause: null,
  systemInformation: 'System info: host: \'\', ip: \'\', \'Linux\', os.arch: \'amd64\', os.version: \'3.13.0-40-generic\', java.version: \'1.7.0_76\'',
  supportUrl: null,
  class: 'org.openqa.selenium.TimeoutException',
  additionalInformation: '\nDriver info: driver.version: unknown',
  hCode: 223997494 }
✔ Passed [ok]: { message: 'Timed out waiting for async script result after 5007ms\nBuild info: version: \'2.45.0\', revision: \'5017cb8\', time: \'2015-02-26 23:59:50\'\nSystem info: host: \'\', ip: \'\', \'Linux\', os.arch: \'amd64\', os.version: \'3.13.0-40-generic\', java.version: \'1.7.0_76\'\nDriver info: driver.version: unknown',

Great news!

As an aside, several links do not render on the starrynight-website:

  • Scaffolding
  • Examples
  • FAQ
  • About

Edit: it seems to be that I had scrolled down on one ‘page’ before clicking on a shorter ‘page’. I.e. the content of the shorter page renders, but the user needs to scroll up to see it.

Also, there is some strange behaviour on the Clinical Meteor Track website. Under the Demo Applications section, the Github and Live Demo buttons in each section do not work when the page first renders. There seems to be an overlay image blocking user interaction.

Thank you much for the feedback!

I’m not 100% sure how Travis caches results; but I think there’s a chance it tried to rerun the tests when you looked at them, and timed out. Travis uses ultra tiny instances (192mb, if that), and it’s easy to overload them. The tests were green during merge, which is the important part. :wink:

And thank you much for the feedback on the StarryNight and Clinical Track sites. We’re preparing for an overhaul and upgrade soon, now that we’ve got a ton more packages published. Seems like it’s about time to take care of that scrolling issue and the overlay image. Will probably be next week before they get fixed, but hopefully before Thanksgiving.

Agree it’s a memory issue, those damn bits switching by itself sometimes :wink:

All looks really interesting what you are doing. It seems a bit invisible for outsiders what exactly you are doing and with how many people.

Yeah, we’re working on addressing that invisibility. It’s largely due to a pile of non-disclosure agreements, liability concerns, backchannel agreements, and non-technical stakeholders.

Long story short… there’s lots of people who are using Meteor for healthcare related projects; but mostly in established small-businesses rather than startups. So many projects, in fact, that I’m making a living salary as a package maintainer and am funded to a) make these packages public, open-source, and audited to work together, and b) be something of an industry representative.

I’ve recently taken UCSC as a client, which has helped streamline the process, and we’re working on getting a bunch of stuff published and out of the backchannels and into the public domain as a coherent product. (The D3 data pipelines are a great example.)

As for the ‘with how many people’, there’s at least 50 or 60 people throughout the Meteor community who are involved with healthcare apps that I know about, and from whom I collect use cases and requirements; maybe a half-dozen angel/VC startup projects I’ve consulted on; and probably two dozen developers from past projects who I consider to be on retainer; 6 people currently on my immediate team at UCSC; another 3 or 4 working groups at UCSC Dept of Engineering using Meteor; etc, etc. (The Meteor community is much larger than just the people who show up for DevShop and who frequent these forums.)

If MDG has been careful about positioning Meteor as a platform, then you might say that we’re publishing a Meteor-specific framework for writing healthcare apps.


@awatson1978 where is the DICOM module ?

DICOM package available on Atmosphere…

And an example app with Cornerstone loaded up…

Awesome work that the Cornerstone guys are doing over there…

1 Like

Upon seeing all that talk in the new Blaze thread by geoff, I am wondering what is going to happen to the view layer of this massive clinical track since MDG is slowly but surely pushing things towards React ? Of course we could use ’Inferno’ ( I have a feeling this name is gonna stick) and be happy with the plethora of present autoform like packages that will work with it out of the box.

Current Clinical packages have been battle tested and HIPAA compliant, choosing React means re-do all the work, including reinventing tons of already-blaze-compatible essential packages like autoform, let alone testing. Honestly, I feel a bit frustrated just thinking about using React.

But again, using React does promise a rock solid future position albeit the temptation of going deep into the functional rabbit hole.

I would want to know your view @awatson1978, is it the same as this ?

We want Blaze in containment. As far as I'm concerned, React integration is only half-implemented, and still lacking a Spacebars API. I'll be happy to migrate Clinical Meteor to React once its in containment. Until then, other people can be responsible for dealing with breaking builds on the bleeding edge. I'm concentrating on bringing things into production, thanks.

Or maybe upon seeing the new thread, Inferno will be the way forward ?

Yup. Clinical Meteor will be using Sideburns/BlazeReact/Inferno, or whatever it eventually gets called. We’ve been very much focusing on publishing things as packages with minimal styling and writing acceptance/validation tests (which can be walked across technologies) with this migration in mind.

In fact, the main reason we’re releasing these reference apps in the first place is so we can baseline them and do controlled refactors and manage upgrades like this. So this is all going pretty well. We’re happy with where things are heading.

Also, we’re about ready to announce inclusion of clinical:autoforms. Like iron:router, there’s the occasional patch we need to make, but mostly we want to cut some cruft out of the library, streamline it a bit, and keep the good parts.

1 Like