13606 revisited - list proposal
Some, actually most, of the issues you mentioned in the context of the NEHTA work are familiar, and I think apply to many implementation situations. Thomas and I have been discussing some possible solutions. 1. The ability to expose parts of the RM which are of particular significance to a particular audience, clinical or technical, to assist in clinical review or implementation guidance, along with contextual descriptions or name overrides. e.g If in a Dischage document we are using the ACTION.time attribute to carry the Date Procedure performed as described in the original requirements, I want to be able to express that in a template, so it is clear to developers and clinical reviewers. One option we discussed was to allow an RM attribute to be annotated and associated with an at-code, which would allow a local nameDate of Procedure and a description to be overlaid. This would be in design-time i.e the name overlay would not appear in data. Right. that would be very nice. 2. The problem of openEHR archetype constructs being over-granular for summarised reports, mostly in the integration space but we do also need this in the EHR space at times. As an example I might want to record a Medication instruction in a summary, along with a couple of key events e.g Date of first prescription, Date of last prescription. Currently we need to use a further 2 ACTION archetypes, which feels clunky to developers and looks clunky in the tooling, as it requires encapsulation within a SECTION or written documentation. right. Agree with this, though I suspect it doesn't quite cover all my issues. I think we can largely resolve this with better tooling but we do lack any easy way of asserting the relationship between the Instruction archetype and the child Action archetypes. I thought this was in ADL 1.5? Grahame
13606 revisited - list proposal
Hi Thomas, Date: Mon, 26 Mar 2012 20:47:05 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: 13606 revisited - list proposal On 26/03/2012 19:49, pablo pazos wrote: Hi Thomas, A while ago, we gave this issue a big thought when designing the EHRGen framework. Periodic event records are needed when recording certain studies and when monitoring a patient, but this can be recorded as single point events, and using a query to get all the points in a series. it can but that's very inefficient, and doesn't correctly represent what is happening, when you are talking about multiple samples in a series, e.g. coming from vital signs monitors, orthostatic BP, apgar, and many others. What I've said was incorrect, I mentioned periodic events and I should have said an Observation with many events, that was your question about, sorry for that. Here is the corrected answer: if you want to record a series of eventual events you can do it with only one Observation with many EVENT, or many Observarions with a single EVENT and an query to get the whole series, e.g. do create a graph. E.g. for vital signs when a patient is under observation at an ER. From the GUI perspective is very difficult to record periodic events, because you have to login, select a patient, select a record, select the section of that record that contains the periodic data, enter a new item to the time series. and presumably enter another, and another. That doesn't sound like a problem - it's how normal GUI for Apgar and multi-sample manual BP collection work. Don't forget, we are talking about time series in the seconds to minutes domain here. Although Glucose tolerance test data would make more sense to be entered as one time series, after the fact. Consider this my comment with the right answer. From the GUI perspective is very difficult to record MANY EVENTS IN THE SAME OBSERVATION, because you have to login, select a patient, select a record, select the section of that record that contains the OBSERVATION, enter a new EVENT FOR THAT OBSERVATION. The other option is to have the patient's record always open, and that is not possible in all scenarios (for technical or security reasons). well ifyou are talking about long period of time, like repeated nursing observations, you should be committing those 1 sample at a time. Consider this ER scenario: a BP value could be recorded each 30 or so, and the system could be used 1. for many patients, 2. by many users, 3. on the same machine. The problem is when an item is commited, it should be as a part of a COMPOSITION (?), so if a nurse want to record a second take of a BP she is monitoring, and of course she wants to see the current recorded values for that series, another COMPOSITION should be created only for that value (or not?). Sorry again for the confusion. Kind regards,Pablo. Of course, the system could have something in the middle storing all the values without commiting them In the other hand, in the majority of cases of clinical record through a GUI, the data is recorded as a single point event, e.g. at a patient visit. So we design the EHRGen just to use point events, and if you want to record a series of events, a service should be provided to get the data from other systems (e.g. a LAB system), but not from the GUI. that and vital signs monitors are certainly a common source of time-based data. But whether the source of the data is the GUI or somewhere else doesn't change the semantics of the model, or the need for it. Like I said elsewhere, I have no problem with adding a single-event Observation as well. But having only that will completely cripple many hospital apps and efficient data representation and querying related to this data. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/50b7decc/attachment.html
13606 revisited - list proposal
On 28/03/2012 03:01, pablo pazos wrote: Consider this ER scenario: a BP value could be recorded each 30 or so, and the system could be used 1. for many patients, 2. by many users, 3. on the same machine. this is most likely a 1-event-per-Observation scenario. I realise it is not always obvious when to use which recording approach! But the other design aspect of a COMPOSITION is that it is a 'single health system event for the patient'. Here it sounds like 1 nursing observation every 30 mins. Therefore we would expect 1 COMPOSITION for each one, each containing one OBSERVATION, containing one EVENT. The problem is when an item is commited, it should be as a part of a COMPOSITION (?), so if a nurse want to record a second take of a BP she is monitoring, and of course she wants to see the current recorded values for that series, another COMPOSITION should be created only for that value (or not?). if I understand correctly, you want to generate a time-based plot for e.g. last few hours' measurements. In that case, use an AQL query to get all the Observations based on BP (or whatever archetype) in a certain time frame. You can get just the systolic and diastolic values if you want. e.g. SELECT obs/path/to/*systolic*/value/magnitude, obs/path/to/*diastolic*/value/magnitude FROM e EHR [ehr_id = $ehr_id] CONTAINS comp COMPOSITION[openEHR-EHR-COMPOSITION.nursing_obs.v1] obs OBSERVATION[openEHR-EHR-OBSERVATION.bp_measurement.v1] WHERE comp/context/start_time current_time() - P24h * * I would have to double check if I have the syntax completely right (and I put fake paths in the SELECT part), but this will return a table of systolic and diastolic pressure values (Reals) from BP measurements inside nursing observations, for the last 24h. The real paths are below: - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120328/6b54aaed/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: cadggeac.png Type: image/png Size: 18491 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120328/6b54aaed/attachment-0001.png
NCA STu in the smoke
Hi Thomas Mr. A. Orban, head of NCZI have ivited today Mr. Martin Foltin, the vice dean of FEI STU and head of NCA STU for short briefing. He had informed Martin, that NCZI will initiate the break of contract between NCZI and STU concerning NCA Because we do not follow the CEN 13 606 but OpenEHR. I will have meeting tomorow with Michal D to investigate next steps. If you could have some advice for us, how to succesfulle defend this attack , pls. Provide me some hints Thank you Ing. Peter Linhardt, PhD., V?skumn? centrum STU Riadite? Slovensk? technick? univerzita v Bratislave Vazovova 5 812 43 Bratislava tel. +421 918 669 121 peter.linhardt at stuba.skmailto:peter.linhardt at stuba.sk www.stuba.skhttp://www.stuba.sk/ P Think environment before you print. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120328/5321ed69/attachment.html
openEHRArchetypes/openEHR-EHR-OBSERVATION.ecg.v1: Is any_allowed...allowed?
Hello everyone I keep getting an error when parsing this ecg archetype (expressed as XML) and i was wondering if this could be because the archetype was uploaded to the CKM when the CKM used a different version of the published openEHR XSDs, if this used to be a bug of the archetype editor or if it could be something that i am doing wrong. The error i keep getting is unrecognised element for any_allowed. In fact, in my small local collection of archetypes*, this archetype is the only one that has an any_allowed element as part of its C_COMPLEX_OBJECT definitions. If i remove any_allowed, the archetype is parsed without any problems, but that's usually a way to create problems, not solve them :-) I would really like to use this ECG archetype as a test case because it contains a large number of definitions. According to the specs C_COMPLEX_OBJECT is supposed to inherit any_allowed by C_DEFINED_OBJECT but the Archetype.xsd does not contain an element / attribute definition for any_allowed in any of the relevant class definitions. This is why i suspect come kind of a (possibly older) mismatch between the CKM / Archetype editor code and the XSDs. What do you think? Could this be related to this item as well? http://www.openehr.org/mailarchives/openehr-technical/msg05970.html I suppose i can safely remove any_allowed (?) Looking forward to hearing from you Athanasios Anastasiou P.S. (*) The 7 Archetypes i am interested in: (encounter, menstrual_cycle_day, blood_pressure, body_temperature, body_weight_adjusted, ecg, height)
NCA STu in the smoke
Hi Peter, I think it is pretty clear that openEHR and 13606 are headed for a very significant convergence as the next update of 13606 takes place and the CIMI work progresses. There has been substantial discussion between developers/implementers in the 2 communities on these lists and the openEHR wiki, with a real willingness to learn from each other's experiences. Many of the tools such as AWB and the LinkEHR editor work with both, several jurisdictions use openEHR tools to deliver 13606 archetypes , as the transforms are generally straightforward, and significant value of tools such as CKM to gather and review clinical content is really agnostic of any Reference Model. There is some interesting news about to emerge from CIMI, which in my opinion, makes the very close alignment of openEHR and 13606 even more likely .. watch this space ... Ian 2012/3/28 Linhardt Peter peter.linhardt at stuba.sk Hi Thomas ** ** Mr. A. Orban, head of NCZI have ivited today Mr. Martin Foltin, the vice dean of FEI STU and head of NCA STU for short briefing. He had informed Martin, that NCZI will initiate the break of contract between NCZI and STU concerning NCA Because we do not follow the CEN 13 606 but OpenEHR. I will have meeting tomorow with Michal D to investigate next steps. ** ** If you could have some advice for us, how to succesfulle defend this attack , pls. Provide me some hints ** ** Thank you ** ** *Ing. Peter Linhardt, PhD.,* *V?skumn? centrum STU* *Riadite?* * * *Slovensk? technick? univerzita v Bratislave* *Vazovova 5 * *812 43 Bratislava* * * *tel. +421 918 669 121* *peter.linhardt at stuba.sk*** *www.stuba.sk* P* **Think environment before you print.* ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com *Primary Health Info 23 - 25th April in Warwick - are you coming?http://www.primaryhealthinfo.org/ * Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120328/48f88845/attachment.html
NCA STu in the smoke
Thank you Ian, for good advices. I guess, all wise people, dealing with AT and 13 606, with standards, to build proper future constructuion of national/european/global Health solutions understand the advantages of OpenEHR approach and necessity of convergence with 13606, which is only part of the solution currently. There is in fact a business imperative, sourceing in NEss and NCZI still listen to the master voice. I will prepare the defending letter, utilising all your input concerning expected merge of OpenEHR and 13606, NCA role In educationg the medical and IT professionals and advantages of archetypes for national eH system. Than we will see. Thanks and best regards0 Ing. Peter Linhardt, PhD., V?skumn? centrum STU Riadite? Slovensk? technick? univerzita v Bratislave Vazovova 5 812 43 Bratislava tel. +421 918 669 121 peter.linhardt at stuba.skmailto:peter.linhardt at stuba.sk www.stuba.skhttp://www.stuba.sk/ P Think environment before you print. From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Ian McNicoll Sent: Wednesday, March 28, 2012 3:54 PM To: For openEHR technical discussions Subject: Re: NCA STu in the smoke Hi Peter, I think it is pretty clear that openEHR and 13606 are headed for a very significant convergence as the next update of 13606 takes place and the CIMI work progresses. There has been substantial discussion between developers/implementers in the 2 communities on these lists and the openEHR wiki, with a real willingness to learn from each other's experiences. Many of the tools such as AWB and the LinkEHR editor work with both, several jurisdictions use openEHR tools to deliver 13606 archetypes , as the transforms are generally straightforward, and significant value of tools such as CKM to gather and review clinical content is really agnostic of any Reference Model. There is some interesting news about to emerge from CIMI, which in my opinion, makes the very close alignment of openEHR and 13606 even more likely .. watch this space ... Ian 2012/3/28 Linhardt Peter peter.linhardt at stuba.skmailto:peter.linhardt at stuba.sk Hi Thomas Mr. A. Orban, head of NCZI have ivited today Mr. Martin Foltin, the vice dean of FEI STU and head of NCA STU for short briefing. He had informed Martin, that NCZI will initiate the break of contract between NCZI and STU concerning NCA Because we do not follow the CEN 13 606 but OpenEHR. I will have meeting tomorow with Michal D to investigate next steps. If you could have some advice for us, how to succesfulle defend this attack , pls. Provide me some hints Thank you Ing. Peter Linhardt, PhD., V?skumn? centrum STU Riadite? Slovensk? technick? univerzita v Bratislave Vazovova 5 812 43 Bratislava tel. +421 918 669 121tel:%2B421%C2%A0918%C2%A0669%20121 peter.linhardt at stuba.skmailto:peter.linhardt at stuba.sk www.stuba.skhttp://www.stuba.sk/ P Think environment before you print. ___ openEHR-technical mailing list openEHR-technical at lists.openehr.orgmailto:openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.commailto:ian.mcnicoll at oceaninformatics.com Primary Health Info 23 - 25th April in Warwick - are you coming?http://www.primaryhealthinfo.org/ Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledgehttp://www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.orghttp://www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120328/d87cc78e/attachment-0001.html
openEHRArchetypes/openEHR-EHR-OBSERVATION.ecg.v1: Is any_allowed...allowed?
Hello Sebastian Thank you for your response. A couple of quick comments: Yes, the archetype that you are linking is the one i am referring to. any_allowed as an attribute could be inherited from C_DEFINED_OBJECT from http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.4.pdf (page 27)...It is of course also referred to as a function in C_PRIMITIVE_OBJECT but it has the indication (effected) (?) page 28 on the same document) All the best Athanasios Anastasiou On 28/03/2012 16:44, Sebastian Garde wrote: On 28.03.2012 14:47, Athanasios Anastasiou wrote: Hello everyone I keep getting an error when parsing this ecg archetype (expressed as XML) and i was wondering if this could be because the archetype was uploaded to the CKM when the CKM used a different version of the published openEHR XSDs, if this used to be a bug of the archetype editor or if it could be something that i am doing wrong. No - the xml in CKM is produced on the fly from the adl, so it is always up to date... But of course not necessarily always correct: There may well a bug in the generation process of the Java XML generator, but can someone say definitely if the any_allowed tag should be in the xml or not, first? (any_allowed is an operation, not an attribute in the constraint model) Many archetypes have this in CKM, e.g. when a DV_TEXT is not further constrained, this would be expressed in XML using the any_allowed tag. I assume you refer to this archetype? http://openehr.org/knowledge/OKM.html#showarchetype_1013.1.276 Sebastian The error i keep getting is unrecognised element for any_allowed. In fact, in my small local collection of archetypes*, this archetype is the only one that has an any_allowed element as part of its C_COMPLEX_OBJECT definitions. If i remove any_allowed, the archetype is parsed without any problems, but that's usually a way to create problems, not solve them :-) I would really like to use this ECG archetype as a test case because it contains a large number of definitions. According to the specs C_COMPLEX_OBJECT is supposed to inherit any_allowed by C_DEFINED_OBJECT but the Archetype.xsd does not contain an element / attribute definition for any_allowed in any of the relevant class definitions. This is why i suspect come kind of a (possibly older) mismatch between the CKM / Archetype editor code and the XSDs. What do you think? Could this be related to this item as well? http://www.openehr.org/mailarchives/openehr-technical/msg05970.html I suppose i can safely remove any_allowed (?) Looking forward to hearing from you Athanasios Anastasiou P.S. (*) The 7 Archetypes i am interested in: (encounter, menstrual_cycle_day, blood_pressure, body_temperature, body_weight_adjusted, ecg, height) ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Senior Developer Ocean Informatics Skype: gardeseb
openEHRArchetypes/openEHR-EHR-OBSERVATION.ecg.v1: Is any_allowed...allowed?
On 28/03/2012 16:44, Sebastian Garde wrote:
On 28.03.2012 14:47, Athanasios Anastasiou wrote:
Hello everyone
I keep getting an error when parsing this ecg archetype (expressed as
XML) and i was wondering if this could be because the archetype was
uploaded to the CKM when the CKM used a different version of the
published openEHR XSDs, if this used to be a bug of the archetype
editor or if it could be something that i am doing wrong.
No - the xml in CKM is produced on the fly from the adl, so it is
always up to date...
But of course not necessarily always correct: There may well a bug in
the generation process of the Java XML generator,
but can someone say definitely if the any_allowed tag should be in the
xml or not, first?
(any_allowed is an operation, not an attribute in the constraint model)
ADL example:
DV_TEXT matches {*} -- object case
or
value matches {*} -- attribute case
In the AOM it is computed to be True if...
* in a C_ATTRIBUTE there are no children
* in a C_COMPLEX_OBJECT there are no children
* in a C_PRIMITIVE_OBJECT, there is no 'value', i.e. no attached
C_PRIMITIVE (parent type of C_DATE, C_INTEGER etc etc)
I would also expect it to be computed from the XML, since the XML is
based in the AOM.
- thomas*
*
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120328/7dc1c75d/attachment.html
openEHRArchetypes/openEHR-EHR-OBSERVATION.ecg.v1: Is any_allowed...allowed?
Although interestingly the same archetype, saved as XML via the archetype editor (or in .opts) does not include any_allowed elements node_idat0081/node_id attributes xsi:type=C_SINGLE_ATTRIBUTE rm_attribute_namevalue/rm_attribute_name existence lower_includedtrue/lower_included upper_includedtrue/upper_included lower_unboundedfalse/lower_unbounded upper_unboundedfalse/upper_unbounded lower1/lower upper1/upper /existence children xsi:type=C_COMPLEX_OBJECT rm_type_nameDV_TEXT/rm_type_name occurrences lower_includedtrue/lower_included upper_includedtrue/upper_included lower_unboundedfalse/lower_unbounded upper_unboundedfalse/upper_unbounded lower1/lower upper1/upper /occurrences node_id / Looks like the java parser is behaving a little differently. Ian On 28 March 2012 16:44, Sebastian Garde sebastian.garde at oceaninformatics.com wrote: On 28.03.2012 14:47, Athanasios Anastasiou wrote: Hello everyone I keep getting an error when parsing this ecg archetype (expressed as XML) and i was wondering if this could be because the archetype was uploaded to the CKM when the CKM used a different version of the published openEHR XSDs, if this used to be a bug of the archetype editor or if it could be something that i am doing wrong. No - the xml in CKM is produced on the fly from the adl, so it is always up to date... But of course not necessarily always correct: There may well a bug in the generation process of the Java XML generator, but can someone say definitely if the any_allowed tag should be in the xml or not, first? (any_allowed is an operation, not an attribute in the constraint model) Many archetypes have this in CKM, e.g. when a DV_TEXT is not further constrained, this would be expressed in XML using the any_allowed tag. I assume you refer to this archetype? http://openehr.org/knowledge/OKM.html#showarchetype_1013.1.276 Sebastian The error i keep getting is unrecognised element for any_allowed. In fact, in my small local collection of archetypes*, this archetype is the only one that has an any_allowed element as part of its C_COMPLEX_OBJECT definitions. If i remove any_allowed, the archetype is parsed without any problems, but that's usually a way to create problems, not solve them :-) I would really like to use this ECG archetype as a test case because it contains a large number of definitions. According to the specs C_COMPLEX_OBJECT is supposed to inherit any_allowed by C_DEFINED_OBJECT but the Archetype.xsd does not contain an element / attribute definition for any_allowed in any of the relevant class definitions. This is why i suspect come kind of a (possibly older) mismatch between the CKM / Archetype editor code and the XSDs. What do you think? Could this be related to this item as well? http://www.openehr.org/mailarchives/openehr-technical/msg05970.html I suppose i can safely remove any_allowed (?) Looking forward to hearing from you Athanasios Anastasiou P.S. (*) The 7 Archetypes i am interested in: (encounter, menstrual_cycle_day, blood_pressure, body_temperature, body_weight_adjusted, ecg, height) ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* *Dr. sc. hum., Dipl.-Inform. Med, FACHI* Senior Developer Ocean Informatics Skype: gardeseb ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com *Primary Health Info 23 ? 25th April in Warwick ? are you coming?http://www.primaryhealthinfo.org/ * Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120328/9e581771/attachment-0001.html
