A requirement for e2e is that the company doesn't hold the keys, otherwise it's just regular transport encryption + a promise that they'll never peak at the your data, even though they can. So yes, it's very much incompatible technically.
You just have two modes, one with e2e enabled and one not. e2e is enabled normally but when LE requests access, the user client receives a message telling it not to use e2e. That may not satisfy you as someone who wants secure encryption (and it probably shouldn't), but it is e2e when it's actually enabled.
Does it inform the user or otherwise stop functioning for telehealth once the signal is received? If not, then does that mean that someone is considered e2e encrypted if it in theory can support e2e encryption even if it isn't using it right now?
It looks like the situation has not been fully thought through and the government is creating a Kafka trap when its laws.
> does that mean that someone is considered e2e encrypted if it in theory can support e2e encryption even if it isn't using it right now?
No. My assumption is that certain communications are required to be end-to-end encrypted, unless the individual is under surveillance. All end-to-end encrypted communications providers are required to have a mechanism in place for disabling and MITMing e2e communications. It stops being e2e encrypted for the duration of that surveillance.
I suppose it's possible that a foolhardy government (I'm not Australian, so I can't say for sure what they've done) would word the laws in such a way that they can't technically be achieved, but there's no reason why they have to be. The laws aren't bad laws because they are logically impossible to fulfill (if they are), they're bad laws because they violate the individual's right to privacy.
Note that the law might also prohibit the government from surveilling communications between patients and licensed health professionals. In that case it would be quite possible to mandate no-exceptions e2e for those communications, and a mechanism for disabling e2e. e2e that is never disabled is always e2e.
The company doesn't have to keep the keys for everyone. They can switch you on request from E2E to central encryption for you account only. Without an opensource client and the possibility to verify the used keys, you wouldn't know that happened. And realistically, even with those options, almost nobody verifies the changed fingerprint.
That adds an even bigger layer of complexity for people to understand. The whole point of E2E was so that only the two ends could decrypt the data being transferred. If we now add "except if government agency requests it" then we're hijacking the term and making it no more meaningful that saying "yeah our app has encryption".
I'm not trying to hijack the term. Once LEO puts in the request the system stops being E2E - that's true. It would be good if this wasn't possible, but for that we need the whole stack of: open protocol, opensource implementation, signed verified release, and people keen to verify fingerprints. And if we're pedantic, also a verifiable execution environment.