Allergy Intolerance UseCase Storyboards
Allergy/Intolerance use cases/storyboards
Care Provision Domain Models: Explanation & Guidance A_AllergyIntoleranceUniversal (REPC_RM000320)
1. Introduction: However good they are, the model diagrams and formal walkthroughs in the Care Provision Domain cannot give enough guidance to engineers writing implementation guides to ensure good clinical functionality in the document, message, and service specifications created from the models. This file is intended as a reference to help engineers who are writing implementation guides, either within the HL7 publication databases or for publication outside of HL7.
As the body of HL7 document, message, and service specifications matures with the writing of more and more implementation guides, these artifacts will create additional examples that can be studied by implementation guide writers. In addition, implementation guides actually tested in production will provide “proof of concept” for these models: sometimes validating the models; sometimes justifying changes in the models. In this guide, areas of “immaturity” in the models will also be discussed.
This example deals with different parts of the allergy and intolerance R-MIM of patient care.
This are ideas to complete the allergy and intolerance R-MIM in the Care Provision ballot.
2. What are we talking about?
Definition from NEHTA in Australia seems quite adequate
Definition Adverse reaction is A harmful or undesirable response to an agent/substance. An adverse reaction may occur within a variable timeframe after exposure to an agent/substance and may range from minor reactions like a skin rash to serious and life threatening events such as anaphylaxis. Exposure may be by ingestion, inhalation, injection or direct contact. An adverse reaction includes allergies, intolerances and sensitivies. An adverse reaction does not include poisoning, medical errors or mishaps that may occur during surgical or medical care, as these are generally classified as an adverse event. Synonymous Names Allergic reaction, Allergy, Intolerance, Sensitivity
3. Use cases around allergy / adverse reaction in clinical practice:
1. The process of identifying adverse reactions is a critical element of good clinical practice and is essential for safety and quality (Nehta). Value Domain Reaction description values http://nis-web.fhs.usyd.edu.au/web_nis/
Example: a patient enters the doctors office with a rash and other signs and symptoms. Doctor concludes to an allergy to a particular substance.
2. Documenting adverse reactions / allergies in the patient record
The nurse discovers an allergic reaction and notes it in the patient record
3. Exchange of adverse reactions among health care providers
A gp refers a patient to a internist and mentions in the referral message that the patient is allergic to penicillin.
4. Carrying out an allergy test (ordering, testing, results presentation) The anaesthetist orders an allergy test for iodine as preparation for an
5. Making an allergy list / list of adverse reactions
The dermatologist makes for a patient a list of known allergies
6. querying a record system for patients that have a particular allergic reaction
Example: surgeon introduces a new type glove and believes after a while he sees more allergies. He wants to compare the number of allergies for gloves before and after and queries the EHR for all patients with glove allergy in the record to assist in appropriate hypothesis formulation.
7. Adverse reaction outcome (Nehta).
Definition The state of well-being of the subject of care after experiencing the adverse event and being treated for it, if required. Context Information about the clinical status of the subject of care after the adverse reaction occurred and was treated.
Example: Gp reports that a rash is gone after treatment.
8. Adverse reaction status (Nehta) Definition An indication of whether the stated adverse reaction is considered an active or inactive health issue, as determined by a healthcare provider.
The anaesthetist determines that the iodine allergy is still active.
4. Storyboard: Physician Evaluates a Rash: use case 1. Precondition: Dr. Patricia Primary is viewing the EMR of Patient Everyman. Dr. Everyman has come to clinic to have a rash evaluated. The allergy list is empty. Activities: Dr. Primary elicits the patient history. The patient has visited an Indian restaurant for the first time and was exposed to many new spices. The patient wonders whether the rash is due to the spices. Dr. Primary examines the rash and notices the typical linear pattern associated with a plant exposure. She questions the patient further and finds the patient had been hiking in the woods earlier in the week. The patient has never had poison ivy. Dr. Primary assures the patient that allergy to Indian spices is unlikely to be the cause of this rash. Rather, Dr. Primary identifies probable poison ivy and educates the patient on the disease. She places Poison Ivy on his allergy list and gives the patient a prescription for Prednisone for the poison ivy. Post-condition: Mr. Everyman has progress notes, findings, impressions, care plans, and a populated allergy list in the EMR that are captured in a manner that allows navigation from one related data item to the next. Specifically, the user is able to navigate from the current name of the allergy on the allergy list to the string of observations and treatment activities associated with management of that allergy over time. Additionally, the user is able to navigate from a data item to the allergy management programs supported by the data element.
5. Storyboard: Physician Manages Allergy List; use case 5 above Purpose: To illustrate common practices in allergy management. Precondition: Dr. Patricia Primary is viewing the EMR of Patient Everyman. Dr. Primary has completed the subjective and objective portions of the visit and is now drawing together the findings into an impression of the patient. Dr. Primary has a referral relationship to an allergist, Dr. Richard Reaction. Activities: Dr. Primary identifies two findings that support the diagnosis of a poison ivy allergy: an itchy rash with linear patterns of distribution; and a potential exposure while walking in the woods prior to the rash. She then places Poison Ivy Allergy on the allergy list. She identifies two findings that support the diagnosis of spring pollen allergies: a history of sinus infections in a seasonal pattern and a family medical history of allergies. She also places the Spring Pollen Allergies on the allergy list and activates a care plan with anti-histamines as needed and a referral to an allergist, Dr. Reaction, for assessment of the Spring Pollen Allergies. Penicillin with a reaction of hives is also placed on the allergy list. The referral appointment for the allergy concern assessment is scheduled. When the allergist, Dr. Reaction, views the referral document for the Spring Pollen Allergies, he navigates from the allergy list to the respective diagnoses, findings, and care plans for each allergy in order to validate the data. He imports the data into his EMR system. He modifies and adds to the basic data in his EMR. These updates and additions include more detail on the symptoms and timelines related to the “Spring Pollen Allergies,” the family medical history of allergies, and more information on the penicillin allergy. He applies skin tests for multiple allergens, including spring pollen allergens and penicillin, and asks Mr. Everyman to return for readings on the tests. When Mr. Everyman returns, Dr. Reaction reads the tests, identifies the positive reactions to Pine Pollens, and updates the allergy list including revising the Spring Pollen Allergy and removing the penicillin allergy. Dr. Reaction returns the information to Dr. Primary in a referral report (consultants’ report) document along with recommended updates to the care plans. Dr. Primary reviews the recommendations from the allergist and adjusts the care plans to include a repeat visit by Mr. Everyman to discuss the recommendations. Dr. Primary also updates the allergies on the allergy list with more specific descriptions of the allergies and marks the penicillin allergy as obsolete. Post-condition: Mr. Everyman has progress notes, findings, impressions, referral documents, care plans, and a populated allergy list in the EMR that are captured in a manner that allows navigation from one related data item to the next. Specifically, the user is able to navigate from the current name of the allergy on the allergy list to the string of observations and treatment activities associated with management of that allergy over time. Additionally, the user is able to navigate from a data item to the allergy management programs supported by the data element.
Note: In order to support this storyboard, HL7 has generalized allergies into the concept of “Concern.” In addition, since allergy is treated as a kind of HL7 Concern, tracked in the condition tracker, the reader should first review the HL7 approach to Concerns in the Condition Tracker R-MIM in this document. Allergy Lists are also a kind of HL7 Concern List. Although allergy truly is a “negative” kind of “concern, the term “Concern” is used generally in HL7 because it is less negative than “problem,” i.e. management of normal pregnancy or wellness is not considered management of a “problem.” In addition, assessing and optimizing the condition of a patient is considered central to effective healthcare by clinicians. Much of the following is shared by the generalized discussions under Concern List and Concern Tracking. Additional guidance on the use of the Concern List and Concern Tracking structures in the specific use cases of allergy and intolerance is given following the general discussions below.
6. Allergy Guidance: When the substitutions of concern names are made in the storyboard, the table for allergy values looks like:
time: Month Concern A tuple Concern B tuple March Aa: Nasal congestion-active May A**: Spring pollen allergy-active June A**: Spring pollen allergy-active Bb: Sinus headache-active July A***: Spring pollen allergy-obsolete B****: Pine Pollen allergy-active
Supporting Data Elements in Allergy: Strictly speaking, the organization of data within the supporting data elements of the EHR is not directly relevant to the high level description and versioning of the episode of illness. However, allergy data is commonly communicated along with adverse reaction determinations and symptoms, and the allergy model includes specific modeling in the areas of causality assessment and exposure events which is generally important in hospital medicine and clinical trials. Although many end-users in healthcare focus on the communication of medication allergies once the allergies have been identified by patient or clinician, this focus tends to hide the clinical picture of how allergies are identified, confirmed, and managed over time. To pull the reader out of the medication focus, the poison ivy storyboard is helpful.
7. A_AllergyIntolerance (REPC_RM000320) R-MIM
AllergyIntolerance Structure The AllergyIntolerance Structure is a collection of classes that represent the allergies, the intolerances, and the adverse reactions that occur because of these conditions in a living subject. This RMIM will be changed, in the near future, to reflect the idea of a 'concerning condition' recently completed in the Condition Tracking RMIM This structure is used to support the creation of implementation guides for messages, documents, services, and rules. More detail on the definitions and use of this structure may be found in the reference document, "Explanations and Guidance for the Care Provision Domain."
AllergyIntolerance Structure Walk-through: 8. AllergyIntoleranceStructure Overview: The AllergyIntolerance Structure includes a collection of classes including Observation, Substance Administration, and Control Acts. It also includes modeling of materials and numerous Act Relationships. These will be described in detail here, beginning with the Act classes. The definitions for class attributes are available in Reference Information Model (RIM) documentation and will not be repeated here. However, the description of the attribute meaning in a message or other communication after the constraints are applied will be described for each class attribute. For a full description of the application of various constraints, please see the associated RIM documentation. A short synopsis is included for ease of reference: Structural Attribute: attribute that is constrained to "immutable," i.e. constrained from being changed once the instance is created. The list of these attributes is documented in the RIM. Mandatory Attribute: bolded attribute in the VISIO and in the tables below it shows as M, which means that the field/association must be present in the message (or other implementation guide), otherwise the message is invalid and is non-conformant. For Mandatory fields, HL7 sets the minimum cardinality to 1 (a value must be present) and set the additional requirement that the attribute shall not be valued with HL7 Flavors of Null Required Attribute: * attribute which places a constraint on the sending system. If the data is available to the sending system, then the field/association is included in the message. If the minimum cardinality is 0 and the data is not available, the field/association may be omitted from the message and still be conformant. If the minimum cardinality is 1 and the data is not available, a NullFlavor is required. Optional Attribute: (0...1) attribute without a * may or may not be present in a message (check the specific qualified meaning of this notation when found with a * in the "Required Attribute" definition above). Datatype: a specification for the information model of the attribute value, often a complex pattern that builds upon the traditional computer science ontology of "primitive datatypes," e.g. string; float; real number; etc. Vocabulary Domain: an attribute constraint that allows implementation guides to bind a specific set of codes (value set) to a specific attribute. X_Value Set: an attribute constraint that blocks implementation guides from extending or constraining the named value set in the diagrams by binding other HL7 value sets to the attribute. CWE: an attribute whose vocabulary domain may be extended by codes outside a value set published in an implementation guide CNE: an attribute whose vocabulary domain shall not be extended by codes outside a value set published in an implementation guide
9. Allergy RMIM Explanatory Walkthrough:
ObservationEvent: As in the previous example of “Sinus headache,” the first time that the EMR might capture a data item later associated with an allergy concern is with some seemingly unrelated “reason for an appointment.” In this “Rash Storyboard,” the reason for visit” or “chief complaint” was “Rash.” In the Allergy RMIM, the “ObservationEvent” clone in the lower-left-hand-corner of the model represents the “pre-causality” determination set of observations on the patient including history, physical exam, and any other preliminary impressions. In some cases, these instances of Observation (with instance identifiers) may have been communicated from another system, such as a stand-alone scheduling system. Modeling of ObservationEvents follows all the same patterns described in various implementation guides for specific kinds of observations such as history, symptoms, physical exam items, and impressions. Guidance: Note that the appearance of a symptom or diagnosis may “kick off” or trigger the remaining actions in this allergy model. In other words, a patient who appears in the office with a rash may trigger a guideline (see Care Plan below) that includes evaluation of causal exposures and the need for management. Although the mood of this class will be EVN in most medical record assertions, the mood of this class in Definition mood might be paired in a guideline with the same class in EVN.CRT mood. In other words, this class may appear in DEF mood pair with the same class in EVN.CRT mood and a MATCH ActRelationship between the moods as a predicate for a care plan. Note: This area of the model is immature in the sense that EVN is included in the model to meet immediate needs; but clearly the mood may need to be extended to DEF, EVN.CRT and even other moods to meet the needs of Care Plans. ExposureEvent: as noted in the Rash Storyboard, there may be one or more exposure events identified. In the hospital or clinical trial, this exposure event may be identified with a specific known material, such as a product from a given manufacturer, and then the model includes support for identifying the specific material. In the ambulatory environment, these exposure events are likely deduced from less definitive knowledge about the specific materials involved, and the communications will be sparser in terms of detail regarding the material. In either case, the Exposure Event is a SubstanceAdministration event, whether the substance was administered accidentally or by design. Modeling of SubstanceAdministrationEvents follows all the same patterns described in various implementation guides for specific kinds of substance administrations such as pharmaceutical administrations, dietary history, and accidental exposures. CausalityAssessment: The subject (Act Relationship Subject) of the causality assessment is the ObservationEvent. The ExposureEvent is identified either with ActRelationship ”Implicates.” Observation.code in causality assessment is a kind of observation that allows a Secondary Observation (source act) to assert (at various levels of probability) that the target act of the association (which may be of any type of act) is implicated in the etiology of another observation that is named as the subject of the Secondary Observation. Examples: causality assertions where an accident is the cause of a symptom; predisposition assertions where the genetic state plus environmental factors are implicated in the development of a disease; reaction assertions where a substance exposure is associated with a finding of wheezing. In Observation.value, the conclusion of the assessment should be specified, e.g. from the storyboard, “not a food allergy;” “probable environmental allergy;” “drug intolerance;” or otherwise as specified in the implementation guide.
10. Allergy list as part of the care statement / act list within Care Provision D-MIM
In an early attempt to exchange information on allergies, a simple act / observation instantiation from the care statement has been used. Clinicians came up with a kind of long list. This has been put in a simple care information model, which in later stage has been enhanced by the new R-MIM in care provision, listed above.
Please find this document attached to this in a separate message to circumvent the zip, zap problems.