Why have you started using Iniz?

Dear Iniz users, I am a newbie and non-tech, are you able to say why have you started using Initializer, basically what were you struggling with before and what has it helped you with now? Is it all benefits, or have you seen cons for this approach? I remember the OCL presentation at the annual conference, it seemed like a game changer, but btw is Iniz and OCL the same thing? Many thanks @mksd

2 Likes

Thanks @kbediri for your question.

No OCL and Iniz are not the same thing. OCL is an implementation of a component of the HIE architecture: the terminology service. All components of the HIE architecture should rely on the terminology service to be fed their clinical terminology. In particular, the EMR components should obtain their clinical terms from the terminology service - that is assumed to be the source of truth in the HIE architecture.

In OpenMRS terms: concepts are managed in OCL and OpenMRS instances should obtain their concepts from OCL. This means that concepts should not be managed locally. And then I would say there’s two practical possibilities:

  1. There is a reliable and secure link between OpenMRS instances and OCL, in which case there is a subscription module that can be installed in OpenMRS to download concepts from OCL over that link.
  2. There is no reliable and secure link between OpenMRS instances and OCL, in which case the OpenMRS instances are virtually offline and there should be another mechanism to convey the concepts regularly from OCL to those OpenMRS instances.

Iniz can be used to work around the second case. The idea is that concepts would be repackaged regularly from OCL into an updated OpenMRS config (which is the name of the config that is loaded by Iniz btw), and this config would be brought to the OpenMRS instances in order to be refreshed with the updated concept dictionaries. Bringing the packaged config to the OpenMRS instances is an implementation “detail”. In other terms that’s the work of the implementer to figure out the best way to do that given the circumstances of the OpenMRS instances.


The thing is that the OpenMRS config packages much more than just concepts, it basically bundles into a comprehensive and versioned package all metadata needed to fully define the backend of an OpenMRS instance.

This means that concepts should not be managed locally.

In fact the paradigm of the OpenMRS config implies that no metadata at all should be managed locally, including but not limited to concepts. All metadata should be managed centrally and repackaged and propagated every so often to all the OpenMRS instances that are defined by that set of metadata.

2 Likes

@ssmusoke, @mseaton, your two cents? Why have you started using Iniz?

Thanks @mksd for taking time to explain, it is very helpful and very appreciated. Have you seen any major drawbacks that are worth mentioning?

Absolutely none, Iniz has been designed to solve an important challenge and it has achieved it fully since 2017 :slight_smile:

At @Mekom we even extended that principle to other systems that sometimes (strangely or even purposely) lack the ability to effectively do the same thing, i.e. package configurations. It is probably worth looking at this one as well:

Kudos to @zouchine on that one :muscle:

It is not a drawback but a necessary side effect of the OpenMRS config paradigm: metadata cannot be user-managed on the production instance anymore. Metadata is necessarily packaged and the source of truth is always the OpenMRS config.

3 Likes