WORK IN PROGRESS · DOCTOR FEEDBACK REQUESTED

How could better toolbar logic reduce day-to-day work?

This is a working review of where a pediatric practice toolbar could go next. Today’s toolbar is basic. Version 1 makes a few small improvements. Version 2 is the larger question: could a clearer clinical choice create a reliable handoff to booking, Ocean, and the patient chart?

Discussion draft: Nothing on this page represents a deployed PS Suite or Ocean automation. We are using the examples to find the useful parts, the wrong assumptions, and the steps that still need a human decision.

Basic today. A small v1 step. A bigger v2 logic question.

The goal is not to make the toolbar look different for its own sake. The goal is to make the next action more obvious, reduce interpretation between people, and give future automation a dependable signal to work from.

TodayBaseline

Basic PSS Pediatric Toolbar

This is the starting point: useful buttons, but limited logic. Staff may still need to interpret what the physician meant, coordinate the follow-up, and remember any separate form work.

Version 1Minor upgrade

Encounter Assistant

This is a smaller improvement: smarter logic, date-stamped messages, and information that should be easier to search later. It improves the handoff without changing the whole workflow.

Version 2Proposed overhaul

Smart appointment-name logic

V2 would use the complete clinical plan to suggest a smart appointment name, such as FU3M-ASQ or FU3M-MOOD. That name could become a consistent signal for the next systems.

  • Ocean could select the matching patient message and template.
  • Ocean could schedule the right form or form package before the visit.
  • Completed forms could be routed back for chart review.

Needs validation: The naming pattern, Ocean rules, timing, scoring, and exception handling would all need to be tested with the clinic before anything is treated as automatic.

What might the same logic do across a handoff?

Choose a possible pathway to see where one standardized appointment name might reduce interpretation. These are proposed examples for review, not a live EMR interface or a promise that Ocean is configured this way today.

01
Physician

Select the clinical plan

Development + ASQ + three-month follow-up

  • Parent alone
  • Virtual permitted
Proposed example
02
PSS toolbar · proposed v2

Make the next action clearer

Use the selected plan to suggest one concise booking instruction and a consistent appointment name.

Book FU3M-ASQ
Parent alone · Virtual permitted

03
Booking staff

Book one appointment

Booking staff would use the exact FU3M-ASQ appointment type. That could remove the need to interpret a separate reminder to send the ASQ.

04
Ocean · proposed rule

Use the name as a signal

A proposed Ocean rule would recognize the appointment type and send the customized patient message and appropriate age-based ASQ 10 days before the appointment.

05
PSS chart · to confirm

Review what comes back

The completed questionnaire and available scoring information could return to the patient’s PSS chart for review before the appointment.

What information should the toolbar carry forward?

This small simulator is only a way to discuss the logic. It is not an exact PSS screenshot, and the output is not a live booking instruction.

Follow-up interval
Clinical workflow
Appointment instructions
Output preview

Instructions remain separate from the appointment-type name.

Booking instruction

Please book FU3M-ASQ.

Parent alone; virtual appointment permitted. A proposed Ocean rule could send the ASQ 10 days before the appointment.

Where could the handoff improve?

The possible benefit is not “automation” by itself. It is fewer ambiguous messages, less searching, fewer reminders to remember, and a clearer place to handle exceptions. The clinic would need to decide whether those gains are worth the setup and ongoing checks.

Today: steps depend on interpretation

  1. Physician requests a follow-up.
  2. Physician separately requests a questionnaire.
  3. Booking staff interpret both requests.
  4. Booking staff schedule the appointment.
  5. Booking staff remember when the questionnaire should be sent.
  6. Booking staff send or schedule the form.
  7. Staff check whether it was completed and added to the chart.

Possible v2: logic carries the plan forward

  1. Physician selects the complete follow-up plan.
  2. Booking staff use one standardized appointment type.
  3. A smart appointment name could select the proposed Ocean template and form timing.
  4. The completed form could return to PSS for review.
  5. Staff could focus on exceptions, but the exception process still needs to be designed.

Candidate appointment names to discuss

These examples show how a name might carry more useful logic than a generic “follow-up.” They are not a final naming convention.

Appointment typeIntended workflow
FU3MRegular three-month follow-up
FU3M-ASQASQ sent 10 days before
FU3M-MCHATM-CHAT sent 10 days before
FU3M-CACTC-ACT sent 10 days before
FU3M-MOODPHQ-9A and GAD-7 sent before the appointment
FU3M-ADHDProposed SNAP and Weiss package

Still to decide: Which combinations happen often enough to deserve a name? Which details should stay as patient-level flags or staff instructions instead?

Questions we should answer together

  • Confirm which questionnaires should be grouped into common packages.
  • Confirm that the correct ASQ version can be selected based on the child’s age.
  • Verify and correct the C-ACT scoring configuration in Ocean.
  • Confirm what happens when an appointment is cancelled or rescheduled.
  • Prevent the same questionnaire from being sent twice for one appointment.
  • Decide how staff will be notified when a questionnaire remains incomplete.
  • Confirm whether “Parent Alone,” “Virtual Permitted,” and “Online Booking” apply only to the next appointment or remain persistent patient instructions.
  • Keep Fragile Patient and Lung Check as patient-level designations rather than incorporating them into every appointment-type name.
  • Add a confirmation step before any discharge action.
  • Define the fallback workflow when a family does not have a valid email address or cannot complete an electronic questionnaire.

What is useful, missing, or wrong?

Please react to the operational details, not just the screen. Which parts match how the clinic actually works? Where would this create another task, a confusing exception, or the wrong form?

Does the overall workflow make sense?
How should the toolbar behave?

Working discussion, not a finished productThe useful version of this idea will come from testing the logic with doctors and staff, finding the edge cases, and keeping only the improvements that make daily work clearer.

Toolbar visual