I have a different take on this from Burke’s.
I’ve been assuming that the biggest value add of OCL and the subscription module is to allow you to assemble your implementation’s dictionary from 90% shared content, and 10% local/custom content.
The general workflow there is that you would have an “AMPATH” organization on OCL, which would have an “AMPATH Custom Concepts” source. Then you would have a collection like “Combined Concept Dictionary” in which you would include the CIEL concepts that you want plus the AMPATH Custom Concepts that you want. And your OpenMRS servers would subscribe to this collection.
So you would use OCL (and not OpenMRS) to do concept management, including local ones, because it allows you to easily see when you could be pulling in an existing concept, vs when you need to create your own custom one.
I wrote more about this vision in the context of Bahmni a year ago: Using OCL to Manage Bahmni Concepts. We haven’t actually done any of this yet though, but I believe the OCL tooling is now ready to support this (which wasn’t true a year ago). AMPATH’s scenario is a bit less complex (because you’re not talking about having starter sets for multiple implementations) and is probably close to how PIH is drawn in the diagrams.
(I have not thought through what you’d do in the situation where you start off by using a CIEL concept but you then decide to fork it later.)