Re: Decision Support Providers
Hi Ian, Ordersets are probably a good starting point for further development. They are less complex than full-blown guidelines, mostly static (no need for process language) and close to the level of existing building blocks like medication, lab investigation archetypes. If my assumption that ordersets are to be expressed on the template level is correct, we need to make sure it is possible to reuse templates as building blocks for larger templates (ordersets as part of careplans), to specialise (further constraining) templates for local adaptations, and equally important that they are human language independent (just as archetypes). Regarding meta-data required by ordersets, I think it's too early to have conclusions. It's best to leave room for any arbitrary meta-data in additions to a few mandatory ones (authorship, references, indication etc). Later on, after we gain more implementation experiences on ordersets, we may want to introduce a dedicated RM class ORDER_SET in the ehr package in order to mandate good designs around ordersets and facilitate software implementation. Cheers, Rong On 29 June 2010 16:22, Ian McNicoll <Ian.McNicoll@oceaninformatics.com> wrote: > Hi Rong, > I am also interested to hear a little more about your thoughts on > further > development. > Since guidelines, ordersets and protocols all represent the optimal > path > fora notional patient, and will interact with the record for that > patient, > it makes sense to base the patient data aspects on the same > structures as > the actual patient data. > In particular I would be interested to know your thought on how much > additional metadata / ref model support might be required to support > simple > ordersets based on openEHR archetypes properly, leaving the more > complex > rules requirements to the side for the moment. > By orderset, I mean a simple collection of related instructions or > requests > for a common clinical scenario, such as 'Suspected MI'. > As well as the traditional static orderset and UI dialog, I am > interested in > driving data entry from such a typical ' clinical scenario' but in > more of a > narrative fashion. i.e start from a blank page and build up content > from the > scenario, some being Instructions, others observations and > evaluations. I > have had some experience of a real, if rudimentary, implementation > and it > seemed popular with clinicians. My interest in openEHR originally > arose from > looking for a generic information model to support this approach. > Ian > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll@oceaninformatics.com > ian@mcmi.co.uk > > Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group > Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health > Scotland > > > > On 29 June 2010 13:57, Tony Shannon <tony.shannon@nhs.net> wrote: >> >> Many thanks Rong, >> >> The approach you outline which reuses archetypes and templates from >> EHR >> models resonates as a logical way to tackle this. >> >> John Halamka mentions in his blog... >> "Thus, Anvita has defined clinical decision support (CDS) standards >> to >> transmit decision support recommendations from the service provider >> back >> to the EHR. I am unaware any widely implemented standards that do >> this >> today. " >> >> Can you comment on his quote/article? >> >> Also can you say some more about the rules element of your work.. >> >> Many thanks, >> >> Tony >> >> Dr. Tony Shannon >> Consultant in Emergency Medicine, Leeds Teaching Hospitals >> Clinical Lead for Informatics, Leeds Teaching Hospitals >> Chair, Clinical Review Board, openEHR Foundation >> +44.789.988 5068 tony.shannon@nhs.net >> >> >> Rong Chen wrote: >> > Hi Tony, >> > >> > I take the challenge to comment ;-) >> > >> > We start to see this kind of CDS services emerging now in Sweden. >> > Web-services based drug interaction check is a good example of >> > this. >> > The difference is that the content (drug database) is available to >> > the >> > users. So it's not really a black-box. I doubt that a black-box CDS >> > implementation will be very popular among the clinicians. >> > >> > I also think remote-service based CDS for raising single >> > alerts/reminders can be useful in some limited scope but will not >> > scale up to provide more comprehensive CDS functions. I am more in >> > favour of developing CDS content based on standardised EHR models >> > so >> > CDS applications can be implemented directly within EHRs. >> > >> > We start to exploring representing clinical guidelines using >> > openEHR >> > archetypes/templates and rules. Using EHR models to represent >> > guidelines could give several potential benefits: 1) reuse of >> > existing >> > EHR content models as building blocks of guidelines; 2) increase >> > interoperability between CDS applications and EHRs; 3) facilitate >> > guideline compliance checking. >> > >> > More details can be found in our MIE2009 paper: >> > >> > http://www.imt.liu.se/~ronch/MIE2009_Representing_Lymphoma_Guideline_5page_v3.pdf >> > >> > Cheers, >> > Rong >> > >> > On 25 June 2010 17:24, Shannon Tony (Leeds Teaching Hospitals NHS >> > Trust) <tony.shannon@nhs.net> wrote: >> >> FYI.. >> >> >> >> A thought provoking post from John Halamka on decision support >> >> providers as service. >> >> >> >> http://geekdoctor.blogspot.com/2010/06/decision-support-service-providers.html >> >> Some of you might have complementary/alternative views as to how >> >> this >> >> might work within an openEHR enabled landscape... >> >> >> >> Rong >> >> Would you like to comment? >> >> Your recent work covered some of this key territory.. >> >> >> >> Regards, >> >> >> >> Tony >> > _______________________________________________ >> > openEHR-clinical mailing list >> > openEHR-clinical@openehr.org >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >> > >> >> -- >> >> >> >> ******************************************************************************************************************** >> >> This message may contain confidential information. If you are not the >> intended recipient please inform the >> sender that you have received the message in error before deleting >> it. >> Please do not disclose, copy or distribute information in this >> e-mail or >> take any action in reliance on its contents: >> to do so is strictly prohibited and may be unlawful. >> >> Thank you for your co-operation. >> >> NHSmail is the secure email and directory service available for all >> NHS >> staff in England and Scotland >> NHSmail is approved for exchanging patient data and other sensitive >> information with NHSmail and GSI recipients >> NHSmail provides an email address for your career in the NHS and can >> be >> accessed anywhere >> For more information and to find out how you can switch, visit >> www.connectingforhealth.nhs.uk/nhsmail >> >> >> ******************************************************************************************************************** >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > _______________________________________________ openEHR-clinical mailing list openEHR-clinical@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical