doctor
Source: Unsplash

Most discussions about expanding healthcare access focus on the technology: the platform, the interface, the clinical features. That focus is understandable. Technology is visible and demonstrable in ways that the systems surrounding it are not. But for founders who have spent time building companies in regulated healthcare environments, the technology tends to be the more tractable part of the problem. What determines whether a platform reaches patients at scale is what gets built around it.

Justin Fulcher has spent almost two decades working on that surrounding layer as a private sector technology founder operating across multiple continents and regulatory environments. That experience produced a specific view of where the real difficulty in healthcare access lies, and it is not in the clinical features or the user interface.

What Healthcare Infrastructure Actually Means

When Justin Fulcher uses the word infrastructure in a healthcare context, he is not referring to buildings or broadband. He is referring to the compliance frameworks, data governance structures, institutional integration points, and workflow configurations that determine whether a platform can function inside a real clinical or government environment.

For RingMD, that meant:

  • FedRAMP Moderate authorization (built according to NIST 800-53 guidelines), subject to continuous monitoring and annual audits by a certified third-party assessment organization.
  • FISMA compliance and HIPAA compliance, with the platform running on AWS infrastructure under a Business Associate Agreement with Amazon Web Services.
  • Building integration support for electronic health records, electronic medical records, electronic prescribing systems, and laboratory information systems.
  • Engineering specifically for low-bandwidth and rural connectivity environments, where standard assumptions about network performance do not hold.

It also meant configuring the platform to align with agency-specific clinical workflows and branding requirements — not shipping a standard product and asking institutions to adapt around it, but building the configurability in from the start so that the platform could fit what institutions were already doing.

Product launches and funding announcements tend to lead with clinical features and user experience, with compliance and integration work typically getting less attention. But it is what institutional clients require before a platform can be seriously evaluated.

Why the Technology Tends to Come First

The sequencing many technology founders use when entering healthcare is product first, compliance and integration later. That sequence has a logic to it: proving clinical value before investing in the regulatory infrastructure required to deliver it at scale is a reasonable way to manage early-stage risk. Many platforms that take this approach build genuinely useful products.

The limitation shows up when those platforms try to move from pilot relationships to institutional contracts. Government agencies, hospital systems, and federal health programs operating in regulated environments cannot adopt a platform that does not meet their security and regulatory requirements, regardless of what else it offers. The compliance and integration work becomes the primary condition for progress. And at that stage, building it could take longer and cost more than it would have earlier.

"People treat compliance like a feature you bolt on once the product is proven," the South Carolina native has said. "In regulated environments, it doesn't work that way. Compliance is the foundation that the product is built on as well as the mechanism that enables accountability."

The distinction matters because it changes the build sequence. Treating compliance as foundational rather than as a later-stage addition means the architecture looks different from the beginning. It also means that when an institutional client evaluates the platform, the prerequisite work is already done.

How Justin Fulcher Applied This in the Private Sector

RingMD's compliance infrastructure was not assembled in response to any single contract requirement. It was built because operating across regulated environments simultaneously required that foundation to be in place before any individual contract could even be discussed.

That sequencing became visible in 2021, when the Indian Health Service awarded RingMD its first dedicated telehealth services contract. The contract covered approximately 2.6 million American Indian and Alaska Native individuals across 24 hospitals and 51 clinics in 37 states.

The platform's low-bandwidth engineering, developed through years of operating in real-world conditions across rural and remote environments in Southeast Asia, was directly applicable to the connectivity conditions those communities faced. IHS Director Roselyn Tso noted at the time that the expansion would increase access to care, patient safety, continuity of care, and patient satisfaction.

That contract was possible because the architecture had been built and tested before the contract was on the table. The compliance work, the rural connectivity engineering, the workflow configurability — all of it preceded the institutional relationship rather than being built on top of it.

RingMD's platform -

  • supported integration with EHR, EMR, and laboratory systems
  • included built-in analytics and reporting for operational oversight and utilization tracking
  • offered artificial intelligence-enhanced clinical decision support and screening modules built to federal privacy and security standards

The platform could be deployed and operational within 72 hours. That deployment speed was itself a product of infrastructure investment: the configurability that made rapid rollout possible had to be engineered in advance.

The Same Problem in a Different Domain

When Fulcher moved into public service in Washington, first at the Department of Veterans Affairs as a founding member of the Department of Government Efficiency, then as senior advisor to Defense Secretary Pete Hegseth at the Defense Department, the structural problem he encountered was recognizable to most people who had spent time as a public sector advisor working at the intersection of technology and institutions. Core systems in high-stakes environments were running on outdated processes. That's a symptom of institutional drag.

This exposed a gap between what the technology could deliver and what the existing institutional infrastructure would permit. The stakes were different: national security rather than patient access, and America's defense budget rather than a platform contract, but the underlying dynamics were the same.

"The domain was different, but the structure of the problem was the same," Justin Fulcher has said when reflecting on his time in public service.

The technology founder's approach in both institutions followed the pattern he had developed while building companies: understand the operational reality before redesigning the system. At the VA, that meant interviewing staff and reviewing programs to build an accurate picture of how the institution actually functioned. At the Defense Department, it meant focusing on acquisition reform and IT modernization initiatives, working to compress software procurement timelines that had previously been measured in years.

The lesson from healthcare translates directly: you cannot build usefully on top of a system you have not accurately understood. The unglamorous work of mapping existing workflows, identifying integration requirements, and building compliance in from the start is what makes the more visible work possible.

Fulcher has written that America is a superpower running on legacy software, and the defense and veterans systems he encountered bore that out directly.

What the Industry Still Has to Solve

Telehealth has demonstrated that it can reach patients. The infrastructure question, whether it can integrate durably with everything else that patient care requires, is less settled.

Justin Fulcher has been direct on this point: "Telehealth proved it could reach patients. The test now is whether it integrates with everything else that patient care requires: labs, records, referrals, the full coordination infrastructure."

Platforms that addressed the access problem without building toward that integration are likely to find the next phase more difficult than the first. The pattern Fulcher identified early, that the technology is rarely the binding constraint and that the surrounding infrastructure is where the durable work happens, hasn't changed.

Building a product that can function inside an institutional environment requires understanding that environment in detail, meeting its real-world constraints before being asked to, and treating the unglamorous foundational work as the competitive work. That has been Fulcher's approach across healthcare, and it is the approach he has carried into every regulated environment he has operated in since.

In healthcare, the technology finally arrived years before the infrastructure caught up with it. The future belongs to builders who close that gap.