HL7 FHIR Consulting Services

Consulting pays off when the expensive mistakes would be made early. Common triggers:

• You have a regulatory obligation (for example a CMS-0057-F API requirement) and need to know exactly what it requires of your systems.
• You are choosing between building a FHIR server, licensing one or using a managed cloud service, and want an independent comparison.
• A product team has started a FHIR build and leadership wants an external review before investing further.
• You need to define profiles or an implementation guide for a network, registry or partner program.
• Your engineers know REST but not FHIR, and you want structured training and design reviews rather than outsourced delivery.

If you already know what to build and need hands on keyboards, a delivery engagement such as FHIR implementation is a better fit. Many firms offer both, which is worth knowing when you assess independence (see below).

Much FHIR consulting in the US is driven by regulation. A competent advisor should be able to connect each rule to concrete technical artifacts without overstating what the rule requires.

• ONC certification and HTI-1: the (g)(10) standardized API criterion, the US Core and SMART App Launch versions in the current certification baseline, and USCDI data classes. Details are published on HealthIT.gov.
• CMS Interoperability and Patient Access (CMS-9115-F): Patient Access and Provider Directory APIs for impacted payers.
• CMS Interoperability and Prior Authorization (CMS-0057-F): Provider Access, Payer-to-Payer and Prior Authorization APIs, with Da Vinci IGs (CRD, DTR, PAS) recommended for the prior authorization workflow. Rule text and timelines are on CMS.gov.
• Information blocking: practices that could interfere with access, exchange or use of electronic health information, and the defined exceptions.
• TEFCA: participation via a Qualified Health Information Network and how FHIR-based exchange fits that framework.

1. Framing: agree on the decision or question the engagement must answer, and who will act on it.
2. Evidence gathering: stakeholder interviews, system inventory, review of existing interfaces, CapabilityStatements and data samples.
3. Analysis: gap analysis against target IGs, architecture options, risk assessment.
4. Validation: a short proof of concept or prototype where a recommendation depends on an assumption that can be tested cheaply.
5. Recommendation and roadmap: written findings, sequencing, and estimates of effort ranges for follow-on work.

Strategy and readiness assessments are usually short, time-boxed engagements. IG authoring and fractional architecture support run longer and are often retained on a monthly basis.

The FHIR consulting companies directory lists firms that advertise advisory services. When you interview them, focus on depth and independence:

• Which implementation guides have your consultants authored or contributed to, and can we see them?
• Who exactly will do the work, and what hands-on FHIR delivery have they done?
• Do you resell or partner with any FHIR platform you might recommend to us? How do you disclose that?
• Show us an anonymized gap analysis or architecture review you have delivered.
• How do you separate what a regulation requires from what is merely recommended or common practice?
• If we hire you for implementation afterwards, how do you avoid recommending work that favors your own delivery team?

Consulting is usually priced as fixed-fee assessments with a defined deliverable, daily or hourly rates for advisory time, or a monthly retainer for ongoing architecture guidance. The main cost drivers are scope breadth (one API versus enterprise strategy), the number of systems and stakeholders involved, and whether a hands-on prototype is included. Ask for a written statement of the decision the engagement will enable; it is the best protection against open-ended advisory spend.