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

In the software world, when we have some complicated logic that we’ve implemented in code, we often will hide that logic under a layer of abstraction which makes the code easier to understand. For example, let’s say I have an application that does nothing but manipulate squares. If I had some code for calculating the area of a square, I might hide that behind a function called Square.getArea(). This would save the caller from having to think about what is going on “under the hood” to actually perform that calculation.

Sometimes though, new requirements arise that break the abstraction. In our example, let’s imagine I wanted to expand my application to handle circles. Now, because the formula for calculating the area of a circle is different than a square, my getArea() function would now have to take a parameter, isCircle, and then have conditional logic based on the value of that parameter. Our abstraction would be broken. In this case, the fix would be as simple as defining a more generic Shape base class. Shape would have more specific Square and Circle subclasses, both of which would implement the getArea() function in their own way.

At pMD, we’ve offered secure messaging functionality to our customers for about two years. In its earliest days, the product was envisioned as a platform where a provider utilizing pMD’s charge capture software could send an encrypted message to another charge capture user. It has evolved today to be a completely standalone, realtime, mobile secure messaging solution. This is really exciting for us as a company, but of course, this incredible growth has put strains on the original abstractions we put in place when we built the software. Specifically, our concept of what constitutes a “contact” in pMD has evolved from being a charge capture user to anyone who has a smartphone and wants to communicate securely.

Sandi Metz has an interesting blog post called “The Wrong Abstraction.” The title is a bit misleading, because what it’s really about is what to do when you realize that your current abstraction has been stretched past its breaking point. At pMD, we arrived at this realization about our secure messaging contact list recently. Our original concept of a contact was no longer capable of supporting the growing list of requirements we were asking of it. So, we decided to spend this week doing a deep refactor of our implementation.

Our goals in this refactor process were to build an abstraction that, first and foremost, is able to meet the demands we have for new features today, e.g. the ability to add anyone to your contact list. We also wanted it to be as future proof as possible, in order to be able to meet requirements that we think we’ll need to accommodate soon, e.g. the ability for doctors to securely message with their patients. It’s definitely tough to find the right balance, and to not “over engineer” our abstraction, but I think that after several days of whiteboarding and discussions, we’ve arrived at something that we’re all really happy with.

We’ll be spending the next several days implementing and testing our new design. We’re confident that we’ve chosen an abstraction the elegantly encapsulates the functionality that our growing secure messaging product asks of it. We’re excited about how far it will take us!
The industry-leading electronic health records (EHRs) were not designed with mobile devices in mind. Targeting the vast majority of physicians who are office-based and largely stationary, they fill a computer's screen with nested menus and rows of buttons. With the added requirements of Meaningful Use certification, there's simply no way to fit all their bells and whistles into a user-friendly smartphone user interface - nor, for the typical primary care practice, is there any great need to do so.

Meanwhile, certain pMD customers who see patients in skilled nursing facilities (SNFs) or dialysis clinics have told us that their EHR requirements are actually pretty straightforward. They mainly want to have consistency in their clinical documentation across all the various facilities that they go to. These facilities use their own proprietary EHRs, or even paper charts in some cases.

The physician groups need the ability to do coding audits internally using the doctors' progress notes, and to respond to any external requests for documentation from insurance companies. It turns out that none of those things require a Meaningful Use certified EHR. These highly mobile doctors can adopt something more elegant and fast that has been designed from the beginning for the same smartphones that they're already using for charge capture. After all, the stimulus money is gone and there's a hardship exemption for groups who see most of their patients at multiple outside facilities.

As specialists, their templates can be small and specific to the type of encounter. Integrated quality measures that are highly context-sensitive keeps data entry to a minimum while preparing for 2019, when quality and efficiency will account for most of the MIPS program which will replace Meaningful Use and will include a value-based payment bonus from Medicare as well.

It's exciting to be working with our forward-thinking customers to build the lightweight, mobile-first EHR that meets the under-served needs of geriatricians, rehab specialists, and nephrologists. The first EHRs were designed by physicians simply to improve their record keeping and to reduce the administrative burdens on their practices. Returning to this idea, it's liberating that we can focus our energy on what the doctors actually need and want from an EHR rather than the bureaucratic requirements imposed by the government and by insurance companies.
It's been one heck of a year for our secure text messaging app in terms of development, roll outs, and viral usage. I can't express enough how proud I am to be part of a development team that listens to its customers and continues to build features based on their feedback. It's our “customer first” mantra that has allowed pMD Messaging (we like to call it “pChat” for short) to see adoption grow 600+ percent in the past year!

What started as a simple add-on feature to charge capture so providers didn’t have to text in code about patients anymore, has evolved into a standalone product for us that is only continuing to grow. We've integrated messaging into our charge capture platform with action triggered messages, automated reminders, and patient alerts, just to name a few. Most recently we added email notification reminders as apart of our multi-platform notification system to accommodate in-office staff workflows in addition to our mobile providers. This was a huge hurdle as many offices do not want their staff to use their cell phones at work.

With each charge capture implementation over the past 12 months, I've seen adoption get easier and easier for the doctors and the practices because we're able to offer what no other product has been able to offer them. A software that works naturally, easily, and is still secure without adding additional work to the user. In my last trip to San Marcos, Texas, it was amazing how lighting fast everyone gravitated towards pMD Messaging! It was easily the fastest viral adoption at a practice that I've personally implemented. Their entire office understood that their old methods of communication were not secure, so each doctor and nurse combo had invented a sort of code to discuss patients.

Once I told them pMD’s messaging was HIPAA-compliant, their eyes widened and they were ecstatic at the notion of being able to text freely. As I went through the individual trainings for 6 doctors and 18 staff users, it was fun to see their excitement and immediate usage of our secure messaging. The last doctor to get set up, who didn't come into the office until the end of the day, had 45 unread “pChats” because he hadn’t logged into pMD yet! As I trained each person from the start of the day, he would get simple notifications that “So-and-so sent you a secure message in pMD". From this alone, he could mentally follow me through his office as I worked with his colleagues. It turns out each person I worked with had sent a pChat to him for testing and so he was able to tell whose office I was in - sort of like GPS via pChats! While we probably won't be implementing geo-locations anytime soon, it's exciting to see what new features we add to secure messaging in 2016.

One of the things I like most about working with the team here at pMD is how productive we are when everyone rallies around a common goal. It’s a cliche saying, but I really believe that often times, the whole is greater than the sum of its parts. When we’re all working towards the same target, the energy of my colleagues is contagious. We all know that we can rely on each other to do whatever it takes to help get us across the finish line.

Recently, we were all pushing hard to hit an end of the year goal that we had set for ourselves. One evening during that period, my colleague asked me if I could jump in at the last minute and spend a couple days on the road with a customer to help with that effort. He felt that this would be asking me to go above and beyond my regular duties, and I could sense that he was treading carefully in his question. I stopped him part way through and borrowed a favorite phrase of mine from our pilot, Will, saying, “The answer is yes. We’ll figure out the details later.”

I really like this phrase, because to me it signifies that we’re all in this together. It’s not truly intended to blindly answer every question with a “yes,” but it does imply a high level of trust in one another. We’re all willing to roll up our sleeves at times and put in the extra work to help the team’s cause.

In my case, that met jumping on an early morning flight to Arkansas and spending a couple of long days working with a customer in the area. It ended up being a productive trip and I enjoyed meeting with a great group of doctors. Best of all, it helped us meet our goal, which gave everyone on the team something extra to celebrate on December 31st. We’re excited to see what 2016 has in store for us!
pMD generates a firehose worth of data around the clock from our customers. It's not petabytes of Big Data, but I like to call it gigabytes of Pretty Big Data. Everything from patient clinical data coming in real time from providers, to billers processing charges, to countless external information exchanges with hospital and software systems around the country. To help our customers make sense of this data, we scrutinize all of our UI features and changes to hide anything that's not essential for someone to do their job easily and effectively.

Yet there are times that a practice needs to step back and see the forest for the trees. For a long time we've had a suite of reports that aggregate visit information across longer time scales, such as the charge and visit count reports to some pretty sophisticated auditing tools for different specialties. As our customers have become more and more data savvy in the new health care landscape, they've requested more insight into their productivity and efficiency. Sometimes these queries can very reasonably span years worth of data. From a technical perspective, this presents some challenges in scalability and processing.

One of my current projects is designing and implementing a new flow for these data intensive reports that can scale with the user's data while also providing a solid foundation for more large-scale reports. There are two basic challenges in building reporting infrastructure:

1. Making it scaleable
2. Decoupling the business logic from the data as much as possible

To address the scalability, some standard practices are being used. Heavily indexed tables, intelligent batching and throttling of work, and making the processing asynchronous to user requests. This last attribute will allow for long running reports to be scheduled on our job queue based on priority and load. The final delivery of the reports will then leverage our secure messaging app itself, which happens to make the report content highly secure.

On the second challenge, I've written about business logic and simplicity before, but it's always a struggle in keeping human affairs and constraints simple in the purely logical world of software. While working on this new infrastructure, I've found myself constantly refactoring codes as the correct abstractions become more clear. One of the tell-tale signs that you need better abstractions is when you realize your business logic is becoming complex, hard to test, and hard to remember the next day. When this happens, one key approach is to question your choice of data structures. Often times a map, list, multi-dimensional array, or queue are what stands between you and a decoupled, maintainable, and dare I say, beautiful business layer. In my case, the big insight was realizing that "flattening" our log data into something more actionable by the logic layer avoids convoluting how the data is stored with how it should be processed.

Reporting tools don't often get the credit for being the sexiest part of an application. After this project, I can think of few things else being more sexy than building elegant and extensible tools while also helping provide clarity and perspective to our customers.
The best text message is the one that you don’t have to send.

Don’t get me wrong - I’m happy that we offer a feature-rich, user-friendly secure text messaging product. But I’m even happier that in many cases, we can use automation to remove the need for a person to manually send a text message at all. At the end of the day, security is great; compliance is great; knowing when a message was read is great; automated reminders are great; file and image sharing are great; group messaging is great; adding external contacts from the community is great; cross-platform (mobile + web) is great… but what’s REALLY great is saving someone time.

This idea is actually the origin story of our secure text messaging software. Years ago, I remember sitting with a charge capture customer who was explaining the process for following up with the doctors about charges that the doctors had submitted through the software. The customer would first add a note to the charge in pMD so they had a record of the follow up. Then they would send the doctor a text message asking their question. The text message itself seemed pretty harmless to them, so they weren’t in the market for secure text messaging software; but when we added the ability for pMD to send that message for them automatically, they became avid users.

Once we started down this road, we saw people manually sending each other routine, repetitive, and nonsecure text messages everywhere. Office receptionists were texting doctors about every new hospital consult. Answering services were texting doctors about nurse calls that occurred after hours. Specialists were texting each other to refer a patient, re-typing demographics that already existed elsewhere. Hospital doctors were texting PCPs (if they even had the person’s phone number) to let them know what had happened to one of their patients who got hospitalized. All of this messaging wasn’t just putting patient information at risk - it was actually costing someone time. Each individual message was fast and easy to send, but for these repetitive tasks, they added up quickly.

In a world where every major software company has its own messaging features, automation is the key to selecting the software that your people will embrace and that will keep giving back to you instead of simply checking a box on a HIPAA-compliance audit.

If you’ve read some of our previous Weekly Byte posts, it should come as no surprise that everyone at pMD - including developers - wear many hats. It keeps my job interesting and never with a dull moment. However, I can never neglect my main task as the lead iOS developer! And even then, my role is not just about writing code. As all developers know, we must continue to learn and hone our craft. Apple releases new software updates all the time and we in turn have to keep up. pMD, who supports a learning culture, encourages that we attend a seminar or sign up for a class once in awhile. Well, last month, I attended my first NSMeetUp!

As the name would imply, NSMeetUp is a gathering of people who "meet in Downtown San Francisco and discuss iOS and Swift & Objective-C related topics, meet other developers and other interesting folks.” Included in the program are talks, workshops, and hack-a-thons, as well as the opportunity to work on interesting projects. The session I attended was, "Lessons Learned with 3D Touch at Instagram". It was the first developer meetup I've been to in quite some time and I have to say, I very was impressed with the turn out.

Maybe the full attendance was for the free beer, but I really think it was for the speaker, Ryan Nystrom. Not often do you get to listen and talk to one of the core developers at a world class app such as Instagram!

The talk was great. As promised, Ryan discussed the pros and cons of 3D touch. For bonus points, we got to see a sneak peek of some new Instagram screens! More importantly though, we got to discuss first hand the rationale behind why they choose to create those features. An interesting story Ryan shared was how 3D touch actually generated a significant unintended uptick in usage for one of their summary screens, which before had little-to-no traffic.

While waiting in line to meet Ryan after the talk, I met a pretty cool freelance Ukrainian developer who moved to the bay area recently and has a three-legged dog! In the end, my main takeaway for 3D touch is that it should be viewed as "icing on the cake" rather than a core functionality for any app. It'll be fun to see what we can do for pMD’s mobile software and how we can add this extra "candy" for our charge capture and secure text messaging users.

I hope this encourages everyone to get out there, meet new folks, hopefully learn a thing or two. Maybe I'll bump into you at the next NSMeetUp!

In a speech from the Oval Office on Sunday, President Obama called on technology companies to work more closely with law enforcement. While he didn’t elaborate on this comment, many interpreted it to be a reference to the ongoing debate about encryption that companies like Google, Apple, and Facebook use to protect their users’ content. The purpose of this blog isn’t to debate politics, but these comments did remind me of how convinced I am that at pMD, we took the right approach in using the strongest possible encryption technology when we were building our HIPAA compliant messaging product.

Wikipedia defines encryption as “the process of encoding messages or information in such a way that only authorized parties can read it.” In practice, this means that only the sender and recipient(s) of a pMD message can read its content. To anyone else, including a pMD developer, the bytes that represent the message just look like gibberish. It’s not possible to decipher them.

When we were building our secure messaging product, it would have been a lot easier and faster to store messages and attachments either unencrypted, or using a weak encryption algorithm. However, both pMD as a whole, and especially our development organization, believe that the right thing to do for our users is rarely the easiest. So we took the best approach for our customers and used the strongest encryption techniques available. We even went as far as removing the default restriction that Java, one of the primary programming languages we use, imposes on maximum encryption strength so that we could use something stronger.

We’ll continue to make our users’ privacy and security a central theme of all the development work we do at pMD. We don’t take that responsibility lightly. And, while the political debate around encryption looks like it will rage on for some time to come, I sleep better at night knowing how we’ve chosen to safeguard our customers’ data.

As the year comes to a close, I've found myself on the road visiting customers as much as I have been sitting at my desk coding features. I've written about the importance of building relationships with our customers before, but another interesting perk is seeing parts of the country that I normally wouldn't get a chance to.

Over the last month, I've spent some time in Jackson, Mississippi, and Birmingham, Alabama, and coming up next week I’ll be in Jacksonville, Florida. Besides spending a year in Louisiana as a child, this was my first time back in the south. Although we keep pretty busy on our trips visiting doctors and hospital staff using our charge capture, secure messaging, HIE, and care coordination software, we do have time to ask for recommendations for places to grab the best local cuisine after a long day (and in the case of Birmingham, enjoy a delicious home cooked meal at a colleague's house). I can honestly say there have been few places I've been to where total strangers are as warm and kind as the south. Southern hospitality, I'm glad to discover, is alive and well and something that should be emulated.

Living and working in San Francisco, one of the major criticisms for most technology companies here is that they often get a distorted sense of priorities in terms of products and markets. pMD originally began in Georgia, moved to New York City, and then most recently moved to San Francisco. So perhaps the varied geographic background has helped us avoid this problem. Yet it takes vigilance to avoid falling into a myopic view of what’s important for our customers. Visiting far and wide to hear first hand what's working well and what could work better is perhaps the best way to make sure your vision and priorities stay relevant.

My friends all admit that they feel overwhelmed by work emails at least some of the time. A Google search on the topic yields headlines such as "Stop Email Overload", "Email Triage", and my personal favorite: "Clear Out Your Overwhelmed Email Inbox with the Nuclear Option". That sounds dire!

According to the Radicati Group, workers now send and receive an average of 122 business emails per day. As my email volume grew over the years, I started to find it challenging not to let emails get buried at the bottom of my inbox - especially those that I knew would take longer to address than a quick “yes” or “no” reply. Due to the number of meaty emails that I now receive during peak hours, the "Inbox Zero" approach isn't always a realistic option for me, so I've discovered a good methodology that works well for the high volume of emails that I receive every day at pMD:

I treat my email inbox literally as an inbox. In other words, it is a place for incoming items only - things I haven't had a chance to look at yet and park in a more suitable place. I've spoken to people whose email inboxes instead resemble either a never ending to-do list, or worse yet, a giant bucket of all the email that they've ever received. The problem is that when your inbox grows too big, it takes an increasingly large amount of time and discipline to sift through it. Inevitably something will get lost in the mix. It's better to treat the inbox as a very temporary place where your emails can wait until they've been moved to where the work will actually happen.

I read all emails as they come in. This helps me stay in the loop. While I'm reading, I archive emails that don't need a response from me, deal with anything that is a true emergency, and respond to any that can be addressed by a quick one-sentence answer. This allows me to stay more responsive than I would otherwise be on "quickies". The trick here, while reading fresh emails, is not to get sucked into responding to those that will require more time to address. It requires a certain amount of discipline, but it's important because...

I work from the bottom of my inbox (oldest emails) towards the top. This removes the anxiety factor of thinking "I have 57 emails I need to answer!" to a much simpler, more calming proposition: I only have to answer the one oldest email. Then, when that's done, I can answer the one next email after that one. This also helps prevent the "layer of crud" effect, where time-intensive or difficult emails tend to sink to the bottom of the inbox and then get buried by fresher emails. Eventually they fall out of sight, but they are never truly out of mind, and they contribute to a sense of futility. If you habitually work from the top, then as soon as you start to hit the layer of crud, you'll feel inclined to throw in the towel because you know that the deeper you excavate, the worse the emails are going to get.

I move to my calendar any emails that will require more than 10 - 15 minutes of work to respond to. I block out some time in my schedule to actually do the work, whether that's writing a lengthy email back to a charge capture customer or researching something before I can give a good reply. This gives me a sense of when I will actually be able to get back to the person, which in extreme cases could be a few days or more. Then after creating my calendar block, I reply to the original email to let the person know when I expect to have an answer for them, and at that point I can archive their email with peace of mind. I know when I'll be able to do the work to provide a good response, and the sender knows when to expect a reply from me. While I'm doing this, I sometimes realize that the time would be better spent in conversation with the person rather than writing an email, and in these situations I'll see if I can set up a call with them for the time slot that I'm already scheduling.

I “snooze” my sent emails if they’re important, so I don’t forget to follow up. All busy people struggle with email from time to time, and I don’t like to rely on the recipient to track and organize my email. So after I send an important email, I snooze it until a date after which I would like to have gotten a reply. If the person hasn't responded by then, the email comes back into my inbox all by itself, and that's my reminder to follow up. I previously used a Gmail plugin called Boomerang for this, but since I switched from Gmail to Google's new Inbox software, I've taken advantage of its elegant built-in Snooze feature.

Email in the workplace represents a confusing mixture of communication and tasks. Losing the thread on either of those things can have nasty consequences, so I hope my techniques will be helpful in battling email overload and avoiding the Nuclear Option, whatever that is!