There is no such thing.
To explain the context: the effort here is to have a new ITS artefact. An openAPI based specification of REST API, which can be fed into document generators, but (more importantly from an ITS pov) also to code generators. This gives openEHR community access to contract-first approach to our REST API. As in, you can get the output of this work, generate both documentation and C#/Java/… code and use that to adopt your existing systems to openEHR, or implement one from scratch, fulfilling the contract of our REST API.
Now, the “clinical APIs” as we call them in Ocean (and others do the same elsewhere I guess), are focused on level 2 of two level modelling, and specifying them based on OpenAPI, to achieve the same benefits I explained above, is a different task. This was discussed in the SEC meeting and my comment was that it would make a good downstream work, once we have the initial output for REST API.
I cannot see any reason for not doing the auto-generation work based on STRUCTURED or FLAT or webtemplate etc formats for the clinical APIs, but then the formalism used to derive the auto generation would not have the ecosystem that OpenAPI has behind it. I’d see that as a downside, but there would be upsides as well, since every re-use of a generic tech comes with its loss of information, and doing what you’re suggesting may offer benefits over using OpenAPI for it. I’d say this scenario has some problems by nature though, which I outlined in my discussion with Erik here: