November 5, 2022
So, you know what type of care you want to offer patients and you’ve identified the people you need on your care team to deliver that care. The next big question is: what tools will you use to deliver that care? One of the most interesting challenges faced by new virtual care companies is determining what tools their clinical and non-clinical teams will need and whether to build them or buy them.
In general, you can think about your product needs in two major categories:
In this edition of the Virtual Care Playbook, we’ll discuss important considerations to evaluate the process of building or buying any tool to address these two broad categories. As you’ll learn, the infrastructure that exists for companies offering virtual-only or virtual-first care has not developed at the same pace as the care delivery market. There’s no clear “best” way to go about building your tech stack for virtual care, so we’ll highlight a few approaches.
One of the main operational differences between an in-person care delivery model and a virtual model is the amount of asynchronous communication that happens between patients and their care teams as well as among the care team itself. For most virtual care practices, the reality is that clinicians and their non-clinical counterparts are likely operating as a distributed team. While most companies plan for their patients and clinicians to be communicating asynchronously, they don’t always plan for their care team to be doing so.
In addition to a designated clinical tool (discussed below), it’s critical to think about how your care team will collaborate with each other on patient care. Common workflows include task management, internal communications, and workload distribution. More often than not, virtual care companies end up with a patchwork system of tools that were not meant for healthcare delivery, but end up in use because they’re the only HIPAA compliant options available. When you’re focusing on getting to market and testing your model, this method, while frustrating, allows you to iterate quickly without committing to an expensive contract or months (to years) of engineering work. It also allows you to understand more clearly what your needs are and what the optimal workflows might be. However, as you continue to grow and add more strain onto those systems, each small inconvenience or manual workaround gets compounded. In the long run, you’ll need to invest in solutions that are tailored to your needs and enable your team to scale efficiently.
The Electronic Health Record (or Electronic Medical Record as they are sometimes referred to) is the catch-all term for the digital form of the traditional “paper chart”. EHRs hold everything related to delivering care to a patient: clinical documentation, prescription records, procedural notes, diagnostic orders and information, and care coordination records like schedules or case notes. In the digital health world the term “EHR” is often used to describe a wide range of products that are built in-house or have been bought and customized. But, depending on what types of patients you are treating, and what type of payment model you have, you may need a certified EHR to meet your needs.
As EHRs became the standard format for storing health data, more and more digital health products were developed. In order to establish standards for these products, the Office of the National Coordinator for Health Information Technology (ONC) created a certification program in 2010. Currently, there are over 50 specific features required for a product to meet the certification requirements from the ONC (in addition to completing the certification process). The idea behind certification is to protect consumers (in this case hospitals and practices) from spending large sums of money on substandard technology, particularly when it comes to data privacy and security. ONC certified EHRs are required for any providers who participate in value-based reimbursement programs through the Center for Medicare and Medicaid Services (CMS). A certified EHR is not required for fee-for-service payments.
The EHR needs for your organization will depend on both the services you offer and your payment model. If you’re accepting and billing insurance (Medicare or private pay), you need a system for billing and coding. If you’re cash pay only (and don’t have plans to accept insurance in the future), you have more flexibility and can focus on specific features your clinicians will need (like E-prescribing, documentation, or care plans, for example).
The not-so-secret truth about EHRs is that they’re designed more to optimize billing than to help providers deliver quality care. Managing the revenue cycle for large institutions like hospitals is incredibly complex, and for smaller practices, it’s often not something they have the staffing or bandwidth to support on their own. EHRs use standard billing codes to document encounters, enabling providers to submit their services for reimbursement, and many EHRs have specific features designed to maximize the reimbursement providers and institutions receive. Unfortunately, this focus on billing and coding means that the experience of using these tools to document clinical care is often sub-standard. In a 2019 study from Mayo Clinic where physicians rated the usability of their EHR tools, the average score was a 45.9 out of 100 (not great for tools that physicians can spend more than half of their day using).
The importance of an EHR and associated tools is amplified in a virtual care setting because clinicians will spend their entire workday in those tools and leverage asynchronous communication for many patient interactions. The experience that your care team has with their EHR and other care delivery tools has a direct impact on the quality of care they can provide. If those tools don’t support the workflows needed for virtual care, or if they don’t enable teams to easily collaborate, the patient experience will inevitably suffer. These two experiences are so closely tied, that virtual care companies should think of them as two parts of the same whole.
Given the importance of the tech stack for virtual care, the big question is, should I build custom clinical software or buy something off the shelf? One of the reasons so many companies choose to build is because legacy EHRs and clinical tools were not built for virtual care. They were built with the implicit assumption that patients and providers would be colocated whenever healthcare services are rendered. While the healthcare industry has rapidly moved past those assumptions (particularly in the past few years), it takes a long time for technology to catch up.
When considering your build vs buy strategy, there is of course no one answer that will apply to all organizations. However, there are a few key points we should remind ourselves along the way:
One of the most exciting parts of virtual care models is the ability to iterate and expand rapidly. When you aren’t dependent on physically building a new clinic every time you want to expand your services, you can reach patients faster. And when you aren’t ingrained in the “traditional” methods of care delivery, you can adapt your services and experience to meet your patients needs. Along with that rapid ability to grow and change comes the challenge of quickly scaling your technology to meet those needs. Regardless of whether you build, buy, or end up with a hybrid, focus your time and energy on the areas that drive value for your patients and will serve their long term needs.
The reality of the situation is, this exact dilemma is why we’re building Source. Up until now, most virtual care companies have built their tech stack from scratch, because there was no other viable option for them. Legacy EHRs are expensive and very difficult to customize to your needs, so any investment of time and money trying to do so was a poor business decision. As a result, virtual care companies spend an inordinate amount of time building just the basic functions they need to stand up their operation. Besides the time investment, building from scratch also means you have to choose between investing in the patient-facing experience or the clinical experience, or focus on very specific problems that face the business in the short term while under-investing in long-term solutions. These are not great trade offs.
At Source, we’re building a new stack for virtual-first care delivery. We know that each virtual care organization is unique, and wants to build a specific experience that best meets the needs of their patients. At the same time, most will face the same core challenges while building that experience. It’s why we built Source as a modular, API-first platform, so you can leverage the modules where it makes sense, build plugins, or customize workflows with our APIs. Of course, Source won’t be the right solution for everyone- you might have a novel care delivery model that isn’t supported by Source, or you might find another product that better fits your needs. At the end of the day, we’re excited to offer a new option for virtual care companies and hope to help accelerate the expansion of access to care and new approaches to care delivery.