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

Here at pMD, we provide world-class charge capture and physician communication solutions. But what's not as well-known until you become a customer is how much we take pride in providing world-class support. We rotate in teams and act as live FAQ/troubleshooters for our customers. This can be pretty fun and rewarding to help our customers out, but at times, it can get fairly demanding. With our customer base growing all the time, this means the support volume is bound to naturally increase. This, of course, is difficult to sustain if we want to continue growing faster and faster! So what’s the solution?

With each development cycle, we attempt to tackle a feature that "sharpens the saw." This is what we call features that help ourselves in order to better help our customers. We recently tackled a volume issue where we were getting too many provider training requests for our in-house support team to handle at one time. A good problem to have, I assure you! But it was daunting trying to coordinate and reschedule requests that came in all asking for the exact same training time. After experiencing this growth problem firsthand for a while, our development team created an in-house scheduling system building off our charge capture appointment functionality. It has worked wonders in managing and spreading out the training requests. Sanity was finally restored and we continue to grow at record pace!

As a fast paced development team, it's easy to fall into a trap of only developing for tomorrow. What's the next best feature to roll out? What's the next 'it' thing to show off to a new customer? But we recognize the need to run various threads of development projects that aim to improve our product from multiple angles. Obviously we have high level initiatives such as "ICD-10 Adoption" and "Secure Text Messaging", but we recognize the need to continue evolving our mobile software to the most minute detail. I can't wait to see what gets sharpened next!

At pMD, we spend a lot of time interacting with our customers, helping them utilize our software in a way that best fits their workflow, and also gathering feedback from them to help make our product better. As an engineer, having this facetime with the people who use the software I build -- charge capture, secure messaging, HIE, and care coordination -- is invaluable. For many companies like us who have customers spread out across the country, visiting some of those users in-person would be extremely difficult. However, we’re very fortunate in that we have access to a small plane which can take us to cities that would otherwise be very challenging to reach.

I had the opportunity last week to meet with customers throughout the Pacific Northwest. We made stops in Boise, ID, Kennewick, WA, and Kalispell, MT, among others, sometimes touching down in several states in one day! We had a series of highly productive face to face meetings with a number of the medical groups we work with throughout the region, many of whom were surprised that we were willing to take the time to meet them in-person. However, we were able to accomplish so much in those meetings that it soon became obvious to us all that it had been time well spent!

An added bonus to this particular trip was that when it ended, I got to spend a long weekend with family in Idaho. I enjoy working with our customers all over the U.S., but having grown up in the Pacific Northwest, I’ll admit that I’m a little biased toward our customer base in that part of the country because they give me a great excuse to see friends and relatives in the region. I returned back to San Francisco on Sunday refreshed from my relaxing weekend, and energized by my renewed connections with our Pacific Northwest customers. I can’t wait for the next trip!
Since the beginning of the year, the number of secure messages pMD processes everyday has increased by 300 percent. One of the key characteristics of any messaging platform is speed and providing the right feedback to the senders and recipients of messages. From amazing user feedback during the same period, we've built quite a few bells and whistles into our platform, letting doctors and staff overcome some of their longstanding communication and workflow challenges. As a developer, however, continually adding features to a system with very tight performance constraints always makes me doubly scrutinize our architectural choices.

It's easy to write a feature that significantly slows down what was once a snappy application. This is in fact all too common in the software industry. We've all experienced the first version of an app that is often fast, but a few years later, after 100s of new features, the system has slowed to a crawl. Typically as consumers, we take faith in Moore's law and simply buy newer and faster phones and personal computers just to keep up. SaaS providers can often times employ the same strategy with their servers by regularly upgrading hardware. Sometimes this makes economic sense, but often times it does not. Instead, it is usually best to try to mitigate the performance hit or simply avoid it with better code.

One interesting strategy that’s been on my mind recently is how to distribute code complexity between the server and clients. The server can often times handle an immense load but can also lead to centralized bottlenecks that become much more difficult to build around and maintain. Finding the right components of a feature that can be implemented on the client side can sometimes bring about immense gains, although not without some trade offs. In terms of maintainability, it is often considered that building server code provides faster iteration times. Because after all, we control the server while all upgrades to native clients like iOS and Android are governed not only by the end user but the respective companies (Apple and Google) as well. This can sometimes provide a huge incentive to keep the client software 'dumb' and merely a consumer and displayer of information.

Pushing complexity into web clients has its own challenges compared to smartphones. There was a brief period a few years ago when everyone wanted to build full html5 and javascript apps with the same functionality as native Objective-C and Java code. The results were discouraging in terms of performance, usability, and maintainability. Part of the challenge had been that for a long period of time javascript, the language of the browser, had been viewed as inappropriate for serious or intense work. Yet the language's renaissance in the last few years, and the astonishingly rich ecosystem of innovative VMs, frameworks, and tooling is breaking many people's assumptions of how complex and maintainable javascript code can and should get. Frameworks like angular and backbone help abstract away a great deal of the incidental complexity and let developers focus on the solutions to their problems instead.

In one of our recent projects, we’re planning on distributing some of the computational needs of a protocol to the web client while utilizing some modern frameworks. The result will attempt to capture the current sweet spot of where an application should live, and perhaps lead to both ‘smart’ clients and servers. Yet as the last few years have shown, this balance is always shifting and needs to be constantly reavaluated.
The deadline is not going to change again, and I've been talking with a lot of customers lately about ICD-10. pMD has customers that have been using a single, unified ICD-9 + ICD-10 code list for almost two years now, but I'm hearing a lot of anxiety from those who haven't “clicked the button” yet and updated their codes.

The bottom line is that people are scared, and scared people sometimes ask for things that don't make sense. I've had to remind one or two practice managers that there is no way their cardiologist is going to see a patient for W55.32XA or R14.3, so there is no benefit in cluttering their diagnosis list with those codes. Nor, realistically, will their cardiologists wade through the 801 results that SNOMED CT® lists for "Diabetes" - nor should they. Diabetes is never going to be a primary diagnosis for a cardiologist. 801 results times 20 patients per day is... enough to push a doctor into early retirement.

Anxiety aside, some very pragmatic questions come up over and over again:

* Compliance officers want to know if the system will help guide their providers to a more specific code when needed. (Yes)

* Providers want to know if they will have to learn brand new names for the same clinical diagnoses that they've been seeing patients for since residency. (No)

* Billing managers want to know if their staff can start seeing ICD-10 codes from the doctors before October 1st so that they can submit test claims and give the providers a grace period to get used to the new codes. (Yes)

I keep finding additional ways that pMD can help make the transition smoother for those who haven't converted yet, and also to make the answers to these common questions more obvious. Our approach has always been to have the software itself do the heavy lifting on helping our customers understand what they need to do - which boils down to "push the button" at this point! - and what will happen when they do.

It's a race to the finish line, and times are busy, but it feels good to be on the front lines helping our customers get there.
Once upon a blogging time, I wrote about the importance of developers actually meeting with their customers face to face. It’s important to see firsthand if what you've created is working out, what's wrong, and what can be better. You don't have to rely on third party accounts for feedback, which can often become a game of telephone. On a recent trip to Texas to work with a gastroenterology group, this was no exception. However, rather than a story of watching and learning about areas I could fine tune or fix, this is a story of satisfaction.

I was warned that the doctor I was about to train was likely going to be a handful. He was notoriously late with his charges because he just didn't care. Billing was a time-consuming pain in the butt and he'd seen enough software products/vendors that he was skeptical of everything. This was going to be a fun one. He was late of course, spending extra time with the patient before our training. The receptionist was really nice and let me in on his little secret of making vendors wait, but she reassured me that he would be fine.

When we finally got started after the initial pleasantries, Dr. A, as we’ll call him here, said something to the extent of "OK I'm going to tell you now that if this isn't faster than me jotting something down on paper, I'm not doing it." Pretty deflating start for sure. As we got into the training, I could see he was OK with everything, but not impressed. The software is easy to use, but his lack of excitement concerned me. He could just as easily go back to his old ways and ignore everything we were doing. We were about halfway through the training when we heard an alert sound coming from his phone. Looking for any reason to do anything except the training, Dr. A started searching for the source of the sound. 30 miles away at another site, my colleague Jen was in the middle of training one of his partners. Jen was covering our secure text messaging feature and they had just sent my doctor a message saying, "I bet I’m better at this than you!" Something clicked with my doctor - the game was on. They volleyed light-hearted insults back and forth through our secure messaging system and it was in this moment my doc realized that this wasn't just some stale program that "captured charges." The entire system was real-time; it was fast, and it was now! This was an amusing moment and was the turning point in our training. Dr. A was excited, and the training turned into a session of "Where else can pMD help us?"

Outside of the obvious big deal this was, a key takeaway for me was how a simple message sparked some ho-hum enthusiasm into a pMD advocate. This wouldn't have happened if the charge capture and secure messaging system we built wasn't rock solid!

It's important for developers to get out there. Meet your customers, get firsthand feedback on what to improve, and also get the rewarding firsthand Eureka! moments. I'm glad to be working for a company like pMD where my dev team constantly pumps out quality products, and where we travel to these places to enjoy these moments.
We recently released a feature for our web application that allows our users to upload files and attach them to patient records within the pMD system. When we started the design process for this new functionality, we knew that we wanted to build a user experience that felt modern and sleek. We’ve all used old, slow, form-based file upload utilities in the past, and we didn’t want pMD to replicate this experience.

We began searching for existing tools that would allow us to provide the desired experience to our users. We wanted pMD to feel almost like an extension of their desktop. What we found was pretty disappointing: there were a few options available that gave us parts of what we needed, but nothing that would function well for the wide variety and age of browsers that our users utilize. For example, one tool we really liked worked well in Chrome and Firefox, but didn’t function at all in older versions of Internet Explorer. After an exhaustive search, we decided that we needed to write an all-new upload tool from scratch.

After several days of development and testing, we were able to come up with something that we are really excited about. It supports all modern browsers (Chrome, Safari, Firefox, Internet Explorer 10), but also functions well in older versions of Internet Explorer, which many of our customers use. The utility we created detects the browser version and offers as much functionality as that particular environment can support, and then degrades gracefully in cases where certain components (e.g. file upload progress updates) aren’t available.

After we released the new upload feature to our customers, we realized that the software tool we had created to support it could be useful to others. So, we decided to share it with the rest of the software development world as open-source software. Doing this has two benefits: it allows others to reap the benefits of the hard work we put into the software, and it also enables us to solicit suggestions and feedback on the utility we’ve created. In the end, we hope that both the software development community, as well as end users will really benefit from this effort.

For the developers out there, we encourage you to fork our repository on GitHub, try it out, and submit any improvements that you come up with. We can’t wait to hear your feedback and see your creative uses of pmdAjaxUploader.
One of the most anticipated technologies coming out in the next six months are the Oculus Rift and SteamVR, both promising to resurrect virtual reality from the dustbin of 90's hype. I have yet to try on even the developer preview prototypes, but I'm already saving my allowance to purchase one of them early next year. The reason is not purely play (although that would be a big part of it), but curiosity in how it may impact medicine in the coming years. At pMD, we spend our days split between talking with medical professionals and building software to help them save time and deliver better care to patients through charge capture, secure messaging, and care coordination. Looking at new technologies and imagining how they may help our mission is a big part of that.

Looking back at some of the literature of the 1990's, during the peak of the unfulfilled VR bubble, we have some tantalizing possibilities:

• Surgical training
• Preoperative planning
• Educating both doctors and patients via 3D models of the anatomy
• Psychological and physical treatments of patients (PTSD, phantom limb syndrome, phobias)
• Diagnostic tool for displaying patient imaging results more accurately
• Telemedicine from remote diagnosis to complex tele-interventions

These possibilities may soon become practical in the years ahead and end up not only as potential charge codes, but find their way into pMD's suite of offerings ;)

It's refreshing to see the hospitals coming to us for a change. I've built interfaces with hospital software such as Epic and Cerner for many years, always at the request of physician practices that use our software. The way this typically plays out is the physicians introduce us to their contact at the hospital. This person may or may not feel favorably inclined towards that physician group, and they almost always have limited IT resources and plenty of their own projects on the burner. They want to do the right thing, but they get a lot of different requests from outside practices. Each request represents more work for their overburdened IT team, and also some risk - they are being asked to send data to an external system that they don't control and may not know much about.

I'm sympathetic to anyone in that position. A hospital can't be expected to build dozens or hundreds of interfaces to the charge capture, practice management, and EMR systems of every practice that sees patients there. Building that many interfaces would take many years, and what works with one system in health care rarely works the same way with another. Plus, the variations from site to site and interface to interface increase the overall HIPAA compliance risk and create maintenance challenges.

So imagine how pleasantly surprised I was when a major hospital system that we've interfaced with for many years approached us and asked if we could reuse their interface for some other groups in the community that were also asking for patient demographics. We've already been doing the filtering on our side and routing the correct patient records to each practice, so it wasn't a big leap for them to realize that we could reuse that interface on their end. We could do the work on the pMD side to take that data the "last mile" and get it into the various systems used by each individual practice.

From the hospital's perspective, this was a win in so many areas: they could keep their community physicians happy without spending their own IT resources on VPNs and interfacing with every practice management system and billing company under the sun. pMD took on the compliance challenges and risk involved in filtering and data transfer, which kept their compliance department happy.

We've been happy with the arrangement as well. We're big believers in interoperability, and it's exciting to have a valuable service that we can offer to hospitals rather than asking them for a favor when our customers want data. Plus, we get to reuse all the work that we've put into being the best in the industry at interfacing.

Word is getting out, and I'm eager to help our Health Information Exchange (HIE) customers meet ONC's new requirement for "a majority of individuals and providers across the care continuum to send, receive, find and use a common set of electronic clinical information at the nationwide level by the end of 2017."

Working at pMD, I get to travel much more often than I did at my previous job. We get to meet our charge capture, secure messaging, and care coordination customers face-to-face, which is always helpful for me as a developer. So naturally, we also get to visit new places - I visited Mount Rushmore for the first and likely the only time in my life! And more generally, we end up with a ton of random stories that you otherwise would not have sitting behind a desk day in and day out.

Coming home from my last trip in Birmingham, I was exhausted, sleepy, and looking forward to a non-eventful flight home. Everything was normal, with some light turbulence here and there but around the two-hour mark, our pilot announced that it was going to get a bit bumpy and asked everyone to take their seats. This happens all the time. No big deal. It was kind of bumpy, but I've had worse - not even close to that roller coaster feeling. But after we had cleared the turbulence, I noticed some commotion two rows back. Have you ever watched a TV show with an episode on a plane and someone falls ill? There's some confusion, shock, mumbling, and you see the flight attendants go up and down the aisle asking everyone, "Is there a doctor on the plane??" Well, that actually happened! Thankfully, I wasn't the one in distress but it was pretty stressful watching the happenings.

Before we departed, I ended up chatting with the guy sitting next to me. He worked for the airline and was able to catch the flight on standby with his wife (who was seated in another row) to spend a quick impromptu weekend in San Francisco. A cute story to start the weekend. It turned out his wife was the one in trouble! As luck would have it, there actually was a doctor on our plane and he was sitting at the end of our row. He did his doctor thing - stethoscope, lights in the eyes, follow the finger, etc... She was given an oxygen tank and her husband swapped seats to sit next to her. The folks close to the action (including myself) tried our best not to look and you could only kind of hear what was going on since it's pretty loud on a plane.

After we landed, we were all told to stay seated. EMT rushed in to find the poor girl, who was in the very last row! The doctor briefed the medics on what had happened and they took her out before we were allowed to deplane. I think/hope she ended up OK; she looked a lot better after we landed than when we were in the air. I don’t think the doctor could charge for his in-flight services, but if he did, he could use pMD for it since pMD works in airplane mode too! I wonder what the charge code for "airplane visit" would be? At least he doesn’t have to use the ICD-10 code V97.33XA - “Sucked into jet engine!”

We all know that we’re supposed to exercise in order to stay fit and healthy, but it can be challenging to find time to fit a workout into the busy day. I know of many people who solve this problem by working out early in the morning, or after work in the evenings. I however, find it very difficult to force myself to strap on the running shoes at 5am. Similarly, when I get home after work, I tend to struggle to find the energy and motivation to hit the gym. So for me, lunchtime is the perfect time for a workout.

As a busy pMDer, my schedule can fill up quickly with meetings, calls, and software development time. However, I try to be diligent about blocking out an hour most days for a midday workout. My favorite workout is swimming laps, and we’re fortunate enough to have the Letterman Pool just a few steps from our office. While some people will argue that having to shower and change in the middle of the work day is a hassle, I find that I have much more energy and my afternoon productivity level is noticeably higher on the days I make it to the pool. For me, the hour spent away from the office is well worth it.

A recent study showed that even just taking a few lunchtime walks each week can have a huge impact on our mood while we’re at work. I didn’t need scientists to convince me of this, but I’m always happy to see the benefits of exercise getting attention in the news. Several of my colleagues have joined the lunchtime workout club as well. Whether their chosen activity is running outside, lifting weights at the gym, or something else entirely, each of us comes back to the office after these sessions with a renewed passion and energy for serving our charge capture, secure messaging, and care coordination customers. So, stop procrastinating, and take the plunge!