FISMART Access

Safety-first education for people with low-back pain and limited access to physiotherapy. Deterministic rules decide when to educate, clarify, or stop before any optional AI response.

Comment

Inspiration

People with low-back discomfort often search online for immediate guidance, especially when access to physiotherapy or other healthcare services is limited by cost, distance, language, disability, transportation, location, or lack of available professionals.

For many people living in rural, remote, or underserved communities, obtaining timely professional guidance may be difficult. However, giving unrestricted health advice through artificial intelligence can also create risk. The central problem is not only misinformation; it is an AI system responding when it should first stop, request clarification, or recommend professional attention.

As a physiotherapist, I wanted to create an accessible educational tool that could help people better understand their situation without pretending to diagnose, prescribe treatment, or replace professional care.

FISMART Access was created around one central principle:

Rules first. AI second.

The objective is to ensure that safety decisions occur before any optional AI-generated explanation.

What it does

FISMART Access is a safety-first educational prototype for adults experiencing low-back discomfort, particularly people with limited access to physiotherapy services.

The system collects only general information necessary for educational orientation and warns users not to enter names, addresses, telephone numbers, medical identifiers, or other personal information.

Before providing any educational content, the system applies deterministic and verifiable safety rules.

The system produces one of three possible outcomes:

  • EDUCATE: The information is compatible with controlled educational guidance. The system may provide activities or explanations selected from an approved content library.
  • CLARIFY: The information is incomplete or ambiguous. The system stops the process and asks a targeted confirmation question before continuing.
  • STOP: A possible warning sign is confirmed. The system generates no plan or activities and recommends seeking professional or urgent attention, depending on the situation.

The AI does not independently decide whether a person is suitable for self-care. The deterministic safety layer makes that decision first.

Safety architecture

FISMART Access uses several protective layers:

  1. Defined scope
    The current prototype is limited to adults with low-back discomfort.

  2. Privacy-first data collection
    The system requests only general information and discourages the use of personal or identifying data.

  3. Structured warning-sign screening
    Confirmed responses are evaluated before any content can be generated.

  4. Deterministic narrative screening
    The system checks limited phrases that may indicate a warning sign that was not selected in the structured questions.

  5. Clarification before continuation
    When information is uncertain, the system blocks the plan and asks for confirmation.

  6. Controlled educational library
    Activities, instructions, dosages, modifications, and stopping rules come from predefined content rather than unrestricted generation.

  7. Second safety filter during follow-up
    A new warning sign can stop any later adaptation or recommendation.

This architecture separates safety decisions from optional explanation.

Designed for limited-resource settings

The prototype was designed for people who may have:

  • Limited access to physiotherapy
  • Long travel distances to healthcare services
  • Financial barriers
  • Limited transportation
  • Language barriers
  • A basic mobile phone or low-cost device
  • Limited health education

The educational actions are intended to be brief, understandable, and possible without expensive equipment.

How I built it

I am a physiotherapist, not a software developer, and I began this project without previous programming experience.

I created the project concept, clinical purpose, safety boundaries, warning-sign logic, educational content, decision flow, user experience, and intended use.

With the support of ChatGPT 5.6 and Codex, I translated these professional and clinical requirements into a functional prototype.

Codex helped me:

  • Structure the application
  • Implement the deterministic workflows
  • Create the user interface
  • Review privacy and safety behavior
  • Build the jury demonstration route
  • Create automated tests
  • Validate syntax
  • Document the architecture and limitations
  • Prepare the final repository and demonstration

The professional criteria, safety principles, target population, educational scope, and project purpose were defined from my experience as a physiotherapist and from my goal of helping people who have difficulty accessing physiotherapy services.

Jury demonstration

The jury mode demonstrates three predefined scenarios in one verifiable flow:

  • Scenario A: Educational case
  • Scenario B: Ambiguous case
  • Scenario C: Urgent case

Each scenario is processed by the server and applies the deterministic rules again.

The technical panel shows whether:

  • A warning sign was detected
  • The generator was called
  • Activities were produced
  • A plan was created
  • Clarification was requested
  • The case was stopped
  • Live AI was enabled

In ambiguous and urgent scenarios, the prototype demonstrates that no partial plan or activities are produced.

Transparency about AI use

The current version operates honestly in demonstration mode with:

liveAI=false

No real GPT-5.6 API call was made or simulated in this version.

The prototype demonstrates the safety architecture, deterministic decision process, controlled educational library, interface, and testing system.

When live AI is enabled in a future version, it would only be allowed to organize or explain content that has already passed the deterministic safety filters. It would not be allowed to override the safety decision, create unapproved treatment, or continue after a confirmed warning sign.

Technical validation

The final prototype completed:

  • 77 of 77 automated tests passed
  • 29 of 29 JavaScript and MJS files passed syntax validation
  • Working tree verified as clean
  • Final repository published from the verified commit
  • Demo mode confirmed
  • liveAI=false confirmed

The tests cover areas including:

  • Scope control
  • Privacy
  • Warning-sign screening
  • Narrative safety
  • Controlled activities
  • Workflow behavior
  • Accessibility
  • Jury scenarios
  • OpenAI integration boundaries
  • Final safety invariants

Challenges

The greatest challenge was translating clinical reasoning into explicit, testable, and deterministic software rules.

In healthcare, information is often incomplete or expressed in different ways. A safe system cannot assume that silence means safety. It must distinguish between:

  • A negative response
  • Missing information
  • Ambiguous information
  • A confirmed warning sign

Another challenge was preventing the interface from showing partial educational content when a scenario should be clarified or stopped.

Because I had no previous programming experience, I also had to learn how repositories, branches, commits, automated tests, servers, APIs, and deployment workflows function while building the prototype.

Accomplishments

I am proud that I was able to transform a healthcare-access problem into a functional and testable software prototype despite beginning without programming experience.

The project demonstrates that:

  • A clinician can define clear safety boundaries for an AI-assisted system
  • Deterministic rules can operate before generative AI
  • Ambiguous information can block unsafe recommendations
  • Confirmed warning signs can stop all educational generation
  • Technical evidence can make safety behavior visible to reviewers
  • AI development tools can help a healthcare professional convert domain expertise into working software

What I learned

I learned that creating a responsible health-related AI system requires more than writing a good prompt.

Safety must be implemented as architecture.

Important rules must be:

  • Explicit
  • Testable
  • Independent from the language model
  • Visible to reviewers
  • Resistant to missing or ambiguous data
  • Unable to be overridden by generated content

I also learned that AI-assisted development can allow a person without a traditional programming background to build a working prototype, provided that the project has a clearly defined purpose, strict boundaries, continuous verification, and transparent limitations.

What is next

The next steps for FISMART Access include:

  • Independent clinical review of the warning-sign logic
  • Validation with physiotherapists and physicians
  • Usability testing with adults from underserved communities
  • Accessibility testing with users who have visual, motor, or literacy limitations
  • Multilingual support
  • Improved low-bandwidth and mobile performance
  • Secure integration with telemedicine services
  • Expansion to additional musculoskeletal conditions only after clinical validation
  • A controlled GPT integration that operates exclusively after deterministic authorization

The long-term goal is not to replace physiotherapists.

The goal is to help people understand when education may be appropriate, when clarification is necessary, and when they should stop and seek professional attention.

Important limitation

FISMART Access is an educational prototype.

It does not diagnose, prescribe treatment, provide emergency care, or replace medical or physiotherapy evaluation.

FISMART — Understanding your body changes everything.

Built With

  • accessibility
  • codex
  • css3
  • deterministic
  • git
  • health-education
  • healthcare
  • html5
  • javascript
  • low-back-pain
  • node.js
  • openai
  • patient-safety
  • physiotherapy
  • privacy
  • rules
  • wcag
Share this project:

Updates