Today’s presenter is John Ramsey, Chief Enterprise Architect at Patagonia Health.
John’s role is to engage with customers, developers, and other members of our leadership team to facilitate development improvements and add new features to our software—always with the customer at the center of everything we do.
Without further delay, I’ll hand it over to John.
John Ramsey:
Good morning, or good afternoon, depending on where you are. As Monique mentioned, I am the Chief Enterprise Architect at Patagonia Health. I’ve been working in software development and support since the mid-1990s, and even before that informally. I’ve worked with both large and small companies in roles including support, development, product management, and business analysis—all centered around software development.
I’ve also worked as an independent consultant helping startups build SaaS (Software as a Service) applications from database to front end. I earned my MBA in 2011 and still maintain an active academic interest in the innovation process, working with organizations in the Research Triangle Park region to support entrepreneurship.
I’ve been in healthcare software since 2007—first in clinical trials, then in backend systems using Medicaid data for community health decision support. For the past two years, I’ve been with Patagonia Health, though I’ve followed the company since it was founded in 2008 and have known the founders since that time.
Patagonia Health’s Approach and Design
Patagonia Health was founded in 2008 and has been creating electronic health records using a user-centered design approach from the very beginning. I met Abe, our CTO, in 2008, and I know firsthand that this philosophy is part of our company’s DNA.
Our system is not only easy to use but has continually improved since 2009. We offer a powerful, affordable, and flexible solution organized into three main areas:
- Practice Management
- Electronic Health Records (EHR)
- Billing
Within the EHR, we include both patient-level and broader program contexts, along with robust reporting. This modular architecture makes it easy to configure, expand, and personalize the system to customer workflows.
Why Flexibility Matters
Our customers range from public health departments to FQHCs and behavioral health organizations. Each has different needs. Software as a service (SaaS) offers several benefits—it’s more affordable, easier to maintain, and allows IT teams to focus on infrastructure while we handle updates and security.
The system is highly customizable. Users can enable or disable certain “apps” depending on their role or workflow. For instance, one user may only need immunization and vitals apps, while another needs additional program modules.
This flexibility allows us to add new features for specific customers without affecting existing users.
Configuration and Continuous Improvement
Configuration plays a key role in our process. It lets us:
- Turn features on or off per user.
- Pilot new features before full release.
- Test changes safely and iteratively.
We release updates every six weeks. This continuous delivery cycle allows us to test, collect feedback, and refine new features quickly. Pilot users help us verify functionality before wider rollout.
For example, users connected to a state immunization registry may see additional buttons in their immunization widget that are hidden for users without that connection. This ensures a clean, user-specific interface.
Balancing Flexibility and Usability
Our EHR isn’t a rigid system, nor is it a blank slate that forces users to build everything from scratch. Instead, it’s designed to balance flexibility with ease of use. Unlike older “file cabinet” style systems that required navigating endless menus, Patagonia Health provides clear, structured workflows tailored to user roles.
In cases where document-based workflows are required—like Michigan’s Maternal and Infant Health Program—we support that structure while still offering electronic efficiency.
User-Centered Design in Practice
This diagram (borrowed from Wikipedia) captures the essence of user-centered design: it’s messy and iterative. The process involves ongoing collaboration between customers and developers, with frequent feedback loops.
Typically, our projects go through about three six-week release cycles—roughly 18 weeks from concept to live implementation for a medium-sized project.
Our Development Process
Our process follows a consistent cycle:
- Requirements Gathering:
- Analysts meet with customers to understand workflows and collect necessary documents and reports.
- We travel onsite whenever possible to observe real usage and ensure accuracy.
- Reporting needs are discussed early to ensure proper data collection.
- Analysts meet with customers to understand workflows and collect necessary documents and reports.
- Mockups and Design:
- Using tools like Balsamiq, we create quick visual mockups to confirm functionality and layout before development begins.
- These mockups are reviewed by users and refined based on their feedback.
- Using tools like Balsamiq, we create quick visual mockups to confirm functionality and layout before development begins.
- Development and Testing:
- Developers build the approved designs, guided by the mockups and documentation.
- Test versions are shared with customers for validation.
- Developers build the approved designs, guided by the mockups and documentation.
- Release and Feedback:
- After deployment, we require active user feedback within the first few weeks.
- Changes are incorporated into the next six-week cycle for rapid improvement.
- After deployment, we require active user feedback within the first few weeks.
Examples of Collaborative Development
We’ve worked extensively with public health departments in North Carolina, building many early system features through collaboration with local user groups.
As we’ve expanded into other states like Michigan, we’ve adapted to state-specific programs and registry requirements. While immunization registries follow general standards, each state implements them differently, and we adjust accordingly.
Examples of collaborative projects include:
- Immunization enhancements – streamlined interfaces, barcode scanning, and integrated billing workflows.
- HIV and general case management – customized for clinical and non-clinical service coordination.
- Inventory integration – automating vaccine usage and billing records.
Each improvement stems from real customer input.
Release Cycle Overview
We release software updates every six weeks, continuously adding functionality since 2009. This means the system has grown steadily without interruption, ensuring modern, evolving tools for all users.
Q&A Session
Moderator:
Thanks, John. If anyone has questions, please type them into the questions box.
Question: Can you clarify whether the six-week release cycle includes app updates or all EHR components?
John: Everything except our billing system follows the six-week release cycle. Billing is on a separate schedule with its own release notes. Occasionally, small fixes or visual changes may go out between official releases.
Question: Do you do design and development work for non-customers or prospects?
John: Yes. We gather feedback from many sources—customers, support, testers, sales, and marketing. We also conduct feasibility studies on potential features before they’re requested. However, we only develop new functionality when there’s confirmed need from a customer or group of users.
Question: Are all apps available to all clients?
John: Generally yes, but some are priced separately or state-specific. For example, a Michigan-specific program app might only apply to that state, though another state could adopt it if desired.
