# [cis-wg] Complexity, killer apps and other conundrums of health information was: cis-wg Digest, Vol 37, Issue 12 (Juliana Brixey) **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2007-03-20 21:45 UTC **Views:** 3 **Replies:** 30 **URL:** https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575 --- ## Post #1 by @Tim_Cook3 \[apologies for cross posting but I doubt it'll offend too many\] Hi Tom \(and all\), This is certainly true\. The CDA and the more constrained CCD demonstrate very effectively the difficulty in transferring health care information along with it's semantic context\. This is of course the reason for the development of two level modeling and the maturation of over two decades work into the openEHR Reference Model and Archetypes as data descriptors\. See: http://www.openehr.org I hope to \(very soon now\) introduce a query language based on openEHR archetypes that will also allow for a certain amount of "possibility and fuzzy" matching\. This will allow the use of object database storage and retrieval based on a true data model\. This will avoid the tragic mismatch and data fragmentation of object \- relational mapping and the horror of SQL masquerading as a true relational model\. The point is though, that the true "killer app" in health care must be based on a REAL health care data model\. Cheers, --- ## Post #2 by @William_E_Hammond Tom and Tim, I am not sure what this messages says or recommends what we need to do\. I particularly don't understand the comment "The point is though, that the true "killer app" in health care must be based on a REAL health care data model\." I think much of the clinical world is confused about the number of types of models and models now being presented\. What kinds of models do we need and how should they be used? We have the RIM, activity models, data models, DAMs, use cases, story books, BRIDG, and others\. Sorting this might be an excellent project for AMIA CIS WG\. Part of the problem also is sorting through the activities of various SDOs\. None of the SDOs seem to offer an overwhelming solution to all the problems for a number of reasons, including scope\. Ed Hammond              Tim Cook              <tw\_cook@comcast\.              > To              Sent by: Tom Lincoln              openehr\-technical <tlincoln@exhubris\.net>, AMIA CIS              \-bounces@openehr\. WG <cis\-wg@mailman\.amia\.org>              org cc                                        For openEHR technical discussions                                        <openehr\-technical@openehr\.org>              03/20/2007 05:45 Subject              PM Re: \[cis\-wg\] Complexity, killer                                        apps and other conundrums of                                        health information was: cis\-wg              Please respond to Digest, Vol 37, Issue 12 \(Juliana              tw\_cook@comcast\.n Brixey\)                 et; Please                 respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                             > Thanks for your reply\.\.\. The situation is certainly more complex as > the HL7 Clinical Document Architecture XML framework clearly > demonstrates\.\.\. Just picked the first and simplest examples at hand\. > > Tom \[apologies for cross posting but I doubt it'll offend too many\] Hi Tom \(and all\), This is certainly true\. The CDA and the more constrained CCD demonstrate very effectively the difficulty in transferring health care information along with it's semantic context\. This is of course the reason for the development of two level modeling and the maturation of over two decades work into the openEHR Reference Model and Archetypes as data descriptors\. See: http://www.openehr.org I hope to \(very soon now\) introduce a query language based on openEHR archetypes that will also allow for a certain amount of "possibility and fuzzy" matching\. This will allow the use of object database storage and retrieval based on a true data model\. This will avoid the tragic mismatch and data fragmentation of object \- relational mapping and the horror of SQL masquerading as a true relational model\. The point is though, that the true "killer app" in health care must be based on a REAL health care data model\. Cheers, --- ## Post #3 by @Philippe_AMELINE Hi to all, Do you think that a data model is mandatory? Don't you think that the "killer app" could well have no data model of its own, but be flexible enough to comply to any of them \- depending on the local "point of view" of its user ? I means getting closer from natural language and just setting a graph between concepts when a given data model is to be used\. Regards, Philippe Ameline William E Hammond wrote: --- ## Post #4 by @William_E_Hammond Philippe, It seems almost blasphemy to not say you have to start with a model\. I agree with you about the role of the model\. In many cases its seems ytou build the model after you build the system, to show others what you did\. Ed Hammond              Philippe AMELINE              <philippe\.ameline              @free\.fr> To              Sent by: For openEHR technical discussions              openehr\-technical <openehr\-technical@openehr\.org>              \-bounces@openehr\. cc              org                                                                    Subject                                        Re: \[cis\-wg\] Complexity, killer              03/21/2007 12:34 apps and other conundrums of              PM health information was: cis\-wg                                        Digest, Vol 37, Issue 12 \(Juliana                                        Brixey\)              Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                             Hi to all, Do you think that a data model is mandatory? Don't you think that the "killer app" could well have no data model of its own, but be flexible enough to comply to any of them \- depending on the local "point of view" of its user ? I means getting closer from natural language and just setting a graph between concepts when a given data model is to be used\. Regards, Philippe Ameline William E Hammond wrote: > Tom and Tim, > > I am not sure what this messages says or recommends what we need to do\. I > particularly don't understand the comment "The point is though, that the > true "killer app" in health care must be based on a REAL health care data > model\." I think much of the clinical world is confused about the number of > types of models and models now being presented\. What kinds of models do we > need and how should they be used? We have the RIM, activity models, data > models, DAMs, use cases, story books, BRIDG, and others\. Sorting this > might be an excellent project for AMIA CIS WG\. > > Part of the problem also is sorting through the activities of various SDOs\. > None of the SDOs seem to offer an overwhelming solution to all the problems > for a number of reasons, including scope\. > > Ed Hammond > >              Tim Cook >              <tw\_cook@comcast\. >              > To >              Sent by: Tom Lincoln >              openehr\-technical <tlincoln@exhubris\.net>, AMIA CIS >              \-bounces@openehr\. WG <cis\-wg@mailman\.amia\.org> >              org cc >                                        For openEHR technical discussions >                                        <openehr\-technical@openehr\.org> >              03/20/2007 05:45 Subject >              PM Re: \[cis\-wg\] Complexity, killer >                                        apps and other conundrums of >                                        health information was: cis\-wg >              Please respond to Digest, Vol 37, Issue 12 \(Juliana >              tw\_cook@comcast\.n Brixey\) >                 et; Please >                 respond to >                 For openEHR >                  technical >                 discussions >              <openehr\-technica >               l@openehr\.org> >> Thanks for your reply\.\.\. The situation is certainly more complex as >> the HL7 Clinical Document Architecture XML framework clearly >> demonstrates\.\.\. Just picked the first and simplest examples at hand\. >> >> Tom >> > \[apologies for cross posting but I doubt it'll offend too many\] > > Hi Tom \(and all\), > > This is certainly true\. > > The CDA and the more constrained CCD demonstrate very effectively the > difficulty in transferring health care information along with it's > semantic context\. > > This is of course the reason for the development of two level modeling > and the maturation of over two decades work into the openEHR Reference > Model and Archetypes as data descriptors\. See: http://www.openehr.org > > I hope to \(very soon now\) introduce a query language based on openEHR > archetypes that will also allow for a certain amount of "possibility and > fuzzy" matching\. This will allow the use of object database storage and > retrieval based on a true data model\. This will avoid the tragic > mismatch and data fragmentation of object \- relational mapping and the > horror of SQL masquerading as a true relational model\. > > The point is though, that the true "killer app" in health care must be > based on a REAL health care data model\. > > Cheers, > \-\- > Timothy Cook, MSc > Health Informatics Consulting > http://home.comcast.net/~tw_cook/ > 01\-904\-322\-8582 > > \[attachment "signature\.asc" deleted by William E Hammond/Dept\_CFM/mc/Duke\] --- ## Post #5 by @Philippe_AMELINE Ed, Of course, it is possible to see a model as an "information mold" that you need to build before it is possible to craft any piece of information\. And putting data here and there "by chance" won't lead to anything\.\.\. except if \(by chance\) you find some order in the entropy\. But I think that it is "thinking the usual way"\.\.\. and Tim spoke of "killer application"\. a "perfect data model", but an application which is able to tell the "health journey story" of a person\. If a formal language is able to tell such a story with a sufficient level of accuracy, we can expect that it is ideally possible, from this information, to automatically fill any kind of attribute/value grid \(say to comply with any usual data model\)\. And even if this ideal is not reachable, we can expect this technology to be able to locally comply to any data model in use while keeping its global genericness\. For example, for continuity of care purposes, the personal health record of Mr Smith must be able to locally comply to the data model used in Hospital X while remaining the plain property of its owner\. Even if it is not easy every day ;\-\) Philippe William E Hammond wrote: --- ## Post #6 by @thomas.beale Given Tim's message below about a new openEHR query language, it seems worthwhile indicating one of our future directions in openEHR\. As you may have noticed, there are now two categories of specifications: 'stable' and 'in\-development' \(see the release 1\.0\.1 roadmap page\)\. As soon as we are done with Release 1\.0\.1, I would proposed that a third category will come into play, which for now I will call 'industry specifications'\. These are proposals for further specifications in openEHR, where the original offerings come from industry, or in fact any external source \(including individuals\)\. The process I believe we should follow \(and this is up for discussion by the community\) is something very close to that of the OMG RFP process, whereby external proposals are made in response to an OMG, or in this case, openEHR, request for proposals for a particular new specification, e\.g\. a query language\. As it happens, my own company has created a new archetype\-based query language \(paper will be published in MedInifo 2007\); the UCL group will most likely propose something\. Any other similar proposals, such as Tims are strongly encouraged\. Therefore in this third category of specifications, final specifications would be developed by a process of review and collaborative work on all received proposals leading to a synthesised specification\. The OMG has a well recognised process for doing this which takes 18 months from RFP to final standard \(or abandonment\)\. The above at the moment is my opinion, and we would encourage community input both on the process itself, as well as particular specifications\. One of the question is whether to clone the OMG process \(assuming we agreed that it was a good one to follow\), or whether the openEHR Foundation sought a formal relationship with OMG\. For similar reasons, relationships with say W3C may be worth considering\. I will leave further thoughts to later, in order to see what reactions the community might have\. \- thomas beale Tim Cook wrote: --- ## Post #7 by @thomas.beale William E Hammond wrote: > Tom and Tim, > > I am not sure what this messages says or recommends what we need to do\. I > particularly don't understand the comment "The point is though, that the > true "killer app" in health care must be based on a REAL health care data > model\." I think much of the clinical world is confused about the number of > types of models and models now being presented\. What kinds of models do we > need and how should they be used? We have the RIM, activity models, data > models, DAMs, use cases, story books, BRIDG, and others\. Sorting this > might be an excellent project for AMIA CIS WG\. > > Part of the problem also is sorting through the activities of various SDOs\. > None of the SDOs seem to offer an overwhelming solution to all the problems > for a number of reasons, including scope\. > Ed, a few comments mainly for other \(probably newer\) members of the community \(Ed knows more about this stuff than most of us\)\.\.\.\. in terms of engaging with the domain, if you are a provider, government, or vendor, the challenge is exactly as Ed says\. If I was coming in cold now, e\.g\. as the IS manager of a large hospital and did some research, I would find all the things Ed has mentioned, and would probably have to spend a year getting on various lists, going to meetings etc in order to even have a starting clue of what to do about it\. Obviously in openEHR we think we have a 'pretty good answer' to some problems, and don't resile from that \- indeed, I would not want to be involving anyone else in a journey whose direction wasn't reasonably coherent and justified by evidence, implementation and real\-world use\. So, for the benefit of newer people who might be here, the technical offering of openEHR is essentially:     \* a set of generic information models that include the notions of       'record', 'subject', various kinds of scientific observation,       assessment, and a few other technical notions such as versioning etc     \* a capability to build a second level of models called archetypes       based on the first level, representing clinical and other domain       content models \(not of concepts, like in Snomed, but of 'data       shapes' for data capture and validation\); this layer can integrate       in sophisticated ways to terminology such as Snomed, LOINC, ICDx etc     \* a capability to build a third level of models called 'templates',       which underpin screen forms and reports \(e\.g\. discharge summaries\)       and messages     \* a capability to build software systems \(back\-ends\) from layer 1,       which can process artifacts from layers 2 and 3     \* a capability to build front\-end applications that talk seamlessly       to the back\-end services using the templates and archetypes     \* a capability to integrate the system and its internal data with       external data sources \(HL7 messages, 13606 Extracts, CDA       documents, relational data extracts etc\)     \* a capability to query the data using portable queries based on the       archetypes; this provides the basis \(possibly for the first time\)       for decision support to get at longitudinal data from multiple       enterprises using reusable queries\. The rest is all detail \(there are all kinds of documents about the details;\-\)\. This approach changes a number of things; it involves clinical people directly \(they develop the archetypes\), enterprise ICT/clinical people \(they develop the templates and some of the applications\)\. It \_integrates\_ the information, clinical models and terminology viewpoints; it provides a solid \_semantic\_ basis for querying, giving decision support new possibilities\. We hope it will also significantly change the software engineering/solution deployment/delivery economics for the better while increasing quality\. Not all of this is proven by any means, but quite a lot has; the prospects for success appear very good based on implementations so far\. Other organisations have approached the problem in different ways, and often addressing a different subset of the total possible scope\. We have made a commitment to a certain split between information models and higher level kinds of models \(Reference Models and Archetypes, in openEHR\-speak\); this is proving to work very well indeed, but of course others have differing opinions\. The only proof that matters is in ultimate deployment: does the system work, does it scale, and is it economic to build and run; does it add something good to the way we do health? That is what we are focussed on \- outcomes\. I think the best approach for dealing with the plethora of SDOs is firstly not to become another one, and secondly to do our best \(via members\) at cross\-review and fertilisation\. A bit of healthy competition is not bad either\. \(Some people, including Ed have suggested that openEHR does in fact become an SDO; I wonder what others think about this\)\. As soon as Release 1\.0\.1 is finalised I think we need to flesh out where openEHR will go from here, and I imagine \(hope\) there will be much input into what the roadmap should include\. \- thomas beale --- ## Post #8 by @Tim_Cook3 since my proposal for an archetype query language is hardly past the musing stage and Ocean is prepared to present theirs at MedInfo; I won't pursue it any further\. Archetypes only need one query language\. :\-\) Cheers, Tim --- ## Post #9 by @system Dear Colleagues, Let me explain by means of a metaphor what we must expect from the killer app for health ICT. What the present situation is, using the Message Paradigm. Compare it with the Two Level Model Paradigm. We all know what to expect from the healthcare of the future. We all know what the ICT-requirements are that are capable to support the healthcare of the future. I know where to look for the killer Applications. I know on what models and standards, they can be based. EN13606 and openEHR. EN13606 part 1 is published as European standard. And is accepted (but not published yet) as ISO standard. The other parts will follow soon. **Metaphor: the letter** When we accept that health ICT is about informing a colleague or your self by means of a letter at a later point in time and or other place in the word, then the Microsoft Word word editor is the example of the killer app we need. Why? What we expect from an application for writing letters is that it is a tool that can be used to write about anything we care, or have to, write about. Avionics, banking, my children, health, etc. The word editor is completely agnostic about model of the world people are in and write about. **What is the present situation translated to the metaphor?** What is the method of the Message Paradigm HL7 is using and CEN was using in the past? People from the healthcare world define a restricted syntax, medical dictionary, text phrases, all assembled in a logical structure. For each clinical domain people meet and produce this. What they have produced in effect are sets of fixed electronic forms in a fixed structure. And each domain will produce its own set, own text phrases and dictionary. All the sets of unique electronic forms are specific for each clinical domain and are used in countries, regions, or the whole world. Since each community is using its own dictionary and dialect, it results in many variations expressing the same concept. System vendors are overwhelmed by the number of electronic forms, each form needing specifically developed software to process it. It is obvious that it takes a lot of discussion and complex consensus to produce these electronic forms and in addition a lot of time to implement these forms in an uniform way in regions, countries or the whole world. (if possible at all) This results in static, in flexible, consensus based electronic forms that can not be adapted fast enough for the ever changing health care. And it places a lot of constraints on nation, regional or local variations that have to be expressed and exchanged. So people start to use work arounds with the electronic forms. *The result using the metaphor* The ICT-application functions as a very dedicated application that can process a limited set of electronic forms. In effect this Message Paradigm results in the situation that any system vendor (it could be Microsoft in my example) writes unique software for each electronic form defined in a community. In present healthcare it will be hundreds or thousands of vendors that will produce proprietary applications that process the electronic forms. For each new version of the electronic form large communities of healthcare providers and software vendors will have to go thru the whole process. The ICT tools used are very context dependent. They contain a lot of domain knowledge. Semantic interoperability will come at a very high cost. it will be inflexible, limited and incomplete at best. **What is the situation using the new paradigm?** A new paradigm is used. The Two Level Model paradigm. This means that the software tool is completely agnostic about dictionaries, and text phrases used in any domain. It is gnostic about the syntaxe (the generic structure of each possible letter or document) since not only must humans be able to read the text. Computers need to a model based syntaxe in order to process the information. In the metaphor there is one application that functions as a generic tool based on a standard. Healthcare providers using a second tool produce letter as they see fit. They use dictionaries as they see fit; text phrases as they see fit. It is in their domain that they must come to the definition of concepts they need. It is their responsibility to become and stay interoperable. Whatever they decide the process using a specific editor. On the screen they see what they have agreed, but the output of this so called Archetype Editor is machine readable. The Archetype Editor (freely available as open source and based on a published specification, is based on a second computer processable model. All text they produce as kinds of letters are conformant to the unified generic syntaxe. Any time they can change the content of the letters, the documents. On the fly these letters and documents can be processed by systems. *The result using the metaphor* It acts like any normal **word**-processor. Each community is able to decide what in a specific context they have to (or want to write) in what kind of document. Microsoft (or any competitor) will not have to rewrite software to accomodate new documents. The healthcare application is able to process all possible letters/documents because they are conformant to the unified generic syntaxe. Without re-programming all possible variations of letters can be processed. All data, information, and knowledge in the letters can be read, stored, retrieved, presented and exchanged without the need to write software. Instantaneously new letters/documents can be defined and processed. Any community can come to agreements about the content of the letter/document with the type of content they need. This community can be small (N=1, N=2, ..) Or very large (Region, Country, Cardiology, ENT, ...) There is plug-and-play semantic interoperability between conformant systems and users. Systems become extremely flexible. The ICT-tools used, are really generic tools that can be used in all possible contexts. The ICT-tools do not contain any domain knowledge. It knows how to store, retrieve, present and exchange all possible documents and all concepts that are defined in any community. Semantic interoperability will come at very low cost. It will be very flexible and comprehensive. Gerard Freriks **conexis** --- ## Post #10 by @Tim_Cook3 Tom, Thanks for your reply to Ed's question\. I would like to answer his comment about not understanding what I meant by the killer app needing to be based on a real health care data model\. The thread on the CIS WG list was about the capabilities required of the killer app in health care\. There were some great ideas in that thread\. However, I was making the point that those functions would not be fully useful or even possible if a solid data model was not used as a foundation\. I was of course referring to the two level model approach of openEHR\. This approach is beneficial to any industry but the subject at hand was health care\. :\-\) Thinking out loud \-\- I believe that the openEHR RM & AOM "could" be the OO Data Model that the OMDG http://www.odmg.org/ was never able to popularize\. This would have far reaching effects on OO application development and interoperability across all industries\. Regards, Tim --- ## Post #11 by @William_E_Hammond Tim, I appreciate the response\. The question is what do we do with the alternate choices to the two level openEHR model\. The HL7 RIM was never intended to be the data model for healthcare, but a reference model\. I do think that other m,odels, including work out of CDISC \(and HL7\) including the BRIDG model is useful and usuable\. Also work by caBIG has value\. My question is is there any give in which we can blend efforts rather than compete\. A real world model will not come pout of an abstract model\. It will result only from and by people who are actually engaged in real world scenarios\. We need to engage those people\. Ed Hammond              Tim Cook              <tw\_cook@comcast\.              > To              Sent by: Thomas Beale              openehr\-technical <Thomas\.Beale@OceanInformatics\.biz>              \-bounces@openehr\. cc              org AMIA CIS WG                                        <cis\-wg@mailman\.amia\.org>, For                                        openEHR technical discussions              03/22/2007 08:17 <openehr\-technical@openehr\.org>              AM Subject                                        Re: \[cis\-wg\] Complexity, killer                                        apps and other conundrums of              Please respond to health information was: cis\-wg              tw\_cook@comcast\.n Digest, Vol 37, Issue 12 \(Juliana                 et; Please Brixey\)                 respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                             Tom, Thanks for your reply to Ed's question\. I would like to answer his comment about not understanding what I meant by the killer app needing to be based on a real health care data model\. The thread on the CIS WG list was about the capabilities required of the killer app in health care\. There were some great ideas in that thread\. However, I was making the point that those functions would not be fully useful or even possible if a solid data model was not used as a foundation\. I was of course referring to the two level model approach of openEHR\. This approach is beneficial to any industry but the subject at hand was health care\. :\-\) Thinking out loud \-\- I believe that the openEHR RM & AOM "could" be the OO Data Model that the OMDG http://www.odmg.org/ was never able to popularize\. This would have far reaching effects on OO application development and interoperability across all industries\. Regards, Tim > William E Hammond wrote: > > Tom and Tim, > > > > I am not sure what this messages says or recommends what we need to do\. I > > particularly don't understand the comment "The point is though, that the > > true "killer app" in health care must be based on a REAL health care data > > model\." I think much of the clinical world is confused about the number of > > types of models and models now being presented\. What kinds of models do we > > need and how should they be used? We have the RIM, activity models, data > > models, DAMs, use cases, story books, BRIDG, and others\. Sorting this > > might be an excellent project for AMIA CIS WG\. > > > > Part of the problem also is sorting through the activities of various SDOs\. > > None of the SDOs seem to offer an overwhelming solution to all the problems > > for a number of reasons, including scope\. > > > > > Ed, > a few comments mainly for other \(probably newer\) members of the > community \(Ed knows more about this stuff than most of us\)\.\.\.\. > in terms of engaging with the domain, if you are a provider, government, > or vendor, the challenge is exactly as Ed says\. If I was coming in cold > now, e\.g\. as the IS manager of a large hospital and did some research, I > would find all the things Ed has mentioned, and would probably have to > spend a year getting on various lists, going to meetings etc in order to > even have a starting clue of what to do about it\. > > Obviously in openEHR we think we have a 'pretty good answer' to some > problems, and don't resile from that \- indeed, I would not want to be > involving anyone else in a journey whose direction wasn't reasonably > coherent and justified by evidence, implementation and real\-world use\. > So, for the benefit of newer people who might be here, the technical > offering of openEHR is essentially: > >     \* a set of generic information models that include the notions of >       'record', 'subject', various kinds of scientific observation, >       assessment, and a few other technical notions such as versioning etc >     \* a capability to build a second level of models called archetypes >       based on the first level, representing clinical and other domain >       content models \(not of concepts, like in Snomed, but of 'data >       shapes' for data capture and validation\); this layer can integrate >       in sophisticated ways to terminology such as Snomed, LOINC, ICDx etc >     \* a capability to build a third level of models called 'templates', >       which underpin screen forms and reports \(e\.g\. discharge summaries\) >       and messages >     \* a capability to build software systems \(back\-ends\) from layer 1, >       which can process artifacts from layers 2 and 3 >     \* a capability to build front\-end applications that talk seamlessly >       to the back\-end services using the templates and archetypes >     \* a capability to integrate the system and its internal data with >       external data sources \(HL7 messages, 13606 Extracts, CDA >       documents, relational data extracts etc\) >     \* a capability to query the data using portable queries based on the >       archetypes; this provides the basis \(possibly for the first time\) >       for decision support to get at longitudinal data from multiple >       enterprises using reusable queries\. > > The rest is all detail \(there are all kinds of documents about the > details;\-\)\. This approach changes a number of things; it involves > clinical people directly \(they develop the archetypes\), enterprise > ICT/clinical people \(they develop the templates and some of the > applications\)\. It \_integrates\_ the information, clinical models and > terminology viewpoints; it provides a solid \_semantic\_ basis for > querying, giving decision support new possibilities\. We hope it will > also significantly change the software engineering/solution > deployment/delivery economics for the better while increasing quality\. > Not all of this is proven by any means, but quite a lot has; the > prospects for success appear very good based on implementations so far\. > > Other organisations have approached the problem in different ways, and > often addressing a different subset of the total possible scope\. We have > made a commitment to a certain split between information models and > higher level kinds of models \(Reference Models and Archetypes, in > openEHR\-speak\); this is proving to work very well indeed, but of course > others have differing opinions\. The only proof that matters is in > ultimate deployment: does the system work, does it scale, and is it > economic to build and run; does it add something good to the way we do > health? That is what we are focussed on \- outcomes\. > > I think the best approach for dealing with the plethora of SDOs is > firstly not to become another one, and secondly to do our best \(via > members\) at cross\-review and fertilisation\. A bit of healthy competition > is not bad either\. \(Some people, including Ed have suggested that > openEHR does in fact become an SDO; I wonder what others think about this\)\. --- ## Post #12 by @thomas.beale Tim Cook wrote: > since my proposal for an archetype query language is hardly past the > musing stage and Ocean is prepared to present theirs at MedInfo; I won't > pursue it any further\. Archetypes only need one query language\. :\-\) > > Cheers, > Tim > well, that wasn't the reaction I was seeking ;\-\) It would be great to get more minds on these problems\. I hate the thought that some great idea might slip into oblivion\! \- thomas --- ## Post #13 by @William_E_Hammond Thomas, These are wise words and I appreciate ypur thoughts\. Fortunately \(or unfortunately\) the clinicaol community is now beginning to become involved\. We need to lead them gently into the night\. Ed              Thomas Beale              <Thomas\.Beale@Oce              anInformatics\.biz To              > For openEHR technical discussions              Sent by: <openehr\-technical@openehr\.org>              openehr\-technical cc              \-bounces@openehr\.              org Subject                                        Re: \[cis\-wg\] Complexity, killer                                        apps and other conundrums of              03/22/2007 02:32 health information was: cis\-wg              AM Digest, Vol 37, Issue 12 \(Juliana                                        Brixey\)                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                             William E Hammond wrote: > Tom and Tim, > > I am not sure what this messages says or recommends what we need to do\. I > particularly don't understand the comment "The point is though, that the > true "killer app" in health care must be based on a REAL health care data > model\." I think much of the clinical world is confused about the number of > types of models and models now being presented\. What kinds of models do we > need and how should they be used? We have the RIM, activity models, data > models, DAMs, use cases, story books, BRIDG, and others\. Sorting this > might be an excellent project for AMIA CIS WG\. > > Part of the problem also is sorting through the activities of various SDOs\. > None of the SDOs seem to offer an overwhelming solution to all the problems > for a number of reasons, including scope\. > Ed, a few comments mainly for other \(probably newer\) members of the community \(Ed knows more about this stuff than most of us\)\.\.\.\. in terms of engaging with the domain, if you are a provider, government, or vendor, the challenge is exactly as Ed says\. If I was coming in cold now, e\.g\. as the IS manager of a large hospital and did some research, I would find all the things Ed has mentioned, and would probably have to spend a year getting on various lists, going to meetings etc in order to even have a starting clue of what to do about it\. Obviously in openEHR we think we have a 'pretty good answer' to some problems, and don't resile from that \- indeed, I would not want to be involving anyone else in a journey whose direction wasn't reasonably coherent and justified by evidence, implementation and real\-world use\. So, for the benefit of newer people who might be here, the technical offering of openEHR is essentially:     \* a set of generic information models that include the notions of       'record', 'subject', various kinds of scientific observation,       assessment, and a few other technical notions such as versioning etc     \* a capability to build a second level of models called archetypes       based on the first level, representing clinical and other domain       content models \(not of concepts, like in Snomed, but of 'data       shapes' for data capture and validation\); this layer can integrate       in sophisticated ways to terminology such as Snomed, LOINC, ICDx etc     \* a capability to build a third level of models called 'templates',       which underpin screen forms and reports \(e\.g\. discharge summaries\)       and messages     \* a capability to build software systems \(back\-ends\) from layer 1,       which can process artifacts from layers 2 and 3     \* a capability to build front\-end applications that talk seamlessly       to the back\-end services using the templates and archetypes     \* a capability to integrate the system and its internal data with       external data sources \(HL7 messages, 13606 Extracts, CDA       documents, relational data extracts etc\)     \* a capability to query the data using portable queries based on the       archetypes; this provides the basis \(possibly for the first time\)       for decision support to get at longitudinal data from multiple       enterprises using reusable queries\. The rest is all detail \(there are all kinds of documents about the details;\-\)\. This approach changes a number of things; it involves clinical people directly \(they develop the archetypes\), enterprise ICT/clinical people \(they develop the templates and some of the applications\)\. It \_integrates\_ the information, clinical models and terminology viewpoints; it provides a solid \_semantic\_ basis for querying, giving decision support new possibilities\. We hope it will also significantly change the software engineering/solution deployment/delivery economics for the better while increasing quality\. Not all of this is proven by any means, but quite a lot has; the prospects for success appear very good based on implementations so far\. Other organisations have approached the problem in different ways, and often addressing a different subset of the total possible scope\. We have made a commitment to a certain split between information models and higher level kinds of models \(Reference Models and Archetypes, in openEHR\-speak\); this is proving to work very well indeed, but of course others have differing opinions\. The only proof that matters is in ultimate deployment: does the system work, does it scale, and is it economic to build and run; does it add something good to the way we do health? That is what we are focussed on \- outcomes\. I think the best approach for dealing with the plethora of SDOs is firstly not to become another one, and secondly to do our best \(via members\) at cross\-review and fertilisation\. A bit of healthy competition is not bad either\. \(Some people, including Ed have suggested that openEHR does in fact become an SDO; I wonder what others think about this\)\. As soon as Release 1\.0\.1 is finalised I think we need to flesh out where openEHR will go from here, and I imagine \(hope\) there will be much input into what the roadmap should include\. \- thomas beale --- ## Post #14 by @system Dear Tim, What you write is obvious to me and a small croud. You are one of them. Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@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 --- ## Post #15 by @ognian.pishev I cannot read your messages\. They arrive as an attachment in the form of \*\.e file \(which is the format for Eiffel\)\. O\. Pishev --- ## Post #16 by @ognian.pishev I saved it, renamed it as a \*\.txt file, read it and can say that I fully agree with you\. I am the Ocean Informatics director in charge of non\-health\. I do believe that the two\-level methodology is generalisable\. However, when dealing with different business domains, we have to deal with different type systems\. For example, in finance we definitely need to have the ability to express money and currency classes etc\. We need rational numbers \(for values quoted as 1 1/4, for example\) and we definitely need to deal with different units of measurement: troy ounces for gold, barrels for oil \(when discussing futures and forwards\), interest rates and so on\. A separate issue is that of ontologies\. There are multiple classification and code systems \(ISIN, etc\.\), ISO codes for countries and currencies \(which can be used in openEHR\)\. The list gets bigger\. In order to have a fully archetyped environment, we need to understand the business rules and constraints of that new business domain and to establish the connection between the reference and the archetype model\. We may try to add these data types to the openEHR and we will need money and currencies for admin entries and to interoperate with the accounting, payment, etc\. I beleive, however, that we need domain specific models, rather than a single OO model\. The industry \(Microsoft for example\) is talking about domain\-specific languages; what we need is domain\-specific reference models and data types\. I can see a common core that is invariant irrespective of the business domain and we should definitely try to reuse the models that have already been created and tested\. Ogi Pishev Ocean Informatics P\.S\. The first business implementation of the archetype concept was in the Mandate Compliance System for the largest fund manager in Australia\. --- ## Post #17 by @Tim_Cook3 \.\.\. > > I am the Ocean Informatics director in charge of non\-health\. I do believe > that the two\-level methodology is generalisable\. However, when dealing with > different business domains, we have to deal with different type systems\. It seems to me that, in these two sentences, saying that either the openEHR approach could be but isn't yet generalized\. Or, you are saying that a "type system" exists for each different business domain\. Could you clarify what you meant? > For > example, in finance we definitely need to have the ability to express money > and currency classes etc\. Types of currencies are not part of a "type system" the same way types of lab requests aren't\. > We need rational numbers \(for values quoted as 1 > 1/4, for example\) I believe you'll find this true in almost all business domains and it certainly is in medicine\. Can you explain any need that is not covered by the DV\_PROPORTION data type? > and we definitely need to deal with different units of > measurement: troy ounces for gold, barrels for oil \(when discussing futures > and forwards\), interest rates and so on\. Again I believe these are fully accommodated in the reference model\. > A separate issue is that of ontologies\. There are multiple classification > and code systems \(ISIN, etc\.\), ISO codes for countries and currencies \(which > can be used in openEHR\)\. The list gets bigger\. > > In order to have a fully archetyped environment, we need to understand the > business rules and constraints of that new business domain and to establish > the connection between the reference and the archetype model\. > I contend that there is already a very strong connection between the reference model and the archetype model\. The ontology issue is fully abstracted and for any domain \(or even subdomains\) you would have to select the appropriate ontologies\. > We may try to add these data types to the openEHR and we will need money and > currencies for admin entries and to interoperate with the accounting, > payment, etc\. I beleive, however, that we need domain specific models, > rather than a single OO model\. This is where I believe you are correct\. You do need an information model for each domain \(and / or subdomain as appropriate\)\. There is a nice little block diagram on the front page of each of the openEHR documents that demonstrated the modularity and generalizable nature of the approach\. I also believe that the openEHR Architecture document describes this quite well\. > The industry \(Microsoft for example\) is > talking about domain\-specific languages; what we need is domain\-specific > reference models and data types\. <sarcasm> Yes\! Let's fragment application development and software engineers even more so than now\. This way they will become completely industrialized and specialized to the point that no one understands the basics any longer\. This is kind of like the way dialects of SQL are taught instead of the relational model\. Then they call it RDBMs data modeling\. </sarcasm> > I can see a common core that is invariant irrespective of the business > domain and we should definitely try to reuse the models that have already > been created and tested\. > Good\. This sounds like a good approach\. ;\-\) > Ogi Pishev > Ocean Informatics > > P\.S\. The first business implementation of the archetype concept was in the > Mandate Compliance System for the largest fund manager in Australia\. > Great; did you have to add new data types to the RM? Cheers, --- ## Post #18 by @Tim_Cook3 > Tim, > > I appreciate the response\. The question is what do we do with the > alternate choices to the two level openEHR model\. The HL7 RIM was never > intended to be the data model for healthcare, but a reference model\. I do > think that other m,odels, including work out of CDISC \(and HL7\) including > the BRIDG model is useful and usuable\. Also work by caBIG has value\. In my humble opinion these have great value in showing us the different ways NOT to do things\. This is no different than any other scientific endeavor\. More is learned from the mistakes we make than by the successes\. > My question is is there any give in which we can blend efforts rather than > compete\. A real world model will not come pout of an abstract model\. It > will result only from and by people who are actually engaged in real world > scenarios\. We need to engage those people\. \.\.\. and I believe that the people at the openEHR Foundation as well as those \(and there is crossover\) working on CEN 13606 and HL7 have been engaged and you can see a melding \(where possible\) of the technologies\. As far as a real world model coming out of an abstract \(do you mean just on paper?\) model I tend to disagree \(as far as I understand your statement\)\. Any truly functional real world application must be based on solid engineering constructs\. I believe that in the near future you will see several 'real world' clinical applications based on the openEHR approach\. Cheers, Tim --- ## Post #19 by @system Dear all, It is for people like Thomas to correct, the EN13606 part 2 is a general model that defines how constraints can be expressed to any Reference Model. Be it EN13606-1, openEHR, HL7v3 CDA, etc. This is how we, at CEN/tc251, have tried and succeeded in defining, I think. Part 2 of EN13606 is fully based on the openEHR specification. It is for these reasons that I state that there is absolutely no connection between part one and part two. Other than part 1 and 2 belong to a series of European standards that are on their way to become (or have become) ISO standards. Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@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 --- ## Post #20 by @system Dear all, Let me make a statement to be proven wrong: **The openEHR Reference Model is so generic that it can be deployed in all sectors of business's that deal with dossiers and documents.** *Perhaps specialised datatypes are needed, perhaps specialised archetypes are needed, I will not contest this, for the moment, at least.* Gerard Freriks -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@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 --- ## Post #21 by @Dr_CHEUNG_Ngai_Tseun Dear Ed, I think these abstract models have huge value - in commoditizing the understanding of health care data, and in providing a framework for interoperability. However, I am quite skeptical of the ability to build highly scalable and extensible systems using these abstract models. Our approach in the Hospital Authority has been on a level of a simple Entity-Attribute-Value model (which allows you to represent anything), and to add one layer of organization (patient records & data forms), somewhat like a simpler version of CEN13606. The key here is that we are trying to represent just the patient record, and not all the administrative data and all the processes within a healthcare system. Like a classic 80-20 rule (or in this case possibly 99-1), we believe that managing the patient record efficiently and effectively gives us most of the value for a lot less complexity. To manage the semantics we also manage both the entity definitions (LOINC-type concept) and the terminology contained in the values (SNOMED-type concept). This web of metadata is what makes the data captured in the record reusable and computable. As you say, real world models are what count. We have been running a multiterabyte clinical record store for >90% of the 7 million citizens of Hong Kong since 2000, achieving subsecond response times and >99.99% availability. Most importantly, the model allows *any* new clinical data to be captured without any programming, and this data is managed from input to storage to extraction, presentation and aggregation. I would be most interested to see how this could be achieved using the complex abstract models that are floating around. Regards Dr Ngai-Tseung Cheung Health Informatics Hong Kong Hospital Authority --- ## Post #22 by @thomas.beale Gerard Freriks wrote: > Dear all, > > Let me make a statement to be proven wrong: > \*The openEHR Reference Model is so generic that it can be deployed in all sectors of business's that deal with dossiers and documents\.\* this might be going a little bit far \- probably I would say that it is general enough to deal with any application that has the concept of a 'record of a subject of care'\. Subjects of care include: \- human beings \(health\) \- animals \(health\) \- cars \(maintenance\) \- buildings \(maintenance\) \- materials & plant assets such as water pipes, power lines, etc \- forests In short, anything with a 'care' or 'maintenance' concept would be a candidate\. \- thomas beale --- ## Post #23 by @thomas.beale William E Hammond wrote: > Tim, > > I appreciate the response\. The question is what do we do with the > alternate choices to the two level openEHR model\. The HL7 RIM was never > intended to be the data model for healthcare, but a reference model\. I do > think that other m,odels, including work out of CDISC \(and HL7\) including > the BRIDG model is useful and usuable\. Also work by caBIG has value\. My > question is is there any give in which we can blend efforts rather than > compete\. A real world model will not come pout of an abstract model\. It > will result only from and by people who are actually engaged in real world > scenarios\. We need to engage those people\. > > Ed Hammond > Hi Ed, I have had a look at caBIG, and my impression is that it is like a library of atomic definitions for building reporting data sets\. I couldn't see any constraints not covered by openEHR on a cursory look\. The main difference seemed to be that there was no reference model per se, and no larger encapsulation granularities\. I wonder how we could get quickly educated on caBIG and BRIDG in this community? In terms of real\-world models and abstract models, you may have observed that the archetypes library is growing fast now \- see http://svn.openehr.org/knowledge/archetypes/dev/html/en/ArchetypeMap.html these to my mind are real\-world models, and they are based on the abstract reference model of openEHR \(see e\.g\. the UML http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/computable/UML/uml_start_view.html) \- but it may be that you didn't mean these words in this way\. In any case, a lot of these newer archetypes are coming from NHS clinical people, so I assume they qualify as being 'actually engaged'\. My feeling is that if good quality clinical models can be built then the underlying reference model and machinery is functioning well\. The openEHR reference model \(what you would call an information model \- see the UML above\) is doing pretty well in this respect today, but it wasn't always so \- we made changes \(sometime radical\) for quite a few years \(no doubt driving at least some people up the wall\) before the reference model started 'working' properly\. There will be some need for changes in the future, but I expect mainly additions\. Anyway, the point is that the 'abstract' part of openEHR only got to where it is today by being heavily modified over time using the feedback of clinical modellers \(not IT methodologists\)\. In addition, the archetype language and machinery seem to work pretty well, having themselves been the subject of some years of progressive refinement\. There will be much more to come in this space I am sure\. Finding common ground for all these abstract and concrete models has to be done on the basis of requirements\. What would we try to achieve? Would a synthesis make sense for the whole world \(I am inclined to think not, as the differences between hospital\-centric/distributed shared care and transcription\-based/structured input environments don't abstract away very well in models I have seen\)? Which applications should we attempt to work on? If we say 'EHR' then we already have a world of difference between US/non\-US in the meaning of that term\. If we say 'decision support' it gets a bit more precise\. I'm wondering how we would start\.\.\. \- thomas beale --- ## Post #24 by @Tim_Cook3 > > I think these abstract models have huge value \- in commoditizing the > understanding of health care data, and in providing a framework for > interoperability\. However, I am quite skeptical of the ability to > build highly scalable and extensible systems using these abstract > models\. Skepticism is a good thing\. It helps to provide for worst case scenarios\. > Our approach in the Hospital Authority has been on a level of a simple > Entity\-Attribute\-Value model \(which allows you to represent anything\), > and to add one layer of organization \(patient records & data forms\), > somewhat like a simpler version of CEN13606\. The key here is that we > are trying to represent just the patient record, and not all the > administrative data and all the processes within a healthcare system\. > Like a classic 80\-20 rule \(or in this case possibly 99\-1\), we believe > that managing the patient record efficiently and effectively gives us > most of the value for a lot less complexity\. Simple is the operative word here\. There are many fundamental things wrong with the EAV approach \(it is not a data model in the formal sense\)\. When you use the EAV approach you essentially remove typing from your data\. Lab values, prescription instructions, etc\. are turned into simple strings\. You also loose the ability to manage data integrity and data quality\. While you may think you do not require re\-programming you have either not used any constraints in your application \(you have already defined that there are essentially none in the database\) or you must develop more and more intelligent queries with more and more complex joins in order to perform any computations on the stored data\. The queries are necessarily more complex over time since attribute/value slicing must be done to analyze the content of the generic variables and convert strings back into their appropriate types for computing\. Think public health needs as well as longitudinal patient condition analysis\. The scary part here is that you will \(if not already\) have a system that doesn't tell you what you don't already know\. Very simply; this is a dangerous route when dealing with patient records\. > To manage the semantics we also manage both the entity definitions > \(LOINC\-type concept\) and the terminology contained in the values > \(SNOMED\-type concept\)\. This web of metadata is what makes the data > captured in the record reusable and computable\. Of course I haven't seen your structure but I can guess that you have removed the ability to do automatic updates to terminologies? Do you have people do this manually? Or, do you mean you have your own terminologies? In which case you can't share any data with other entities\. > As you say, real world models are what count\. Real world models that lock health care 'information' into 'data' silos do not reveal the 'information' contained in that 'data'\. The longer this trend continues the more work that will be required to fix it later\. > We have been running a multiterabyte clinical record store for >90% of > the 7 million citizens of Hong Kong since 2000, achieving subsecond > response times and >99\.99% availability\. Most importantly, the model > allows \*any\* new clinical data to be captured without any programming, > and this data is managed from input to storage to extraction, > presentation and aggregation\. I would be most interested to see how > this could be achieved using the complex abstract models that are > floating around\. I would be most interested in seeing data quality measures from your database\. The size and response times you mention are very impressive indeed\. If you are using an EAV approach then I assume you have a staff of SQL experts that continue to get knowledge updates from clinical staff about what is in the database so they can provide the necessary queries when new concepts are added? I doubt everyday users are expected to run their own queries in this environment? "Subsecond response times" \.\.\. Hmmmm, must have some awesome hardware\. You do realize that Moore's Law is really just an observation and not a prediction of \(long term\) future trends in hardware development? As I said earlier; skepticism is a good thing\. ;\-\) Cheers, Tim --- ## Post #25 by @Philippe_AMELINE Hi Tim, You answered what most people involved in 2 level modeling would have said\. Of course, trying to tell somebody's health journey just filling a list of EAV seems strange enough for us to guess that their goal is far more limited than that\. Of course again, 2 level modeling has a price to pay in term of response speed\. But maybe we could understand the way they build an EAV from a "genuine semantic path" as a kind of indexing\. They just need to move from EAV to EAVP by adding a pointer to the "node in the tree" and their super\-fast engine can be turned into an indexing system for most often used queries\. Just my 2 cents\. Philippe Tim Cook wrote: --- ## Post #26 by @Tim_Cook3 > I'm afraid this simply isn't true\. EAV models don't have to remove data > typing\. There's no reason why one couldn't make columns for each data > type within the primary stacked \(observation\) table\. Additionally, well > done EAV models can have constraints, and I'd argue that they can be more > rigorous in terms of data integrity\. Especially when vocabularies are > used to define both the clinical concepts and their corresponding answers\. > > See: http://openmrs.org/wiki/Obs_Table_Primer for one such example\. I'm afraid my statements are exactly true\. While the items don't have to be stored as strings they typically are\. They could be lists, hashes, encoded objects, etc\. But the fact remains that they must be decomposed before any computation can take place\. In your link above you describe an entity\-relationship approach\. A much better approach \(in my opinion\)\. However, you have the exact issues with schema drift that EAV was meant to avoid\. Please see: http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pubmed&pubmedid=9824799 for information on what EAV really looks like\. > > The scary part here is that you will \(if not already\) have a system that > > doesn't tell you what you don't already know\. Very simply; this is a > > dangerous route when dealing with patient records\. > > This seems like a bit of an overstatement\. EAV by no means is the panacea > of clinical database design, but it's far from dangerous\. I'm surprised a physician would say this\. IMHO, anytime you don't know, what you don't know; people's lives can be at risk\. >   It's all about how you design it\. I'm interested in seeing your EAV design\. Regards, Tim "Make everything as simple as possible, but not simpler\." \-   \-\- Albert Einstein --- ## Post #27 by @Tim_Cook3 The misinformation in this thread led me to do a bit of Google searching for reinforcement\. Of course I have no idea what the qualifications of the participants are but one can imagine that they are mostly DBAs at some level\. See the short conversation at: http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=57307 Cheers, Tim --- ## Post #28 by @Tim_Cook3 > > Tim, I have no intention of getting into an email argument with you\. The > only reason I replied is because I believed you were using FUD to make a > point\. I didn't know we were arguing\. I thought we were still are\) having a technical discussion regarding a major factor in clinical information systems design and implementation\. > There is no hard and fast definition to an EAV data model, outside > of the fact that a single piece of data is the unit of storage within a > row\. See: http://en.wikipedia.org/wiki/Entity-Attribute-Value_model > Thanks\. The example used here makes my point precisely\. > We can quibble re: whether you think that what I linked to before is an > EAV model, but you know what my point was\. I am not quibbling \(1\.an instance of the use of ambiguous, prevaricating, or irrelevant language or arguments to evade a point at issue\.\)\. I was merely correcting your misunderstanding of the two different approaches\. > Just because the items are > "typically strings" in most designs, doesn't mean they have to be\. > Designs can be enforced that allow for a datum per row, and still maintain > datatype integrity / constraints\. Most large scale repositories that > attempt EAV, that I've laid eyes on do so\. > "By de facto definition"; this simply is not possible\. If you have examples that you have laid eyes on, that maintain datatype integrity / constraints in the database, then they are NOT an EAV approach\. That would have to be done in the application or in stored procedures which by all accounts would be part of the application code\. > I suppose if there were an infinite number of datatypes to clinical > information, perhaps there would be this "schema drift" that you refer to, > but once again, I think you overstate your case a bit too strongly\. You may continue to think I over state my case or you can review a few papers on persistence of complex data, i\.e\. clinical information systems, GIS applications, etc\. > I think I've missed your point\. Is there a system around that "knows" > everything about patients? > Of course not\. I apparently did not describe my point in enough detail\. The point is that users make assumptions about the knowledge contained in an application\. This is based on many things such as types of data they have personally entered\. When data is entered without constraints and queries are executed based on assumptions then information can be missed quite easily\. While this seems naive on the surface it is a reality in designs that use approaches like EAV\. > > I'm interested in seeing your EAV design\. > > I didn't write to this list to speak on behalf of our work\. Neither was I critiquing it\. I made a technical observation regarding the information at the URL you provided\. One can clearly see the differences in the examples from your wikipedia link and the example on the OpenMRS link\. I understand it is a very good application and it's certainly from a prestigious institution\. I did find it interesting that OpenMRS uses an abstraction approach to reduce the complexity issues of clinical data persistence\. It would seem natural that the design team of OpenMRS would embrace the concepts of openEHR\. Just my interpretation of course\. > I merely saw something I knew wasn't fully true, and I felt the need to clarify\. I'm unclear as to what part\(s\) of my statements are untrue\. If you have discovered factual errors on my part I would like to have them corrected\. Please validate your assertions with something a little better than wikipedia\. :\-\) > If you're interested in continuing the discussion, feel free to write me > privately, as this seems to be getting off topic somewhat\. :\) I fail to see how a discussion of the validity of various persistence models of clinical data is off topic for these two mailing lists\. I was going to change the subject line of the thread but actually I believe the subject I entered earlier in the thread is still the topic of this conversation\. If other list members do not see value in our discussion then they should feel free to speak up\. On the contrary, I hope others with expertise in this area do join in\. Cheers, Tim --- ## Post #29 by @Tim_Cook3 This is clearly a point where we will continue to disagree\. I believe words mean certain things and things have definitions\. Maybe my view is a little too black and white? EAV, EAV/CR, E\-R, etc\. seem to me to be all 'different' approaches to modeling application data\. Apparently, you believe they are all the same? BTW: I wasn't 'attacking' Dr\. Cheung's patient record system\. But if it is based on the approach that I believe is EAV\. I am first amazed at it's scale \(and would like to know more about it\) and secondly I am concerned about the data quality\. Now if you consider it none of my business then fine\. I happen to believe that if, as a professional, I have a founded concern about something as important as data quality in a patient record system\. Then I have a duty to mention it\. If the folks in Hong Kong are happy with their approach to insuring data quality then I am happy for them\. I've done my duty and they've done theirs\. Cheers, Tim --- ## Post #30 by @Tim_Cook3 Dr\. Cheung, > I notice you take issue with our approach being simple\. I find that > simple is usually better than complicated\. Way better\. Occam's Razor > comes to mind\. In the words of a modern era pragmatist; "Everything should be made as simple as possible, but not simpler\." \-Einstein > It may be hard to believe, but we have indeed constructed a tool which > lets normal users query across our multiterabyte clinical warehouse > for any concept which is captured in the system, including new > concepts as they are introduced\. No programming is required to define > the data capture, the data storage, or the data retrieval\. As I said before; this is a very amazing accomplishment and you and your team are to be commended\. In view of the importance of this accomplishment it would benefit the entire world if you could publish your structure and some documentation on a public server\. Maybe even on SourceForge? I realize that this requires man\-hours\. But it would help if everyone could emulate it\. It is a shame to see so many people reinventing something that already works so well\. We could all move on to more important things like building a tool to translate a written clinical guideline into a computable form\. > Another very important point which people often forget is that there > is a difference between building a scalable, sustainable system and > communicating between systems\. Very true\. But both are important\. > As I said, things like HL7V3 may be a good framework for > interoperability as information is very clearly defined\. But there is > nothing presenting the HKHA \- using a very simple EAV type approach \- > from sending out our data in HL7V3 format\. > Well, apparently I did not understand the definition\(s\) of the EAV approach and there are multiple EMRs around the world using this approach to data modeling with great success\. > I just wouldn't want to build our entire system based on it\. > I would want to build an entire system based on HL7V3 either\. :\-\) Thanks for your reply and I look forward to reading more details about your system\. Kind Regards, Tim --- ## Post #31 by @William_E_Hammond I received this and will try to get back with an answer\. This group is rather independent and is coverigna lot of ground\. They are now beginning to build structures as well\. I look for opportunities\. I also have had only limited success in getting them involved with HL7\. Chris Chute is connected with them/ Ed              Thomas Beale              <Thomas\.Beale@Oce              anInformatics\.biz To              > For openEHR technical discussions              Sent by: <openehr\-technical@openehr\.org>              openehr\-technical cc              \-bounces@openehr\. AMIA CIS WG              org <cis\-wg@mailman\.amia\.org>                                                                    Subject                                        Re: \[cis\-wg\] Complexity, killer              03/26/2007 06:29 apps and other conundrums of              AM health information was: cis\-wg                                        Digest, Vol 37, Issue 12 \(Juliana                                        Brixey\)              Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                             William E Hammond wrote: > Tim, > > I appreciate the response\. The question is what do we do with the > alternate choices to the two level openEHR model\. The HL7 RIM was never > intended to be the data model for healthcare, but a reference model\. I do > think that other m,odels, including work out of CDISC \(and HL7\) including > the BRIDG model is useful and usuable\. Also work by caBIG has value\. My > question is is there any give in which we can blend efforts rather than > compete\. A real world model will not come pout of an abstract model\. It > will result only from and by people who are actually engaged in real world > scenarios\. We need to engage those people\. > > Ed Hammond > Hi Ed, I have had a look at caBIG, and my impression is that it is like a library of atomic definitions for building reporting data sets\. I couldn't see any constraints not covered by openEHR on a cursory look\. The main difference seemed to be that there was no reference model per se, and no larger encapsulation granularities\. I wonder how we could get quickly educated on caBIG and BRIDG in this community? In terms of real\-world models and abstract models, you may have observed that the archetypes library is growing fast now \- see http://svn.openehr.org/knowledge/archetypes/dev/html/en/ArchetypeMap.html these to my mind are real\-world models, and they are based on the abstract reference model of openEHR \(see e\.g\. the UML http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/computable/UML/uml_start_view.html \) \- but it may be that you didn't mean these words in this way\. In any case, a lot of these newer archetypes are coming from NHS clinical people, so I assume they qualify as being 'actually engaged'\. My feeling is that if good quality clinical models can be built then the underlying reference model and machinery is functioning well\. The openEHR reference model \(what you would call an information model \- see the UML above\) is doing pretty well in this respect today, but it wasn't always so \- we made changes \(sometime radical\) for quite a few years \(no doubt driving at least some people up the wall\) before the reference model started 'working' properly\. There will be some need for changes in the future, but I expect mainly additions\. Anyway, the point is that the 'abstract' part of openEHR only got to where it is today by being heavily modified over time using the feedback of clinical modellers \(not IT methodologists\)\. In addition, the archetype language and machinery seem to work pretty well, having themselves been the subject of some years of progressive refinement\. There will be much more to come in this space I am sure\. Finding common ground for all these abstract and concrete models has to be done on the basis of requirements\. What would we try to achieve? Would a synthesis make sense for the whole world \(I am inclined to think not, as the differences between hospital\-centric/distributed shared care and transcription\-based/structured input environments don't abstract away very well in models I have seen\)? Which applications should we attempt to work on? If we say 'EHR' then we already have a world of difference between US/non\-US in the meaning of that term\. If we say 'decision support' it gets a bit more precise\. I'm wondering how we would start\.\.\. \- thomas beale --- **Canonical:** https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575 **Original content:** https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575