Turning Clinical Data Into Actionable Care Workflows

Healthcare teams usually have the information they need inside their EMR. What they often do not have is that information arranged so a clinician or a manager can see, at a glance, what needs attention, which patients need follow-up, what has happened recently and what is coming next. Ayeim built a dedicated microservice and dashboard around OpenEMR that brings the relevant data together and turns it into prioritized workflow views — one for clinicians, one for managers.

The challenge

The problem was not the absence of a dashboard. It was that understanding a patient’s current situation meant moving between several places: recent activity, previous interactions, the upcoming schedule, how severe the patient’s situation is, and risk- and RAF-related information.

Each of those existed. Pulling them together into a picture of “what needs to happen next” was manual work, repeated for every patient and every shift.

Why traditional reporting was not enough

A reporting screen answers “what does the data say?” It leaves the user to read it, connect the parts, and decide what to do. For a team working through a list of patients, that is the slow step.

The objective here was a workflow-oriented view, not another static report — information organized around the decisions and actions the user needs to take, with the priorities already surfaced.

The Ayeim approach

Ayeim built a dedicated microservice responsible for processing the relevant healthcare data and giving the dashboard exactly what clinicians and managers need. The processing chain, conceptually:

The important decision was to keep the dashboard and its processing logic in a dedicated service rather than building it directly into the core application.

The clinician experience

The clinician dashboard is a consolidated view of relevant patient activity and upcoming actions. Where the implementation supports it, that includes recent interactions, upcoming schedule dates, a patient severity indicator, prioritized patients, and relevant risk- and RAF-related information.

It is built to help a clinician answer practical questions: who needs my attention, what happened recently, what needs to happen next, and which patients should I prioritize.

The dashboard surfaces information and calculated indicators to support that workflow. It does not diagnose patients and it does not replace clinical judgment.

The manager experience

The same underlying data supports a management view. Managers can use it to understand patient activity, the workload coming up, how patients are distributed by severity, current workflow priorities, RAF-related information, and overall operational activity.

It is built to help a manager answer: what is happening across the organization, where is attention required, what workload is coming, and which patient groups need closer operational attention.

How severity is calculated

One of the core capabilities is a patient severity indicator. The microservice takes the relevant patient information available to it and applies the configured severity logic to produce that indicator.

The severity indicator is an application-generated calculation, intended to support workflow prioritization. It is not an autonomous medical assessment, and it is presented as one signal among several.

How RAF-related information is calculated

The microservice also processes the relevant information to calculate or surface RAF-related information — Risk Adjustment Factor (RAF) information — and presents it on the dashboard alongside the other patient indicators.

This is workflow visibility, not a financial guarantee. The system does not claim to guarantee reimbursement outcomes, change CMS scores, increase revenue or ensure coding compliance. It makes RAF-related information visible next to the rest of the picture so it is not something the team has to go and look for separately.

How messages contribute to the workflow

Messages are one of the inputs the configured logic considers, where applicable. A message can carry activity or a signal that matters in a patient’s ongoing workflow, so the processing chain looks like:

Patient activity + messages + relevant patient information + scheduling information → processing → severity / RAF-related indicators → prioritized dashboard.

Not every message represents clinical severity. Messages are considered by the configured rules alongside the other inputs, and how much weight they carry is part of that configuration.

Prioritizing upcoming schedules

The dashboard also helps users see upcoming schedule dates in light of patient severity — a patient, their severity indicator, and the relevant scheduling information, resolved into a prioritized view of the next activity.

That answers the second half of the question. Not just “what happened?” but “what needs to happen next, and for whom first?” The system surfaces and prioritizes schedule information; it does not autonomously schedule care.

The microservice architecture

OpenEMR remains the system of record. A separate dashboard microservice consumes the relevant data, events and inputs, does the processing, and serves both dashboards from one place.

The infrastructure and stack are chosen to fit the environment; the architectural point is the separation, not a particular technology.

Why we chose a microservice

Treating the dashboard as a distinct capability — with its own processing and its own presentation requirements — had practical benefits:

• Separation of responsibilities from the core application.
• Processing logic that can evolve on its own.
• A reusable data service rather than logic duplicated per screen.
• The same underlying service feeding two different user experiences.
• Less coupling, so dashboard changes do not mean core-application changes.

The dashboard was not a feature bolted onto a reporting page. It was built as its own thing, because that is what it is.

From reporting to action

Traditional reporting goes: data → report → the user interprets it → action. The user does the interpreting.

This approach goes: data → process → calculate → prioritize → dashboard → action. The interpreting that can be encoded is done before the screen is drawn.

The value is not more information on screen. It is information organized around the decisions the user has to make.

Before vs after

The previous setup was usable. The change is in how quickly a person can see what matters.

The engineering challenge

The hard part was not building charts. It was deciding:

• Which data actually matters for the decision at hand.
• How the different data points relate to each other.
• How severity should be represented as a single, usable indicator.
• How messages should contribute to the workflow, and how much.
• How upcoming schedules should be surfaced against severity.
• How RAF-related information should be represented alongside the rest.
• How one underlying service should serve both clinicians and managers.

The UI is the visible part. The real work is behind it.

The result

• A centralized dashboard giving clinicians and managers a more actionable view of patient activity, upcoming schedules, severity and RAF-related information.
• A microservice that acts as a reusable processing layer — different dashboard experiences without duplicating the underlying logic.
• A shift from navigating information to working from prioritized information.

Business value

The solution helps an organization move from “where is the information?” to “what needs attention?” In practice that means:

• Better information visibility for the people doing the work.
• More structured, prioritized workflows.
• Easier operational monitoring for managers.
• A reusable architecture that further dashboard needs can be built against.

Improved patient or clinical outcomes are not claimed here; that would need to be independently demonstrated. The claim is about information visibility and workflow organization.

Technologies and capabilities

OpenEMR engineering, healthcare technology, microservice architecture, data processing, rule-based calculation, clinical-workflow support, dashboard engineering and integration — designed around how the organization needs to work, not around the data that happened to be available.

Related OpenEMR services

• OpenEMR Integration
• OpenEMR Customization
• OpenEMR AI Solutions
• OpenEMR Services overview