FHIR Support and Maintenance Services

Agree in writing where maintenance ends and new development begins. Without that line, enhancement work silently consumes support capacity.

Generic uptime checks miss the failures that matter most in FHIR systems. Effective monitoring includes:

• Synthetic transactions that obtain a token and run representative searches end to end, not just a ping to `/metadata`.
• Tracking OperationOutcome issue codes and HTTP status distributions per counterparty, so one health system's failure is visible against the rest.
• Data freshness checks: when was the last resource received from each source?
• Profile validation sampling in production to detect drift in source data quality.
• Security signals: unusual token use, scope escalation attempts and access outside expected patterns, which also supports FHIR security obligations.

{
  "resourceType": "OperationOutcome",
  "issue": [{
    "severity": "error",
    "code": "invalid",
    "diagnostics": "Observation.status: minimum required = 1, but only found 0",
    "expression": ["Observation.status"]
  }]
}

Much of the value of a support partner is watching upstream change so you are not surprised by it.

• Implementation guide versions: US Core publishes new versions periodically, and certification programs and payer rules reference specific versions. Plan upgrades so supported versions match your obligations; see HL7's published US Core.
• EHR platform changes: EHR vendors release upgrades, deprecate API versions and change registration processes. Integrations with platforms such as Epic need regression testing around customer upgrade windows.
• Regulatory updates: ONC rules such as HTI-1 updated certification baselines, and CMS-0057-F introduces new payer APIs. A support partner should translate announcements into a dated backlog.
• FHIR server releases: security patches and new versions of the server product or open-source libraries.

SLAs should reflect clinical and business impact rather than generic IT severity. A failure that stops results reaching clinicians is different from a slow analytics export. Define:

• Severity levels with concrete FHIR examples for each, agreed by both parties.
• Response and resolution targets per severity, and which hours they apply to.
• Escalation paths, including who contacts EHR vendors and health system IT on your behalf.
• Availability targets for any service the partner hosts, and how they are measured.
• Monthly reporting: incidents, root causes, upcoming upgrades and capacity trends.

If a different firm built your system, a transition period with documentation review and shadowing is essential. Questions to ask:

• How do you onboard a system you did not build, and how long before you can take full responsibility?
• Which EHR and IG changes are you tracking for our stack in the next year?
• Can you show a sample monthly support report and an incident post-mortem?
• What is included in the base fee, and how are enhancements estimated and approved?
• Do you have staff with FHIR expertise on call, or only general application support?

Systems built through FHIR integration or EHR/EMR integration projects typically move into this kind of agreement after hypercare.

Common structures are a monthly retainer covering a defined scope and hours, tiered plans differing by coverage hours and response targets, per-connection or per-site fees for integration support, and time-and-materials for enhancements beyond the retainer. Cost drivers include the number of integrations and sites, coverage hours, response targets, hosting responsibility and the volume of expected upstream change.