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

I don't typically write a lot of code in hotel rooms, but after what we had seen working onsite with one of our surgical practices earlier that day, I really wanted to get an update out right away.

Three of my co-workers stood behind my clunky hotel room desk chair, watching my screen with excitement as I made the last tweak and pulled up my web browser to test it. Sure enough, we found that this update would save the medical assistants (MAs) five clicks per patient as they prepped each day's visits in pMD.

I pushed the change out for code review and dragged my desk chair around to face the others. We were all grinning. It had been a busy travel week and we were all exhausted. But we knew that this change would make a huge real-world difference because we had all seen the same thing during our meetings with the MAs. It felt amazing to be able to push it through quickly instead of "passing my feedback along" or "logging a ticket" and hoping that someone else who hadn't experienced what I had would prioritize the request as highly.

When we returned to the practice the next day and followed up with the MAs that we had trained, we found that they were ecstatic and very grateful for the update. It hadn't been bad before, they said, but in an environment that is full of distractions, and with an ever-growing workload in every area, this was an electronic charge capture process that was now definitively faster than the paper superbills that they were filling out before.

As a software developer, I found it so satisfying to act on what I had seen and to make a quick change that took the experience from "fine" to "great" in the eyes of these users. And it felt amazing to be in a room with coworkers who all had the same experience and arrived at the same conclusion.
It takes a team of amazing people to develop and support pMD’s charge capture and secure messaging software. Here’s a chance to learn more about one of our team members, Siavosh Bahrami. Siavosh is a Lead Software Design Engineer and the mastermind behind our system that allows pMD employees to efficiently provide unparalleled service to all of our customers.

How long have you worked at pMD?
We were just talking about this. I’m a super senior.

What does that mean?
Over five years. Wow. That’s a long time.

How do you explain your job to someone you meet at a dinner party?
Well, since I live in San Francisco, I don’t usually need to do much explaining. Outside of San Francisco... I’d say that I write software, and I make websites and mobile apps for medical folks.

What sort of languages do you use on a regular basis?
The main language we use for the backend server at pMD is Java. The database is MySQL. On the front end we do a lot of JavaScript, HTML, and CSS. We use different libraries. We have frameworks we use: Backbone, jQuery. And then there’s iOS development and the language is Objective-C.

Do you do any sort of software development outside of work?
I’ve always liked programming, and I think programming outside your regular job is helpful if you have the time. I don’t always have as much time as I like. But yeah, I do programming outside of work. Actually, one of my side projects is something I talked about in my pMD interview at the time.

Side projects always introduce you to new things. And it's actually a really good feedback loop. A lot of times I’ve learned stuff in my side project that I brought back to work, too.

What’s the side project?
My hobby is woodworking. I was frustrated by having to follow a lot of blogs manually. I would have to open up like 50 different tabs just to see if a site had posted anything new. For whatever reason I never got into RSS feeds. I never could find the software, figure it out… I guess it was over my head. And there would be blogs that didn't have RSS feeds and I couldn’t really keep track of them very easily. So essentially I wrote a web crawler that goes out and checks all these blogs for me and posts if they have new blog posts. These are amateur woodworkers who blog about stuff they’re building. It saves me a lot of time. A few other people use it too, so that’s kind of fun. At this point, it probably checks 300 blogs a few times a day. It posts the links and the pictures. You should check it out! It’s called

What health care trends are you following most closely?
As a company, we’re paying very close attention to the community aspects of health care. ACOs are very interesting. I think that would be a dramatic shift in how the country does health care. I think it's very important for software companies like us to try to support that.

It fits in line with our philosophy. Our philosophy is to make the doctors happy. Doctors are obviously happy if they can focus on treating the patient. Regardless of what the reimbursement model is, that’s going to be a constant. If your software company can keep the doctor happy and effective, and the patients as healthy as possible, it will succeed no matter what.

What's been your biggest achievement as a developer at pMD?
One project that was really fun just last year was when we introduced the web chat client. We ran into interesting scaling issues after we had gone live. What I still remember is that we convinced the team, the whole company, to give us 5 days to re-write the message panel after we had learned a whole bunch of stuff.

As a software developer you don't often get the chance to go back and re-do something. This was a very special opportunity. It was a very important opportunity. It was a lot of fun working very closely with the rest of the devs architecting it, implementing it (all within 4 or 5 days), and releasing it successfully. I still remember that week as being super fun - and intense. Looking back, I’m very proud of what we, as a team, accomplished.

What are you most excited to develop in the next year?
I would love it if pMD does a virtual reality app. (laughing) I’ve been reading a lot about VR and think it's so super fascinating. VR and augmented reality have been talked about in the medical world for a long time so it’s not totally far fetched.

But realistically… I think it would be fun to build an app for the Apple Watch for the physicians. That would be fun. Writing a brand new iOS app for the Apple Watch would be a great chance to use Swift, the year-old language that Apple introduced that replaces Objective-C. It would be a lot of fun to build something from the ground up.

What’s your superpower?
It’s definitely not running or anything athletic! Well, I tend to be pretty curious, which has led me to learn a little bit about a lot of different things. I wouldn’t say it's a superpower, but it’s something I’ve learned about myself. I find most things pretty interesting.

Best soundtrack for an afternoon Code Bash?
For a morning code bash I usually listen to electronic music. Trance or something. That usually gets me going with coffee in my hand. In the afternoons I tend to mellow out a little bit, so in the office we sometimes play some Miles Davis. It depends on my mood. I’m a moody guy! I listen to everything in between those two.

ICD-9 or ICD-10?
I’m old school; I like ICD-9. But you know, supposedly, ICD-10 is going to help the world keep track of things.

Giants or 49ers?
You’re asking the wrong guy.

New York or San Francisco?
Tough one! There’s no city like New York. Everyone should try to live in New York for at least a little while. San Francisco is a pretty cool place… aside from the weather.

Favorite pMD customer memory?
We have a customer who I’d spoken to a lot over the years. When I finally traveled there, it was wonderful. We felt like we knew each other. She hugged me on first sight. It’s nice putting a face to somebody you’ve worked with for a long time. Having the face-to-face interaction helps to build the communication and the trust.

Favorite pMD team memory?
When we first came out to San Francisco, a lot of us didn’t know anyone here so we used to hang out a lot. When one of our colleagues Ryan first came out (it may have been for his interview or during his training) we went out to the Mission and had a great night. We had dinner and it was an all-night sort of thing. It was a good time.

Tell me a joke.
Um…. I have no jokes. I’ll have to get back to you on that one.
It's no secret to anyone working in medical IT that the storing and transferring of data digitally is a booming space. Doctors generate terabytes of health data every day, but that data isn't useful unless it's sent somewhere. EHR and practice management (PM) software systems need to send and receive that data to facilitate patient care and track reimbursement. At pMD, we are proud of our ability to interface with any software using HL7 specifications or any other structured data. We are always looking for ways to minimize manual entry, avoid unnecessary errors, and increase efficiency. After all, who enjoys manually entering data from one system to the next? With an obvious need to share data between systems, one would think that software companies would make this process as easy and simple as possible. Sadly, this isn't always the case.

What typically holds up an interface project? In my experience, cost is often the culprit. We all work for many reasons: to help others, to solve problems, and, at the end of the day, to get paid. But sometimes, the hunt for the almighty dollar gets in the way of the greater good, and it's frustrating. A few weeks ago, one of our providers approached us to discuss setting up a simple one-way appointment interface between his new PM system and pMD’s charge capture software. Everything started off on track: the kick-off call went well, the technical challenges were minimal, and schedules were clear to set up a transfer of appointments into pMD. Then came the cost discussion.

Our customers are typically surprised to hear that pMD doesn't charge any additional fees for building interfaces. Most EHR and PM vendors will charge customers an initial fee for the development of an interface with some sort of recurring cost added for "maintenance." That being said, each vendor has a different philosophy about how much revenue they plan to generate from interface projects. Because this is a relatively simple interface that some other vendors offer free of charge, we were shocked to hear this PM vendor quote thousands of dollars for the initial setup and a hefty 18% annual maintenance fee!

The doctor was disheartened and justifiably angry. When he further investigated the situation, the PM vendor tried to push their own mobile product on him as a cost-effective alternative to interfacing with pMD. If you read our post earlier this week, you might be able to guess how that went over. The doctor said, “[The PM vendor’s] mobile product is an unreliable POS! What a bunch of crooks!” Needless to say, this doctor chose to forego the interface and is still happily using pMD.

We’re continuing to search for alternative solutions for this doctor, since the PM vendor’s price quote was so unreasonable. My opinion as a software developer is that this approach lacks integrity. It's not right to ask for an absurd amount of money for such a simple interface. That doesn’t help doctors, and it certainly doesn’t help patients. I'm so glad to be a software developer at pMD, a company that looks to solve problems by working with our customers instead of viewing their requests as a way to make money.
As a software developer, it’s always exciting to me when I can take existing pieces of functionality we’ve built at pMD and combine them together in a new way to produce something new and innovative. I like these situations because it means we’ve written the components of our system in a modular and reusable way, and also because it allows me to provide additional value to our customers without having to write a feature completely from scratch.

An example of this type of code-reuse occurred recently while working with a care coordination group in Anchorage, Alaska. Care coordinators in many ways are the quarterbacks of medicine. Their job is to help improve patient outcomes by coordinating with all of the providers involved in a patient’s health care, including primary care doctors, specialists, pharmacists, therapists, and insurance companies.

We like to think of these various groups as a health care community. In Anchorage, the community uses pMD to stay in-sync with one another around patient care. They share clinical notes and send secure text messages. pMD’s care coordinators, who are at the center of this data exchange, noticed that often times their patients would get admitted to the hospital, but the coordinators wouldn’t find out about it until a few days later, when perhaps a hospitalist, or the patient’s primary care doctor, or even the patient themselves, notified the coordinator.

We realized that we could provide a unique solution to this problem: when the hospitalist group admits a patient to the hospital, pMD could send an automated alert to the care coordinators, along with the other members of the community who provide care for the patient. We already had functionality in place to support other types of alerts, and we already had the Anchorage community connected to each other via pMD, so it was straightforward to add this new piece of functionality.

When we released this new alert feature we got immediate feedback, both from the care coordinators and the primary care providers. They were thrilled to have access to this additional piece of real-time information about their patients. For me, it was extremely satisfying to be able to identify this need and quickly release something that added a tremendous amount of value for a relatively small amount of effort. I’m excited to see what else we can do at pMD to make our care coordination software offering even more powerful.
In my last post, I talked about the importance of involving everyone in a company in direct customer interaction - one of these ways being customer support. The challenge with this approach is how to do this efficiently and successfully. A few weeks ago, we began trying out a rotation-based approach to customer support around our charge capture, secure messaging, care coordination, and HIE software. Prior to this, we had a much more informal system, which granted us infinite flexibility, but with significant overhead. When everyone is responsible for every support request, you start witnessing something akin to the tragedy of the commons.

The challenge for us was how to implement a rotation-based system that would increase everyone’s efficiency, allow flexibility in our schedules, and still maintain quality customer support. There are three variables that define any support rotation:

• Size of the team and the rotation period
• Skill composition of team
• Duration of the rotation

Each of these is a lever that can change the outcome of a rotation. All three of these rotation attributes directly affects the others. If the teams are too large, individuals will feel more anonymous and less empowered to directly impact support quality. Additionally, if the teams are too small, the rotation periods are overly spread out with large gaps of customer interaction, and you risk not having the correct mix of skill sets in a rotation (development, sales, operations). The challenge for every organization is to discover what the sweet spot is to these attributes.

At pMD, we've been experimenting for the past month with different values for these variables and have learned a great deal. The result has been somewhat astounding. The majority of the company now has dedicated, uninterrupted time to excel at their core tasks in any given week. At the same time, the new scheme brings a significant measure of predictability to one’s exposure to the inherently unpredictable nature of customer support. As we continue to iterate on these three variables, we hope to fine tune and settle on the perfect balance.
I had been chatting with a doctor for a while about his hospital rounding and charge capture process and how he ended up with his current practice, when I suddenly had a question for him about the Apple Watch.

We’d been looking at different aspects of pMD together and his excitement about the mobile software kept growing. Meanwhile, we had also swapped stories about Seattle and New York and about the geographical challenges caused by pursuing a career in medicine. On a whim - not certain yet myself if I would get one - I asked him if he was thinking about getting an Apple Watch.

"Ah," he said regretfully, "I don't think I will get one."

I noticed that he was wearing a large, elegant, solid-looking steel watch and asked him about it. His face lit up with pride. "I will be buried wearing this watch," he smiled. "I won it in a race..." He began telling me about his hobby of street-racing BMWs and of his excitement at winning the rally. I could tell that the watch meant a lot more to him than timekeeping or as a fashion statement. It was something that he had earned - a badge of honor.

It made me think about the increasing overlap between the professional and the personal, and also between fashion and technology. We use our own devices to do our jobs better, and we've begun to wear and carry and accessorize these computing devices as they have become more mobile. A watch, more than a phone or a computer, has always meant something different to different people: time keeper, fashion statement, status symbol, memento.

I myself did eventually decide to spring for the Apple Watch - but I wasn't replacing anything. If I were in his shoes, I might also hold off, at least until I had a chance to win an Apple Watch Edition in a street rally!
I wrote about the importance of team chemistry in my last Charge Capture post and how it’s key to creating world class medical software. So what helps create that chemistry? It takes a team and a car. When I first started with pMD, I parked at a lot nearby the office and bought daily permits. Parking in San Francisco is usually off-the-charts expensive, so I definitely had a discount at $6 a day. I didn't know where anyone lived and everyone commuted to work independently.

This went on for about a year or so until Siavosh, one of my fellow dev members, moved a little further away from work and needed to figure out a new way to get to work. Siavosh had lived close enough to walk before, or if he was feeling really lazy, had a neighborhood parking pass that could be used all day just outside the nearby gates. He was in a bit of a conundrum now, but he didn't stress. You see, Siavosh was our transportation liaison (I still don't know what that means) and he had heard about free carpool parking in the underground parking lot at an elusive Presidio transportation meeting (no one knows what these are, either).

Anyway, as luck would have it, he had moved literally onto my commute route! Driving from Daly City, a city just south of SF, I take many side streets to avoid the main rush hour crunch of the inner highways - it was a boring 30-40 minute car ride. But stars aligned and this gave way to the first ever pMD developer carpool! Now I have a carpool buddy to chat with and shake up the monotony of commuting.

Through this carpooling, I've learned enough to call Siavosh a friend rather than just a coworker in the amount of time that otherwise would have taken A LOT longer as just cube-mates. We had worked pretty well together before this joint commute, but I'd attribute a lot of our growth as the pMD iOS team to riding in a car together for 10 minutes a day, each way.

We’ve written on the Charge Capture blog in the past about how everyone at pMD wears many hats. For me, as an engineer, that means I also get to spend time doing things outside of software development, such as account management and sales. When I am doing engineering though, that time is typically spent working on software. However, because pMD is expanding our private cloud into a second datacenter here in San Francisco, I’ve recently had the opportunity to get my hands dirty with a different area of engineering: hardware!

We’re adding a new datacenter in order to provide great performance and reliability for our medical customers across the country. As part of that expansion, we’ve had to purchase and configure a number of different types of servers. While these generally arrive to us pre-built, I’ve found myself with several of them opened up and partially dismantled on my desk over these past weeks. I’ve installed power supplies, upgraded memory, changed network cards, and installed RAID controllers. I’m a bit of a computer hobbyist on the side, so some of these tasks were pretty familiar to me, but others, such as working with RAID controllers, were new and fun to learn.

For those who haven’t heard the term, RAID stands for redundant array of independent disks. It’s a technology that takes multiple physical disk drives and groups them together into one “logical” disk. For example, in a simple RAID 1 configuration, you might have two disks in an array together. To the operating system on the server, they look like one drive, but in reality there are actually two physical devices, each with identical copies of the other’s data. This means that if one of them fails, the computer can keep running. In fact, you can even swap the failed drive out for a replacement without interrupting the server’s normal operation in most cases.

Managing these RAID arrays typically requires a special piece of hardware called a RAID controller. This device has to be physically inserted into a special slot in the server, and then wired up to the server’s hard drives. Up until last week, I had never had the chance to install one of these cool gadgets, but I’ve set up two of them in the last couple of days and have really enjoyed the process!

While I’m still a software engineer at heart, there’s something very satisfying about occasionally getting to build tangible objects. It’s rewarding to see those machines come to life and contribute to a great experience for pMD’s customers.
As a small software company trying to make waves in the medical industry, we at pMD have to do things differently than most folks. One of those is how we interact with our charge capture, secure messaging, and HIE customers. In a previous post, I wrote about a developer's responsibility to their customers. Philosophically, I think a developer must communicate directly with their users on a regular basis. Not doing so leads them down a slippery slope of wrong priorities.

Customer support is perhaps the most raw form of this crucial feedback. When speaking to other software developers about their projects, I can pretty quickly tell if they've ever had any substantive experience communicating with users (or if they've ever had any). Doing support changes you as a developer, quickly kills any bikeshedding, plants your feet firmly on the ground, and tells you what needs to be done. Pleasant or unpleasant, the work is real, but so is the satisfaction, knowing effort is not being wasted. When your team and customer size is small, little to no organization is needed to provide excellent support and still maintain efficiency. As the team grows however, it's every organization's challenge to maintain and nurture the communication link with their customers.

Some companies hire consultants, which then recommend and implement a far away call center, shielding the developers and the company from direct contact with their customers. Sometimes this may make sense, I'm not sure, but it's probably not before your company has achieved its mission statement. Balancing efficiency and the benefits of egalitarian support by the whole company is no easy task but something I've been tasked to scale as pMD has grown. Today, the team is still relatively small but spread across four time zones, and our customer base has grown by several orders of magnitude since I joined. In my next post, I'll discuss some things we've been trying, and new experiments on doing effective support. There are always difficulties when trying new things, figuring out what works and what doesn't, but it's necessary as we try to reinforce our link to our customers, and try to make waves.

The practice manager pulled up the patient that I named. This patient had long been part of her nephrology practice, and in many respects was like their thousands of other patients, but with one major difference: this patient had a care coordinator.

Her eyes widened as she looked at the patient in pMD and started reading the care coordination summary. "They know so much more about her than we do," she said quietly. Before her eyes was a concise summary of the patient's medical history, including an accurate medication list and the patient's overarching goals of care.

The care coordinator had painstakingly pieced together this summary using notes from hospital electronic health records, lengthy conversations with the patient and her family, conversations and secure text messages with health care providers who had seen this patient, and the electronic health records of multiple private practices.

By consolidating and summarizing all this fragmented information into a single note, and by using pMD not just for charge capture but also sharing information automatically across all the physicians in the community who might see this patient in the future, the care coordinator was ensuring that everyone who saw this patient would have the big picture. They would not be relying on the patient alone to provide complete and accurate information about her own medical history - something that the sickest patients are often unable to do.

As we left the nephrology group's office, I reflected on how many times I've seen physicians beaten down by technology that burdened them with excessive data entry and that generated massive, redundant electronic records for them to wade through looking for kernels of information. When they really need it, like a primary care doctor seeing a patient who was just discharged from the hospital, they can't get into the hospital's silo.

At that moment, I felt renewed excitement about working with the care coordinators who are the patient's ally in navigating our fragmented health care system. They can't be everywhere at once, but now their clinical summary can.