On 29-06-18 10:26, Thomas Beale wrote:
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
On 29-06-18 07:38, Heather Leslie wrote:
BTW Bert - here's a project that has some archetypes that might be useful for
your diet app scenario:https://ckm.openehr.org/ckm/#showProject_1013.30.47.
They were volunteered by some of our Portuguese colleagues and refined by CKM
Editors.
Thanks, I
On 29-06-18 07:13, Heather Leslie wrote:
please try not to disseminate this kind of message.
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 cop
On 29-06-18 01:11, GF wrote:
Any one automobile or airplane or house is built using many, many
standards.
You are right Gerard, that was I was in my joke explicitly talking about
interoperability standards.
Bert
___
openEHR-clinical mailing list
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
AM
*To:* For openEHR clinical discussions
; Bert Verhees
*Subject:* Re: Machine Learning , some thoughts
One other example of "a big bunch of" things is https://www.snomed.org/.
This does not come for free. Snomed works along a well defined set of
processes, performed by experts with
On Thu, Jun 28, 2018 at 08:34:20AM +0200, GF wrote:
> The GDPR allows the collection of health data.
> The GDPR restricts itself to person identifiable data and it secondary
> use/abuse of privacy rights.
>
> Since health and care are about all of society, all of life, all must be able
> to be
On 28/06/2018 15:49, Bert Verhees wrote:
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
M
> To: Bert Verhees
> Cc: For openEHR clinical discussions
> Subject: Re: Machine Learning , some thoughts
>
> Bert,
>
> Any one automobile or airplane or house is built using many, many standards.
>
> The models/standards I mentioned deal with a particular aspect o
ds
>
> Heather
>
> -Original Message-
> From: openEHR-clinical On
> Behalf Of Thomas Beale
> Sent: Friday, 29 June 2018 12:13 AM
> To: openehr-clinical@lists.openehr.org
> Subject: Re: Machine Learning , some thoughts
>
>
>
> On 27/06/2018 16:57, Bert
m: openEHR-clinical On Behalf
Of Thomas Beale
Sent: Friday, 29 June 2018 12:13 AM
To: openehr-clinical@lists.openehr.org
Subject: Re: Machine Learning , some thoughts
On 27/06/2018 16:57, Bert Verhees wrote:
>
> I have sport-app which tells me the power I produce, and it tells me
>
about openEHR.
Regards
Heather
From: openEHR-clinical On Behalf
Of Bert Verhees
Sent: Wednesday, 27 June 2018 10:00 PM
To: openehr-clinical@lists.openehr.org
Subject: Re: Machine Learning , some thoughts
Dear Seref, I do not agree with this without having explored all the
possibilities. I
take action through
the relevant organisations.
Evelyn
From: openEHR-clinical On Behalf
Of GF
Sent: Friday, 29 June 2018 9:12 AM
To: Bert Verhees
Cc: For openEHR clinical discussions
Subject: Re: Machine Learning , some thoughts
Bert,
Any one automobile or airplane or house is
Bert,
Any one automobile or airplane or house is built using many, many standards.
The models/standards I mentioned deal with a particular aspect of data to be
stored, retrieved, processed and exchanged.
Data that is generated in and by a patient in a context,
observed by a person in a context
D
available at
https://www.thieme-connect.de/products/ejournals/pdf/10.15265/IY-2016-015.pdf
provides an overview of its mission and membership.
Evelyn
From: openEHR-clinical On Behalf
Of GF
Sent: Friday, 29 June 2018 7:50 AM
To: For openEHR clinical discussions
Subject: Re: Machine Learning
GF said: We need standards on how to describe the health data and their
epistemology/context, modeling patterns and rules on how to use coding
systems and deal with ‘negation’, just to mention a few other things needed
to define data inside EHR systems in such a way that data can exchanged.
Dear G
Dear Evelyn,
Is there more to read about the scope/purpose of the group?
Gerard
Gerard Freriks
+31 620347088
gf...@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
> On 28 Jun 2018, at 21:18, Dr Evelyn Hovenga wrote:
>
> Stefan I fully support your statement that:
> Instead, the g
Gerard Freriks
+31 620347088
gf...@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
> On 28 Jun 2018, at 16:03, Stefan Sauermann
> wrote:
>
> Instead, the greatest hope for effective systems will be realized when the
> infrastructure for introducing computational tools in medicine
Evelyn
From: openEHR-clinical On Behalf
Of Stefan Sauermann
Sent: Friday, 29 June 2018 12:04 AM
To: For openEHR clinical discussions ; Bert
Verhees
Subject: Re: Machine Learning , some thoughts
One other example of "a big bunch of" things is https://www.snomed.org/.
This d
Hmm... imagining...
Steps walked | phone in trouser pocket
| phone in handbag | strap length
:-)
Colin
> On 27 Jun 2018, at 6:13 pm, Anastasiou A. wrote:
>
> Imagine Steps_Walked defined separately for FitBit, FitBlit, FitZit, FitBic,
> etc, wh
> I agree there is a need to be able to create archetypes much more
quickly based on device specifications. We need to work on that.
If you are looking for device specifications, I guess you are aware of
the medical device information model and the nomenclature of ISO EN IEEE
11073?
http://11
On 28-06-18 10:33, Thomas Beale wrote:
On 27/06/2018 13:00, Bert Verhees wrote:
Dear Seref, I do not agree with this without having explored all the
possibilities. I think it is important not to jump to conclusions and
keep the discussion open.
I have some ideas how to keep it interoperable. I
On 28-06-18 16:12, Thomas Beale wrote:
On 27/06/2018 16:57, Bert Verhees wrote:
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 healt
On 27/06/2018 16:57, Bert Verhees wrote:
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
One other example of "a big bunch of" things is https://www.snomed.org/.
This does not come for free. Snomed works along a well defined set of
processes, performed by experts with well defined profiles. Much of this
is paid work.
There are things volunteers can do. There are other things that
Correct! That is what I meant.
If clinicians decide that something must be documented, they do so in
fulfilment of the "doctors" law (at least in Austria). The GDPR is
therefore satisfied (as far as I understand).
Stefan
Am 27.06.2018 um 12:48 schrieb Diego Boscá:
I assume that when Stefan sa
> I don't know who May is but
May is many ;-)
Sorry, no time now, later I come back to your message
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
On 27/06/2018 13:00, Bert Verhees wrote:
Dear Seref, I do not agree with this without having explored all the
possibilities. I think it is important not to jump to conclusions and
keep the discussion open.
I have some ideas how to keep it interoperable. I like to discuss that
with an open mind
The discussion between Stefan and Karsten is about data related to an
identifiable person, so gdpr is applicable.
I hope I resume it right:
Karsten says that it is illegal to collect data about a person if the
purpose id not known. This is because Stefan says that it is allright to
collect data wi
> 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 archety
When it necessary and defendable data can be collected and used.
Explicitly kinds of data and organisations are mentioned that can store more
data than most others.
Healthcare and political parties are examples special catagories.
Clause 53 deals with health and care
Gerard
https://www.gdpr.ass
Dear Karsten,
The GDPR allows the collection of health data.
The GDPR restricts itself to person identifiable data and it secondary
use/abuse of privacy rights.
Since health and care are about all of society, all of life, all must be able
to be documented.
No restrictions.
So I disagree with:
On 27-06-18 16:43, Philippe Ameline wrote:
1) you can find a bunch of practitioners that agree on working extra
hours to comment a big bunch of images, or
Did I tell you about the plant-app? I believe I did. 700.000 pictures
are reviewed, often by volunteers.
The app recognizes 16000 plants.
On 27-06-18 18:55, Anastasiou A. wrote:
openEHR goes back to 1994 and its ideas are starting to become more widely
known in the last few years.
It is true, especially thanks to the good work of Marand but also others.
As long as it is not part of medical school training, I do not think the
>>> 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 ac
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 pa
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 compan
Bert, I don't think that we really disagree there. As you nail it the
dataset comes from people agreeing on building it the proper way. And
agreeing with Karsten (who is plainly right), doesn't make that process
simple.
Means that wether:
1) you can find a bunch of practitioners that agree on work
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
Dear Bert,
Always happy to keep a discussion open and I appreciate your input. I'm
sure achieving the kind of agility without introducing the problems I
mentioned would be of interest to many people, so by all means feel free to
make suggestions.
The market is a commercial dynamic. It is true tha
From: openEHR-clinical On Behalf
Of Bert Verhees
Sent: 27 June 2018 13:52
To: openehr-clinical@lists.openehr.org
Subject: Re: Machine Learning , some thoughts
Thanks for your reply, Anastasiou,
I disagree with some opinions you express as fact.
On 27-06-18 14:21, Anastasiou A. wrote:
I think t
Thanks for your reply, Anastasiou,
I disagree with some opinions you express as fact.
On 27-06-18 14:21, Anastasiou A. wrote:
I think that this is the bit that causes the “friction” J
“Archetype” is not a “value”. It is a type.
It is an archetype, it is written in ADL following the ADL-synta
>The same things you have to do when you need to handle a generated archetype.
>But it will not be that hard. Don't expect much complexity from these
>generated archetypes.
>I called them before, micro-archetypes, containing only one datapoint, or a
>few closely related datapoints.
>With machine
Dear Seref, I do not agree with this without having explored all the
possibilities. I think it is important not to jump to conclusions and
keep the discussion open.
I have some ideas how to keep it interoperable. I like to discuss that
with an open mindset.
Talking about interoperability.
By
On Wed, Jun 27, 2018 at 12:48:11PM +0200, Diego Boscá wrote:
> I assume that when Stefan says "all", he is referring to these extra data
> points, which can be identified and accepted (or not), even on a one-by-one
> basis if needed
That would, formally, fulfil the requirements :-)
Which, of cou
I assume that when Stefan says "all", he is referring to these extra data
points, which can be identified and accepted (or not), even on a one-by-one
basis if needed
2018-06-27 12:36 GMT+02:00 Karsten Hilbert :
> On Wed, Jun 27, 2018 at 12:28:30PM +0200, Diego Boscá wrote:
>
> > Technically it's
On Wed, Jun 27, 2018 at 12:28:30PM +0200, Diego Boscá wrote:
> Technically it's ok if patients/citizens are aware of it (and willing to
> share it)
No, because the basic rule is that
everything is forbidden
except where
explicitely allowed
PLUS
Technically it's ok if patients/citizens are aware of it (and willing to
share it)
2018-06-27 12:18 GMT+02:00 Karsten Hilbert :
> On Wed, Jun 27, 2018 at 11:57:05AM +0200, Stefan Sauermann wrote:
>
> > I agree completely that it is not possible to know which information is
> > relevant, and that
I don't think this completely breaks openEHR. Even Thomas talks about how
many "data points" there are in the CKM right now. Probably we could
(re)use each one of these data points on their own, keeping their meaning.&
creating/reviewing them by using a modeling methodology.
2018-06-27 11:50 GMT+0
On Wed, Jun 27, 2018 at 11:57:05AM +0200, Stefan Sauermann wrote:
> I agree completely that it is not possible to know which information is
> relevant, and that all information is better recorded just in case
Not that I like the fact but that is currently illegal under EU GDPR.
Karsten
--
GPG
Dear all,
please be assured that myself and many others here and elsewhere support
the need to record information, for the sake of treating patients, no
matter if there is an archetype or not.
Probably this discussion circles around the fact that "informatics"
types of persons always are look
Hi Bert,
Let me try to keep it brief: you seem to suggest breaking the openEHR
methodology. If you allow downstream actors (clinical systems, guided by
their users) create archetypes without going through the methodology, i.e.
creating, discussing, reviewing archetypes, you'll end up with computab
One short addition, why this discussion, the original point:
What about machine learning?
Machine learning becomes possible when many daily health related data are
available. A machine can, f.e. detect deviations.
Why generated archetypes?
Every day there are new devices, new ideas about health,
Thanks for supporting reactions.
It is really typical in western medical science that it is very problem
oriented. All EHRs, even unconventional one, even the new thinking, it is
very problem oriented.
All data are gathered around a problem and in relevance of a problem. All
datastructures are po
12:17 AM
> To: Stefan Sauermann ; For openEHR clinical
> discussions
> Subject: Re: Machine Learning , some thoughts
>
> On 26-06-18 14:35, Stefan Sauermann wrote:
>> Dear Bert, all!
>> Sorry if this consumes excess bandwith, feel free to delete.
>>
>> The case you de
> But the person should be seen as more then a medical complaint, but as a
> complex of conditions and lifestyle.
> We need generic archetypes which can store machine generated datasets to
> store information about the whole person, instead of only the medical
> condition which is subject of con
Dear Bert,
You mention:
"There will be some semantics.
A clinician can indicate that data are from the user story, or from the
observation, so, that is already some information."
If there is some semantics: The archetype to store this information will then
need at least some structure, and not
.
>
> Evelyn
>
> -Original Message-
> From: openEHR-clinical On
> Behalf Of Bert Verhees
> Sent: Wednesday, 27 June 2018 12:17 AM
> To: Stefan Sauermann ; For openEHR clinical
> discussions
> Subject: Re: Machine Learning , some thoughts
>
> On 26-
R clinical
discussions
Subject: Re: Machine Learning , some thoughts
On 26-06-18 14:35, Stefan Sauermann wrote:
> Dear Bert, all!
> Sorry if this consumes excess bandwith, feel free to delete.
>
> The case you describe clearly provides a sound reason why "generic
> archetyp
On 26-06-18 14:35, Stefan Sauermann wrote:
Dear Bert, all!
Sorry if this consumes excess bandwith, feel free to delete.
The case you describe clearly provides a sound reason why "generic
archetypes will remain necessary".
I agree completely. This use case must always be satisfied.
It does not
Dear Bert, all!
Sorry if this consumes excess bandwith, feel free to delete.
The case you describe clearly provides a sound reason why "generic
archetypes will remain necessary".
I agree completely. This use case must always be satisfied.
It does not include automated processing at the receivin
Many Machine learning applications are analogous to "experience'
ie pattern recognition
Typical ML algorithms require training data where the results are
known . They seem to have most application in areas where there are
massive amounts of data which a human cannot comprehend -
> Therefore I conclude for myself that I will not trust (and recommend to
> trust) automatically found archetypes, because you can not derive
> reliable conclusions from them at a defined level of reliability.
Stefan, I give a short reply, I have already given much input in this
discussion and wan
could be semi-automated: clinical review will
still be necessary.
--
Colin
From: openEHR-clinical On Behalf
Of GF
Sent: Tuesday, 26 June 2018 1:48 AM
To: For openEHR clinical discussions
Subject: Re: Machine Learning , some thoughts
One needs patters that document the documentation process in
One needs patters that document the documentation process in general for
Medical Statements, Evaluations, Orders, Actions
Patterns to Collect Complaints
Patterns to Collect Observations by tractus
Patterns to collect complaint specific data
Patterns to collect Diagnosis specific data
Patterns to
Bert Verhees
Sent: 25 June 2018 14:35
To: Anastasiou A. ; For openEHR clinical discussions
Subject: Re: Machine Learning , some thoughts
On 25-06-18 14:56, Anastasiou A. wrote:
Once you have this minimal dataset discovered, THEN you could compose the
template or automatically create the arche
Athanasios Anastasiou
>
>
>
>
>
>
> -Original Message-
> From: Bert Verhees
> Sent: 25 June 2018 12:31
> To: Anastasiou A. ; For openEHR clinical
> discussions
> Subject: Re: Machine Learning , some thoughts
>
> On 25-06-18 12:44, Anastasiou
that would
enable all this. Maybe things are progressing faster where you are (?)
All the best
Athanasios Anastasiou
-Original Message-
From: Bert Verhees
Sent: 25 June 2018 14:35
To: Anastasiou A. ; For openEHR clinical
discussions
Subject: Re: Machine Learning , some thoughts
O
Excellent observations!!!
Carol
El 25-06-2018, a las 07:30, Bert Verhees escribió:
On 25-06-18 12:44, Anastasiou A. wrote:
The time scales for doing this would be enormous. We can probably work out a
lower limit by looking at the lifecycle of archetypes
in the current CKM.
Thanks, for your an
On 25-06-18 14:56, Anastasiou A. wrote:
Once you have this minimal dataset discovered, THEN you could compose the
template or automatically create the archetypes.
And yes, this CAN be done today, definitely.
There is an understandable mindset which aspires to work with a
standard-set of arch
On 25-06-18 14:47, Philippe Ameline wrote:
Successfully using machine learning demands a prior culture of data
quality and information awareness.
Dear Philippe, I read your document later.
I have to disagree with the word "prior".
It makes it sound like, is has gone wrong long time ago, and t
On Mon, Jun 25, 2018 at 02:47:07PM +0200, Philippe Ameline wrote:
> A friend of mine recently published a paper, after studying a group of
> GPs located in the South of France. He found out that the diagnosis is
> not reported in observations in more than one encounter out of two.
That's because
N you could compose the
template or automatically create the archetypes.
And yes, this CAN be done today, definitely.
All the best
Athanasios Anastasiou
-Original Message-
From: Bert Verhees
Sent: 25 June 2018 12:31
To: Anastasiou A. ; For openEHR clinical
discussions
Subject:
Have anyone tried AQL adapter to pandas(python data analysis package
for machine learning and statistics)?
Shinji
2018-06-24 1:11 GMT+09:00 Bert Verhees :
> Today my wife showed me Plantnet.
>
> https://plantnet.org/en/
>
> It recognizes over 6000 plants from showing a flower or a leaf to your
>
You may be interested in this paper (from my Tech Trends):
http://philippe.ameline.free.fr/techtreads/additionalMaterial/Boyd_MagicOfBigDataAndArtificialIntelligence.pdf
A friend of mine recently published a paper, after studying a group of
GPs located in the South of France. He found out that the
On 25-06-18 13:52, Karsten Hilbert wrote:
This approach much reminds me of what Philippe (sp?)
described of his fils guides. Instances of "micro achetypes"
would be generated on the fly while typing/speaking.
The doctor mumbles to his screen while the patient tells it story, or
the doctor does
On Mon, Jun 25, 2018 at 01:30:30PM +0200, Bert Verhees wrote:
> What about micro-archetypes which describe only one datapoint? And the GP
> should be able to invoke them by voice. He says "red eyes" and magic
> happens, there is a datapoint on the screen which offers a possibility to
> click on a
On 25-06-18 12:44, Anastasiou A. wrote:
The time scales for doing this would be enormous. We can probably work out a
lower limit by looking at the lifecycle of archetypes
in the current CKM.
Thanks, for your answer, I agree with you and others, and already wrote
that, that an EHR will not be
Largely I agree with Bert.
Medicine is an art for 80% and science for 20%
What medical data is recorded in most cases by GP’s is so scanty that AI is not
possible.
Collecting data over long periods of time might help.
Most IT-systems can not store all the epistemology that is needed for AI, at
On 25-06-18 12:31, Thomas Beale wrote:
On 25/06/2018 11:21, Stefan Sauermann wrote:
82% of correct recognition rate is a desaster in healthcare.
92% would be a disaster in healthcare ...
74% is even worse.
My evidence based feeling is that we still will need to sort it out
manually for
On Mon, Jun 25, 2018 at 12:52:07PM +0200, Bert Verhees wrote:
> Allthough, there are some patient-conditions which are very typical for a
> disease, mostly this is not the case.
> For example, many infection-diseases have fever as a symptom, and one person
> gets pain in his back, and the other ha
On 25-06-18 12:21, Stefan Sauermann wrote:
Hope this helps,
Not really Stefan, but thanks for trying.
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
On 25-06-18 12:40, GF wrote:
Providing health and care is part science and for a large part an art.
Meaning that humans are needed.
Artificial Intelligence is a nice scientific hyped topic and nothing more.
That is not to say that AI might play a role and can be of use.
It needs to be properly
On Mon, Jun 25, 2018 at 11:31:27AM +0100, Thomas Beale wrote:
> > 82% of correct recognition rate is a desaster in healthcare.
>
> 92% would be a disaster in healthcare ...
It much depends. In typical care "92%" (of what ?) can be an
extremely brilliant result far beyond anything available
today
Dear Bert and all
> I wonder, Is OpenEhr usable for recognizing pattern in diseases over
> Machine Learning, isn't behind every diagnosis a small cloud of
> archetypes which forms a pattern? The features of recognizing/learning
> should not be found in archetypes ID's, although, that can help a
Providing health and care is part science and for a large part an art.
Meaning that humans are needed.
Artificial Intelligence is a nice scientific hyped topic and nothing more.
That is not to say that AI might play a role and can be of use.
It needs to be properly designed, engineered and not ha
On Mon, Jun 25, 2018 at 12:21:26PM +0200, Stefan Sauermann wrote:
> My evidence based feeling is that we still will need to sort it out manually
> for some years to come.
Not in visual classification of dermatological health concerns.
Or areas of radiological diagnostics.
Karsten Hilbert
--
GP
On 25/06/2018 11:21, Stefan Sauermann wrote:
82% of correct recognition rate is a desaster in healthcare.
92% would be a disaster in healthcare ...
74% is even worse.
My evidence based feeling is that we still will need to sort it out
manually for some years to come.
I am slightly more
82% of correct recognition rate is a desaster in healthcare.
74% is even worse.
My evidence based feeling is that we still will need to sort it out
manually for some years to come.
Hope this helps,
Stefan
Stefan Sauermann
Program Director
Biomedical Engineering Sciences (Master) ->
Medical E
89 matches
Mail list logo
