Machine Learning , some thoughts

Clinical (archive)
61

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 without any direct purpose, for just in case.

For example, get the heartrate of a patient as standard, not because it is clinical necessary.

I will not be surprised that very soon it will be possible to measure heartrate on sight. Will that be allowed?

62

that is correct, because FHIR imposes its own model. This is the basic reason why one should not really use message standards to interoperate over systems whose data are already transparently structured. However, some organisations want to pay for these pointless conversions, so people do them. they only need to use the same data points of those archetypes, or else any specialised derivative. This isn’t hard to achieve; pretty clearly all systems using openEHR today use the same vital signs archetypes or derivatives to record vital signs. There is no point doing otherwise. I’ve missed some of the earlier discussion, but unless you are dealing with genuinely novel measurements or orders, you won’t have any ‘generated archetypes’ for most Observations or Instructions or Actions. You might have some for novel questionnaires or other kinds of assessment tools (new kind of score etc). But for the vast majority of cases, I would think the real need is for runtime of data points from archetypes to create on-the-fly templates, something we’ve known about for 15 years. Let’s assume some of these are created, for the reasons mentioned above; pretty soon you are going to want to curate them properly and add them to the library. Over time, the number of ‘generated archetypes’ will fall to nearly zero, and it will be the matching process that is the main challenge when encountering data not planned for. it is slowed down, that’s true, and it could be faster. But I don’t see how that reduces flexibility. 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. - thomas

63

I don’t know who May is but

May is many :wink:
Sorry, no time now, later I come back to your message

64

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

65

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 need resources.
I often saw very successful volunteer initiatives, doing innovation in medical care. They designed IT systems, using archetypes or other technology, and did a lot of good.

Many then wanted to scale these best practices to larger communities. That is when the law, quality, standards and harmonised archetypes come in.

Wiser men have been there before:
Shortliffe EH: The adolescence of AI in medicine: will the field come of age in the '90s? Artif Intell Med. 1993 Apr;5(2):93-106.
From that I often throw the following sentences around:
"If the situation is to change, there must be high-level institutional support for medical computing applications in clinical settings. I am not arguing for blind adoption of computational innovations, but I do believe that we must accept the impossibility of viewing the introduction of decision-support tools as a grass-roots activity that emerges from the research lab, appears as an isolated entity is a clinic or on a hospital ward, and then grows by some kind of mass effect to encompass an entire medical community. It is naiveté about this point which has characterized our efforts to introduce AIM systems in the past.

Instead, the greatest hope for effective systems will be realized when the infrastructure for introducing computational tools in medicine has been put in place by visionary leaders who understand the importance of networking, integration, shared access to patient data bases, and the use of standards for data exchange, communications, and knowledge sharing."

The archetype community (and many other standards groups) have them all, volunteers, early adopters, and large scale implementers. Sometimes we lose sight of each other, but they are all there.

Looking forward,
greetings from Vienna,

66

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?

or... someone who is working on an application or system to be used for sports can just create drafts of the archetypes and upload them to CKM now. The review might take a bit of time, but not that long, if the archetypes are not complicated.

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

no because this is reference knowledge, in the same sense as references ranges of path results, or formal drug descriptions. Archetypes are models of data about instances (individuals). You would probably want to create archetypes for recording meals / ingredients however, then an application can compute for you your calorific intake.

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.

it is immaterial, as far as I can see whether it is a CLUSTER (= a data group) or an ELEMENT (= a data point). If some device outputs treadmill speed, treadmill incline, heart rate, vO2, work rate etc as a group, then you will have an archetype for this. With a bit of study and review of typical devices, it will be fairly clear what kinds of things go together in what ways. For example, input variables such as treadmill speed and incline could be anything, depending on the machine in use, but the physiological variables are all going to be pretty standard ones.

If you have customers wanting this stuff, I suggest making some initial proposals for CKM.

- thomas

67

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?

or... someone who is working on an application or system to be used for sports can just create drafts of the archetypes and upload them to CKM now. The review might take a bit of time, but not that long, if the archetypes are not complicated.

That might be, but when one wants to create a product, not long, still is long, and every change in thinking again requires administrative procedures. And those procedures are not the problem, the problem is that review can lead to changes. The control get out of hands.

But there is also a good site on CKM. The archetypes are written in public, they don't are in secret hands of big vendors. It keeps the market and knowledge pool open.

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

no because this is reference knowledge, in the same sense as references ranges of path results, or formal drug descriptions. Archetypes are models of data about instances (individuals). You would probably want to create archetypes for recording meals / ingredients however, then an application can compute for you your calorific intake.

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.

it is immaterial, as far as I can see whether it is a CLUSTER (= a data group) or an ELEMENT (= a data point). If some device outputs treadmill speed, treadmill incline, heart rate, vO2, work rate etc as a group, then you will have an archetype for this. With a bit of study and review of typical devices, it will be fairly clear what kinds of things go together in what ways. For example, input variables such as treadmill speed and incline could be anything, depending on the machine in use, but the physiological variables are all going to be pretty standard ones.

If you have customers wanting this stuff, I suggest making some initial proposals for CKM.

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.
Maybe more neutral, an archetype for food intake without mentioning the term Obesity.
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.

How good would that be. In sports and leisure software they have the same problems as in medical health software. When they want a database change, they are afraid that forgotten corners/things in the software will break.
This is for me a very strong point of OpenEhr, you can always introduce another (better) archetype, without breaking the old one, and without breaking the data of the old one.
And it is very easy to do.

How easy is it to create a sports-app when you have an OpenEhr kernel running in the background? Just write a few archetypes, create some API's for those archetypes, write an app-GUI with flutter ( https://flutter.io/ )
And you are in business. And of course, having monitoring apps for the desktop as web-clients for team-leaders, and so on.

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?

Bert

68

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 the way, how do you create FHIR messages from OpenEhr-compositions? Or how do you create Openehr-compositions from FHIR messages?
You have to create a template manually, fitting that item to that datapoint, isn't it?

that is correct, because FHIR imposes its own model. This is the basic reason why one should not really use message standards to interoperate over systems whose data are already transparently structured. However, some organisations want to pay for these pointless conversions, so people do them.

Stability and Mapping:
I think FHIR is good, because it is a stable model, and mapping to/from FHIR can be used for long time, and FHIR is also much used, so mappings can be used in more occasions. There are also disadvantages, like the HTTP-REST protocol which it incorporated. Google is now planning a GRPC protocol for FHIR, and that is promising, because every datatype can have its own GRPC field predefined, and the performance can really improve very much, maybe even 100 times as fast. As a rule of thumb one could say: Never use REST/JSON/HTTP1.1 for stable models, it is throwing away a lot of performance.

Transparancy:
Data must not only be transparent in a way that people can understand them, but they must also be transparent in a way that the software-internals of the sender and receiver can handle them. For that purpose they need to be mapped from and to these internal processes. If a GP receives a FHIR message and maps it to his own EHR-tables, then the data from that message become available in the normal working screens of the doctor. That is transparency that is needed.

Even within two parties using OpenEhr. You are only automagically interoperable when two parties use exact the same archetypes, else you need to puzzle the dataitems.

they only need to use the same data points of those archetypes, or else any specialised derivative. This isn't hard to achieve; pretty clearly all systems using openEHR today use the same vital signs archetypes or derivatives to record vital signs. There is no point doing otherwise.

I don't know if that is true, but if you say so, I accept that statement, also because it is restricted to vital signs.
https://en.wikipedia.org/wiki/Vital_signs

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've missed some of the earlier discussion, but unless you are dealing with genuinely novel measurements or orders, you won't have any 'generated archetypes' for most Observations or Instructions or Actions. You might have some for novel questionnaires or other kinds of assessment tools (new kind of score etc). But for the vast majority of cases, I would think the real need is for runtime /matching/ of data points from /existing/ archetypes to create on-the-fly templates, something we've known about for 15 years.

I agree, there are not an endless number of data-points-types. They could also be predefined. We would need sport-coaches, athletes and so on to help us with that.

I called them before, micro-archetypes, containing only one datapoint, or a few closely related datapoints.

Let's assume some of these are created, for the reasons mentioned above; pretty soon you are going to want to curate them properly and add them to the library. Over time, the number of 'generated archetypes' will fall to nearly zero, and it will be the matching process that is the main challenge when encountering data not planned for.

With machine learning algorithms, it must not be hard to interpret them.

Don't understand me wrong, I like OpenEhr, because of the archetyped system, and the flexibility it offers. It is not by accident that I discuss it here and not in a HL7 group, although that would bring more money.

But if flexibility is slowed down by years of review, discussing and consensus over the whole world for a set of archetypes, then there is not much flexibility left.

it is slowed down, that's true, and it could be faster. But I don't see how that reduces flexibility.

The inflexibility is in giving the proceedings out of hands, losing control, having to deal with changes which are not asked for or wanted. The data-points would need to be as simple as possible, mostly in ELEMENT-structure instead of CLUSTER, or only very simple CLUSTERS when 1 data-point is not sufficient. No deep structures, I would advise.

This can work very good for the archetypes which are in CKM, but all those new devices, all those new datatypes, all this new protocols, which cannot wait for these review-procedures, because the market will be jumped far ahead by then.

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.

Yes, I agree

Bert

69

How about creating a protocol-buffer generation tool for archetypes, or as a matter of fact, for the reference model would be sufficient.
Good idea, to remember.

Or has someone already done it and did I miss it?

Bert

70

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://11073.org/, especially
https://standards.ieee.org/develop/wg/PHD.html
11073:10101 is the nomenclature standard.

They have “Device Specialisations” for blood pressure, blood sugar, medication dispensers, …
This is heavily used by many, including Bluetooth, NFC, …
This is also used in FHIR:

http://build.fhir.org/devicemetric.html
This is Maturity Level 1, so not fully stable (“Trial Use Use Context: Not Intended for Production use”)
Work seems to be ongoing, I see very recent changes there.

Hope this helps,
greetings,

71

Hmm... imagining...
Steps walked | phone in trouser pocket
                        > phone in handbag | strap length

:slight_smile:
Colin

72

Stefan I fully support your statement that:

Instead, the greatest hope for effective systems will be realized when the infrastructure for introducing computational tools in medicine has been put in place by visionary leaders who understand the importance of networking, integration, shared access to patient data bases, and the use of standards for data exchange, communications, and knowledge sharing."

May I suggest that this group makes contact with IMIA’s newly established International Academy of Health Sciences Informatics (I’m one of the 110 or so founding Fellows) who globally represent HI expertise. We’re just getting our by-laws and purpose sorted. I’ve drafted a strategic plan for this group to begin to drive the necessary global transformation to get an appropriate infrastructure and infostructure needed to support the digital health transformation. It’s with IAHSI’ president at the moment and is expected to be distributed to the Fellows once he’s been able to make his contribution. As you’ve indicated this needs to be achieved via collaboration with many stakeholders of experts, movers and shakers including this group. Christoph U. Lehmann, MD, FAAP, FACMI, FIAHSI, Professor of Biomedical Informatics and Pediatrics, Vanderbilt University Medical Center is the current chair. Messages of support for this approach may be useful. His email address is christoph.u.lehmann@Vanderbilt.Edu.

Evelyn

73

Gerard Freriks
+31 620347088
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

Instead, the greatest hope for effective systems will be realized when the infrastructure for introducing computational tools in medicine has been put in place by visionary leaders who understand the importance of networking, integration, shared access to patient data bases, and the use of standards for data exchange, communications, and knowledge sharing.”

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.

74

Dear Evelyn,

Is there more to read about the scope/purpose of the group?

Gerard

Gerard Freriks
+31 620347088
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

75

Gerard,

You’ll find information about IMIA at http://imia-medinfo.org/wp/welcome-to-imia-2/ and about the new Academy’s establishment at http://imia-medinfo.org/wp/international-medical-informatics-association-establishes-international-academy-health-information-sciences-2/ The paper 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

76

Gerard I suggest you prepare a concept proposal for your standards organisation to submit to CEN or ISO. My co-director of GeHCo chairs the ISO WG on all data matters, have you had a look at their current worklist? ICO TC2215 or CEN TC251? Anyone who identifies a standards gap is able to take action through the relevant organisations.

Evelyn

77

Hi Bert,

I’d really like to be careful about the terms we use here.

“But if flexibility is slowed down by years of review, discussing and consensus over the whole world for a set of archetypes, then there is not much flexibility left.”

At present, the slow part is lack of editorial resources to facilitate the reviews and achieving consensus. Until we have adequate funded resources applied to the CKM process and then still proved that it is too slow, please try not to disseminate this kind of message.

Some will use loose phrases as their ‘truth’ and perpetuate further misinformation about openEHR.

Regards

Heather

78

I totally endorse what Thomas is saying here.

Let's be realistic here! CKM is not some automagic process. There is no archetype fairy.

We need candidate archetypes proposed by openEHR members and we need the process to be modestly funded.

What we have achieved with largely volunteer labour so far is absolutely extraordinary - let's not lose sight of that and we should be eternally grateful to those who have contributed long unpaid hours to create what we have today.

Lots of crappy archetypes won't help interoperability. Only a few perfect ones won't either.

We're working hard to get a balance between the two with a minimum of resourcing.

Until there is dedicated, ongoing funding for managing CKM, and potentially additional funding for modellers to create new archetypes at the request of the community, the status quo will remain indefinitely.

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.

Regards

Heather

79

Thanks Heather for your reply. Unfortunately I am whole day not able to reply. This evening or tomorrow.

Best regards
Bert

80

Dear Evelyn,

The ideas I have are collected in a rough document called SIAMM (Semantic Interpretability Artefact Modelling Method)
This is known by several persons active in ISO/CEN.

At present I’m no longer actively involved in standardisation work.

Gerard Freriks
+31 620347088
  gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands