Units, Quantities, etc
Verstuurd vanaf mijn iPhone Op 18 mrt. 2012 om 15:15 heeft Thomas Beale thomas.beale at oceaninformatics.com het volgende geschreven: I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. Although i tend to agree with you, this won't work because then you assume that we're talking about the absolute truth. The absolute truth only exist when you're talking, for instance, about astronomics. In medicine you can't say 25 ml of alcohol is lethal. You can only say something like: 25 ml of alcohol is lethal in an adult man of 80 kg. And only when he doesn't drink more than 15 unit alcohol ? week. When he drinks more then The lethal dose is higher. For ? roman of the same weight who drinks 15 units ? week, the lethal dose is lower. My point is that an absolute quantity alone doesn't meander much. At The other hand, we know empirically that if someone has smoked 15 pack years he's at serious risk. Then about puffs. I' m almost sure that you can translate ? puff info a volume. If i remember it correctly 40 drops is 1 ml. So the same should go for puffs. Cheers, Stef
13606 revisited - list proposal
I asume there is no subscription fee for openEHR members. Cheers, Stef Op 15 dec. 2011, om 11:33 heeft Gerard Freriks het volgende geschreven: For more information about the EN13606 Association and the Seville meeting I refer to: www.en13606.org Non-members that want to participate in this meeting are invited to subscribe. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/163939c0/attachment.html
Fwd: [openEHR-announce] CIMI group goes with openEHR archetypes UML profile
Congratulations to all who made this possible and to ourselves This is a crucial 'breaktrough' which will pave the way towards future proof health records which will be widely accepted and used. Cheers, Stef Begin doorgestuurd bericht: Van: Thomas Beale thomas.beale at oceaninformatics.com Onderwerp: [openEHR-announce] CIMI group goes with openEHR archetypes UML profile Datum: 14 december 2011 10:38:14 GMT+01:00 Aan: openehr-announce openehr-announce at openehr.org [press release from the CIMI group] The Clinical Information Modeling Initiative is an international collaboration that is dedicated to providing a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents. CIMI has been holding meetings in various locations around the world since July, 2011. All funding and resources for these meetings have been provided by the participants. At its most recent meeting in London, 29 November - 1 December 2011, the group agreed on the following principles and approach. Principles 1. CIMI specifications will be freely available to all. The initial use cases will focus on the requirements of organisations involved in providing, funding, monitoring or governing healthcare and to providers of healthcare IT and healthcare IT standards as well as to national eHealth programs, professional organisations, health providers and clinical system developers. 2. CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats. 3. CIMI is committed to transparency in its work product and process. Approach ADL 1.5 will be the initial formalism for representing clinical models in the repository. CIMI will use the openEHR constraint model (Archetype Object Model:AOM). Modifications will be required and will be delivered by CIMI members on a frequent basis. A set of UML stereotypes, XMI specifications and transformations will be concurrently developed using UML 2.0 and OCL as the constraint language. A Work Plan for how the AOM and target reference models will be maintained and updated will be developed and approved by the end of January 2012. Lessons learned from the development and implementation of the HL7 Clinical Statement Pattern and HL7 RIM as well as from the Entry models of 13606, openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) initiative will inform baseline inputs into this process. A plan for establishing a repository to maintain these models will continue to be developed by the group at its meeting in January. Representatives from the following organizations participated in the construction of this statement of principles and plan B2i Healthcare www.B2international.com Cambio Healthcare Systems www.cambio.se Canada Health Infoway/Inforoute Sant? Canada www.infoway-inforoute.ca CDISC www.cdisc.org Electronic Record Services www.e-recordservices.eu EN 13606 Association www.en13606.org GE Healthcare www.gehealthcare.com HL7 www.hl7.org IHTSDO www.ihtsdo.org Intermountain Healthcare www.ihc.com JP Systems www.jpsys.com Kaiser Permanente www.kp.org Mayo Clinic www.mayoclinic.com MOH Holdings Singapore www.moh.com.sg National Institutes of Health (USA) www.nih.gov NHS Connecting for Health www.connectingforhealth.nhs.uk Ocean Informatics www.oceaninformatics.com openEHR Foundation www.openehr.org Results4Care www.results4care.nl SMART www.smartplatforms.org South Korea Yonsei University www.yonsei.ac.kr/eng Tolven www.tolven.org Veterans Health Administration (USA) www.va.gov/health Further Information In the future CIMI will provide information publicly on the Internet. For immediate further information, contact Stan Huff (stan.huff at imail.org) ___ openEHR-announce mailing list openEHR-announce at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-announce -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111214/c525d6e9/attachment.html
Could YAML replace dADL as human readable AOM serialization format?
+1 Cheers, Stef Op 6 dec. 2011, om 12:44 heeft Seref Arikan het volgende geschreven: Please do not get me wrong, all the discussion we are having here is useful, it is just that in my humble opinion, some discussions are more useful than others if this standard into which I am heavily investing is to go forward. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111206/b6cb5b37/attachment.html
openEHR Transition: two procedural and one licensing question
Op 7 sep 2011, om 09:55 heeft Erik Sundvall het volgende geschreven: Do read that wikipage and follow the links there to the mail discussions. What is it that you think is missing or unclear in the arguments against SA? That they're hidden in a lot of text form which one has to follow through hyperlinks and read even more text. You stated somewhere - correctly - that companies want to avoid risk, similarly decision makers want to avoid reading through lengthy discussion (from which they have to draw there own conclusions:-) ) If I understand you correctly your main argument is that: the share alike (SA) requirement will create a risk for lengthy juridical procedures - in every country they operate - for companies who include openEHR archetypes or derivatives thereof in their systems. Since companies avoid risk, they will choose other solutions without an SA requirement. The reason for this is that it's not clear what SA exactly means. For instance in the context of building archetype-based GUI- stubs, forms etc. in proprietary systems. As a consequence it could be possible that companies are forced - unwillingly - to open up the source of their proprietary systems. It will take years and many court cases, in different countries, to sort this out. Until then (the large) companies will stay away from openEHR. This problem can be avoided completely by dropping the SA requirement. So I guess the first question is: who has a solid argument against Erik's argument. The second question is: what are the exact benefits of the SA requirement and are they worth the risk of companies not using openEHR at all (presuming that's a real risk). Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110907/d2a043db/attachment.html
Fwd: [openEHR-announce] openEHR Transition Announcement
Very good news indeed. This is exactly what is needed to bring openEHR to where it belongs, at the center of the healthcare. Just out of curiosity, who are these Associates, will they raise sufficient money and how long will it take before these become plans effective. The sooner the better is my idea:-) Cheers, Stef Begin doorgestuurd bericht: Van: Thomas Beale thomas.beale at oceaninformatics.com Datum: 5 september 2011 03:00:45 GMT+02:00 Aan: openehr-announce openehr-announce at openehr.org Onderwerp: [openEHR-announce] openEHR Transition Announcement Dear All, I am writing on behalf of the new Transitional Board of openEHR to share our plans to take openEHR to a new level of operations; a new structure, business model and governance. Our vision is the creation of a thriving community that works collaboratively to benefit humanity through efficient and effective electronic health records (EHRs) that support the highest quality health care for the least effort. Until now, the openEHR Foundation has functioned as an owner of intellectual property, governed by University College London and Ocean Informatics, with board members Prof David Ingram (UCL), Prof Dipak Kalra (UCL) and Dr Sam Heard (Ocean). With the support of the considerable community of Members and via engagement of a new category of sponsoring organisational Member known as ?Associates? - Companies, Universities and Governments - the Transitional Board proposes a number of changes: The openEHR Foundation becomes an operational non-profit organisation with paid key staff and resources; The Board (of governance) of the Foundation is extended to up to 10 people with a shift to election by the openEHR Associates; Members who participate are recognised by their peers, may take on decision-making roles, and have the right to commit changes to the key development assets of the Foundation. The Members will participate individually and, through qualification by peer recognition, will control the development within the three Programmes that are building the key assets: The openEHR specifications of the logical health record and attendant services as well as the methods for describing the content using archetypes (Detailed Clinical Models) and templates; and The openEHR archetypes and templates to be used within systems and for message content between systems to achieve interoperability; and The openEHR software projects, to provide open source development of tools to support the uptake and use of the specifications and templates. A group of Members will be needed to bootstrap each of these programmes and determine the working arrangements that are suitable to the products that they are managing at the current stage of development. The Associates will determine who governs the Foundation by nominating and voting on new members of the Board. The Board will appoint key Operational staff and will approve the leader of each of the Programmes. The Programme Leaders will be appointed by Qualified Members working in that Programme, subject to Board approval. We believe this will create the right balance between the ?ground up? creation of openEHR through participation of Members and ?top down? governance. The first step is to share with you a white paper providing more detail on the proposals and to ensure that the Members are reasonably satisfied that this is the right direction to head. Some key activities have been proceeding in the background and are reaching a point of maturity. It has taken us some time to gather more clinical champions in this endeavour and companies that can use and work with the tools in their early stages of development. It has also taken quite some time for Thomas Beale to work out how to provide a seamless pathway between definition of archetypes, specialisation of archetypes to ensure development scalability, to meet jurisdictional requirements, and templates that allow tailoring for actual use in specific settings. The result is ADL/AOM 1.5. He has, as usual, been totally committed to this work and it is probably very important for me to say, it is ?no mean feat?. There is a lot to do. Most important are: Begin to showcase development teams and software using openEHR successfully in clinical settings; Finalise ADL/AOM 1.5, including its succinct XML expression, and integrate it into existing and emerging tools; Update the openEHR reference model to version 1.1 bringing our collective knowledge to bear on the new features and changes while ensuring backward compatibility; Begin an open source software project for tools, web-based if possible, to author archetypes, templates and terminology reference sets directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools; and Establish a mechanism for Associates to formally endorse archetypes (and
openEHR Transition: two procedural and one licensing question
Hi Eric, Good that you bring up the SA + or - discussion again. In order to make the best decision can you please provide us with these arguments and, if possible, with the names of those companies/organisations. Cheers, Stef Op 6 sep 2011, om 16:51 heeft Erik Sundvall het volgende geschreven: I have heard serious arguments in more than one country where companies/organisations are not wanting to use openEHR archetypes partly because of the SA licencing issue. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/0753a42b/attachment.html
Multiple archetypes in a single concept as a way to create an archetype collaborative
Just to add to this. Another great aspect of openEHR is the separation of the technical and medical (content) aspect. In the clinical knowlegde manager (which Thomas already referred to) clinicians can cooperate to create archetype without have to think about the technical aspects. As for the technical people: whatever the clinicians come up with, they don't have to change any code, unless it would require a change in the reference model, which is extremely rare. Cheers, Stef Op 3 aug 2011, om 09:44 heeft Hugh Leslie het volgende geschreven: Hi Joaquin Just to add another view... The issue of openMRS implementations having different representations of the same thing is a common problem across clinical systems everywhere. Its this problem that is one of the things that we are trying to solve with archetypes. In general, what we find is that most clinical concept representations in clinical systems are subsets (based on a use case) of a fully specified concept. What we try to do in the archetypes is produce the fully specified concept and then constrain it for all the use cases. The different names that you see used for different concepts are not just language dependent, but are also region and usage dependent. This is also usually a matter of constraining the archetype or using a particular terminology subset to represent the information. What openEHR offers openMRS is a single way of representing clinical information that becomes a logical record architecture. If openMRS adopted this approach, then any openMRS system could immediately share information with any other even if the other system hadn't seen the information before. It also means that the burden of developing high quality, clinician validated information models is shifted away from the application developer to a global or regional space. This is going to become more and more critical, as we try to capture more complex clinical information and compute on it as well as share it. regards Hugh On 3/08/2011 3:29 AM, Blaya, Joaquin Andres wrote: Hi, Apologies in advance if this is the incorrect email list for this topic, but I thought it was the most relevant. I'm a member of OpenMRS and there we are discussion a way to have users share the concepts (a limited form of an archetype) created in their systems. This means that for a single concept you could have many concepts from different implementations. This could be because of language or because different words refer to the same concept. For example, Gender in the US might be Sex in another country and Sexo in spanish. I would like to see if OpenEHR has solved this problem so that perhaps OpenMRS could begin to use archetypes. Thanks Joaquin om ___ 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/20110803/3141c7b3/attachment.html
Representing binary values with DV_BOOLEAN
And it's to simplistic too. In that case one also would like to know allergic to which specific type(s) and/or components of penicillin. In that case I also would like to know how that was tested, when and who did that etc., etc. So I guess what's I'm trying to say is: What's the value of such forms and should we discuss this at this level? I guess that doctors always will keep using local forms for all sorts of purposes and at their own responsibility but I don't think we should try to standardize these form as well. I we're able to record the symptoms/abnormalities/functions found or exluded, by whom using which method it's up to the person who has access to that data how to interpret it and to evaluate if he/she can draw a conclusion based on his/ her standards. Like I said earlier an diagnose RA from hospital A can be a different disease from the one meant by the diagnose RA from hospital B and unless I have access to the underlying data I can't and won't use the the diagnose. Cheers, Stef Op 10 feb 2011, om 11:47 heeft Ricardo Correia het volgende geschreven: Of course, this would for sure have bad implications regarding the size of forms and time to fill them -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110210/de13344a/attachment.html
Representing binary values with DV_BOOLEAN
To make thing even more complicated (we discussed this already some years ago) the question should be: Does the patient have diabetes according to the definition used commonly in this practice/ hospital/ county/ country/ part of the world. Don't remember it exactly but back then I could easily find more than 4 different definitions of the disease/ syndrome called RA. So maybe you search for DM patient should be 'diabetes Y/N' but 'symptom X present' AND 'blood glucose Y' etc., etc. so that you find only those DM patients that comply to your locally used definition of DM. This is also one of the bottle necks, would I blindly treat a DM patient who's diagnosed according to a different definition/ standard then I'm using? Probably not. So whether it's a boolean or a coded_text the phrase DM Y doesn't mean much, unless I know the rest of the story as well. (I make the contrast a bit 'black and white' for discussion purposes) Cheers, Stef Op 9 feb 2011, om 19:03 heeft Ian McNicoll het volgende geschreven: Interesting discussion. The big problem with DV_BOOLEAN is that it subverts the standard 'clinical statement model' used in current health informatics. e.g The patient has diabetes (DV_CODED_TEXT) ) vs. Does the patient have diabetes ? Y/N (DV_BOOLEAN). This of course complicates looking for patient with diabetes, sine we now have to run 2 different searches and the boolean variation may not be able to take advantage of the inferencing in the terminology i.e sub-types of diabetes. The other problem is when desiging archetypes, what may seem like a simple boolean, turns out to be a lot more complex when other clinical groups are involved. To take Derek's consent example. On the face of it, Consent Y/N seems like a boolean but if you look at Snomed, there are at least 30 terms below Consent status e.g. self consent, verbal consent for examination. I found similar issues when modelling other clinical findings Blood in the urine Y/N in some data capture vs. Ordinal scales +,++ etc etc in others. This starts to become very important when interoperating with other clinical groups. Null values are useful but often match poorly to the clinical terms for a particular use case. Negated questions are a further problem - what does Diabetes (no) mean - are we asserting that the patient does not have diabetes or is the negation just a way of ensuring that the question has actually been asked. We do not normally capture negations in 'clinical statement' stylwdata capture. So !!! Clinical questions are always going to be with us, and are certainly easier to use when generating GUI but they have major issues with interoperability and extensibility. My own ompinion is that we need to look at some sort of clinical variation on DV_BOOLEAN, as Koray suggested that allows the various True, False and null states to be mapped/bound to term based equivalents, as Koray has already suggested. e.g. Diabetes Y = Snomed Diabetes term Diabetes N = Exclusion of Diabetes (or perhaps just boolean N). This would have the advantage of allowing alignment with clinical statements but make it easier for GUI designers to understand how to represent the questionairre. I very rarely now use DV_BOOLEAN when modelling but agree that using DV_TEXT/CODE_TEXT is a pain to map to a checkbox/radiobutton GUI. Ian Dr Ian McNicoll office +44 (0)1536 414994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 9 February 2011 17:18, David Moner damoca at gmail.com wrote: 2011/2/9 pablo pazos pazospablo at hotmail.com I mean: when there is no data, it is taken as false, but what happen if the person who do the questionnaire do not try to make this question false? I do not agree with this. When there is no data, there is no data, neither true nor false. And the null flavour gives us the reason for that case. I think the DV_BOOLEAN is perfect as it is and if in some case it is not good for your needs, then you should use a different data type (a coded text for example). -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) ___ 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
Joint HL7 RIMBAA / OpenEHR implementers list
Dear Rene, This is good news. Great blog too. I really like the initiative to start a joint feasability project. I'm confident that there will be a outcome that will not only work for all parties involved but also creates synergy. Is it an idea that based on the presumed positive outcome of this project we go back to IHTSDO with a renewed proposal? Don't know what the HL7 involvement is at this moment, but now is the time to convince IHTSDO that they should prepare for the standards of the future and use those as the basis for their developments Cheers, Stef Op 25 jan 2011, om 09:25 heeft Rene Spronk (Ringholm) het volgende geschreven: During the HL7 WGM the HL7 RIMBAA group (software developers that use the HL7 RIM for persistence and in memory processing) met with OpenEHR implementers (mainly: representatives from Ocean Informatics). We found we have a lot in common when it comes to architectural and implementation approaches. See http://wiki.hl7.org/index.php?title=RIMBAA_201103_Agenda for minutes of that meeting (browse down a bot until you reach the minutes of the Thursday meeting) , and http://www.ringholm.com/column/HL7_openEHR_finally_cooperating.htm for a related blogpost. Representives of Ocean have indicated that they'll be present during the next HL7 WGM in Orlando, so we'll be organizing this joint implementers model again. We'd also like to invite any other implementations of OpenEHR to this meeting. Reference Model based software development - that's what we have in common as implementer communities. TTYL, -Rene ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
ISO 21090
Dear Grahame, Op 23 nov 2010, om 14:24 heeft Grahame Grieve het volgende geschreven: It appears that Tom and I may jointly develop a variant of ISO 21090, that features the same basic semantic content, but in a format that is suitable for use in systems rather than for exchange. It will describe clearly how to interoperate using 21090, but will be suited for system/case design. This is really great news. Still I think that the result of your joint effort should be adapted by representatives of the communities who are discussing on this list (and preferably some others to) and if all agree on it bring it further into the formal standardization process. Maybe would coudl see it then as a WWTA (World Wide Technical Agreement). To answer you question, important technical agreed standards should still become formal standards because, at least here in Europe, they can be incorporated in laws. Informal standards or technical agreements can't. And that's an important issue when governments are going to make (or adapt) legislation about EHR's I also wonder what the others think of this effort. People in Ed's group or the DCM people should possibly benefit from this as well or do they see that differently? Cheers, Stef
World Peace
Dear all, As Ed Hammond said it somewhere earlier in this discussion: It's like World Peace - a great idea but probably not achievable. I agree with Ed if we think along the line of ?one solution should fit all? and I also think that if we create different solutions for different purposes World Peace is achievable after all. Please let me explain. The 21090 standard is a fact, is here to stay and is not going to change (soon). As William G. said it has been a tremendous accomplishment and Graham did a hell of job in finding consensus between all parties involved. Based on the reactions of some in this list and the fact the the majority of CEN and ISO voted for it, 21090 fits it?s current purpose which is: ?provides set of data type definitions for representing and exchanging basic concepts that are commonly encountered in healthcare environments in support of information exchange in the healthcare environment? The way I see it, the main point of discussion untill now is the question: exchange between who and/or what. This is also where the solution lies. Although it isn?t stated specifically the current use of the 21090 seems to be primarily at the level of functional interoperability (? the ability of two or more systems to exchange information (so that it is human readable by the receiver) (ISO/TR 20514:2005)). I?m sure it?s intended use is also at the level of (some) semantic interoperability but allow me to make this distinction to explain the need for different solutions. What Tom and many others on the list here are striving form is (let?s say an ?advanced level? of) semantic interoperability (? the ability for information shared by systems to be understood at the level of formally defined domain concepts (so that information is computer processable by the receiving system) (ISO/TR 20514:2005)). With advanced I mean that systems can not only support but eventually take over certain critical functions in the medical process. This goes beyond the level of decision support. In in the (not so far) future also fully automated systems based on input from several parties will be created. For instance automated triage of after hours GP visits, assess whether someone can get a refill prescription, an agent that checks for medication interaction, automated screening for certain risk profiles, follow up of patients with a certain diseases, etc, etc. Whether we like it or not, systems have to support and even take over some functions of healthcare providers in order to be able to provide sufficient care 10-15 years from now. If not for that reason alone, this type of applications can (hopefully) help to improve the quality of healthcare. For instance by making personalised medicine possible at a large scale. These advanced systems are (potentially) going to decide on matters of life and death and therefore they need to be reliable in that the outcome must be correct and similar in every system that uses the same standard(s). I fully agree with Tom?s remark that this requires an engineered standard instead of one that is the result of a political process (If you know the person who would travel on a plane built by 'democracy' rather than engineering, please introduce us... )) So here?s my proposal We leave the 21090 for what it is right now and focus on a datatype standard for semantic interoperable systems to be used in critical healthcare processes. This is a new and very specific scope which not only justifies but calls for a new standard. The thing we?re going to do differently is that for the standard creation process we?re - initially - going to bypass the political process. To do so, a small group of dedicated engineers (2-3 from all parties involved/ interested, is composed. Based on the reactions on this list it should be possible to get at least engineers of HL7, DCM,13606, and openEHR involved. Preferably this should be extended with engineers from IHTSDO, NHS, the Swedish implementation group and ?.? Lets say a maximum of 20 people. The goal of this group is to create a datatype standard for semantic interoperable systems to be used in critical healthcare processes which addresses the following requirements: - a set of clean, clear core data types - a set of wrapper types designed to use the core types, optimised for messaging - other sets of wrapper types as needed, optimised for other specific purposes, e.g. storage or whatever Also the standard should be modular in order to expand it quickly and easy in the future if new use cases would require that. If all parties involved agree upon the end result, the standard will be brought to CEN/ISO to be included into the formal standardisation process. This of course would need some political work after all, since all CEN/ISO members would need to vote for this need standard in order to make it official. I?m very confident that if the standard is developed and agreed upon
ISO 21090 data types too complex?
Great, do you have a link where they can be found/seen. Cheers, Stef Op 8 nov 2010, om 21:02 heeft Williamtfgoossen at cs.com het volgende geschreven: In a message dated 8-11-2010 15:38:26 W. Europe Standard Time, thomas.beale at oceaninformatics.com writes: I have been asking HL7 since 2003 or so to show a clean model of any of the following in RIM or CDA structures: 2 or 3 sample Apgar standard 3 sample GTT (glucose tolerance test) with patient state ICU vital sign time series Tom, these are available since about that time in HL7 space. However, they where not balloted yet. William Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 ___ 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/20101108/1f167442/attachment.html
ISO 21090 data types too complex?
Dear Ed, Thanks for your clear and frank contribution to this discussion. Although I don't always agree with the boldness of Tom's remarks and I'm one of those people with 'little competence' (although I tent to think that I understand what is being engineered), I can understand his frustration as well. It's difficult if you try to reach something that you feel is being blocked just because people don't see what you're doing and as a result they choose somethings that looks sufficient today. Looking through this frustration, wouldn't you agree that an ideal international standard on datatypes should be about a set of clean, clear core data types a set of wrapper types designed to use the core types, optimised for messaging other sets of wrapper types as needed, optimised for other specific purposes, e.g. storage or whatever If no, how would your ideal standard look like? If yes, how could we go about to establish this is the near future? Cheers, Stef Op 7 nov 2010, om 01:33 heeft William E Hammond het volgende geschreven: Interesting comments. It is interesting that the ISO standard was approved by HL7, CEN and ISO. As to why we fix the problems of ISO 21090 on HL7, someone else will have to address. As far as I know, HL7 actually does not even vote on ISO standards. I must admit that I hoped at times the differences could be resolved. I guess the differences are so fundamental that we can't find a path to harmonization. Maybe some other group with the biases that we have can help resolve the situatiuon. I am interested in seeing things brought together. I think if we don't, neither of us will enjoy success at a level we would like to see. More importantly, I think we won't meet the requirements of the global HIT community without trying to find a solution to the differences. I think, and I know you don't agree, that some of the differences are matters of opi ion - a different way of doing things., I am using data types for ISO 21090 without any problems. I may be to dumb to appreciate the difficulties. I do admit that I am not using every data type. In any case, the best to you. I thnk openEHR has made major progress and is becoming an influential organization. I do enjoy some of the discussions on this list server. I am, believe it or not, learning some new things. Thanks to these discussions. Best. Looking forward to seeing you all in January. W. Ed Hammond, Ph.D. Director, Duke Center for Health Informatics Thomas Beale thomas.beale at oce aninformatics.com To openehr-technical at openehr.org Sent by: cc openehr-technical -bounces at openehr. Subject org Re: ISO 21090 data types too complex? 11/06/2010 05:36 PM Please respond to For openEHR technical discussions openehr-technica l at openehr.org Hi Ed, well since you asked ... my list of problems, from a cursory examination: The model is defined such that all data types inherit from HXIT and then ANY, which contain 7 attributes specific to HL7v3 messages. This means that any other types, such as BL (Boolean) inherits these attributes. This is a basic modelling error, since the normal approach is to separate context-specific attributes (e.g. specific to the use of data values in messages, but not other uses) into ?wrapper? classes. The practical effects of this modelling are twofold: There is not a close correspondence between the 21090 idea of ?ANY? and the typical Any/Object or other root class of most object-oriented type systems ? this name clash would have to be resolved in some way; an implementation of the 21090 data types is forced to have HL7v3 specific attributes in its base classes, and it also complicates the use of more orthodox modelling for such purposes; alternatively to produce a version of 21090 for use
ISO 21090 data types too complex?
It looks like we're getting to the heart of the matter here. What I really would like to know from the others what their opinion's on these subjects are? If it indeed turns out to be true that Tom don't understand how datatypes, RIM or data types are working, we, as the openEHR community, should ask him to shut up. If not we should find better ways to get the message across... Cheers, Stef Op 7 nov 2010, om 12:12 heeft Grahame Grieve het volgende geschreven: hi Tom . The context specific stuff is specific to HL7 only. It just doesn't apply elsewhere. not at all. And I'm surprised you still think this. HXIT is to do with capturing and managing foreign data. As is some of the II stuff. It doesn't and won't arise in an EHR system for internal data, but it will for imported data. So where it does arise is not HL7 specific. Flavors are a ISO 21090 thing. And optional - they aren't in the schema, for instance. Update mode is transactional. Almost everybody will profile it out. .. There is not a close correspondence between the 21090 idea of ?ANY? and the typical Any/Object or other root class of most object-oriented type systems ? this name clash would have to be resolved in some way; It appears I will have to keep repeating this until I am blue in the face. It is not a name clash, nor does it (or should it) correspond to a root class in any other system - it is it's own class. The fact you think this indicates that you are totally confused as to what ISO 21090 is. (Hint: look at how you modeled your own data types...) ... The modelling style seems to follow the strange HL7 obsession with non-object orientation, popularised in the RIM. which indicates that you don't understand the RIM or the data types, and how they differ. Grahame ___ 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/20101107/ff8325dc/attachment.html
Term bindings in archetypes and templates
For those of you interested in the 'problems' within Snomed as an ontology, here (http://precedings.nature.com/documents/3465/version/1) you can find a good and recent article describing them. This doesn't mean we shouldn't use Snomed, but knowing where the problems are is helpful to find solutions as Thomas already stated. Cheers, Stef Op 11 mrt 2010, om 11:06 heeft Mikael Nystr?m het volgende geschreven: Hi Michael, I agree that post-coordination is useful when mapping to SNOMED CT and it works well in many cases. However, to be able to create post-coordinated concepts the pre-coordinated building blocks have to already exist in the terminology, which are not always the case. There are sometimes also harder to reuse information mapped to post-coordinated concepts than post-coordinated concepts, because the hierarchies around the post-coordinated concepts are generally not so tailored for the post-coordinated concepts as the hierarchies around pre-coordinated concepts are. It is also only SNOMED CT and a few other terminology systems that allow post-coordination, so for the majority of terminology systems post-coordination isn't possible to use. My view is therefore still that creating archetypes and the terminology bindings in parallel is better than fist create the archetypes and afterwards add terminology bindings. Greetings, Mikael -Original Message- From: openehr-technical-bounces at chime.ucl.ac.uk [mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Michael.Lawley at csiro.au Sent: den 11 mars 2010 01:46 To: openehr-technical at chime.ucl.ac.uk Subject: Re: Term bindings in archetypes and templates Hi Mikael, You may be interested in our mapping tool, Snapper, which is designed to tackle this problem for mapping to (not from) SNOMED CT. It provides extensive support for mapping to post-coordinated expressions where single-concept maps are not possible and can be used to create unofficial extensions to SNOMED CT. More details and a short screen-cast are on our website http://aehrc.com/snapper Cheers, michael -- Dr Michael Lawley Principal Research Scientist The Australia e-Health Research Centre http://aehrc.com/ +61 7 3253 3609; 0432 832 067 Ein Fl?gel und einen Schnabel machen kein Vogel On 11/03/10 9:49 AM, Mikael Nystr?m mikael.nystrom at liu.se wrote: Thomas Beale wrote: On 10/03/2010 22:16, Mikael Nystr?m wrote: I belong to a group that, except for openEHR related research, also do research about terminology systems and terminology systems mapping. During mapping from one terminology system to another terminology system is it quite common to be unable to map properly, because the two terminology systems have divided the domain in different ways. This problem appears even when mapping to SNOMED CT, which have a broad coverage and a concept model allowing a broad set of relationships. My view is that the same problem will appear when finalized archetypes are bound to existing terminology systems. it will certainly appear. The question is: for those archetype nodes that it is useful to bind to terminology (likely to be 10% or less), how close is the match? For example, in labs, it should be nearly spot on. For anatomy, it should be pretty close. For diseases, the disease concept in an archetype will assume that it is coded in the first place by terminology, so the only problem there is mapping problems from ICD to SCT etc. I think we need to look at the actual size of the concrete problem, not its theoretical worst case. I agree that we have to wait and see how much problems we will get. That was also my reason to reply to Sebastian's e-mail which told that there is no problem to add terminology bindings after the archetypes are finalized. However, I didn't refer to theoretical worst case. I referred to actual problems that have appeared for us during both our research work and in our national SNOMED CT project in Sweden. Greetings, Mikael ___ 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
Interoperability with HL7
Op 10 feb 2010, om 11:37 heeft Gerard Freriks het volgende geschreven: It is imperative that DCM's are absolutely free to use and in the public domain. CEN/ISO and ANSI assure that with the standardisation IP rules in general. DCM's must be absolutely free from IP problems, well maintained in a formal, flexible, organisation, owned and controlled by all that use them. OpenEHR as we know it today is a private company. (See under Status: http://www.openehr.org/about/foundation.html) Hi Gerard, What has happened? For years and years you have been the initiator of many disputes between 13606/openEHR and HL7 and now all over sudden openEHR seems to have become the 'enemy'. OpenEHR is a not-for profit organisation and it's knowlegde is in the open domain. If you had Googled around a litte bit you could have found the following: A company limited by guarantee is an alternative type of incorporation used primarily for non-profit organisations that require corporate status. A guarantee company does not have a share capital, but has members who are guarantors instead of shareholders. The guarantors give an undertaking to contribute a nominal amount towards the winding up of the company in the event of a shortfall upon cessation of business. It cannot distribute its profits to its members, and is therefore eligible to apply for charitable status if necessary. So I would like you to withdraw this unfunded accusation or provide some solid facts to prove the contrary. This really doesn't help the discussion. I do like the fact that you've turned around and see opportunities to harmonize HL7, 13606 and openEHR, so let's keep working on that track. Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/113227be/attachment.html
Fwd: Interoperability with HL7
For one or another reason a part of the text in my reply is 'meshed' up when I receive it back via the mailinglist. The first sentence of my reply was intended to be: What has happened? For years and years you have been the initiator of many disputes between 13606/openEHR and HL7 and now all over sudden openEHR seems to have become the 'enemy'. I hope it shows up correctly this time. Does anybody know why/how this 'mesh-up' happens? Begin doorgestuurd bericht: Van: Stef Verlinden stef at vivici.nl Datum: 10 februari 2010 13:05:01 GMT+01:00 Aan: For openEHR technical discussions openehr-technical at chime.ucl.ac.uk Onderwerp: Antw.: Interoperability with HL7 Op 10 feb 2010, om 11:37 heeft Gerard Freriks het volgende geschreven: It is imperative that DCM's are absolutely free to use and in the public domain. CEN/ISO and ANSI assure that with the standardisation IP rules in general. DCM's must be absolutely free from IP problems, well maintained in a formal, flexible, organisation, owned and controlled by all that use them. OpenEHR as we know it today is a private company. (See under Status: http://www.openehr.org/about/foundation.html) Hi Gerard, What has happened? For years and years you have been the initiator of many disputes between 13606/openEHR and HL7 and now all over sudden openEHR seems to have become the 'enemy'. OpenEHR is a not-for profit organisation and it's knowlegde is in the open domain. If you had Googled around a litte bit you could have found the following: A company limited by guarantee is an alternative type of incorporation used primarily for non-profit organisations that require corporate status. A guarantee company does not have a share capital, but has members who are guarantors instead of shareholders. The guarantors give an undertaking to contribute a nominal amount towards the winding up of the company in the event of a shortfall upon cessation of business. It cannot distribute its profits to its members, and is therefore eligible to apply for charitable status if necessary. So I would like you to withdraw this unfunded accusation or provide some solid facts to prove the contrary. This really doesn't help the discussion. I do like the fact that you've turned around and see opportunities to harmonize HL7, 13606 and openEHR, so let's keep working on that track. Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/e433e686/attachment.html
Interoperability with HL7
Op 10 feb 2010, om 14:07 heeft Bert Verhees het volgende geschreven: It is not the juridical status of a company that makes the difference for the IP-status of something. If an organization is not-for-profit or for-profit, both can issue all kinds of IP-licenses. The company form has nothing to do with the licenses it issues I agree, but the way Gerard puts it, seems to imply it does. About the IP licenses. The OpenEHR board issued an e-mail on Okt 2nd 2099 in which they announce that: ' We have discussed the issues set out above, at length, and they cannot be quickly decided upon, safely. We view it as our role, at this stage, to publish here an interim statement of the policy issues we have identified and the direction of travel we are following, for the Foundation, which is as follows: To meet immediate needs, we are minded to publish archetypes managed at http://www.openEHR.org/knowledge from the Foundation under the Creative Commons license ? specifically the Attribute and ShareAlike (CC-BY-SA). This is the same license that Wikipedia is using. We also propose, at a minimum, that the copyright of all archetypes managed at http://www.openEHR.org/knowledge should be assigned to the Foundation. This is needed to ensure that the Foundation can give permission to others to adapt the work (see the CC license for details). We will continue to listen and consult on the wider issues discussed in this interim statement. We must align the Foundation?s approach with the requirements and plans of our partners in IHTSDO and EuroRec and with the development of the new governance framework and business plan now needed for the Foundation. We will keep the plan under close review over the period ahead, as we work with EuroRec, IHTSDO and others to fund a major experimental and clinically driven project for clinical content quality assurance, embracing archetypes and terminology. This interim statement is now on the wiki at http://www.openehr.org/wiki/display/oecom/Archetypes+-+Copyright+and+Licensing. Subject to any necessary rethinking as a Board, arising from responses we receive before December 1st 2009, we plan that it will become official openEHR Foundation policy from January 1st 2010, when a set of rules covering its implementation will also be published. We will also consider whether and in what form we might usefully propose guidelines for how copyright in archetypes might best be managed in other contexts, such as a) when managed by governments on national or regional servers, b) when managed privately by healthcare organisations, professional bodies or companies, and c) when managed experimentally, eg in research programmes.' As far as I'm aware the above has become openEHR foundation policy as of January 1st 2010. I have to admit that these changes in the IP status can't be found on the openEHR homepage at this moment. Can somebody please place the renewed 'Statement on Copyright and Licensing of Archetypes' at a prominent place at the openEHR website. Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/13682983/attachment.html
{Disarmed} Re: Interoperability with HL7
Op 1 feb 2010, om 10:33 heeft Charlie McCay het volgende geschreven: More is needed to ensure that information can be safely reused and combined. Dear Alberto, Can you please explain what this 'more' is and provide some examples for a non-technical person like myself. Cheers, Stef Op 1 feb 2010, om 10:33 heeft Charlie McCay het volgende geschreven: Alberto I would say that EHR systems based on the openEHR specification face similar interoperability challenges to to those based on other proprietary or open source architectures. I will take a step back and observe that two implementations of openEHR or any other EHR system design will not interoperate fully unless there are coherent information structures used. This is certainly true of a system as flexible as that defined by the openEHR architecture. Agreeing on a reference model (HL7 RIM, 13606, openEHR, ...) and a terminology certainly helps, but even with that agreement in place there are many ways to represent the same clinical content. More is needed to ensure that information can be safely reused and combined. Within an openEHR installation this is achieved by using a single coherent set of archetypes, much as data structures are localised in other EHR architectures. If your requirement is limited to communicating within an openEHR community, then developing and agreeing to use a suite of common archetypes and templates is sufficient. If you wish to interoperate with the broader healthcare information systems installed base, then it makes sense to work with HL7 specifications which are focused on delivering this, and broadly adopted for this purpose. For external communication of entry-level detail using HL7v3 there is a need for agreed static models (R-MIMs). These are implemented as templates (eg with CDA), or as CMETs in V3 messaging - and a corresponding sets of archetypes for 13606 or openEHR can be defined if these are what you use to configure your system. All the best Charlie -- Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel +44 1743 232278 / +44 7808 570172 skype: charliemccay linkedin:charliemccay From: Thomas Beale thomas.beale at oceaninformatics.com Organization: Ocean Informatics Reply-To: For openEHR technical discussions openehr-technical at chime.ucl.ac.uk Date: Sun, 31 Jan 2010 23:30:22 + To: openehr-technical at openehr.org Subject: Re: Interoperability with HL7 On 29/01/2010 07:41, Alberto Moreno Conde wrote: I would like to address the interoperability with the HL7 standards. As I understand it is possible to map between OpenEHR to HL7 CDA, this allows us to create systems that are based on the openEHR reference model compatible HL7. This system would be able to send HL7 v2 and HL7 v3 messages from the CDA and EHR_EXTRACTS from the OpenEHR reference model. I don't understand what consequences have that the HL7 RIM is still not fully compatible with the OpenEHR reference model if we can send messages from HL7 CDA. Is there other problems in the interoperability between HL7 and OpenEHR? I hope that Thanks Alberto Hi Alberto, In practical terms, performing mapping between HL7v2 messages and openEHR, and also CDA and openEHR is certainly possible. It takes some work - the complexity of the HL7 RIM doesn't make it that easy for CDA or other v3-based structures. In a theoretical sense, the key thing to understand is that in HL7 there is a pervasive approach of restriction-based modelling - in the RIM, the data-types, and all *MIMs. In this kind of modelling, abstract classes have numerous attributes, in theory all that would ever be needed, and descendant classes are defined as restrictions of the parents. You will have noted for example that the Act class in the RIM has 22 attributes, and the Act-relationship class 18. I won't go into the problems that this causes, but there is one other key fact to note: the RIM classes contain a mixture of domain information related attributes and message-related attributes. However, if your interest is not hand-building messages, it can be hard to see past these attributes to get a pure domain model of the concept in question, e.g. cholesterol test result, or whatever. This is one of the reasons CDA has become popular, because it is a more generic, less message-oriented RMIM than other message types. It nevertheless contains the same fine-grained (level 3) concepts as the RIM, albeit in a restricted form. At a more concrete level of analysis, you need to compare the reference models. The openEHR reference model is a standard OO style of modelling, and has been heavily influenced by the development of archetypes over the years. It now appears to accommodate most clinical models pretty naturally and has been very stable for
Meaningful use criteria
Is anybody following the current discussion in the US about the meaningful use citeri and/or is anybody actively involved? The published criteria can be found here: http://frwebgate5.access.gpo.gov/cgi-bin/PDFgate.cgi?WAISdocID=467405454267+0+2+0WAISaction=retrieve Is just scanned it very quickly and one thing stroke me, this is just a pre-definition.: 'In order for an EHR technology to be eligible for certification it must first meet the definition of a qualified electronic health record. This term will be defined by ONC in its upcoming interim final rule, and we propose to use the definition of qualified electronic health record adopted by ONC.' So it appears that the ONC final rule will set an important road ahead for the coming decades. Is anybody promoting the benifits of the 13606 standard and if not shouldn't we do that? Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100114/c750de96/attachment.html
License and copyright of archetypes
Hi Erik, I see your point and agree. My call for the -SA extension was based on the idea of reciprocity. So let's go for CC-BY. Cheers, Stef (I sended this reaction earlier but for an unknown reason only to Eric. So now for the whole group. Although I still believe in the idea of reciprocity and would like to advocate for it, a license shouldn't become a hindrance for the broad usage of openEHR archetypes and/or a 'paper tiger' as we call it in the Netherlands: don't create rules which you can't (or don't want to) follow up) Op 14 sep 2009, om 12:14 heeft Erik Sundvall het volgende geschreven: Requiring SA in addition to BY might add value or it might mostly add complications and hard-to-interpet situations regarding what a derivative work is. Is data entered using the archetype a derivative work? Is a template or screen-form based on the archetype a derivative work? Is a book using the archetype in an example a derivative work? A specialization of an archetype intended for top-secret medical research is most likely a derivative work, is that a problem or not? It is issues like these that get companies uneasy regarding using things with SA-licencing-schemes (such as GPL) in some situations. Another question is if SA is necessary in an openEHR-based health record exchange system. If you want to exchange archetyped data you're probably in most cases requested to supply the used archetype too anyway.
Documentation Desparation
+2 Stef Op 26 sep 2009, om 08:13 heeft Grahame Grieve het volgende geschreven: +1 Grahame Sent from my iPhone On Sep 25, 2009, at 6:23 PM, Koray Atalag koray at cs.auckland.ac.nz wrote: Hi All, I really appreciate the mental exercise to achieve a better documentation; however I must say I am really surprised to watch the recent discussions like this one because I wonder if we, as a community yet to solve many fundamental problems and overcome the many challenges, have enough resources to deal with this at the moment. Frankly I disagree with the need to translate all the specs and documentation into other languages at the moment - not to say that this is trivial but I don't think we are at that stage at the moment. And when we become (if ever!) a multi-million $$$ foundation then I suggest looking at how ISO or national bodies approach the multi-lingual documentation problem. While I believe in and most importantly own a couple open source projects myself, I see many from FOSS rounds getting into the pitfall of seeing software as either evil or good or having the illusion of open source as a merit by itself. That is not true...I hope we don't end up trying to FOSS everything just for the sake of the open in our prefix ;) And ?eref I don't think much people left in Turkey to bother with openEHR anyways! Cheers, -koray Seref Arikan wrote: Tom, I'd be happy to help you out, just let me know what you need me to do. I'll be putting all of the documentation into Eclipse plugins of Opereffa anyway. We can turn that task into an experiment to lay out some sort of method for transformation of documentation to other formats. Cheers On Fri, Sep 25, 2009 at 6:08 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: Unfortunately I can't make any conversion mission a top priority, but let's commit at least to an experiment which I can initiate - I will generate the 'standard as-is' XML output from one specification (say the data types) and make that available - Seref or someone else may be able to determine what rules it is following; in the meantime I can do a bit of research on what needs to be done to a FM document to make its XML output DITA based. - thomas Tim Cook wrote: Hi Seref, Thanks for your concerns and well thought out points. If you read my original posting, I didn't ask Tom to stop using Framemaker. I ask for some output in place of (or in addition to) the PDF and Framemaker formats. I'll happily accept .doc files at this point. It seems that we have a different perspective on what the sense of trust in the community is also. But that is an entirely other subject. :-) --Tim On Fri, 2009-09-25 at 11:08 +0100, Seref Arikan wrote: Dear all, I'd like to express my concerns about practical outcomes of suggested changes, changes based on potential benefits. I'd appreciate your input about the use cases we are discussing just to make sure that I get this right. First of all, translation of openEHR documentation to other languages is a very critical task, which would be quite a challenge, because we are talking about very high quality documentation, to which I keep going back quite often, mostly to find out that a point that I was missing has already been there, expressed carefully. At one point I've thought about translating the docs to Turkish, my mother tongue, and realized that not having a Framemaker licence was the least of my problems. Reflecting the same quality, and more important than that, the same semantics consistenty in other languages is a huge challange. It requires understanding of the domain, the standard, and possesion of more than ordinary control over two languages, one being English. Also, as a member of openEHR community I would not like to see translations of the specs in the wild, with no official approval or inclusion from openEHR foundation, since this can easily lead to confusing documentation on an already confusing topic, which is challanging enough to master with really good docs. I would like to know if there are efforts, or even intentions of translating this documentation to other languages, and the owners of these intentions. How many translations of the documentation will be for Spanish for example? If a person would give this task a try, due to reasons expressed above, he/she would have to possess quite a lot of time, skills and he/she would have to communicate with openEHR to make sure that the outcomes do not do harm instead of doing good. My opinion is, this would be an effort linked to an institutuion like a university, or a government agency, working with openEHR. I can't see people working in their homes/offices on their own, doing this whole work, and if there are people like this, I really want to know them. The
Concept Overload Caution
Hi Heath, I complety agree with you. Let's all do what we're best at. What I would like to add to your proposal is some feedback (both ways) so doctors and technicians can learn from eachother. Rather than de- empowering the one or the other I think we should team up to create a properly working system that really adds value for the citizens/ patient who are the subject of this all. Also as I clinician I really would like an understandable (at technical lay-mans level) manual with clear examples who things can work and why some solutions shoudl be avoided. Maybe some best- practices of whatever you like to call that Cheers, Stef Op 23 jun 2009, om 02:15 heeft Heath Frankel het volgende geschreven: Hi Tim, Thank you for your post, I complete agree. Like you I am not a clinician and feel that I am rocking the establishment of openEHR and the principles of Archetypes by saying this, but I strongly believe that we need to have a technical review process of archetypes before they are published. What I am looking to review is not related to the clinical content, but the patterns used to represent that clinical content. In particular, I would looking to ensure that we have single concept representation, loose coupling, reusability, appropriate use of specialisation, and most importantly I believe, appropriate structures to support querying. These are all good object-oriented (or general software) design principles that technicians are trained to be better at then clinicians. As part of the archetype governance and publishing process, I would like to see a technical review process. I realise I am writing to a group of technicians on this list and this is probably a topic for the clinical list, but I think there probably are enough clinicians on this technical list to knock me around if they feel that I am rocking it too hard. Please understand that I not trying to re-empower the technician, I am simply looking for good quality knowledge artefacts and believe this a process that is missing in the current archetype development process. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Tim Cook Sent: Wednesday, 3 June 2009 9:59 AM To: For openEHR technical discussions Subject: Concept Overload Caution Hi All, The past 3 or 4 subjects on this list takes me back to conversations that we had before (maybe several years ago?) when we were discussing slots and links. Maybe they were here maybe they were on the ARB list. I do not recall now. But my feeling in both of these areas are that there is a tendency for archetype developers to create archetypes that are more than one clinical concept. IIRC, that is about the time that templates were being thought of/designed to alleviate the pressure on archetypes to serve everyone, everywhere. As Heath has just mentioned, templates are the better place for this type of grouping. They tend to provide that ability to be more localized. Remember that when you are creating or reusing archetypes that they should be universally reusable. If they are not, then they do not meet the basic requirement of being a single clinical concept. This is fundamental to openEHR being future proof. The misuse of slots and probably any use of links in a particular archetype; IMHO is a very bad thing and will lead us down the road that we see with data model centric systems as opposed to our information model. While I am not a clinician nor a lab tech I do ask those of you creating archetypes to review the fundamental principles of archetypes and templates. Then think twice before publishing an artifact. From what I am reading I think that there is becoming a tendency to put too much runtime functionality into what is supposed to be singular data items. My 2 cents/pence/centavos --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* ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Announcement of the release of Opereffa by the openEHR Foundation
Dear Tony, David and Seref, Congratulations to you (and to the openEHR community). This is truly very good news, great work and a major milestone for the openEHR community. I'm confident that this will boost many efforts that are out there a helps to focus our energy as well as to show the outside world what really can be done with openEHR. Cheers, Stef Op 10 jun 2009, om 10:11 heeft Thomas Beale het volgende geschreven: Announcement of the release of Opereffa by the openEHR Foundation The openEHR Foundation is pleased to announce the early release of Opereffa ? openEHR REFerence Framework and Application, under development at UCL. As healthcare systems are under increasing pressure, internationally, they are exploring improvements in health information systems, as a key way to survive and thrive in the 21st century. As a means to support these efforts, members now working under the umbrella of the openEHR Foundation have been developing and implementing open specifications for an Electronic Health Record for many years, and these have since formed the basis of the ISO and CEN 13606 archetype standard. In response to a recent exploration of the openEHR international clinical community?s requirements, by the openEHR Clinical Review Board Chair Dr Tony Shannon, an open source clinical reference application, focused on early clinical benefit and usability, was deemed to be an important next step for the community. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090610/2b525726/attachment.html
Reverse_relationships
I've been working through the demographic AT's that were provided by
Sergio. It's probably due to my lack of technical knowlegde but I
can't find where reverse_relationships are defined in these
archetypes. Or it must be in openEHR-DEMOGRAPHIC-
ROLE.health_consumer.v1 under:
relationships matches {
PARTY_RELATIONSHIP[at0010]
matches {-- relationship between a health consumer and a
third-party payer
details matches { --
we gaan er klaarblijkelijk vanuit dat er maar 1 relatie kan bestaan
met zorgverzekeraar
allow_archetype CLUSTER[at0011]matches { -- identifier
used in the relationship
include
archetype_id
/value matches {/([a-zA-Z0-9_]+)*(identifier)\.v1/}
In that case I probably don't understand how this works. From what I
read in the demographic_im there shoudl be by references to the
HIER_OBJECT_IDs
Can somebody help me to understand this and possible explain how to
create such an reverse_relationship in an AT.
Cheers,
Stef
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090507/b729be28/attachment.html
2009 and beyond
Dear Tony, You're the new chair now for almost 6 months. Can you provide us with some views/ outlooks of what is going to happen in 2009 and beyond. Are there any plans/ ideas to set up an official (top level?) archetype repository so that one unified set of archetypes is being created. If such a thing isn't installed quickly we run into a big risk that everbody starts using their 'home brewed' archetypes. In that case interoperability will be lost and if one wants to create that we have to harmonise/ map all those archetypes a few years from now. I can't imagine that's the idea behind openEHR. Cheers, Stef
is OpenEHR.org down?
Here it's also still down Op 12 jan 2009, om 08:38 heeft Seref Arikan het volgende geschreven: Unfortunately that is not the case for me at the moment. Still down? Best Seref On Sun, Jan 11, 2009 at 8:27 PM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: It is back working now Ian On 1/11/09, Stef Verlinden stef at vivici.nl wrote: It seems down indeed. Cheers, Stef Op 11 jan 2009, om 14:34 heeft Seref Arikan het volgende geschreven: Hi there, I can not access to openehr.org from Turkey at the moment, and I've also tried a proxy in USA. Is it me only, or is the site down? Kind Regards Seref ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at mcmi.co.uk Clinical Analyst Ocean Informatics ian.mcnicoll at oceaninformatics.com BCS Primary Health Care Specialist Group www.phcsg.org ___ 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/20090112/59914fbe/attachment.html
is OpenEHR.org down?
It seems down indeed. Cheers, Stef Op 11 jan 2009, om 14:34 heeft Seref Arikan het volgende geschreven: Hi there, I can not access to openehr.org from Turkey at the moment, and I've also tried a proxy in USA. Is it me only, or is the site down? Kind Regards Seref ___ 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/20090111/f4e50f98/attachment.html
Insight into the choices to be made in standards for the electronic exchange of health record information
Thomas. Op 7-okt-2008, om 17:10 heeft Thomas Beale het volgende geschreven: Governments need to understand these realities, or they will continue to find it difficult to see how to apply any of the competing standards available today. I have to say that I don't find this report particularly helpful, because it gives very little in the way of really solid advice on how governments should move forward. Although I agree with you, you also know where we're coming from: a situation where two camps dug in deep, proclaimed that their solution was the best and didn't want to look over the fence. This is a consensus document generated by all parties involved and as such a big step ahead. Another thing is that this document is about the interational EHRCOM standard 13606 and not about all the fantastic things we could do once openEHR derived commercial solutions finally become widely available. Since openEHR isn't an international standard, nor widely implemented as a commercially product, so that people can see it's beneifits, your remarks seem academic. Furthermore it's intended audience is the people at CEN and ISO, not governments. For that purpose we'll try to create a less technical document. I completely agree with your remark that Governments need to understand these realities. Again I'll invite everbody to come up with clear examples, proof and/or bussiness models, which are understandable for decission makers (technical lay-man) so they can get a good understanding of these realities and the consequences of their choices. So far the discussion is only accesible for the happy few who have the time, enthousiams and (some degree of:-)) technical understanding to dug in deep. To convince an average decission maker you have a couple of minutes. If we (as the openEHR community) aren't capable of selling 'our' product to these decission makers in an understandable and concise manner, we still have the best product in the world but nobody will use it. So far I haven't seen any document/ example/ bussiness case that can convince a decission maker/ goverment why they should consider using openEHR. As you might know this is what we call the Dutch or Philips syndrome over here: Back in the eighties Philips created an brillant new and innovative product: a videoplayer called Video 2000. Since everybody was convinced that such an superior system would sell itself not much attention was paid to marketing. At the same time a videoplayer which was on all fronts inferior to the Philips player was developped: the VHS player. Since it's producers knew that marketing was key, they promoted the product as aggresively as they could and with great succes. Since for the end user the VHS already was a big step forward (untill then there was no way to record and play video at home) and all they heard about was VHS they bought into that system and took over the market. Any simllarities here? Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081008/e37f041b/attachment.html
Insight into the choices to be made in standards for the electronic exchange of health record information
Eric, To be clear, it is not my document. It is the document created by the members of the Dutch mirror group on, to which I've contributed. Like I stated it's a consensus document which is great but also created many boundaries to the extend we could extend the discussion. So don't shoot the messenger. Op 8-okt-2008, om 11:16 heeft Eric Browne het volgende geschreven: Stef, I don't question your intentions, but I definitely question the value of such a document in helping the discussions at CEN and ISO level. I can only see it confusing the already muddied waters. You simply cannot advance the cause of harmonisation of standards, or choosing between standards, by dumbing down the issues to such an extent! I'm sorry, Stef, if my response seems brutally rude, but I'm sure that the level of debate at CEN and ISO must be more sophisticated than the simplistic suggestions embodied in your document. If not then we are centuries away from the sort of IT-enabled healthcare systems that many of us can imagine. I'm sorry to disturb your sweet dreams, but this is the level of debate that takes place at least at NEN. I'm not aware of more sophisticated discussions at the level of CEN of ISO. Please feel free to post your brilliant contribution to this debate so we can educate the less sophisticated among us. And as for your analogy regarding the Dutch Syndrome, we are not talking about marketing a product, we are talking about standards and specifications for e-health interoperability, decision support and much more, that affect our own health and the health of others. Please reconsider taking your document to those meetings. Again it's not my document and not my decission and if you had taken the time to read my mail properly you could have known that. Luckely the Istanbul meeting is in 2 weeks so there is plenty of time to come up with an alternative document in which al of your brilliant analyses are put togehter. I really encourage you to do so. Cheers, Stef regards, eric browne On 08/10/2008, at 7:05 PM, Stef Verlinden wrote: Thomas. Op 7-okt-2008, om 17:10 heeft Thomas Beale het volgende geschreven: Governments need to understand these realities, or they will continue to find it difficult to see how to apply any of the competing standards available today. I have to say that I don't find this report particularly helpful, because it gives very little in the way of really solid advice on how governments should move forward. Although I agree with you, you also know where we're coming from: a situation where two camps dug in deep, proclaimed that their solution was the best and didn't want to look over the fence. This is a consensus document generated by all parties involved and as such a big step ahead. Another thing is that this document is about the interational EHRCOM standard 13606 and not about all the fantastic things we could do once openEHR derived commercial solutions finally become widely available. Since openEHR isn't an international standard, nor widely implemented as a commercially product, so that people can see it's beneifits, your remarks seem academic. Furthermore it's intended audience is the people at CEN and ISO, not governments. For that purpose we'll try to create a less technical document. I completely agree with your remark that Governments need to understand these realities. Again I'll invite everbody to come up with clear examples, proof and/or bussiness models, which are understandable for decission makers (technical lay-man) so they can get a good understanding of these realities and the consequences of their choices. So far the discussion is only accesible for the happy few who have the time, enthousiams and (some degree of:-)) technical understanding to dug in deep. To convince an average decission maker you have a couple of minutes. If we (as the openEHR community) aren't capable of selling 'our' product to these decission makers in an understandable and concise manner, we still have the best product in the world but nobody will use it. So far I haven't seen any document/ example/ bussiness case that can convince a decission maker/ goverment why they should consider using openEHR. As you might know this is what we call the Dutch or Philips syndrome over here: Back in the eighties Philips created an brillant new and innovative product: a videoplayer called Video 2000. Since everybody was convinced that such an superior system would sell itself not much attention was paid to marketing. At the same time a videoplayer which was on all fronts inferior to the Philips player was developped: the VHS player. Since it's producers knew that marketing was key, they promoted the product as aggresively as they could and with great succes. Since for the end user the VHS already was a big step forward (untill then there was no way to record and play video at home) and all they heard about
Question on the role of EHR reference models for achieving functional interoperability
Dear Georg, Op 24-jun-2008, om 12:16 heeft Georg Duftschmid het volgende geschreven: I am now wondering why an EHR reference model is seen to be REQUIRED for achieving functional interoperability. If I exchange bare PDF-documents (without any describing metadata) between two EHR systems, then I would say there is a good chance that these docs are readable by a human receiver and thus functional interoperability should be achieved although clearly an EHR reference model is not used. Theoretically you're right; there is a good change that these docs are readable by human. The real question is: are these usable? Maybe such documents are usable between two health care providers who know and trust each-other. But now I receive such a document from somebody I don't/ superficially know. Am I willing to use (potentially critical) information in the treatment of my patient without knowing the proper context. By doing so I'll take over the responsibility. So if now my patient dies based on wrong interpretation of the incomplete information I'm liable for the death of that patient So I would never use that information and do everything all over again. Why shouldn't I, I'm getting paid for this double work as well (as least here in the Netherlands this holds true and this is what we call 'perverse incentives'). Thing is that if we leave room to doubt the quality of the information and/or are not able to create insight in the responsibilities and the transfer thereof, people won't use it. In that case what's the use of an EHR in the first place? Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080624/468ec8fc/attachment.html
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
openEHR Querying specifications
I'm not a technical person but to me it seems very cumbersome if such 'differences' could exist between 2 versions of the same archetypes. This would mean that for every query one has to go into detail of every version of that AT which could mean al lot of work. To my understanding versions of AT's should be 'backward compatible'. One can only add (and maybe remove) items, but never rename an existing item. Only then a lot of unnecessary work for 'query-makers' can be avoided. Is this assumption indeed correct? Cheers, Stef Op 3-jun-2008, om 23:26 heeft Mikael Nystr?m het volgende geschreven: I disagree with Rong. If for example the change between the first and second version is a change in a position value set from ?sitting?, ?standing? and ?other? to ?sitting?, ?standing?, ?lying? and ?other?. If then a query is written for the first version of the archetype searching for all cases where the position is ?not sitting? and ?not standing? the query will search for the position ?other? and return a correct answer. If we implement Rong?s suggestion the query will work also with the second version of the archetype, but it will return another answer than the intended, namely the cases where the position is ?not sitting? and ?not standing? and ?not lying? instead of the intended ?not sitting? and ?not standing?. I therefore think that excluding the version information can result in a mess. /Micke From: openehr-technical-bounces at openehr.org [mailto:openehr- technical-bounces at openehr.org] On Behalf Of Rong Chen Sent: den 3 juni 2008 22:54 To: For openEHR technical discussions Subject: Re: openEHR Querying specifications I suspect changes between version could potentially break the paths in WHERE clause. So maybe the version information isn't significant here since either the path works and the criteria are checked or the path doesn't work and fails silently. /Rong On Tue, Jun 3, 2008 at 10:36 PM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Fair point. Perhaps AQL should support ranges of version numbers to simplify the query as in many cases the query will not be affected by a structrural change to the archetype e.g. FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN 1.5 AND 2] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v [=1] WHERE ( obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/ value = 140 Versions and revisions would need to be handled. Ian 2008/6/3 Greg Caulton caultonpos at gmail.com: -- Message: 2 Date: Tue, 03 Jun 2008 16:39:37 +0100 From: Thomas Beale thomas.beale at oceaninformatics.com Subject: openEHR Querying specifications To: Openehr-Technical openehr-technical at openehr.org Message-ID: 484565B9.6030805 at oceaninformatics.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed The current material is therefore intended as a resource for discussion and definition of a query language for openEHR. A team can be defined after sufficient time for the community to react to this material and determine if it makes sense to use AQL as the basis or to seek other solutions or candidates. - thomas beale Perhaps this has been answered but as the archetypes change version is it expected that the AQL will need to keep up with that - I assume our historic data would be specific to the archetype version - not 'upgraded' ? i.e. after v1: FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] WHERE obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/ value/value = 140 after v2: FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] CONTAINS OBSERVATION obs2 [openEHR-EHR- OBSERVATION.blood_pressure.v2] WHERE ( obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/ value = 140 OR obs2/data[at0001]/events[at0006]/data[at0003]/items [at0004]/value/value = 140 ) not sure if that is exactly right. thanks! Greg http://www.patientos.org ___ 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 ?
openEHR Querying specifications
Op 4-jun-2008, om 10:23 heeft Thomas Beale het volgende geschreven: I hope this clarifies things Absolutely, thanks. Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080604/9103ac24/attachment.html
MIE-2008
Hi all, Here's my positive reaction:-). We started some discussion around this topic back in November. One of the other items we discussed then was a place for 'openEHR' presentations that could be used by others under a common creative (or other) license. Although I can find several presentations under 'recently updated' I would expect those to be found under education. This might also be the place for the pages about the past, future and eventually the openEHR exclusive conference. Also this could be a place for all publications available. I know that publications can be reached directly form the home page under resources, but I think these should (also) be present in the Wiki section. The link directly under resources only reveals the 3 theses about workflow. There is another link under resources/ getting started and then under 'I want to - see the publication pages' (where probably the other publications could be found) but this link is dead. Having all this together under the educationsection in Wiki might provide an easier entrance for those who wants to be educated about openEHR. Cheers, Stef Op 30-mei-2008, om 11:48 heeft Thomas Beale het volgende geschreven: Can we have reactions from a few more people - if the response is positive, I will organise the conference material onto the wiki. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080530/da08585e/attachment.html
{Disarmed} Comparison of EHR models
Dear all, Recently an article by Bernd Blobel was published in the Dutch HL7 magazine (Dec 07 issue) in which he compares the different EHR models: openEHR, HL7v3, EN/ISO 13606 and CCR. Robert Stegwee, the chair of HL7.nl, kindly translates this article in Dutch, which unfortunately makes it unsuitable for distribution outside the Netherlands I?ve tried to ask Bernd Blobel to share the original text of this article (which is hopefully in English), so that the openEHR community also can take notice of it. I haven?t received an answer yet. I won?t translate the whole article back to English (and I still hope that Dr. Blobel will share the original article), but for the sake of discussion I would like already to point out a few things that ?triggered? me. From what I understand Blobel claims that all the paradigms for an advanced EHR architecture were, already back in the nineties, defined in the context of the Generic Component Model (GCM) (no reference provided). In the article he states that the GCM provides a service oriented, model driven system architecture for the development of a sustainable and semantic interoperable EHR systems. The GCM provides a multi-model approach for EHR architectures, system development and implementations by the simplification of the system description by means of: - transparent domain management, - the composition and decomposition of the system components - the views from the different angles on the system (amongst which thorough modelling of business models As a result the GCM provides reference architecture for analysing, designing en implementation of EHR architectures, as well as a tool for the development of migration strategies (Educational challenges of health information systems? interoperability. B. Blobel, Methods Inf Med 2007; 46 p.52-56) Although I can?t assess the article fully on it?s merits, the idea of a theoretical ?meta? reference architecture for the future which can be used for the purposes above seems appealing, both for further improvement of the openEHR architecture as well as for the future harmonisation of HL7 en openEHR in a common (EN/ISO 13606 derived?) internationally accepted EHR standard. So my first question is: Is the GCM to be seen as a theoretical ?meta? reference architecture, which can be used as a guideline for future developments? If the answer is no, why not? Further in the article Blobel compares GEHR against the GCM. Although the header of this section mentions the openEHR foundation, he consistently talks about GEHR and the GEHR project (http:www.gehr.org). The URL for GEHR links to a site, which has to do with different aspects of healthcare than we?re generally talking aboutJ). Also when Blobel talks about ADL he refers to a URL that doesn?t exist anymore (http://www.deepthought.com.au/) and most certainly it wouldn?t have linked to the latest version of the ADL So my second question is: is Blobel, when making his comparison, referring to the latest versions of the reference architecture and ADL as recently developed within the openEHR community? Blobel?s conclusion of comparing GEHR to the GCM, is that GEHR limits itself to the structural aspects of the knowledge components and doesn?t comprise behavioural aspects. Also it isn?t possible, due to the lack of specified rules, to aggregate archetypes. Instead they have to be replaced by more complex archetypes. More generally the GEHR approach has some essential shortcomings at the mathematical, system theoretical and informatics levels. These shortcomings have to be addressed in the future. In the discussion en conclusion section Blobel adds to this: that within the EN/ISO 13606 approach, although almost complete as far as semantic interoperability concerns, a lot of shortcomings and inconsistencies have to be solved. As example: the issue of structural composition and decomposition, as well as the modelling of business processes is not solved well. Personally I think that such statements should be underpinned with arguments/ scientific proof and/or examples or at least a reference to a properly peer reviewed article that does so. I would like to invite Blobel (and others if they feel obliged to) to provide these scientifically valid facts to underpin these statement, so we can have a proper discussion. This type of ?review? statements creates confusion, which hinders any serious discussion about future developments and harmonisation. It also undermines the (in my opinion) otherwise good intention of the article as a whole. My third and last question to the community is: are these conclusions (if applicable to the current version of openEHR) valid and if yes how can we address those issues? Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL:
Antw: Re: Compact XML format...?
Op 24-nov-2007, om 7:45 heeft Williamtfgoossen at cs.com het volgende geschreven: V3 has no various implementations, Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog (http://hl7-watch.blogspot.com/, the text is also underneath). Probably I don't understand it correctly, so if you could enlighten me that would be very helpful. I think that we all agree that a good standard should have only one implementation Cheers, Stef --- The Dialects of RIM The latest Minutes of Evidence of the House of Commons Select Committee on Health, on the UK National Programme for IT, contain this comment from Richard Granger: In terms of the core Spine infrastructure, there was some mythology in the Health Informatics Community that the standards existed, HL7 was mature, and so forth. That was completely untrue. Dr Granger goes on: We have had to put an awful lot of effort into specifying the standards for messages, around demographics, around booking, around prescriptions, and then the software that BT have built with a number of sub-contractors is brand new software that has been custom-built for the NHS; so that is high-risk, new build software. There was no other way of doing it. I am very pleased a number of other jurisdictions are getting very interested in using that. He thereby inadvertently touches on another issue currently causing concern in HL7 circles. The HL7 Reference Information Model or 'RIM' was, we will remember, introduced as the solution to the problems created by the appearance of multiple dialects in earlier versions of the HL7 standard. HL7 would prevent the appearance of dialect versions by enforcing conformity to the RIM. Now, however, it is becoming increasingly clear that the RIM itself exists in multiple dialects. This is more than just a problem of successive, incremental improvements. As the RIM Document Editorial Assessment from 8 June 2007 points out: ... the 2006 Normative Edition contains a RIM document based on the last balloted RIM [from 2003]: this gap creates the opportunity for conceptual conflict between the document and current practice. A reader must choose between a normative edition of the RIM published for ANSI, which contains nothing extraneous but is out of date; an extract of the current RIM as maintained by MnM, which will be the most up-to-date, but which is not readily available to the membership at large; or, which is most probable, the RIM document published in the Normative Edition, which both contains extraneous information and is out of date. It seems, in fact, that we have at least: 1. the version of the RIM adopted by ISO as an international standard 2. the balloted RIM document that describes those parts of the RIM designated as 'normative', the latest (and still current) version of which, it seems, dates back to June 2003 3. an ANSI publication based on 2. 4. a CEN Standard EN 14822-1:2005 Health informatics - General purpose information components - Part 1: Overview (see also CEN Standard EN 14720-1:2005), based on 3. 5. the 'living' RIM UML model (regularly updated through harmonization) as it exists at any given stage. This RIM contains content that existed at the time of balloting in 2003 but was not then balloted, together with four years worth of cumulated changes. Some of this material is, I am told, intended to be balloted in the future; some (e.g. in CoreInfrastructure subject area) is not. 6. an idealized 'frozen' version consisting of those parts of 5. which have, at any given stage, passed through the process of harmonization, 7. the UK rebuild. As I understand matters (and as always this understanding may be for various reasons imperfect) the RIM documentation included in any publication of the V3 standard more recent than 2003 should be based on the latest working version of the model as maintained by the Modeling and Methodology (MnM) committee. The publication label ?Normative Edition? may cause confusion, however, if it is taken by the reader as suggesting that the contents so labeled are all normative (though this issue should be addressed in the relevant document preface). -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071124/573e33f8/attachment.html
Antw: Re: Antw: Re: Compact XML format...?
Op 24-nov-2007, om 17:14 heeft b.cohen het volgende geschreven: No. A good standard should ensure that all implementations that satisfy it are mutually interoperable (see, for example, the Whitworth stanard for nuts and bolts!). This requires that: 1. the standard include the the tests that supposdly conformant implementation must pass; 2. that test be necessary and sufficent to guarantee compliance; and 3. Proven compliance to the standard be necessary and sufficient to guarantee interoperability. I agree. I guess I should have written 'a good standard' should have only one version that is used by all who underwrite that standard. Of course it must comply to these 3 requirements above One way to do this is to for the standard to overdetermine implementation to such an extent that exactly one implementation satisfy it. This is how 'de facto standards' work. But I was of the impression that that was not the intention of the international health care community. Am I wrong? Can you please elaborate on this statement? My feeling is that your right but don't know what you mean exactly. As far as I know there are at least 3 different openEHR implementations on 3 different software platforms (Eiffel, .net and Java (and soon one on Ruby)), and these should be able to communicate seamlessly. So it seems that openEHR meets at least the first 2 the requirements and, if I'm correct, complying to the third is well on it's way Cheers, Stef Quoting Williamtfgoossen at cs.com: In een bericht met de datum 24-11-2007 8:30:05 West-Europa (standaardtijd), schrijft stef at vivici.nl: Op 24-nov-2007, om 7:45 heeft A HREF=mailto:Williamtfgoossen at cs.comWilliamtfgoossen at cs.com/A het volgende geschreven: Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog (A HREF=http://hl7-watch.blogspot.com/;http://hl7- watch.blogspot.com/A/, the text is also underneath). Probably I don't understand it correctly, so if you could enlighten me that would be very helpful. I think that we all agree that a good standard should have only one implementation Cheers, Stef Hi Stef, Yes, here you have a point! Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 /HTML -- __ Prof Bernard Cohen, Dept of Comp Sc, City Univ, Northampton Sq. London EC1V 0HB tel: ++44-20-7040-8448 fax: ++44-20-7040-8587 b.cohen at city.ac.uk WWW: http://www.soi.city.ac.uk/~bernie Patterns lively of the things rehearsed This message was sent using IMP, the Internet Messaging Program. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Multiple parents and max number of nested specialized archetypes?
ah - 'data quality' in other words - i.e. markers / meta-data relating to the data capture from the source, not the integrity of the data as represented on the openEHR system? I would like to expand that to data quality assurance. How can one objectively and according to locally accepted standards establish that data is of good quality, i.e. (re)usable, or should be rejected/ ignored. IMHO this is one of the crucial points for a functional EHR. What's the use of a centralized system to store and retrieve semantically interoperable data if the data is of poor/unknown quality. It also has a legal aspect. When one uses data provided by a third party one also takes over/ shares responsibility from/with that third party if one willingly accept data of poor quality. My guess is that not many people want to do that. Cheers, Stef
Hidden reference model stuff in template
Hi Thio, Thanks for this excellent explanation. Although it remains a steep learning curve for a 'non-technical' person, it certainly provides a better insight in this 'tough' material. One last remark to explain my question. I while ago Thomas Beale demonstrated the OI template builder, which is a really great tool. From what I understood this template builder also can be used as a GUI designer and that's where my interest lies. Thing is that templates, as you stated, further constrain and bundle several archetypes to fit a certain organisations data entry needs. My point is that since the 'hidden classes' aren't present in the originating archetype(s), there also aren't present in a GUI constructed with this template builder. Therefore such a GUI lacks certain 'essential' data entry classes/fields (for instance 'date and time of measurement). You can also see this in the 'example templates' made for/by the NHS- UK and which can be found in the dev-uk-nhs part of the archetype database. So if you look for instance at the 'bloodpressure template (Archetype Id openEHR-EHR-OBSERVATION.blood_pressure.v1 Template ID945c2617- dc89-4c28-94cf-43ee46c1ecb0), you'll only see the data classes/fields which where archetyped but none of the 'hidden' data classes/field (such date/time of measurement but also performer of committer). These are typical examples of data I would like to present in and/or enter via a GUI. So I guess a template builder isn't suitable for creating GUI's after all (or I've misunderstood this in the first place). Thanks again, Stef Op 31-mei-2007, om 1:50 heeft Thilo Schuler het volgende geschreven: Hi Stef, I have followed the thread and I will try to provide some hopefully useful hints. I will start with the central idea, the two-model-approach, and will try to cover your questions after that: - Archetypes are a way of constraining and plug-and-playing (LEGO principle) a relatively limited number of generic reference model classes of the reference model, that are expected to stay stable over a long period of time. In that way the multitude of quickly changing medical concepts (the medical knowledge) can be expressed and adapted to the current needs, while the building blocks (the reference model classes) stay the same. One big advantage of this approach is that software can be developed based on the reference model without knowing the archetypes in advance (future proof systems). - Analogy: Reference model classes are the LEGO bricks, Archetypes are the LEGO construction plans - The constraining rules (grammar) of *all* archetypes (or more precisely archetype instances) are defined in the archetype model. That is where the name two-model-approach came from: firstly the reference model and secondly the archetype model. - Every archetype (e.g. for blood pressure) is an instance of the archetype model. There could be many notations invented to express this archetype model. They only have to support the full semantics of the archetype model. Of all the theoretically possible notations the archetype editor currently supports ADL and can also transform the archetype into an XML version. - Every piece of medical information (the blood pressure values of person X in simple case) is a bundle of several reference class instances with the attributes set to certain values (to reflect the state of the patient X). The archetype or a combination of archetypes define(s) which classes, how many of them and what combination are in the bundle. Further more it can define things like value ranges for reference class attributes. Like archetyeps hese bundles could also be expressed in several formats, but today mostly XML is used (this is meant when Sam talks about data). - So don't confuse an XML data bundle (validated by the reference model schema) with an archetype expressed in XML. - In a message etc you would send the XML data NOT (!) the XML archetype that the archetype editor can output. Although there are references to the archetypes (that where used during creating) in the data. So the receiving system of the message can also retrieve the archetypes from an archetype server to add meaning to the data. - An archetype can validate (during creation or after reception) that a data bundle conforms to the concept that the archetype describes. So an archetype is a schema of a particular medical concept. Actually the XML schema language was evaluated as a means of expressing archetypes but was found to be not expressive enough. Therefore ADL has been invented. - As it was mentioned before (and as you correctly named hidden reference model stuff) archetypes only contain the constraints on the reference model which FURTHER constrain what is automatically by the reference modle. So if the a reference model class has an attribute of a date type and the archetype doesn't have a further constraint on
Hidden reference model stuff in template
Maybe this question should be asked on the technical mailing list, since there's no reaction on the clinical list:-) Cheers, Stef Begin doorgestuurd bericht: Van: Stef Verlinden stef at vivici.nl Datum: 24 mei 2007 12:00:43 GMT+02:00 Aan: For openEHR clinical discussions openehr-clinical at openehr.org Onderwerp: Antw.: Point in time 2 Great. Does this also mean that this 'hidden' reference model stuff will/can be a part of a template? From my point of view I would like to 'control' (view and/or enter) thing as date/time of measurement via a template. Another question related to that. The way I think to understand it (as a non-technical person:-) ) we can use the XML message's created by the archetype editor to display and post data to and from a UI/ website. But here again, this XML message comprises only the classes that are created in the archetype but not the 'hidden' stuff. Is there an 'overhead' XML message in which the 'specific' AT XML message can be embedded/nested so one has access to all available data? Cheers, Stef Op 23-mei-2007, om 7:01 heeft Thomas Beale het volgende geschreven: Erik Sundvall wrote: Hi! On 5/22/07, Heather Leslie heather.leslie at oceaninformatics.biz wrote: Perhaps the apparently 'hidden' reference model stuff should perhaps even be displayed, in an uneditable format, in the Archetype Editor and Template Designer - to make this design process more transparent and help bridge the clinical/technical divide just a little. This very much matches my point of view. Ideally archetype editors etc should be delivered with a built in mini-EHR system for simple testing purposes (security, scalability etc would not be in focus then). I think such a solution will come from somewhere eventually. I'd love provide something like that in the LiU Archetype Editor. I wish we had enough time and resources to implement that, currently we have to focus on other more urgent things. We do have engineering students doing master thesis work around openEHR-based GUIs though and with some luck that might provide some parts of the suggested solution. I agree that we need this kind of functionality; it will be implemented fairly soon in the ADL workbench and Archetype Editor. - thomas ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070530/1b36b5e5/attachment.html
