Machine Learning , some thoughts

Anastasiou A. a.anastasiou at
Wed Jun 27 11:12:40 EDT 2018

A few notes:

>>You cannot specialise the Blood Pressure Archetype to express anything other than blood pressure as far as I am aware.
> I am not sure about that, but it is not important in how I think about it. Because the micro-archetypes contain valid paths, they can be queried.
> A company delivering services to persons, using software/devices from X, know which archetypes will be generated, and they can query them.
> Semantics is also something in the eye of the beholder.

That's what I would be worried about.
If that company's archetypes were not derived by the bigger conceptual model, it would only make sense to its ecosystem.

Again, in CS the definition of syntax and semantics are two different things. Your notation might be A+B to denote addition but the semantic of the + operator 
over A,B Sets could lead to Union or simply remain undefined (i.e. "In our type system, you don't apply union over sets using +").

So, when it comes to communication, Semantics plays a very important role. It's not "my" definition of Blood Pressure. Blood Pressure is what it is. Maybe "we" tend to 
measure it intravenously but it is still Blood Pressure.

> Maybe it is not really generated but delivered by the producer of the device, a minimalistic archetype, it is not important, important is that it a minimalistic archetype is which can contain the data which are to delivered.
> Most manufacturers will not write archetypes, so a software vendor selling an openehr system is to deliver an archetype in which the data can be enveloped.

What would be great for manufacturers would be to tell "us" what it is that their device measures. If they could do it with proposing an Archetype hierarchy for vitals derived by consumer devices that would be even better.

Imagine Steps_Walked defined separately for FitBit, FitBlit, FitZit, FitBic, etc, when they can simply all use the same archetype.

> I don't not have it all thought through, how procedures will look like.
> But important is that manufacturer of apps and devices are many and they bomb the market with thousands of products and protocols. And it will only get worse.

I agree. I see a great opportunity. Let's get modelling :)

> Interoperability with the market is only possible if not every micro-archetype needs to be discussed and reviewed by the whole world CKM reviewers, that is not feasible for every corner of the world.

Indeed. Each specialisation level of the tree of Archetypes would be relevant only to a specific group of people.

> The first I click on in CKM, must be devils luck. It is an OBSERVATION archetype, made to attached those CLUSTER archetypes
> I clicked on the first which came under my mouse pointer: openEHR-EHR-OBSERVATION.body_mass_index.v2
> There is a slot in it, a CLUSTER slot. Which archetypes does it allow?
> All archetypes!! As long as they are CLUSTER

I suppose that you refer to "Extension" whose purpose is "Additional information required to capture local context or to align with other reference models / formalisms".
So, you cannot really constraint it any better than saying "It's a CLUSTER".

In addition, the examples you are mentioning are in the "Protocol" section. Not the "Data" section.

So, an accurate example is Entry/Observation/Demonstration whose Data specifies two Slots which are very well constrained. 

>Okay, must be devils luck, let's click another. 
> . . .
> Some want a device-archetype, and some allow everything (from type CLUSTER), for example at0039 (Fluid Details)
Same case as above.

> I understand the problems which the reviewers have. What shall we allow on a slot that wants fluid-details as semantics?
> It is obvious that it is hard to set a constraint there.

I do not think that this means "Any permissible". I think that this means "It is too early to tell". When we have Archetypes for those other RMs / Formalisms then these slots will need 
to be specified too.

>>Unless a machine can understand which concepts are supposed to be bunched together we will still need humans in the loop.

> Of course we need humans. But the difference is if we need an information technician on the spot, or reviewers from CKM.
> Often it will be a mixture of both.
This would make me feel more comfortable than automatic adaptations that exploit just the Pathable capability.

>I don't see it like that. A hack sounds unprofessional. Being agile is not unprofessional. It is adapting to an ever changing world. Which is 
> better then staying on the sideline and leave your customers with less functionality then they could have.

The Archetypes must be put on a coherent model. I would not see anyone working towards that as staying in the sidelines (?).

I don't mind continuing the discussion on a concrete example of how this could work. Maybe that would help formulate the idea better.

All the best
Athanasios Anastasiou

More information about the openEHR-clinical mailing list