The Challenge
In the context of Gravitate Health project, one of the most prominent objectives is to provide patients with the information they need about their medications. However, this information needs to be adapted to the context and preferences of the end-user to achieve effective and optimal understanding.
A lot of progress has been made since Hackathon #1, and now there are many annotated ePIs, the Gravitate Health Implementation Guide (IG), and several lenses. At Hackathon #2 the challenge will be to design more lenses and contribute with more ideas on lenses-i.e. how to personalise medicines information.More specifically, to Develop G-lenses (a ‘G-lens®’ is a piece of code which encodes certain knowledge required to better adapt the content of product information) using:
(1) the Gravitate Health FOSPS*,
(2) ePIs with embedded semantic annotations (using standard terminologies such as SNOMED-CT, LOINC, ICD 10, iCPC-2),
(3) a persona vector i.e., the information relevant to the patient’s health in an International Patient Summary-IPS, and
(4) the patient’s current context and preferences, create a lens that effectively and optimally adapts the content to preferences and context to provide the patient with relevant information about his/her medicines.
A set of resources will be available well in advance of Hackathon #2 for participants.
*FOSPS: federated open-source platform services
Because there are many ways to adapt information, the concept of “G-lens®” was developed to modularise the approaches to information focusing. A G-lens® is a piece of code which encodes certain knowledge required to better adapt the content. Within the G-lens® execution environment, the executable will have access to the content, in this case the ePI, with embedded semantic annotations (using standard terminologies such as SNOMED-CT, LOINC, ICD 10, ICPC-2), as well as the persona vector; this is all the information relevant to the patient’s health (i.e. International Patient Summary, IPS) as well as the patient’s current context and preferences.
The G-lens® can effectuate changes on the presentation of the content, these changes are categorised in 2 types: attention detail modification (“highlight”, “collapse”), addition of supplementary information (hyperlinks, images or videos, etc.).
In our system design, think of “lenses” as special tools coded in Java Script. These tools have access to the document you’re working with and some structured data about the user’s health and preferences.
Under no circumstances lenses are allowed to remove content, as ePI are highly regulated documents.
Lenses can be categorized by the type of knowledge and objectives they are encoding, here are some examples:
- Generic Medicine knowledge (e.g. General recommendations, processes)
- Personal Preferences (e.g. pictograms, terminology, text – speech)
- Condition (e.g. Pregnancy, smoker, allergies, etc.)
- Chronic, Specific, or rare Disease (e.g. Diabetes, Hypertension, Arthritis)
- Adapting to patient’s Health Literacy
- Dealing with side effects
- Enhancing Patient Safety
- Adding Health Care Professional advice
- Linking to Local Social/Wellbeing services (e.g. provide the link to call directly the nearest anti-poison centre)
- Embedding additional material
- Enhancing Accessibility
- Dealing with drug Interactions, e.g. food-drug, add drug to therapy regime (med list)
- Accessing Open Data (e.g. allergy medication + pollen count in the zone)
*FOSPS: federated open-source platform services
BACKGROUND INFORMATION
[1] FIRSTLY, LET’S BE CLEAR ON WHAT EXACTLY IS AN ePI
ePI stands for “electronic product information”, which refers to digital versions of product information leaflets or package inserts for medicinal products.
These are documents that provide important information about a medication, such as its dosage and side effects. The existence of ePI, makes producing, maintaining, distributing, and accessing medication information easier. ePIs are designed to be accessed electronically, such as on a website or through a mobile application and are intended to replace the traditional paper-based product information leaflets that are included in medication packaging.
By providing this information in a digital format, ePIs can be updated more easily and frequently than paper-based versions and can also be tailored to specific audiences or languages.
[2] WHAT IS A RAW ePI
Raw ePI refers to the (semi)structured, machine-readable version of the electronic Product Information (ePI) for a medicinal product. It typically includes the SmPC (Summary of Product Characteristics), Package Leaflet (PIL), Labelling information, as well as chemical information and even clinical information. This is structured using the HL7 FHIR standards and can be encoded in a standard markup format (such as JSON or XML).
[3] WHAT IS AN ANNOTATED ePI
ePIs can be semantically annotated, i.e., the process of identifying and labelling important concepts, entities, and relationships within a given piece of text. This will allow the patient information to become relevant for a patient when combined with his/her condition and preferences and transform it to “personalized patient information”.
The goal of this semantic annotation is to create a structured representation of the information contained within the unstructured text, making it easier to analyse, search, and understand.
This can be useful in a variety of applications, such as information retrieval, text classification, and sentiment analysis.
This can involve the use of various natural language processing (NLP) techniques, including named entity recognition (NER), part-of-speech (POS) tagging, and syntactic parsing, among others.
[4] WHAT IS FOCUSING
In particular the application which annotated ePIs will be used for is what we call focusing. This is having identified the concepts that specific words or phrases refer to, and with the context and preferences of the user, each can be determined to be highlighted, for the particular user, because this concept is extremely relevant to them, or collapsed, allowing the patient to safely skip this information as it does not apply to them.
As a result of Hackathon #1, ePI preprocessing modules were created: given a FHIR format ePI, preprocessed ePIs will automatically add annotations to the content, keeping it in FHIR format for later use in the focusing mechanism. ePI preprocessing modules do not need to address all annotations, they may focus on specific knowledge; ePI preprocessors may be stacked, i.e., executed sequentially, to generate a complete annotation of the ePI. The annotation will employ standard terminologies such as SNOMED-CT, LOINC, ICD 10, ICPC-2, as well as International Patient Summaries (IPS’s). Automatic preprocessors are preferred since they will better address the scalability challenge of annotating thousands of ePIs.