The FHIR Maturity Model (FMM) is a formal rating system used by HL7 to communicate the development stability of a FHIR resource or artifact. Each level, from FMM 0 (Draft) to FMM 5 (Normative), corresponds to specific criteria regarding the artifact's maturity, including the number of independent implementers, successful interoperability testing at connectathons, and the resolution of substantive community comments. It provides a clear signal to implementers about the risk of future breaking changes.
Glossary
FHIR Maturity Model (FMM)

What is FHIR Maturity Model (FMM)?
The FHIR Maturity Model (FMM) is an HL7-defined framework that assigns a level from 0 to 5 to each FHIR resource, indicating its stability and readiness for production use based on community testing and implementation experience.
Advancement through the FMM levels is governed by a formal FMM rubric that requires objective evidence. For instance, reaching FMM 2 (Tested) requires successful testing by at least two independent organizations, while FMM 4 (Trial Use) mandates publication in an official HL7 ballot and implementation across multiple domains. Only resources that have been locked down and proven in wide-scale production can achieve FMM 5, signifying they are considered a normative part of the specification and will not undergo backward-incompatible changes.
FHIR Maturity Model Levels
The progression of a FHIR resource from draft to normative standard, as defined by HL7's FMM levels.
| FMM Level | Designation | Required Criteria | Production Readiness |
|---|---|---|---|
0 | Draft | Resource has been published on the current build site. No formal review has been conducted. | |
1 | FMM 1 | Resource satisfies all FHIR design quality criteria and has been presented to the community for review. | |
2 | FMM 2 | Resource has been tested and successfully supports interoperability across at least three independently developed systems using semantic testing. | |
3 | FMM 3 | Resource has been verified by the community as meeting the 'trial use' quality guidelines and has been subjected to round-trip testing across multiple scopes. | Trial Use |
4 | FMM 4 | Resource has been formally published and tested across its entire scope. All known security and privacy risks have been documented. | Trial Use |
5 | FMM 5 | Resource has been implemented in at least five independent production systems across more than one country and has been balloted as a normative standard. | Normative |
Frequently Asked Questions
Clear answers to common questions about the FHIR Maturity Model (FMM), the HL7 framework that assigns stability levels to FHIR resources based on real-world testing and implementation feedback.
The FHIR Maturity Model (FMM) is an HL7-defined framework that assigns a numeric level from 0 to 5 to each FHIR resource, indicating its stability, completeness, and readiness for production use based on the breadth of community testing and implementation experience. FMM 0 represents a draft resource with no real-world testing, while FMM 5 signifies a resource that has been tested across at least five independent production systems in multiple countries. The model provides implementers with a clear signal about the risk associated with adopting a particular resource, allowing them to make informed architectural decisions. Unlike a formal standard, FMM is a normative indicator of maturity, not a guarantee of future compatibility. Resources at FMM 1-3 are considered trial use, while FMM 4-5 approach normative status, meaning subsequent changes must be backward-compatible.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Key Characteristics of the FHIR Maturity Model
The FHIR Maturity Model (FMM) is an HL7 framework that assigns a level from 0 to 5 to each FHIR resource, indicating its stability and readiness for production use based on community testing and implementation experience.
FMM 0: Draft
The resource has been published on the current build but is purely a draft. It has not been tested across any systems and is subject to significant change or removal. No interoperability is expected at this level.
FMM 1: FMM 1
The resource meets basic draft quality criteria. It has been scanned for obvious issues but has no real-world implementation testing. The scope is still fluid, and backward compatibility is not guaranteed.
FMM 2: FMM 2
The resource has been tested and successfully supports interoperability among at least three independently developed systems. Most core issues have been resolved, but it may still undergo non-backward-compatible changes based on implementer feedback.
FMM 3: FMM 3
The resource is considered mature and ready for production use. It has been verified by the sponsoring work group as conforming to quality guidelines. Changes are now expected to be backward-compatible, and the scope is largely fixed.
FMM 4: FMM 4
The resource has been tested across its full scope and published in a formal HL7 publication (e.g., a normative edition). It has been implemented in multiple prototype projects and is considered stable for widespread adoption.
FMM 5: Normative
The resource has been locked down as a normative standard. It has been implemented in at least five independent production systems in at least two different countries. Future changes are strictly limited to backward-compatible corrections and clarifications.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us