Machine Learning , some thoughts

Anastasiou A. a.anastasiou at swansea.ac.uk
Wed Jun 27 12:55:42 EDT 2018


>>> 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.

Alright. If that enables you to infer what something is without having seen it before, then that's fine.
I have not looked into FHIR in great detail, this is a great opportunity.

>> 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?

 openEHR goes back to 1994 and its ideas are starting to become more widely known in the last few years.
As long as it is not part of medical school training, I do not think the CKM will see the archetypes you are dreaming about or 
others with more immediate application.

The design of archetypes is up to domain specialists. I cannot say if the example you provide is accurate or not.

>>> 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.

It is not up to them. There is nothing stopping people to start modelling the outputs of these devices on CKM.
And by the way, if anyone wants to do it (https://www.kickstarter.com/discover/tags/science), let me know, I'd give it a try.


The webservice example is what I would consider a hack. It produces an isolated Archetype just for the sake of storing it in the EHR in a convenient form.
What is Watts/kg as an observation?

If that question is not answered then you cannot query the data. Say for instance that you wanted to create "mobile lifestyle" profiles for each one of the patients in your EHR database.
With so many fragmented archetypes you would have to query each and every one of them. With a proper model you would have to say "All descendants of MOBILE_OBSERVATION".

The rate of growth of micro-archetypes will be faster than the rate of growth of the modelled / reviewed archetypes and we are back to square one. Things making sense only to some actors.

>> 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. 

This is what I am asking concrete examples of, of how this is going to be done (?)


>>> 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 reflection.

I think that you are taking the SLOT example out of context: "Additional details about the fluid" (...such as nutritional value)".
And this is on a Fluid Input Archetype. Why should it be any further constrained? If you refer to its Use section, you will see why the SLOT is unconstrained there.

>>> 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

What makes you think that the people working in an alternative form of CKM would not come across the same modelling problems?
It is hard to create a coherent model by which to express what is happening in the domain but it has been done in Mathematics.
Why not in Medicine too? (Or maybe the informatics aspects of it).

All the best
Athanasios Anastasiou



More information about the openEHR-clinical mailing list