It helps clinics log, review, investigate, and resolve events that may affect patient safety, client experience, staff safety, equipment reliability, medication handling, surgical outcomes, or clinic operations.

QI Events are not about blame. They are about visibility, accountability, follow-through, and improvement.

Use Clinical Intelligence when something happens that should be documented, reviewed, resolved, or learned from.

What Clinical Intelligence Does

Clinical Intelligence helps your clinic:

• Log quality improvement events

• Track adverse events

• Categorize events by type

• Set severity

• Confirm patient or system context

• Add investigation notes

• Maintain an investigation timeline

• Track open, in-review, and resolved events

• Search events by patient, staff member, or event details

• Resolve events after review

• Create an audit trail for quality improvement

This is the clinic’s “catch it, document it, learn from it” layer.

Main Areas

Clinical Intelligence includes:

• Event list

• Search

• Status filters

• Event details

• Original report

• Investigation timeline

• Investigation notes

• Log Event workflow

• Resolve action

Event List

The event list shows logged QI or adverse events.

Each event may display:

• Severity

• Event title

• Short description

• Patient or case context

• Event category

• Time since report

• Current status

Use the event list to quickly see what is open, what has been resolved, and what needs review.

Search Events

The search bar allows users to search events by:

• Event title

• Patient name

• Staff member

• Event details

• Category

• Notes

Use search when reviewing a specific incident, patient, staff report, or event type.

Status Filters

Status filters narrow the event list.

Available filters may include:

• Open

• Resolved

• All

Open

Open shows events that still need review, follow-up, investigation, or resolution.

Open events should not sit indefinitely. If it matters enough to log, it matters enough to close the loop.

Resolved

Resolved shows events that have completed review and have been marked resolved.

Resolved does not mean “nothing happened.” It means the clinic reviewed the event and completed the required follow-up.

All

All shows open and resolved events together.

Use this for historical review, trend analysis, or audit purposes.

Event Status

QI Events may move through different statuses as they are reviewed.

Common statuses include:

• Open

• In Review

• Resolved

Open Status

Open means an event has been logged but has not yet completed review.

An open event may still need:

• Investigation

• Staff follow-up

• Patient review

• Client communication

• Medical record review

• Management review

• Corrective action

• Resolution

In Review Status

In Review means the event is actively being reviewed.

This may include:

• Reviewing the original report

• Talking with involved staff

• Reviewing the medical record

• Checking medications, equipment, or workflow logs

• Adding investigation notes

• Determining next steps

Resolved Status

Resolved means the clinic has completed the review process and closed the event.

Before resolving, confirm that any needed action has been completed or assigned.

Severity Levels

Severity indicates the seriousness of the event.

Common severity levels include:

• Low

• Medium

• Critical

Low Severity

Low severity events are minor issues that should be documented but may not require urgent escalation.

Examples:

• Minor workflow miss

• Documentation correction needed

• Small communication breakdown

• Non-urgent client concern

• Minor equipment inconvenience

• Near miss with no harm

Low severity does not mean irrelevant. Small cracks become expensive architecture if ignored.

Medium Severity

Medium severity events require review and follow-up.

Examples:

• Medication process concern

• Surgical workflow issue

• Patient care concern

• Client complaint requiring manager review

• Equipment failure affecting workflow

• Staff safety concern

• Near miss with meaningful risk

Medium severity events should be reviewed promptly.

Critical Severity

Critical severity events require immediate attention.

Examples:

• Patient death or serious harm

• Major medication error

• Surgical complication requiring urgent review

• Staff injury requiring escalation

• Severe client safety issue

• Controlled substance issue

• Major equipment failure affecting patient care

• Serious adverse event

Critical events should follow clinic escalation policy immediately.

Log Event

Log Event starts a new QI event report.

Use this when something happens that should be documented, reviewed, or escalated.

The Log Event workflow may include:

1. Choose what happened

2. Confirm system or patient context

3. Add event details

4. Select severity

5. Choose reporter identity

6. Submit the event

Event Categories

When logging an event, choose the category that best describes what happened.

Available categories may include:

• Medication

• Surgical

• Patient Event

• Client Issue

• Staff Injury

• Equipment

• Other / Uncategorized

Medication Event

Use Medication for events involving medications, prescriptions, dosing, dispensing, labeling, administration, refills, or pharmacy workflow.

Examples:

• Wrong medication selected

• Wrong dose entered

• Missed medication

• Dispensing error

• Labeling issue

• Controlled substance concern

• Medication given late

• Refill process issue

• Allergy or contraindication concern

Medication events should be reviewed carefully because they can affect patient safety and compliance.

Surgical Event

Use Surgical for events involving surgery, anesthesia, perioperative workflow, recovery, complications, or surgical documentation.

Examples:

• Surgical complication

• Anesthesia concern

• Incorrect surgical prep

• Instrument issue

• Recovery complication

• Consent issue

• Delayed surgical start

• Missing surgical checklist item

• Unexpected intraoperative event

Surgical events should usually include timeline notes and clinical review.

Patient Event

Use Patient Event for events involving patient safety, care delivery, handling, condition changes, or adverse outcomes.

Examples:

• Patient fall

• Bite or scratch involving patient handling

• Unexpected clinical decline

• Escape or near escape

• Missed treatment

• Delayed care

• Adverse reaction

• Incorrect patient workflow

• Patient identification concern

Client Issue

Use Client Issue for events involving client communication, client conflict, consent concerns, billing disputes, complaint escalation, or client experience.

Examples:

• Client complaint

• Miscommunication

• Consent concern

• Estimate misunderstanding

• Service recovery issue

• Aggressive client interaction

• Missed callback

• Incorrect client information given

Client issues can become operational and reputational problems if not documented clearly.

Staff Injury

Use Staff Injury for events involving employee injury, exposure, safety concern, or workplace incident.

Examples:

• Bite

• Scratch

• Fall

• Needle stick

• Chemical exposure

• Lifting injury

• Equipment-related injury

• Workplace safety incident

Staff injury events should follow clinic safety, HR, OSHA, workers’ compensation, and internal reporting policy where applicable.

Equipment Event

Use Equipment for events involving broken, malfunctioning, unavailable, unsafe, or improperly used equipment.

Examples:

• Anesthesia machine issue

• Autoclave failure

• Radiology equipment issue

• Lab machine failure

• Printer or label issue affecting care

• Monitoring equipment malfunction

• Broken cage, table, or restraint equipment

• Calibration concern

Equipment events help identify patterns before one broken widget becomes a full gremlin parade.

Other / Uncategorized

Use Other / Uncategorized when the event does not fit another category.

Examples:

• Facility issue

• Workflow gap

• Policy concern

• Unusual operational issue

• General quality concern

Use this sparingly. If many events are uncategorized, your categories may need review.

Just Log It Quickly

Just log it quickly allows the user to record an event with minimal friction.

Use this when the most important thing is capturing that something happened, even if all details are not available yet.

Quick logging is useful when:

• The clinic is busy

• The event needs to be captured before details are forgotten

• A staff member needs to report quickly

• The event can be investigated later

• The reporter does not have all context yet

A fast rough report is better than a perfect report that never gets filed.

Confirm System Context

After selecting an event type, the system may ask the user to confirm context.

Context may include:

• Patient

• Client

• Visit

• Appointment

• Provider

• Staff member

• Location

• Department

• Related record

Context helps connect the event to the correct operational or clinical record.

No Context Detected

No context detected means the system did not automatically identify the patient, client, visit, or record related to the event.

The user can still continue and add details manually in the next step.

This prevents event logging from being blocked just because the system cannot auto-detect context.

Confirm Context

Confirm Context confirms the system-detected or manually selected context before continuing.

Use this to make sure the event is tied to the correct patient, client, visit, or workflow.

Event Details

The event details step captures what happened.

This may include:

• Severity

• Description

• Notes

• Reporter identity

• Submission

What Happened?

Use this field to describe the event.

Good event notes should include:

• What happened

• When it happened

• Who or what was involved

• What was observed

• What immediate action was taken

• What still needs review

Keep it factual. Avoid blame, guesses, sarcasm, or courtroom fan fiction.

Optional Details

Some detail fields may be optional so users can submit quickly.

Even when optional, include enough information for the reviewer to understand the event.

Report as Myself

Report as Myself records the event under the current user’s identity.

This supports accountability and allows reviewers to follow up if more information is needed.

Depending on clinic policy, other reporting options may exist.

Submit

Submit creates the QI event.

After submission, the event appears in Clinical Intelligence and can be reviewed, updated, investigated, and resolved.

Event Details Page

The Event Details page shows the selected event and its review history.

It may include:

• Event title

• Reporter

• Time since report

• Current status

• Resolve button

• Original report

• Investigation timeline

• Investigation note entry

Event Title

The event title summarizes what was reported.

Example:

Surgical Incident Report

The title should help reviewers understand the general event type quickly.

Reported By

Reported By shows who submitted the event.

This helps reviewers follow up for more context if needed.

Time Since Report

This shows how long ago the event was submitted.

Use this to prioritize review and avoid stale open events.

Original Report

The Original Report shows the initial event description submitted by the reporter.

This should remain available as the starting record of what was reported.

Investigation Timeline

The Investigation Timeline tracks review activity after the event is submitted.

Timeline entries may include:

• Investigation notes

• Follow-up actions

• Reviewer updates

• Status changes

• Resolution notes

• Corrective actions

• Communication notes

The timeline creates an audit trail of how the event was handled.

Add Investigation Notes

The note field allows reviewers to add investigation notes or log actions.

Use this area to document:

• Record review

• Staff follow-up

• Client communication

• Patient status update

• Equipment check

• Medication review

• Corrective action

• Policy review

• Training need

• Resolution rationale

Investigation notes should be clear, factual, and useful for future review.

Resolve

Resolve marks the event as resolved.

Use Resolve only after the event has been reviewed and any required follow-up has been completed or assigned.

Before resolving, confirm:

• The original report was reviewed

• Patient safety concerns were addressed

• Client communication was completed, if needed

• Staff follow-up was completed, if needed

• Equipment or medication issues were addressed

• Corrective actions were documented

• Investigation notes are clear enough for future review

Resolution should close the loop, not sweep the confetti under the rug.

Common Event Examples

Medication Example

A patient was almost sent home with the wrong dose of medication, but the issue was caught before discharge.

Suggested setup:

• Category: Medication

• Severity: Medium

• Context: Patient and visit

• Notes: What was prescribed, what was caught, who caught it, what correction was made

• Follow-up: Review prescribing workflow or label process

Surgical Example

A surgical checklist item was missed before induction.

Suggested setup:

• Category: Surgical

• Severity: Medium or Critical depending on impact

• Context: Patient, provider, surgery visit

• Notes: Which checklist item, when it was discovered, whether patient care was affected

• Follow-up: Review surgical checklist process

Patient Event Example

A patient slipped while being transferred from treatment to the exam room.

Suggested setup:

• Category: Patient Event

• Severity: Low, Medium, or Critical depending on injury

• Context: Patient and location

• Notes: What happened, whether the patient was examined, client communication, next steps

• Follow-up: Review handling process or flooring issue

Client Issue Example

A client reports they were not told about expected costs before treatment.

Suggested setup:

• Category: Client Issue

• Severity: Medium

• Context: Client, patient, visit

• Notes: What client reported, estimate status, what was communicated, who followed up

• Follow-up: Review estimate and consent process

Staff Injury Example

A staff member was bitten while restraining a patient.

Suggested setup:

• Category: Staff Injury

• Severity: Based on injury severity

• Context: Patient, staff member, location

• Notes: What happened, immediate care, reporting steps, whether medical care was needed

• Follow-up: Follow clinic injury and safety policy

Equipment Example

The anesthesia monitor stopped reading during a procedure.

Suggested setup:

• Category: Equipment

• Severity: Medium or Critical depending on patient impact

• Context: Surgery, patient, equipment

• Notes: What failed, when it failed, backup used, patient impact

• Follow-up: Remove equipment from use and document repair/replacement

Best Practices

Use Clinical Intelligence to build a learning system, not a blame machine.

• Log events as soon as possible.

• Keep reports factual.

• Use the right category.

• Set severity honestly.

• Add patient or system context when available.

• Investigate medium and critical events promptly.

• Add timeline notes as review progresses.

• Resolve only when follow-up is complete or clearly assigned.

• Review recurring event types for process improvement.

• Do not punish people for reporting issues in good faith.

A clinic that logs problems early can fix them while they are still small. A clinic that hides them gets surprise invoices from reality.

Common Workflows

Log a New QI Event

1. Open Clinical Intelligence.

2. Select Log Event.

3. Choose what happened.

4. Confirm patient or system context if available.

5. Select severity.

6. Enter event details.

7. Choose reporter identity.

8. Submit the event.

Log an Event Quickly

1. Select Log Event.

2. Choose the event category.

3. Select Just log it quickly.

4. Add the details available now.

5. Submit.

6. Add more investigation notes later.

Review an Open Event

1. Open Clinical Intelligence.

2. Select the Open filter.

3. Choose an event from the list.

4. Review the original report.

5. Add investigation notes.

6. Update status as needed.

7. Resolve when follow-up is complete.

Add an Investigation Note

1. Open the event.

2. Type the investigation note or action taken.

3. Submit the note.

4. Confirm the timeline updates.

Resolve an Event

1. Open the event.

2. Review the original report.

3. Review the investigation timeline.

4. Confirm required follow-up is complete.

5. Select Resolve.

6. Add final resolution notes if required.

Final Definition

Clinical Intelligence is the QI event and adverse event management layer inside PawthosX One.

It allows clinics to log events, categorize issues, set severity, confirm context, investigate what happened, document follow-up, and resolve events with a clear audit trail.