A note on exporting and importing OCL packages

Following conversation from the above post, what appeared like an OCL .zip export containing coded questions and their answers not being loaded by the openconceptlab api correctly i.e. the questions not getting filled with their answers, with attempts to load their concept mappings showing failure logs, was instead a problem caused by missing concepts answers/references in the package. After following up closely, it became evident that when packaging an OCL collection, one has to include all references/their target and from concepts to the collections to avoid such cases as I have highlighted above. This should be the default behaviour IMO with a prompt to rather exclude an option.

To resolve the issue, I had to select all references/mappings associated with the concepts and added them all to the collection including the from and target concepts as shared in the snapshots below, then finally downloaded the generated export file. I’m using iniz ocl domain to import the packages.

cc @grace, @akanter, @mksd, @ibacher, @paynejd, @mseaton, @jamlung

1 Like

I’m a little cautious about what should be the default behaviour for OCL, since it has use-cases beyond OMRS where this may not always be the appropriate default.

That said, this is not always be the right behaviour even for OMRS. As a basic rule, this is the right behaviour for mappings of types Q-AND-A and CONCEPT-SET, but that’s in part because OMRS treats those two categories (ConceptAnswers and ConceptSetMembers) differently from other mapping types. For example, if you had a SAME-AS mapping to a PIH concept, pulling in the actual PIH concept would, in fact, be the wrong behaviour (because the SAME-AS mapping means, more-or-less, “can be used in the place of”) and, concretely, you would end up with a collection that imported two concepts with the same SAME-AS mapping (your mapped concept and the PIH-mapped one). The problem here is that the “right” thing is situationally dependent and so, it kind of makes sense to make it an explicit choice on the part of the user.

Incidentally, the OpenMRS Dictionary Manager was an attempt to help hide the inner workings of OCL and implement some OpenMRS-specific business logic. That tool, though, has been somewhat stagnant as we haven’t had a real champion in the community willing to put resources into maintaining it (it still works, but there are newer features we could take advantage of in OCL that we currently don’t).

1 Like

@ruhanga @ibacher Thanks for the discussion. I agree with Ian that there is some specific OMRS logic that is inherent in this process, so OCL needs to be thinking about how best to handle such cases.

For what it’s worth, we have a very near term effort (which falls under a category we call “Cascade”) coming up that is pretty directly related to this. It’s the general idea that, when you are trying to build a collection, you can select one concept to add to a collection and also get its related mappings and concepts. Some example use cases are in this comment in our GitHub. The goal is that we can come up with a workflow and UI solutions that can meet OpenMRS needs and non-OpenMRS needs.

If anyone here would like to get more involved in this effort, we are hoping to engage users about it pretty soon. Please let me and/or @pauladams know if you want to be engaged in helping this effort move forward.

1 Like

Ohh, ok thanks @ibacher, it then makes sense why this step was considered. Following your comment on github @jamlung, thanks already for looking into such openmrs specific use-cases to Improving user experience with OCL.

@ruhanga so the OpenMRS use case can be responded to, but it requires to tick options that are not selected by default when making the export. Is my understanding correct?

Correct @mksd.