Trying to understand the openEHR Information Model
-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130417/989512a8/attachment-0001.html
Mimetype ADL
On 16/04/2013 07:14, Bert Verhees wrote: Hi, Is there a mimetype defined for ADL-files? There's no dedicated one; a text type should do, but remember ADL is UTF-8. I haven't looked up the rules on that but if text/plain allows UTF-8, then I would use that. - thomas
Mimetype ADL
On 04/17/2013 11:10 AM, Thomas Beale wrote: On 16/04/2013 07:14, Bert Verhees wrote: Hi, Is there a mimetype defined for ADL-files? There's no dedicated one; a text type should do, but remember ADL is UTF-8. I haven't looked up the rules on that but if text/plain allows UTF-8, then I would use that. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org Thanks, ;-) Bert
Template designer download asks for login info
Hi, I'm trying to download de template designer from here * but is impossible, maybe there's an alternative site for download? Thanks. * http://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+Releases -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130417/13a3bc3d/attachment.html
Trying to understand the openEHR Information Model
I should probably point out that there are some dozens of openEHR operational deployments http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities, all heavily using AQL for screen population, reporting and so on. The performance is perfectly adequate in all of these systems for the kinds of queries used in point of care (e.g. typically sub 1-second), and in some cases where ETL is implemented, the performance is also acceptable. It's also true that quite a lot of effort and thinking has gone into optimising AQL queries. There is always a query that can be written that will take a long time to answer, but so far there is no overlap between those type of queries and point of care latency requirements i.e. such queries are always report-oriented, research queries or some other kind of population query, where a (let's say) 5 second response is perfectly acceptable. There is probably about 3 years of experience of such systems now (there's more like 6 years experience of commercially deployed AQL) that show that the performance challenges of this kind of framework are satisfiable, and no longer a research question (they were once obviously!). The second order types of structures I mentioned below rely less on AQL, and more on smart commit type rules / triggers logic, which effectively enables pre-built query results to be maintained in a live system. We're somewhere on a road where we are already riding in motorised transport, but we don't really know if what we have today is a Fiat Punto or a Maserati. Hopefully it's the Fiat, because that leaves us a lot of fun and room to get to the Maserati (at which point we start looking at air travel;-). - thomas On 17/04/2013 15:58, Randolph Neall wrote: Hi Seref, Hint: think about how you're going to get data out before thinking how you're supposed to keep it. There are lots of possibilities, but you need to anchor those with a single method of access. I suggest a brief look at Archetype Query Language (AQL) That's the whole point, Seref--how you're going to get the data out. And certainly AQL is one way to do that. My concern has to do with querying performance (deserialization as a prerequisite to record inspection, etc.) and the infrastructure resources necessary to support them. Thomas hints at possibly some big changes when he said, There is an emerging set of 'second order' object definitions, that use the URI-based referencing approach in very sophisticate ways to represent things like care plans, medication histories and so on. I can't point to a spec right now, but they will start to appear. I don't know how radical that will prove to be. I'd assume they'd still occur within the AQL paradigm. But it does appear that openEHR itself is evolving on this point and perhaps for good reason. Please don't interpret my remarks as any sort of disrespect for openEHR; I hope it has been apparent that my respect for the entire system has grown as I have learned more about it. Some really brilliant people, perhaps including you, put this whole thing together. And you all do the whole world a favor by make it all open and by making yourselves available for the sort of questions I have raised. Randy ** -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130417/96e4bd84/attachment.html
openEHR webinar in spanish
Hi all, Next friday I'll give a talk at the Hospital Italiano de Buenos Aires, Argentina, about openEHR.This will be transmitted and recorded online.More info: http://www.hospitalitaliano.org.ar/archivos/noticias_archivos/11/Ateneosnews/11_wabr13.html Anyone knows how can I get this published on the openEHR.org events page? Thanks. -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130417/9ec5a649/attachment.html
Trying to understand the openEHR Information Model
The performance is perfectly adequate in all of these systems for the kinds of queries used in point of care (e.g. typically sub 1-second), and in some cases where ETL is implemented, the performance is also acceptable. It's also true that quite a lot of effort and thinking has gone into optimising AQL queries. There is always a query that can be written that will take a long time to answer, but so far there is no overlap between those type of queries and point of care latency requirements i.e. such queries are always report-oriented, research queries or some other kind of population query, where a (let's say) 5 second response is perfectly acceptable. That's excellent! Can you give any idea how long it takes to retrieve into live memory and screen on a user's computer an entire EHR record of typical size and complexity? Or does that not generally happen, with records instead being fetched in smaller pieces? Randy On Wed, Apr 17, 2013 at 12:10 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: I should probably point out that there are some dozens of openEHR operational deploymentshttp://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities, all heavily using AQL for screen population, reporting and so on. The performance is perfectly adequate in all of these systems for the kinds of queries used in point of care (e.g. typically sub 1-second), and in some cases where ETL is implemented, the performance is also acceptable. It's also true that quite a lot of effort and thinking has gone into optimising AQL queries. There is always a query that can be written that will take a long time to answer, but so far there is no overlap between those type of queries and point of care latency requirements i.e. such queries are always report-oriented, research queries or some other kind of population query, where a (let's say) 5 second response is perfectly acceptable. There is probably about 3 years of experience of such systems now (there's more like 6 years experience of commercially deployed AQL) that show that the performance challenges of this kind of framework are satisfiable, and no longer a research question (they were once obviously!). The second order types of structures I mentioned below rely less on AQL, and more on smart commit type rules / triggers logic, which effectively enables pre-built query results to be maintained in a live system. We're somewhere on a road where we are already riding in motorised transport, but we don't really know if what we have today is a Fiat Punto or a Maserati. Hopefully it's the Fiat, because that leaves us a lot of fun and room to get to the Maserati (at which point we start looking at air travel;-). - thomas On 17/04/2013 15:58, Randolph Neall wrote: Hi Seref, Hint: think about how you're going to get data out before thinking how you're supposed to keep it. There are lots of possibilities, but you need to anchor those with a single method of access. I suggest a brief look at Archetype Query Language (AQL) That's the whole point, Seref--how you're going to get the data out. And certainly AQL is one way to do that. My concern has to do with querying performance (deserialization as a prerequisite to record inspection, etc.) and the infrastructure resources necessary to support them. Thomas hints at possibly some big changes when he said, There is an emerging set of 'second order' object definitions, that use the URI-based referencing approach in very sophisticate ways to represent things like care plans, medication histories and so on. I can't point to a spec right now, but they will start to appear. I don't know how radical that will prove to be. I'd assume they'd still occur within the AQL paradigm. But it does appear that openEHR itself is evolving on this point and perhaps for good reason. Please don't interpret my remarks as any sort of disrespect for openEHR; I hope it has been apparent that my respect for the entire system has grown as I have learned more about it. Some really brilliant people, perhaps including you, put this whole thing together. And you all do the whole world a favor by make it all open and by making yourselves available for the sort of questions I have raised. Randy * * ___ 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/20130417/8d1cfdc7/attachment-0001.html
Trying to understand the openEHR Information Model
On 17/04/2013 18:47, Randolph Neall wrote: The performance is perfectly adequate in all of these systems for the kinds of queries used in point of care (e.g. typically sub 1-second), and in some cases where ETL is implemented, the performance is also acceptable. It's also true that quite a lot of effort and thinking has gone into optimising AQL queries. There is always a query that can be written that will take a long time to answer, but so far there is no overlap between those type of queries and point of care latency requirements i.e. such queries are always report-oriented, research queries or some other kind of population query, where a (let's say) 5 second response is perfectly acceptable. That's excellent! Can you give any idea how long it takes to retrieve into live memory and screen on a user's computer an entire EHR record of typical size and complexity? Or does that not generally happen, with records instead being fetched in smaller pieces? Right - you wouldn't ever pull an entire EHR to the screen. I have seen openEHR applications pulling the main managed lists (say 6-8 Compositions), latest lab results, plus a chronological list of consultations / events for the last year or so, plus key demographic data, all sub 0.5 sec. Then the user starts clicking on things, and more comes back. More interesting screens contain a mixture of text and e.g. vital signs real-time graphs, which AQL copes with nicely - you can bring back just a 2-D array of numbers and timestamps for the graph, using AQL. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130417/78d2fadf/attachment.html
Template designer download asks for login info
Hi Pablo, We are looking into this. There is a new internal release being worked on which is normally 'private' but the betas have generally been open access, so I am not sure what has happened. Ian On 17 April 2013 16:16, pablo pazos pazospablo at hotmail.com wrote: Hi, I'm trying to download de template designer from here * but is impossible, maybe there's an alternative site for download? Thanks. * http://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+Releases -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com ___ 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 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
Trying to understand the openEHR Information Model
Thomas, somehow I'm not finding the AQL specification. It's probably right under my nose on your specification/release page. Also, do you have any references describing the AQL processor? Did you write *that* from scratch?? It would seem that the AQL processor would indeed function as a formidable DBMS in its own right, at least with regard to reads, capable of managing AND/OR logic trees and serving up flat tables of joined data structures like any RDBMS. Randy On Wed, Apr 17, 2013 at 4:17 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 17/04/2013 18:47, Randolph Neall wrote: The performance is perfectly adequate in all of these systems for the kinds of queries used in point of care (e.g. typically sub 1-second), and in some cases where ETL is implemented, the performance is also acceptable. It's also true that quite a lot of effort and thinking has gone into optimising AQL queries. There is always a query that can be written that will take a long time to answer, but so far there is no overlap between those type of queries and point of care latency requirements i.e. such queries are always report-oriented, research queries or some other kind of population query, where a (let's say) 5 second response is perfectly acceptable. That's excellent! Can you give any idea how long it takes to retrieve into live memory and screen on a user's computer an entire EHR record of typical size and complexity? Or does that not generally happen, with records instead being fetched in smaller pieces? Right - you wouldn't ever pull an entire EHR to the screen. I have seen openEHR applications pulling the main managed lists (say 6-8 Compositions), latest lab results, plus a chronological list of consultations / events for the last year or so, plus key demographic data, all sub 0.5 sec. Then the user starts clicking on things, and more comes back. More interesting screens contain a mixture of text and e.g. vital signs real-time graphs, which AQL copes with nicely - you can bring back just a 2-D array of numbers and timestamps for the graph, using AQL. - 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/20130417/ea2e9498/attachment.html
Trying to understand the openEHR Information Model
AQL is not part of the official specification yet. Regards Seref On Wed, Apr 17, 2013 at 10:04 PM, Randolph Neall randy.neall at veriquant.comwrote: Thomas, somehow I'm not finding the AQL specification. It's probably right under my nose on your specification/release page. Also, do you have any references describing the AQL processor? Did you write *that* from scratch?? It would seem that the AQL processor would indeed function as a formidable DBMS in its own right, at least with regard to reads, capable of managing AND/OR logic trees and serving up flat tables of joined data structures like any RDBMS. Randy On Wed, Apr 17, 2013 at 4:17 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 17/04/2013 18:47, Randolph Neall wrote: The performance is perfectly adequate in all of these systems for the kinds of queries used in point of care (e.g. typically sub 1-second), and in some cases where ETL is implemented, the performance is also acceptable. It's also true that quite a lot of effort and thinking has gone into optimising AQL queries. There is always a query that can be written that will take a long time to answer, but so far there is no overlap between those type of queries and point of care latency requirements i.e. such queries are always report-oriented, research queries or some other kind of population query, where a (let's say) 5 second response is perfectly acceptable. That's excellent! Can you give any idea how long it takes to retrieve into live memory and screen on a user's computer an entire EHR record of typical size and complexity? Or does that not generally happen, with records instead being fetched in smaller pieces? Right - you wouldn't ever pull an entire EHR to the screen. I have seen openEHR applications pulling the main managed lists (say 6-8 Compositions), latest lab results, plus a chronological list of consultations / events for the last year or so, plus key demographic data, all sub 0.5 sec. Then the user starts clicking on things, and more comes back. More interesting screens contain a mixture of text and e.g. vital signs real-time graphs, which AQL copes with nicely - you can bring back just a 2-D array of numbers and timestamps for the graph, using AQL. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ 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/20130417/83f32baa/attachment-0001.html
Template designer download asks for login info
I'm sure I downloaded a version of the TD a month (or so) ago from there without any problems.I wanted to show the last version of the tool in my talk this friday, please let me know when the download will be available again. Thanks a lot! -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com From: Ian.McNicoll at oceaninformatics.com Date: Wed, 17 Apr 2013 21:23:59 +0100 Subject: Re: Template designer download asks for login info To: openehr-technical at lists.openehr.org Hi Pablo, We are looking into this. There is a new internal release being worked on which is normally 'private' but the betas have generally been open access, so I am not sure what has happened. Ian On 17 April 2013 16:16, pablo pazos pazospablo at hotmail.com wrote: Hi, I'm trying to download de template designer from here * but is impossible, maybe there's an alternative site for download? Thanks. * http://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+Releases -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com ___ 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 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 ___ 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/20130417/b2569f28/attachment.html
Trying to understand the openEHR Information Model
Seref, I was simply trying to take your hint. :). On Wed, Apr 17, 2013 at 5:08 PM, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: AQL is not part of the official specification yet. Regards Seref On Wed, Apr 17, 2013 at 10:04 PM, Randolph Neall randy.neall at veriquant.com wrote: Thomas, somehow I'm not finding the AQL specification. It's probably right under my nose on your specification/release page. Also, do you have any references describing the AQL processor? Did you write *that* from scratch?? It would seem that the AQL processor would indeed function as a formidable DBMS in its own right, at least with regard to reads, capable of managing AND/OR logic trees and serving up flat tables of joined data structures like any RDBMS. Randy On Wed, Apr 17, 2013 at 4:17 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 17/04/2013 18:47, Randolph Neall wrote: The performance is perfectly adequate in all of these systems for the kinds of queries used in point of care (e.g. typically sub 1-second), and in some cases where ETL is implemented, the performance is also acceptable. It's also true that quite a lot of effort and thinking has gone into optimising AQL queries. There is always a query that can be written that will take a long time to answer, but so far there is no overlap between those type of queries and point of care latency requirements i.e. such queries are always report-oriented, research queries or some other kind of population query, where a (let's say) 5 second response is perfectly acceptable. That's excellent! Can you give any idea how long it takes to retrieve into live memory and screen on a user's computer an entire EHR record of typical size and complexity? Or does that not generally happen, with records instead being fetched in smaller pieces? Right - you wouldn't ever pull an entire EHR to the screen. I have seen openEHR applications pulling the main managed lists (say 6-8 Compositions), latest lab results, plus a chronological list of consultations / events for the last year or so, plus key demographic data, all sub 0.5 sec. Then the user starts clicking on things, and more comes back. More interesting screens contain a mixture of text and e.g. vital signs real-time graphs, which AQL copes with nicely - you can bring back just a 2-D array of numbers and timestamps for the graph, using AQL. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ 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/20130417/da261169/attachment.html
