@dkayiwa Yes. For example FHIR Group object has no description field so Cohort.description won’t be synced.
@kcissewski was it agreed upon that such data is not critical and hence can be ignored in production?
@dkayiwa No it wasn’t agreed. I think we should review which data is critical and required on production. In case of required data we can use extension on maybe other field.
I have long been concerned by this and have often expressed my desire for us to focus first on synchronization of all data via the OpenMRS Web Services model, and add the option of syncing with FHIR as a secondary feature, as for me the most important thing for the sync module is to reliably sync any and all data between 1-N OpenMRS instances in the same managed network.
Can someone involved with the sync2 project explain the primary use case of using FHIR as a data exchange format for Sync2? Are we doing this in anticipation of Syncing data with other systems (FHIR servers or other systems in an HIE)?
@kcissewski i do not think any implementation would take on a solution that regards any collected data as non critical, and hence that can be lost during synchronization.
I think am with @mseaton on this, I think the most important thing is to be able to sync data, using FHIR vs another data format is of less significance as of now, I want to believe FHIR has not yet been widely adopted so we shouldn’t let it hold us back or slow us down.
I fixed Allergy and Cohort mapping proposals. To synchronize fields that are missing in FHIR Objects we will use extensions. This will let us synchronize all object fields.
Hey Mike. Yes, supporting FHIR standard is mainly done in anticipation of syncing data with other systems. I believe FHIR is getting traction nowadays. Support for it shouldn’t slow us down significantly and also it is likely better to plan in longer term.
The main goal of Sync2 module will be to sync any and all data between multiple OpenMRS instances.
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.
I completely agree with @mseaton
@mseaton Thanks - these are legitimate questions. I wasn’t involved in this project last year, hence I don’t know full context.
@pgesek Can you shed a light on the prioritization of FHIR support rather than REST?
Replacement for openmrs sync module based on FHIR (as much as possible) and atom feeds
- LOE: 6+ months
- Customers: of interest to many existing OpenMRS implementations (many are desperate for a usable & reliable sync solution)
From what I understood the intention was always to further OpenMRS interoperability by using FHIR and that was an integral part of the Sync 2.0 effort. Using OpenMRS REST representations was done primarily to represent resources that couldn’t be represented in FHIR, but also to showcase how the module can be extended with different connectors (FHIR, REST, HL7?, etc.). But FHIR was always treated as the primary means for communication.
As to why the whole thing wasn’t done with REST to begin with - the idea of the MVP was to just showcase synchronization of patient data and that was done with both FHIR & REST - it demonstrates how different sync methods can be used to achieve syncing.
Regarding the path forward, my opinion is that we definitely should be adding REST connectors in order to keep the idea of an extensible module alive, but shouldn’t push FHIR to the side. We should start these discussion about the representations sooner rather than later, especially since the current scope of the project also has FHIR written all over it.
@kcissewski have you already laid out a plan of how you are going to use extensions for fields that are missing in FHIR? Can you share some examples?
I’m working on the way how to use FHIR Extensions for OpenMRS needs. I just finished initial research on the extensions.
For anyone interested in FHIR Extensions, but not really into them yet, I suggest reading the following blog posts. They explain in an easy way a lot on FHIR extensions.
The work on the extensions can be tracked under the following tickets. We decided to start the implementation of the FHIR strategies without extensions first, the extensions will be added in the ticket FM-260.
- Research on FHIR Extensions - https://issues.openmrs.org/browse/FM-258
- Search for existing FHIR Extensions matching our needs - https://issues.openmrs.org/browse/FM-259
- Add FHIR extensions to implemented FHIR Strategies - https://issues.openmrs.org/browse/FM-260
I’m currently looking for existing FHIR extensions, located on public repositories, that match our needs. We want to minimize the number of new extensions we’ll have to create. However, for all the fields that won’t match any existing extensions, we will have to create a new local extension.
We will share additional details on the extensions as soon as we will have determined what extensions we are going to use, and what extensions we will have to create. This should happen within a few days.
Once again, thanks for your feedback and time.
Sorry for my slow reply on this. I wrote that initial statement that Pawel mentioned, and I definitely want to see the FHIR improvements happen via this project because it has lots of ancillary benefits. And it hopefully gives us some protection from data model changes, e.g. even allowing you to sync between OpenMRS servers running different versions of the API.
One thing, though, is that if some domain object does not map well to a FHIR resource, or the FHIR resource is low-maturity, then we should not hesitate to just synchronize that domain object via REST. (Especially for the metadata.)
And like others have said, all data must be preserved when synchronizing. Except for one thing: it is not necessary or desirable to preserve the database primary key. (E.g. I just peeked at the mappings for Cohort and I see “cohortId” mentioned there, requiring an extension, but this should not be included from the perspective of sync.)
One further addendum. I do not personally think it’s necessary to synchronize “dateCreated” and “dateChanged” and a few similar fields, or to represent these in FHIR. (I’m curious what others think.)
Can we scheduled time on a design call to go through the proposed mappings? There is a lot of content there, and it’s obviously hard for people to make time to review it, so maybe scheduling that time is best.
Specific comments (just based on quickly reviewing these during my last call):
- Form https://wiki.openmrs.org/display/projects/Form+synchronization
- the fact that nothing about FormField matches anything in FHIR makes me think I would just do REST for this.
- if using FHIR, please look at the existing extensions that they mention in the Scope and Usage section at https://www.hl7.org/fhir/questionnaire.html
- for this and all resources, UUID should be our primary ID that we use externally. The database primary key doesn’t need to be shared, in my opinion.
- Drug https://wiki.openmrs.org/display/projects/Drug+synchronization
- seems wrong to have to use an extension for strength since that’s a primary use case for both our domain object and their resource. Maybe there’s a way to put that into ingredient/amount.
- About allergy https://wiki.openmrs.org/display/projects/Allergy+synchronization
- It cannot be right that coded and noncoded allergen need an extension that’s the entire point of the resource, e.g. what is the patient allergic to. I think the correct FHIR field is “code”. (I believe that the CodeableConcept datatype in FHIR can be used to hold both coded and noncoded data.)
- About Programs https://wiki.openmrs.org/display/projects/Programs+synchronization
- I think this was a nice attempt at finding things that sort-of match, but I do not think the matches are good enough. E.g. patientprogram (i.e. program enrollment) is not really a “referral”. Care Plan and Episode Of Care in FHIR should be reserved for when we support those actual resources in OpenMRS, not used for something that they don’t really match.
- in other words I would use REST to synchronize these
- https://www.hl7.org/fhir/researchstudy.html and https://www.hl7.org/fhir/researchsubject.html are close to what we intend for Program and PatientProgram, but they have maturity level 0 so I would not use them.
@darius Awesome - thanks for concrete feedback. I agree that scheduling a time for a design call should speed things up and hammer out object mappings.
I’ve proposed object mappings as a topic on Propose a Design Forum Topic for next available slot and I invited people that are involved in the discussion here or likely were in the past. Let me know if someone else could be invited as well.
I’ve looked through public FHIR extension repositories (hl7 and simplifier) for extensions that might match our needs.
I’ve found 5 FHIR Extensions that might be useful for OpenMRS. I’ve published them on Confluence, under the following URL: https://wiki.openmrs.org/display/projects/FHIR+Extensions
Hope it helps in any way.
Have you looked at the FHIR dosage resource (https://www.hl7.org/fhir/dosage.html) for maximumDailyDose?
We had a design call on 2 Oct 2018. Notes available here.