Machine Learning , some thoughts

That could be possible, but then you get structure, and node-identifiers. Maybe just flat paths are more convenient, so that the OBSERVATION archetypes do not require CLUSTERS but ITEMs so that it is possible to include ELEMENTs on that point. I don't understand the restriction in a slot for allowing only CLUSTER, especially if that slot has an occurrence of *
But also I don't see an OBSERVATION archetype which is equipped for sports or lifestyle.

The problem is that I don't have customers for this, because they get scared away, when seeing CKM, they think it is not for them. They think it is for healthcare problems.
Like CKM has a lot of archetypes for all kind of OBSERVATIONs, but all related to problems, it should have an archetype for a not problem-related OBSERVATIONs.

Well there is no problem to do that - there is nothing specifically in the OBSERVATION model that mentions health problem; OBSERVATION is really just a 3-way structure of data/state/protocol for recording one or more samples of an datum. It's quite well adapted in fact to sports data, because the data attribute can record a time-series of a datum (or more than one) from the body, say heart rate and breathing, and the state (remember, 'state' means patient state) can record data items from e.g. a treadmill, e.g. a computed work rate or maybe the stroke rate on a rowing machine. So if you want to study heart rate and breathing against physical work rate, the data structures are very convenient.

Maybe more neutral, an archetype for food intake without mentioning the term Obesity.

I assume you are referring to the documentation more than the structures - that's probably a good point. If an archetype can equally be used for a problem (obesity) as well as a wellness program (general diet tracking) then it should be documented to have those possible uses.

Then it could attract vendors which work on the fast growing market-segment for sports and lifestyle.

How good would it be when the machinery for OpenEhr becomes available for this market-segment? The flexibility, the model-based queries, the data-storage, all the advantages for OpenEhr.

And also think of INSTRUCTION-archetypes to notate sport-plans, and workout out well. And ACTION archetypes to record the proceedings.

I would expect most INstructions and Actions to be specific for sport.

And because sports and leisure is very closely related to problem-centric healthcare, it is OpenEhr which can be ready to fill up the market-gap that now exist.

So, how about that?

I think you have a good point about the documented uses of archetypes potentially being too narrow - it would be worth a global review to see if anything already there can be used for purposes different from that originally envisaged. I wonder if clinical modellers have anything to say about this.

- thomas

The intention is certainly a good one. It just needs to be the reference model and the Abstract Platform Specification as the starting point.

  • thomas

While I share your point of view I doubt that adverserial
lawyers will be interested in understanding.

But that's far beyond the realm of this list.

Karsten

Dear Evelyn!
Thanks for the support! Please note that the statement is not mine, but from Edward Shortliffe. He was together with Christoph Lehmann, Patrice Degoulet and Hyeoun-Ae Park and Elaine Huesing leading the election process of the IMIA academy. The world is small :slight_smile:

Thanks also for the information about IAHSI. In the documents you mention I find no details about Christoph Lehmanns approach. What is it and how can we support it?
There are some among us who do their best to align standardisation efforts, across the many standards organisations and groups around, and connecting this to “the real world”. This is heavy lifting and all hands are highly welcome.

Looking forward,
greetings from Vienna,

Exactly right. Archetypes are high-value clinical informatics work, and they are free. Making more of them, faster, means getting more clinician and informatician time, which means that projects who would like to have domain models of information and process - even if their final consumption format is not openEHR - should consider providing some time (machine conversions are pretty easy, and there is a lot of open source software about to do them). It’s the only way good things get made faster and remain free for everyone to use.

  • thomas

I understand the message, Heather, and every time when I express some criticism about how CKM is functioning, I never forget to tell how important it is and how good work it is. When you would had copied the whole message, you would see a nuanced message.

Then you would have also quoted this: "I like OpenEhr, because of the archetyped system, and the flexibility it offers." and this: "This (procedures in CKM) can work very good for the archetypes which are in CKM, but all those new devices, all those new datatypes, which cannot wait for these procedures, because the market will be jumped forward by then."

In fact it is your quoting only a small part of that message which causes a extra negative image.

And maybe I am wrong, it is to others to tell me that. That is discussion. I think discussion is very important. I am therefor happy that you explain why you got irritated by my message. And I see your point. In the context of marketing, it is good to tell how important and how qualified the people are, and how many there are. And not only under a hidden tabview somewhere in CKM, but on the frontpage, in a blog, or on twitter.

I think OpenEhr could use good marketing, I promise I will do so (I will write a very positive blog about CKM, and share it in my growing Twitter-network, next week), to compensate that possible negative sentence I wrote.

Further that is another subject and I rather stay with this one where I started and I am glad to see that Thomas did some suggestions to which I gonna reply now.

Best regards, and I will better take care in the future.

Bert

Thanks, I take a look at it.

Bert

I was thinking of the following. We can “translate” the core-RM (which is to use in archetypes) to protocol-buffers definitions. These protocol buffer definitions are programming language independent. It should be possible to convert the definitions (in XML I believe?) directly to this format (with a small application). Is this still maintained, or is there something else I should use? I could write such a small application. Would take me a few days when doing it in spare time. This would be a good start. Next task would be a small application which “translates” archetypes to protocol buffers. I was thinking this afternoon how that could be done, because archetypes are flexible to use, you don’t want any archetype-code in the kernel. But on the other hand, protocol buffers demand compiled protocol buffer definitions. So archetypes will then be compiled for the sake of network traffic. This compiled code could have standard API calls to ask which archetype it represents. I don’t know how the feelings are about this. Bert

That is a good idea, and maybe we should get some volunteers which are involved in sports, on amateur level or professional level.

I would have thought the easiest way would be to machine convert the RM BMM and the Abstract Platform UML model to the protobuf3 specification format. Note that when reading the BMM files it is better to use existing tools or libraries to read them in and convert the multiple files to a single model - this is what you see in the ADL Workbench, and the new Archie project does this a well.

I think what would be most interesting is to develop a repeatable mechanism / tool to do this.

This would get us a generic protobuf3 service interface that implements the Abstract Platform model.

If you wanted to have a more specialised service interface based on particular archetypes or templates (I would have thought the latter), then it seems to me that you want to generate template structures as specialisations of their corresponding RM types. protobuf3 format doesn’t know about specialisation, so we would need to work out a way to represent it, but this has to be a standard problem.

Note that in protobuf3 you can specify a message definition and a service definition. This would enable the machine generation of message definitions corresponding to any openEHR data - i.e. the protobuf equivalent of Template Date Schema (TDS).

  • thomas

That is good, I look at the code, and see how it is done. Reading the model should not be a problem then. When I have questions, I let you and Pieter Bos on this list. Exactly my idea. I have written a proto-file for ucum, because I have written an ucum-micro-service. I do not have that open source (yet) but showing a part of the proto file does not hurt. Regarding to class hierarchy, when in the way, I take the widest class which can have all possible attributes and add an enum to indicate which class was meant. (I call it “flattened”, and put the word Derivates to the end, which, on second thought, would not have been necessary, all derivates of the Ucum Concept-class fit in this construct) This works good, because the only purpose is to bring over the data and reproduce them again to the original state as they were send. It only needs to read the attributes which belong to the class indicated in the enum. In this way, the optimal use of the protobuf principle is used (having everything in its own primitive datatype, and only read/write to the buffer what is necessary). But maybe there is a better way? I am not sure what you mean here. Maybe it gets clear when I read the code from Pieter. In my current point of view in protobuf, the service-part represents the functions (compare them with API-calls in REST), and the message parts are the data. This is how the service and message part look like. Some messages represent classes out of the application-sphere (as seen in the previous example), some represent data used as parameter-sets (I call them Request and Response messages). I copy some example-lines from the ucum-service-proto below. Best regards Bert

Dear Bert,

The plant-app was the subject of your initial post.

The math in support of deep learning are being studied. To make it
short, it remains somewhat mysterious since such classification
algorithms "should not work", but actually, they do :wink:

From an article I just read, such NP complete algorithms are similar to
finding a needle in a hay stack and shouldn't provide valuable
answers... unless the conditions (large enough needle, correctly ordered
stack) make the problem handy.

To sum it up, data quality (signal over noise ratio) is paramount. In
the plant-app you mentioned, adding a certain level of fuzziness
(improperly labeling images or adding images of objects that are not
plants) could probably make the whole app plainly crappy.

Just to say that building a deep learning system starts from making
certain that the data it will be fed with are of proper quality. This is
usually not the case in medicine, largely because IT is considered a
back office concept and there is seldom the kind of feedback loop that
could lead to having errors fixed.

My point is that you can perfectly (but with considerable efforts)
organize a trained network of practitioners to feed a "data lake" in
order to train a neural network... but will probably be disappointed if
you try to process existing information.

Best,

Philippe

Data of perfect quality means, in my opinion, data and their complete context.
A diagnosis by a nurse is not the same as one by a patiente, or strting intern, or one MD with 20m years experience.
Just mentioning one example.

Gerard Freriks
+31 620347088
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

Of course Philippe, but that would be vandalism. Most sensible people don't do that when they stand behind the goal, and a little bit of dirt, therefor it is Machine Learning, it can filter it out. It is part of the learning process.

If a culture of data quality is properly installed, then it is possible
to name improper use "vandalism".
In medicine, since such a culture has never existed, we could name it
"don't carisme", "no time for thisisme" or "was never thaughtisme".

My point, and what the paper I previously pointed out explains, is that
trying to get something out of machine learning in a domain of poor data
quality is a modern kind of magic thinking.
It just means that any such project should first organize for data
quality as a first step.

When considering it in hindsight, it makes sense since machine learning
involves statistics and data quality is paramount in this domain.

Hi Philippe,

I completely agree with your view. This is why data stewardship is needed before we can make real use of the data: https://en.wikipedia.org/wiki/Data_steward

As we use this approach in HiGHmed, I might be able to report in 2020 about lessons learned :slight_smile:

Best,

BTW, is someone aware of this project by Google?
https://ai.googleblog.com/2018/05/deep-learning-for-electronic-health.html

Initially, I thought that it would have been this one: https://arstechnica.com/tech-policy/2017/07/google-deepmind-nhs-deal-broke-uk-data-law/

But it seems to be entirely US based.

“Events of importance worth recording in the BOOK OF LIFE are frequently put on record in difference places since the person moves about
the world throughout his lifetime. This makes it difficult to assemble this BOOK into a single compact volume.

Yet, sometimes it is necessary to examine all of an individual’s important records simultaneously. No one would read a novel, the pages of which were not assembled.

Just so, it is necessary at times to link the various important records of a person’s life”.

Getting there J

All the best

Athanasios Anastasiou

Okay, not vandalism but don't-careism. The result is different. The first gives wrong data to frustrate the machine learning process, the second does not give data, voluntarily or not of good quality.

Good that there are procedures that create good data to learn from, these data are recorded anyway.
For example, in medical imaging diagnosis. Often this is very accurate and also cheap and fast. This not science fiction. This not new.
Early detection of diseases can reduce cost for healthcare enormously and will change the daily practice of healthcare.

Not only to find cancer, but even early detection of alzheimer is being worked on or already in use.
Currently, medical images account for 90% of all medical data, according to an IBM-report a year ago. This will be much more, and this will happen soon.

These machine learning processes do not suffer from don't-careism because the images are produced anyway, and have the manual diagnosis to learn from also.
Medical imaging is a good candidate for machine learning, not only because of the data which are very suitable, but also because of the importance, and (I repeat because of your argument) the processing for getting data does not require extra effort.

Upload images to a web-service, so hospitals do not have to buy expensive machines or employ specialists for this. Just upload the image and within 5 seconds, there is an analysis with high accuracy and cheap.
https://lunit.io/
https://www.vuno.co/

Also ultrasound supported by machine-learning/deep learning, “Users can reduce taking unnecessary biopsies and doctors-in-training will likely have more reliable support in accurately detecting malignant and suspicious lesions,” said Professor Han Boo Kyung, a radiologist at Samsung Medical Center.
https://www.samsunghealthcare.com/en/products/UltrasoundSystem/RS85/Radiology/benefit

I think it is time for optimism. But there is one thing that can come in the way. People might not accept being diagnosed by a machine, although this diagnose is more trustable. Also radiologist may fear for their employment, but instead of taking radiologists’ jobs, their job will change to prediction and guiding treatment. (so says Dr. Bradley Erickson from the Mayo Clinic in Rochester, Minnesota)

Bert

Opinions from yesterday may still be valid today.

Inventions and business models follow up quickly. But the law is behind, as law should be: conservative, keeping an eye on human rights.