{"id":7718,"date":"2018-10-17T01:09:34","date_gmt":"2018-10-17T01:09:34","guid":{"rendered":"http:\/\/orionhealth.weareiceberg.co\/?p=738"},"modified":"2024-08-13T03:14:18","modified_gmt":"2024-08-13T03:14:18","slug":"digitally-sharing-adverse-reactions","status":"publish","type":"post","link":"https:\/\/orionhealth.com\/global\/blog\/digitally-sharing-adverse-reactions\/","title":{"rendered":"Digitally Sharing Adverse Reactions"},"content":{"rendered":"\n

A project that clinically validates an information model<\/h4>\n\n\n\n

A project is underway to develop a Standard to collect information about Adverse Reactions and make that information available to those who need to access it. Borrowing from the approach used to develop the highly effective\u00a0FHIR\u00ae standard<\/a>, the project is developing a guide that has had cross sector input, and practical validation.<\/p>\n\n\n\n

Adverse Drug Reactions (ADRs) are a significant cause of morbidity and mortality in patients and contribute to the incidence of adverse events. The detection, management, documentation and reporting of ADRs are important for ongoing patient safety.<\/p>\n\n\n\n

The project started by identifying the clinical need, and then collecting the requirements from a group of expert users (including clinicians and analysts). Following this we developed a model to collect this information using the FHIR standard.<\/p>\n\n\n\n

I\u2019ve long been proposing a process to\u00a0involve clinicians in more health IT projects<\/a>(recognising that most of them are more interested in the outcomes of the projects rather than the deep technical details).<\/p>\n\n\n\n

At a high level this process is:<\/p>\n\n\n\n

    \n
  1. Create a number of scenarios that represent what we are trying to achieve in the project.<\/li>\n\n\n\n
  2. Create an information model (or models) to represent the information to be exchanged (regardless of how this is done)<\/li>\n\n\n\n
  3. Validate that the model\/s are fit for purpose<\/li>\n\n\n\n
  4. Map that into the FHIR resources required<\/li>\n\n\n\n
  5. Test at a connectathon.<\/li>\n<\/ol>\n\n\n\n

    One of the other benefits of this approach is also that it provides a path for clinicians who want to learn more about the underlying technology a channel to do so. By involving them in a project of interest to them, it\u2019s an easier way than studying the specification.<\/p>\n\n\n\n

    We’ve been using this approach in the Adverse Reactions project in New Zealand, and we have come up with a Logical Model that the domain experts are happy with. Here\u2019s a screenshot of part of that model \u2013 you can access the full model here:\u00a0http:\/\/clinfhir.com\/logicalModeller.html#s25zx<\/a>\u00a0(And thank you to SMILE CDR\u00a0https:\/\/smilecdr.com\/<\/a>\u00a0for supplying the FHIR server where this model is stored)<\/p>\n\n\n\n

    Note that this model is in no way influenced by FHIR resources (though it does use FHIR datatypes) \u2013 and also represents all the data that could be captured in an adverse reactions report (my openEHR colleagues would likely call this a \u2018maximal data set\u2019) \u2013 you certainly wouldn\u2019t expect an average report to include all these elements.<\/p>\n\n\n\n

    Have a look at the ReactionDescription element. Because the element is coded and has a ValueSet assigned to it (we call this \u2018binding\u2019 to the ValueSet), we\u2019re able to show the kinds of data items we might expect).<\/p>\n\n\n\n

    How do we proceed to step 3? First, we must prove that the model is correct, and it contains all the options needed for submitting reports? After all, it was created by a small number of experts and it would certainly benefit from review by a wider group of people. One way (and the one we usually use) is to send the model out for comment in a paper form \u2013 transcribe the model into a document and ask people for comments. Then have the expert group update the model based on those comments.<\/p>\n\n\n\n

    The trouble is, this is a time consuming and manual process \u2013 and not exactly exciting to do. Unless you are really interested in this topic, are you going to put time into it? An alternative approach is to collaboratively test this at a Connectathon (whether in-person, remote or both) \u2013 and this is what the ConMan tool has been developed to facilitate (Incidentally, the name stands for CONnectathon MANager).<\/p>\n\n\n\n

    The way this works is that the tool takes the Logical Model and creates an on-line form that matches the model into which sample data can be entered to represent the real-life scenarios identified at the start of the process. There are also places where participants can enter comments or notes about the elements in the model \u2013 or the model itself \u2013 which are then available for review and serve as the feedback to help validate (or correct) the model.<\/p>\n\n\n\n

    Some notes:<\/p>\n\n\n\n