This is something that @harsha89 had discussed with me several times, and we’d shared similar concerns.
Right now, the FHIR module supports the export of a subset of FHIR resources. The last release of the FHIR module supported OpenMRS 198.
Currently, we have three separate GSoC projects on FHIR underway. One student is building support to create OpenMRS data using FHIR, another is working on complicated lab support for FHIR, and finally, a third is working on authentication. Given the parallel development efforts, it would be hard for us to get a stable release out anytime before the end of the GSoC period.
Another issue is our need to keep in line with HAPI FHIR API, which we are strongly tied to. The FHIR spec went under ballot in 2015 May, and currently there’s a lot of minor modifications underway. If HAPI were to commit changes to a snapshot version that we need to use (this has happened, BTW), then we’d have to bump up to using a snapshot version, just to make it easier for us to get on track with supporting the FHIR spec.
Also, our focus is to get FHIR into the OpenMRS 2.x platform. I agree that we need to enable as much uptake as possible, but given our long term plans, it made sense to focus on getting FHR in a position to move into the platform.
Does any of this make sense? the platform vs. the ref app has been always been a complicated issue, at least for me.
@burke, would appreciate your comments, as always