So, according to the HHS security guidelines, a username and password combination is a sufficient mechanism for authenticating an individual. However... Storing user passwords in plaintext in a config file is not usually a recommended design pattern. Certainly not a list of every individual user allowed to access the database along with their plaintext passwords. I am not a PHI/HIPAA auditor, but I would strongly expect that if I were to present this design to an auditor, he might take issue with this.
Some measures that you could take to limit your risk:
1) Don't store passwords at all. Rather, store only the password you need to access a user database for authentication, and not the password to the database containing the PHI. The database password can be derived from the user's application password using a KDF, and it can be derived on authentication, rather than being stored.
2) Store the password, but encrypt the config file. To prevent this from being simple obfuscation, you need to store the encryption key somewhere more secure than another config file, like in an HSM.
3) Ensure that indirect database access is blocked, in case of stolen credentials. The database server should be firewalled and access should be via a whitelist. In most cases, only the application (web) servers should be granted access to the database server. This way, even if someone steals credentials, they can't simply log into the the database from their own machine. Additionally, since the data by rule must be encrypted, if you decrypt using the application rather than database level functions, even if a malicious user does manage to access the database from outside of the application, they won't have access to unencrypted data.