Hi Thilo, See my comments inline below...
> -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Thilo Schuler > Sent: Monday, June 02, 2008 11:12 PM > To: heath.frankel at oceaninformatics.com; For openEHR technical > discussions > Cc: timothywayne.cook at gmail.com > Subject: Re: Decision Support was: MIE-2008 > > Yes, agree on the querying ... and for querying we need structured > content! > > As Sam and I noticed before this has to be considered when designing > archetypes. This doesn't mean there shouldn't be free-text fields, > this is a very valid requirement in clinical medicine! [Chunlan Ma] Agree with this requirement. However, we have to be very careful when we allow free text in archetypes because more free-text fields would have less control over data quality. Currently, data quality is an issue and I believe that archetypes will play a very important role in resolving this issue. However, if we provide more free-text fields than necessary, then we may loss one of the advantages of using archetypes. Even though all text fields can be either free-text or coded text, there should be some rules/guidelines suggesting what kinds of fields can be free-text, coded-text or both. Whether a text field is defined appropriately should be assessed during archetype governance process. What I am saying is that carefully defining a text field is not only for the purpose of DSS, it is also for data quality control. Chunlan > > Thus, when designing archtypes the art is to find the balance between > free-text (max. flexibility) and structured content. In my mind we > often have to offer *both* in an archetype. If I want to create a > local application with lots of DSS I create a template that uses > mostly the structured parts of the archetype. If I want maximum > freedom I use mostly the free-text parts. > > Another scenario is that I receive information from another > archetype-enabled system: The receiving system doesn't know whether > the sending system had used the archtype in a flexible (free-text) or > in a structured way. To allow the receiving system to decide whether > it can use DSS with this information I see two options: > 1) We have a root archetype that optionally offers both (free-text and > structured) and we specialise a "DSS optimised" archetype from it. So > only if the DSS optimised archetype was used, much DSS is can be > offered. > 2) Or we create generic archetype design patterns with switch-like > constructs (i.e. if this option option was chosen I can rely on these > other attributes to be available as well) so the receiving system's > DSS engine can do a kind of archetype-introspection to decide what it > can use and what not. > > Just early thoughts. What do others think? > > > On Mon, Jun 2, 2008 at 9:55 AM, Heath Frankel > <heath.frankel at oceaninformatics.com> wrote: > > Thilo, > > I think the key thing that needs to be considered in Archetype design > to > > support Decision Support is querying. > > > > Heath > > > >> -----Original Message----- > >> From: openehr-technical-bounces at openehr.org [mailto:openehr- > technical- > >> bounces at openehr.org] On Behalf Of Thilo Schuler > >> Sent: Saturday, 31 May 2008 8:13 PM > >> To: timothywayne.cook at gmail.com; For openEHR technical discussions > >> Subject: Re: Decision Support was: MIE-2008 > >> > >> 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 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
