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


Working at pMD, I sometimes forget that I'm not a typical developer. We get to travel for charge capture implementations, customer check-ins, and health care conferences, so I've come to conclude that I am, in fact, a traveling developer! Although we have other responsibilities that make my job even more interesting, at the end of the day I am still a developer. This means getting creative in where we code. For me, I sometimes do my best work on a plane. But being mobile has its challenges. Namely, how can I keep my laptop charged to make the plane flight most productive??

Here are some secret (and some obvious) tips and tricks that I employ to keep my Macbook Pro alive for those long flights across the country on a plane that has no outlet.

Before you fly


1) Make sure your laptop has a healthy battery. I rarely check this when I’m in the office, but it's good practice to ensure you have a healthy battery before a trip. Otherwise, no matter what you try to do, your bad battery will end up draining quickly. Check the "System Information" on your Macbook Pro.

2) Update to the latest Mac OSX. Apple is good about their software - well, as much as a giant software powerhouse can be. New OS versions always attempt to fix any previously known power issues.

While traveling


1) Use the Integrated Graphics Card instead of the Discrete Graphics Card. If you can turn off apps that require the discrete GPU, switch over to the integrated GPU! Discrete GPUs are bigger, faster, and just downright hungrier. Turn that off to save juice!

2) Dim your monitor. The lower the brightness of your laptop, the less power the monitor draws. This one is fairly obvious, but tough. Make sure you don't dim your monitor too much where you can't easily see what you're doing! No power saving is good enough to warrant introducing a bug from misreading something. (Make sure to turn off auto-brightness as well, otherwise your dimming will be overridden.)

3) Turn off all apps! Well, turn off the ones you're not using anyway. This is not to be confused with minimizing apps. Laptop apps run in the background even when they are minimized. Browsers especially can be caught attempting to reach the outside world even if you don't have Internet access.

4) Speaking of Internet access, if you're not using Wi-Fi on a plane, disable Wi-Fi and bluetooth! Even though you are not using any connected devices, these enabled radios will draw power in search of nearby devices to connect to.

5) Check your energy saving settings. I've spoken a lot about what you can do while the laptop is active, but there's much to save when the laptop is closed! Make sure your sleep mode settings are set to turn off hard disks whenever possible and disable power nap. These are seemingly harmless, but they can drain precious power while you're not working.

With these tips you, too, can enjoy programming in the friendly skies like I do!

One of the goals of the pMD software development team for Q4 is to pay extra attention to new things going on in the software world around us, and to learn as much as we can from them. It can be easy to get caught up in just shipping the next feature without stopping to find out if there might be a new or better way of doing something. Not everything we read about, or hear about at tech talks, is applicable to us, but the education process itself has been really enjoyable.

As our team’s lead Android developer, one of my focuses has been on modernizing our Android application. I’ve been studying the latest Android UI trends, software design patterns, and Android development tools, looking for things I can apply here at pMD. To that end, a major task that I recently completed is migrating our codebase to the new official Android Integrated Development Environment (IDE), which is called Android Studio.

Android Studio offers a number of great benefits over the old set of tools we were using, and I’ve enjoyed setting up our codebase from scratch within the new environment. The biggest change is probably the build system, called Gradle, that Android Studio utilizes. Gradle is powerful, yet flexible, and uses Maven for dependency management. It’s going to help us more easily keep our dependencies up to date, and will also allow us to release different build types (dev, beta, production) with less effort than was previously required.

We’ll be benefitting from several other great features of Android Studio as well, including its updated set of virtual devices. These simulators allow us to run our app on a variety of virtual Android devices, so that we can catch any potential device-specific issues before we ship our software to customers. Android Studio also comes with a set of lint tools that help us identify and fix potential performance bottlenecks in the app that previously would have been more difficult to spot.

I expected that migrating our codebase to Android Studio would be extremely challenging, but it ended up not being nearly as bad as I anticipated. I think part of that was just because many of the new features have been a delight to learn and use. Overall, the project was a great experience, and I’m excited to usher the pMD Android app into a new era.



There is no question that technology is changing at an accelerating pace. If just a few years ago someone had told me that my smart phone (a verifiable supercomputer) would become disposable with an annual lease plan, I would have laughed. Yet that is the reality of how quickly consumer hardware and software change and improve. As developers, this is one of the things that excites us the most about our jobs, and prevents things from becoming stale. Technology is the embodiment of progress and improvement - a manifestation of optimism. Our coding tools and industry standards constantly expand what is possible and empower us to be more efficient and make a real difference. This gives us tremendous power when tackling other industries that are not as fluid, like medicine and health care. Yet keeping up with the constant changes is a challenge.

When I was in grad school and working in a research lab, we were faced with a similar challenge. How does one continue their own immediate work but keep up with the latest research and results? One common and helpful practice was organizing weekly reading-groups with my labmates. Each week, or as time permitted, one person would pick an interesting research article and send it out to the others prior to that week’s meeting. Everyone would read or skim the article, but the one who chose it would present it and lead a discussion of the paper. This helped distribute the work and provide a great forum for teaching and learning. It was often the case that a discussion or question during one of these meetings would lead to serendipity in one's own work.

At pMD, the developers have a similar challenge. How to keep up with the latest technologies and best practices in scalability, mobile platforms, languages, security, and health tech as a team and as individuals? This motivated me to start a reading group just like my old lab, where the motivation and effort is distributed across the team. The reading items can be anything from research papers to cool engineering blog posts describing some technical issue. We'll be having our first presentation later this week, and I'm looking forward to being the first presenter but even more excited to where the discussion leads.
While evaluating pMD, health systems and other large enterprises often ask us to fill out security and compliance questionnaires. Overall these are more similar than different. For example, "Do you allow users to share accounts?" and "Do you encrypt protected health information in transit and at rest?" show up nearly every time. Even though the questions are mostly boilerplate and our answers are strong, I used to dread the task of filling out the spreadsheets, if only because they tend to be so long. It's not unusual to see several hundred questions.

But I've actually enjoyed working through the last couple of compliance questionnaires that came along. It's fun to get a chance to show off in the areas where we're exceptionally strong. For example, how many other companies can confidently say that they have two-factor authentication turned on for 100% of their corporate email accounts? How many can hot-switch from one datacenter to another if needed, any of which is fully capable of serving all of their customers? How many automatically prevent users from choosing complex but easily-guessed passwords such as "Password123!"?

Some of the survey questions are almost whimsical - for example, one asked whether data backups are stored on magnetic tape. Who does that anymore?! Another asked which departments are represented in our compliance policy review committee, and also the membership of the committee responsible for overseeing the compliance policy review committee. I had to remind myself that most of the vendors that this enterprise works with probably have more than thirteen employees.

Humor value aside, I always find at least a few insightful questions from each enterprise that challenge how we think about security. We don't always approach thorny compliance challenges in the same way as another organization, but it's healthy to have to explain why and to always evaluate our approach for any blind spots. As with other parts of the sales process, hearing these concerns expressed (even in spreadsheet form) makes us more sensitive to our customers' needs. I say keep 'em coming!

The pMD development team has a number of cultural values that we believe help us work better together and produce a great product. One of the most important items on that list is that we, both on the dev team, and the company as a whole, use our own software in every way possible. We leverage pMD for everything from recording our expenses (we capture them as charges, just like a doctor would capture a medical charge), to securely messaging one another, to tracking sales leads.

Recently, we started trying to address a challenge we were facing with our customer support desk. We offer 24/7 phone support to our customers. pMD users can reach a pMD employee literally any time of the day or night, 365 days a year, if they encounter a problem or have a question. As our company has grown and we have added team members who are located all across North America, we’ve found it’s more difficult to coordinate the responsibilities of handling phone support than it was when we all worked in the same office together.

In our search for a tool to help us with this problem, we realized that the answer was right in front of us: pMD already has a call schedule built into it! Our customers utilize this functionality to keep track of which provider in their group is on-call at any given time, and to make sure that no call goes unanswered should a patient need their attention. We immediately saw that we could use the pMD call schedule internally in much the same way to coordinate our customer support desk work.

To do this, we first built a programmatic interface to the pMD call schedule. This interface allows other software programs to “ask” pMD which employees are currently on-call. Then we did some work on our phone system to enable it to query the new pMD call schedule interface. Now, when a call comes in our phone system knows exactly which pMDers are available to assist. The best part is, the system doesn’t discriminate based on a person’s physical location. It can ring my cell phone while I’m on the road just as easily as it can reach the landline on my desk in pMD’s San Francisco office. I can work with pMD customers from literally anywhere on the planet that has a telephone.

This new functionality is still in its early stages, but so far it has been working very well. We hope that as it matures we’ll be able to roll out components of it to our customers. If pMD is able to route our calls internally, it could also provide that service for pMD users who utilize pMD to coordinate patient care. We’re excited that we’ve found another way to dogfood pMD, and can’t wait to see where it takes us.
ICD-10 is only a day away and the entire team here at pMD is working on all cylinders to ensure our customers will have a seamless transition experience. Looking back on the last few months, there's been a lot of preparatory work both from the development team as well as sales, operations, and our account managers to lay the groundwork for one of the biggest regulatory changes in the health care industry in recent memory. From a software development perspective, automation is a key tool. We spent a significant amount of time more than a year ago to make our ICD-10 conversion wizard as seamless as possible, yet we were originally requiring each customer to work with one of us during the transition directly. Although a great experience all around, we realized that we had become a bottleneck to our users for their code update.

This realization led us to automate the process even further, by taking ourselves out of the critical path of our customers becoming ICD-10 compliant. We were originally very concerned that a human guide was necessary to ensure that the conversion would be successful at every step. Yet the line between automation and providing a human safety net is a tricky one to determine and is best found from fully understanding and empathizing with your customers. The new wizard, which almost all of our customers have used to convert their codes to ICD-10, is now completely self-driven through an intuitive interface and thoughtful feedback at key stages of the conversion. This is an approach we are actively taking with many of our other features, empowering our users to do more with the software we build while always being there to lend a hand.

The Brown University student shifted in his chair and leaned forward. "That's where it got really hard," he admitted. "We didn't realize it during the project, but we were making a lot of assumptions. We had tested our code carefully and gathered a lot of feedback about the usability, mainly from other students. But we didn't realize that the clinics in Tanzania wouldn't have a consistent Internet connection. We had created a web-based EHR, so that was kind of a show stopper! And the people using the software - some of them were new to using a keyboard, and a lot of them weren't familiar with the controls and button types that are familiar to you and me. We thought the software was very user-friendly, but it took a lot of hand-holding to get them up and running with it."

I don't think I had ever met someone so early in their career as a software developer who had experienced something like this. I've never been to Africa, but through my work at pMD I've become very familiar with the "connectivity dead zone" that exists inside many hospitals, and with physicians who aren't fluent with software despite being gifted and experienced clinicians. This student had gotten a taste of one of the most challenging industries to write software in, and instead of running away from the hard parts, he was eager for more.

One thing I've always appreciated about pMD is how often we consciously choose to do things "the hard way." It's easy to justify tradeoffs in software design when it's twice as fast to write code that results in features that are one extra click for the user. But if you take a challenging industry, multiply that one click times twenty patients, and throw the software at a busy doctor in a distracting environment, the easy justification suddenly seems like the worse path. Taking the extra time to write a native app that's fast and works well offline has paid off time and time again. If I were a student, I would have no way to learn that, no way to judge the long-term effectiveness of my software designs. But taking the long view and committing to work at a self-sustaining company, I get to enjoy the dividends of doing things "the hard way."

As a developer at pMD for the past few years, it's fun to be directly involved in shaping how pMD “Makes Doctors Happy". From a reliable mobile software that's actually easy to use, to eliminating paperwork, to real-time secure messaging, I thought I had seen all of the different ways that pMD could benefit a doctor. That is until my most recent trip to Dallas for a group rollout at seven satellite offices. As it turns out, pMD doesn't only make doctors happy at work, but at home too!

On a training in Fort Worth, I worked with two doctors to figure out the best way to utilize pMD for their hospital patient handoff. They had been emailing each other weekly about their patients as many pre-pMD groups I've worked with before have done. After presenting the traditional way of organizing handoff notes in pMD with a shared mobile list, one of the doctors, Dr. D, joked to the other doctor, "Oh man, your wife is going to love this!" We all had a quick laugh and I asked "Is your wife a doctor too?" thinking she could benefit from using pMD as well. Before Dr. A could answer, Dr. D jumped in with "No, it takes him over an hour to do his handoff notes, so now his wife won't lose him in the black hole of emails every Sunday night!" All Dr. A could do was laugh and nod in sheepish agreement, finally answering "It's true. When I tell her I have to go do my emails, she knows that's her cue to go find something else to do by herself." It was one of the more humorous endings to a training that I've had in a long time and it was enjoyable to learn about another indirect benefit of our mobile software. Perhaps we should change our slogan to "pMD Makes Doctors (And Their Spouses) Happy!"
Over the years, pMD has become increasingly a geographically diverse team. Communication between the office developers and the remote teams has had its challenges and benefits, but despite all our busy schedules we try to all hang out a few times a year in a non-work capacity. On Monday, the team celebrated a milestone and flew the entire team out for a day of relaxation and go karting. These weren't your childhood go-carts but semi-professional machines coupled with hours of instructions in order to drive the machines at peak performance. As developers, the technical aspects of racing brought out our hacking mentality as we tried to shave seconds off our times and best our teammates in friendly competition. A great time was had by all.

Working with our colleagues in person, even if just a few times a year, helps us build the relationships necessary to have high bandwidth communication and productivity the rest of the year. This philosophy is also leveraged with our customers through onsite meetings with developers. Maybe we should invite some of them to our next go karting event…

I was recently on a business trip that took me through New Jersey. Peculiarly, it's illegal to pump your own gas there. The station was understaffed, so I waited for quite some time. The gas pump handle was almost within reach, so I was about to break the law by the time the attendant finally arrived. Some people enjoy chatting with the attendant or the feeling of being served by a person, but I was in a hurry so I got frustrated.

It made me think about software design. I've seen people get stuck because they're "waiting for the attendant," unable to do something that they would be perfectly capable of doing themselves if the software gave them the option and made it easy.

For example, when we first released our ICD-10 functionality in 2013, we used to be very involved every time a group wanted to update their diagnosis code list with ICD-10 codes. We would schedule a demo with them ahead of time, send them screenshots and suggested verbiage to forward to their providers, and wait until they had "followed the process" before we allowed them to update their code list. By doing this, we gathered some great feedback on common questions and concerns, and we learned how to make ICD-10 more intuitive and user-friendly in pMD. But from the user's point of view, this process was confusing and slow, and some practices got stuck at various places along the way even though they were interested in converting early.

Fast-forward to 2015. We've been busy for almost two years applying what we learned to streamline the process and to remove any remaining gotchas and speed bumps with the transition to an ICD-10 list. Since October 1 is right around the corner, we've now taken the final leap and made it as simple as clicking the button to become ICD-10 ready in pMD.

It's a great feeling as a user to be capable and empowered. If the software makes it easy for you, then it doesn't feel like you're being asked to do more work. Instead, you're saving time because you don't need to wait in line or interact with a human. Just think about how many people go into a bank branch to withdraw money from a checking account - it now seems archaic and tedious to do that under normal circumstances.

At pMD we work very hard to provide unparalleled service. As an engineer, I believe that the best service is often provided by the software itself.