Build vs. Buy: How to plan healthcare software architecture

In order to determine an appropriate healthcare software strategy, it’s important to first clarify the role of digital technology in the overall patient experience. For most care delivery organizations, the primary value being delivered to patients is high-quality medical care.

Digital health technology may enable this care delivery or create an excellent patient experience, but the software itself is not the main product being sold.

As such, most provider organizations do not invest in full in-house technical teams the way that software companies do. When HTD works with a new client, our first step is to understand the unique value proposition of the health organization and where technology sets them apart from competitors. This begins with product discovery—a series of design thinking and technical workshops to align on the desired user experience and business priorities like budget limitations, speed of scale, contemplated partnerships, and security requirements.

Product discovery involves deep exploration of product vision, core use cases and capabilities, and the ideal tech stack to meet product needs. A key part of discovery is determining what features or capabilities can be achieved through existing third-party digital health solutions and where customization is key to unlocking value.

Discovery starts with a series of patient experience workshops to align on key user groups, user needs and behaviors, and desired user journeys. If needed at this stage, additional UX research can help fill in the gaps to identify and validate real pain points or missing health tech solutions in the market.

Teams then work together to narrow these user needs to core solutions that the digital product should provide. These are articulated through detailed user stories or epics that provide a blueprint for the overall medical software design. This stage may also include user flows or even low-fidelity wireframes to document the anticipated user experience with the product.

Once user stories and product functionality are finalized, features are grouped by functional components including non-functional requirements like integration options, customization capability, extensibility, etc.

Some functional areas and components could fall into:

• Workflow management
• Intake and onboarding
• Scheduling and availability
• In-app video consults
• SMS or email reminders
• ePrescriptions
• Charting
• Patient education resources

Though HTD specializes in designing and developing healthcare software, we don’t believe in reinventing the wheel. With a rich ecosystem of digital health SaaS products, there are often third-party solutions that can support functional areas and save time in the healthcare software development process. The key is understanding the full set of options in the market and evaluating how third-party solutions fit into the overall product strategy.

HTD analyzes third-party tools using a feature comparison matrix. The matrix compares solutions against the required functional areas identified in the exercises above. This analysis also takes into account non-functional areas such as:

• Security and compliance requirements: Do solutions offer appropriate levels of security required for future business partnerships? This may mean signing a Business Associate Agreement (BAA) with customers or achieving HITRUST certification.
• Interoperability capabilities: With information flowing between multiple parts of a software system, it’s important to understand the format of data and where manual standardization may be required.
• Tech specs: Teams review API documentation to fully understand product capabilities and the technical details required for implementation and integration.
• Customization capabilities: While no-code tools are a great way to get started, most organizations eventually “outgrow” solutions that cannot be adequately customized or branded.
• Community and vendor support: SaaS vendors have different levels of support, often correlated to subscription tier or payment model. It’s important to understand what this support looks like, especially if software issues or bugs could crucially affect system and organization performance.
• Pricing: Third-party software is often attractive because of the cost saved in building custom applications or features. However, it’s also important to analyze the pricing model and how costs scale with the business.
• Business stability: Any new external software components introduce risk into a software system. If product issues arise or—in the worst case—the SaaS company runs into problems, it’s important to know how disruptive it would be to replace that piece of the system. As we’ve seen with some of the recent startup failures in the digital health ecosystem, business leaders should carefully weigh confidence in third-party companies before building a system that relies heavily upon any one solution in the market.

The feature comparison matrix allows team members to compare the benefits and trade-offs of each third-party solution and predict how much development work is required to stand up the ideal system. This is a comprehensive way for determining the best healthcare software solution and what level of compromise is necessary between buying and building.

With the complete matrix in hand, HTD prepares a set of questions about specific features to validate usability with the vendors being evaluated. Workshops can involve a review of tech support options, case studies, and dry-run scenarios that are specific to the business use case.

This is also an opportunity to evaluate long-term maintenance costs of partnering with a third-party vendor. In addition to any subscription, licensing, or usage costs, it’s important to analyze what the hypothetical team would look like. There are both headcount and required skill considerations for keeping the new architecture running smoothly and evolving in a stable manner.

The discovery completes with a set of recommendations based on the analysis described above: HTD proposes a system architecture including any well suited third-party solutions along with projected operating cost, some of the pros and cons of each system component, and key considerations related to evaluated vendors.

We typically conclude discovery engagements with a final diagram of the system architecture which describes how each piece fits into the larger system and contributes to product capability.

US healthcare is complex, and often so are the software systems that support it. Expert teams like HTD can help businesses design systems that are highly configurable and scalable. HTD is committed to partnering with digital health solutions that are willing to look ahead and build new functionality required for the future, without wasting time reinventing the wheel. Ready to chat through planning, designing, and developing healthcare software that empowers people? Get in touch today.