We work with GRADE guidelines, and due to their methodological rigor all guidelines and recommendations have the same main components and follow the same development steps. We have broken these components down to structured digital elements, and use these components to guide authors through the development steps. In following the GRADE steps, and writing the components into our structured electronic platform, the guideline authors have moved from constructing a document to producing discrete elements of information.
A very central element in this guideline structure, is the PICO element. PICO is a way of structure a clinical question, into the elements of population, intervention, comparator and outcome. There have been many variants of PICOs proposed, with various names like SPICE, PIRO, PICOS, but they essentially do the same – structure the elements of a clinical question a specific elements.
In the PLUGGED IN approach, we use the PICO elements as a basic coded element, which we can link to other information elements, or systems. The MAGIC platform lets guideline authors specify and code their PICO elements, using various existing ontologies and terminologies. We let the authors that write the guidelines code their PICOs themselves, as they are the ones that know their content best, and can choose the most appropriate terms.
Behind each recommendation you will find one or more or PICO questions, and therefor also find all the structured terminology the authors have added to these PICOs. The authors can also add relevant clinical variables to a recommendation directly, like laboratory tests, observations, disease groups, medications as supporting information. These clinical variables are not to be seen as exclusion and inclusion criteria for the recommendation, but rather as useful supporting information for the clinicians when making a clinical judgment.
With PLUGGED -IN we have a new way to present recommendations combined with clinical elements to personalize advice. We present structured multilayered guidelines developed with GRADE methodology within the Electronic Health Records, and through an API the Electronic Health record get to know which clinical items the authors thought was relevant. The Health record system can then choose to display this information within its own firewalls. If there are elements the health record system do not have as structured elements (different systems have different degree of information available as structured elements), they simply don’t show it. The recommendation is not dependent on this information being showed, having it there just facilitates the contextualization for the clinician. Setting it up this way allows all electronic health records to integrate with the guidelines, no matter what level of structure they have.
In the PLUGGED- IN research program, we will to study how this link between fully digitized and ontology coded guideline, and patient specific data in the EHR will work technically for the electronic health record systems, and practically for clinicians.
The main idea is that if your guideline is developed in small structured parts, you can show different levels of detail to clinicians, depending on their need there and then. At point of care there will be a need for more or less information depending on complexity of situation and the information need of the patient. When these small structured parts are coded using current existing ontologies and terminologies, we can link that automatically with patient specific data from the EHR, of your current patient.
This approach will allow a correct use of weak recommendations where rules and algorithms are of little use and clinicians need access to information underlying recommendations to facilitate well informed decisions with patients.
For some recommendations the traditional approach in CDSS with alerts and reminders are of course still of relevance, but we encourage developers to think through the implications of using especially weak recommendations for this purpose.
Having the guidelines and recommendations in a more structured format will also greatly facilitate the development of Decision support, including alerts/reminders, order sets and suggestions . Through the PLUGGED-IN project and our work with Flow of data we will investigate both the use of Guidelines directly in the Electronic Health Records and how the single recommendations and the knowledge within can be used in Decision support systems.
Screenshots below shows the idea behind using the guidelines directly as Lightweight decision support in the Electronic Health Records, developed through the PLUGGED-IN project.
The interaction between an EMR and a recommendation relies on the presence of structured information in both the recommendations and the EMR and exchange of this information via APIs. This means that any EMR system can make use of the structured information behind a recommendation, to the degree which it can make use of the information. The EMR system will stay in total control over how, and what information to display, while the range of relevant items is set by the guideline authors.
An EMR with structured drug information in it’s own system, can use the structured drug information in a recommendation to highlight this drug on the patients medication list if there, if it was ever there or offer it to the clinician as a possible order.
An EMR without structured drug information in it’s own system, might still use the structured drug information in a recommendation to be able to free text search for the drug name in clinical notes
When activating (clicking to look at more information) a recommendation the EMR are allowed to pick up all the codes and clinical elements from that recommendation to contextualize the view of patient specific information.
The EMR system will also be allowed to send over search terms to narrow down the list of possible recommendations that will fit the activated patient.
This way the two systems, guideline platform and EMR system, can help each other contextualize their information to help their clinicians find the information they need.
You need two things: