Page tree

718 View 2 Comment In discussion Comments enabled In the category: Undefined

As you know, we're trying to implement SCT to capture allergies in our EHRs. Our goal is to make clinical information reusable and to use it to trigger alerts and clinical pathways.
In our EHR, we have in the clinical notes and reports an "allergy" field where clinicians can document the presence or absence of an allergy (in the broad clinical sense, also the pseudoallergies). This field is what we call a "recurrent field" meaning that the information captured in this field goes to a central "permanent" patient summary, that can be viewed separately form the notes, and that whenever a clinician opens a new empty clinical note, the field allergy in this note will automatically be filled in with the allergy data already present in the patient summary.
Now this allergy field is not a free text field but linked to a dictionnary of terms (that can be updated if some clinicians detect a missing term or expression). Previously it was a rather bad ICD-based dictionnary, so it wasn't much used. Now we work on a SCT-based dictionnary. A first basic dictionnary of 500 SCT-liked french terms is in production since August in a number of our participating institutions and we're working on adding more clinical expressions / concepts to it.

We had one term in the dictionnary that was "no known allergy". Now clinicians ask for more specific "no known allergy" terms that would include the causative agent, like no known allergy to latex. Because you could be allergic to penicilline and not allergic to latex and the surgeon would want to know that the question has been asked and you're not allergic to latex. So "no know allergy" for when the patient is allergic to nothing is not enough. We need also to record the absence of allergy to specific substances.

Now there are not many "no known allergy to X" SCT terms and I wonder even if there should be any. Should the negation, the absence of a disease or a finding not always be outside the terminology and be a postcoordination of the existing positive clinical concept?

If the negation is in the concept, precoordinated, when the patient becomes allergic, you can not consider this as an update to your existing entry, you have to create a new record line for the allergy and the old no known allergy to the same substance will remain visible as an "inactive" former "disease record". Clinicians find it confusing. They would wish the no known allergy entry to be "written over" if the patient becomes allergic to the same substance.

We have a similar "switch" problem between concepts with allergic reaction and allergic disposition. When you record an allergic reaction in the contact nr1, this diagnose will go to the patient summary but on the visit nr2, what you want to have in your problem list is the mention of an allergic disposition. And what you want is to get this allergic disposition to trigger warning when you prescribe exams, drugs or to the kitchen for the food given at the hospital. So in an EHR, you actually need a layer above SCT that will automatically switch from one concept to the other, from reaction to disposion, when you store the captured allergic reaction concept in the patient summary if you want to re-use your information in the patient summary in the next event and as trigger of clinical actions/pathways?

How is this handled in the EHRs that use SCT right now? Anyone knows? Any advice on whether I should put the negation outside my dictionnary (postco) or inside (using the few no known allergy concepts and creating eventually more of them locally)?

Thanks beforehands for your input.

Contributors (2)

2 Comments

  1. Marie, in our EHR we don't use "no known allergy to x" but rather just no known allergy. Allergies are documented in 2 ways:

    1. As diagnoses mapped to SNOMED CT. These are used for problem list entries and to associate with allergy procedures such as testing or shots
    2. In a separate allergy section. This consists of fields for causative substance, type of reaction i.e allergy, intolerance, symptoms, severity and no known allergy. This section is used to trigger alerts if a substance on the list is ordered. The field values are added from dropdown lists and derived from SNOMED CT.

    Updating the information for both of these methods is up to the doctors and nurses. Allergy information is required to be reviewed at each visit and by all departments. If not updated after a certain point, ordering new medications is blocked. I can show you screenshots if you would like.

  2. Dear Bruce,

    Thanks for your answer. It would be very interesting for us indeed to see how it's sucessfully done elsewhere, so as not to reinvent the wheel. We had thought to do something like that with our belgian simplified CBB model, with a field for the reaction type, the substance, the manifestation and its severity but the clinicians and the ERH provider seem to find its "too many clicks" and wonder if we should not just have have a dictionnary with the terms allergy to x or intolerence to y in the allergy section of the EHR. Those wanting to register there more informations could use a free text box next to the dictionnary (what is in the free text box would then not be SCT-linked or could be SCT-linked though a later NLP run) or write their full expression in the dictionnary field. If you wrote your clinical expression, say "mild allergic dermatitis due to pinda's", in the dictionnary field, it would be submitted to the terminologist, to be incorporated in the dictionnary as a french expression linked to the the SCT postcoordinated equivalent. It would then become a reusable expression available to everyone in the dictionnary. What do your clinicians say of the "number of clicks" involved with your four fields? How many fill in all the fields and how many stop at the first two (reaction type and substance)? Are they all mandatory? I suppose not, just the first two. Do you have any idea of the statistics of use and level of "user-happiness" with this solution?

    Now as to the absence of a specific allergy, we do have currently a status attached to the data captured with a dictionnaries: confirmed, suspected, excluded ( = confirmed no present) and error (ex: the status you put if it was encoded for the wrong patient since the data is never overwritten just deactivated). I though maybe the best way to provide the clinicians for terms like "not allergic to latex" (meaning we asked the specific question and he said he's not allergic) would be to allow for capture of "allergy to latex" concept with an associated status of "excluded".  If that patient would become allergic to latex, you would just need to change the status from excluded to confirmed. And in the historical view for your allergies you'd get

    (inactive)    Allergy to latex - excluded .       from 10/1/2000 to 5/5/2016 

    (active)       Allergy to latex - confirmed .     from 5/5/2016 - current

    Seems to me the meaning would be clear to the clinician both reading the entry and read the historical log later. We would "just" need to take into account the status field when building our alerts. But that would be intersting for any disease or disorder, to be able to capture the confirmed absence of it. What do you think of this approach?