Solutions for Healthcare
When patients need care, the platform is part of the care.
The website is how patients find care, schedule care, and reach care at 2am. When it fails, the institution fails them. Patients do not differentiate between the technology and the institution that operates it. The platform is part of how care is delivered, and it has to hold up at the moments patients need it most.
What is managed WebOps for healthcare?
Managed WebOps for healthcare is the engagement category in which a single partner takes continuous operational responsibility for an organization's digital platform. eWay Corp engages with healthcare organizations in two distinct models. In the first model, eWay operates the public web layer (CMS, cloud infrastructure, patient-facing portals) and integrates with the customer's existing EHR systems (Epic, Cerner, Allscripts, Meditech) through APIs that preserve PHI scope inside the covered systems. In the second model, eWay designs, builds, and continuously operates custom clinical platforms, including custom EMR, case management, patient portals, and ePrescription integration, under BAA for organizations whose operating model does not fit commercial EHR. In that second model eWay is the accountable covered-system operator. Free Clinics of Iowa and Pacent Solutions are examples of the second model. Both models maintain HIPAA, Section 1557, Section 508, Title II, and NIST 800-53 compliance posture as continuous operational practice. Engagements are designed to survive M&A integration cycles, vendor transitions, and post-breach security reviews.
What you are dealing with
Specific healthcare realities.Not generic public sector challenges.
These are the four pressures most healthcare CIOs, marketing directors, and patient experience leaders describe to us in the first conversation. We have been in enough rooms with people in your position to describe them precisely.
The breach landscape, not the compliance story
Healthcare is the most-attacked sector in the United States by a significant margin. HHS OCR settled more than forty HIPAA enforcement actions in 2024. Ransomware attacks on hospital systems have delayed surgeries and diverted ambulances. Patient-facing web properties are part of the attack surface: unpatched CMS vulnerabilities, third-party JavaScript on healthcare pages used for credential harvesting, misconfigured access controls on patient portal integrations. Cybersecurity in healthcare is not a compliance question. It is operational continuity and patient safety.
Three frameworks intersecting at the web platform
HIPAA governs protected health information. Section 1557 of the ACA prohibits discrimination in health programs and requires language access and accessible communications. Title II of the ADA requires accessible digital services for government health entities. For most healthcare organizations all three apply simultaneously, and they intersect at the web platform layer. A Section 1557-compliant patient portal needs language access services. A Title II-compliant health agency site needs WCAG 2.1 AA. A HIPAA-compliant integration needs PHI to stay out of the CMS. The web platform is the surface where the three frameworks meet, and the partner has to understand all three together.
Patient acquisition before clinical encounter
Patients now choose providers based on digital experience before they ever enter a clinical setting. A health system whose website is slow, inaccessible, or hard to navigate loses patients to competitors with better digital front doors, even when the clinical quality differential favors the first system. Research consistently shows patients conflate digital experience quality with clinical competence. This is not a satisfaction story. It is a direct revenue impact and a patient acquisition story that the marketing VP and the CFO both understand.
Margin pressure that constrains every choice
Healthcare margins compressed since 2020. Health systems running on three-to-four percent operating margins are now running on one-to-two percent or negative. Capital is constrained. Every technology investment is being evaluated against tighter return requirements than four years ago. Health systems running on compressed margins cannot maintain the internal web platform teams that effective governance requires. Internal staffing at healthcare IT salary levels costs more than a managed engagement. That math is the argument for managed services in healthcare right now, and margin pressure is the context that makes it land.
Patients do not experience website failures. They experience the institution failing them.
Where we operate
Healthcare organizations we have built solutions for
From the largest free clinic network in Iowa to academic medical centers and county behavioral health platforms.
Free Clinics of Iowa
EMR, patient portal, and ePrescription on Microsoft Azure. 34 clinics, five phases of continuous evolution since 2017.
Read case studyUNM Health Sciences
Academic medical center, managed platform operations.
Read case studyPacent Solutions
Wound care platform across home care, skilled nursing, hospice, and virtual clinics.
Polk County Crisis and Advocacy
Behavioral health and crisis advocacy platform, county-administered.
Read case studyThree buyer perspectives
Healthcare buying committees are not single buyers.Three buyers, three concerns, one platform engagement.
A healthcare platform decision typically involves the technology and operations leader, the marketing and communications leader, and the patient experience leader. At a free clinic or community health organization, those three perspectives may live inside a single executive director. The framing speaks to both.
Technology and Operations
When you are responsible for a platform that must meet HIPAA, hold up at the moments patients need it most, and operate within a budget that does not allow for full internal management.
Technology and Operations
When you are responsible for a platform that must meet HIPAA, hold up at the moments patients need it most, and operate within a budget that does not allow for full internal management.
You inherited a CMS, an integration layer, and a security review backlog. Your team is a small group of generalists who know healthcare well enough to be useful and not deeply enough to be specialists in everything the platform demands. Your last vendor disappeared after go-live. Your security review process takes months. Your board has been asking harder questions about vendor risk since the last sector-wide breach made the news. The platform is not a project you can hand off. It is an institutional asset that needs an accountable operator who understands healthcare without claiming to do everything.
Marketing and Communications
When the digital presence is your primary patient acquisition channel and your primary brand expression, but it is managed reactively rather than strategically.
Marketing and Communications
When the digital presence is your primary patient acquisition channel and your primary brand expression, but it is managed reactively rather than strategically.
The website is the highest-traffic entry point for prospective patients, families, referring providers, and the community. Yield depends on what they experience there. Your team owns the content, the messaging, and the campaign work, but every change to the platform requires IT involvement, every campaign launch involves negotiating with the development queue, and every accreditation cycle exposes the gap between what you publish and what your stakeholders see. You need the platform to behave like a marketing channel, not like an IT project that you happen to publish through.
Patient Experience and Access
When the patient relationship begins through the website, before any clinical encounter, and the experience there shapes whether patients trust the care that follows.
Patient Experience and Access
When the patient relationship begins through the website, before any clinical encounter, and the experience there shapes whether patients trust the care that follows.
Patients form their first impression of the institution through digital touchpoints: the appointment scheduler, the patient portal, the new-patient onboarding flow, the after-hours information page. That impression affects whether they schedule, whether they complete intake, whether they trust the care they receive. A friction-filled portal does not just frustrate patients. It reduces care adherence, damages the patient relationship, and shifts loyalty to competitors with better digital experiences. The work of the patient experience function is to make the digital touchpoints reflect the institution's clinical standards. The platform either supports that work or undermines it.
Three roles, one engagement, one accountable team. The same platform serves the technology leader's need for operational continuity, the marketing leader's need for a platform that supports campaigns, and the patient experience leader's need for digital touchpoints that reflect institutional standards.
Proven in production
Free Clinics of Iowa.Five phases of continuous evolution since 2017.
The largest network of free medical clinics in Iowa, serving underserved populations across 34 clinic locations. Most clinics have a static website. FCI's platform is the operational system through which the network's care is delivered, scheduled, and reported. eWay has continuously evolved that platform across five phases since 2017.
FCI's previous EMR could no longer meet security, usability, or compliance requirements. eWay rebuilt it from the ground up on ASP.NET MVC with N-tier architecture, then continuously evolved the platform through five phases since 2017: adding patient-portal capability, integrating DoseSpot ePrescribing, layering in Telerik-based compliance reporting, and scaling Azure infrastructure for distributed clinic operations. eWay holds the BAA and is the accountable operator of the clinical platform. PHI lives inside the systems eWay built, with architectural boundaries between clinical, administrative, and public surfaces designed in from the start.
What we built
- Custom EMR engineered from the ground up on ASP.NET MVC with N-tier architecture
- Patient portal with self-registration, intake, and appointment workflows
- ePrescription integration via DoseSpot
- Compliance and operational reporting via Telerik Reports
- Microsoft Azure infrastructure, scaled for distributed clinic operations
- Public-facing access for clinic discovery and service information
The engagement posture
- Continuous engagement since 2017, evolving across five phases
- Same engineering team across the duration of the relationship
- BAA-bearing operator of the clinical platform
- Architectural boundaries between clinical, administrative, and public surfaces
- Architecture and integration documentation maintained throughout
- Mission-driven engagement model with no proprietary lock-in
How we engage with your clinical stack
Two engagement models.Both with one accountable team.
Healthcare organizations come to us in one of two postures. Either you have a major EHR and you need the public web layer plus the integrations into it, or you need a clinical platform built from scratch because no commercial EHR fits your operating model. We operate both.
Model A
You bring the EHR. We operate the web layer.
For health systems and academic medical centers running Epic, Cerner, Allscripts, Meditech, or similar. PHI stays inside your covered systems. We do not touch your EHR. We operate the public-facing platform and the integrations into it.
What we own
- Public-facing Cascade, Drupal, and WordPress environments
- AWS and Azure infrastructure
- Patient-facing portals, clinic-discovery surfaces, and identity federation (SSO, SAML, OIDC, ADFS)
- API gateways and integration layers into your EHR (Epic, Cerner, Allscripts, Meditech)
- ePrescription endpoints (DoseSpot, Surescripts), language-access services, and telehealth scheduling
- Managed WebOps across the full stack
PHI stays inside your covered systems. The web layer handles session, authentication handoff, and presentation. The boundary is architectural.
Model B
We build the clinical platform. And we operate it.
For free clinics, community health networks, behavioral health programs, and specialty providers where commercial EHR does not fit and you need a platform engineered for your operating model. We hold the BAA. We are the accountable covered-system operator.
What we build and operate
- Custom EMR engineered to your clinical workflow
- Case management systems for behavioral health, advocacy, and community-care contexts
- Patient portals with self-registration, intake, and appointment workflows
- ePrescription integration (DoseSpot, Surescripts)
- Compliance and operational reporting (Telerik Reports and similar)
- AWS and Azure infrastructure under continuous operation
We hold the BAA. PHI lives inside the systems we built and operate, with architectural boundaries between clinical, administrative, and public surfaces.
Both models share the same operating discipline: a small named team, multi-year continuity, defined SLAs, and the same engineers across phases. Free Clinics of Iowa and Pacent Solutions are Model B engagements.
Compliance posture
Healthcare compliance is not a checklist.It is the operational reality of running a regulated platform.
HIPAA, Section 1557, Section 508 + Title II, and NIST 800-53 all apply to most healthcare web platforms simultaneously and they intersect at the platform layer. Each card below names the framework, our role within it, and where the boundary sits.
HIPAA: posture depends on the engagement model
When integrating with your existing EHR (Epic, Cerner, Allscripts, Meditech), PHI stays inside your covered systems. The web layer handles session, authentication handoff, and presentation. We do not touch your EHR. When we build and operate a custom clinical platform (EMR, case management, patient portal), we hold the BAA and we are the accountable covered-system operator. PHI lives inside systems we built, with architectural boundaries between clinical, administrative, and public surfaces. The BAA is a standard part of the engagement, not a separate legal negotiation.
Trust Center documentationSection 1557 language access
Section 1557 of the ACA prohibits discrimination in health programs receiving federal financial assistance. The web platform dimension is language access for limited English proficiency populations and accessible communications for people with disabilities. We design content modeling, translation workflows, and language toggles that satisfy 1557's web requirements. Your federally funded health program does not get exposed by an inaccessible patient portal.
Accessibility Compliance serviceSection 508 and Title II
Public hospitals, academic medical centers, and health agencies that are government entities are subject to Section 508 and Title II of the ADA on top of Section 1557. WCAG 2.1 AA is the technical standard that satisfies the accessibility obligations of all three frameworks at the web platform layer. Accessibility is built into every implementation and maintained as the platform evolves. The DOJ April 2026 deadline is not a project for us. It is a baseline.
Accessibility Compliance serviceNIST 800-53 cyber framework alignment
Healthcare's breach landscape made NIST alignment a vendor evaluation question, not just an internal IT discipline. We architect AWS and Azure environments to align with NIST 800-53 controls, and we provide the documentation a healthcare CISO will request as part of a security review. The aligned-versus-authorized distinction matters and we state it directly. eWay is not FedRAMP authorized. Our infrastructure is FedRAMP-aligned. A healthcare CISO demonstrating NIST alignment for board reporting can point to our posture as supporting evidence.
Common Questions
What healthcare buying committees ask us
You manage healthcare web platforms. Does that mean you have access to patient data?
No. eWay operates the web platform layer. Our platforms are designed so that PHI does not transit through or reside in the CMS. Patient portal integrations connect to your EHR or patient data systems through APIs that keep PHI inside your covered systems. The web layer handles the session, the authentication handoff, and the user interface. It does not see the data behind it. That boundary is architectural, not just policy. We design every healthcare engagement so the web platform stays outside the PHI scope your covered entity infrastructure is already responsible for.
Do you sign a Business Associate Agreement?
Yes. The BAA is a standard part of our healthcare engagement process, not a separate legal negotiation that has to be renegotiated each time. The agreement covers the limited operational context in which our platform operations could be adjacent to PHI, the security controls that govern that context, and the breach notification process if scope is ever materially expanded. We execute the BAA before the engagement begins. If your legal team has a preferred BAA template, we will work from yours rather than insisting on ours.
We use Epic for our patient portal and Cerner for clinical data. What does your engagement touch and what does it not touch?
We do not implement, configure, integrate within, or manage Epic, Cerner, or any other EHR system. The web platform we operate sits in front of these systems and connects to them through published APIs and integration standards. The integration we build and maintain is the connection between the patient-facing web experience and the authentication or scheduling layer the EHR exposes. What is behind that layer (clinical data, billing records, care plans, encounter notes) is entirely outside our scope and always has been. Your EHR vendor and your clinical IT team own that surface. We own the web platform that sits on top of it.
What is the difference between Section 1557 and Title II, and how does your platform address both?
Section 1557 of the Affordable Care Act prohibits discrimination in health programs receiving federal financial assistance and requires meaningful access for people with limited English proficiency along with accessible communications for people with disabilities. Title II of the ADA requires accessible digital services for entities that are government entities or that operate government programs. Many health departments, federally qualified health centers, public hospitals, and academic medical centers receiving federal funding are subject to both simultaneously. The web platform addresses both through WCAG 2.1 AA conformance as the technical standard that satisfies the accessibility requirements of each framework, plus language access considerations in the content modeling and UX design layer for Section 1557 (translation workflows, language toggles, alternative format support).
We had a ransomware incident last year that affected several systems. Our board is now asking harder questions about every vendor we bring in. What does your security documentation look like?
We provide NIST 800-53 aligned controls documentation, the security architecture documentation for the workloads we operate on AWS and Azure, our penetration testing cadence, patch response windows by severity level, our incident response plan, our data handling practices, and the specific controls that govern our access to your web platform environment. This documentation is available at any stage of the procurement process, not only after contract execution. Your information security officer should not have to wait until the SOW is signed to evaluate our posture. On the post-breach concern specifically: our web platform engagement is scoped to the web layer and designed to minimize the attack surface your team is responsible for monitoring, not expand it. We do not introduce new privileged access paths into your covered systems or your EHR environment.
How does your platform handle a traffic surge during a public health emergency or a community health event?
The platform is architected for unplanned surges, not just predicted ones. Auto-scaling infrastructure on AWS or Azure responds to traffic increases automatically without manual intervention. CDN configuration is tuned for the publishing patterns your communications team uses during emergencies, multiple stakeholders pushing critical content simultaneously to a public-facing platform that is suddenly carrying ten times its normal traffic. The on-call engineer is available within fifteen minutes of an unexpected event, not the next business day. We test the platform against the historical surge pattern for relevant events before they happen, and we monitor through the window with the engineer who built the architecture on call. The COVID-19 information page that went down during a surge announcement, the urgent care wait times page that was unavailable during a flu season spike: those failures were not unavoidable. They were preventable, and the platform we operate is designed to prevent them.
We are in the middle of integrating two health systems after a merger. We have three separate web presences, two CMS platforms, and a governance model that does not yet exist. Can you help with that?
Yes, and post-merger digital integration is one of the more common engagement starting points in healthcare right now. The technical work is real: two CMS platforms to be rationalized, content models to be merged or rebuilt, integration contracts to be re-evaluated against the new system landscape, brand standards to be harmonized. What matters more is the political work alongside it. Two health systems that just merged have two communications teams, two brand histories, two sets of stakeholder expectations, and two sets of patient-facing content that need to become one coherent presence. We approach platform consolidation with an assessment process that surfaces the technical and political dimensions together, a migration plan that respects the timeline of the broader merger integration program, a governance model designed jointly with both communications teams, and a phased consolidation that does not disrupt patient access during the transition. We have done this. We will not pretend it is purely a technical migration problem.
Our last web platform partner built something we could not maintain without them. What happens if we need to transition away from eWay?
The platform documentation, the architecture decisions, the integration contracts, and the operational runbooks are documented during the engagement, not at the end of it. If you transition to another vendor or bring operations in-house, the next team has what they need to take over without rebuilding institutional knowledge from scratch. We provide knowledge transfer support during the transition period as part of the engagement, not as an extra-cost add-on. The platform is built on standard open source and cloud technologies, no proprietary lock-in, no custom build that only our engineers understand. We do not hold institutional knowledge as leverage. Your platform stays operational through the transition. We will hand off cleanly because that is the engagement model we sell, not just the engagement model we describe in our proposal.
Evaluating an engagement?
Schedule a conversation about your patient-facing platform.
30 minutes with the engagement manager who would lead your project, not a sales rep. We will walk through your current platform, where the PHI boundary sits, what your compliance posture looks like, and what the first 90 days would look like under a managed engagement.