Product overview
What you can build
Explains how Durin lets a hospital compose its own tools and widgets on top of the other tools' data, to cover its own specific needs.
Durin is the builder where a hospital composes its own tools and widgets on top of the other tools' governed data. It covers the specific needs a fixed tool list leaves open, so a hospital shapes the platform to its own way of working.
Composing over governed data
A tool is a full-screen application that opens from the dock. A widget is a compact panel a person pins to the desktop. Durin builds both by arranging building blocks over the platform's ontology, the working model of the hospital and its patients that every tool reads and writes through.
A built tool draws on the same record, orders, charges and hospital model as any shipped tool. It asks the record for what it shows rather than keeping its own copy, so the figures a built tool renders match the figures every other tool renders.
Tools and widgets
The two shapes cover two reading distances. A tool fills the screen for focused work. A widget sits on the desktop for a glance.
| Shape | Where it lives | What it suits |
|---|---|---|
| Tool | The dock, full screen | A board, a worklist or a review a role returns to. |
| Widget | Pinned to the desktop | A stat card or short list a person watches through a shift. |
The building blocks
A built tool is assembled from building blocks laid on a canvas. Each block reads governed data and renders one part of the screen.
| Building block | What it renders |
|---|---|
| Table | A list of the records the viewer is entitled to see. |
| Detail panel | One record opened for reading. |
| Form | A structured entry that writes back through the record. |
| Chart | A governed metric drawn from analytics. |
| Action | A control that places an order, opens a form or starts a process. |
| Filter | A control that narrows the records on show. |
What a tool reads
A tool binds to the ontology surface a hospital already runs on. It reads the record, the orders and charges an encounter carries, the hospital model of sites, units and beds, and the metrics analytics prepares.
Diagnoses, results, documents and consent, read through the record tool.
What is ordered for a patient and where each order stands.
The billable consequences of care, priced as they stood.
Sites, units, beds, services, people and roles.
Governed numbers carrying their lineage, from analytics.
The stat cards a widget shows are the same governed numbers analytics defines, so a built widget and an analytics stat card agree by construction.
Where a tool lives
A published tool appears in the dock beside the shipped ones. A published widget pins to the staff desktop. Both resolve against the same access decision as every other surface, so each person holds only the tools their role and relationships allow.
Covering the specific needs
Every hospital carries work that a fixed tool list leaves open: a ward-round board shaped to one unit, a discharge tracker one department reads, a follow-up list a clinic keeps. Durin gives that work a home on the same governed data, so a hospital extends the platform by composition.
One model, many tools
A built tool reads and writes the same ontology as the shipped tools. A bed that moves in the hospital model, or a role that changes in access control, is understood by a built tool at once, because one model sits underneath them all.
Common questions
Do I write code to build a tool?
You arrange building blocks on a canvas and bind them to governed data. The composition carries the platform's behaviour without a line of code.
Where does a built tool get its data?
From the same record, orders, charges and hospital model every shipped tool reads. A built tool asks the record for what it shows rather than storing its own copy.
Can a widget and a tool share the same data?
Yes. Both bind to the one ontology, so a widget and a tool built on the same figures stay in step.
Follow the steps to compose a tool in Durin.