Currently I'm researching two areas of #openEHR CDR implementation: 1. Conformance verification, 2. Performance / High throughput. For #openEHR conformance verification I'm continuing my work at #HiGHmed in which I designed hundreds of test cases and data sets (archetypes, templates, JSON and XML instances), to verify an openEHR CDR complies with the openEHR specs.

There are some #openEHR marketing materials circulating that states "openEHR is a clinical data persistence standard" which is incorrect and people is getting and forwarding the wrong message. First the marketing material mixes what is the #openEHR specification with some implementation (won't name names). Second, openEHR specifications don't even mention how to persist clinical data.

Healthcare information has many zoom levels, from microcellular, tissue, organ or DNA data, to international metrics and statistics, and everything in between. When working on healthcare data platforms it's important to know at which level(s) you are working. That will determine how you design your components, repositories, rules, APIs, etc. and when your processes change between different zoom levels, for instance, aggregating data.

Recordé la publicación "Estándares e interoperabilidad en salud electrónica: Requisitos para una gestión sanitaria efectiva y eficiente" de la Comisión Económicapara América Latina y el Caribe (CEPAL) de Naciones Unidas donde hice mención de #openEHR allá por 2011. Fui coautor junto a Selene Indarte, en ese momento presidenta de SUEIIDISS (HL7 Uruguay), ella escribió desde el punto de vista de la gestión sanitaria y quien les habla desde los estándares y la interoperabilidad.

In the last couple of weeks I've been studying and testing the #openEHR demographic model which has a lot of potential though it needs some improvements. First it needs more flexibility to specify roles by setting the identities to optional. Second there is an inconsistency in the languages attribute which is DV_TEXT and a better option would be CODE_PHRASE.