The definition of end to end encryption is that only the parties that are part of the communication can read the message, while the infrastructure that supports the communication can't. HTTPS encrypts between the client and the server, but it does not encrypt between the patient and doctor. In other words, it's not an end to end encryption in the conventional sense of the word.
Whether this is enough depends on your threat model and any regulatory requirements that applies to you (e.g. HIPPA).
I also should be able to retrieve messages exchanged in case of legal issues between doctor:patient, basically a man-in-the-middle.
Since you only need to decrypt messages between doctors and patients when there is a dispute, then you can be sure that at least one party is going to cooperate with you. One way you can implement this with encryption is to encrypt a data encryption key with key encryption key and use secret splitting (e.g. Shamir's Secret Sharing) to split the key encryption key three ways (patient, doctor, and you). The communicating parties then discloses the data encryption key to you in an encrypted form and one share of the key encryption key and you record the encrypted messages. In this scheme, you cannot decrypt the data encryption key and the message, unless one party has agreed to disclose their share of the secret to you. This preserves doctor-patient confidentiality while allowing you to check the decrypt the message that has been deliberately disclosed to you.
A simpler solution, if you're fine with having a single person/trusted party that can decrypt the entire world; is to have the messages encrypted with an asymmetric intercept key. Both sides have to encrypt all their messages to the intercept key, and the person controlling the intercept key has to keep his private key private. The patient and doctor knows the public key part of the intercept key, so they can encrypt the message so that the intercept key can decrypt it.