Machine Learning , some thoughts

Thomas Beale thomas.beale at
Thu Jun 28 04:33:13 EDT 2018

On 27/06/2018 13:00, Bert Verhees wrote:
> Dear Seref, I do not agree with this without having explored all the 
> possibilities. I think it is important not to jump to conclusions and 
> keep the discussion open.
> I have some ideas how to keep it interoperable. I like to discuss that 
> with an open mindset.
> Talking about interoperability.
> By the way, how do you create FHIR messages from OpenEhr-compositions? 
> Or how do you create Openehr-compositions from FHIR messages?
> You have to create a template manually, fitting that item to that 
> datapoint, isn't it?

that is correct, because FHIR imposes its own model. This is the basic 
reason why one should not really use message standards to interoperate 
over systems whose data are already transparently structured. However, 
some organisations want to pay for these pointless conversions, so 
people do them.

> Even within two parties using OpenEhr. You are only automagically 
> interoperable when two parties use exact the same archetypes, else you 
> need to puzzle the dataitems.

they only need to use the same data points of those archetypes, or else 
any specialised derivative. This isn't hard to achieve; pretty clearly 
all systems using openEHR today use the same vital signs archetypes or 
derivatives to record vital signs. There is no point doing otherwise.

> The same things you have to do when you need to handle a generated 
> archetype. But it will not be that hard. Don't expect much complexity 
> from these generated archetypes.

I've missed some of the earlier discussion, but unless you are dealing 
with genuinely novel measurements or orders, you won't have any 
'generated archetypes' for most Observations or Instructions or Actions. 
You might have some for novel questionnaires or other kinds of 
assessment tools (new kind of score etc). But for the vast majority of 
cases, I would think the real need is for runtime /matching/ of data 
points from /existing/ archetypes to create on-the-fly templates, 
something we've known about for 15 years.

> I called them before, micro-archetypes, containing only one datapoint, 
> or a few closely related datapoints.

Let's assume some of these are created, for the reasons mentioned above; 
pretty soon you are going to want to curate them properly and add them 
to the library. Over time, the number of 'generated archetypes' will 
fall to nearly zero, and it will be the matching process that is the 
main challenge when encountering data not planned for.

> With machine learning algorithms, it must not be hard to interpret them.
> Don't understand me wrong, I like OpenEhr, because of the archetyped 
> system, and the flexibility it offers. It is not by accident that I 
> discuss it here and not in a HL7 group, although that would bring more 
> money.
> But if flexibility is slowed down by years of review, discussing and 
> consensus over the whole world for a set of archetypes, then there is 
> not much flexibility left.

it is slowed down, that's true, and it could be faster. But I don't see 
how that reduces flexibility.

> This can work very good for the archetypes which are in CKM, but all 
> those new devices, all those new datatypes, all this new protocols, 
> which cannot wait for these review-procedures, because the market will 
> be jumped far ahead by then.

I agree there is a need to be able to create archetypes much more 
quickly based on device specifications. We need to work on that.

- thomas

Thomas Beale
Principal, Ars Semantica <>
Consultant, ABD Project, Intermountain Healthcare 
Management Board, Specifications Program Lead, openEHR Foundation 
Chartered IT Professional Fellow, BCS, British Computer Society 
Health IT blog <> | Culture blog 
<> | The Objective Stance 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list