Patient Travel Support Foundation (PTSF)

AI-Assisted Study Note

This page brings together public scenario links and AI-assisted research notes for study use. Start with the scenario brief, make your own attempt, and open the spoiler section only when you are ready to compare.

Scenario Snapshot

Field	Detail
Start here	Discovery index
Scenario source	Official or official-adjacent scenario (Scenario 602 / Step 1 Evaluation)
Current status	Official Practice (Live)
First public date	2021
Primary source	Open primary source
Coverage available	Scenario brief + Solution + Video or presentation + Discussion or analysis

Why This Scenario Matters

• This entry is included because it appears in the public CTA scenario corpus and has enough public evidence to track for study use.

Only Open If You Have Attempted the Scenario

The section below contains public follow-up links, board-call material, and AI-assisted notes compiled from those public sources.

Open follow-up links, Q&A, and analysis

Follow-Up Links

• Discovery index
• Analysis reference

Board Insights & Common Pitfalls

Generalized Judge Questions

• Sensitive Data Access: “How do you ensure a Volunteer can only see the patients they are currently assisting? Why choose a Private model over hierarchies?”
• Integration Reliability: “What happens if the Travel Agency API is down when a booking is submitted? Describe your error handling and retry mechanism.”
• Privacy Compliance: “How are you handling the ‘Right to be Forgotten’ for patients? Can you mask records while preserving financial audit trails?”
• Encryption Impact: “You recommended Platform Encryption. How does this affect the staff’s ability to search for patients by name or medical ID?”
• Org Strategy: “Why choose a Single-Org strategy for a global foundation? How do you partition data without a multi-org overhead?”

Common Mistakes

• Public Patient Data: Using a “Public Read/Write” model for Patient records, which is a critical HIPAA/GDPR fail for medical data.
• Synchronous Booking: Using synchronous Request-Response for flight bookings. Travel APIs are notoriously slow; this should be Asynchronous (Platform Events/Queueable) to avoid UI timeouts.
• Data Skew Traps: Linking all travel requests to a single “Foundation” Account, creating a massive parent-child skew that blocks record locking.
• Master-Detail Overuse: Using Master-Detail for everything and hitting the 2-master limit or blocking independent record ownership for volunteers.

Strong Patterns

• The “Golden Path” focus: In this short mock, successful candidates focus strictly on Intake -> Approval -> Booking -> Feedback without over-engineering.
• Shield for Compliance: Using Shield (specifically Deterministic Encryption) to balance security needs with the requirement to search for patients.
• Experience Cloud for Volunteers: Using Customer Community Plus to allow volunteers to manage travel requests while maintaining strict security boundaries.

Strategic Insights

• 60-Minute Discipline: Success in this “Step 1” scenario depends on making decisive, standard-first choices quickly rather than exploring multiple custom alternatives.
• NGO Licensing: Be prepared to justify the use of Nonprofit Cloud features vs. standard Service Cloud objects.

Additional Notes

• A “short mock” designed to test fundamental architect skills: medical compliance, high-volume data, and multi-region logistics.
• Often used as the benchmark for the Step 1 Architect Evaluation.