We need a common understanding and high level approach for OCL and OpenMRS interoperability beyond the subscription module. There’s good progress toward MVP of OCL for OpenMRS, but for PIH and deploying/updating production systems, this must include this full “happy path” from OCL -> Code -> OpenMRS Implementations. Is it possible to support Initializer (‘Iniz’) compatible csv format? Is this a good approach?
Should we discuss via this Talk thread? A Slack channel (#OCL or other)? Design meeting?
Maybe the approach would be for OCL to generate an Iniz compatible CSV or a Data Exchange XML or even a metadata deploy package for all concepts (or for a selected set) or even a single one
That way even if the integration of the output is manual at the beginning OCL adoption can start - currently we have no use at all since the concepts cannot be gotten out of OCL
Thanks @ball for starting this conversation, very important one.
OCL being able to provide concepts ready for the OpenMRS config (that’s the official name of what Iniz consumes) would be a terrific feature. I completely second @ssmusoke on this.
Another option that I have been working on is to simply being able to extract the above config from any OpenMRS instance that has Iniz installed. This would lead to a somewhat heavier process that would work this way:
OCL for concept management → concepts received on an OpenMRS “metadata instance” (running the OCL subscription module) → concept extracted as an OpenMRS config (aka ‘Iniz’ config) → config deployed on “real” instances running Iniz
That is a workaround where an intermediate “metadata instance” is used as a buffer between OCL and the target instances. It might still be used for a while though because the intermediate instance can also help maintain other pieces of metadata than concepts, and those could be exported as well in the very same fashion to be part of deployable configs aimed at real instances.
Lastly, and specifically in regards to CIEL, I intended to reach out to @akanter in the next few weeks to work out with him a way for CIEL releases to not only produce the usual SQL file but also new concepts as an OpenMRS config patch. This would allow implementers to start off the SQL dump at first and subsequently only add the CSV patches every time there’s a new CIEL release. Cc @jesplana.
P.S. Again, “OpenMRS config” refers to what is in the configuration/ folder that Iniz consumes, see the README.
This would be my preferred approach. Right now we have a stand-alone OpenMRS instance that acts as our metadata server and we generate Metadata Sharing packages that we include in our OpenMRS config (via some custom import functionality we have added to our PIH Core module).
Ideally, we wouldn’t need a stand-alone OpenMRS instance to serve as a metadata server, but rather have OCL/OCL for OpenMRS generate the export that we can include in the OpenMRS config. And I’d prefer to migrate away from Metadata Sharing packages to the “standard” CSV format that Iniz consumes. Metadata Sharing has served us very well, but it’s rather slow and opaque.
@mksd - @mogoodrich and I had the exact same discussion yesterday, and also discussed the approach of using the Subscription module to go from OCL -> our “metadata server”, and then from there to Iniz packages or similar as a solution (interim or otherwise)
The main thing we are trying to figure out at PIH is how to make near-term improvements to our Concept installation process while doing this in such a way that will be compatible with our long-term plans for Concept Management.
What some of us have been considering internally that we prioritize evaluating a move of our Concept Installation process from MDS packages (which are slow and cause a lot of issues in our builds) to Iniz-supported CSVs. We can do this with the process you describe above using the intermediary server and subscription module, and then investing effort in tools to export our dictionary as CSV. However, there is some reluctance to do this if that CSV format is not a planned data exchange format (eg. not a planned output of OCL).
If we have a technical roadmap we can follow here, it will allow us to both make short-term improvements to our processes while also allowing us to prepare for OCL adoption more easily.
What do we need to do to agree on Iniz-compatible CSVs or another alternate data exchange format that will allow exporting from OCL and importing into OMRS? @paynejd and @raff FYI.
@mogoodrich and @mseaton, the good thing is that Iniz already provisions for a version to drive the behaviour of CSV parsers.
Meaning that if the standard OCL tabular CSV representation of concepts that we may come up with is different than the current one, there will be all the room to parse them specifically while remaining backward compatible.