Machine Learning , some thoughts

Bert Verhees bert.verhees at
Wed Jun 27 11:57:59 EDT 2018

On 27-06-18 17:12, Anastasiou A. wrote:
> 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.

You can always map them to structures FHIR requires, and that is 
accepted by a growing number of vendors.
> 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 +").
I know the difference between semantics and syntax.
> 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.
And heartbeat is heartbeat. And when a device measures heartbeat, there 
can't be much doubt about what is meant.
I have sport-app which tells me the power I produce, and it tells me 
that in Watt/kg
That is more important then BMI, because athletes can have a BMI above 
thirty (muscles are heavier then fat) and be very healthy, so important 
is to know what they can do with all that weight.

I didn't see that one in CKM. When do you expect that to be there? Will 
it make the next Olympics (in 2020 in Tokyo)
And in the meantime, we tell those athletes to be patient?

For boxers, weight is also very important, if the grow into an higher 
class, they are the lightest person in that class and become from winner 
a loser.
So they watch very carefully what they eat. They could use a 
machine-learning program which tells them how many sandwiches to eat.
Because every person reacts different on food, the one gets fat from the 
same amount of food where another stays the same.

They need tables which tell, the bread with cheese has so much calories, 
and bread with fish so much. How would these tables come alive. In 
And this morning in the gym, he spent so many calories on the cross-trainer.
These are also data which can change. Maybe the tables not in the 
archetypes, but the items with calories on the moment of intake of the 
food in the archetypes, so that is recorded that a sandwich with cheese 
was lighter last year then this year.

(sorry, just having fun)
>> 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.
Of course they will tell people and let them write archetypes, if they 
want to support OpenEhr. But mostly they do not want that. They deliver 
the Watts/Kg on a webservice as just a number. We envelop it in a 
micro-archetype, so it can find a place in an OpenEhr database.
> Imagine Steps_Walked defined separately for FitBit, FitBlit, FitZit, FitBic, etc, when they can simply all use the same archetype.
Exactly, and it can be a micro-archetype, which makes it modular. Not a 
cluster, because it is only one data-item. It will be an ELEMENT. A 
CLUSTER with only one datapoint looks a bit stupid.
Better is in CKM that they replace all CLUSTER slots with ITEM slots so 
that it can be a CLUSTER or ELEMENT, what is appropriate.

When do you expect this change to be done, so we can support Fitbit in a 
proper way?
>> 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.

The Protocol section is not very important?

> 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.
>> openEHR-EHR-OBSERVATION.fluid_input.v1
>> . . .
>> Some want a device-archetype, and some allow everything (from type CLUSTER), for example at0039 (Fluid Details)
> Same case as above.
Except that this example was from the Data section, which makes it 
worse, as you say.
I am just pointing out that there could be more consideration and 
>> 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.
I do not want to discuss the hard and good work reviewers do. And I do 
not want to criticize them.
Their task is hard. Maybe too hard. Maybe CKM should not be the only 
source of truth
> 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.

I gave you a few examples.


More information about the openEHR-clinical mailing list