Decision Support was: MIE-2008
Hi Hugh and Gerard, I very much agree that snomed coding should only be done where it adds value. Since archetypes provide meaning themselves not everything has to be coded (as opposed to HL7 that relies more on external codes). Although for export to non-openEHR formats (or data-mining on openEHR *and* non-EHR data) it could still be useful. But since finding suitable codes can be very tough, such gimmick coding will probably rarely happen in the first instance. Using codes to reduce the number of archetypes is a very valuable use case. Having a generic archetype as a recording pattern (e.g. lab archetype) and using codes to specify the actual analyte makes sense. As mentioned before templates should be used to aggregate these archetypes in a specific testing 'battery'. Looking at the openEHR archetype repository, there is a generic lab archetype and several specialiced ones based on it. However, it seems to me that the specialisations were done mainly to create battery type lab results structures (e.g. laboratory-liver_function) I think keeping the lab archetype to one analyte and aggregating them in a template would be cleaner and better from a query perspective. Specialisations of the generic lab archetype should only be used to add a field that is missing for an unkonventinal lab test. What do you think? Again, I would like to point you to the terminology use case section in the openEHR wiki: http://www.openehr.org/wiki/display/healthmod/Archetypes+and+Terminology#ArchetypesandTerminology-Usecasesforterminologyreferencesinarchetypes Lets fill this use case list in a *collaborative* manner. It is better to have our thoughts in a permanent spot (wiki) than only in a mailing list thread where they get burried and forgotten after a while. No hesitation, add/rearrange etc as you please ... everything is versioned so nothing gets lost! Hugh, could you add the fewer archetypes use case please. Cheers, Thilo On Fri, Jun 13, 2008 at 10:53 AM, Gerard Freriks gfrer at luna.nl wrote: Hi, The way I like to think about it is that there is a generic archetype for lab-tests as a recurring 'pattern'. Each individual lab test procedure is a code from a general coding system. The way Lab-test are reported (quantitative data, in what units of measurement, precision, normal value ranges, semi quantitative data, in what ordinal scale ,etc, etc) will be 'codes' as well, but this time from the Laboratory Resource Description System. The 'patterns' will probably be a special type of Archetype that is of the cluster nature. Batteries have Template nature. Gerard On 13, Jun, 2008, at 6:11 , Hugh Leslie wrote: Hi Daniel I was just using that as an example where its not always useful to code everything. I certainly wasn't trying to say that its not useful to code anything and the example that you give is where it is useful to code. I was just pushing back against those that want to code everything as I believe that we need to code those things that make sense. In terms of battery archetypes, thats another problem because batterys tend to vary between labs (certainly here in Australia anyway.) I would expect that it might be templates that solve this problem with the archetype providing something more generic. Coding of the analytes would then make sense so that you can compare different result sets. This could be also solved by producing archetypes for each analyte and then reusing them for different batteries. This would then mean that P-ALAT is the same archetype where ever it is used. Personally, I think the coded solution is better here as we would have fewer archetypes to manage. regards Hugh -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
Dear all, It is all about patterns for documenting. I agree that inspection of the present collection of openEHR archetypes and those produce by the NHS are a nice resource. But we must realize that these were produced for demonstration, testing, learning or the collection of information requirements. The Templates and Archetypes we need must be designed for semantic correct, reusable, patient safe recording, retrieval, exchange and archiving in mind. A complete new set of scopes that need explicit requirements. - Patterns are to be re-used and aggregated in other archetypes or templates. Question: What are the rules to be applied to make that decision? - A pattern will need a new specialization only when new things have to be added to the original pattern. Question: What are the rules for to decide when to specialize or when to add a new item to the original archetype and create a new version? - What patterns do we have to have in order to be able to document what we need to document? Will we find the answer when we look at the language aspects of what we document? - Some Archetypes document complex notions. For example: the Barletts Index. It is a collection of Observations about a patient system. Each of these observations can be recorded using a documentation pattern. The aggregation of observations is expressed as a number using an algorithm. This aggregation is named the Bartletts Index. All of the observations can be documented using separate archetypes using semi-quantitate patterns. The algorithm can be documented in whatever format. The result is documented using a semi-quantitative pattern, either on its own as the professional opinion of the healthcare provider, or as the result of the application of the algorithm, as substitute of the healthcare providers subjective estimation. So the Bartletts Index can be a subjective statement of the class of Evaluation Archetypes based on Observations, or the a subjective statement (Evaluation) by a healthcare provider without any reference to feeding observations, What will we do when new observation elements are added to the Bartletts Index? What will we do when a new algorithm is used to do the calculations? Is this line of reasoning not leading to the following statements: Observations are observations and end up in Observation Archetypes and are recorded in the EHR, as such. The Bartlett Index is a derivative that either is an Evaluation of Risk expressed as the ARchetype Index as perceived by the documenting healthcare provider, or, the Bartletts Index is a formalism (algorithm) applied to a set of documented Observations leading to a risk index that has to be documented as an Evaluation. I might even argue that the Bartletts Index is an agreed Common Template to express risk for the new born, that could change over time as it is the result of present opinions that can change. This means that there are two versions of the Bartlett Index that express the same notion. One is the professional opinion of the risk for the newborn by the healthcare provider is a certain number. And that the risk is calculated by a specified algorithm using a defined set of observations. Question: Is the Bartlett Index an Observation or an Evaluation? Question: Are there two kinds of Indexes? Question: Is the Bartlett Index an Archetype or Template? Or more general: Are Archetype about recording patterns? Are Templates about context (location, time and culture) dependent collection of constituting archetypes? Gerard On 14, Jun, 2008, at 15:55 , Thilo Schuler wrote: Looking at the openEHR archetype repository, there is a generic lab archetype and several specialiced ones based on it. However, it seems to me that the specialisations were done mainly to create battery type lab results structures (e.g. laboratory-liver_function) I think keeping the lab archetype to one analyte and aggregating them in a template would be cleaner and better from a query perspective. Specialisations of the generic lab archetype should only be used to add a field that is missing for an unkonventinal lab test. What do you think? -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080614/1a2f5da0/attachment.html
Decision Support was: MIE-2008
Hi, The way I like to think about it is that there is a generic archetype for lab-tests as a recurring 'pattern'. Each individual lab test procedure is a code from a general coding system. The way Lab-test are reported (quantitative data, in what units of measurement, precision, normal value ranges, semi quantitative data, in what ordinal scale ,etc, etc) will be 'codes' as well, but this time from the Laboratory Resource Description System. The 'patterns' will probably be a special type of Archetype that is of the cluster nature. Batteries have Template nature. Gerard On 13, Jun, 2008, at 6:11 , Hugh Leslie wrote: Hi Daniel I was just using that as an example where its not always useful to code everything. I certainly wasn't trying to say that its not useful to code anything and the example that you give is where it is useful to code. I was just pushing back against those that want to code everything as I believe that we need to code those things that make sense. In terms of battery archetypes, thats another problem because batterys tend to vary between labs (certainly here in Australia anyway.) I would expect that it might be templates that solve this problem with the archetype providing something more generic. Coding of the analytes would then make sense so that you can compare different result sets. This could be also solved by producing archetypes for each analyte and then reusing them for different batteries. This would then mean that P-ALAT is the same archetype where ever it is used. Personally, I think the coded solution is better here as we would have fewer archetypes to manage. regards Hugh -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080613/37cb8174/attachment.html
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080612/fb6f2e22/attachment.html
Decision Support was: MIE-2008
Hi Hugh, ok, you got me ;), I tried but I could not find a case were there would have been a value in knowing that two standings are (more or less) the same, I think because the word standing is so obviously *well-enough* defined in everyday English, even for a Swede! But what about e.g. the various laboratory battery archetypes? I would think that to know when there is an overlap between batteries is a good thing. E.g. P-ALAT;cat.c. would be in at least a couple of batteries. Also, I do not see this as a problem of bad or good archetyping, but as an archetyping reproducibility problem. Hi Gerard, the problem, as I see it, is that the vocabulary have semantic structures attached whether it is represented or not and these semantics may interact with the semantics of the archetype, hence the grey zone. As it is hard to draw the line reproducibly and as the boundaries may move as both archetypes and terminologies evolve, some overlap may be another good thing. As a conclusion I would like to agree with Hugh that terminology needs information models and vice versa and that the focus now should be to build consensus on the areas surrounding the grey zone. /Daniel On Wed, 2008-06-11 at 09:23 +1000, Hugh Leslie wrote: Hi Daniel I would be interested in a real world use case where you need to know that standing has the same meaning in two different archetypes. If archetypes are designed properly, then the semantics of the model are self contained as a single concept. Specialisations of the model will maintain the same meaning of the contained elements, and the semantics of the contained elements relate to the whole concept. I would contend, that in any examples where the same element needs to have the same meaning across different archetypes, it is probably because the design of the archetype is bad. Coding everything to that level has great implications in terms of cost - not only in terms of development, but also in terms of maintenance. If there are compelling real world use cases for doing this, lets do it, otherwise lets do what is pragmatic and gets the job done as soon as possible. regards Hugh Daniel Karlsson wrote: Hugh, The argument comes when you say that every data point in an archetype needs to be coded and here there are arguments both ways. I would say that it is unnecessary to code every data point. There is little benefit for instance in coding sitting, lying, standing, reclining n a blood pressure archetype. The archetype contrains the value of position to these four values. The values are in context and their meaning is clear to anyone using this archetype. Translation is much easier as the archetype gives an absolute context for the meaning of the term. Coding these terms in SNOMED would be so that you can query your health record for every standing item? Its pretty unlikely that this would be a useful requirement. Coding everything s going to be a very slow and enormously expensive process to get right. It makes translation of archetypes much more difficult, especially for those many countries that don't (yet) have a SNOMED translation. Building archetypes is proving to be a very rapid and useful process. I think that there can be more reasons for binding archetype nodes to external terminologies apart from information re-use requirements in the query for everything standing example, e.g. to be able to express that standing in one archetype has the same meaning as standing in another archetype. Also, I didn't realise that I said that everything necessarily should be coded. Referring to David Markwell's report, he states (more or less) that things in the grey zone should be represented redundantly but he also states that terminology binding requirements should be driven by information re-use requirements. I agree with him on both points. /Daniel ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI Clinical Director Ocean Informatics Pty Ltd M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: www.oceaninformatics.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080611/73a8c58e/attachment.html
Decision Support was: MIE-2008
Dear Daniel, yes, I said that the grey zone is a relic of the past, It is there and we have to deal with it. But that is not to say that it must stay the same. To my mind we have to be aware that when dealing with semantics and IT we must stay close to the eons proven way to do things. For eons we have had as semantic ingredients: - a list of words (nouns and verbs) plus modifiers (adverbs, adjectives): dictionary/vocabulary - a syntaxis/grammar - ways to define what makes sense. The list of words/dictionary/vocabulary defined the concepts building block to be used in grammar. Using words and grammar we could produce sentences and express what we had to express. But we could produce sensical and non-sensical combinations of words and grammar in sentences. Therefor we had ways to select and use only the sensical sentences. And these are archetypes and templates. Archetypes and templates -in addition- provide the patterns (types of sentences) that can be used in healthcare to document observations, evaluations, instructions, and actions. We must think very carefully whether it is wise to have two grammars at the same time. Archetypes and templates have on one hand the role of grammar and the pattern used for documenting. What is a compelling reason to combine the role of a code-list with that of grammar in SNOMED? Does SNOMED have a rich enough grammar? As rich as archetypes and templates allow? Does it has a way to deal with patterns? Isn't it a solution for the grey zone problem to accept that from now on we use SNOMED as a code list / vocabulary, that eventually helps us reasoning because of the ontological features? And that archetypes and templates are the grammar and the expression patterns? Coding systems are a fact of life. Archetypes and templates are a fact of life. Both need a natural role. Isn't this suggestion the most practical way to deal with the grey zone in the future? Gerard On Jun 10, 2008, at 9:55 PM, Daniel Karlsson wrote: I didn't say that the grey zone is a relic of the past but, quite differently, a fact we need to acknowledge and relate to. The main reason: terminologies are not just merely dictionaries but make assumptions of semantics that interact with assumptions of semantics made in archetypes. Also, in terminological languages, representations of the semantics may be processed formally. -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080611/da7e5c9f/attachment.html
Decision Support was: MIE-2008
Dear Everyone, just to add another perspective, in the Galen project post coordination was the norm while IHTSDO sits on a heritage of some 300 000 things Snomed CT needs to take care of. Also, pre-coordination is (I think) required for making fixed length identifiers. Still, Snomed CT is unusable without post-coordination, making pre-coordinated entities for everything in Snomed CT that has laterality would mean approcimately 700 000 entities. /Daniel On Thu, 2008-06-05 at 20:19 +1000, Hugh Leslie wrote: Hi Stef, SNOMED can be pre or post co-ordinated. A pre coordinated term is something like left foot where the side is included as part of the whole code and there is a separate term for right foot. There are many such codes in SNOMED. A post coordinated term is one which is described by a number of codes i.e. foot, left. This can get as complex as you like such as this example from wikipedia 284196006|Burn of skin|: 246112005|Severity|=24484000|severe, 363698007|Finding Site|= (113185004|Structure of skin between fourth and fifth toes|:272741003|Laterality|=7771000|left) We believe that building and querying for these complex post coordinated sentences is very difficult. The marriage of archetypes and terminology is a good one as much of the complexity of trying to express these things in a terminology can be expressed more simply using an archetype with the terminology enabling inferencing. hope this helps regards Hugh Stef Verlinden wrote: Hi Ian and Gerard, Could you please explain what post-coordination is and maybe provide an example of post- (and pre-?) coordination? Cheers, Stef Op 5-jun-2008, om 0:48 heeft Ian McNicoll het volgende geschreven: most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end, ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI Clinical Director Ocean Informatics Pty Ltd M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: www.oceaninformatics.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
? In order to solve it we must look forward and reduce the 'grey zone' by acknowledging that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end. Gerard Realizing that the current Snomed CT Concept Model is not enough (today, unfortunately by far) and that the tools for supporting constrained post-coordination mainly are lacking, at least Snomed CT provides *some* constraints on semantics in areas where openEHR provides none. Also, the suggestion by David Markwell, I believe, is to represent semantics in Snomed space *as well as* in the archetype space. Also, I firmly believe that the grey zone will always exist as it is the result of the concurrent use of two different models of semantics. Thus, the boundary problem will not be solved, rather we will have to develop methods that makes the grey zone related problems less harmful. Regards, Daniel -- Daniel Karlsson, PhD Department of Biomedical Engineering/Medical Informatics Link?pings universitet SE-58185 Link?ping Sweden Ph. +46 13 227573, +46 70 8350109
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/d6b41912/attachment.html
Decision Support was: MIE-2008
Hugh, The argument comes when you say that every data point in an archetype needs to be coded and here there are arguments both ways. I would say that it is unnecessary to code every data point. There is little benefit for instance in coding sitting, lying, standing, reclining n a blood pressure archetype. The archetype contrains the value of position to these four values. The values are in context and their meaning is clear to anyone using this archetype. Translation is much easier as the archetype gives an absolute context for the meaning of the term. Coding these terms in SNOMED would be so that you can query your health record for every standing item? Its pretty unlikely that this would be a useful requirement. Coding everything s going to be a very slow and enormously expensive process to get right. It makes translation of archetypes much more difficult, especially for those many countries that don't (yet) have a SNOMED translation. Building archetypes is proving to be a very rapid and useful process. I think that there can be more reasons for binding archetype nodes to external terminologies apart from information re-use requirements in the query for everything standing example, e.g. to be able to express that standing in one archetype has the same meaning as standing in another archetype. Also, I didn't realise that I said that everything necessarily should be coded. Referring to David Markwell's report, he states (more or less) that things in the grey zone should be represented redundantly but he also states that terminology binding requirements should be driven by information re-use requirements. I agree with him on both points. /Daniel
Decision Support was: MIE-2008
Hi Daniel, Hugh et al. A couple of weeks ago I started a section on the wiki to collect use cases for terminology mappings from archetypes: http://www.openehr.org/wiki/display/healthmod/Archetypes+and+Terminology#ArchetypesandTerminology-Usecasesforterminologyreferencesinarchetypes IMHO this is a very important topic and it would be good if the people following this thread could use it to share their ideas in the wiki. Cheers, Thilo On Tue, Jun 10, 2008 at 3:52 PM, Daniel Karlsson daniel.karlsson at imt.liu.se wrote: Hugh, The argument comes when you say that every data point in an archetype needs to be coded and here there are arguments both ways. I would say that it is unnecessary to code every data point. There is little benefit for instance in coding sitting, lying, standing, reclining n a blood pressure archetype. The archetype contrains the value of position to these four values. The values are in context and their meaning is clear to anyone using this archetype. Translation is much easier as the archetype gives an absolute context for the meaning of the term. Coding these terms in SNOMED would be so that you can query your health record for every standing item? Its pretty unlikely that this would be a useful requirement. Coding everything s going to be a very slow and enormously expensive process to get right. It makes translation of archetypes much more difficult, especially for those many countries that don't (yet) have a SNOMED translation. Building archetypes is proving to be a very rapid and useful process. I think that there can be more reasons for binding archetype nodes to external terminologies apart from information re-use requirements in the query for everything standing example, e.g. to be able to express that standing in one archetype has the same meaning as standing in another archetype. Also, I didn't realise that I said that everything necessarily should be coded. Referring to David Markwell's report, he states (more or less) that things in the grey zone should be represented redundantly but he also states that terminology binding requirements should be driven by information re-use requirements. I agree with him on both points. /Daniel ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
Dear colleague, I agree with you that the grey zone is a relic from the past we have to deal with. Never the less, I want to argue that we have to reduce this grey-zone. By means of my suggestion to do post-coordination as much as possible in the archetype. The main reason is: - In language post coordination is done in the syntaxis and not in the dictionary. Gerard On Jun 10, 2008, at 9:37 AM, Daniel Karlsson wrote: Realizing that the current Snomed CT Concept Model is not enough (today, unfortunately by far) and that the tools for supporting constrained post-coordination mainly are lacking, at least Snomed CT provides *some* constraints on semantics in areas where openEHR provides none. Also, the suggestion by David Markwell, I believe, is to represent semantics in Snomed space *as well as* in the archetype space. Also, I firmly believe that the grey zone will always exist as it is the result of the concurrent use of two different models of semantics. Thus, the boundary problem will not be solved, rather we will have to develop methods that makes the grey zone related problems less harmful. Regards, Daniel -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/31d12655/attachment.html
Decision Support was: MIE-2008
leslie, I agree with the statement below. Gerard On Jun 10, 2008, at 10:06 AM, Hugh Leslie wrote: openEHR needs SNOMED and I believe that SNOMED needs archetypes. The decision will be where archetypes and SNOMED should begin and end and I think there will be a lot of debate in the next year or so! -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/7e3ed64c/attachment.html
Decision Support was: MIE-2008
Hi Gerard, I agree with most of your comments and in principle that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end, this amounts to heresy in a UK context and I think we should be prepared to regard David Markwell's Grey Zone as a contested area for some time. I think we could waste a lot of energy in trying to reduce the grey zone and might be better served by allowing dual-representation in both openEHR paths and Snomed post-coordination, and concentrating our efforts on the clearer areaswhere one approach is obviously better than the other. I would rather present Snomed-openEHR as the productive marriage of 2 noble families, whose sum is greater than the parts, whilst accepting that there will remain on-going jockeying for position in the 'border lands'. Ian (joyfully mixing his metaphors) 2008/6/3 Gerard Freriks gfrer at luna.nl: Hi, Free text versus structured data and information debate: - Like Ian said: Archetypes and templates take away problems from the IT-domain and leave them for those in healthcare. When those in health need, want decision support they will have to use more structured info. In the end they will solve their own problems. - We, in the archetype world, will have to show the way. Timo's thoughts are providing ways to think. Archetypes used must be able to serve many purposes: recording, retrieval, exchange, archiving and re-use for among others decision support. - The boundary problem has to be solved. Davids 'grey zone' must be reduced to a manageable small zone. We can not change the past and must find ways to deal with pre-historic (pre-archetype) data. In order to solve it we must look forward and reduce the 'grey zone' by acknowledging that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end. Gerard On Jun 3, 2008, at 7:43 AM, Sam Heard wrote: Terminology A final part of the equation is the area that David Markwell has been working on in the NHS in the UK. He is investigating how to generate computable terminology code phrases from an archetype: that is, how to post-coordinate information captured in an archetype for inferencing in the terminology space. This has benefit in linking with the pre-archetype data and may allow complex research to be undertaken in the future using ontological tools and engines. So we need to keep the balance between freedom and structure, recognising (as Ian McNicoll says) that good archetypes take the problem out of the technical space to where it becomes a human (and potentially soluble) issue. Cheers, Sam -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Ian McNicoll office +44(0)141 560 4657 fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.org
Decision Support was: MIE-2008
Hi Ian and Gerard, Could you please explain what post-coordination is and maybe provide an example of post- (and pre-?) coordination? Cheers, Stef Op 5-jun-2008, om 0:48 heeft Ian McNicoll het volgende geschreven: most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end, -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/4d21b3e3/attachment.html
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/725c0b1f/attachment.html
Decision Support was: MIE-2008
Ian, I agree. But my wished outcome is clear. And of course we have to deal with the past. But the sooner we, ... Gerard On Jun 5, 2008, at 12:48 AM, Ian McNicoll wrote: Hi Gerard, I agree with most of your comments and in principle that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end, this amounts to heresy in a UK context and I think we should be prepared to regard David Markwell's Grey Zone as a contested area for some time. I think we could waste a lot of energy in trying to reduce the grey zone and might be better served by allowing dual-representation in both openEHR paths and Snomed post-coordination, and concentrating our efforts on the clearer areaswhere one approach is obviously better than the other. I would rather present Snomed-openEHR as the productive marriage of 2 noble families, whose sum is greater than the parts, whilst accepting that there will remain on-going jockeying for position in the 'border lands'. Ian (joyfully mixing his metaphors) -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/38e85b5f/attachment.html
Decision Support was: MIE-2008
Hi Thilo, See my comments inline below... -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thilo Schuler Sent: Monday, June 02, 2008 11:12 PM To: heath.frankel at oceaninformatics.com; For openEHR technical discussions Cc: timothywayne.cook at gmail.com Subject: Re: Decision Support was: MIE-2008 Yes, agree on the querying ... and for querying we need structured content! As Sam and I noticed before this has to be considered when designing archetypes. This doesn't mean there shouldn't be free-text fields, this is a very valid requirement in clinical medicine! [Chunlan Ma] Agree with this requirement. However, we have to be very careful when we allow free text in archetypes because more free-text fields would have less control over data quality. Currently, data quality is an issue and I believe that archetypes will play a very important role in resolving this issue. However, if we provide more free-text fields than necessary, then we may loss one of the advantages of using archetypes. Even though all text fields can be either free-text or coded text, there should be some rules/guidelines suggesting what kinds of fields can be free-text, coded-text or both. Whether a text field is defined appropriately should be assessed during archetype governance process. What I am saying is that carefully defining a text field is not only for the purpose of DSS, it is also for data quality control. Chunlan Thus, when designing archtypes the art is to find the balance between free-text (max. flexibility) and structured content. In my mind we often have to offer *both* in an archetype. If I want to create a local application with lots of DSS I create a template that uses mostly the structured parts of the archetype. If I want maximum freedom I use mostly the free-text parts. Another scenario is that I receive information from another archetype-enabled system: The receiving system doesn't know whether the sending system had used the archtype in a flexible (free-text) or in a structured way. To allow the receiving system to decide whether it can use DSS with this information I see two options: 1) We have a root archetype that optionally offers both (free-text and structured) and we specialise a DSS optimised archetype from it. So only if the DSS optimised archetype was used, much DSS is can be offered. 2) Or we create generic archetype design patterns with switch-like constructs (i.e. if this option option was chosen I can rely on these other attributes to be available as well) so the receiving system's DSS engine can do a kind of archetype-introspection to decide what it can use and what not. Just early thoughts. What do others think? On Mon, Jun 2, 2008 at 9:55 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Thilo, I think the key thing that needs to be considered in Archetype design to support Decision Support is querying. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Thilo Schuler Sent: Saturday, 31 May 2008 8:13 PM To: timothywayne.cook at gmail.com; For openEHR technical discussions Subject: Re: Decision Support was: MIE-2008 I am also interested. I wonder how much decision support has to be considered when designing archetypes. In the near and midterm future decision support will probably mostly happen on a local (i.e. template) level, but I still assume that there should be design patterns of the underlying archetypes that make local decision support feasible. -Thilo On Sat, May 31, 2008 at 1:38 AM, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? I am certainly interested. It is the core of my interest semantic information management in healthcare and my primary driver for being involved in the EGADSS project http://egadss.sourceforge.net/ Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I left the project. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** ___ openEHR-technical mailing list
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/5d6ab130/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanInformaticsl.JPG Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/5d6ab130/attachment.JPG
Decision Support was: MIE-2008
Hi, Free text versus structured data and information debate: - Like Ian said: Archetypes and templates take away problems from the IT-domain and leave them for those in healthcare. When those in health need, want decision support they will have to use more structured info. In the end they will solve their own problems. - We, in the archetype world, will have to show the way. Timo's thoughts are providing ways to think. Archetypes used must be able to serve many purposes: recording, retrieval, exchange, archiving and re-use for among others decision support. - The boundary problem has to be solved. Davids 'grey zone' must be reduced to a manageable small zone. We can not change the past and must find ways to deal with pre- historic (pre-archetype) data. In order to solve it we must look forward and reduce the 'grey zone' by acknowledging that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end. Gerard On Jun 3, 2008, at 7:43 AM, Sam Heard wrote: Terminology A final part of the equation is the area that David Markwell has been working on in the NHS in the UK. He is investigating how to generate computable terminology code phrases from an archetype: that is, how to post-coordinate information captured in an archetype for inferencing in the terminology space. This has benefit in linking with the pre-archetype data and may allow complex research to be undertaken in the future using ontological tools and engines. So we need to keep the balance between freedom and structure, recognising (as Ian McNicoll says) that good archetypes take the problem out of the technical space to where it becomes a human (and potentially soluble) issue. Cheers, Sam -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/d583d302/attachment.html
Decision Support was: MIE-2008
Hi Sam, Boosted clinical process is a nice term indeed, maybe another alternative would be augmented clinical process, inspired by augmented reality, which could probably have interesting applications in healthcare. I should say that I am not sure if I have made my mind about the outcomes of demand pull vs supply push when it comes to initiatives like OpenEHR. On one hand you are right about the requirement for having EHR working, on the other hand a piece of software that benefits from a subset of the standard may help increase the adoption of it. I'd really like to see the outcomes of a little project which would be about porting a simple existing decision support system to an OpenEHR based infrastructure. Warning against adverse drug events for patient safety would be a good target for example. (mostly) rewriting this kind of app would give valuable feedback to archetype designers and also standard developers. A very rough idea at the moment, but I'd like to give this a try in a year or two, when I settle things in other fronts a little bit more. In case any member of this group have a candidate app for a trial like this, I'd be delighted to get some pointers for future work. Regards Seref On Mon, Jun 2, 2008 at 12:04 AM, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Seref, The two things that openEHR offers decision support are: - Formal statement of context (in so far as the reference model has captured it) - see Context Model of Recording p35 of the EHR IMhttp://www.openehr.org/releases/1.0.1/architecture/rm/ehr_im.pdf - The meaning of the information as expressed in a shared set of archetypes. Obviously use of a standard terminology adds further value. By leveraging on these two aspects, and with terminology inferencing, it is possible to build: - A Virtual EHR interface that allows reading, writing and querying of an EHR which can be made available to decision support modules. This service interface provides a means of determining the state of health of a person as expressed in their health record and also writing notifications, monitoring etc. in the EHR. For many years Pete Johnson has been working on this aspect using HL7 and more recently CDA using terminology - the problem is context. - It is important in real applications that the Virtual EHR separates out what is in the EHR and what is being collected today, what has been written by the clinician and what by the decision support, work flow steps etc. Thomas Beale said a long time ago that the problem with Health Informatics is that it doesn't really exist - everyone just goes and builds their own applications, taking little or no heed as to what has gone before. Further, there is no real understanding of what is required of the platform on which to base the added value of decision support, care pathways etc. I believe that openEHR can provide the spring board for major advances in decision support. Archetype designers do need to be aware of the data requirements of decision support and workflow - or what might be best termed *the 'boosted' clinical process*. I like the idea of 'boosted' as it does imply making something good better. At present there is not a lot of demand as we have no platform on which to base it. I believe the boosted clinical process is the next area to get sorted once we have the EHR working nicely!! Cheers, Sam Seref Arikan wrote: Hi, That's an interesting question, and honestly, my knowledge of archetypes is a little bit rusty to comment on this. However, there are other aspects of OpenEHR related work which I find worthy of discussing in the context of decision support. A decision support system is built on top of other layers like ETL which transfers, transforms and updates data that is used by machine learning tools and analysis purposes. The same data is sometimes subject to transformation to OLAP cubes, on which you may again execute machine learning algorithms and/or data mining. Information fed by these systems to a decision support system reaches its final destination where it becomes a driving force in the decision making process. The thing is, this connection from data to decision support engine requrires lots of interfaces. Interfaces to different sources of data, which for example may use different persistence approaches. Feeding data to such a pipeline direclty from archetypes would be an interesting challange. Or performance impact of various persistence approaches in the context of this pipeline, OLAP, etc is worth discussing. My favorite tool Weka, is a machine learning workbench, and everytime I use it for some kind of data, I have to import and transform (make continious data concrete etc) data. I can't help imagining what would happen if I had a version of Weka that allowed me to connect to an OpenEHR based repository. In short, this is a quite broad field,
Decision Support was: MIE-2008
On Mon, 2008-06-02 at 00:41 +0300, Seref Arikan wrote: In case any member of this group have a candidate app for a trial like this, I'd be delighted to get some pointers for future work. I was going to save this for the decision support mailing list. But since you asked ... :-) The EVIDENCE-BASED GUIDELINES AND DECISION SUPPORT SYSTEM (EGADSS) [Yeah we thought it was a cool acronym too!] Is a project that I worked on up until we came to some obvious disagreements over implementation. But the concepts are valid and proven. See: http://egadss.sourceforge.net/ The basic concept is that an EMR sends a basic known set of information about a patient to the DSS. The DSS processes whatever clinical guidelines it knows about using the CLIPS Inference Engine http://clipsrules.sourceforge.net/ and if it finds something applicable to this patient it processes the guideline. If it needs more information (lab results etc.) it sends a request back to the EMR. The guideline analysis is completed and instructions returned to the EMR. A re-implementation of this engine using GLIF instead of Arden Syntax guideline encoding and using an openEHR EHR Extract instead of the CDA for messaging is certainly in my future plans. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/63ba55d1/attachment.asc
Decision Support was: MIE-2008
On Mon, 2008-06-02 at 09:45 -0300, Tim Cook wrote: A re-implementation of this engine using GLIF instead of Arden Syntax guideline encoding BTW: I am not including/excluding other possibilities here. PROforma is a prime candidate but even after reading John Fox's book Safe and Sound: Artificial Intelligence in Hazardous Applications, http://mitpress.mit.edu/book-home.tcl?isbn=0262062119 I was still confused but very interested. :-) --Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/feae05e0/attachment.asc
Decision Support was: MIE-2008
On Mon, Jun 02, 2008 at 09:48:17AM -0300, Tim Cook wrote: I'd really like to see the outcomes of a little project which would be about porting a simple existing decision support system to an OpenEHR based infrastructure. Warning against adverse drug events for patient safety would be a good target for example. (mostly) rewriting this kind of app would give valuable feedback to archetype designers and also standard developers. Doing adverse drug reactions isn't too tough of a technical problem. It is however a MASSIVE knowledge problem. Using clinical guidelines to determine things like immunization adherence etc is a much butter place to start IMHO. Full ACK. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Decision Support was: MIE-2008
On Mon, Jun 02, 2008 at 09:45:08AM -0300, Tim Cook wrote: The EVIDENCE-BASED GUIDELINES AND DECISION SUPPORT SYSTEM (EGADSS) The basic concept is that an EMR sends a basic known set of information about a patient to the DSS. The DSS processes whatever clinical guidelines it knows about using the CLIPS Inference Engine http://clipsrules.sourceforge.net/ and if it finds something applicable to this patient it processes the guideline. If it needs more information (lab results etc.) it sends a request back to the EMR. The guideline analysis is completed and instructions returned to the EMR. That's precisely how I would want a DSS to work for interfacing it with GNUmed. When I last looked at EGADSS (a year or so ago) it looked like they wanted me to use their own GUI not just for defining guidelines but also make the user use their GUI to check for guideline adherence of patients handed over from an EMR. IOW, I couldn't find any documentation on how to get instructions back into GNUmed. Any pointers ? A re-implementation of this engine using GLIF instead of Arden Syntax guideline encoding and using an openEHR EHR Extract instead of the CDA for messaging is certainly in my future plans. Looking forward to that. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Decision Support was: MIE-2008
Yes, agree on the querying ... and for querying we need structured content! As Sam and I noticed before this has to be considered when designing archetypes. This doesn't mean there shouldn't be free-text fields, this is a very valid requirement in clinical medicine! Thus, when designing archtypes the art is to find the balance between free-text (max. flexibility) and structured content. In my mind we often have to offer *both* in an archetype. If I want to create a local application with lots of DSS I create a template that uses mostly the structured parts of the archetype. If I want maximum freedom I use mostly the free-text parts. Another scenario is that I receive information from another archetype-enabled system: The receiving system doesn't know whether the sending system had used the archtype in a flexible (free-text) or in a structured way. To allow the receiving system to decide whether it can use DSS with this information I see two options: 1) We have a root archetype that optionally offers both (free-text and structured) and we specialise a DSS optimised archetype from it. So only if the DSS optimised archetype was used, much DSS is can be offered. 2) Or we create generic archetype design patterns with switch-like constructs (i.e. if this option option was chosen I can rely on these other attributes to be available as well) so the receiving system's DSS engine can do a kind of archetype-introspection to decide what it can use and what not. Just early thoughts. What do others think? On Mon, Jun 2, 2008 at 9:55 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Thilo, I think the key thing that needs to be considered in Archetype design to support Decision Support is querying. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thilo Schuler Sent: Saturday, 31 May 2008 8:13 PM To: timothywayne.cook at gmail.com; For openEHR technical discussions Subject: Re: Decision Support was: MIE-2008 I am also interested. I wonder how much decision support has to be considered when designing archetypes. In the near and midterm future decision support will probably mostly happen on a local (i.e. template) level, but I still assume that there should be design patterns of the underlying archetypes that make local decision support feasible. -Thilo On Sat, May 31, 2008 at 1:38 AM, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? I am certainly interested. It is the core of my interest semantic information management in healthcare and my primary driver for being involved in the EGADSS project http://egadss.sourceforge.net/ Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I left the project. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
On Mon, 2008-06-02 at 15:14 +0200, Karsten Hilbert wrote: That's precisely how I would want a DSS to work for interfacing it with GNUmed. When I last looked at EGADSS (a year or so ago) it looked like they wanted me to use their own GUI not just for defining guidelines but also make the user use their GUI to check for guideline adherence of patients handed over from an EMR. IOW, I couldn't find any documentation on how to get instructions back into GNUmed. Any pointers ? once upon a time there was a pretty good demo online and it appeared to adhere to the initial concepts. As I said; I left the project due to the chosen implementation strategy. I am therefore not 100% certain how it works in implementation now. I don't hold out much hope for a collaborative open source community around this project though. ** In full disclosure though; for those thinking about using EGADSS. I was recently asked (a few weeks ago) to facilitate a conference call with EGADSS people and the FreeMED Foundation in order for the Foundation to gain some open source project management position and move the project forward. In my investigation of the status of EGADSS I found that it is only being used as a tool in Dr. Jankhe's computer science courses at this time. Dr. Jankhe is the one that took over my position as project technical lead and drove the implementation in it's current direction. I was never able to build any real open source mindset within the group and left in frustration. Dr. Jankhe had told me in one of our first meetings that he could never promote open source because Microsoft was a major contributor to his computer science program. You can take all this for what it is worth and maybe the FreeMED Foundation will be able to rekindle some open source energy in the project? Either way, I believe a re-implementation is the best way to go. As Paul Harvey ( http://www.paulharvey.com/ )would say; Now you know, the rest of the story. :-) Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/daa61a4f/attachment.asc
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080601/4358c1c3/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanInformaticsl.JPG Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080601/4358c1c3/attachment.JPG
Decision Support was: MIE-2008
Tim Cook wrote: On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? *ok, well I think that's a vote in favour... i'll ask for openehr-decisionsupport at openehr.org - thomas beale *
Decision Support was: MIE-2008
I am also interested. I wonder how much decision support has to be considered when designing archetypes. In the near and midterm future decision support will probably mostly happen on a local (i.e. template) level, but I still assume that there should be design patterns of the underlying archetypes that make local decision support feasible. -Thilo On Sat, May 31, 2008 at 1:38 AM, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? I am certainly interested. It is the core of my interest semantic information management in healthcare and my primary driver for being involved in the EGADSS project http://egadss.sourceforge.net/ Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I left the project. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
Hi, That's an interesting question, and honestly, my knowledge of archetypes is a little bit rusty to comment on this. However, there are other aspects of OpenEHR related work which I find worthy of discussing in the context of decision support. A decision support system is built on top of other layers like ETL which transfers, transforms and updates data that is used by machine learning tools and analysis purposes. The same data is sometimes subject to transformation to OLAP cubes, on which you may again execute machine learning algorithms and/or data mining. Information fed by these systems to a decision support system reaches its final destination where it becomes a driving force in the decision making process. The thing is, this connection from data to decision support engine requrires lots of interfaces. Interfaces to different sources of data, which for example may use different persistence approaches. Feeding data to such a pipeline direclty from archetypes would be an interesting challange. Or performance impact of various persistence approaches in the context of this pipeline, OLAP, etc is worth discussing. My favorite tool Weka, is a machine learning workbench, and everytime I use it for some kind of data, I have to import and transform (make continious data concrete etc) data. I can't help imagining what would happen if I had a version of Weka that allowed me to connect to an OpenEHR based repository. In short, this is a quite broad field, for which I'd love to exchange ideas with others in a list created for this particular subject. All the best Seref On Sat, May 31, 2008 at 1:43 PM, Thilo Schuler thilo.schuler at gmail.com wrote: I am also interested. I wonder how much decision support has to be considered when designing archetypes. In the near and midterm future decision support will probably mostly happen on a local (i.e. template) level, but I still assume that there should be design patterns of the underlying archetypes that make local decision support feasible. -Thilo On Sat, May 31, 2008 at 1:38 AM, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? I am certainly interested. It is the core of my interest semantic information management in healthcare and my primary driver for being involved in the EGADSS project http://egadss.sourceforge.net/ Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I left the project. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080531/dd294b73/attachment.html
Decision Support was: MIE-2008
On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? I am certainly interested. It is the core of my interest semantic information management in healthcare and my primary driver for being involved in the EGADSS project http://egadss.sourceforge.net/ Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I left the project. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080530/9d91e776/attachment.asc
