TL;DR: FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard for exchanging healthcare data via REST APIs using JSON or XML. FHIR API integration enables hospitals, EHR vendors, and healthcare software platforms to share patient data securely across systems. Successful enterprise FHIR integration requires three foundations: a well-designed FHIR server architecture, SMART on FHIR authentication, and HIPAA-compliant security controls.
What Is FHIR API Integration?
FHIR API integration is the process of connecting healthcare systems EHRs, patient portals, billing platforms, lab systems, and clinical apps using HL7 FHIR (Fast Healthcare Interoperability Resources) REST APIs. FHIR API integration allows these systems to exchange structured clinical and administrative data in real time, using standard formats like JSON and XML, without proprietary connectors or custom middleware.
For healthcare organizations still running HL7 v2 interfaces, point-to-point integrations, or siloed EMR data, FHIR represents a fundamental architectural shift not an incremental improvement.
Why Healthcare Needs FHIR APIs
Direct Answer: Legacy healthcare systems fail to share data across organizational boundaries, creating clinical risk, operational inefficiency, and regulatory exposure. FHIR APIs solve this by providing a standardized, web-native interface that any modern application can consume.
The scale of the problem is well-documented. According to the Office of the National Coordinator for Health IT (ONC), health data fragmentation contributes directly to medical errors, redundant testing, and delayed treatment decisions. The 21st Century Cures Act (2016, enforced from 2022) mandates FHIR-based data access for all certified EHR vendors operating in the United States, making FHIR API integration a compliance requirement, not just a technical preference.
The operational consequences of avoiding FHIR integration are measurable. Data silos prevent care coordination across provider networks. HL7 v2 interfaces require custom parsing logic for every connection. Legacy systems cannot support real-time patient data exchange for telemedicine, remote monitoring, or AI-powered clinical decision support. Each of these gaps translates directly into engineering overhead, clinical risk, and lost revenue.
The shift toward digital health acceleration, predictive analytics, and AI-assisted care further increases the pressure. AI systems in healthcare require structured, standardized, real-time data feeds. Without FHIR, those feeds do not exist at enterprise scale.
What Is HL7 FHIR?
Direct Answer: HL7 FHIR (Fast Healthcare Interoperability Resources) is a standard developed by Health Level Seven International (HL7) that defines how healthcare information can be exchanged between systems. FHIR uses REST APIs, JSON and XML data formats, and a modular resource model making it compatible with modern web development practices, unlike its predecessors HL7 v2 and HL7 v3/CDA.
| Feature | HL7 v2 | HL7 v3 / CDA | FHIR R4/R5 |
|---|---|---|---|
| Data format | Pipe-delimited text | XML (verbose) | JSON, XML, RDF |
| API style | Point-to-point messaging | Document-based | RESTful HTTP |
| Developer accessibility | Low | Very Low | High |
| Interoperability support | Limited | Limited | Native |
| US regulatory status | Legacy (still in use) | Declining | Mandated (ONC/CMS) |
| Real-time data exchange | No | No | Yes |
| Modern app compatibility | Poor | Poor | Excellent |
FHIR organizes clinical and administrative data into Resources discrete, modular objects like Patient, Observation, or Medication. Resources can be assembled into Bundles for batch operations, extended using Profiles to meet national or organizational requirements, and enriched with Terminology Services for standardized code systems like SNOMED CT, LOINC, and ICD-10.
The current production standard is FHIR R4, with FHIR R5 gaining adoption across enterprise implementations. The US Core Implementation Guide, built on FHIR R4, defines the minimum data requirements for US-based EHR interoperability.
Core FHIR Resources
FHIR organizes all healthcare data into discrete Resource types. Each resource represents a specific clinical or administrative concept and follows a consistent structure with a unique identifier, metadata, and structured data elements.
| FHIR Resource | Description | Common Use Cases |
|---|---|---|
| Patient | Demographic and identity information | Registration, care coordination, patient portal |
| Practitioner | Provider credentials and contact info | Directory services, care team assignment |
| Encounter | Clinical visit or interaction record | Visit history, care coordination |
| Observation | Clinical measurements and lab results | Vitals, lab values, assessment scores |
| Condition | Diagnoses and health problems | Problem lists, chronic disease management |
| Medication | Drug information | Formulary, drug reference |
| MedicationRequest | Prescriptions and medication orders | e-Prescribing, medication management |
| Appointment | Scheduled visit data | Scheduling systems, patient portals |
| DiagnosticReport | Diagnostic test results and reports | Lab, radiology, pathology |
| Procedure | Clinical procedures performed | Surgical history, care plans |
| AllergyIntolerance | Allergy and intolerance records | Safety checks, clinical alerts |
| Immunization | Vaccination records | Public health reporting, patient records |
| Organization | Healthcare organization data | Provider directories, network management |
| Location | Physical care delivery sites | Facility management, care routing |
How Does FHIR API Work Step by Step?
A FHIR API interaction follows a standard request-response cycle: a client application authenticates via SMART on FHIR OAuth2, sends an HTTP request to a FHIR server endpoint, the server validates the request against FHIR profiles, retrieves or writes the relevant resource, and returns a structured JSON or XML response.
Step-by-step enterprise workflow:
- Client Application initiates a request (e.g., patient portal, mobile app, AI assistant)
- Authentication Layer validates the access token via SMART on FHIR / OAuth2
- API Gateway enforces rate limiting, routing, and audit logging
- FHIR Server receives the validated request
- Validation Engine checks the resource against applicable FHIR profiles (e.g., US Core)
- Business Logic Layer applies organizational rules, consent checks, and data transformations
- Data Store retrieves or persists the FHIR resource
- Response is returned as JSON or XML with appropriate HTTP status codes
One of the most common misconceptions is that a FHIR server is simply a database with an API wrapper. In reality, a production-grade FHIR server must handle profile validation, terminology binding, versioning, audit logging, and consent enforcement concurrently. Organizations that treat FHIR server selection as a commodity decision consistently underestimate implementation complexity.
FHIR REST API Operations
FHIR REST API operations follow standard HTTP methods, with additional FHIR-specific interactions for search, batch processing, and history tracking. Each operation maps to a specific clinical or administrative action.
| Operation | HTTP Method | FHIR Interaction | Enterprise Example |
|---|---|---|---|
| Read a resource | GET | read | Retrieve a Patient record by ID |
| Search resources | GET | search | Find all Observations for a patient in the last 30 days |
| Create a resource | POST | create | Register a new patient encounter |
| Update a resource | PUT | update | Modify an existing medication order |
| Partial update | PATCH | patch | Update a single field in a Condition resource |
| Delete a resource | DELETE | delete | Remove a draft Appointment |
| Retrieve history | GET | history | Audit all versions of a Practitioner record |
| Batch operations | POST | batch | Submit multiple resource reads in one request |
| Atomic transactions | POST | transaction | Create a Patient and Encounter together, or roll both back |
FHIR’s transaction operation is particularly important for enterprise systems. It guarantees atomicity either all resources in a Bundle are written successfully, or none are. This behavior is critical for clinical workflows where partial data writes create safety risks.
SMART on FHIR Authentication
Direct Answer: SMART on FHIR is the standard authorization framework for FHIR APIs. It combines OAuth 2.0 for authorization, OpenID Connect for identity, and FHIR-specific scope definitions to control which resources a client application can access on behalf of a patient or provider.
SMART on FHIR app launch flow:
- Client application registers with the FHIR authorization server
- User (patient or provider) initiates the app from within an EHR or portal
- EHR launches the app with an iss (FHIR server URL) and launch parameter
- App requests authorization from the authorization server, specifying requested scopes
- User authenticates and grants consent
- Authorization server issues a JWT access token and, if offline access is needed, a refresh token
- App includes the access token in all subsequent FHIR API requests
- Tokens expire; the app uses the refresh token to obtain a new access token without re-prompting the user
FHIR scope patterns control access granularly:
patient/Patient.readread Patient resources on behalf of the authenticated patientuser/Observation.readread Observations on behalf of an authenticated providersystem/Medication.writeserver-to-server write access to Medication resourceslaunch/patientrequest patient context during EHR launch
One of the most common authentication failures in enterprise FHIR implementations is scoping too broadly. Requesting patient/*.read when the application only needs patient/Observation.read violates the principle of least privilege and introduces unnecessary PHI exposure risk. Define scopes at the resource level before development begins, not during security review.
Enterprise FHIR Architecture
Direct Answer: A production enterprise FHIR architecture layers a healthcare application, API gateway, authentication server, FHIR server, business logic engine, audit logging, and cloud infrastructure to connect EHRs, lab systems, billing platforms, patient portals, and AI systems through a single, governed interoperability layer.
Core architectural components:
- Healthcare Application Layer: Patient portals, mobile apps, clinical dashboards, AI assistants, telemedicine platforms
- API Gateway: Rate limiting, request routing, SSL termination, API key management, threat detection
- SMART on FHIR Authorization Server: OAuth2/OIDC token issuance, scope enforcement, patient/provider consent
- FHIR Server: Resource validation, profile conformance, terminology services, CRUD operations (e.g., HAPI FHIR, Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake)
- Business Logic Layer: Clinical rules, organizational policies, data transformation, workflow orchestration
- Audit & Compliance Layer: HIPAA audit logs, access records, consent management
- Monitoring & Observability: API latency, error rates, resource usage, security event detection
- Source Systems: EHR (Epic, Cerner/Oracle Health), lab systems, billing platforms, imaging systems
Organizations that deploy FHIR servers without a dedicated API gateway expose themselves to rate-abuse attacks, unthrottled PHI extraction, and unlogged access events. The API gateway is not optional infrastructure.
Integrating with Popular EHR Systems
Major EHR platforms expose FHIR R4 APIs for third-party app integration, but each vendor implements profiles, authentication flows, and data availability differently. Understanding vendor-specific requirements before integration reduces development time significantly.
- Epic FHIR API: Supports FHIR R4 via MyChart and clinical app integrations. Requires registration through the Epic on FHIR developer program. Epic’s Sandbox environment is publicly accessible. Epic enforces strict scope and data access review before production approval.
- Oracle Health (Cerner) FHIR API: Provides FHIR R4 endpoints through the Cerner Ignite platform. Supports SMART on FHIR for both patient-facing and provider-facing apps. Strong support for US Core profiles.
- Athenahealth FHIR API: FHIR R4 access available through the More Disruption Please (MDP) marketplace. Requires partner program registration. API coverage varies across athenahealth product lines.
- MEDITECH FHIR API: Exposes FHIR R4 APIs through MEDITECH Expanse. Strong adoption among community hospitals. Supports patient access and provider-facing clinical workflows.
- Allscripts / Veradigm FHIR API: FHIR R4 access through the Allscripts Developer Program. Commonly used in ambulatory and specialty care settings.
- Redox: A healthcare integration platform that normalizes data across multiple EHR systems, including FHIR and HL7 v2 interfaces. Useful for organizations needing to connect to multiple EHRs without managing per-vendor integrations.
- Health Gorilla: A FHIR-based health data network that aggregates clinical data from multiple sources. Commonly used for lab results, ADT feeds, and clinical document exchange.
Each EHR vendor has different production approval timelines. Epic’s production review process typically requires four to eight weeks after sandbox testing is complete. Plan for vendor approval cycles in your project timeline or risk delays that affect go-live dates.
Common Healthcare Use Cases for FHIR API Integration
FHIR APIs enable a wide range of healthcare applications, from patient portals and telemedicine to AI-powered clinical decision support, remote monitoring, and automated claims processing.
- Patient portals: Real-time access to medical records, lab results, and care summaries via FHIR Patient and Observation resources
- Telemedicine platforms: Pulling pre-visit clinical context from EHR systems to support asynchronous and synchronous virtual care
- Remote patient monitoring: Streaming device data (blood pressure, glucose, SpO2) as FHIR Observation resources for clinical review
- Clinical decision support (CDS): FHIR CDS Hooks enable real-time alerts and recommendations within EHR workflows at point of care
- Healthcare AI assistants: LLMs and AI copilots consuming FHIR data for ambient documentation, care gap identification, and treatment recommendations
- Appointment scheduling: Patient self-scheduling via FHIR Appointment and Slot resources, synchronized across EHR and scheduling systems
- Medical imaging integration: DiagnosticReport and ImagingStudy resources linking radiology workflows with clinical systems
- Claims automation: Using Encounter, Procedure, and Condition resources to automate prior authorization and claims submission
- Population health management: Aggregating FHIR data across patient panels to identify care gaps, risk stratify populations, and trigger outreach programs
- Healthcare mobile apps: iOS and Android applications consuming FHIR APIs to provide patients with personalized health information and care management tools
FHIR Security Best Practices
FHIR API security requires layered controls across authentication, authorization, encryption, audit logging, and threat detection. HIPAA compliance is a baseline requirement, not a complete security framework.
Security checklist:
| Control | Requirement | Implementation Approach |
|---|---|---|
| Transport security | TLS 1.2 minimum, TLS 1.3 preferred | Enforce at API gateway and server level |
| Authentication | SMART on FHIR OAuth2 | Implement per SMART App Launch Framework |
| Authorization | RBAC + FHIR scopes | Minimum necessary access per role |
| PHI encryption at rest | AES-256 or equivalent | Database-level and storage encryption |
| Audit logging | All PHI access logged | Immutable logs, per HIPAA §164.312(b) |
| Consent management | Patient consent records | FHIR Consent resource + enforcement engine |
| Zero Trust architecture | Verify every request | Never trust network location; always verify identity |
| API rate limiting | Per-client throttling | Prevent data harvesting and DoS attacks |
| Input validation | All inbound data validated | FHIR profile validation before processing |
| Threat detection | Anomaly monitoring | SIEM integration with healthcare threat feeds |
| Data minimization | Return only requested data | Scope enforcement at resource field level |
| Least privilege | Minimum access by default | Review and audit scopes quarterly |
HIPAA defines the minimum compliance floor. It does not address modern threat vectors such as API abuse, token theft, or prompt injection in AI-assisted FHIR workflows. Organizations treating HIPAA compliance as equivalent to security will discover the difference after a breach.
Common FHIR Implementation Challenges
The most common FHIR implementation failures trace back to data quality problems, legacy system constraints, and vendor-specific profile variations not FHIR standard complexity itself.
- Data quality: Source systems often contain missing, inconsistent, or duplicate patient records. FHIR exposes these problems by making data visible across systems. Clean source data before integration begins, not during testing.
- Legacy HL7 v2 coexistence: Most healthcare organizations run HL7 v2 interfaces alongside FHIR for several years. This dual-stack operation requires interface engines (Mirth Connect, Rhapsody, Azure API for FHIR) to translate between formats.
- Vendor profile variations: Each EHR vendor implements FHIR profiles differently. Epic’s US Core Patient profile includes fields that Cerner’s implementation may handle differently. Test against each target vendor’s sandbox before assuming cross-vendor portability.
- Authentication complexity: SMART on FHIR adds significant implementation complexity compared to simple API keys. Teams unfamiliar with OAuth2 and OIDC consistently underestimate this effort.
- FHIR server performance at scale: FHIR servers handling large patient populations require database indexing strategies, caching layers, and horizontal scaling. Default HAPI FHIR configurations are not production-ready without tuning.
- Terminology mapping: Translating between SNOMED CT, LOINC, ICD-10, and local codes requires a dedicated terminology service. Hardcoded code mappings break when source systems update terminology versions.
- Version compatibility: FHIR R4 and R5 are not backward-compatible in all resource definitions. Establish a versioning policy before the first production deployment.
- FHIR profile governance: Organizations using multiple Implementation Guides (US Core, Da Vinci, USCDI) must manage profile conflicts systematically. Informal governance leads to inconsistent implementations that block interoperability.
FHIR API Integration Best Practices
Enterprise FHIR implementations succeed when architecture, governance, and security decisions are made before development begins. Retrofitting these decisions after go-live is consistently more expensive and disruptive than planning for them upfront.
- Start with a FHIR capability statement review. Every FHIR server publishes a
/metadataendpoint. Review it to understand which resources, interactions, and search parameters each vendor actually supports before writing integration code. - Use US Core profiles as your baseline. US Core defines the minimum FHIR R4 requirements for US interoperability. Build to US Core by default, then extend with additional Implementation Guides where the use case requires it.
- Deploy a FHIR-aware API gateway. Generic API gateways lack FHIR-specific validation, routing, and audit capabilities. Use a gateway that understands FHIR resource types and interaction patterns.
- Implement SMART on FHIR from day one. Adding SMART on FHIR authentication after initial development requires significant rework. Design the authorization model before writing business logic.
- Version your FHIR APIs explicitly. Include the FHIR version in your API path (e.g.,
/fhir/r4/Patient). This prevents breaking changes when the organization migrates from R4 to R5. - Validate all resources against target profiles before writing. Accepting non-conformant resources creates data quality debt that accumulates rapidly in high-volume environments.
- Log every PHI access event immutably. HIPAA requires audit logs; litigation, breach investigations, and compliance audits require them to be tamper-proof. Implement immutable logging infrastructure before processing any PHI.
- Use FHIR Bulk Data (FHIR $export) for population-scale operations. Individual REST reads do not scale for population health, analytics, or AI training workflows. The FHIR Bulk Data API supports efficient, asynchronous export of large patient populations.
- Implement a terminology service. SNOMED CT, LOINC, ICD-10, and RxNorm require a dedicated normalization layer. Organizations that hardcode terminology mappings will encounter failures when vendors update code systems.
- Test against each vendor’s sandbox, not just the FHIR specification. Specification compliance and real-world vendor behavior diverge. Epic’s sandbox reveals integration issues that specification review cannot.
- Define and enforce FHIR scopes at the resource level. Broad scopes (
patient/*.read) expose more PHI than necessary. Define scopes at the resource level (patient/Observation.read) and enforce them at the authorization server. - Monitor API performance with FHIR-aware observability. Track response times by resource type, error rates by interaction, and payload sizes. Generic APM tools miss FHIR-specific performance patterns.
- Plan for EHR vendor approval timelines. Production access to Epic, Oracle Health, and athenahealth requires vendor review and approval. Factor four to twelve weeks of vendor review time into your project schedule.
- Establish a FHIR governance committee before scaling. Organizations that deploy FHIR integrations without governance defining profile ownership, change management processes, and versioning policies accumulate architectural debt that blocks future interoperability initiatives.
- Design for FHIR R5 migration now. FHIR R5 introduces significant improvements to subscription mechanisms, clinical reasoning, and cross-version compatibility. Architecture decisions made in R4 implementations should account for eventual R5 migration without requiring full rewrites.
FHIR Implementation Checklist
| Phase | Checklist Item |
|---|---|
| Planning | Define FHIR use cases and business objectives |
| Planning | Identify target EHR systems and FHIR capability statements |
| Planning | Select FHIR version (R4/R5) and applicable Implementation Guides |
| Planning | Establish FHIR governance committee and profile ownership |
| Architecture | Select FHIR server (HAPI FHIR, Azure Health Data Services, AWS HealthLake, GCP Healthcare API) |
| Architecture | Deploy FHIR-aware API gateway |
| Architecture | Design SMART on FHIR authorization model and scope definitions |
| Architecture | Define FHIR resource versioning and API path strategy |
| Security | Implement TLS 1.3 for all FHIR API traffic |
| Security | Configure RBAC and FHIR scope enforcement |
| Security | Deploy immutable PHI audit logging |
| Security | Implement rate limiting and threat detection at API gateway |
| Development | Build FHIR profile validation pipeline |
| Development | Integrate terminology service for SNOMED CT, LOINC, ICD-10 |
| Development | Implement FHIR Bulk Data ($export) for population-scale operations |
| Testing | Test against each target EHR vendor sandbox |
| Testing | Validate US Core profile conformance |
| Testing | Conduct HIPAA security risk assessment |
| Deployment | Submit EHR vendor production access applications |
| Deployment | Configure monitoring and FHIR-aware observability |
| Operations | Schedule quarterly scope and access reviews |
| Operations | Establish FHIR R5 migration roadmap |
What Is the Future of FHIR APIs in Healthcare?
Direct Answer: FHIR APIs are becoming the data infrastructure layer for AI-powered healthcare. FHIR R5, agentic AI systems, ambient clinical documentation, and cloud-native healthcare platforms are converging on FHIR as the standard interface for real-time clinical data exchange.
Several converging forces are accelerating FHIR adoption beyond regulatory compliance:
Agentic AI and LLMs in clinical workflows: Large language models require structured, real-time patient data to support ambient documentation, care gap identification, and clinical decision support. FHIR is the primary data interface these systems consume. Healthcare organizations without mature FHIR infrastructure will not be able to deploy clinical AI at scale.
FHIR R5 capabilities: FHIR R5 introduces improved subscription mechanisms (topic-based subscriptions replacing polling), enhanced cross-version compatibility, and expanded clinical reasoning resources. Organizations investing in R4 now should architect for R5 migration without requiring full system rewrites.
CMS interoperability rules: The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F, 2024) requires payers to implement FHIR APIs for prior authorization, patient access, and provider directory functions. This extends FHIR requirements significantly beyond EHR vendors into the payer ecosystem.
Cloud healthcare platforms: AWS HealthLake, Azure Health Data Services, and Google Cloud Healthcare API have made FHIR server deployment a managed service rather than a self-hosted infrastructure responsibility. This reduces time-to-production for enterprise FHIR implementations.
Predictive analytics and population health: FHIR Bulk Data exports enable population-scale analytics pipelines that were previously only possible with custom data warehouse integrations. AI-driven predictive models in chronic disease management, readmission prediction, and care gap closure depend on FHIR bulk data infrastructure.
Organizations that invest in enterprise FHIR architecture today are building the data foundation that clinical AI, digital health platforms, and value-based care models will require over the next decade.
Frequently Asked Question (FAQ)
FHIR API integration is the process of connecting healthcare systems EHRs, patient portals, lab systems, billing platforms, and clinical applications using HL7 FHIR REST APIs. FHIR API integration allows these systems to exchange structured patient and clinical data in real time using standardized JSON or XML formats, without proprietary connectors or custom data transformations.
HL7 v2 uses pipe-delimited text messages sent over point-to-point connections. FHIR uses REST APIs, JSON/XML, and a modular resource model compatible with modern web applications. FHIR is mandated by the ONC for US EHR certification; HL7 v2 remains in use for legacy system interfaces but does not support real-time web-based data exchange.
FHIR R4 is the current production standard and is required for US Core compliance and ONC certification. FHIR R5 is gaining adoption in new implementations and offers improved subscription mechanisms and cross-version compatibility. New enterprise architectures should implement R4 with an explicit R5 migration path designed into the API versioning strategy.
SMART on FHIR is the authorization framework that controls which applications can access which FHIR resources on behalf of which users. It combines OAuth 2.0 for authorization, OpenID Connect for identity, and FHIR-specific scope definitions. SMART on FHIR is required by the ONC’s 21st Century Cures Act rules for all third-party application access to certified EHR systems.
A focused single-EHR integration for a specific use case takes six to twelve weeks, including vendor sandbox testing and production approval. A multi-EHR enterprise interoperability platform takes four to nine months, depending on the number of source systems, profile complexity, and regulatory requirements. EHR vendor production approval processes typically add four to twelve weeks to any timeline.
FHIR provides the data exchange mechanism; HIPAA compliance requires additional controls layered on top. These include TLS encryption for data in transit, AES-256 encryption for data at rest, RBAC access controls, immutable PHI audit logs, and a completed HIPAA Security Risk Assessment. FHIR’s SMART on FHIR authentication framework supports HIPAA’s access control requirements but does not automatically satisfy all HIPAA Security Rule provisions.
The choice depends on infrastructure preferences and scale requirements. HAPI FHIR is the leading open-source option with strong community support. Azure Health Data Services, AWS HealthLake, and Google Cloud Healthcare API provide managed FHIR server infrastructure that reduces operational overhead. Organizations with existing cloud commitments typically choose the managed service from their primary cloud provider.
Epic exposes FHIR R4 APIs through its Epic on FHIR developer program. Third-party applications register for sandbox access, develop and test against Epic’s sandbox environment, and then apply for production access through Epic’s application review process. Epic enforces US Core profiles and requires explicit scope approval before production data access is granted. Production approval typically takes four to eight weeks after sandbox testing is complete.
FHIR profiles are constraints applied to base FHIR resources to meet specific national, regional, or organizational requirements. The US Core profile, for example, defines which Patient resource fields are required for US EHR interoperability. Profiles matter because EHR vendors and implementation guides require conformance to specific profiles not just base FHIR for interoperability certification and data exchange agreements.
FHIR Bulk Data ($export) is an asynchronous API operation that exports large volumes of FHIR resources for an entire patient population. It is designed for use cases that individual REST reads cannot support at scale: population health analytics, care gap analysis, AI model training, and regulatory reporting. Organizations processing more than a few hundred patients at a time should implement Bulk Data rather than sequential individual resource reads.
