erroredpathwaysApplied when an automation pathway encounters an error and stops.
Tags
MedFlow ships a standard set of tags for use in queries and pathway logic. Each tag attaches to either a patient or a pathway, and you reference them in the queries that feed search triggers.
Tenant tag rules
Section titled “Tenant tag rules”Beyond the standard set, each tenant can define its own patient tags as rules in Tags Management → Tenant Config. Rules are grouped by the data they read, and every rule names an evaluator (eq, eqAny, includes, includesAny), a field, one or more labels to match, and the tag to stamp. The nightly import recomputes every patient’s tags from scratch, so a rule’s tag appears the night after the rule is saved and disappears the night after it is removed.
| Category | Reads | Fields |
|---|---|---|
patient | The patient record, and the patient’s last assigned provider | postalCode, providerId |
appointments and the timed variants (incoming, upcoming, future, past, pastCompleted, pastMissed, recent, pastQuarter, pastYear) | Appointments, including visits converted from encounters, optionally limited to some statuses | type, reasonCode, departmentId, providerId |
diagnosticReports | Lab and diagnostic reports, optionally inside a withinDays or withinCalendarYear window | codeText, loincCode, orderTypeCode |
conditions | Active, confirmed diagnoses | icd10Code |
encounters | Encounter procedure codes | cptCode |
workflows | Pathway runs cloned from a process diagram | sourceId |
Workflow runs
Section titled “Workflow runs”A workflows rule tags a patient who has a run of a given process. The label is the process diagram’s id (the id in the diagram’s URL, not its name). By default only completed runs count: a run the trigger has queued but not yet executed has not done anything for the patient, so it does not earn the tag. Set statuses to change that deliberately, for example ["running", "completed"] to include runs still in progress. Use eqAny with several ids to cover more than one process with a single tag.
A run can complete without doing the thing the tag is named for, for example by taking a branch that skips the patient case, and it can error after that step already happened. When the tag means “this step happened”, set automationKey to that automation’s key (the rule editor lists the automations by name). A run then counts only when an automation with that key completed in it, on any node that carries it, and statuses applies to the automation instead of the whole run.
A common use is campaign follow-up: patients who already received the first campaign’s patient case are tagged campaign-1-sent, and the next campaign’s cohort excludes them with without #campaign-1-sent.
{ "workflows": { "tags": [ { "evaluator": "eq", "field": "sourceId", "tag": "campaign-1-sent", "label": "0c6a4c7e-2b1e-4ab9-9f0e-1d2b3c4d5e6f", "automationKey": "<automation key>" } ] }}The tag must also exist in the Tag library (Tags Management → Add Tag) before the search autocomplete will offer it; the rule editor warns when it does not.
Timing. The nightly import computes the tag, while search triggers run every hour. A patient who joins both cohorts on the same day can get both patient cases before the tag exists. Run campaigns that exclude each other one after the other: turn the earlier campaign’s trigger off, let one nightly import run, then turn the next campaign’s trigger on.
One-off runs only. Every run of a named process is read again on each nightly import. Point workflows rules at processes that run once per patient, such as a campaign. A process whose trigger repeats adds a run for every patient each period, so the nightly read keeps growing; the import logs a warning when a rule names one.
Appointment department and status
Section titled “Appointment department and status”An appointment rule can match where a visit is booked. departmentId is the department id on the appointment’s location, written as a string label such as "150", not the department’s name. An appointment that carries no department never matches a departmentId rule.
Any appointment rule can also take statuses, the appointment statuses that count: booked, arrived, checked-in, fulfilled, noshow, cancelled, and the rest of the FHIR set. Without it, every appointment in the category counts whatever its status, cancelled ones included, which is how appointment rules have always worked. ["booked"] counts what the built-in upcoming-appointment tag counts.
For example, to keep patients who are already booked at one clinic out of a campaign, tag a booked appointment at that clinic’s department under futureAppointments, which counts a booking on any future date, then add without #<tag> to the campaign’s cohort. Use upcomingAppointments instead only when a booking 48 hours to 8 days out is what matters. Like any tenant tag, the tag also needs a Tag library entry.
A department tag only sees bookings. It does not say where a patient is registered, and it misses a booking the EHR feed has not delivered yet. When that matters, keep a live check of the patient’s current department in the workflow and use the tag to narrow the cohort.
{ "futureAppointments": { "tags": [ { "evaluator": "eq", "field": "departmentId", "tag": "booked-at-north-clinic", "label": "150", "statuses": ["booked"] } ] }}Provider
Section titled “Provider”A providerId rule tags patients by provider. The label is the provider’s id in your EHR, written as a string, such as "69". A provider’s name never matches.
In the patient category, providerId is the patient’s last assigned provider: the same provider the built-in latest-provider-assigned tag records, which is the provider of the latest completed visit, replaced by the provider of the soonest booked future visit when there is one. A patient with no completed visit and no booked visit has no last assigned provider and never matches. This is the rule to use when a workflow should only reach, or should skip, one provider’s panel.
In an appointment category, providerId is the provider on each appointment, and statuses applies as for departmentId. Use it for “has a booked visit with this provider” or “was seen by this provider in the past year” rather than for the patient’s current provider.
{ "patient": { "tags": [ { "evaluator": "eqAny", "field": "providerId", "tag": "panel-of-pilot-providers", "label": ["69", "71"] } ] }}Like any tenant tag, the tag needs a Tag library entry. A cohort then narrows to the panel with #panel-of-pilot-providers, or keeps it out with without #panel-of-pilot-providers.