How Panels stores data
Panels keeps its data as FHIR resources, the standard the rest of healthcare already speaks, which is why a row updates the moment something changes and why one panel can serve many facilities without duplicating it.
A panel looks like a spreadsheet, but underneath it is a clinical data store. Everything a panel shows is held as FHIR resources — Fast Healthcare Interoperability Resources, the international standard for describing patients, tasks, encounters and results. See How Awell connects to other systems for what FHIR is used for elsewhere in the platform.
Most teams never need to know this. Where it shows up is what a row is made of, how quickly it changes, and who can see it.
A panel is built from FHIR resources
A published care flow writes as it runs, and what it writes lands in the store as resources with standard meanings rather than as columns in a private table.
| Resource | What it holds in a panel |
|---|---|
| Patient | The person the row is about, and the profile behind it |
| Task | A piece of work waiting on someone — the rows of a panel in task mode |
| Encounter | A hospital stay: admission period, discharge date |
| Observation | Something measured or recorded, such as the outcome of an outreach call |
| Communication | A message sent to a patient or a member of the care team |
| CarePlan | What the patient is enrolled in |
A column in a panel reads from these. So a days since discharge column is counting from a discharge date held on an Encounter, not from a date somebody typed into a sheet.
A care flow is not the only thing that writes
Data from other systems can land in the same store and appear in a panel beside what a care flow collects: ADT feeds, labs, claims, pharmacy data, patient-reported data. Each of those is an integration Awell builds, not something a team connects from inside the app, so ask support@awellhealth.com about a source you need.
Standard resources mean the data keeps its meaning
A discharge date stored as a FHIR Encounter means the same thing to the next system that reads it
as it does to the panel. Data arriving from elsewhere and data written by a care flow end up
described the same way, so a team can build a column on either without knowing which is which.
The store answers FHIR queries directly
Because a panel's data is FHIR, it can be read as FHIR. A team's own systems can query the store directly rather than scraping a panel or waiting for an export, and get back resources any FHIR client already understands.
Panels is the only part of the platform that works this way. The Orchestration API is not a FHIR server, as How Awell connects to other systems explains.
Rows update on change, not on a refresh
The store emits an event whenever a resource changes, and only the panel rows affected by that change are updated. That is why a panel is current when someone opens it, and why nobody has to re-run an export to see this morning's work.
One panel can serve many facilities
Access policies scope what a person sees, patient by patient, over the same panel and the same views. Two facilities can work from one shared setup and each see only their own patients, while someone with enterprise scope sees all of it — without a separate panel, or a separate database, per facility.
Next steps
Next: Build a panel, to turn these resources into the columns a team works from.
Panels and views
A panel holds the columns and settings; views built on it are tailored for a particular job. Which changes affect everyone, and which affect one view.
Build a panel
Describe the columns a team needs in plain language and the column builder finds them in the data underneath, then arrange, calculate and filter until the panel is the worklist for one job.