Clinical Platform for Home Rehabilitation
A web solution for receiving inquiries and managing home-rehabilitation records.
Problem
An independent physiotherapist needed two connected tools: a public site for receiving a limited volume of relevant inquiries and a local clinical tool for maintaining records and organizing care.
Home rehabilitation combines administrative data, treatments, visits, and documentation. The system needed to organize that process without treating every inquiry as active care or recording visits outside its treatment context.
The product
The public site presents services and structures the information needed before initial contact. It does not seek to maximize inquiries: it aims to receive the volume the professional can handle and reduce the initial back-and-forth.
The local clinical tool organizes requests, patients, treatment cycles, visits, and reports.
Main workflow
An inquiry does not automatically become treatment. Intake creates a basic patient record and a ServiceRequest under review. Only a valid, accepted, unused request can start a treatment cycle.
- Request
- Patient
- Treatment
- Visit
- Follow-up
Treatment opens an EpisodeOfCare; visits are recorded as Encounter resources inside it. Dates are validated against the episode start and closure. The patient view shows the next action for the current state.
My contribution
I defined the functional workflow, business rules, and screen responsibilities. I also implemented the product, FHIR model, tests, and documentation.
Decisions
Inquiries aligned with capacity
The public page prioritizes relevant inquiries and structured initial information, aligned with the professional’s capacity.
Request before treatment
A request can remain under review, be accepted, or close without generating visits. It adds a step, but prevents an inquiry from becoming an active case.
Distinct but connected areas
The interface separates administrative data, clinical context, and treatment. The patient view connects these areas, although some actions require moving between them.
Visits inside an active episode
Visits require an active EpisodeOfCare and dates inside its treatment cycle. Multiple simultaneous active episodes remain outside the current scope.
FHIR isolated from the UI
An intermediate layer translates FHIR resources into interface concepts. Contract changes require coordinated updates across both layers.
FHIR and future evolution
FHIR R4 serves as the local clinical model. The core uses Patient, ServiceRequest, EpisodeOfCare, Encounter, and Observation; supporting resources add context when needed.
ANDES bases its interoperability layer on HL7/FHIR standards. Using the same family of standards avoids ruling out a future integration path, but it does not guarantee compatibility: profiles, contracts, terminology, and security would still need to be aligned.
Quality, privacy, and boundaries
The project includes typed contracts, domain validations, automated tests, and workflow documentation. The screenshots use fictional data.
The admin is local/private, marked as noindex, and excluded from public analytics. The current scope does not include production authentication, multi-user operation, validated compatibility with ANDES, a patient portal, or a complete electronic health record.