BI Capabilities on openEHR

Implementation Platform
1

Hi all,

I am analizyng openEHR capabilities but I cannot find information regarding on BI and Analitycs.
I am not wrong, information model is oriented to store a complete xml into a field but, what options do we have to extract information and add some reports, charts, … to it?
Thanks in advance

1 Like
2

Have a look at this thread please. Business Intelligence tools with openEHR support - #15 by pablo

3

Many thanks @joostholslag
So the idea is create a datawarehouse applying ETL over each XML and structure the info. I supposed that BI was generalized because the structure of the information is well formed before the aggregation and some standard fact tables could be created by default, but it has sense develop ad hoc fact tables denormalized to extract measures and KPI
Regards

4

@Hector_del_Castillo,

our learning at Hannover Medical School and HiGHmed is that openEHR can be an excellent foundation for an Enterprise Data Warehouse (for the clinical data part) and then specific data marts can be derived. This can be automated to some extend as describe here:

There is also ongoing work on semi-automated transformation into OMOP data model.

1 Like
5

So the idea is create a datawarehouse applying ETL over each XML

I’d see it more as creating a set of BI-oriented AQLs as the basis for your ETL, then normalising those AQL resultsets into a SQL or CSV type structures. You generally do not want to be working with whole compositions for BI type stuff, I’d have thought.

3 Likes
6

Hi Hector,

In general terms, ETL is applied over a database, not over a set of XMLs, but not sure what your requirements are.

Also, in general, a transactional database used as the information source is not the one that is used to store the information to run BI procedures (aggregate, drill-down, etc), which in general has a different structure like start or snowflake, so the ETL is from the source to the star/snowflake. XML, JSON spreadsheets, CSV, text files, etc. could be used as middle formats for the ETL or as secondary data sources, for instance if you need to mix your main clinical data with other kinds of information like geolocation.

So this doesn’t seem to be correct (unless you are using XML as a transport format, but conceptually that is not your data source)