I’m guessing that you would like to save some data into openEHR. You need to convert from your format to what openEHR expects. Is this what you are trying to achieve - your description doesn’t mention openEHR?
What is the content of your data? Have you found the archetypes that are similar to your data?
You will have to map your data to the openEHR archetypes/templates first. These will finally be saved to the openEHR CDR using the API.
This isn’t “an easy automatic process”. And technology whether it is XML/JSON isn’t to blame.
Thinking about your requirements in small tasks will help you start in achieving your goal. Wenting about the technology will put you in a bad mood and you will procrastinate even more.
Check out the LinkEHR if you decide to use a tool.
I’m not in openEHR context at all. I have a e-commerce platform, running on WordPress, Laravel and other servers and are connected vie AWS SNS / SQS event queues. An EDA. Messages (my wire protocol) are not yet formally specied, just by the de-facto standard, the implementation. Now I would like to put a formal specification in place, my idea there was json-schema. Then any participating service could generate native code from that schema. so far the idea, but still some digging needed it seems but thanks for listening
I’m not sure how comprehensively I should be discussing e-commerce architecture in openEHR forums, but still, now that you’ve given some background:
Given the current talent pool and practices of the industry, REST at the system boundaries is still your best bet. That’s OpenAPI, with its tooling and community etc. I don’t see any realistic alternatives to that, anything smarter will leave you alone against the status quo.
Things are different internally. Xml is still an option there, and protocol buffers have decent support for code generation, generally more mature than json schema IMHO. We have deployments in production that expose REST to on-prem systems (in hospitals), which then uses RabbitMQ to talk to some backend, via protocol buffer payloads. XML also gets used in the backend, event driven side of things, because … well, it works.
I’ll force myself to stop here, since this is getting sidetracked
“That’s OpenAPI, with its tooling and community etc. I don’t see any realistic alternatives to that, anything smarter will leave you alone against the status quo.”
totally agreed upon this! Especially the second part. As sad as it is.
That is the reason I am actually putting so much effort into this, even that it drove me far away outside my domain, until even into the openEHR here. Do not even know what that is. Please excuse me for de-railing the forum here, that was not my intention.
Thank s for the polite and pleasant hosting of my quest. I guess we’re all unite in our aim to find a decent working standard compliant system to build our cases on without always starting back from scratch. In this sense, I just was taken by surprise how immature and brittle all this json-schema / openapi thing is. Have not expected that.
and now back for some real work
“Be liberal in what you accept, and conservative in what you send”, Jon Postel.
but thanks for listening 
