Mobile medical is most definitely a use-case for openEHR. I am working with several clients right now to do exactly that , for both professional and patient-facing apps.
It would be good to a bit more information as Birger suggests but broadly speaking, the idea is that openEHR takes over the data management aspects of the app (data definitions, storage and increasingly business rules).
This can seem counter-intuitive at first since a lot of individual apps themselves have quite simple information requirements / rules or are operating as purely patient-facing apps, where provenance and trusted, medico-legallly safe data handling seems out-of-scope. The complexity of openEHR, which largely reflects the real complexity of health data, seems overkill.
However, at some point, if the data in the app is seen to be valuable to health professionals as well as patients, you start to hit hurdles. How does my app’s data definitions line up with everything else (usually not), how does it hook up with professional-grade authentication/authorisation services, and proper provenancing/versioning of data commits. How do we integrate with the need to use terminologies like SNOMED CT etc.
The premise of ‘open platform’ is that it makes much more sense to offload many of these burdens of data management, and the integrations that surround it.
You certainly do not need to use the openEHR data-structures natively in your app until the point of commit, but doing so does provide some advantages, as when you commit the data to the openEHR datastore backend, you do need to use the openEHR data definitions.
So quick answer frontend optional, backend mandatory, though there are various efforts ongoing to make it easier for third-party devs to bridge that gap, through simplifications.