The pMD Blog

Welcome to the
pMD Blog...

where we cover interesting and relevant news, insights, events, and more related to the health care industry and pMD. Most importantly, this blog is a fun, engaging way to learn about developments in an ever-changing field that is heavily influenced by technology.

POSTS BY TAG | Developer

When I was asked to man the pMD booth at the ACC/Medaxiom Cardiology Conference in Orlando last week, my immediate reaction was "COOL!" followed by a sense of confusion. I'm a programmer, not a sales guy. Shouldn't someone from the sales team do this instead of me? What was I going to get out of this exactly? I eventually would come to learn the real benefits of having a developer at a conference - especially for myself.

Working with our customers every day, I’m exposed to groups who are already using pMD charge capture or are in the process of implementing our solution. During this conference though, speaking with potential customers was definitely eye opening.

At the booth, many doctors and practice managers came to talk to us. Some knew about our product and wanted to learn more, while others wanted to know "How DOES pMD make doctors happy?" And some just wanted some handmade candy that we were giving out. It was fun to speak with people who have a real need for our solution. As one doctor spoke to me about his paper charges, I could just see the frustration in his face as he discussed his day to day process. Another doctor brought up his grievances with his current electronic mobile solution. Reliability, or lack there of, was killing him. As I spoke with each new potential customer, I started to empathize more about their plight. They went to school to be a doctor, to help the sick, not to figure out how to bookkeep their activity. Seeing that pain versus just hearing about it was a big difference for me.

As a programmer, it's important to see and hear about how the work I'm doing is actually being used. Working at a defense contractor in the past, I can tell you first hand how dull and painful it is to wait a year to see your work finally do what it was intended to do. At the conference, we had a few of our own customers in attendance. When they came up to us, I had never met them before, but they were so open and willing to speak to the folks around us about how happy they were to use our product. It gave me that sense of accomplishment that I otherwise would not have gotten from behind my desk.

Speaking about the technical aspects of our application, interfaces, and overall utility I seemed to get an extra nod from those around me. My sales partner, Ryan, was more than equipped to speak about our software, but folks seemed to find an extra bit of worth in my words simply because I introduced myself as a developer. After the conference, Ryan expressed his joy at directing the technical questions to me. People just seemed to trust the technical answers from the technical person.

It was a great experience and I'm glad I did it. It was fun! As a developer, you work hard behind the scenes and it's difficult at times to remember the real life struggles that your product aims to solve. It’s reinforcement from all these doctors, directors, and nurses telling me about the pains of their existing system - paper, emails, and most interestingly to me, non-reliable software. I'm able to take this experience back with me with a rejuvenated sense of focus. I recommend to any developers out there to take a trip out to a conference. Not just to get out from behind your desk, but to meet the users that would or could benefit from your products. My sole regret from this trip was not being able to go to Disney World when I was only steps away!
In high school, I wrote my programs first on paper before typing them out. It was a habit that came from writing all of my english essays in a notebook. Whether the topic was Shakespeare or Binary Search, paper and pencil somehow helped me organize my thoughts better than a text editor. Over the years, my instincts on when to step away from the computer have continually evolved, but I’ve continued to wonder why different mediums had such a big impact on my thinking.

These days I still use paper to initially sketch out my code when I can’t just Google for a solution. The result is usually some flowchart, pseudocode, and more importantly, a clearer understanding of the problem. The paper makes the problem feel more tangible and concrete, a physical entity that can be held and inspected.

If the problem’s big enough, I don’t quite start typing away at my keyboard right after the paper and pencil phase. In college, I discovered that the visual size of my writing had an ability to get me unstuck somehow. Math proofs that felt insurmountable in my trusty notebook seemed to get a second chance on a large whiteboard. It still puzzles me why the size of the writing makes such a difference. I’d like to think it’s the act of making ideas human-size that helps me see them from a new perspective, and increases the chance of serendipity and insight as you walk past it throughout the day.

There are times however, when I forgo all of the above. Sometimes speed, legibility (I have terrible handwriting), and the ability to cut and paste text quickly is the best choice. In these situations, my text editor excels. The choice of what medium to use isn’t always clear cut. Sometimes I find myself internally debating the pros and cons of going to my notebook, whiteboard, or editor first. Other times, if I take shortcuts and skip the natural progression dictated by a problem, I usually regret it.

A growing volume has been written about “slow programming” and hammock driven development, and I think the common theme is that picking the right medium and slowing down your process (not your thinking) has significant benefits. Bret Victor recently gave an illuminating summary of his recent work in a talk titled “The Humane Representation of Thought.” In it, he attacks the shackles of static representations of thoughts and communication as great inhibitors of our full potential. We are seeing glimmers of this approach with Chris Granger’s Light Table and most prominently Apple’s Swift language with its Playground. How far these ideas can go and provide alternatives to notepads and whiteboards is an open, and exciting question.

At pMD, we’re building out big new functionality in secure messaging, coordination of care, health information exchanges, and charge capture, and we’re facing a lot of interesting engineering challenges. Using the right medium to think about and discuss problems is more important than ever.

Sometimes it’s good to go back to your roots. When slinging code and pounding the pavement in the world of private industry, it’s easy to feel distanced from the thoughtfulness, idealism, and teaching of academe. Yet these qualities are essential to success in any industry. And students benefit from the dialogue as well as they prepare for the world beyond the university’s boundaries.

I graduated from Brown University in 2004, which makes me ancient in the eyes of college students. But my visits to Brown on behalf of pMD, a company that makes mobile charge capture software for doctors, have been rejuvenating. Over the past few years I’ve given technical talks, helped students polish their resumes, and reconnected with some of the faculty members whom I admired most.

Each visit, I’ve been inspired by the insights and diverse perspectives of the students. They haven’t shied away from asking tough questions during my talks - or from putting themselves out there. When I asked a large audience to name their favorite mobile apps, one student immediately shouted "Tinder!" Perhaps the movie “The Social Network” was right, and college students only care about one thing. But more to the point, this is an incredibly successful app that came into existence only two years ago. The students have their fingers on the pulse, and they’ve kept me on my toes.

More satisfying still has been the experience of giving back. Through resume review sessions, I’ve met one-on-one with dozens of students to talk about their career goals and help them fine tune their resumes. As a hiring manager at pMD I’ve had the dubious pleasure of reading more than a thousand resumes, so I know what makes a resume scannable and readable, and what’s attractive to an employer. Many students hesitate to trim and focus their resumes, and they’ve told me that it’s helpful to hear my “less is often more” perspective.

Finally, I’ve found the most joy in giving tech talks at the computer science department. Working at pMD, I’ve had the opportunity to sit with hundreds of physicians and their staff as they learn to use our software for the first time. So most recently I spoke about “How to Build Learnable Apps that Users Love at First Sight.” User experience design is rarely taught in the classroom, yet the students showed a remarkable aptitude and passion for creating truly love-worthy apps.

“I'm in the early design stages of an app with a few friends and we've been debating the issue of borrowing UI patterns from common apps vs. coming up with something novel (which might require more investment from users to learn). Your talk certainly helped me think about that.” -Jonathan Schear ‘15

“I found it particularly interesting that large, well-known companies seem to think they can get away with neglecting new users in their UI design. A team of freshmen (myself included) won Hack@Brown with a voice-messaging app called "Squawk," and we tried to simplify the design as much as possible.” -Joe Engelman ‘17

I returned from Brown feeling invigorated and with renewed enthusiasm to move the dial on great software design. Even more importantly, I met and spoke with another generation of computer scientists committed to building great, learnable software that users love. I can imagine nothing more rewarding.

This is a continuation of part one where I started to introduce some of the terms the developers here at pMD throw around that might give non-developers a better understanding of what their favorite software engineer may be referring to. This list focuses on some of the terminology used in practicing agile software development--a methodology we started practicing more formally earlier this year.

Agile software development - An iterative and flexible approach to software development.

Scrum - One type of agile software development, where the basic unit of work is a sprint (see below).

Sprint - The regular work cycle of the scrum method. Most teams prefer short sprints of one-two weeks when all assign tasks can be completed.

Stand-up - A daily (usually morning) meeting to quickly get status updates on yesterday's completed and today's planned work. Standing helps avoid long drawn out meetings.

Scrum Master - A team member that helps facilitate the scrum process and assist in communicating and protecting the team from outside distractions.

Also to help give context to agile methodologies, defining an alternative may help:

Waterfall Model - A classic approach to software development that consists of rigid and sequential stages consisting of gathering requirements, designing, implementing, verifying, and maintaining software. This approach is generally criticized as being too rigid and slow to respond to the realities of customers and business needs.

In a small company, developers can’t work in isolation and neither can non-developers. I often find myself discussing a project with a non-developer colleague and am pleasantly surprised when they recognize some software terms I inadvertently used. This made me wonder if sharing a list of common terms developers use may help communication even more. So without further ado, here is part one of a list of terms that might help when conversing with your favorite coder.

Spaghetti Code - Structureless code; like an incoherent essay without proper grammar or flow; a developer’s worst nightmare.

Object Oriented Programming - Code written in terms of objects (ex. User and Document) and their relationships with each other (a User has many Documents); helps avoid spaghetti code.

Null Pointer Exception - The system expected a value to be there, but none was found; usually originates from an unhandled scenario and sometimes leads to a crash.

Refactor - Rewriting code to be cleaner, more robust, and/or better performing; a very gratifying exercise that programmers usually enjoy.

Technical Debt - Compromises made to deliver features in a timely manner at the expense of best practices; the analogy is an accrual of debt that needs to be paid back at some point in the future. Payment can be in the form of horrific catastrophes, or better yet, the time it takes to refactor.

Timing Issue - Technically this refers to unwanted behavior in software arising out of the temporal variance of events, difficult to reproduce and debug; I also use the phrase freely whenever I have no idea what’s going on.

Regression - When a change to the code leads to a previous feature to stop working; the identification of this type of bug is usually preceded a few seconds earlier by the claim that “I haven’t touched that code in months!”

As a developer for a mobile charge capture company, I am blessed with some unique access to the medical industry. I get to have one-on-one conversations with doctors, practice administrators, and even those who've been on Capitol Hill to discuss and lobby for better health care reform! Those special experiences aside, at the end of the day, I’m a developer at a software company. And like all developers at software companies, I am subject to similar frustrations and roadblocks that can prevent me from being the best programmer I can be.

In my career I have spent an unknown number of hours on a bug that I just couldn't figure out, or a new feature that just wouldn't work right. Often, I get that "Eureka! moment," not from staring at the screen for the umpteenth hour, but driving home or walking the dog. But why couldn't I see the answer when I was dead focused on it, and instead more successful when I was, say, doing the dishes? Aren't developers supposed to disappear into a dark coding cave for long periods of time and mystically emerge with some cool new feature? To answer that question, we must admit that developers are not machines. We are humans and we need breaks. It may sound backward, but we need to stop working so much in order to get more done.

As developers, we have a responsibility to create great code that should do more good than harm. When we work and push ourselves for long periods of time, we set ourselves up for failure. When the mind fatigues, the risk of introducing software bugs goes up. The more bugs introduced, the more time needed to fix them later. This downward spiral is expensive - in both time and money. With our ever growing technologically dependant society, these bugs can cost billions of dollars, physical harm, and in the worst of cases, fatalities. A particularly expensive example occurred in 2012 to Knight Capital Group. What was supposed to be a simple set of trades over the course of a few days, was executed in a matter of moments, and reportedly cost the company $440 million. Yikes!

But what can we do? Implement new or better agile practices? Add seemingly infinite unit tests? Re-train personnel to re-emphasize the importance of testing? Or all of the above? No matter what the attempted solution, nothing will help without a clear, focused mind to execute these solutions. So instead of working long hours in a row, we should think about how to work more efficiently and effectively. Rather than powering through daily code-a-thons, try working in smaller blocks of time (90-120 minutes). Afterwhich, get away from your desk and take an effective break.

The goal of an effective break is to let your brain recharge from all the concentrating. Tap into the other lobes of your brain for a few minutes; those synapses need exercise too! Go for a walk, grab a snack, or chat with coworkers - just get away from your desk. By switching gears, we let our minds take a rest from the tunnel vision of focusing and can just relax. The mind constantly works even when we’re not aware of it, and it continues to process information even when we’re doing something entirely unrelated. And no, as much as we’d like to tell ourselves, checking and responding to emails is NOT an effective break!

Here at pMD, we pride ourselves in providing our customers the confidence to desire and expect constant quality of our software. We strive to go above and beyond these expectations, and to do so, we strive to strike that proper work/life balance. We achieve this by promoting the work hard AND work smart mentality. So get up and get some grub. Go take a jog during lunch. Me? I’m taking the long way back from the coffee shop.

"After I was overruled, I wrote a letter of resignation. In my letter I explained the risks and said I would rather resign than allow dangerous hardware onto the Shuttle. And I pressed my letter into more hands than absolutely necessary. The embarrassment level got pretty high and the managers backed down — I was allowed to make the necessary changes.

Does this make me a hotshot, a moral person? Not really. I wasn’t married, no children to support, I could afford to lose my job for a principle. Besides, I was able to imagine what would happen to me if I caused a Shuttle failure — kids on the street saying ‘There’s the guy who killed all those astronauts and the schoolteacher.’

I didn’t become an engineer just to design things. I wanted to design them right. I was a bit too idealistic for engineering profession, who’s motto is “Ship it.” So I changed careers — I got into computer science.”

- Paul Lutus, Confessions of a Long-Distance Sailor

This was written more than twenty years ago, and it’s funny that the term “ship it” was as connotative and full of meaning back then as it is today in the midst of the lean startup movement. When I read this in Paul Lutus’ very engaging sailing travelogue, it made me think that software engineering has always had a bad reputation when it comes to quality and reliability.

It seems like not a week goes by without millions of emails and accounts being hacked or a software bug halting a stock exchange or delaying an airline. Software’s increasing potential for good is only matched by its equal potential for harm. Testing methodologies and its culture have advanced a great deal in the last decade, but most would agree that it’s no panacea. Instead some argue that the deeper solution is in the languages and idioms we use that make writing code safer. Yet this too can never protect us if the person who writes the code doesn’t see the potential for harm in their work and second, does not feel the moral responsibility of saying no to “ship it.”

In an industrial society, the makers of things are usually far removed from the end usage and impact of their product. Developers are no different, and that’s why when I joined pMD, I was so surprised by the heavy exposure of the developers with the customers. We routinely visit customers on site and build first-name relationships with them. I remember the first time I sat down with the billers in a practice in Colorado and discussed their workflow, their pain points, and generally how overworked they were. When I returned back to the office, I felt a renewed sense of empathy and purpose to how a seemingly small feature I would write could impact someone’s daily job across the country. This impact could go well beyond the ROI of our software, and affect someone’s happiness and sense of effectiveness in their profession.

Even though developers sometimes love to put on their headphones and crank out some piece of software wizardry, it’s important to occasionally step out of the office and engage with your customers. Regularly seeing the daily work-life of your users first-hand helps establish that sense of responsibility to the end-user, and it makes the software better for it.

I’ll leave with an excerpt of an interview with a famed Japanese woodworker, Toshio Odate:

"Toshio added something very important: there is something else that is not always being grasped by many woodworkers in the craft: the social responsibility of the craftsperson, be they woodworkers, musicians, photographers, doctors, or writers. Each of these persons practices a craft and in that craft they are expected to produce a result that carries with it a social responsibility. And that responsibility is where the person’s skill and even artistry must be used to serve others. For example, if a joint is used to show off a person’s ability to create a showy piece, but fails when it comes to joining two pieces of wood securely and efficiently, that person has failed at their responsibility to society—even if the joint “looks beautiful.” But the craftsperson who makes a solid joint, that looks “good enough,” does its job and holds for decades or centuries to come—that person has fulfilled the responsibility society asks of them. Even if that joint is hidden, it has the spirit of being a good joint…

…once you commit to making a piece for a client, or a family member, that responsibility is there, to those people. It’s your job to make sure your design and your workmanship serve the needs and desires of your clients, and that the techniques and materials you use serve those ends. Anything else is superfluous, and runs the risk of being dangerous, or at best, ugly.”

Source Fine Woodworking.
As a pMD software developer, I take great pride in building best-in-class medical software that our customers love. Our development team accomplishes this not only by shipping a high quality product, but also by making sure that the features we are working on address the most important needs of our users. However, as you might imagine, this list of customer priorities isn’t static. In fact, it changes almost constantly. To help keep our development team in-sync with this ever-moving target, we use an agile software development methodology called Scrum.

Traditional software development

In the traditional world of software development, something called the Waterfall method is frequently employed. This long-running process of building a software product is broken into several phases: requirements gathering, design, code, test, and release. Each of these steps might last as long as several months. At the end, you (hopefully) have a piece of software ready to ship. However, there is one problem: the thing you have produced is based on a set of customer requirements that is now a year or more out of date!

Even if those customers had come to you several months into the process with an updated set of priorities, there would have been very little you could have done to change what was being worked on, especially if you had already moved past the requirements gathering stage. You’re stuck building software that isn’t going to address the current needs of your customers. That’s where Scrum comes in.

Scrum to the rescue

Scrum is a popular agile software development method that takes the Waterfall process and compresses it into a much shorter development cycle called a sprint. A sprint typically lasts from two to four weeks (we do two week sprints at pMD) and still includes all five phases of development from the Waterfall method, just in a much more abbreviated form.

The key player on a Scrum team is the Product Owner. It’s this person’s job to make sure that the backlog of features waiting to be worked on by the development team stays prioritized according to the current needs of the customers. When a feature request or bug report comes in, it’s up to the Product Owner to prioritize it and add it to the backlog in the appropriate place.

With this backlog in hand, the software development team sits down at the beginning of each sprint for a Sprint Planning meeting. This meeting has two parts: first, using a system of points, the team establishes what their development capacity will be for the upcoming sprint, i.e. how much bandwidth they’ll have to work on the software (things like travel to customer sites, jury duty, and vacation affect capacity). Then, they start at the top of the backlog and begin estimating the work involved in each feature by assigning it a point value. When the total of number of points estimated reaches capacity, they stop.

These features then get assigned to the upcoming sprint. For the next two to four weeks, the team works on them, going through the design, code, and test process for each one. At pMD, we frequently release features as they are completed. Other groups may choose to wait until the end of the sprint and do one, larger release. Even in this case though, releasing every few weeks is still far better than shipping software once a year!

It’s all about the customer

We love building software that delights our customers. Scrum helps us achieve this by providing us with a great framework for keeping our work in-sync with our users’ changing needs and priorities. In future posts, I’ll dive deeper into the details of how we’ve implemented the Scrum process at pMD and some of the tools we use to collaborate and track our progress.
At pMD we’ve been building mobile messaging and charge capture apps for doctors since the Palm Pilot. The app was a bit ahead of its time, but it’s surprising to note that even though the landscape has drastically changed, the fundamentals of what makes a good mobile app for doctors have not.

So before you decide to revolutionize the way doctors interact with their patients and smartphones, here are five lessons we’ve learned:

1. Security

There are very important and profound responsibilities for any application that deals with protected health information. From client side encryption of stored and transmitted data to strict requirements for any cloud based server solutions, these are not challenges that can be addressed “later.” Plan and build for them from day one. More than likely, you’ll need to persuade a hospital’s security team and lawyers that your app won’t lead to unwanted litigation and meets HIPAA/HITECH rules.

2. Robust offline mode

For many consumer apps, this isn’t a high priority. Yet if you’ve spent just a little bit of time walking the halls of a hospital, you’ll understand that there are some very pronounced WiFi and cellular dead spots, so not being able to work offline is a dealbreaker. From cath labs to a doctor’s office, work needs to get done even without internet access. Medical apps, with few exceptions, must have a robust offline mode; essentially allowing the doctor to do all that is physically possible in the app without any reception. Any pending work should be transparently queued and sent when connectivity is reestablished. Native apps have advantages in this area over strictly mobile friendly websites, but if the app still needs data connectivity to load a screen or let the user enter any data, you’re still failing to offer true mobility.

3. Interoperability

A doctor does not work in isolation, but is part of a larger care eco-system. Any medical app dealing with patient data will need to live and integrate with other systems sooner rather than later. This is one of the main value propositions of moving away from paper in health care. Currently, this interoperability is through the industry standard HL7 protocol between Electronic Health Records, Practice Management, hospital registration, and billing systems.

4. Hidden Customizability

Many medical practices have become Galapagos Islands of “individuality.” Across more than a hundred medical specialties and a tumultuous regulatory and financial landscape, different communication and financial workflows have evolved over time. The key in building a usable app for doctors is understanding where you can change a workflow for the better, and when you need to adapt to it. Hiding additional buttons and screens from the end-user until the last possible moment helps preserve the simplicity and elegance of your app. Let the customer grow into any advanced functionality.

5. Easy Access to Support

Human support is always important, especially when you’re dealing with a highly educated and time-pressed clientele. When we train doctors on our charge capture and messaging software, we tell them that the most important thing to remember in the app is how to reach us anytime by simply tapping the built-in button to call or message us. Many won’t need to, but the option and ease to do so is hugely reassuring to a busy doctor.