# Machine Learning , some thoughts **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2018-06-23 16:11 UTC **Views:** 3 **Replies:** 99 **URL:** https://discourse.openehr.org/t/machine-learning-some-thoughts/15520 --- ## Post #1 by @system Today my wife showed me Plantnet\. https://plantnet.org/en/ It recognizes over 6000 plants from showing a flower or a leaf to your phone\. It has learned from machine\-learning 700\.000 pictures, and its knowledge every day grows stronger, because it keeps on learning\. And not only the looks of a flower, but if it takes location \(biotope\) and date in consideration, the certainty of recognizing gets stronger\. Now you can imagine that it must be hard to recognize a plant from a picture, without seeing the dimensions and showed in many possible angles, in sunlight, cloudy or twilight\. I was impressed how good it already was\. Very advanced computer\-knowledge for free in the hands of the millions\. There is also an app, I did not try it, which recognizes birds from audio\. You walk somewhere, hear a bird and want to know what kind of bird that is\. The Berlin Natural History Museum leads a contest of 29 teams using 23 different methods, with more than 82% good identifications for isolated bird recordings, and more than 74% correct identifications for recordings mixing several bird songs\. I often notice there is a trend in thinking that Machine Learning cannot be much help, see how miserable google\-translate translates\. But then we for get to see how much progress is made in other areas\. Why am I writing this? Just to let you think about it\. 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 lot, but it should also look to datatypes, their semantics and relations\. Isn't OpenEhr better for recognizing pattern then whichever classic storage structure, because the data\-structures in OpenEhr are in semantic models, this instead of some weird Codd\-structure, which only has technical reasons to exist\. \(Classic data stored in classic SQL schema's could be brought over to archetyped structures, to make the base of machine\-learning larger\.\) I think, when this is developed, we should be able to get to at least two advantages\. 1\) We don't need CKM anymore, computers can understand archetypes, we don't need to restrict ourselves to a limited number\. We can also use archetypes we do not know, and maybe we never know\. Even, we wouldn't need archetypes anymore, just as reminder/instruction\. But the computer could create the archetypes on the fly, when seeing the kind of data, the relations, the diagnosis\. 2\) We could use the pattern to recognize healthcare situations, and maybe treat/handle/cure on base of instructions coming from machine learning\. Some thoughts when walking with my wife through the wonderful dunes, and its special vegetation\. Maybe I must write a blog about it\. Have a nice day\. Bert --- ## Post #2 by @Stefan_Sauermann 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 Engineering & eHealth \(Master\) in September 2018\! University of Applied Sciences Technikum Wien Hoechstaedtplatz 6, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mme I: www\.technikum\-wien\.at/bhse I: healthy\-interoperability\.at fb: www\.facebook\.com/uastwMME portfolio: https://mahara-mr.technikum-wien.at/user/sauermann --- ## Post #3 by @system 92% would be a disaster in healthcare ... I am slightly more optimistic: I suspect that the key bit of research is to create machines, e.g. for interpreting images, that can accurately distinguish between 3 of image: don't know; not sure (error rate likely to be too high); and sure (e.g. less than 0.2% error rate or similar). Such machines would throw images in the first two groups to humans, and would do the work on the 'sure' group. The key is to be able to recognise ambiguity or the lack of it. Doing this properly might require more than one kind of AI. And of course, AI image interpreters would not need to work with displayed bit maps, but would work with computable 3-D and 4-D matrices. - thomas --- ## Post #4 by @Karsten_Hilbert Not in visual classification of dermatological health concerns\. Or areas of radiological diagnostics\. Karsten Hilbert --- ## Post #5 by @system 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 hacked together. It is certain that AI applications in healthcare must be treated as Medical Devices. For it function properly we need to be able to document healthcare topics including the full context/epistemology. Present OpenEHR/13606 and terminology developments form a good foundation. But are not sufficient. What is lacking are well researched and designed shared patterns that capture the full context, epistemology. CIMI is trying to do that. CIMI, part of HL7, is possibly diverging and getting under the influence of practical thinking as it is adjusting ist gols to encompass FHIR. GF Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #6 by @ANASTASIOU_A 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 lot, > but it should also look to datatypes, their semantics and relations\. openEHR and the dual modelling approach, model the data which reflect the evolution of a person's health condition\. Inferences from the data \(irrespectively of whether they are stored in an openEHR enabled server or not\) would return information about the health condition itself\. Inferences from the data models \(descriptions of the data\) would return information about the modeller's understanding of the health condition and anything else that stems from the requirements for cataloguing it\. As a similar example, consider what else does ICD\-10 encodes along with the rest of the "\.\.\.Classification of Disease": https://www.icd10data.com/ICD10CM/Codes/V00-Y99/V30-V39 We usually express research questions in sets of codes, sometimes with branches to make sure that we pin point exactly the information about the condition and not anything else that might be encoded along\. > Isn't OpenEhr better for recognizing pattern then whichever classic > storage structure, because the data\-structures in OpenEhr are in > semantic models, this instead of some weird Codd\-structure, which only > has technical reasons to exist\. Yes and no\. It is more a question of whether the EHR does encode all information that is dependent on the class\. > 1\) We don't need CKM anymore, computers can understand archetypes, we > don't need to restrict ourselves to a limited number\. We can also use > archetypes we do not know, and maybe we never know\. Even, we wouldn't > need archetypes anymore, just as reminder/instruction\. But the > computer could create the archetypes on the fly, when seeing the kind > of data, the relations, the diagnosis\. The last bit where the "computer" composes the archetype is indeed incredibly interesting and in the current climate it could be something like "AI Assisted Archetype Composition"\.\.\.\.\.\.I doubt we can go 100% automated there\. Do words encode everything in a language exactly? Logic expressions / deductions are "stale"\. Given the axioms and the operations, you can work out the complete universe\. This is partially true for \*\*some\*\* of the stuff that we do but for others, there comes a point where the "Concept Set" gets re\-distributed or enriched\. New things, new ideas, new conceptions are coming in\. The "computer" needs a way to encode this process in order to express it and this will happen as soon as "we" understand how that happens too :\) > 2\) We could use the pattern to recognize healthcare situations, and > maybe treat/handle/cure on base of instructions coming from machine > learning\. 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\. BTW, I am not shooting down the proposals / ideas, there is definitely fertile ground for the use of openEHR along the lines you suggest here\. All the best Athanasios Anastasiou --- ## Post #7 by @Karsten_Hilbert It much depends\. In typical care "92%" \(of what ?\) can be an extremely brilliant result far beyond anything available today\. Say, correct ECG interpretation for NSTEMI in the presence of thoracic pain in an unselected primary care setting\. Karsten --- ## Post #8 by @system I agree, especially on GP\-level, I checked with my wife, she is GP, as you \(Gerard\) know\. I asked her if the context/epistemology in a EHR is sufficient for machine\-learning\. It is not, she sufficient, and that will never be\. GP's have other things to do then carefully record all datapoints that describe a disease\. Even when using archetyped\-systems this does not change\. 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 has headache as a result of fever and other inconveniences coming with infection disease\. So, the GP cannot do much with machine learning, the best source of knowledge is his experience, and if he cannot solve with that, he should ask someone else, or send the patient to the hospital to a specialist\. But there, machine learning can do things in some specialties\. Anyway, thanks for your reply Bert --- ## Post #9 by @system Not really Stefan, but thanks for trying\. --- ## Post #10 by @Karsten_Hilbert > 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 has headache as a result of fever and > other inconveniences coming with infection disease\. > > So, the GP cannot do much with machine learning, the best source of > knowledge is his experience, Experience is, at most, an equal source to evidence\. It becomes "better" over time\. > and if he cannot solve with that, he should ask > someone else, or send the patient to the hospital to a specialist\. Nonetheless, an algorithm \_can\_ scan records in the background looking for telltale constellations indicating the "I am sure" group \(which we sometimes DO miss\) and highlight those to the GP\. Karsten --- ## Post #11 by @system So we have always worked with 82% or 92% or 74% recognition, and we never called that a disaster. We called that healthcare, and it is only a few years ago, that is was like that, and in many cases it is still like that. I now know they are using machine learning for checking x-ray's for cancer, and it is a fact that these machine-learning algorithms are much better and much more accurate then humans are. The find micro-metastasis of only a few cells, and they are of course manually checked. So that is a real improvement. Now, thanks to machine learning the rates of detection are 99%. It is not only much better, but also much cheaper. How much do you think it costs of a radiologist is staring at pictures? Thanks for your reply and confirming this. Bert --- ## Post #12 by @system Thanks, for your answer, I agree with you and others, and already wrote that, that an EHR will not be good enough for machine learning\. I was too optimistic and to much impressed by some results of machine learning\. It will do very good things in healthcare, but only on very specific cases\. But while writing this What would be good, however, an improvement\. I suggested to my wife \(a GP\), and she agreed \(partly\) Classic EHR software only has few datapoints on a screen, and many particularities come into free text, and if the GP is really motivated, maybe he finds some ICPC code\. Archetypes do not really change this practice\. A GP is a busy person\. What could help is modularity\. A GP should be able to add datapoints to his screen\. For example, beside all the normal things, the GP sees that there are red eyes, but how can he make this available to the system in a way that it can be found back? 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 checkbox\. Eventually a choice, A bit red, medium red, very red\. This kind of software does not have to be something for the far future, but can be available already now\. Also thanks to machine learning, a limited form of NLP \(natural language expression \(machine learning helping with NLP\) can be used, and that was my idea of generating archetypes, last Saturday\. A computer could, in some cases of simple datapoints, also even generate micro\-archetypes for them, and with templates or container\-archetypes, generate evaluation\-archetypes Maybe, when it is so easy to create datapoints, and store them, maybe then machine learning in diagnostic can come closer, also in some cases for a GP, or machine learning can do suggestion: look to the tongue of the patient, but the fact remains, a good GP needs experience for diagnotics\. Bert --- ## Post #13 by @Karsten_Hilbert 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\. As for GP land, care is also rarely about "a diagnosis", but rather about "a person"\. Karsten --- ## Post #14 by @system The doctor mumbles to his screen while the patient tells it story, or the doctor does something and mumbles\. He wouldn't even have to change his behaviour\. Looks promising that others think so too\. Bert --- ## Post #15 by @Philippe_AMELINE You may be interested in this paper (from my Tech Trends): [http://philippe.ameline.free.fr/techtreads/additionalMaterial/Boyd_MagicOfBigDataAndArtificialIntelligence.pdf](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 diagnosis is not reported in observations in more than one encounter out of two. Another point is that many medical documents don't get external feedback and can be of very low quality. In France, patients leave the hospital with an hospitalization report. My mother in law was admitted in an hospital for 3 days several months ago, and her "outpatient report" didn't mention any of the things she had discussed with doctors... and her weight was supposed to be 20 kg less than her actual one. Wrong patient, copy-pasted document not properly actuated? Since nobody dare having this kind of document corrected, it remains forever wrong in hospital's records. Successfully using machine learning demands a prior culture of data quality and information awareness. Best, Philippe --- ## Post #16 by @system Have anyone tried AQL adapter to pandas\(python data analysis package for machine learning and statistics\)? Shinji --- ## Post #17 by @ANASTASIOU_A Hello Bert and all I am a little bit "worried" with "micro\-archetypes" the way you describe them\. I think that what you are probably referring to is "Disease Specific Templates", which I really hope is what we are all working towards :\) So, archetypes do indeed describe one conceptual quantity, or aspect of a person's healthcare and then a template describes a multidimensional "Point" which characterises the patient journey within the disease\. Consider for example "Total Brain Volume"\. You can use it to track cognitive decline in AD \(https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(04)15441-X/abstract) and this gives you one "explanatory variable"\. But, still, there are patients whose brain volume is abnormal \(for their age\) and they still perform well in other tests, so you need more "data points" \(a richer template\) around the phenomenon to understand it better\. I think that what you are describing is something like "An automated approach to constructing disease specific 'Minimal Clinical Datasets'"\. 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\. All the best Athanasios Anastasiou --- ## Post #18 by @Karsten_Hilbert That's because it rarely actually matters\. And it is rarely actually specifiable\. There's a four\-stage grouping of "diagnostic certainty" in German GP research lore:   'A': \_\('A: Sign'\),   'B': \_\('B: Cluster of signs'\),   'C': \_\('C: Syndromic diagnosis'\),   'D': \_\('D: Scientific diagnosis'\) Most encounters or even episodes of care don't reach C, let alone D\. Karsten --- ## Post #19 by @system 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 there is nothing what we can do\. Big data for machine learning can be build very quick, we have millions of people in healthcare every day\. Imagine a GP making a picture of an eye, or a part of skin, and gets within a second a good explanation about what is there to see\. It is cheap\. If many GP's agree to use an app for classifying viewable symptoms, the supporting big database will grow fast\. I also have to agree with Karsten, it is not only a disease which needs to be cured, but it is a person having that disease\. So, age, weight, gender, ethnicity, profession, social status, country, those are all factors which limit the search area in which the machine learning database must find what it sees\. --- ## Post #20 by @system There is an understandable mindset which aspires to work with a standard\-set of archetypes, which are many times reviewed, and which have a review\-status and a kind of guaranteed quality\. There is a risque of bias in this, for example: That datapoint is not practical, a GP will never record that, or it is not significant\. Those predefined archetypes are always a filter on what can occur\. But they have also an advantage because they are build on common sense, on what is desirable in healthcare to know\. So mostly they cover what is to say about a disease, but it is always knowledge from the past, and always in common sense, so it is quite conservative\. I wonder if besides that approach an approach of archetypes growing in the wild could be of use\. They could be used beside the predefined archetypes\. So we don't need to worry, we throw nothing away\. We are adding, not replacing\. Bert --- ## Post #21 by @Dr_Carola_Hullin_Luc Excellent observations!!! Carol --- ## Post #22 by @ANASTASIOU_A Hello Bert and all > I wonder if besides that approach an approach of archetypes growing in the wild could be of use\. They could be used beside the predefined archetypes\. I don't think that enabling people to create local fragmented subsets of information is a step in the right direction\. We still need the functionality of the CKM, in the same way that you need consensus in an open source project\. You need to file issues, that are reproducible and reasonable and someone takes responsibility for dealing with them and there is a cycle of "refreshing" the current best knowledge and so on\. I am hoping that somewhere, some junior doctors are taking up projects in defining Archetypes and Templates and buddy up with their friends who joined Computer Science instead and they all become a tribe too\. They could be working on "Archetypes & Templates for Secondary Uses of Routinely Collected Data" and that could be a lab for development of new things away from "practice"\. As a side comment: I think that you are also speaking from different experiences\. There is still some way to go in the transition to an electronic HER that would enable all this\. Maybe things are progressing faster where you are \(?\) All the best Athanasios Anastasiou --- ## Post #23 by @system It is a truth that, in the case of GP’s, almost always they deal with Complaints, Tentative diagnosis or estimation of the Seriousness (good/bad feeling), some trial Therapies and some addition investigations/tests, plus finally some time to observe the evolution of the complaints over time; await the test results, and after a while get an idea of a possible diagnosis or a complaint free patient. Rarely one consultation resulted in a distinct diagnosis. The patient population of GP’s is very amorf. There are a lot of haystacks and a few needles. In hospitals it is somewhat different. It is much more finding a diagnosis and treatment or proving that there some diagnosis do not apply. Hospital patient are a highly selected group of patients. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #24 by @system > Hello Bert and all > >> I wonder if besides that approach an approach of archetypes growing in the wild could be of use\. They could be used beside the predefined archetypes\. > > I don't think that enabling people to create local fragmented subsets of information is a step in the right direction\. We still > need the functionality of the CKM, in the same way that you need consensus in an open source project\. You need to file > issues, that are reproducible and reasonable and someone takes responsibility for dealing with them and there is a cycle > of "refreshing" the current best knowledge and so on\. I believe were are in misunderstanding\. I am not against CKM\. I am for an addition on CKM, and then it is an addition which can enclose unexpected functionality, new desirable datapoints, and which will have a flat structure so it is easy to use for machine searching/learning processing\. Machine learning in combination with revolutionary GUI enhancements, in combination with third\-party devices, home\-devices, IoT, phone\-apps, references to blockchained applications, surgery or other treatment abroad, it can bring new insights, new datapoints, more datapoints, it can change parts of healthcare\. I think knowledge\-gathering must change\. It must also happen also more implicitly, automatically\. --- ## Post #25 by @system 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 collect data for ordering of procedures (diagnostic, treatment) Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #26 by @Colin_Sutton Pattern recognition could be done with AI systems using a large selection of health records, to suggest new, possibly unexpected archetypes, but not yet. As commented earlier, data are not sufficiently recorded yet, specialists are too busy; responsibilities are left undefined as patients move from one hospital department to another; discharge records written by subordinates are incomplete summaries of partial records. I can only hope that better systems will be developed to reduce the workload of recording the complexity of patient progression. Then the production of archetypes could be semi-automated: clinical review will still be necessary. --- ## Post #27 by @system > 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 want others to let give their opinion. Suppose an IoT device gives an output which is not covered by a CKM archetype. Suppose someone is treated in Georgia with bacteriaphages therapy. Someone having strange skin marks which do not fit in the CKM evaluation archetype, but which is recognized by a machine learning app. What to do, not accept this medical relevant information, or create an a on-the-fly archetype, or let a computer create it, so the information can be stored? Suppose we had a situation like In the eighties, it would be difficult to enter in an EHR that someone having AIDS, because no software would support that, it was a new disease. All those rare symptoms coming together. How would we handle that? It is clear that generic archetypes will remain necessary, and generic flat archetypes are perfect to be used by computers to store generated datasets. That is in fact a good possibility to store unexpected datapoints. Today we have in the Netherlands rare diseases caused by chemical substances where people worked with thirty years ago. It is so complex, so many kinds of poison, all kind of symptoms and treatments can be necessary, how to handle this without generic archetypes? I wanted to keep it short. So best regards Bert Verhees --- ## Post #28 by @richardh 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 - eg facial recognition in a crowd Clinical problems on a one to one basis are a different problem - encoding the symptoms/signs will be an issue Interesting idea though Doctors are not too good at sticking to known protocols where the condition is known - machines might do better here R --- ## Post #29 by @Stefan_Sauermann 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 receiving end. The receiving party must read the information and decide what to do, using their human brain cells, no 100% reliable computer aided decision support (as in medical devices). In this use case, I see no difference between: - transmitting information within a "generic archetype" - transmitting the same information in unstructured free text. Both technologies provide a useful solution for the use case. - So (in my humble view) this specific use case does not demand a "generic archetype". In other words, it needs no archetype at all. - A generic archetype does not hurt, of course. - If a community decides to store ALL information in archetyped ways, then so be it. There then MUST be structured and unstructured archetypes. My engineering mind puts up behavioural resistance, if unstructured information is stored in a structure, like an archetype. I can happily educate my mind to stop this, and get acquainted with the view that: - all medical information can be stored in archetypes - some archetypes are more restrained than others - the "generic archetype" does not restrain at all - decision support and advanced, automated analysis will only be available for information stored in the more restrained archetypes, if reliability is needed - information contained in the "generic archetype" must be interpreted by human experts I am very sorry if I missed basic truth, that everybody else is fully aware of. All the best, greetings from Vienna, Stefan --- ## Post #30 by @system Just a few days ago I heard about Google scanning a great number of files of all kind and format, searching for medical information\. The results were quite remarkable\. https://www.healthdatamanagement.com/articles/google-continues-work-to-use-machines-for-health-analytics But unstructured information is not what I am aiming for\. 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\. While talking with the patient, the doctor can measure heartbeat, bloodpressure, saturation, temperature, bloodsugar, even almost without touching de patient\. It will be more soon\. Development goes so fast\. And patients can also measure data at home, or at work, or wherever\. Context is also location, patient personal data, time of the day, jet\-lag, season of the year, weather conditions, other medical conditions, alcohol consumption, social status Most of these data are not regarded as relevant in the actual medical condition\. So archetypes do not have items for this\. There are two kind of medical data\. a\) Medical data which are relevant in the context of a specific medical condition\. b\) Medical data of which the relevancy is not yet known in the context of a medical condition, or another medical condition, which maybe is also not known at the moment\. The data of the second kind are also medical data, so why not store them? Karsten yesterday said, a person at the doctor should be more then a medical complaint\. I agree with that\. But the current medical practice is not like that\. You go to the doctor with a medical complaint, and you talk about that, the doctor does research in that context, and the software finds some archetypes which fit to that\. 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 conversation\. I believe I am the only person in this list who thinks like that\. But that does not matter\. Have a nice day Bert --- ## Post #31 by @system Bert nurses think like you, they need to view every patient within the context of the person's response to their complaint, injury, procedures performed or treatments provide and the person's individual social network, family commitments, lifestyle, home and workplace environments, location exposures \(current and/or past\) etc\. We should be able to collect and store information about these aspects in lifelong EHRs\. Evelyn --- ## Post #32 by @Rakesh_Biswas Doctors too. More here [http://ubplj.org/index.php/ejpch/article/view/766](http://ubplj.org/index.php/ejpch/article/view/766) --- ## Post #33 by @Stefan_Sauermann 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 be "completely generic"? (I try to better understand your use case. Probably "generic" needs a definition to agree on?) Greetings, all the best, Stefan --- ## Post #34 by @Karsten_Hilbert > 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 conversation\. > > I believe I am the only person in this list who thinks like that\. But > that does not matter\. Actually, any worthwhile GP thinks like that \(except we don't say things like "datasets" or "generic archetype"\)\. I rather doubt you are alone in this\. Even on\-list\. Karsten --- ## Post #35 by @system I agree fully. This implies that on the fly small archetypes need to be used to store one or more aspects. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #36 by @system 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 pointing to a problem. Without problem there is no datarecording. It is historically grown like that. Medical data collecting is only done by clinicians, and only when a patient has a problem, the data around the problem, the diagnosis, and the treatment, that is important. Data which do not have a known relevance are not recorded. And when the patient has a new problem, the only information available are the problems in history. Information about lifestyle is unknown. One can ask the patient, but some patients have a selective memory. But in sports this is different. Medical datarecording also happens when there is no problem, but as daily routine. But now, many people today, also no-sport people, I wrote before today, measure data many times. Apple patented a blood pressure device in Applewatch. It is cheap, easy to do. It will not take long and people have their own EHR at Google, Amazon, Microsoft, Walmart or Apple, to record their daily medical data. They maybe will be able to demand that GP's store their findings in that EHR, so a more holistic view about the patient will become available, and maybe insurance companies will reward access to that holistic view. We must prepare for that, the face of healthcare will change. Until now it was problem-care, which we called in Orwellian tradition Newspeak: healthcare. But it will change to really healthcare. It is something completely different, and it happens fast. I learn also from this, while writing I learn. But I have said it all. Now it would be nice to discuss how to implement healthcare instead of problemcare. Bert --- ## Post #37 by @system 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, we cannot wait for CKM to follow day to day inventions, and some of them only used by minorities. The EHR must be able to create archetypes when needed. --- ## Post #38 by @Seref 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 computable health with no interoperability. This will in turn break machine learning because you cannot learn anything valuable from datasets which are created based on data, which are based on models, which are based on clinicians going siri on their systems. As a side note, this whole domain will make much faster progress when someone starts teaching clinicians (when they're at medical school) that informatics, just like washing hands before an operation, is partly their responsibility and they cannot get much out of their systems until they start taking charge of some aspects of it, instead of waiting for vendors to present them their incorrect/biased view of clinical care. Our fundamental problems need humans doing what needs to be done, we're still nowhere near the capability to get rid of having to do what openEHR methodology allows us to do, from and AI perspective. All the best. Seref (who could not keep it brief...) --- ## Post #39 by @Stefan_Sauermann 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 looking for structures in information. This is their job. They care for information. This always starts with a well-defined use case, and introduces limits. Doctors and nurses deal with information, in any way it comes. They care for the patients. They can not accept limits on the information they must store. I agree completely that it is not possible to know which information is relevant, and that all information is better recorded just in case (accepting only the limits of resources and time for those who do the recording). Both is fine and exactly as it should be (to my mind). We are lucky, in that all information can be stored and processed, no matter if structured or unstructured. Again this confirms my observation that we need to cooperate across our disciplines, to get the most out of all fields. Great job for me!! Looking forward, Stefan --- ## Post #40 by @Karsten_Hilbert Not that I like the fact but that is currently illegal under EU GDPR\. Karsten --- ## Post #41 by @yampeku 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. --- ## Post #42 by @yampeku Technically it's ok if patients/citizens are aware of it (and willing to share it) --- ## Post #43 by @Karsten_Hilbert > 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 --- ## Post #44 by @yampeku 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 --- ## Post #45 by @Karsten_Hilbert That would, formally, fulfil the requirements :\-\) Which, of course, isn't practical: as I said, cluelessness in the design of GDPR\. Karsten --- ## Post #46 by @system 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 --- ## Post #47 by @ANASTASIOU_A >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 --- ## Post #48 by @system 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. --- ## Post #49 by @ANASTASIOU_A 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 --- ## Post #50 by @Seref 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 --- ## Post #51 by @system 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 --- ## Post #52 by @Philippe_AMELINE 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\. --- ## Post #53 by @ANASTASIOU_A 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 --- ## Post #54 by @system > 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 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\. 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 --- ## Post #55 by @ANASTASIOU_A >>> 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 --- ## Post #56 by @system > >   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 truth > > What 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 :\-\( --- ## Post #57 by @system 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\. https://plantnet.org/ It is a French product\. --- ## Post #58 by @system 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](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #59 by @system 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/](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](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #60 by @ANASTASIOU_A >>>>> 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 truth >> >> What 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\. --- ## Post #61 by @system 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? --- ## Post #62 by @system 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 --- ## Post #63 by @system > I don't know who May is but May is many ;-) Sorry, no time now, later I come back to your message --- ## Post #64 by @Stefan_Sauermann 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). --- ## Post #65 by @Stefan_Sauermann One other example of "a big bunch of" things is [https://www.snomed.org/](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, --- ## Post #66 by @system > > 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 --- ## Post #67 by @system > >> 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 --- ## Post #68 by @system > >> 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 --- ## Post #69 by @system 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 --- ## Post #70 by @Stefan_Sauermann > 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/](http://11073.org/), especially [https://standards.ieee.org/develop/wg/PHD.html](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](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, --- ## Post #71 by @Colin_Sutton Hmm\.\.\. imagining\.\.\. Steps walked | phone in trouser pocket                         > phone in handbag | strap length :\-\) Colin --- ## Post #72 by @system 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](mailto:christoph.u.lehmann@Vanderbilt.Edu). Evelyn --- ## Post #73 by @system Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto: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. --- ## Post #74 by @system Dear Evelyn, Is there more to read about the scope/purpose of the group? Gerard Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #75 by @system Gerard, You’ll find information about IMIA at [http://imia-medinfo.org/wp/welcome-to-imia-2/](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/](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](https://www.thieme-connect.de/products/ejournals/pdf/10.15265/IY-2016-015.pdf) provides an overview of its mission and membership. Evelyn --- ## Post #76 by @system 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 --- ## Post #77 by @system 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 --- ## Post #78 by @system 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 --- ## Post #79 by @system Thanks Heather for your reply. Unfortunately I am whole day not able to reply. This evening or tomorrow. Best regards Bert --- ## Post #80 by @system 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 --- ## Post #81 by @system > > 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 --- ## Post #82 by @system The intention is certainly a good one. It just needs to be the reference model and the [Abstract Platform Specification](http://www.openehr.org/releases/SM/latest/openehr_platform.html) as the starting point. - thomas --- ## Post #83 by @Karsten_Hilbert 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 --- ## Post #84 by @Stefan_Sauermann 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 :) 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, --- ## Post #85 by @system 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 --- ## Post #86 by @system 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 --- ## Post #87 by @system Thanks, I take a look at it\. Bert --- ## Post #88 by @system 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 --- ## Post #89 by @system That is a good idea, and maybe we should get some volunteers which are involved in sports, on amateur level or professional level\. --- ## Post #90 by @system I would have thought the easiest way would be to machine convert the [RM BMM](https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.3/BMM) and the [Abstract Platform UML model](https://github.com/openEHR/specifications-SM/tree/master/computable/UML) 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](https://github.com/openEHR/archie) 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](https://developers.google.com/protocol-buffers/docs/reference/proto3-spec) 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 --- ## Post #91 by @system 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 --- ## Post #92 by @Philippe_AMELINE 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 ;\-\) 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 --- ## Post #93 by @system 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](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #94 by @system 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\. --- ## Post #95 by @Philippe_AMELINE 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\. --- ## Post #96 by @system 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 :\) Best, --- ## Post #97 by @Philippe_AMELINE BTW, is someone aware of this project by Google? [https://ai.googleblog.com/2018/05/deep-learning-for-electronic-health.html](https://ai.googleblog.com/2018/05/deep-learning-for-electronic-health.html) --- ## Post #98 by @ANASTASIOU_A 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/](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 --- ## Post #99 by @system 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 --- ## Post #100 by @system 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\. --- **Canonical:** https://discourse.openehr.org/t/machine-learning-some-thoughts/15520 **Original content:** https://discourse.openehr.org/t/machine-learning-some-thoughts/15520