# Patient creation with SIU messages
URL: https://docs.awellhealth.com/docs/connect-systems/patient-creation-with-siu-messages

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



**SIU** (Scheduling Information Unsolicited) messages are Health Level Seven (HL7) messages that carry
appointment information between clinical and administrative systems. The hospital scheduling system
generates them, and Awell receives them.

It's the most automated way to connect a hospital: care flows follow appointments, and clinicians don't
manage them by hand.

## Appointment messages start, modify and cancel the care flow [#appointment-messages-start-modify-and-cancel-the-care-flow]

| Message     | Event                | What Awell does        |
| ----------- | -------------------- | ---------------------- |
| **SIU S12** | Appointment created  | Starts a care flow     |
| **SIU S14** | Appointment modified | Modifies the care flow |
| **SIU S15** | Appointment canceled | Cancels the care flow  |

The patient's care flow therefore tracks the appointment's real state, including cancellations.

## How the messages reach Awell [#how-the-messages-reach-awell]

SIU messages are processed by **Mirth**, which can run on the hospital side or the Awell side. See
[How Awell connects to other systems](/docs/connect-systems/healthcare-interoperability).

The hospital makes a location available for Awell to collect the messages from. Awell also needs a
virtual private network (VPN) to query the hospital for patient demographics, since an SIU message
carries appointment and identifier information rather than a full patient record.

## What to agree before building [#what-to-agree-before-building]

This integration spans two organizations, so the decisions below need agreement on both sides:

* **Which appointment types** should start a care flow. Not every booking should.
* **Which care flow** each appointment type maps to.
* **What happens on S14 and S15**, particularly whether a cancellation stops the flow or just a track.
* **The identifier** used to match the patient. See
  [Patient identifiers](/docs/connect-systems/patient-identifiers).

Agree these in a [swimlane diagram](/docs/connect-systems/emr-integration-terminology) before writing
any Mirth channels.

## Next steps [#next-steps]

**Next:** [Patient Demographics Query](/docs/connect-systems/patient-demographics-query) for pulling
the patient record itself.