Thanks @kkaczmarczyk. If we can achieve this (using extensions, etc), it would definitely be a huge benefit to have 100% FHIR coverage over the OpenMRS data model.
That said, my understanding from the early days of this project was that one could choose “Rest” or “FHIR” for a given entity that needs to sync, and we were mixing and matching these approaches. I was always curious as to why we didn’t just first try to solve the problem using REST, since theoretically everything is already available using this mechanism, and if it isn’t then this is a bigger priority to fix than FHIR support.
That wouldn’t close the door to supporting a FHIR-based approach, but rather just prioritizing getting sync working with existing REST representations and not getting slowed down by the work involved in mapping OpenMRS entities to FHIR resources in a way that might require broader community design input and iteration.