Hi Sam, Boosted clinical process is a nice term indeed, maybe another alternative would be augmented clinical process, inspired by augmented reality, which could probably have interesting applications in healthcare. I should say that I am not sure if I have made my mind about the outcomes of demand pull vs supply push when it comes to initiatives like OpenEHR. On one hand you are right about the requirement for having EHR working, on the other hand a piece of software that benefits from a subset of the standard may help increase the adoption of it. I'd really like to see the outcomes of a little project which would be about porting a simple existing decision support system to an OpenEHR based infrastructure. Warning against adverse drug events for patient safety would be a good target for example. (mostly) rewriting this kind of app would give valuable feedback to archetype designers and also standard developers. A very rough idea at the moment, but I'd like to give this a try in a year or two, when I settle things in other fronts a little bit more. In case any member of this group have a candidate app for a trial like this, I'd be delighted to get some pointers for future work.
Regards Seref On Mon, Jun 2, 2008 at 12:04 AM, Sam Heard <sam.heard at oceaninformatics.com> wrote: > Hi Seref, > > The two things that openEHR offers decision support are: > > - Formal statement of context (in so far as the reference model has > captured it) > - see Context Model of Recording p35 of the EHR > IM<http://www.openehr.org/releases/1.0.1/architecture/rm/ehr_im.pdf> > - The meaning of the information as expressed in a shared set of > archetypes. > > Obviously use of a standard terminology adds further value. > > By leveraging on these two aspects, and with terminology inferencing, it is > possible to build: > > - A Virtual EHR interface that allows reading, writing and querying of > an EHR which can be made available to decision support modules. This > service > interface provides a means of determining the state of health of a person > as > expressed in their health record and also writing notifications, monitoring > etc. in the EHR. For many years Pete Johnson has been working on this > aspect > using HL7 and more recently CDA using terminology - the problem is context. > - It is important in real applications that the Virtual EHR separates > out what is in the EHR and what is being collected today, what has been > written by the clinician and what by the decision support, work flow steps > etc. > > Thomas Beale said a long time ago that the problem with Health Informatics > is that it doesn't really exist - everyone just goes and builds their own > applications, taking little or no heed as to what has gone before. Further, > there is no real understanding of what is required of the platform on which > to base the added value of decision support, care pathways etc. I believe > that openEHR can provide the spring board for major advances in decision > support. > > Archetype designers do need to be aware of the data requirements of > decision support and workflow - or what might be best termed *the > 'boosted' clinical process*. I like the idea of 'boosted' as it does imply > making something good better. At present there is not a lot of demand as we > have no platform on which to base it. > > I believe the boosted clinical process is the next area to get sorted once > we have the EHR working nicely!! > > Cheers, Sam > > Seref Arikan wrote: > > Hi, > That's an interesting question, and honestly, my knowledge of archetypes is > a little bit rusty to comment on this. However, there are other aspects of > OpenEHR related work which I find worthy of discussing in the context of > decision support. > A decision support system is built on top of other layers like ETL which > transfers, transforms and updates data that is used by machine learning > tools and analysis purposes. The same data is sometimes subject to > transformation to OLAP cubes, on which you may again execute machine > learning algorithms and/or data mining. > Information fed by these systems to a decision support system reaches its > final destination where it becomes a driving force in the decision making > process. > The thing is, this connection from data to decision support engine > requrires lots of interfaces. Interfaces to different sources of data, which > for example may use different persistence approaches. Feeding data to such a > pipeline direclty from archetypes would be an interesting challange. Or > performance impact of various persistence approaches in the context of this > pipeline, OLAP, etc is worth discussing. > My favorite tool Weka, is a machine learning workbench, and everytime I use > it for some kind of data, I have to import and transform (make continious > data concrete etc) data. I can't help imagining what would happen if I had a > version of Weka that allowed me to connect to an OpenEHR based repository. > In short, this is a quite broad field, for which I'd love to exchange ideas > with others in a list created for this particular subject. > > All the best > Seref > > On Sat, May 31, 2008 at 1:43 PM, Thilo Schuler <thilo.schuler at gmail.com> > wrote: > >> I am also interested. I wonder how much decision support has to be >> considered when designing archetypes. In the near and midterm future >> decision support will probably mostly happen on a local (i.e. >> template) level, but I still assume that there should be design >> patterns of the underlying archetypes that make local decision support >> feasible. >> >> -Thilo >> >> On Sat, May 31, 2008 at 1:38 AM, Tim Cook <timothywayne.cook at gmail.com> >> wrote: >> > >> > On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: >> >> I wonder if we should have a particular list for people who are >> interested in working with openEHR from a decision support point of view. >> >> This may not be appropriate just yet but I believe it will generate a >> considerably different intellectual space. I wonder what others think? >> > >> > I am certainly interested. It is the core of my interest semantic >> > information management in healthcare and my primary driver for being >> > involved in the EGADSS project http://egadss.sourceforge.net/ >> > Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I >> > left the project. >> > >> > >> > >> > -- >> > 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 >> > >> > >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > ------------------------------ > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -- > > Dr Sam Heard > Chief Executive Officer > Director, openEHR Foundation > Senior Visiting Research Fellow, University College London > 214 Victoria Avenue > Chatswood, NSW, 2067 > Phone: +61 2 9415 4994 > Mobile: +61 4 1783 8808 21 Chester Cres > London E8 2PH > Phone: +44 20 7249 7085 > Mobile: +44 77 9871 0980 > > _______________________________________________ > 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/20080602/dfc70538/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: OceanInformaticsl.JPG Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/dfc70538/attachment.JPG>
