If you are still in the layout and design phase, I have some very general advice for you. My comments will go more towards "mindset" than specific things to do. I'll try to be brief (but those who know me probably WOULD bet against brevity.)
#1 If you can't do it on paper, you can't do it in Access
This means you need a good, thorough analysis ahead of time because Access knows NOTHING about medicine. It is a tool that builds databases. YOU will be supplying the subject-matter expertise. "Doing it on paper" almost always involves a discussion of how to approach given situations - one situation at a time - and taking really good notes.
By doing your analysis first, you save yourself from having to back-track large blocks of code. Ideally, your up-front analysis will generate some kind of document (of non-trivial size) that tells you - and anyone else who reads it - about the choices you made and why. This is your "roadmap." If this project is like a journey, you will need a roadmap - if for no other reason than to recognize when you finally reached your intended destination.
The direct meaning of the statement is simple. If you have a design guideline, you can start implementing stuff in Access. If you have no idea why you want to implement something, you are just piddling around. Don't call in Access until you know what data features you need.
#2 Access won't tell you anything you didn't tell it first.
Access isn't a search engine per se. All it can tell you is what is already inside of it. If you programmed a search feature, it would be limited to database content. Therefore, when you went through that design process (see #1 above) you laid out what you were doing. Part of that layout is defining / enumerating what you want to see. Actions specific to my #2 guideline are that for EVERY output you need to verify that you have a data source for that output. If this means working backwards through your design to verify data sources, so be it. If you wanted output XYZ, then either you need a data source of XYZ ... or you need data sources for X, Y, and Z and the formula you can use to combine them.
#3 Access is the map, your business is the territory
Your business rules should have existed long before you started this project. You do not want to change your business in any way due to this project EXCEPT for efficiency or accuracy in record-keeping. The point here is that if you have a disparity between what your business rules would do and what your database would do, the database is usually wrong. At NO TIME do you ever want the tail to wag the dog.
If you let the DB app control what you do or what your users do, it has to be because it accurately implements a model of your business. I have seen too many cases where people had to change what they did because the DB app they had couldn't track certain actions / processes. So they had to change their business flow. I have seen DB problems because the process implemented by the DB doesn't accurately reflect what the end user of the process wants to do to just get the job done.
At the same time, having done a thorough analysis of this project, you might have found a spot or two where you had to decide what to do in reality because you never thought about that situation before the analysis project. I.e. analysis can find "holes" in your business model and give you luxury of deciding ahead of time rather than do a tap-dance around something you never thought about. If you change your model (and your roadmap) because you discovered a gap, that is a case of "no harm, no foul."
The above principles are design-level guidelines to help orient your way of thinking when you work on this project. They are general in nature but based on 40+ years worth of IT work for private industry as well as U.S. Military operations.