Maximum Length 'act.patientClinicalNote.1.0'
Hi,
Is there a way to increase the maximum length of the clinical note? I am not sure what the actual maximum length is, but I have ours set to 4500.
When I have tried to increase the max length to 10000, I get the error:
Could not execute JDBC batch update; SQL [insert into act_details (act_id, name, type, value) values (?, ?, ?, ?)]; nested exception is org.hibernate.exception.DataException: Could not execute JDBC batch update
One of our specialists likes to write a lot in a note, and seems to be going over the maximum often, meaning it doesn't save properly in the letters.
Thanks,
Greta
Re: Maximum Length 'act.patientClinicalNote.1.0'
Hi Greta,
Maximum size is currently 5000 characters per note.
If need more then currently have to split into multiple notes.
Cheers Tony
Re: Maximum Length 'act.patientClinicalNote.1.0'
Hi,
I know this is still an issue for Greta's practice and is something that increasingly crops up as an issue at ours.
Do we need to create a project to sort this?
Re: Maximum Length 'act.patientClinicalNote.1.0'
In 1.6, the note field length is 4500 characters. This can be increased to 5000, just by editing the act.patientClinicalNote archetype.
In 1.7, the maximum length is now 5000 characters.
There's several changes that can be made to support even longer notes:
1. Change the database.
The value column of act_details table holds the notes field, amongst other things. It can be increased up to around 65000 characters. There may be performance implications in doing this, particularly on large databases.
2. Store notes as documents
There is a dedicated table for storing documents which has no practical size limit.
3. Split notes
Here, notes are automatically split into multiple act.patientClinicalNote if they exceed the character limit. For display purposes, you still see the one note.
Option 1 requires a database change, but is the simplest to implement. There may be performance implications.
Option 2 requires code changes and data migration.
Option 3 requires code changes and no data migration, but is the most complex of the three solutions.
I prefer option 2.
-Tim
Re: Maximum Length 'act.patientClinicalNote.1.0'
Hi tim,
With option 1. What are the performance implications if the notes size is increased to let's say 7000 characters? Do you only get performance changes if you are filling up notes with this amount of information regularly? Or does everyone suffer no matter if you use the extra space or not? I guess I wonder if it is the simplest and cheapest solution if there is a happy medium that can be struck between size and performance (or are we at that point now?).
Why is your preference option 2?
What is the rough cost difference between these options?
Re: Maximum Length 'act.patientClinicalNote.1.0'
I have no idea what the performance implications are. The act_details table is used for all acts (e.g customer invoices, appointments, patient records), so any change could potentially have wide ramifications.
There may be very little difference in increasing it to 7000 characters, but I imagine this may not be enough for some users, so there needs to be a way to quantify different lengths.
It would require developing tests to evaluate performance. These would time retrieval of different acts for different field sizes on a large database (e.g 10 million acts). Tests would include:
The tests would be run on dedicated hardware, and the mysql server restarted after each test. Each test would run identical untimed queries at the start to initialise mysql caches.
Option 2 is a nice balance between 1 and 3. Any performance hit is limited to the retrieval of patient notes. If the notes are stored plain-text (documents are all compressed at present), then it will still be possible to write SQL queries to report on patient history.
Option 3 makes report writing difficult, as the report needs to handle merging multiple notes.
-Tim
Re: Maximum Length 'act.patientClinicalNote.1.0'
Ok, well as you say, sounds like option 2 is the most sensible as by the time performance testing for option 1 has been done it might have been quicker to just implement option 2.
Can we please have this costed.
Thank you,
Adrian
Re: Maximum Length 'act.patientClinicalNote.1.0'
See http://www.openvpms.org/project/large-text-documents
-Tim
Re: Maximum Length 'act.patientClinicalNote.1.0'
Hi, this has cropped up as an issue for us again. Does the project need updating in light of the fact it was proposed 4 years ago, or can it go ahead in the form it is currently in?
thanks,
Adrian
Re: Maximum Length 'act.patientClinicalNote.1.0'
I would do it a bit differently now. If a note exceeds 5000 characters, I would:
There would be some database migration required, to convert existing notes (they need to change types to support documents), and the Medical Records Report and Problems Report would need to be updated to handle notes with documents attached.
Re: Maximum Length 'act.patientClinicalNote.1.0'
Hi,
- Hmmm.... i worry about the entire medical record not being visible/viewable in the medical record screen. Ideally this screen should not require "more clicks" to do what it is designed to do - view the medical record.
- Is this a cheaper approach?
- Is the original approach still viable?
Re: Maximum Length 'act.patientClinicalNote.1.0'
It would be marginally cheaper. The advantage of showing a truncated note is that there would be no (or negligible) performance decrease compared to the status quo.
Displaying the entire text, that would not be the case, and performance would decrease with longer notes both in terms of browser rendering times, and database retrieval.
Re: Maximum Length 'act.patientClinicalNote.1.0'
For some of our associated specialist histories this would be good.
I dont have a problem with Read More option as pages of notes for a single visit makes scanning thru a history so difficult. I suspect the performance hit for some of our majorly verbose histories would be pretty significant for us.