This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Specializing reason relationship for flavors of indications

From HL7Wiki
Jump to navigation Jump to search

NOTE: Harmonization proposal on public display here for the purpose of commenting and collaborative editing. All your edits are tracked and nothing gets lost. FEEL FREE to improve the proposal and to add any question you want to raise in the discussion. Thanks!

Recommendation for HL7 RIM Change RECOMMENDATION ID:
Submitted by: Gunther Schadow Revision (# and date): 3
Date submitted: 20050212 Committee status: open
Submitted by: Gunther Schadow  
NAME: ActRelationship.typeCode for reason  

Stewards Position

REQUIRED - This table should contain one row for each Steward Committee affected by the recommendation.

TC RECOMMENDATION APPROVAL STATUS AFFECTED ENTITIES OF INTEREST TO TC
(responsibility level: S=Steward; I=Interested)
O&O Unknown I
RCRIM Unknown I
PC Unknown I

Issue

Need to be more specific about the nature of an indication (reason).

Current State

Has reason (RSON) has one specialization already: mitigates (MTGT). No other place to qualify reasons to say how specifically something is a reason.

Recommendation(s)

Add additional ActRelationship subtypes of “has reason” (RSON), thus expanding the hierarchy for types of reasons (indications). Currently HL7 has:

*RSON has reason (indication) The reason or rationale for a service. A reason link is weaker than a trigger, it only suggests that some service may be or might have been a reason for some action, but not that this reason requires/required the action to be taken. Also, as opposed to the trigger, there is no strong timely relation between the reason and the action.

Discussion: In prior releases, the code "SUGG" (suggests) was expressed as "an inversion of the reason link." That code has been retired in favor of the inversion indicator that is an attribute of ActRelationship.

**MITGT mitigates The source act removes or lessens the occurrence or effect of the target act.
and we propose to add as specializations of MITGT
***TREAT treats The source act is intended to improve a pre-existing adverse situation described by the target act. This is not limited to diseases but can apply to any adverse situation or condition of medical or technical nature.
***PRYLX prophylaxis for The source act is intended to reduce the risk of of an adverse situation to emerge as described by the target act. This is not limited to diseases but can apply to any adverse situation or condition of medical or technical nature.
and we propose to add as specialization of RSON and sibling of MITGT
**DIAG diagnostic for The source act is intended to help establish the presence of an adverse situation described by the target act. This is not limited to diseases but can apply to any adverse situation or condition of medical or technical nature.

Rationale

The change is a logical extension of the finer nuances that are already been made with the difference between has-reason and mitigates, it's necessary to describe indications better.

The change is motivated to complete the U.S. national SPL project with FDA and all of Pharma Industry to provide improved drug labeling in HL7 v3 format. It is implementing a requirement from the Physician’s Labeling Rule that became effective in January 2006.

There seems to be a problem with the definition of MITGT particularly as it compares to TREAT. This issue had been discussed within the FDA while considering the use of MITGT. It appears that MITGT encompasses both treatment and prophylaxis, i.e., it includes treatment of an existing disease and prevention of the disease ("lessens the occurrence ...of disease").

To address this, two solutions are possible:

a) adopt these new concepts as specializations of MITGT, because they define things in a more granular way; or

b) clarify mitigation to be consistent with just treatment of an existing condition and not prevention.

Presently the proposal reflects option b), because, on critical reading it appears that perhaps the prophylaxis is not intended to be under mitigation, because "lessens ... the occurrence of disease" may not mean "lessens the incidence of disease" but instead "lessens the existence or prevalence of disease". In any way mitigare means to soften and mitigating the disease would always mean treating the disease, not preventing it (something that doesn't exist cannot be softened.) When speaking of mitigation of a disease of prophylaxis, it is a misuse of the word, because what is being mitigated is not the actual disease condition, but the risk for the disease to actualize.

The difference can be explained very simply: disease or condition actually present: yes - mitigation/treatment, no - prophylaxis, and this has importance for the use of these relationships in decision support systems. So it needs to be clear.

Workaround Considered

Attaching some arbitrary observation, but that would be an abuse of observations.

For the use case at hand -- indication for treatment -- we could use a has-generalization to a SubstanceAdministration code which would classify the administration act as to its intent to mitigate, cure, diagnose, etc. This seems the wrong place to do it, as we are truly qualifying the reason or rationale of administering a substance.

Recommended Action Items

  • Implement the proposed solution


Resolution

This proposal had been discussed and approved in the March 2006 harmonization meeting.