# Get started
URL: https://docs.awellhealth.com/docs/get-started

> For the complete documentation index, see [llms.txt](https://docs.awellhealth.com/llms.txt).





Organizations adopt Awell to change something specific about how care happens, and to be able to show
that it changed: cost per episode, patients seen without adding staff, a quality measure that has to
improve this year.

Awell coordinates what happens to a patient over time: which form goes out when, who reviews it, and
what happens if nobody responds.

## Awell is built for a methodology called CareOps [#awell-is-built-for-a-methodology-called-careops]

The practice behind the product is called [CareOps](https://www.careops.org/), and it has a public
community and a lifecycle. It does for care delivery what DevOps did for software, by bringing clinical
experts, clinical operations, engineering, product and compliance into one loop instead of handing
documents between them.

The loop repeats rather than running once:

1. **Design & Validate.** Work out what should happen, and check it with the people who will do it.
2. **Build & Operate.** Put it into software that patients and care teams actually use.
3. **Monitor & Prove.** Watch what happens, and show which changes improved results.
4. **Rinse, Repeat.** Feed the evidence back into the design.

A care process can stop after the second stage, or never leave a document at all. The platform is built
for closing that loop: shortening the time between deciding a process should change and patients
experiencing the new version.

The navigation follows the same loop. **Design** is where care flows are built, **Operate** is where they
are delivered, **Monitor** is where they are watched, and **Improve** is where the evidence comes back.

<img alt="The Awell platform home, with the left navigation expanded to show Design, Operate, Monitor and Improve and the sections beneath each" src="__img0" />

## What teams use it to change [#what-teams-use-it-to-change]

* **Capacity.** Intake once collected by phone is collected by the care flow, so the same team takes on
  more patients without adding people.
* **Speed of change.** The operations team adjusts a care flow itself, rather than raising a ticket and
  waiting for an engineering cycle.
* **Quality and compliance.** Every eligible patient gets the reminder, the appointment, and the
  follow-up, so a reporting requirement is met without anyone chasing it by hand.

Deciding which of those to aim at, and how to measure it, is covered in
[Decide what to improve](/docs/improve-and-analyse/decide-what-to-improve), which is worth reading before
building rather than after.

## Read the pages in order [#read-the-pages-in-order]

This section explains the ideas the rest of the docs assume, then points to the right path.

## Concepts to read first [#concepts-to-read-first]

1. **What is a care flow?** The central idea: a plan of activities that runs itself.
2. **Awell platform overview.** Studio, Care, Panels, and the Orchestration API, and which one each
   role works in.
3. **Key terms.** The words these docs use precisely, so every page means the same thing by them.

## After that, the path depends on the role [#after-that-the-path-depends-on-the-role]

**Care flow authors** decide what should happen, for whom, and when, in clinical and operational
terms. Continue to **Design care flows**.

**Engineers** wire care flows to electronic health records, APIs, and data warehouses, so every
activity has real data behind it. Continue to **Connect systems** or **Automate with events**.

The two paths cross constantly: pages aimed mainly at engineers say so, and pages that need an
engineer's help say where to hand off.