Rampant "Undefined array key "DOB" in ..." error

Management and Administration
1

I keep getting the above php warning all over the place. Actions that have caused it for me recently:

Opening a patient chart
Searching for a patient
Generating a document template
opening a clinical document within the portal

Here’s an example line from my apache2 php error.log file:

[Fri Nov 14 14:51:49.366934 2025] [php:warn] [pid 415867] [client [ip] PHP Warning: Undefined array key “DOB” in /storage/openemr/src/Services/DocumentTemplates/DocumentTemplateRender.php on line 381, referer: [webroot]/portal/patient/onsitedocuments?pid=4

I’m on 7.0.3(4), php 8.3.6, apache2, mariaDB, OS is Ubuntu server 24.04.3

Any ideas on how to address this?

2

hi @BenFosterPsyD, looks like a typo since the query is selecting it as ['dob'] in the service.

3

Hmm, but DocumentTemplateRender doesn’t use the service to define $this->ptrow. It’s either [] on line 40, or sqlQuery("SELECT pd.*, … FROM patient_data AS pd …") on line 74.

  • If sqlQuery fails or returns 0 rows, then $this->ptrow will be false, and we’d have a different error. So that’s not it.
  • ptrow is initialized in doRender. doRender is the only thing that calls doSubs and both the property and doSubs are private. So there’s no chance doSubs is getting called out of order, or that something is tampering with ptrow.
  • patient_data in sql has had a capitalized DOB field since it was created 21 years ago. So it’s not a casing typo.

So, with the information I have right now I think that $this->ptrow is not empty, but that it’s somehow being populated without a ‘DOB’ column. Thus, I can only surmise there’s something wrong in the data in the database, itself.

Can you try running SELECT COUNT('DOB') FROM patient_data on your database directly?

1 Like
4

I don’t have access to my server today, but I can 100% confirm that the column in my patient_data table is ‘dob’ in lowercase and not ‘DOB’. I checked that the other day, and didn’t even notice since every other column is all lowercase.

Would it be safe to backup the table and then run an ALTER command to change the column to ‘DOB’?

5

If you plan to do this live without taking the system offline, then even with a backup there’s an element of unsafety to it. If you can take the system offline, do the backup and try out the change without impacting active users, then it’s pretty safe from a data-loss/disaster-recovery PoV.

It wouldn’t be unreasonable to try to just fix it with ALTER TABLE and see what comes, but I’d still be vigilant about what caused ‘dob’ to be lowercase in the first place, because in the history of sql/database.sql in openemr’s codebase, it has never been lowercase.

Do you know of anything that could have caused this? Recent changes? Are you on a platform, or have a configuration, where anything case-insensitive could’ve been involved?

6

I should have clarified this in my first post:

None of this is live. I am working to get my openEMR instance up and running before using it for any actual patients (right now I’m using another system entirely for my own practice). It’s more or less a fresh install I’ve been tinkering with. So it’s live in that I’m not using a staging environment for changes (I’m new to developing, and I’m working on a development/stage/production setup), but nothing is production yet. I could fairly easily start from scratch if I had to.

That being said, I am almost positive DOB got changed to dob as a result of me following chatGPTs advice blindly. Suffice it to say I’ve now learned that lesson over and over again.

running the ALTER command within mariaDB did fix the issue, for the record.

Thanks for the help, everyone. It was a simple issue, but I learned alot for myself here.

1 Like