1 / 31

Infobuttons and Point of Care Access to Knowledge

Infobuttons and Point of Care Access to Knowledge. Introduction. One type of CDSS is the use of health information resources (e.g., published literature) to support decision-making simply by educating the decision maker

devika
Télécharger la présentation

Infobuttons and Point of Care Access to Knowledge

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Infobuttons and Point of Care Access to Knowledge

  2. Introduction • One type of CDSS is the use of health information resources (e.g., published literature) to support decision-making simply by educating the decision maker • If the appropriate knowledge can be invoked at the time that the clinician needs it, then it can truly support clinical decision making as “just-in-time” • The fact that the clinician sitting in front of a computer presents is an opportunity for educational CDS. • A clever CDS can anticipate the needs and automatically satisfy them (e.g., Proteus mirabilis in urine and questions that should be answered). • The emphasis for infobuttons (a sample educational CDSS), as well as for other related approaches to point-of-care access to knowledge, is on methods for automatically selecting and retrieving appropriate knowledge resources, rather than on methods for automatically interpreting them, as is the case with many other CDS capabilities.

  3. Understanding Clinician Information Needs • Information Needs in Clinical Practice • A study in 1985 showed that physicians in an outpatient clinical setting had two questions for every three patients only 30% of these questions were answered during the patient visit. Studies in 1991 to 2000 had similar results. • In 2000 a taxonomy was created with 64 question types to classify clinical questions. Most common question topics among family doctors were about drug prescribing (19%). • In 2003 a study showed that information needs arose most often while reviewing laboratory results and medication orders. Over half of health knowledge needs (55%) were not successfully resolved. • Use and Impact of Online Information Resources • Clinicians seldom use the online information one systematic review found that clinicians search resources from 0.3 to 9 times a month. • One study found that nurses use colleagues, particularly senior nurses, as a primary source of information to answer their clinical questions

  4. Understanding Clinician Information Needs cont. • Despite the apparent underutilization of online resources, online summarizations of evidence and best practices have been considered a sound strategy for meeting clinicians’ information needs performance on answering a set of clinical questions improved by 21% among doctors when they were provided with access to a set of resources. • Barriers to Use of Online Information Resources • Obstacles preventing pursuit of answers • doubt that an answer existed • ready availability of consultation leading to a referral rather than a search • lack of time • question not important enough • uncertainty about where to look for information • Obstacles to finding answers to pursued questions • topic not included in the selected resource • failure of the resource to anticipate ancillary information needs • The amount of time taken to find an answer (~6 to 30 mins for Medline search!) • Suboptimal clinicians’ literature search skills (40% get answer, 10% know MeSH)

  5. Linking Clinical Informatics Systems to Online Resources • The integration of clinical information systems with online health knowledge resources can address the dual barriers of access and time constraints • Hepatopix and Psychtopix: contained sets of topic-specific Medline search strategies that could be matched to liver biopsy and psychiatric records  required extensive manual effort by experts to create the search strategies • Term Linker and the Meta-1 Front End: both employed the Unified Medical Language System to support translation to the Medical Subject Headings while copying and pasting from clinical records. • Chartline system: allowed the user to specify particular topics of interest related to the term of interest in the clinical record  the system translated it to MeSH and used a predefined Medline search to find the articles. • Interactive Query Workstation and Internet Gopher: allowed users to perform searches against a variety of resources besides Medline • DeSyGNERsystem: supported the integration of books, tutorials, and simulation systems into a radiologist’s clinical workstation. • Web-Based Systems: MedWeaver system, Active-Guidelines system, PAMFOnline system (patient oriented)

  6. Infobuttons • Context-specific links from clinical information system to online resource • Infobuttons not only invoke relevant resources, but anticipate information needs and initiate retrieval strategies to help the user navigate resources • Understanding the Context of Information Needs • The role of context in predicting the nature of workers’ information needs  in the effort to characterize information seeking, it is important to accurately define the types of information clinicians may use as well as states of information need which trigger information search and retrieval • Computer systems are able to capture the context in which common information needs occur  systems would be able to predict the information needs, automatically translating them into queries that can be executed by online resources • Infobutton Development at Columbia University • Originally the Medline Button  support automated bibliographic searches  the system failed to address real information needs of real users. • Developed a representational scheme for capturing user information needs (‘‘Is <disease 1> caused by <disease 2>?’’) + connected to the Web (Dxplain)

  7. Infobuttons cont. 1 2 3 Screen shots from the Medline Button(1) shows patient diagnoses, coded in ICD9-CM, in the clinical information system. When the user selects two ICD9-CM diagnoses (e.g., Acute MI, Subendoc Infarc, Initi and Convulsions)  the Medline Button translates the diagnoses into MeSH terms (Myocardial Infarction and Convulsions)  and (2) presents several possible questions of interest to the user. (3) When the user selects a question (e.g., question 2 Is Myocardial Infarction caused by Convulsions?), the system generates the Medline search strategy, in turn, (4) produces the search results (e.g., one article was returned). 4

  8. Infobuttons cont. 1 2 3 Infobutton Implementation at New York Presbyterian Hospital (1) shows a typical WebCIS screen displaying pharmacy orders The infobuttons are the i icons, to the right of each medication. (2) shows the result of clicking on an infobutton  a screen pops up with links to two resources, Micromedex and Medline. Note that the infobutton has extracted the trade name PRILOSEC for use in searching Micromedex and has also used a terminology knowledge base to recognize that the drug has the ingredient Omeprazole, which is suitable for use in searching both resources. (3) the result of clicking on the Micromedex Omeprazole link (4) the result of clicking on the Medline Adverse effects link 4

  9. Infobuttons cont. • Infobutton Development at Intermountain Healthcare (IHC) • In 2001 IHC integrated infobuttons with the medication list, problem list, and laboratory results modules of HELP2 system • When an infobutton is clicked, the user is presented with a list of questions about the concept of interest  user can select from a list of resources that cover the domain of the questions under consideration. • All clinical coded data values represent clinical concepts maintained within the IHC terminology server  each coded concept is translated into a suitable standard terminology (e.g., ICD-9-CM, LOINC, National Drug Codes). If not found in the terminology server then free text will be used in the query.

  10. Infobuttons cont. A medications list screen from IHC’s HELP2 system, showing infobuttons (left) and the result of selecting the infobutton next to the medication Lanoxin (Digoxin) (right)

  11. Infobuttons cont. • The utilization of infobuttons has been constantly increasing since their initial release. For instance, in 2004, infobuttons were used 17,656 times (58% higher than the same period in 2003). • The infobuttons in the medications module were the ones with highest use (64.9%), followed by the modules for viewing lab test results (21.5%), and managing problems lists (13.6%). Total number of hits on the infobuttons at IHC from January 2002 to January 2005

  12. Infobuttons cont. Number of infobutton users at IHC from January 2002 to January 2005.

  13. Infobuttons cont. • Other Infobutton Development Work • MINDscape: integrates a digital library and electronic medical record. Links are all hard-coded, creating problems with maintenance and with passing details about the user’s context. • Geissen University Hospital: use of a data dictionary to provide additional information about the data from the clinical record. • SmartQuery: collects a variety of terms from the patient record, then translated into MeSH terms and used to search five different resources. • KnowledgeLink: look-up buttons within the electronic medical record wherever a medication is displayed to the user. • PC-POETS: Patient Care Provider Order Entry with the Integrated Tactical Support provides links from order entry screens to online resources with searches for the item being ordered.

  14. Managing Infobuttons • Updating and customizing the programming is time consuming. Logical step in developing infobuttons is to decouple the clinical systems from the knowledge resources to allow for more flexible connections. • Columbia University’s Infobutton Manager • Infobutton Manager (IM) involved three design components: • First component is the standardization of the set of context information that would be passed to the IM  insert a hyperlink to the CGI call that included the values of all the data items as parameters. Example of a link to the Infobutton Manager. Most of the HTML code is the same for each link. The clinical system needs to provide specific parameter values, such as info_med, which, in this case, contains the code for the laboratory test being reviewed (‘1600’ is the code for a serum glucose test).

  15. Managing Infobuttons cont. • The second design component is a table of user questions (the Infobutton Table). Each question has been determined through Columbia’s empirical studies of clinician information needs The Infobutton Table therefore contains a unique question ID, a natural language version of the question (to display to users), and the URL for carrying out the search. A sample of rows from the Infobutton Table in Columbia’s Infobutton Manager. The Infobutton ID is the unique identifier for the query, the Question is the natural language version of the query (for display in the user’s Web browser), and the URL is the link to the target information resource.

  16. Managing Infobuttons cont. • The third design component is the Context Table. IM receives the context parameters and matches them against rows in the Context Table. Then the set of question-resource-links is assembled into a Web page for the user.

  17. Managing Infobuttons cont. Columbia University’s Infobutton Manager

  18. Managing Infobuttons cont. • Advantages of IM: (1) the link itself is essentially the same no matter where it is inserted (2) flexibility of adding questions and resources (3) it is not necessarily institution specific (Generic Institution) An example of output from Columbia’s Infobutton Manager. This was evoked when the user clicked on the infobutton icon next to a serum potassium result.

  19. Managing Infobuttons cont. • Intermountain Healthcare e-Resources Manager (ERM) • The ERM is composed of four core components: e-resource profiles, e-resource selection, question builder, and query translator E-resources Manager (ERM) and its core components. The i represents an infobutton call, and the API represents the programmatic interfaces between the Clinical Information System and the ERM, and between the ERM and the resource. XML XML

  20. Infobuttons Standardization • Different vendors of Infobuttons may provide different Infobutton Managers  integration of different vendors into different parts of Clinical Information systems (e.g., CPOE, LIS, RIS) is difficult. Current integration scenario: the lack of a standard for infobutton APIs requires the custom development of multiple interfaces among clinical information systems and infobutton managers and among infobutton managers and content resources

  21. Infobuttons Standardization cont. Desired integration scenario: a standard for infobutton APIs is adopted by the various parties involved in an infobutton transaction, simplifying the development and maintenance of infobuttons.

  22. Infobuttons Standardization cont. • HL7 Clinical Decision Support Technical Committee (CDSTC) has been developing a standard for infobutton APIs. 1 2 3 4 5 HL7 (?) 6 Sequence diagram depicting a typical HL7-compliant infobutton transaction involving a clinical information system, and infobutton manager, and a resource. Arrows indicate steps where HL7 messages are exchanged.

  23. Infobuttons Standard. Brief description of the main parameters defined in the HL7 proposal for infobutton APIs.

  24. Standards for Information Resources • Online resources provide a variety of methods for handling information requests  links provided by the infobutton manager must resort to a variety of methods and tricks to automate the retrieval of answers to questions. • Information resources generally do not recognize the controlled terminologies used in clinical information systems. • XML is used to address the semantics issues mark up guidelines in order to facilitate access to specific, relevant parts of large guidelines (e.g., ActiveGuidelines project) A clinical information system could then retrieve the parts of the guideline that were relevant to a particular order being considered by a user by searching for the relevant tag. • Information resources are generally not geared to provide specific answers to specific questions  Information resource providers are starting to recognize the need for interfaces to their products that provide answers, rather than documents about the answers (e.g., Micromedex InfoButton Access).

  25. The Role of Standards: What We Can Expect and When

  26. Key Standards and Their Benefits • CDS Development with and without Standards • The key advantage that standardization can provide is the ability to share and re-use knowledge once it is created. • Creation of Knowledge: Studies aimed at discovering knowledge are generally difficult and time-consuming to carry out. We learn about such results through their publication in the literature. Only 14% of literature end up in practice. • Coding Knowledge: the process of encoding knowledge in executable form is not performed reliably, in that knowledge in the form of published results or narratives or even guidelines is subject to many ambiguities. • Knowledge Maintenance: The greater the degree to which the knowledge is integrated into clinical applications, also, the more effort is required to modify instances of its use when update becomes necessary. • It would be highly advantageous if many of these processes could be done only once for a given item of knowledge. • Although a variety of standards are needed to robustly support CDS, some of which are now well defined, many are still primitive or nonexistent.

  27. Key Standards and Their Benefits cont. Tasks involved in deploying knowledge in operational settings

  28. Key Standards and Their Benefits cont. Tasks involved in deploying knowledge in operational settings (cont.)

  29. Key Standards and Their Benefits cont. • Beyond the Standards • Potential capabilities and the benefits that could be derived from standards: • Collections of discovered knowledge of various types could be made widely available in the form of knowledge bases (e.g., Cochrane Collaboration). • The management of the knowledge bases under the authority of external content provider  relieve local sites or vendors from undertaking this task. • Knowledge could be flexibly provided in a variety of ways. • Beyond translation and interfacing to a host platform, local efforts could be confined to customization to local requirements and constraints. • Updates to knowledge could be coordinated by the provider of knowledge, communicated to users, and details of versioning maintained. • Given economies of scale of effort that could be devoted to knowledge update, external knowledge bases would be likely to be kept more up-to-date and reliable than those that are developed or maintained locally. • Knowledge developed and created by local experts could also be uploaded and incorporated into larger knowledge bases.

  30. Key Standards and Their Benefits cont. • Three principal classes of artifacts are needed for standards-based CDS: • Knowledge bases: the business models are for knowledge base provider’s ongoing support, how they are structured, their mode of access or interface, or how they are maintained and updated. • Tools for authoring and update: after knowledge bases are standardized, tools are required for authoring, review, editing, and publishing of knowledge of the types in the knowledge base  facilitate identification of similar knowledge to that which is being authored or modified, to provide a starting point for the work, and to detect potential inconsistencies, contradictions, redundancies, and gaps in the knowledge relating to a specific topic. • Tools for execution: development of execution (engines) tools that will operate on standardized knowledge, and that can be invoked by host environments. The engine should: (1) be invoked by the host when specific CDS functionality is needed (2) obtain data from host EHRs (3) return the results of its evaluations in order that appropriate actions can be initiated by the host systems

  31. How Important are Standards? • It is not immediately clear that the potential for access to external resources and reuse through standardization will have significant benefit in overcoming barriers  the case for the benefits of sharing and reuse as a driver is weak. • Barriers are those that relate to the difficulties in adapting successful demonstrations for use in settings with different clinical settings. • There are not many instances one can point to where such sharing and reuse in fact has occurred  only ~240 MLMs have been made publicly available. • Medical Knowledge Implementation (IMKI) - 2001: goal of creating and jointly contributing to a shared pool of knowledge resources such as MLMs, but after two to three years, it foundered for lack of commitment by participants to making knowledge content available. • Open Clinic (http://openclinical.org): promote awareness and use of decision support, clinical workflow and other advanced knowledge management technologies for patient care and clinical research. • The main purpose for standards development to date in other areas has not been for sharing of external resources but for interoperability of systems standards for CDS have a problem with the business model!

More Related