Engineering Health

Most technical problems are like games. All of them have a way to win and all of them have rules; the easiest way to ensure you always win is to learn the rules inside and out, and more importantly what the rules don’t cover! Paying attention to what the rules don’t cover is what leads to out of the box thinking. What sets the great players apart from the rest is learning what the rules don’t cover which allows for creativity and, sometimes, shortcuts.

Cerner’s journey with Ruby started in the summer of 2009. We selected Ruby on Rails for rapid development of the Cerner Store to prepare for release at the Cerner Health Conference that year. In three months, with three engineers and a designer, we wrote and released the first version of an e-commerce web application. Two of those engineers, including me, had never worked with Ruby before but quickly realized the power and expressiveness of the language due to resources like Why’s (Poignant) Guide to Ruby.

Developers often take for granted the level of flexibility and customization that is available within the software they use every day. Consumers of imaging software have traditionally been completely confined to interpret exams a specific way, and frequently in ways that are unintuitive. Every physician, specialist, technologist, med student, and others across the continuum of care has a preference as to not only how exams are laid out, but what information is displayed with the images and what transformations would be applied or processed automatically.

Introduction Tycho is a build tool for integration between PDE and Maven. Cerner has a long history of working with Eclipse RCP but P2 integration is something of a more recent phenomenon. This post is going to talk about how Cerner is using Tycho, what prompted our transition to Tycho and how we accomplished moving our build to using Tycho. Why we use Tycho The first question when evaluating any tool is asking yourself: “why would I use that”?

From MapReduce to realtime This post covers much of the Near-Realtime Processing Over HBase talk I’m giving at ApacheCon NA 2013 in blog form. It also draws from the Hadoop, HBase, and Healthcare talk from StrataConf/Hadoop World 2012. The first significant use of Hadoop at Cerner came in building search indexes for patient charts. While creation of simple search indexes is almost commoditized, we wanted a better experience based on clinical semantics.

In the dark ages of development, great software meant packing in the functionality. People began doing more and more with their software. Updates meant newer and more exciting functionality. Sounds great, right? Of course it does, but something went horribly wrong. Slowly we became inundated with cluttered screens as software developers struggled to find a place to put their latest innovative functionality. Buttons began adding up and before we knew it, we were inventing user interface controls like ribbons to hold all the buttons.

Hello and welcome to a public face for Cerner Engineering, by Cerner Engineering associates, to talk about engineering, technology, and all of the other awesome things we do. Cerner has been recognized as a visionary company, transforming the delivery of healthcare around the world. Improving the health of individuals and the delivery of care is an extremely large, complex, ever-changing problem. Along with the efforts of our strategists and consultant organizations, solving this problem takes a ton of smart folks in our Engineering and CernerWorks Hosting organizations, who are free to play with, adopt, and embrace new technologies and ways of working.

Most developers know this pattern well: we design a set of schemas to represent our data, and then work with that data via a query language. This works great in most cases, but becomes a challenge as data sets grow to an arbitrary size and complexity. Data sets can become too large to query and update with conventional means. These challenges often arise with Hadoop, simply because Hadoop is a popular tool to tackle such data sets.