Exactly! you have better words than me 
There are many approaches for extracting data, all valid, each might fit specific requirements better. Architecturally, a broker component could be built to sit on top of any CDR and transform any openEHR structure (complete compositions or AQL results) into a plain structure on any format (text, CSV, JSON, XML, …). Note that broker should be built in a custom way, considering specific data requirements, like what we are building to integrate FHIR into the EHRBASE for HiGHmed. It’s easy with the data requirements, to create the corresponding data mappings, and implement those in the broker.
PROS:
- a broker can be as complex as needed
- a broker can mix openEHR data with data from other sources, standards, APIs and formats
- the ETL doesn’t depend directly on a CDR
- a broker can have a temporal storage for the ETL data (intermediate schema)
- a broker could get data from the CDR in a way that avoids to overload it (good for production environments)
- could be better for scaling
CONS
- adding a broker adds complexity to the overall architecture
- needs extra resources and maintenance