Legacy Classic ASP Patient Notes – Development Specification / Request for Quote

Background

We maintain a legacy Classic ASP application originally developed approximately 20 years ago. We did not develop the original application.

The application has a recurring issue involving its Patient Notes functionality.

Currently, a patient's accumulated notes/history are maintained as one continually growing notes field. When a new note is entered, the application processes and saves the accumulated history rather than saving only the new clinical entry.

Previous changes were made to increase the amount of data that could be transmitted and to increase the autosave delay. These changes improved the existing process but were intended as a mitigation rather than a permanent solution.

We have since experienced another incident where historical notes disappeared/truncated and had to be recovered from a database backup.

The objective of this project is to redesign the Patient Notes saving process so that entering a new note no longer requires transmitting and overwriting the patient's entire historical notes record.

Recommended Approach

Our preferred approach, subject to the developer's review of the existing code and database, is:

1. Preserve existing historical notes

Existing accumulated patient notes should remain intact and accessible. We would prefer not to parse, split, migrate or otherwise manipulate the historical content unless technically necessary.

2. Make existing historical notes read-only

Once the new functionality is implemented, the existing historical notes should no longer be modified or resaved when a user enters a new note.

3. Store new notes independently

New clinical notes should be stored as separate database records rather than appended to the existing large notes field.

Conceptually, a new table might contain:

PatientNoteID
ProfileID
CreatedDate
ModifiedDate
UserID
NoteText

The exact schema should be determined by the developer after reviewing the existing application.

4. Only the current/new note should be editable

Creating or editing a new note should transmit and save only that individual note. It should never require the patient's complete historical record to be submitted and overwritten.

Once a note is no longer considered the current note, it can become part of the read-only history. We are open to the developer's recommendation regarding exactly how this should work from a usability standpoint.

5. Maintain a familiar interface where practical

Ideally, users should still be able to view the patient's notes as a reasonably continuous chronological history, with the current/new note editable and previous notes read-only.

The editable and read-only portions do not necessarily have to be contained within the same HTML/editor field. The goal is for the interface to remain familiar and straightforward to the end user.

However, this is a legacy application, so we are open to the developer's recommendation regarding what is practical without unnecessarily complicating the project.

6. Remove automatic date creation/save when simply viewing notes

The existing application has another behaviour that needs to be addressed.

Currently, simply opening Patient Notes automatically adds a new date/time header to the notes. As a result, opening and closing a patient's notes without actually entering anything can create multiple blank dated entries and can also trigger an unnecessary save.

Under the redesigned system:

Simply viewing/opening/closing Patient Notes should not create a new note or date entry.
Viewing notes should not modify the patient's record or trigger a database save.
A new dated note should only be created when the user actually begins entering a new note, or through an "Add New Note" function if that is the preferred interface.
The date/time should ideally be associated with the individual new note record rather than being added to the patient's entire historical notes field.

We are open to the developer's recommendation regarding the cleanest way to accomplish this while keeping the workflow simple for the user.

Autosave

The existing system uses autosave. We would like to retain autosave for the current note if practical, but autosave should operate only against the individual current note, rather than resending and replacing the patient's complete historical notes.

Please also review the autosave implementation to ensure that overlapping/concurrent save requests cannot result in an older save overwriting a newer version.

Performance

The new structure should be designed so that performance does not degrade significantly as the number of individual note records increases.

Appropriate database indexing should be used so that notes can be efficiently retrieved for an individual patient.

If necessary, older notes can be loaded on demand or paginated rather than loading an unlimited number of records into an editable control.

The intention is that the redesigned system should ultimately perform better than the current approach, since only the current individual note should need to be processed when it is saved.

Data Safety

A failure while saving a new/current note must not be capable of overwriting or deleting the patient's previously saved historical notes.

If individual new notes can subsequently be edited, please advise whether retaining the immediately previous version or implementing a simple revision/audit history would be straightforward and appropriate.

A full document-management/versioning system is not required unless there is a technical reason for one.

Scope

This is not intended to be a rewrite of the entire application.

The goal is a targeted redesign of the Patient Notes functionality within the existing Classic ASP application and database.

Existing historical notes must remain accessible, and other patient/profile functionality should continue operating normally.

We would prefer to leave the existing historical data in its current format and begin using the new note structure from the implementation/cutover date forward, unless the developer identifies a reason this would not be advisable.

Developer Review / Quote Requested

Before implementation, please review the existing Patient Notes code and relevant database structure and provide:

Your recommended technical implementation.
Whether the proposed separate-record approach is appropriate for the existing application.
Your recommendation for how the editable current note and read-only historical notes should be presented in the existing interface.
Any suggested changes or improvements to the approach described above.
Any risks or compatibility concerns.
Estimated development and testing hours
Any questions or decisions required from us before implementation.

Please quote/review first. Do not implement changes until the proposed scope has been approved.

Important: This is a legacy Classic ASP application, so applicants should have experience working with and modifying existing Classic ASP applications and SQL databases. Also, the application uses TinyMCE for the notes area so experience with that is ideal.

______________________________________________________________________________________

Additional clarifications: Environment is Classic ASP/VBScript, SQL Server 2022 Express (64-bit), Windows Server 2022; TinyMCE 2.0.8 (2006). Existing history remains in Profiles.Notes, becomes permanently read-only, and will NOT be parsed/migrated. New notes are separate records linked to ProfileID and remain individually editable after saving; please recommend a simple revision/audit approach. Existing AJAX autosave should be retained but save only the active note and protect against overlapping/out-of-order saves. Opening/viewing notes must not create a date/note or trigger a save. History may use pagination/lazy loading and should not be loaded into TinyMCE. Legacy Notes must remain administratively restorable from backup without affecting new notes. No new integrations/role changes. Sanitized code/schema available; staging can be discussed with selected developer.