Updated for 2026. Healthcare organizations rely on multiple technology systems to manage patient information. Electronic Health Records (EHRs), hospital information systems, laboratory platforms, care management applications and clinical communication systems often need to exchange information to support coordinated patient care.
For healthcare practices delivering Chronic Care Management (CCM), interoperability is especially important because care coordinators and providers frequently need information from multiple clinical sources.
Three important healthcare interoperability standards are HL7 FHIR, HL7 Version 2 (HL7 v2) and Clinical Document Architecture (CDA).
Although these standards support healthcare information exchange, they differ significantly in structure, integration methods and common use cases.
Which standard is best for Chronic Care Management software? Should healthcare applications use FHIR APIs, HL7 v2 messages or C-CDA clinical documents?
This guide compares these standards and explains how healthcare organizations can select appropriate interoperability approaches for modern CCM workflows.
What Is Healthcare Interoperability?
Healthcare interoperability is the ability of different healthcare information systems to exchange and appropriately use information.
For example, a patient receiving chronic care services may have records distributed across a primary care practice, specialist office, hospital, laboratory and pharmacy.
Without effective interoperability, healthcare teams may need to manually retrieve clinical records and enter information into multiple systems.
Interoperability standards help systems communicate through consistent information structures, terminology and technical exchange patterns.
Understanding the Three Major Healthcare Standards
HL7 FHIR, HL7 v2 and CDA were developed to address different information exchange requirements.
HL7 FHIR
FHIR is a resource-oriented healthcare interoperability standard that supports modern APIs and multiple exchange patterns.
FHIR is especially relevant to applications requiring authorized access to structured clinical information.
HL7 Version 2
HL7 v2 is a message-oriented interoperability standard commonly used for exchanging clinical and administrative events between healthcare systems.
Typical scenarios include hospital admissions, discharges, transfers and laboratory results.
Clinical Document Architecture
CDA defines structured clinical documents that preserve important document context and human-readable clinical narratives.
Consolidated CDA, commonly called C-CDA, provides U.S. implementation guidance for exchanging documents such as patient summaries, consultation notes and discharge summaries.
FHIR vs HL7 v2 vs CDA: Comparison Table
| Feature | HL7 FHIR | HL7 v2 | CDA / C-CDA |
|---|---|---|---|
| Primary Approach | Resources and supported APIs or exchanges | Event-oriented messaging | Structured clinical documents |
| Common Data Format | JSON or XML | Delimited message segments | XML documents |
| Typical Integration | FHIR REST API | Messaging interface or integration engine | Clinical document exchange |
| Typical Data | Patients, diagnoses, medications, observations | Admissions, transfers, discharges, results | Patient summaries and clinical notes |
| Common Use Case | EHR API integration | Hospital event integration | Clinical document sharing |
| Exchange Pattern | Query, read, write and other supported patterns | Usually message-based delivery | Document-based exchange |
| Modern Web API Support | Native RESTful framework | Usually requires interface processing | Usually requires document processing |
| CCM Opportunity | Retrieve relevant patient clinical information | Receive hospital and laboratory events | Import clinical summaries and care documents |
These are typical implementation patterns rather than absolute technical limitations. All three standards can participate in more complex integration architectures.
1. What Is HL7 FHIR?
FHIR stands for Fast Healthcare Interoperability Resources and is developed by Health Level Seven International.
FHIR defines standardized resources representing important healthcare information.
Examples include:
- Patient: Patient identity and demographics
- Condition: Diagnoses and clinical problems
- Observation: Measurements and clinical findings
- MedicationRequest: Medication prescriptions and orders
- AllergyIntolerance: Allergy and intolerance information
- CarePlan: Planned care activities
- Goal: Patient and treatment goals
- Encounter: Healthcare encounters
- CareTeam: Care team participants
- DocumentReference: References to clinical documents
FHIR supports standardized RESTful interactions that can allow authorized applications to retrieve or update supported resources.
Example FHIR API Requests
GET /Patient/123
GET /Condition?patient=123
GET /Observation?patient=123
GET /MedicationRequest?patient=123
GET /CarePlan?patient=123These requests illustrate common FHIR R4-style interactions. Actual resource availability and permissions depend on the connected FHIR server.
Benefits of FHIR for CCM
- Structured access to supported clinical records
- Compatibility with modern API development frameworks
- Potential reduction in duplicate data entry
- Integration with supported EHR platforms
- More targeted retrieval of relevant information
- Support for standardized authorization frameworks such as SMART on FHIR
FHIR does not automatically provide real-time synchronization, full EHR write access or HIPAA compliance. These capabilities depend on the implementation.
2. What Is HL7 Version 2?
HL7 Version 2 is a long-established healthcare messaging standard widely used by hospitals and other clinical systems.
Unlike the common FHIR REST API pattern, HL7 v2 typically exchanges messages representing events or clinical information.
HL7 v2 messages consist of structured segments containing defined fields.
Common HL7 v2 Message Types
| Message | Typical Purpose |
|---|---|
| ADT | Admission, discharge and transfer events |
| ORU | Unsolicited clinical observation results |
| ORM | General order messages in applicable versions |
| SIU | Scheduling information |
| DFT | Financial transaction information |
Exact message structures, event codes and supported workflows vary by HL7 v2 version and implementation.
Why HL7 v2 Matters for CCM
Hospital events can be valuable in ongoing Chronic Care Management.
For example, when a patient is discharged from a hospital, a participating hospital interface may send an ADT event to an authorized receiving system.
The CCM application could use that event to alert the appropriate care team that a patient may require follow-up.
This can be particularly useful when coordinating post-discharge activities or evaluating whether Transitional Care Management services may be appropriate.
However, receiving an ADT message does not automatically establish Medicare TCM eligibility or satisfy its billing requirements.
3. What Is CDA and C-CDA?
Clinical Document Architecture is an HL7 standard for structured clinical documents.
CDA defines the structure and semantics of clinical documentation, including document context, authorship and human-readable narrative.
Consolidated CDA provides implementation guidance for common U.S. clinical document types.
Common C-CDA Documents
- Continuity of Care Document (CCD)
- Discharge Summary
- Consultation Note
- Progress Note
- Care Plan
- History and Physical
- Procedure Note
- Other supported clinical document types
A Continuity of Care Document may contain clinical information such as problems, medications, allergies, procedures and relevant treatment history.
C-CDA documents are particularly useful when healthcare providers need to exchange a structured clinical summary containing multiple categories of information.
Why C-CDA Matters for CCM
CCM teams may need to review clinical information from external providers that do not expose every required detail through FHIR APIs.
An authorized C-CDA exchange may provide a clinical summary that helps the care team understand relevant patient history.
Document information should still be reviewed for currency, completeness and clinical meaning before being incorporated into patient care activities.
FHIR vs CDA: Resources Compared with Documents
One important distinction is the granularity of the exchanged information.
FHIR commonly allows an authorized client to request particular clinical resources.
For example, a CCM application might query recent clinical observations without needing to retrieve a complete patient summary document.
CDA, by contrast, is designed around structured clinical documents with narrative and document-level context.
FHIR Example
A care coordinator requests available blood pressure Observations associated with an authorized patient.
C-CDA Example
A care coordinator receives a Continuity of Care Document containing multiple sections of the patient's clinical information.
Neither approach is universally superior. The most appropriate method depends on the clinical workflow, source capabilities and information required.
Can FHIR Exchange Clinical Documents?
Yes. FHIR is not limited to individual resource retrieval.
FHIR also defines document-related resources and exchange patterns.
A FHIR document uses a Bundle of type document with a Composition resource as its first entry, along with supporting resources.
The DocumentReference resource can describe or reference existing clinical documents, including documents produced outside FHIR.
Therefore, FHIR can participate in document-oriented exchange as well as resource-oriented interactions.
FHIR documents and CDA documents are different formats and should not be assumed to be interchangeable without appropriate transformation.
HL7 v2 vs FHIR: Event Messaging Compared with API Access
HL7 v2 is commonly used when an event in one system must be communicated to another system.
FHIR REST APIs are commonly used when an application needs to request a supported clinical resource.
HL7 v2 Scenario
A hospital discharges a patient and sends an ADT notification through its authorized messaging interface.
FHIR Scenario
A CCM platform requests permitted Encounter and Condition resources to obtain supported clinical information.
FHIR also supports messaging and other event-related patterns, while HL7 v2 systems may be exposed through modern API integration layers.
The difference is therefore more about typical implementation architecture than a strict distinction between events and queries.
Which Standard Is Best for Chronic Care Management?
There is no single standard that fits every healthcare integration requirement.
The appropriate choice depends on the source EHR, available interfaces, type of clinical information and operational workflow.
| CCM Requirement | Standards to Evaluate |
|---|---|
| Retrieve supported patient demographics | FHIR |
| Retrieve diagnoses and medications | FHIR or C-CDA |
| Receive admission and discharge notifications | HL7 v2 ADT or supported FHIR event mechanisms |
| Import a clinical patient summary | C-CDA or supported FHIR document exchange |
| Retrieve clinical observations | FHIR or HL7 v2 ORU |
| Review external consultation documents | C-CDA or supported FHIR document access |
| Connect a modern EHR application | FHIR when supported |
| Connect a legacy hospital interface | HL7 v2 when supported |
Many organizations benefit from supporting more than one interoperability approach.
Practical CCM Example: A Patient with Multiple Chronic Conditions
Consider a patient diagnosed with diabetes, hypertension, heart failure and chronic kidney disease.
The patient's primary care team is responsible for ongoing care coordination, but the patient also receives services from specialists and hospitals.
FHIR Integration
The CCM application retrieves authorized diagnoses, medication orders and clinical observations from the connected EHR.
HL7 v2 Integration
A hospital sends an authorized discharge notification when the patient returns home after hospitalization.
C-CDA Integration
The care team receives a structured discharge summary or continuity-of-care document containing relevant clinical information.
Combined Care Management Workflow
The CCM team reviews the event notification, examines relevant clinical information and determines appropriate follow-up activities.
Each exchange contributes different information to the broader patient care workflow.
This is an illustrative integration scenario. The availability of each workflow depends on supported interfaces, permissions and clinical agreements.
Recommended Integration Architecture for Modern CCM Software
Healthcare organizations planning a flexible CCM integration platform may consider an architecture that can accept multiple clinical information formats.
Integration Architecture
EHR FHIR API + HL7 v2 Interface + C-CDA Document Import → Integration and Validation Layer → Patient Identity Matching → Clinical Data Mapping → CCM Application Database → Authorized Provider and Care Coordinator Workflows.
Such an architecture can reduce direct coupling between clinical source formats and application business logic.
Core Architecture Components
- FHIR API integration service
- HL7 v2 message receiver
- C-CDA document parser
- Patient identity matching component
- Clinical terminology mapping component
- Validation and transformation service
- Data synchronization management
- Security and access control layer
- Audit and monitoring mechanisms
- Error handling and recovery processes
These components are design recommendations, not a claim that every CCM platform already provides them.
How to Convert HL7 v2 Messages into FHIR Resources
Some healthcare organizations use an integration engine to transform HL7 v2 messages into FHIR resources.
For example, information from an ADT event may contribute to Patient and Encounter resources.
Laboratory observations delivered through an ORU message may be mapped into FHIR Observation resources.
| HL7 v2 Element | Potential FHIR Representation |
|---|---|
| PID patient identification | Patient |
| PV1 patient visit information | Encounter |
| OBX observation values | Observation |
| OBR observation request information | ServiceRequest or DiagnosticReport context, depending on mapping |
| DG1 diagnosis information | Condition in an appropriate mapping context |
These are illustrative correspondences. Converting HL7 v2 into valid, clinically meaningful FHIR requires mapping rules, terminology handling, source context and appropriate validation.
Direct conversion is not always lossless or semantically equivalent.
How to Convert C-CDA Clinical Documents into FHIR
C-CDA documents may contain structured entries representing problems, medications, allergies, results and other information.
HL7 provides C-CDA on FHIR implementation guidance describing mappings between supported C-CDA content and FHIR resources.
A transformation process may:
- Receive an authorized C-CDA document.
- Validate the XML and applicable templates.
- Identify the correct patient and document source.
- Extract supported structured clinical entries.
- Map information to appropriate FHIR resources.
- Validate terminology and clinical context.
- Preserve relevant document provenance and narrative.
- Make reviewed information available to authorized workflows.
Not all clinical document content can be converted perfectly into individual resources. The original document and relevant narrative context may need to remain available.
Important 2026 Healthcare Interoperability Standards Updates
Healthcare interoperability standards continue to evolve through HL7 publications and U.S. health IT certification guidance.
US Core 9.0.0
HL7 published US Core Implementation Guide version 9.0.0 in 2026. It is based on FHIR R4 and describes U.S. profiles and interactions for important categories of patient information.
C-CDA 5.0.0
HL7 published C-CDA version 5.0.0 in June 2026, providing updated U.S. clinical document implementation guidance.
2026 ONC Standards Version Advancement Process
The 2026 Standards Version Advancement Process includes updated FHIR and C-CDA standards for voluntary adoption by eligible certified health IT developers under applicable conditions.
These approvals do not mean every EHR must immediately support the newest version or that all previous implementation requirements have been replaced.
Healthcare organizations should verify the versions supported by their actual integration partners and distinguish voluntary standards advancements from currently applicable certification requirements.
Can HL7 FHIR, HL7 v2 and C-CDA Work Together?
Yes. Healthcare interoperability architectures often use different standards for different workflows.
For example, a hospital may continue producing HL7 v2 admission and discharge messages while offering FHIR APIs for certain clinical resources and exchanging C-CDA documents for transitions of care.
A CCM platform can potentially integrate with those interfaces through a properly designed and authorized interoperability layer.
Supporting multiple standards can improve compatibility across participating healthcare systems, although each integration introduces additional development, monitoring and maintenance responsibilities.
Security and HIPAA Considerations
FHIR, HL7 v2 and CDA define healthcare information exchange structures and mechanisms. They do not independently establish HIPAA compliance.
Covered healthcare organizations and business associates must meet applicable privacy, security and contractual requirements when handling protected health information.
FHIR API Security
FHIR integrations may use SMART on FHIR authorization, protected communications, appropriate token management and server-side access controls.
HL7 v2 Security
HL7 v2 messaging implementations require appropriate protections for message transport, interface authentication, message handling and stored information.
Legacy messaging transport methods should be assessed carefully to ensure PHI is protected.
C-CDA Document Security
C-CDA document exchange requires appropriate controls over transport, storage, document access, retention and authorized disclosure.
Shared Security Responsibilities
- Conduct appropriate security risk analysis.
- Enforce authorized patient and organization access.
- Protect data in transit and at rest as appropriate.
- Maintain applicable audit controls.
- Protect credentials and integration secrets.
- Establish required Business Associate Agreements.
- Manage integration vendors and subcontractors.
- Maintain incident response procedures.
- Validate patient identity and source information.
Security must be evaluated across the complete workflow, including the sending system, integration services, receiving application and storage infrastructure.
Does Interoperability Automatically Improve CCM Billing?
No. Healthcare interoperability and Medicare CCM reimbursement involve separate requirements.
Receiving clinical information may support care management activities, but imported data does not automatically establish completion of a billable service.
Medicare CCM billing depends on applicable clinical eligibility, consent, practitioner, time and documentation requirements.
A hospital discharge notification does not automatically satisfy Transitional Care Management requirements, and a FHIR Observation does not independently establish qualifying Remote Patient Monitoring activity.
Healthcare practices should use exchanged clinical information appropriately while evaluating each billing program under its own requirements.
How to Choose the Right Integration Standard
Healthcare organizations should begin by identifying the clinical workflow and available source systems.
Choose FHIR When
- The EHR provides compatible FHIR APIs.
- The application needs structured clinical resource access.
- The workflow involves authorized patient-specific queries.
- Modern API integration is an important architectural requirement.
Choose HL7 v2 When
- The source system provides event-oriented messaging.
- Hospital admission, discharge or transfer notifications are needed.
- Laboratory results are delivered through existing HL7 interfaces.
- The integration must support an established hospital messaging environment.
Choose C-CDA When
- The clinical workflow requires an exchangeable document summary.
- Participating systems provide standardized clinical documents.
- Transitions of care require access to comprehensive external documentation.
- Document narrative, authorship and context are important.
When multiple standards are available, the decision should account for implementation cost, data quality, security, vendor support and ongoing maintenance.
Interoperability Implementation Checklist for CCM Software
- Identify participating EHR and hospital systems.
- Document the clinical information required for each CCM workflow.
- Confirm available FHIR, HL7 v2 and C-CDA interfaces.
- Verify supported standard versions and implementation guides.
- Obtain appropriate vendor access and authorization.
- Establish patient identity matching procedures.
- Design terminology and clinical data mappings.
- Validate incoming messages, resources and documents.
- Preserve relevant provenance and source information.
- Implement secure communication and storage.
- Enforce backend access control policies.
- Maintain appropriate audit mechanisms.
- Develop error handling and reconciliation workflows.
- Test using authorized synthetic patient data.
- Review HIPAA and BAA requirements.
- Verify CCM documentation and billing requirements independently.
Common Healthcare Integration Mistakes
Assuming FHIR Replaces Every HL7 Interface
Many healthcare organizations still depend on established HL7 v2 interfaces and C-CDA exchange workflows.
Ignoring EHR-Specific Capabilities
FHIR compatibility does not guarantee that every resource or API operation is supported.
Importing Clinical Data Without Validation
Incorrect terminology, missing information or outdated records may create clinical risks.
Failing to Match Patient Records Correctly
Patient identifiers may differ across healthcare systems. Robust identity management is important.
Discarding Original Clinical Document Context
Extracting isolated values from clinical documents may lose relevant narrative, authorship or clinical meaning.
Assuming Integration Equals HIPAA Compliance
Technical interoperability does not replace required privacy, security and contractual safeguards.
Automatically Treating Imported Events as Billable Activities
Clinical data imports do not independently satisfy Medicare care management billing requirements.
How ChronicSync Fits into Healthcare Interoperability Planning
ChronicSync is focused on helping healthcare organizations organize Chronic Care Management workflows, patient information, provider assignments, care coordination activities and related program operations.
As practices evaluate digital care management platforms, interoperability with existing healthcare systems is an important consideration.
Standards such as HL7 FHIR, HL7 v2 and C-CDA offer different approaches for exchanging clinical information across participating systems.
Organizations evaluating ChronicSync should confirm its currently available integration capabilities, supported EHR connections, implementation requirements and applicable security arrangements before planning production interoperability workflows.
Explore ChronicSync and Request a Demo to learn more about modern Chronic Care Management workflows.
Frequently Asked Questions
What is the main difference between FHIR and HL7 v2?
FHIR commonly uses structured resources and API-based interactions, while HL7 v2 commonly uses messages to communicate clinical and administrative events between healthcare systems.
What is the difference between CDA and C-CDA?
CDA is the general HL7 clinical document standard. C-CDA provides U.S. implementation guidance and templates for common clinical document types.
Which standard is best for CCM software?
FHIR is often a strong option for modern EHR API integration, HL7 v2 is useful for existing hospital event interfaces, and C-CDA supports structured clinical document exchange. The best choice depends on the clinical requirements and available systems.
Can CCM software use all three standards?
Yes. A CCM platform can be designed to support multiple interoperability standards when appropriate interfaces, permissions and integration components are available.
Is HL7 v2 outdated?
HL7 v2 is an established standard that continues to be used for many healthcare messaging workflows. Modernization decisions should consider existing infrastructure and clinical requirements.
Does FHIR replace C-CDA?
No. FHIR and C-CDA can support complementary exchange scenarios. FHIR also defines document exchange mechanisms, but the formats and implementation requirements differ.
Can HL7 v2 messages be converted to FHIR?
Yes. Integration services can transform supported HL7 v2 content into FHIR resources, provided appropriate mapping, validation and semantic consistency procedures are implemented.
Can C-CDA documents be converted to FHIR?
Yes. HL7 publishes C-CDA on FHIR mapping guidance. However, transformation may not be completely lossless, and relevant document context should be preserved.
Which standard supports hospital discharge notifications?
HL7 v2 ADT messaging is commonly used for admission, discharge and transfer notifications. Other event exchange approaches may also be supported.
Can FHIR retrieve medication and diagnosis information?
Yes. Compatible EHR systems may expose medication and diagnosis information through supported FHIR resources and authorized APIs.
Is FHIR required for Medicare CCM billing?
No. Medicare CCM billing is governed by applicable CMS service requirements. FHIR is an interoperability standard and not a universal CCM billing prerequisite.
Are FHIR, HL7 v2 and C-CDA HIPAA compliant?
No interoperability standard independently guarantees HIPAA compliance. Compliance depends on the organization, applicable requirements, implementation safeguards and business relationships.
What is US Core?
US Core is a U.S. FHIR implementation guide defining profiles and interactions for exchanging specified categories of healthcare information.
What changed in U.S. interoperability standards in 2026?
Newly published versions include US Core 9.0.0 and C-CDA 5.0.0. The 2026 ONC Standards Version Advancement Process approves applicable newer standards for voluntary adoption by eligible certified health IT developers.
Final Thoughts
FHIR, HL7 v2 and CDA remain important components of healthcare interoperability.
FHIR provides a modern framework for structured resource exchange and API integration. HL7 v2 supports established clinical messaging workflows, while CDA and C-CDA support structured clinical document exchange.
For Chronic Care Management software, supporting the appropriate interoperability patterns can improve the availability of relevant clinical information and help care teams coordinate across participating healthcare systems.
Healthcare organizations should choose integration methods based on clinical needs, technical capabilities, vendor support and security requirements rather than assuming one standard is universally superior.
Explore ChronicSync: www.chronicsync.com
Official Sources and References
- HL7: FHIR R4 Specification
- HL7: Comparison of FHIR with Other HL7 Standards
- HL7: Clinical Document Architecture
- HL7: Consolidated CDA Implementation Guide
- HL7: US Core Implementation Guide
- HL7: C-CDA on FHIR Mapping Guidance
- ONC: Standards Version Advancement Process
- CMS: Chronic Care Management
- HHS: HIPAA Security Rule
Disclaimer: This article is provided for educational and technical information only and does not constitute medical, legal, compliance, coding or billing advice. Healthcare interoperability standards, EHR capabilities and regulatory requirements may change. Organizations should verify current implementation specifications and applicable requirements before deploying integrations involving patient information.