Event-Driven Hospital Capacity Systems: Building Real-Time Bed and OR Scheduling with EHR Integration

Hospitals don’t fail capacity management because staff don’t care. They fail because the system of record, the bedside reality, and the scheduling plan are often out of sync by minutes or hours. In a high-acuity environment, that delay is enough to create boarding in the ED, wasted OR slots, preventable diversions, and frustrated care teams. A modern event-driven capacity management platform closes that gap by making bed status, OR availability, transport milestones, discharge readiness, and arrival predictions visible in near real time, then feeding those facts back into scheduling and command-center workflows.

This guide is an architecture and implementation blueprint for building that platform with FHIR, HL7, CQRS, predictive modeling, and multi-tenant security. It also reflects the market direction: capacity software is expanding quickly as hospitals seek real-time visibility, AI-assisted planning, and cloud-scale coordination. For context on why this category is accelerating, see our broader reading on the architecture patterns for compliant EHR hosting, and compare the operational lens with how to structure innovation teams within IT operations when rolling out hospital workflow systems.

1) Why hospital capacity needs an event-driven architecture

Capacity is a moving target, not a static report

Traditional bed boards and OR schedules are snapshots. They are useful for humans, but they are fragile as a source of truth when the situation is changing constantly. A patient may be discharged, but the room is still occupied by housekeeping; a surgical case may be booked, but the surgeon is delayed and the anesthesia team is holding; an ED admission may be predicted, but the bed assignment is blocked by infection-control constraints. An event-driven design treats each of those changes as a first-class business event, not as an after-the-fact database update.

The practical difference is enormous. Instead of polling every system every few minutes, the platform subscribes to events such as ADT A01 admission, HL7 discharge, clean room ready, OR case started, or transfer initiated. Each event flows through a bus, updates the operational model, and triggers downstream actions such as score recalculation, bed recommendation, or schedule alerting. This is the same shift many large distributed systems made years ago: real-time, loosely coupled coordination beats brittle point-to-point integrations. If your team already thinks in platform terms, the lessons from enterprise automation and trust patterns in K8s fleets map surprisingly well to healthcare operations.

Capacity has multiple states, not one truth

One of the biggest mistakes in hospital software is assuming a bed or OR has a single status. In reality, it has different statuses depending on the consumer. Operations wants “available,” environmental services wants “needs cleaning,” nursing wants “ready for transfer,” infection prevention wants “isolation required,” and revenue-cycle systems want “documentation complete.” CQRS is a good fit because it lets you separate the write model that records every event from the read model that powers dashboards and scheduling views. That separation is especially helpful when integrating the EHR with external systems that update at different speeds and levels of confidence.

The result is more than cleaner code. It gives you traceability, rebuildability, and better fault isolation. If a downstream read model becomes stale, you can replay the event stream. If a connector drops a message, you can recover from an idempotent event ledger. That makes the platform more trustworthy for clinical operations and much easier to audit. For teams evaluating the broader analytics stack, the market movement described in hospital capacity management market trends and healthcare predictive analytics growth explains why this architecture is becoming standard rather than experimental.

Why spreadsheets and point-to-point interfaces break under load

Capacity problems are often “solved” with a spreadsheet, email chain, or custom dashboard bolted onto an EHR. That can work in a low-volume clinic, but hospitals have bursts, exceptions, and overlapping workflows. By the time one user refreshes the spreadsheet, another department has changed the plan. Point-to-point interfaces also create hidden coupling; when a vendor changes a field or message format, your coordination model silently drifts. In a high-stakes environment, that drift becomes an operational risk.

A healthier pattern is to treat capacity as an operational platform. The EHR remains the clinical system of record, but the capacity layer becomes the system of coordination. That layer listens to canonical events, normalizes them, and projects them into operational views. In implementation terms, this is where disciplined integration design matters as much as the algorithm itself. Teams that need a refresher on integration mechanics can compare this with the patterns in Veeva and Epic integration, especially around interoperability, compliance, and event-triggered workflows.

2) Reference architecture: from EHR events to capacity decisions

The core layers of the platform

A robust hospital capacity system usually has five layers. First is the ingestion layer, which receives HL7 v2 messages, FHIR subscriptions, APIs, and occasionally flat-file or legacy feeds. Second is the event normalization layer, which maps source-specific messages into a canonical event schema. Third is the event bus, which distributes validated events to consumer services. Fourth is the state and projection layer, often built with CQRS and materialized views. Fifth is the decision layer, where rules engines, optimization services, and predictive models propose actions.

In practice, the best systems also include a human override layer. Bed management is not a purely mathematical problem because clinicians and charge nurses know things the data cannot fully capture, like staffing strain, pending consults, or a patient who is medically ready but socially complex. The architecture should preserve automation while still giving trusted users a way to override recommendations with reason codes and audit trails. That balance is similar to what teams learn when operationalizing governance in scheduling and quota systems for scarce resources.

Event bus design: durable, observable, and replayable

The event bus is the heartbeat of the platform. Whether you use Kafka, Pulsar, RabbitMQ, or a cloud-native equivalent, the key requirements are durability, ordering where needed, and observable processing. Bed and OR events often need partitioning by facility, unit, or room so that related updates stay in sequence. You should also capture metadata like source system, encounter ID, tenant ID, confidence score, and correlation ID. This makes troubleshooting possible when a discharge event arrives before the admission reconciliation is complete.

Good event design also reduces the blast radius of downstream failures. If the staffing service is down, the ingest pipeline should not stop accepting admissions. If the predictive service is lagging, scheduling should still function based on current state. In healthcare, graceful degradation is not a nice-to-have; it is a safety feature. For broader perspective on resilient platform operations, see budgeting and operating AI infrastructure, which offers useful ideas for designing services that scale without becoming financially unpredictable.

CQRS and read models for operational clarity

CQRS works especially well when you have distinct users with different latency needs. The write side captures immutable events: patient admitted, OR case scheduled, bed cleaned, transfer accepted, patient discharged. The read side then projects those events into purpose-built views: “open beds by unit,” “OR utilization today,” “patients awaiting transport,” “predicted admissions in next 6 hours.” This avoids trying to make one relational schema satisfy everyone at once, which is a common source of schema bloat and query contention.

The most effective pattern is to create read models for each operational persona. A bed manager sees capacity by unit and specialty; an OR scheduler sees room utilization and turnover windows; an administrator sees system-wide throughput and transfer bottlenecks. When the event stream is trustworthy, those views can be regenerated at any time. If you want a practical analogy for coordinated resource scheduling in another domain, the logic resembles the governance and fairness concerns discussed in QPU scheduling governance, just with patient safety instead of quantum hardware.

3) Interoperability with FHIR and HL7: connectors that actually work

HL7 v2 is still everywhere, and that is okay

Many hospitals still rely on HL7 v2 ADT, SIU, ORM, and ORU feeds because they are deeply embedded in EHR workflows and interface engines. A realistic capacity platform should embrace that reality rather than fight it. HL7 v2 remains the most pragmatic source for admission, discharge, transfer, and scheduling events, especially when you need broad coverage across facilities and legacy systems. The trick is to normalize the message content into a more modern canonical event structure before it reaches your decision services.

That normalization layer should handle field mapping, code translation, deduplication, and temporal reconciliation. For example, an ADT A01 may arrive with a bed assignment reference that is later corrected by another update. Your system should preserve both facts, but only expose the latest valid state in the read model. You also need robust handling for message retries and backfills, because interface engines and EHRs are not always perfectly synchronized. The integration lessons from Epic integration guidance are relevant here: canonicalization and compliance are more important than forcing every system to speak the same native format.

FHIR gives you modern resources, but not complete operational truth

FHIR is excellent for structured interoperability, especially for Encounter, Location, Appointment, Bed representations where available, and related clinical context. But capacity management is often more nuanced than the FHIR resources alone suggest. A “bed” in the EHR may not reflect real-world readiness, and an “appointment” may not account for surgeon availability, pre-op checklist completion, or anesthesia staffing. That is why a hybrid integration strategy is usually best: use FHIR for structured access and HL7 v2 for event completeness, then enrich with local operational events from housekeeping, transport, staffing, and command-center systems.

When designing FHIR connectors, pay attention to versioning, search semantics, and subscription behavior. Not all vendors support the same eventing patterns, and not all hospitals expose every resource equally. Build adapters that can degrade gracefully and keep the core capacity workflow alive even if a specific FHIR endpoint is unavailable. For a broader look at how real-time health data is increasingly used in analytics, our guide to reading health data with SQL, Python, and Tableau offers a good data-literacy companion to this architecture.

Interface engine strategy: don’t let middleware become a black box

Interface engines like Mirth/NextGen Connect or enterprise iPaaS tools are useful, but they should not become opaque logic dumps. The more logic you bury in interface mappings, the harder it becomes to test, version, and audit behavior across tenants and sites. A better pattern is to use the interface engine for transport, authentication, message splitting, and protocol translation, while keeping business rules in services with versioned code. That separation makes your system easier to reason about and much safer to change.

Logging and traceability are essential. Every transformation should emit a correlation trail that allows operations teams to answer: where did this event come from, how was it normalized, what rule changed the state, and why did the scheduler respond the way it did? Without that trail, you cannot support clinical operations at scale. The same principle underlies trustworthy digital operations in other domains, such as the careful observability-first thinking shown in cloud security stack planning.

4) Predictive admission models: turning data into proactive capacity planning

What to predict, and why

Predictive modeling in capacity management should focus on operationally actionable questions, not just academic accuracy. The best predictions are usually: probability of admission from the ED, expected discharge time, likely length of stay, OR case start delay, and surge probability over the next 4–24 hours. Those outputs directly influence bed assignments, staffing, room turnover, and transport prioritization. The market data confirms that this is where the category is heading, with AI-driven analytics increasingly embedded in hospital operations and predictive analytics growing rapidly across healthcare.

Be careful not to overpromise. A model that predicts admissions well but cannot explain uncertainty is often less useful than a slightly less accurate model with calibrated confidence. Operations teams need to know when to trust an early warning and when to treat it as a soft signal. Predictive models should therefore include confidence bands, feature transparency, and thresholds that map to specific operational actions. This is where the healthcare predictive analytics trend matters: the value is not prediction alone, but prediction connected to decision workflows.

Feature engineering from EHR and operational signals

The best models use more than encounter history. Useful signals may include arrival acuity, prior utilization, diagnosis group, seasonality, day of week, staffing ratios, OR block utilization, lab turnaround times, discharge order timing, and even transport queue depth. Some systems also incorporate bed turnover duration, isolation requirements, and historical admission patterns by service line. You can enrich those signals with external data like flu trends or weather if your governance allows it, but the model should still work when those feeds are absent.

In practice, the model pipeline should be retrainable, monitor drift, and support champion/challenger experiments. For example, a gradient-boosted tree model may outperform a logistic baseline on admission prediction, but a simpler model might be easier to deploy in a regulated environment. The right choice depends on explainability requirements, latency constraints, and the hospital’s model governance maturity. For a useful contrast in model risk and rollout discipline, see AI adoption pitfalls and measurable ROI, which translates well to healthcare ML implementation.

From model output to scheduling action

Prediction is only valuable if it changes behavior. A good capacity system turns forecast output into action tables: reserve two med-surg beds for likely ED admits, delay cleaning handoff on a room likely to be needed by an ICU transfer, or recommend adding a second recovery nurse during a projected OR surge. These actions should be configurable by facility and unit because operating models differ. A tertiary academic hospital will use the same framework differently than a community hospital with limited specialty coverage.

It helps to treat predictions as events too. When a model emits “high probability of admission within 90 minutes,” that event can trigger staffing alerts, create a tentative bed reservation, or notify a transfer center. If the probability later drops, the system can retract or downgrade the recommendation. That reversible logic is one reason event-driven systems outperform static reports. If your organization is just starting to operationalize predictive AI, the market growth described in healthcare predictive analytics research is a strong signal that this is becoming a standard capability rather than an experimental add-on.

5) Bed management and OR scheduling workflows in the real world

Bed management: from status updates to throughput orchestration

Bed management is not just about “occupied” versus “free.” A serious system tracks housekeeping state, specialty eligibility, isolation status, service-line restrictions, and staffing compatibility. That allows the platform to recommend the right bed, not just any bed. For example, a telemetry patient may technically fit in a standard med-surg room, but if the unit is at staffing threshold, the recommendation should respect the staffing constraint and perhaps propose a nearby alternative or hold the patient temporarily in a monitored setting.

The biggest operational win comes from reducing ambiguity. If every status change is event-backed and time-stamped, the charge nurse can see why a room is not yet available and what dependency is blocking it. That transparency reduces phone calls and manual reconciliation. It also creates a reliable historical trail for throughput analysis. Capacity teams can identify whether delays are due to EVS turnaround, transport latency, discharge order timing, or upstream admission surges.

OR scheduling: room time is scarce, and turnovers matter

Operating rooms are an especially good use case because cost of idle capacity is high and the dependency chain is long. A complete OR scheduling system must incorporate surgeon schedule changes, anesthesia readiness, pre-op testing, implant availability, case duration estimates, PACU capacity, and downstream bed availability for post-op admission. If the OR is optimized in isolation, the hospital may create bottlenecks elsewhere, such as a PACU overflow or an ICU bed shortage. The system should therefore connect OR scheduling to the broader capacity graph, not treat it as a standalone calendar.

In practice, event-driven OR logic can handle updates such as case added, case delayed, room turned over, patient arrived, anesthesia start, incision, and case complete. Each event should refresh the operational forecast and update downstream constraints. This makes the schedule resilient to real-world volatility. A helpful analogy is the way event programs are coordinated in media and live production; our piece on crafting event experiences and timelines can give non-healthcare stakeholders a sense of how sequencing, dependencies, and audience expectations affect outcomes.

Command-center UX: clarity beats dashboard sprawl

The user interface should not try to show everything. Instead, it should highlight exceptions, next actions, and confidence. A good command center shows the current bed map, the OR schedule, predicted demand, and blockers in one coherent workflow. It should also surface explainability: why did the system recommend this bed, why is that OR case predicted to run long, and what dependency is preventing transfer? If users cannot trust the “why,” they will route around the system.

Design the UX around personas. Bed managers need speed and confidence. Executives need trend visibility. Charge nurses need local detail. Surgeons need schedule stability and quick rescheduling options. That persona-based design discipline is similar to the way great product teams tailor workflows in other industries; even seemingly unrelated guides like reading deep hardware reviews reinforce the value of metrics that actually matter to the user.

6) Multi-tenant security, privacy, and compliance considerations

Tenant isolation is not optional in healthcare platforms

If you are building a SaaS capacity platform for hospital groups, health systems, or regional networks, multi-tenancy must be designed as a security boundary, not just a billing concept. Each tenant should have explicit identity isolation, data partitioning, encryption separation where feasible, and auditable administrative access. Hospitals will ask hard questions about how data from one facility is prevented from appearing in another facility’s read model, how backups are segmented, and how cross-tenant analytics are governed. Those questions need architectural answers, not policy promises.

Use tenant-aware event routing and access control at every layer. The event bus should stamp tenant context on every message, the storage layer should enforce row-level or schema-level partitioning, and the UI should never infer tenant boundaries from the frontend alone. Role-based access control is necessary but not sufficient; sensitive operational data often requires attribute-based rules such as facility, unit, and job function. For hospitals evaluating cloud posture and compliance, the patterns in hybrid multi-cloud EHR hosting are directly relevant.

HIPAA, auditability, and data minimization

Capacity platforms often need less clinical detail than the EHR, which is good news for compliance. Only ingest the minimum necessary data required to support bed, OR, and throughput workflows. When possible, separate clinical identifiers from operational events, and use pseudonymization or tokenization in analytics pipelines. You should also maintain immutable audit logs for access, state changes, overrides, and model-driven recommendations. Those logs are critical not only for compliance but also for root-cause analysis after an incident.

Auditability should cover both humans and machines. If a user manually overrides a bed assignment, capture who did it, when, what they changed, and the reason. If a model triggers a recommendation, capture the model version, input snapshot, confidence score, and rule outcome. That level of detail improves trust and supports governance reviews. For a broader lens on healthcare data use and patient-facing data literacy, the guide harnessing AI for smarter medication management offers a useful example of controlled, outcomes-oriented healthcare analytics.

Threat modeling for event-driven healthcare platforms

Event-driven systems create new attack surfaces: message spoofing, replay attacks, tenant leakage, privilege escalation through admin consoles, and data exfiltration via logs. Secure the bus with mTLS, signed payloads where possible, short-lived credentials, and strict schema validation. Validate message provenance before a message can alter operational state. Treat external connectors as hostile by default, even if they originate from trusted hospital systems, because misconfiguration and drift are common in long-lived interfaces.

You should also plan for disaster recovery and degraded operation. If the predictive layer is offline, the core bed workflow must still function. If the FHIR connector fails, the platform should fall back to the latest valid projections and alert support teams. Security and resilience are intertwined here. A secure system that stops operating is not useful in a hospital, and a fast system that cannot be audited is not acceptable either. For additional perspective on safety-first engineering, the article cloud security stack planning provides a useful operational mindset.

7) Implementation roadmap: from pilot to production

Start with one hospital, one workflow, one measurable KPI

Do not attempt to replace every scheduling process at once. Start with one facility and one high-value workflow, such as ED-to-bed assignment or elective OR block utilization. Define a clear KPI such as boarding time, bed turnaround time, OR first-case on-time start, or PACU overflow rate. Then instrument the baseline before you automate anything. Without a baseline, you cannot prove value or know whether your event-driven platform improved the process.

At pilot stage, keep the domain model small. Focus on the few events that matter most, establish a canonical schema, and prove that the system can ingest, normalize, project, and present state within your latency target. If your platform cannot reliably handle admissions, discharges, and room readiness, adding more complexity will only magnify the problems. This disciplined rollout approach mirrors best practices in enterprise transformation, similar to the focused sequencing discussed in dedicated innovation teams.

Instrument observability from day one

Observability is not just technical hygiene; it is clinical operations support. Track message lag, event processing latency, projection freshness, error rates, dead-letter queue volume, model drift, and override frequency. Create runbooks for common failures such as stale projections, duplicate events, and interface engine outages. When stakeholders see that the system is monitored like a mission-critical service, trust increases dramatically.

Also measure business outcomes. If the platform reduces bed assignment time by 18% but does not improve transfer throughput, that tells you the bottleneck moved elsewhere. If OR schedule accuracy improves but PACU becomes overloaded, the solution needs downstream coordination. A mature capacity platform should surface these tradeoffs instead of hiding them. For teams that need help framing measurable system value, the ROI discipline in budgeting AI infrastructure is a helpful analogue.

Govern change management carefully

Healthcare workflows are socio-technical systems. Even a technically perfect solution can fail if nurses, bed managers, surgeons, and IT do not trust the recommendations or if the change process disrupts a delicate local routine. Run simulation sessions, shadow the current process, and validate edge cases with end users before go-live. Include exception handling for diversion events, isolation outbreaks, mass casualty surge, and temporary staffing shortages, because these are the moments when the platform’s value is most visible.

It is also worth creating a governance board that includes clinical ops, IT, security, compliance, and analytics. That group can decide which events are authoritative, which overrides are allowed, and how model changes are approved. Governance is not bureaucracy when the system is controlling scarce clinical resources; it is how you keep the platform trustworthy. For teams dealing with fast-moving technical change, the advice in upskilling for AI-driven technical change also applies to healthcare IT staff adopting event-driven methods.

8) Data model and implementation patterns you can use

A practical canonical event schema

Your canonical event schema should be simple enough for every connector to populate and rich enough to support analysis. At minimum, include event type, source system, tenant ID, facility ID, encounter ID, location ID, actor, timestamp, version, correlation ID, and payload. Add domain-specific fields such as bed status, OR room, scheduled start, expected discharge, and confidence score. If you store the raw source message alongside the normalized event, you improve traceability and future-proof your platform for reprocessing.

Consider separate topic families for clinical-adjacent operations and pure scheduling. For example, admissions and transfers can live in one set of streams, while OR cases and room turnover live in another. That separation can simplify consumer logic and access control. Use schema registry and strict versioning to avoid breaking downstream projections when source systems change. Reliable schema governance is just as important here as it is in other regulated workflows, including the careful data handling seen in health data literacy workflows.

Example pseudo-code for event handling

Below is a simplified example of how a write-side service might process a bed event and publish a projection update. The purpose is not the syntax itself, but the pattern: validate, persist, publish, project, and keep it idempotent.

function handleBedStatusChanged(event) {
  assertValidSignature(event)
  assertTenantAccess(event.tenantId)
  if (isDuplicate(event.id)) return

  appendToEventStore(event)
  publish("capacity.events", event)

  projection = buildBedProjection(event.bedId)
  updateReadModel("bed_status_read", projection)

  if (event.status === "READY" && projection.expectedDemandHigh) {
    emitRecommendation("reserve_for_admission", event.bedId)
  }
}

In a production system, this would include retries, dead-letter handling, schema validation, distributed tracing, and transactional outbox or equivalent patterns. The key is to separate the immutable event record from the current operational view. Once you build that discipline, adding new consumers becomes much safer and faster. This is one reason event-driven systems scale better than tightly coupled integration silos.

Table: Comparing common implementation approaches

9) What success looks like: metrics, ROI, and operating discipline

Measure operational outcomes, not just technical uptime

Technical SLAs matter, but healthcare leaders care about throughput, safety, and resource utilization. Track metrics such as ED boarding time, average bed turnaround time, OR start-time adherence, elective cancellation rate, transfer delay, and occupancy by service line. Tie those metrics to staffing and patient experience where possible. If the platform reduces friction without changing outcomes, you still may not have solved the right problem.

Make sure to monitor model quality as well. Predictive systems drift when patient mix changes, seasonality shifts, or local operations evolve. Calibration, precision, recall, and false-positive burden should all be reviewed with clinical stakeholders. The fastest way to lose trust is to let a model generate noisy recommendations that overload staff. The market trends we saw in hospital capacity management research and predictive analytics market growth make clear that the winners will be the platforms that operationalize these metrics credibly.

ROI comes from fewer delays and better utilization

ROI in capacity management often shows up in multiple places at once: more efficient bed utilization, fewer diversions, better OR throughput, less staff overtime, and fewer wasted blocks. One avoided elective cancellation can justify a surprising amount of platform investment, especially in high-margin surgical service lines. But the strongest argument is usually systemic: smoother flow improves staff satisfaction, which reduces burnout and turnover, and that affects the entire hospital. Good capacity software does not just move patients faster; it reduces operational chaos.

For a useful comparison, look at how other high-complexity operations treat scarce resources. In the same way that teams plan for equipment, deployment, and scheduling in high-stakes logistics planning, hospitals need coordinated control of scarce beds, rooms, and staff time. Capacity platforms make that coordination explicit and measurable.

Build for continuous improvement

A mature implementation should evolve with the hospital’s operating model. Add service-line specific rules, smarter predictions, better reason codes, and improved alerting over time. Capture user feedback directly in the workflow so the system can learn which recommendations were useful and which were ignored. That loop matters because the best hospital operations software becomes a learning system, not a static dashboard.

As you expand, consider whether some features should be tenant-specific, facility-specific, or standard across the network. Not every hospital will want the same thresholds or heuristics. A platform that respects local nuance while preserving a common core is much more likely to be adopted. That balance is the essence of scalable healthcare IT.

10) Conclusion: the future of capacity management is a living system

The next generation of hospital capacity management will not be a reporting tool bolted onto the EHR. It will be a living, event-driven coordination system that connects clinical truth, operational constraints, and predictive insight. FHIR and HL7 will remain essential, but they are inputs to the architecture, not the architecture itself. CQRS, event buses, and model-driven recommendations give hospitals the ability to respond in real time while maintaining auditability and security.

If you are evaluating or building this kind of platform, focus on one principle: the system must make the next operational decision easier, faster, and more trustworthy. That means clean event design, disciplined interoperability, strong tenant isolation, and predictions that map directly to action. For teams that want to go deeper into the supporting infrastructure and governance model, the reading list below offers several practical adjacent guides.

Pro Tip: In hospital capacity systems, the best architecture is the one that lets a charge nurse, OR scheduler, and compliance officer all answer the same question—“What changed, why, and what happens next?”—without pulling three different reports.

FAQ

Related Reading

• Architecting Hybrid Multi-cloud for Compliant EHR Hosting - Learn how to design healthcare cloud environments that satisfy compliance and availability needs.
• Veeva CRM and Epic EHR Integration: A Technical Guide - See how interoperability, governance, and data privacy shape enterprise healthcare integrations.
• Platform Playbook: From Observe to Automate to Trust in Enterprise K8s Fleets - A useful framework for operationalizing observable, resilient platforms.
• Harnessing AI for Smarter Medication Management - Explore a practical healthcare AI workflow with safety and outcomes in mind.
• Budgeting for AI Infrastructure: A Playbook for Engineering Leaders - Understand the cost and governance tradeoffs that matter when scaling predictive systems.