Machine Learning , some thoughts

Bert Verhees bert.verhees at rosa.nl
Wed Jun 27 10:24:49 EDT 2018


On 27-06-18 15:14, Anastasiou A. wrote:
>
> Not as “fact”, it is probably how I expressed it, this is my 
> understanding so far and I would not mind it being corrected if wrong.
>
> >It is an archetype, it is written in ADL following the ADL-syntax, it 
> is  processable by AOM, it consists of datatypes from the reference model.
>
> That is the first level. Archetypes re-use RM types and they in turn 
> are used to define more complex structures. So, the Archetype becomes 
> a type itself.
>
> 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.

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.

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

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.

> >For example, all those cluster archetypes, they cannot be added in an 
> composition, they are to add to an entry archetype, which at that 
> point has a slot as container.
>
> My understanding is that this specifies a “Composed Of” type of 
> relationship with Archetypes that should be descending from a specific 
> type. At that point, you don’t
> really care what that archetype will be defining, but you do specify 
> that whatever is attached to that slot should be bearing a specific 
> type of information (conceptually).
>

That is not always the case.

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 checked the status: Published

Okay, must be devils luck, let's click another.
openEHR-EHR-OBSERVATION.fluid_input.v1

It also some slots, what do they allow?
Some want a device-archetype, and some allow everything (from type 
CLUSTER), for example at0039 (Fluid Details)

And the status is Published since June 2017, after two review rounds and 
33 reviews by 19 reviewers.

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.

But shall we then be a bit mild on people solving their own affairs?


> That is not a container.
>
> I do not see any major disagreement (except maybe difference in 
> specific concepts) here. You can construct N different isolated 
> archetypes for all the information
> produced by new devices. Ultimately, you will still have to compose 
> them into a larger structure by bunching together the similar 
> concepts. That would be a bottom up design.
>
> 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.

> Maybe what you propose can be expressed using the functionality of 
> Archetypes but that would be more of a “hack” (in a positive sense) 
> rather than intentional use (?).
>
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.

Bert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180627/68f3d368/attachment.html>


More information about the openEHR-clinical mailing list