CEN 13606
hi Andrew I can comment about the datatypes not ready for 'prime time'.. two that immediately came to my attention were the ED support type that has a compulsory language attribute (which means what for a photo?) and URI reference? Maybe the UML diagram is wrong or something but it seems to indicate that both of them compulsory, when surely they have to be optional attributes? both are optional. (I have just read it again, and in their defence, it does say they are waiting for a new datatypes standard to be published yes, there will be something new, though it is not clear yet exactly what that will be so perhaps they have not looked too much at this area).. But even the examples seem confused.. annex C has an 'informative' sample ehr_system.extension = Whittington ehr_system.assigningAuthorityName = NHS ehr_system.valid_time = 1/1/1990 - 1/1/3000 ehr_system.root.oid = 9876543211 agree the valid_time is confused and confusing Grahame ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN 13606
Dear Andrew, There is a very substantial overlap between OpenEHR and EN13606. Both technically and personally. But there are differences. EN13606 EHRcom is the result of an European/Australian consensus process and can not be equated with OpenEHR. EN13606 can be used to map to legacy systems and interact with OpenEHR conformant systems. OpenEHR is a much richer specification that can be used to produce an EHR-system with real plug-and-play semantic interoperability. Within the framework of OpenEHR it is (will be) possible to use the CEN EHRcom extract. For all practical purposes I consider OpenEHR as a specific implementation specification of EN13606 with some important additional features. My advice is to use OpenEHR as an implementable specification and make and use archetypes derived from OpenEHR. The status of EN13606 EHRcom is that the parts 1,2,3 and 4 are stable. Part 1 is final and will be published soon, I expect. Parts 2,3 and 4 will be voted on soon and published next year. It is expected that soon ISO will adopt these standards as well. Your technical comments I will refer to Dipak Kalra the task force leader. ADL and part 2 of the EN13606 are identical. Gerard Freriks -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 3-nov-2006, at 10:27, Andrew Patterson wrote: Apologies that this is perhaps not the right forum, but I sense there is a fair crossover between the CEN and openehr communities so I thought this might reach the right ears.. I have been perusing the draft cen 13606-1 specification in my exploration of all things openehr related (given the large overlap in ideas.. two level modelling etc). I was wondering if anyone had any ADL archetypes based on the 13606-1 reference model? I am going to hand craft some as an experiment but would love some that are more clinically valid than my idle musings.. On related notes - I do not normally have any access to cen materials and am completely in the dark as to the whole cen standards process, but I take it that 13606-1 is in draft mode, awaiting a vote on acceptance? From my brief reading, it seems not ready for 'prime time'.. two that immediately came to my attention were the ED support type that has a compulsory language attribute (which means what for a photo?) and URI reference? Maybe the UML diagram is wrong or something but it seems to indicate that both of them compulsory, when surely they have to be optional attributes? (I have just read it again, and in their defence, it does say they are waiting for a new datatypes standard to be published so perhaps they have not looked too much at this area).. But even the examples seem confused.. annex C has an 'informative' sample ehr_system.extension = Whittington ehr_system.assigningAuthorityName = NHS ehr_system.valid_time = 1/1/1990 - 1/1/3000 ehr_system.root.oid = 9876543211 Why would any health standard be promoting an example using 'magic' dates to indicate infinite time ranges?? Surely these are open ended intervals rather than actually statements that this ehr_system is going to cease to be valid in the year 3000? I know its just a sample, but if the sample doesn't show the proper techniques, what chance does any programmer reading the spec have to do it correctly.. I also am under the impression that 13606-2 will be an effort to standardise the expression of archetypes? Is ADL in its current form a contender for that standard? How far along is the standards process and are there any avenues to review the work (for non-europeans)? Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.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/20061103/d30d6990/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN 13606
both are optional. thanks Grahame, I thought they had to be optional (given the ED datatype recursively refers to itself it would be hard to implement if they were mandatory!).. am I misreading the UML diagram notation or are the diagrams not up to date? It uses notation like thumbnail: ED[1] which I would read as a mandatory attribute. Or is the optionality introduced using the null_flavour attribute on DATA_VALUE? Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN 13606
see below. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 3-nov-2006, at 14:02, Andrew Patterson wrote: So 13606 EHRcom is very much a go-between format - something that can be used to transfer clinical data between systems, but not something around which you would build an actual running system i.e. a system sitting in a GP's office? Is that the correct thinking? Yes, this is how I understand things. Your technical comments I will refer to Dipak Kalra the task force leader. ADL and part 2 of the EN13606 are identical. How does the openehr governance and CEN process mesh? At the moment, if we find a typo in the ADL spec, we mail Thomas and he fixes it (I know there is an actual formal openEHR process but for simple changes, that is what is boils down to :). When it becomes an ISO standard, do changes to the openEHR ADL spec automatically transfer across into the ISO standard? Is there any chance in a divergence between the languages? For quite some time I'm of the opinion that conformance testing of standards is useless. We need to test conformance against an implementable specification. In general the standard will be the most generic stable point of reference. But in reality we all know that reality and experience evolve faster than any standardisation organisation is able to cope with. For all practical purposes OpenEHR is the fast track, quick response, organisation taking care of a version of an implementable specification. In the case of CEN13606 part 1 conformance testing should be done using the OpenEHR specification (the CEN Extract part) In the case of CEN13606 part 2 conformance testing should be done using a designated version of the OpenEHR ADL specification. It will be up to OpenEHR, the user community and possibly others (like governments) to decide when to correct, amend and update the standards. Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.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/20061103/e9e5d78d/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype questions
Hi, I'm currently working in a group that has been evaluating archetypes and they found out that there in archetypes may be needed to add external nodes from other archetypes instead of only adding complete archetypes as slots. Does the current ADL specification allow that external parts from other archetypes can be included? I think the openEHR templates allow to cut off parts in a slot, but I'm not sure if they can exclude everything except a single item. The group also found out that there is a need to deduct certain answers depending on previously answered questions. For example if we previously answered that the blood pressure was above 160, then another question about hypertension should be answered automatically. Is this possible to do in archetypes? Another issue is about computation. For example we could want a quantifiable magnitude to be the result of two previously entered values. Is this possible to do in archetypes? Perhaps in the declaration section or the invariant section? I've seen that these sections should contain some kind of first-order predicate logic, but I'm not sure of the scope and limitations/possibilities of these ADL sections. Also, the declaration section is actually not even described in the ADL 1.4 document, it is only shown in an example overview figure. Another feature is value reporting, which should work when we use several archetypes in an openEHR template. For example if some question was answered in one archetype, then another archetype that has the same question should get the value reported from the previous archetype. Is this possible? I guess this has to do with external references as I mentioned in my first question. We would also like to ask if there is a way of specifying validity for questions depending on previously answered questions. E.g. if a certain answer was given from a multiple alternative question (coded_text), then and only then, some other group of questions will be valid. Is this possible to do in archetypes? Perhaps it's possible with invariants? Finally is there a way of specifying the relevance of answers in archetypes. Say for example that if some laboratory results are too old, could an archetype contain some restrictions that make it illegal to answer certain questions because the material that the answers are based upon is too old? I'm not sure if this is related to DSS or something else. Regards, Mattias, via the Link?ping Team. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061103/4f968b4d/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype questions
Mattias Forss mattias.forss at gmail.com wrote: Hello Mattias, these are exactly the questions, issues I have been working on for 3 years now. All I can specify in the HL7 v3 Care Provion Domain model, that is basically why I apply this method for the time being, waiting for a better tool to do this. Below specific answers after each question. Hi, I'm currently working in a group that has been evaluating archetypes and they found out that there in archetypes may be needed to add external nodes from other archetypes instead of only adding complete archetypes as slots. I agree, in the care provision we therefore have included the organizer class that allows you to start with atomic items, link them via an organiser code to a higher level item (e.g. blood pressure is part of vital signs, mobility is part of activities of daily living, potasium is part of electrolytes etc.). I work bottom up because of another question of you below. This is possible in ADL I believe / am told, but have not seen operationalised yet. However the template specifier does this, but I am not sure how the formal links work. In organiser we can code the higher level rubrics. Does the current ADL specification allow that external parts from other archetypes can be included? I think the openEHR templates allow to cut off parts in a slot, but I'm not sure if they can exclude everything except a single item. We break down such care information models in two parts if there are use cases where only a part is used. So we make 2 slots instead of one. The group also found out that there is a need to deduct certain answers depending on previously answered questions. For example if we previously answered that the blood pressure was above 160, then another question about hypertension should be answered automatically. Is this possible to do in archetypes? We can relate HL7 obs classes to each other, including if a value of Obs 1 160, then Obs gets default hypertension. However, there is no agreed formalism in HL7 v3 to do this. Arden syntax an d Gello are often named in this area, but I have no examples. I just use plain english for the time being. Another issue is about computation. For example we could want a quantifiable magnitude to be the result of two previously entered values. Is this possible to do in archetypes? We apply this a lot in the HL v3 care information models. Basically most scales have a kind of sum up feature of say 10 observations (Barthel) each gets a numeric score and obs 11 is for the total score. In the method section we define: total score, but again, there is no formalism used, just plain English. Similarly this would work with basic calculations such as average scores, or the formula for the body mass index etc. Perhaps in the declaration section or the invariant section? I've seen that these sections should contain some kind of first-order predicate logic, but I'm not sure of the scope and limitations/possibilities of these ADL sections. Also, the declaration section is actually not even described in the ADL 1.4 document, it is only shown in an example overview figure. It is perfectly possible to express your rules in predicate logic and if only it would be included as a comment text part, it will be clear that the system needs to be able to do such operations on the variables. Another feature is value reporting, which should work when we use several archetypes in an openEHR template. For example if some question was answered in one archetype, then another archetype that has the same question should get the value reported from the previous archetype. Is this possible? I guess this has to do with external references as I mentioned in my first question. If the first observation is coded appropriately (tracable and identifyable) then the second one could refer to this codes variable. It would work so that the variable in question and addressed from 2 archetypes, would have the same code and both archetypes should allow entering the value and presenting the value. But again, I would prefer a bottom up approach. Given that this variable is used in 2 archetypes for me would imply it can be better an atomic archetype in itself, where the other more molecular ones include this atomic archetype. This goes back to your earlier question: the bottom up approach which we currently apply in the Care Provision modelling works such that you can do what you ask for here. We would also like to ask if there is a way of specifying validity for questions depending on previously answered questions. E.g. if a certain answer was given from a multiple alternative question (coded_text), then and only then, some other group of questions will be valid. Is this possible to do in archetypes? Perhaps it's possible with invariants? I understand your question, we have similar use cases, e.g. for questions related to being eligible for types of care or treatment or facilities. We
CEN 13606
Dear Andrew, Your e-mail, with some thoughtful questions, has generated some interesting discussion inputs already. The relationship between 13606 and openEHR is long-standing, since a number of the openEHR family have been involved in this standard's development but 13606 does, as you have gathered, have a different and narrower scope. The openEHR Foundation is in the process of reviewing how best to reflect the relationship as it is now, and if you can wait a bit we shall be writing this up more clearly in future documents. You have also raised a couple of technical points. Graham has I think responded clearly on the data types - in an ideal world the ISO data type standard would be ready to use before 13606 is finalised, but as this is not the case we have on a temporary basis referenced the CEN TS 14796 (and included some explicit data types as you have seen). These will eventually be superseded by the ISO ones). openEHR data types are one of the input feeds to ISO. The example OIDs in the worked sample in Annex C only have placeholder illustrative attribute values for the validity, root and extension attributes of the II data type. Ideally I should have found an expert to give me more plausible values, but the main purpose of the example was to show how the clinical hierarchy and revision works and many of the attribute values for IDs and codes are very clearly made up ones (such as the terminology ones). If you have the time to send me some corrections (more plausible values) I can still incorporate them. Most readers have accepted that examples such as this inevitably have limitations in their completeness, but I agree that it's not ideal. Gerard has also responded to you on archetype specification currency within openEHR and 13606. Standards need to be stable, and standards organisations assume that this stability is reasonable and desirable for the marketplace. A innovative organisation like openEHR has the freedom to make changes more rapidly, but it also wishes for them to be validated in real implementations. The rapid turn around that you describe is for a document change, not for a field-validated improvement! With best wishes, Dipak Dr Dipak Kalra Clinical Senior Lecturer in Health Informatics CHIME, University College London Holborn Union Building, Highgate Hill, London N19 5LW Direct Line: +44-20-7288-3362 Fax: +44-20-7288-3322 Web site: http://www.chime.ucl.ac.uk ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
