Why Integration Pattern Matters
A dosing model can produce a technically sound recommendation and still fail to help a clinician if the necessary data cannot reach it at the right point in care, or if the result returns through a channel the clinician does not use. Integration pattern describes the operational route between clinical systems and a dosing service: how a request or event is sent, how a response is returned, and where a person sees or acts on it.
For example, a clinician might request a calculation while reviewing a patient’s chart. That interaction suits a different exchange pattern from a service that receives a stream of laboratory results and later notifies a care team that a review is due. Neither pattern is universally best. The design decision depends on who initiates the exchange, how quickly the result is needed, what happens when a component is unavailable, and where responsibility for the next action sits.
The earlier material on harmonizing clinical data semantics addresses what exchanged data mean. This tutorial focuses on the operational patterns that carry patient data and recommendations between systems. The pattern does not, by itself, guarantee that the exchanged content is complete, correctly interpreted, or clinically appropriate.
Three Patterns and Their Boundaries
These categories are useful, but they are not mutually exclusive technical layers. An embedded dosing app can retrieve chart data through an API. A background service can publish a recommendation event to a message broker, while an EHR-embedded view retrieves the recommendation through an API when a clinician opens the chart. A complete design should name both the user-facing interaction and the underlying exchange mechanism rather than treating “embedded” as a transport protocol.
A typical synchronous API flow is: the requesting system sends a request; the service validates and processes it; and the service returns a response or an error. The requesting workflow waits for that response, at least long enough to receive a result or determine that the request did not complete in time. This is attractive when a clinician explicitly asks for a recommendation and needs the answer before continuing.
A typical message-based flow is: a producer publishes a message; infrastructure stores or routes it; and a consumer processes it independently. The producer may receive confirmation that the message was accepted by the broker without waiting for the dosing calculation to finish. A later message, notification, or user-facing query can make the result available. This decoupling helps absorb bursts and temporary consumer outages, but it introduces questions about queue delay, acknowledgement, retries, and duplicate delivery.
An embedded flow places the dosing task near the chart review or ordering activity where it is relevant. It can reduce navigation and make the patient context visible, but it depends on the EHR’s supported extension points, access controls, and user-interface conventions. It does not automatically make the calculation synchronous: the embedded component could call an API, wait for a result, or display a result produced asynchronously.
Assumptions for Comparing Patterns
A meaningful comparison assumes that all candidate patterns exchange the same clinically intended inputs and recommendation content, and that each has an agreed responsibility boundary. In particular, a returned recommendation is not automatically an order. The clinician-facing workflow should make clear whether the result is informational, requires review, or is being accepted into a separate ordering process.
The exchange also needs a defined contract: which system initiates the interaction, what response or acknowledgement means, how errors are surfaced, and who monitors failures. The earlier semantic work informs the meaning of the payload; the interface design must still ensure that systems interpret the agreed contract consistently. The calculations below use hypothetical operational values, not measured performance claims.
Worked Example: Checking Whether a Synchronous API Fits a Point-of-Care Request
Suppose a clinic wants a clinician to request a dose recommendation while a patient chart is open. The workflow team sets a hypothetical maximum wait of 3.0 seconds for the result to appear. In a test environment, chart-data retrieval takes 0.8 seconds, calculation takes 0.7 seconds, and rendering the result takes 0.5 seconds. The API exchange adds 0.3 seconds.
Assumption. Treat these four durations as sequential parts of one request, with no retries and no additional queueing. This is a simplified latency budget, not a claim that actual latency is constant.
Calculation. The total expected path under these assumptions is:
The 2.3-second total is 0.7 seconds below the 3.0-second target. On this estimate, an API request-response interaction is a plausible fit for the immediate workflow. However, an average or single test result does not establish that the service meets the target during slowdowns. The team would also need to observe the distribution of response times under representative load and decide what the clinician sees if the request exceeds the permitted wait.
If the user’s workflow cannot wait for a result, a background message might be more appropriate, but it would change the interaction: the recommendation would need to become available later and the clinician would need a reliable way to find it. Simply replacing an API with a message does not preserve an immediate response.
Reliability, Coupling, and Failure Behavior
Synchronous APIs couple the requesting workflow to the availability and response time of the service. If the service is unavailable or slow, the request may fail or time out while the clinician is waiting. A timeout means that the caller did not receive a response within the configured interval; it does not necessarily prove that the service did no work. The caller therefore needs a clear recovery path and must avoid presenting an ambiguous request as a confirmed recommendation.
A message broker can decouple producer availability from consumer availability: a broker may retain an accepted message while the consumer is temporarily offline. This benefit depends on the broker, its configuration, and operational monitoring. It does not mean that a message has been processed, that a recommendation exists, or that a clinician has seen it. Those are separate states and should not be represented by the same acknowledgement.
A useful reliability calculation illustrates why every dependency matters. Suppose a synchronous path needs both a data API and the dosing service to be available at the same time. Assume, for illustration, that their availabilities are 99.5% and 99.8%, and that their availability events are independent. The probability that both are available is the product of their availabilities:
That is 99.301% availability for this simplified two-component path. The independence assumption is important: shared infrastructure, shared network failures, or correlated maintenance can make the product calculation inappropriate. The calculation also says nothing about whether an available service returns a clinically usable result. It shows why a workflow relying on several components can be less available than any one component alone.
Worked Example: Estimating Message-Queue Recovery Time
A hypothetical dosing service receives 3 messages per minute during a busy period. A consumer is offline for 6 minutes, then restarts and can process 6 messages per minute while new messages continue to arrive at the usual rate. Assume messages are not discarded, the arrival rate stays constant, and the consumer processes messages in order.
Backlog created. During the outage, the broker receives:
Net backlog reduction after restart. The consumer handles 6 messages per minute, but 3 new messages arrive each minute. The backlog therefore shrinks by:
Recovery time. At that net rate, clearing 18 queued messages takes:
This estimate is valid only while the stated rates and assumptions hold. If arrival rates equal or exceed processing capacity, the backlog will not clear. Operational monitoring should therefore distinguish a consumer that is running from one that is keeping pace with its incoming work. The service also needs a defined policy for retries and duplicate deliveries: message systems may deliver a message more than once, so processing should be designed not to create duplicate clinical actions.
Where the Clinician Encounters the Result
The main advantage of EHR embedding is often workflow proximity rather than a particular data-transfer mechanism. A recommendation displayed in the relevant chart context can reduce navigation and make its relationship to the active clinical task easier to recognize. An embedded interface may also support an explicit handoff, such as asking the clinician to review a recommendation before deciding whether to act.
Embedding has costs. The EHR may limit how the component can be launched, what context it can receive, how it can display content, or how it can be maintained. A UI change can disrupt a workflow even when the underlying API remains available. An external service with a separate user interface may be easier to evolve, but clinicians may need to switch applications, re-establish context, or locate the result later.
Worked Example: Estimating the Effect of an Embedded Workflow
A clinic estimates that opening a separate application, finding the relevant patient, and returning to the chart takes 45 seconds per dosing consultation. A proposed embedded workflow is estimated to take 8 seconds for the same navigation steps. The clinic expects 24 such consultations in one working day. Assume, for this simple calculation, that the time estimates apply to every consultation and exclude the time spent interpreting the recommendation.
Time difference per consultation.
Estimated daily navigation time saved.
Converting units gives \(888 \div 60 = 14.8\) minutes per working day. This is an estimate of navigation time, not a measured reduction in errors, a guarantee of adoption, or evidence that the recommendation is clinically better. A pilot should check whether the actual embedded interaction works in the intended context and whether the time saved is offset by other workflow steps.
Choosing and Combining Patterns
| Design question | API request-response | Message-based exchange | EHR-embedded interaction |
|---|---|---|---|
| Who initiates? | Often a user-facing system or another service making a request | Often a producer publishing an event or task | Usually a clinician interacting in the chart, though results can be precomputed |
| When is a result expected? | During the request, subject to a timeout | After asynchronous processing; arrival time can vary | When the embedded interface retrieves or displays it |
| Main operational strength | Direct request and response with a clear immediate interaction | Decoupling and buffering across temporary service interruptions | Proximity to the clinician’s chart workflow |
| Main operational risk | Slow or unavailable dependencies interrupt the waiting workflow | Queue delay, duplicate processing, or unobserved unprocessed work | Dependence on EHR extension points and interface behavior |
The comparison is not a ranking. A design may use an API for a clinician’s explicit request, messaging for background work, and an embedded component to present the result. The important question is whether each part has a defined purpose and a safe failure behavior. For an immediate dose decision, an asynchronous result that appears after the clinician has left the encounter may be poorly timed even if message delivery is technically reliable. Conversely, forcing a non-urgent background task to hold an active UI request open can unnecessarily couple the workflow to processing time.
A selection process can be made explicit:
Identify whether a clinician is actively requesting a recommendation or whether a system is reporting an event for later processing.
Specify whether the result must be available before the current interaction can proceed, and define what the user sees if it is delayed or unavailable.
Decide whether the result belongs inside the EHR workflow or whether a separate interface and notification are operationally acceptable.
Distinguish request accepted, work completed, result available, result viewed, and recommendation accepted. Define monitoring and recovery for failures between those states.
Diagnostics, Pitfalls, and Limits
A design is going wrong when its operational signals do not match the promises made to users. For an API, examine response-time distributions, timeout rates, error rates, and whether timed-out requests later complete. For messaging, examine queue depth, message age, processing rate, retry volume, and the handling of repeated deliveries. For an embedded workflow, observe whether clinicians can reach the feature in the intended chart context, whether results are visible when expected, and whether interface failures are distinguishable from calculation failures.
- Confusing acceptance with completion. A broker acknowledgement may confirm that a message was accepted for delivery; it does not establish that a dosing calculation finished or that anyone reviewed it.
- Treating a timeout as proof of no action. The caller may have stopped waiting even though the service continued processing. Design retries so they cannot silently create a second recommendation or action.
- Assuming asynchronous means reliable. A queue can buffer work, but it can still be misconfigured, delayed, or unmonitored. Verify that messages are processed and that failures are visible to an accountable operator.
- Calling a separate application “integrated” because it can open. If the clinician must manually reconstruct context or search for the result, the technical connection may not provide a usable workflow.
- Choosing solely by technical preference. An elegant interface is not a fit if its response timing or location conflicts with how the recommendation is used.
These patterns do not resolve every implementation concern. They do not, by themselves, establish the quality of patient inputs, the correctness of their timing, or the validity of model execution. Nor do they ensure that a recommendation is displayed clearly or that a clinician understands its uncertainty. Those are separate design and verification responsibilities. The integration pattern should make the handoff explicit, observable, and recoverable without implying that delivery alone equals clinical action.
Check Your Understanding
Answer each question, then compare with the solutions.
- A clinician requests a result and must see it before proceeding. Which interaction pattern is a natural starting point, and what failure condition must be designed for?
- A message consumer processes 10 messages per minute while 4 new messages arrive per minute. How quickly will a backlog of 30 messages clear, assuming constant rates?
- A team says a message was “completed” because the broker acknowledged it. What distinction should the team make?
- A separate dosing application calls the EHR’s API but opens outside the chart. Is this necessarily an EHR-embedded interaction? Explain.
Solutions. (1) A synchronous API request-response is a natural starting point because the user is waiting for the answer. The design must handle a slow or unavailable service, including a timeout, without presenting an ambiguous request as a confirmed recommendation. (2) The net backlog reduction is \(10 - 4 = 6\) messages per minute, so the backlog clears in \(30 \div 6 = 5\) minutes under the stated assumptions. (3) Broker acceptance is different from consumer processing, result availability, and clinician review; the acknowledgement should be described only as the state it confirms. (4) No. Calling an EHR API describes an exchange mechanism, but opening outside the chart does not necessarily provide an EHR-embedded user interaction. The interface may still require the clinician to switch applications and re-establish context.