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.
Technically it’s ok if patients/citizens are aware of it (and willing to share it)
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
it can only be allowed if *necessary* for
a given purpose,
which, by definition, it is not:
[...] it is not possible to know which information is
relevant, and that all information is better recorded just in case
That is, at any rate, the current interpretation I am aware
of here in Germany.
Of course, this whole situation attests to the cluelessness
of people designing GDPR.
"Just in case" is simply not possible.
But better to let this rest.
Karsten Hilbert
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 course, isn't practical: as I said, cluelessness in
the design of GDPR.
Karsten
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?
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.
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 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.
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.
Best regards
Bert
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 learning algorithms, it must not be hard to interpret them.
I think that this is the bit that causes the “friction” J
“Archetype” is not a “value”. It is a type.
What you are describing refers to re-packaging or translations between values. Not types.
A type is stricter.
There is a lot of “fuss” around whether something has to be a cluster or a list. For very good reasons.
A condition where you have a Set that behaves “kind of like” a Set but if you need it, it could also be a List ALONGSIDE an existing List type
doesn’t get you anywhere.
So, Archetypes are supposed to be elementary types. Not necessarily in the computer science meaning of the term. But more in the logic meaning of the term.
You use types that can compose to more complex types and they might even have operations associated with them to make inferences about what they describe.
This is why, the Archetype is like saying the set of integers (Z) rather than uint8 which is a subset of Z.
If you have a unit8 level of Archetype, you subclass the corresponding archetype at the Integer level.
Archetypes help you think conceptually about the domain. They are not supposed to be fancy containers (That’s what Templates are for J ).
Conversions between Whatever ↔ openEHR are supposed to happen at the conceptual level.
Automatically constructing archetypes would look into the minimal subset of (currently used) clinical encodings
that tend to be used together in the context of a disease. Having this subset you would then use their mappings to SNOMED
concepts and from SNOMED you would start constructing the Archetypes respecting the relationships between the represented concepts.
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.
Indeed, but look at it as if it were a type Universe. Or a programming language that gives you access to a type system.
When you express any kind of data transformation in this programming language, you would have to express it in the types it supports. If the types imply values that are all over the place you cannot even do data validation.
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.
The pressure is real, I agree but I feel more comfortable having a CKM as our modelling CANVAS which helps you identify the correct position for inserting Archetypes that result from a new device.
All the best
Athanasios Anastasiou
That is another discussion, but I see in CKM archetypes which are container archetypes. I don’t see any problem in that, container archetypes can cause modularity, and flexibility in datastorage. 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.
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.
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 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.
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 (?).
All the best
Athanasios Anastasiou
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 that it keeps jumping around, but not necessarily far ahead, at least in terms of providing the solutions to the health IT problems we’ve been trying to solve.
I for one will be keeping an eye on your suggestions re how to do what you’re suggesting
Kind regards
Seref
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. 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? 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. 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
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 working extra
hours to comment a big bunch of images, or
2) you expect this process to be(come) part of the usual information
recording... and you must instill a culture of data quality and
information awareness before the dataset can exist.
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 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.
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.
Again, in CS the definition of syntax and semantics are two different things. Your notation might be A+B to denote addition but the semantic of the + operator
over A,B Sets could lead to Union or simply remain undefined (i.e. "In our type system, you don't apply union over sets using +").
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.
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.
Imagine Steps_Walked defined separately for FitBit, FitBlit, FitZit, FitBic, etc, when they can simply all use the same archetype.
I don't 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.
I agree. I see a great opportunity. Let's get modelling
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.
Indeed. Each specialisation level of the tree of Archetypes would be relevant only to a specific group of people.
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 suppose that you refer to "Extension" whose purpose is "Additional information required to capture local context or to align with other reference models / formalisms".
So, you cannot really constraint it any better than saying "It's a CLUSTER".
In addition, the examples you are mentioning are in the "Protocol" section. Not the "Data" section.
So, an accurate example is Entry/Observation/Demonstration whose Data specifies two Slots which are very well constrained.
Okay, must be devils luck, let's click another.
openEHR-EHR-OBSERVATION.fluid_input.v1
. . .
Some want a device-archetype, and some allow everything (from type CLUSTER), for example at0039 (Fluid Details)
Same case as above.
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.
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.
This would make me feel more comfortable than automatic adaptations that exploit just the Pathable capability.
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.
The Archetypes must be put on a coherent model. I would not see anyone working towards that as staying in the sidelines (?).
I don't mind continuing the discussion on a concrete example of how this could work. Maybe that would help formulate the idea better.
All the best
Athanasios Anastasiou
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 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.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.
Again, in CS the definition of syntax and semantics are two different things. Your notation might be A+B to denote addition but the semantic of the + operator
over A,B Sets could lead to Union or simply remain undefined (i.e. "In our type system, you don't apply union over sets using +").
I know the difference between semantics and syntax.
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?
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?
And this morning in the gym, he spent so many calories on the cross-trainer.
These are also data which can change. Maybe the tables not in the archetypes, but the items with calories on the moment of intake of the food in the archetypes, so that is recorded that a sandwich with cheese was lighter last year then this year.
(sorry, just having fun)
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.
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. 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.
When do you expect this change to be done, so we can support Fitbit in a proper way?
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 CLUSTERI suppose that you refer to "Extension" whose purpose is "Additional information required to capture local context or to align with other reference models / formalisms".
So, you cannot really constraint it any better than saying "It's a CLUSTER".In addition, the examples you are mentioning are in the "Protocol" section. Not the "Data" section.
The Protocol section is not very important?
So, an accurate example is Entry/Observation/Demonstration whose Data specifies two Slots which are very well constrained.
Okay, must be devils luck, let's click another.
openEHR-EHR-OBSERVATION.fluid_input.v1
. . .
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 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
The Archetypes must be put on a coherent model. I would not see anyone working towards that as staying in the sidelines (?).
I don't mind continuing the discussion on a concrete example of how this could work. Maybe that would help formulate the idea better.
I gave you a few examples.
Bert
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
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 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.
It is a measurement for athletes. Sport-apps can give this value. But it is only an example, there are many.
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.
I don't see it happening, this is also because the community on OpenEhr is health-problem-centric thinking, and what we also need is health-lifestyle/sport/consumer thinking.
The culture change from problem-centric-care to health-centric-care is not yet happening on CKM.
That is with communities, you get what you get. And even if they were, would they be able to keep up with the industry?
And why not let the industry design their own archetypes? Or the software vendors?
I don't see why that is such a big deal for you.
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?
It is used by runners and cyclists, the more watts per kg you can produce the faster you can run or ride. Especially in the mountains, weight is a real enemy. They say that every kg above the ideal weight cost 30 seconds on Alpe d'Huez. Froome is now 68 kg. When you have less kg, then you need less Watts to ride and every Watt makes you faster. So Watts per Kg is very important.
But you want software for many more things, how is your heart doing when riding at steep sloop of 10%, and what if you push the rate 5 beats higher, how long can you do that? Does it improve or does it slowly go down?
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 truthWhat makes you think that the people working in an alternative form of CKM would not come across the same modelling problems?
If more people are busy with archetypes writing, CKM can do the problem-related, others can do the sport-related. They do not need to know about each other. Some vendors like to work in secrecy. They do not want to give away their ideas before they come to market.
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).
I believe you want to recall this. This is blasphemy, comparing healthcare with mathematics. May will disagree with you, and I think they are right.
All the best
Athanasios Anastasiou
Good luck.
Suddenly I realize that I should be working right now. Have a nice evening (in the Netherlands it is evening, but I work 
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. Important is how you do it, and that it does not cost effort by the volunteers, for example in relation to what they do anyway.
It is a French product.
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: ‘but that is currently illegal under EU GDPR.’
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
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.associates/download-gdpr-text-23-languages/
Special categories of personal data which merit higher protection should be processed for health-related purposes only where necessary to achieve those purposes for the benefit of natural persons and society as a whole, in particular in the context of the management of health or social care services and systems, including processing by the management and central national health authorities of such data for the purpose of quality control, management information and the general national and local supervision of the health or social care system, and ensuring continuity of health or social care and cross-border healthcare or health security, monitoring and alert purposes, or for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, based on Union or Member State law which has to meet an objective of public interest, as well as for studies conducted in the public interest in the area of public health. Therefore, this Regulation should provide for harmonised conditions for the processing of special categories of personal data concerning health, in respect of specific needs, in particular where the processing of such data is carried out for certain health-related purposes by persons subject to a legal obligation of professional secrecy. Union or Member State law should provide for specific and suitable measures so as to protect the fundamental rights and the personal data of natural persons. Member States should be allowed to maintain or introduce further conditions, including limitations, with regard to the processing of genetic data, biometric data or data concerning health. However, this should not hamper the free flow of personal data within the Union when those conditions apply to cross-border processing of such data.
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
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.I don't see it happening, this is also because the community on OpenEhr is health-problem-centric thinking, and what we also need is health-lifestyle/sport/consumer thinking.
The culture change from problem-centric-care to health-centric-care is not yet happening on CKM.
I see a lot of overlap there between what you refer to as health-lifestyle and secondary uses of routinely collected data.
This is definitely changing with the availability of platforms that support openEHR (beyond what we had previously)
That is with communities, you get what you get. And even if they were, would they be able to keep up with the industry?
And why not let the industry design their own archetypes? Or the software vendors?
I don't see why that is such a big deal for you.
The "big deal" for me is people developing Archetypes together and on one coherent model.
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?
It is used by runners and cyclists, the more watts per kg you can produce the faster you can run or ride. Especially in the mountains, weight is a real enemy. They say that every kg above the ideal weight
cost 30 seconds on Alpe d'Huez. Froome is now 68 kg. When you have less kg, then you need less Watts to ride and every Watt makes you faster. So Watts per Kg is very important.
But you want software for many more things, how is your heart doing when riding at steep sloop of 10%, and what if you push the rate 5 beats higher, how long can you do that? Does it improve or does >it slowly go down?
Thank you for letting me know, my question refers to what is Watts/kg as an observation. Not at what is "Watts/kg" literally. As an OBSERVATION (openEHR class), where does it descend from? What does it mean? What is it?
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 truthWhat makes you think that the people working in an alternative form of CKM would not come across the same modelling problems?
If more people are busy with archetypes writing, CKM can do the problem-related, others can do the sport-related. They do not need to know about each other. Some vendors like to work in secrecy. >They do not want to give away their ideas before they come to market.
"Secrecy" is costly, or at least this is how I perceive it.
Whether you call it "problem-related" or "sport-related" or "research-related", these parameters all observe the same phenomenon: Life, from birth to death.
Therefore, you will have a set of concepts (which may well be expanding, because the phenomenon does not wait for "you" to study it) but a number of "perspectives" around the concepts.
"Blood pressure" can participate in a Template with one role in the context of pregnancy and in another Template with a completely different role in the context of diabetes.
So, really, the notion that people started working in problems first probably stems from necessity. This is what is immediately needed.
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).I believe you want to recall this. This is blasphemy, comparing healthcare with mathematics. May will disagree with you, and I think they are right.
I don't know who May is but there certainly is a set of people who will feel negatively towards the idea but will keep on reaping its fruits unknowingly.
Archetypes are "Types", not values, or "objects". There is no point in equipping a ->value<- with Inheritance or the ability to constrain its attributes.
As Types, they imply established ways of thinking about them and developing them. Inevitably, the "dimensions of Health" will compose a Universe.
You are trying to make data ->computable<-, not just easily transportable.
I am not dug into any trench. On the contrary, the feedback I decided to provide is towards the realisation of what you proposed, not against it.