I wanted to try out the FHIR module locally and it failed when I tried to build it (naively using JDK 6).
Is there some reason that the module is being developed against the master branch of openmrs-core? Do we need some just-introduced functionality?
I would suggest that the FHIR module should be built against a released version of the OpenMRS platform, so that devs and implementations can consider using it for the (growing) set of use cases it already covers.
(Speaking just for myself, if the FHIR module requires OpenMRS platform 2.0.x, then I basically won’t look at it until next year.)
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
I think it makes perfect sense that (a) you don’t expect stability, (b) you reserve the right to backwards-incompatible, since the FHIR spec is evolving, and © the target is the next platform release.
However I don’t think that implies that you need to compile against the to-be-next-platform release. Unless you are explicitly relying on some openmrs-core master feature, why not just pick a released line and build against that? (That will mean that during development people can play around with FHIR in realistic environments, and when the release does happen existing implementations could use FHIR right away.)
Keep in mind that the OpenMRS Platform 1.12 / 2.0 release is going to be characterized by having a tougher-than-normal upgrade path for implementations (requires upgrading to Java 8) and modules (requires testing against new versions of Spring and Hibernate). My expectation is that existing implementations will be slow to upgrade. So, speaking as someone with ties to existing implementations, but also an interest in FHIR, I would be much happier if the FHIR module were targeted against openmrs-core 1.10.x or 1.11.x.
@surangak, it depends on your goals for the FHIR module. If you want to maximize adoption over the next year, then I’d try to appease @darius. If you are okay with FHIR adoption among users of OpenMRS 2.3+ (e.g., likely gaining speed in 2016-2017), then you needn’t worry about the pre-Java 8 or pre-Hibernate/Spring Upgrade world.
If we can devise a way for you (and all module authors) to reasonably manage support for both pre & post Java8/Hibernate+Spring Upgrades, then we’d be in a much happier place.
/cc @wyclif @raff
One of main issue that we may need to address when supporting FHIR is the incompatibilities of some data elements in FHIR resources and OpenMRS domain objects. Sometimes we require core features to support various attribute based searches in FHIR. But as per @burke we shouldn’t implement all the search methods based on resource attributes without a use case.
For example FHIR resource may have a mandatory attribute in a resource which may not available in OpenMRS resource, at that time we may need to discuss and add required attributes to relevent OpenMRS resources. So far we have identified few of them but they seems not blockers for the development.
The main advantage of developing against latest master will be getting core fixes to module without waiting for a release.
But as @darius and @burke mentioned. we need to consider other side as well. So that implementers can try the module and request for any feature enhancements which will make module to be mature and stabilize.
As Burke just told me in person, we’re between the devil and a very hard place right now.
We want to track the core, and we want people to be able to use it too. FHIR needs to happen now, not only in 2016 and 2017.
If we switch to supporting OpenMRS 1.11.2 (Which is what OpenMRS 2.2 is built on) we still won’t be able to release the next version of our module until the end of August, because that’s when GSoC ends. So, can we work against 1.11.2, release in August and then quickly upgrade to be ready for the platform in Q4 2015? I do think that despite of everything, we need to make it into platform 2.0.
@darius, @mseaton @harsha89,
I just had a chat with @burke.
@harsha89, things are not as rosy as we’d thought in the practical world. @burke’s opinion is that OpenMRS platform 2.0 won’t be released until late 2015 or early 2016. And given that Platform 2.0 contains major changes to hibernate, spring and java, it might be quite some time before implementations start adopting it. This is a problem, because we want to encourage early adoption.
@darius. plainly speaking, what version of OpenMRS would you like us to support? @burke and I are in favor of OpenMRS 2.2 (OpenMRS Platform 1.11.2) ?
As a general rule, I would expect a community-supported module to target the lowest supported OpenMRS release that has a sufficient feature set for it. In this case 1.9.x is out because it doesn’t have the new order entry API, but I would presume Platform 1.10.x is fine. (Offhand I can’t think of any clinically-significant functionality added in Platform 1.11 that would be relevant here.)
Further, I would like to see support for Platform 1.10.x because Bahmni uses this, PIH Haiti just upgraded to it, and it’s a very easy upgrade from 1.9.x (which is surely the most prevalent modern OpenMRS version).
Also, I would suggest applying a weak version of CD philosophy to development of this module: it should be continuously deployable. Anyone should be able to take any passing build of the module and install it on a recent OpenMRS setup to try it out. (No need to commit to actual CD, i.e. no backwards compatibility until the module hits 1.0.)
The GSoC projects ought to function using branches such that the master branch of the FHIR module is stable (also a courtesy to each of the students, since each one’s work must be independently reviewable, per Google).
To be blunt, a release strategy that counts on a new OpenMRS platform release happening and three separate GSoC projects being completed before it’s “stable” signals to me that implementations should ignore this module until it is actually released. Whereas a pre-1.0 module that is committed to always having some functionality working is something that I can recommend that an implementation test, plan around, and even fork to use in production for limited purposes.
@surangak we will need to evaluate 1.11.x bit because we may need some new features added in 1.11.x to FHIR module. @darius will do a quick evaluation and see whether which version will be more suits for the FHIR. :).
Thanks, FHIR module team, for looking into this.
I’m really excited about the potential of the work you all are doing, and I
just want to make sure that people all over the community get as much as
possible out of it.
Hi @darius and everyone,
I think it’s important to note a couple of realities, just for everyone’s consideration:
As it currently stands, FHIR is on it’s 0.5 release… that is, it’s in “comments period” for the second “draft standard for trial use”. Following this comments period, it will enter into a 0.6 release.
Our OpenMRS FHIR module is currently built against the 0.5 DSTU2 comment version.
Following this, there will be a period of real world use, and hopefully insufficient change feedback to drive them towards a DSTU3. Grahame’s goal is to avoid another DSTU as well.
If that happens, there will be a 0.9 “pre-release for comments version” as well as a “1.0 release” (which will be available in the mid-late 2016 timeframe.
So as you can see, there’s still a fair bit of work to be done.
Now, the reason I’ve been advocating for work on FHIR, is that I thought it would be useful for us to influence the standard towards our needs (which has happened on a couple of fronts already)… and for us to have the time given our often deliberate and sometimes slower community process, to build up code that can grow into something that is ready when 1.0 is ready. We’re well on our way there.
Underneath all of this is the strategic question: “to what extent do we want to encourage real world use (at scale) of something that’s still under review and change?” I’ll leave that for you all to think through and consider, and for my part, I’ll make sure that Grahame is watching this thread so that he can intercede when needed.
Hope this helps!
I think there’s 2 different change kinds mixed up in here.
FHIR is still changing, and will be for a couple of months. The kind of changes we are making are almost all fine adjustments around field content, or corner cases in the API. From this perspective, it makes sense to isolate the openMRS FHIR work in a module that’s got it’s own lifecycle.
However the changes are overall fairly small; I wouldn’t think they would have architectural implications for the interface between the FHIR module and the rest of openMRS. And I would think that this is where the heavy lifting is - what are the implications for core schema, for user management, for concept dictionary management. I would have thought that it wouldn’t be easy to make the FHIR module very version independent from openMRS core
Hey @grahamegrieve, nice to find you on talk
And thank you, we agree.
Right now, @harsha89 is trying to evaluate 1.10.x and 1.11.x, and trying to figure out their compatibility with FHIR needs. Once we hear back from him, we should be able to arrive at a decision as to what version/s to support…
Hi @darius, could you please explain your suggestion on being continuously deployable? are you speaking in terms of “the next release of the FHIR module should be usable by OpenMRS 1.10.x, 1.11.x and 1.12.x?” or is it more in the lines of the philosophy used in the webservices.rest module?
@darius I have went though the changes in openmrs core 1.10.x and 1.11.x. It seems there are no major openmrs core level changes. With the 1.11.x, I saw that appointment scheduling and chart search comes to the OpenMRS 2.2. From them appointment scheduling contains some FHIR related resources. But for now we can just leave it there. And what are the clinically-significant functionality added in Platform 1.11?
“Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.”
I am suggesting that you all follow a limited version of this philosophy while developing the FHIR module.
Particularly, I presume that the module doesn’t create any database tables or significant state, so there is no reason that an interested implementation couldn’t install the very latest build of the module for testing at any point (e.g. to test that a resource you just implemented works as expected).
What I am suggesting is:
- You have a CI build, with good test coverage.
- Significant in-progress changes that will break functionality should happen in branches
It’s really about following this as a guiding philosophy, rather than approaching things from the perspective that it’s okay for the build to be functionally broken all summer because release won’t happen until after GSOC.
(And #2 is good practice anyway with multiple parallel development streams.)
Hi, to summarize, we had a very insightful design call with @darius today. As a result, we agreed to support OpenMRS 1.10 so that PIH, Bahmni an other implementations could benifit from our work.
Thank you for the expert advice, @darius
I was going to take a look at this (one year later!) but I see there is only one release of this module in Modulus, from May 2015. Is this module still being actively maintained?