Procedures Portal for a Rehabilitation Medical Center

From discovery to production, end to end.

The problem

The center managed its master index of clinical procedures in one shared Excel file that linked to hundreds of Word documents on a network share. Excel takes a whole-file lock, so the index broke whenever several staff opened it at once. There was no access control and no record of who read what, even though an annual sign-off on core procedures is a regulatory requirement.

My role

I came to the institution, sat with the staff and their IT, and characterized the real problem and the real requirements: concurrent reading, two access profiles, and a read log for the audit. Then I took the project end to end. Design, development, deployment on their internal network, and user training.

The solution

An internal ASP.NET Core (.NET 10) portal with SQLite, fully Hebrew (RTL), with zero internet dependencies. The legacy catalog migrated automatically: I wrote a Python extractor that read the hyperlinks inside the original Excel and preserved the folder structure, so about 90 document links worked immediately against the existing network share, without a single manual re-link. Each reader gets an independent copy of the procedure. Zero locks, the whole staff at once.

Key mechanisms

• Full read tracking (name, national ID, department, timestamp) with a manager audit screen offering filtering and Excel export.
• Catalog and user management from the browser.
• Security and privacy hardening: login lockout, national-ID masking, CSV injection protection, and automatic data purge by retention policy.
• Update-safe architecture: data lives apart from code, schema managed with EF Core migrations. A future update never deletes what the institution has accumulated.

The deployment, which is the part that stands out

I installed the system myself on a Windows/IIS server inside the institution's internal network, and solved a chain of real enterprise infrastructure failures along the way: a mapped network drive that system services cannot see (diagnosed and moved to the UNC path), Active Directory permissions (the difference between a computer account and a domain identity for the application pool against the file share), and a firewall that blocked the port. By the end of the day the site was reachable from every employee workstation, files opened from the real network share, and the tracking recorded.

Handover and training

Full deliverables: an installation guide for IT, a presentation, an acceptance checklist, an interactive Hebrew training module with a quiz, and complete as-built documentation in a private repo.

Outcome

The system is live in production and used by the staff. The institution is evaluating follow-up expansions.