If you wrap your mind around it, I think its possible to migrate from procedural coding to OOP by relating what you already know to the MVC approach and OOP in general. The deadline pressures of working on a true project will force you to learn OOP more quickly.
I would design the database schema first. Based on the schema, you can determine the number of modules (MVC triads) required to build the user interface for the electronic patient record system. If you were developing the system using procedural PHP coding practices, you would have to do something similar so you can relate what you already know about programming up to this point. You might consider downloading an existing application like Bamboo Invoice to learn how the developer separated controller, model and view code into separate files and compare that to what you might have done to do the same in procedural programming.
You might think about selecting one of the simple modules for your EPR user interface and attempt to build it using MVC. Keep an open mind while doing this and try to learn OOP as you proceed. You can always return later to refactor your code if your first attempt does not meet your expectations. One of the nice advantages of MVC is that it promotes code reuse and uses modular approaches to application creation. Thus, it becomes reasonably easy to return later to optimize your code to take advantage of the skills and approaches you learn later in the project.
If you plan to use CI, you might do some searches first on ‘Base Controller’ to learn how to construct a main controller which all of your other controllers can inheirit from. By using this approach, common reusable code can be integrated into the base controller and would be inheirited by sibling controllers. This will lead you in the direction of maximizing your reuse of code. Code reuse minimizes code redundance the obviously leads to faster application speed.
Regarding the use of ADODB, CI’s database library is somewhat similar to ADODB in syntax. You can use the CI Active Record approach or use ANSI queries; or you can use the existing solution on the wiki to integrate the ADODB library. There is an ADODB integration project on ciforge.com. If you do use ADODB, the phpGACL (Generic Access Control List) library is an option for system authorization. This is a fine-grained Access Control List system based on nested sets. Rather than using the sample phpGACL admin user interface included with the package, build a new admin user interface based on Thunder’s Nested Sets Model (also on the wiki). This would take a bit of work, but its feasible. There are other ACL and RBAC solutions under development by others, so FreakAuth is not your sole option. You can always develop around the need for authorization until later when more options become available.
I think you will find CI to be a better solution in your case, especially if you are on a learning curve. The community here is very helpful and the CI docs are excellent.