Balancing Your Informatics Gauge

I had a realization recently, in my software developer role – I’ve become a much better C# programmer because I’ve been programming in Ruby.  A lot of this is due to the Ruby developers I’ve worked with, who have taught me how to do things the “Ruby Way” and the “Rails Way”, or in some cases just the “Right Way”.  Good programmers know that they can never stop learning, and this highlighted the importance of not only learning new frameworks and libraries, but also new languages (and language cultures).

I realized the same thing applies to informatics.  I like to think that I’m a better informatician because I’ve been able to learn different informatics “cultures”.  I started my career developing EHR software, and was focused a lot on how to most efficiently collect that information to support clinical workflows.  This, of course, required me (a novice to the field of healthcare at the time) to learn about clinical workflows!  But I was able to adapt to that mindset.

When I made the transition to research, I had to learn all over again.  Researchers had not only different operational workflows, but they approached the collection and use of clinical data in a different way than the clinicians did.  Many of the researchers were also clinicians, so they understood both sides of the coin, but when they wore their researcher hat they thought about it differently.  From a development side, because of the tight deadlines that come with research grants, not to mention the dynamic nature of research in general, I had to be able to quickly adapt to changing requirements.  This was much different from planning out clinical software releases months in advance.

Overall though, what I started to find was that my clinical experience helped me understand not only how the data was collected, but some of the nuances of how it could be interpreted.  For example, knowing that a physician could import text from a previous note into their current note meant I knew these things weren’t being explicitly typed out each time (and so might need some consideration for what it means).  Having worn the clinical developer hat made me much more effective to wear my research developer hat.

Most recently, I have started to shift my focus more to the clinical side once again.  What was most interesting for me was the wake-up call on how much my clinical developer persona had atrophied.  Sure, I still remembered a lot of general ideas, but I also realized I approached clinical development in a slightly biased research way.  I kept thinking “how can I collect all of this data”, instead of focusing on the appropriate balance of usability and data utility within the clinical workflow.  Likewise, I was so used to the more rapid development cycles in research that I neglected to account for existing and future project plans when working with other clinical developers.  In short, even though I had been a clinical developer I really had forgotten a lot of what that meant.

If you think of a needle gauge between “clinical” and “research”, my needle is leaning away from the research side and more to the balance of clinical and research.  Invariably, this is going to be an ongoing process – if I focus solely on clinical development, I’m sure my gauge will lean towards the “clinical” side of things again.  What I’m finding is that it’s critical to stay active in both domains.

I realize that not everyone has had the opportunities that I have to be able to switch domains like this, but that doesn’t mean there aren’t things we can do.  Of course, keeping up on our journals is a good start (and be sure you read the occasional article that at first glance doesn’t seem like it applies to you), but that only provides a small slice of what’s going on at your institution.  Instead, if you work in research, actively seek out colleagues in the clinical side (and vice-versa) and try to meet with them on a regular basis (maybe a monthly lunch) just to talk shop and keep informed of what they are doing.  The best part of this informal approach too, is you usually end up hearing the good, the bad and the ugly of these projects.

If you get the opportunity to work on a project that involves both research and clinical folks, so much the better.  At my institution, both teams use a daily scrum, and I make it a point to get to both on at least some occasion so both sides hear about the projects I’m working on.  I’ll mention everything too, not just the projects that may be specifically relevant to them.  I’ve had more than a few after-scrum discussions explaining my projects in greater depth to people who were interested.

The important think to take away here is that informatics and software development follow a similar maxim – “stagnate and die”.  We need people to specialize, but also remember we need people who know both sides.  So regardless of where your gauge may point, trying to make it lean a little less to one side or the other will be a huge benefit for you, your organization, and the informatics community.