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

Difference between revisions of "HL7 v2.x Insulin Sliding Scales and Tapering"

From HL7Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 27: Line 27:
  
 
== Response ==
 
== Response ==
 +
 +
'''It is possible to encode much of the discrete content of a sliding scale dosing scheme, but it does not appear to be complete enough to rely clinically on a v2.x representation.'''  Also, there is concern that this approach can scale to more complex dosing schemes
 +
 
===Prior to v2.5===
 
===Prior to v2.5===
 
ORC.7 and OBR.27 carried the order timing information in the TQ data type.  The TQ data type has the following components:  
 
ORC.7 and OBR.27 carried the order timing information in the TQ data type.  The TQ data type has the following components:  
Line 64: Line 67:
  
 
Without considering the clinical appropriateness, assume we are attempting to code the following
 
Without considering the clinical appropriateness, assume we are attempting to code the following
:<font face=Courier style="color:darkred">|Inject 0 units before meals if BG<100, 5 units for BG > 100, 10 units if BG>200, 15 units if BG>300 and call MD </font>
+
:<font face=Courier style="color:darkred">Inject 0 units before meals if BG<100, 5 units for BG > 100, 10 units if BG>200, 15 units if BG>300 and call MD </font>
  
 
What I would typically expect from a pre-v2.5 implementation would be no detailed encoding, ORC.7 would appear as  
 
What I would typically expect from a pre-v2.5 implementation would be no detailed encoding, ORC.7 would appear as  
Line 84: Line 87:
 
</font>
 
</font>
  
==Complete email thread==
+
==email thread==
 +
 
 +
[[file:HL7_v2x_Insulin_Sliding_Scale.pdf]]
  
[[file: HL7_v2x_Insulin_Sliding_Scale.pdf]]
 
  
--[[User:Smrobertson|Smrobertson]] 18:36, 16 November 2011 (UTC)
+
--[[User:Smrobertson|Smrobertson]] 18:50, 16 November 2011 (UTC)

Latest revision as of 18:56, 16 November 2011


Question

(simplified) How do you represent a sliding/tapered dose in HL7 v2.x?

Response

It is possible to encode much of the discrete content of a sliding scale dosing scheme, but it does not appear to be complete enough to rely clinically on a v2.x representation. Also, there is concern that this approach can scale to more complex dosing schemes

Prior to v2.5

ORC.7 and OBR.27 carried the order timing information in the TQ data type. The TQ data type has the following components:

TQ Data Type
SEQ DT COMPONENT NAME COMMENTS
1 CQ Quantity
2 RI Interval
3 ST Duration
4 TS Start Date/Time
5 TS End Date/Time
6 ST Priority
7 ST Condition
8 TX Text
9 ID Conjunction
10 OSD Order Sequencing
11 CE Occurrence Duration added in v2.3.1
12 NM Total Occurrences added in v2.3.1

Without considering the clinical appropriateness, assume we are attempting to code the following

Inject 0 units before meals if BG<100, 5 units for BG > 100, 10 units if BG>200, 15 units if BG>300 and call MD

What I would typically expect from a pre-v2.5 implementation would be no detailed encoding, ORC.7 would appear as

||^^^^^^^0 units before meals if BG<100, 5 units for BG =100 to 199, 10 units if BG=200-299, 15 units if BG=300 or more and call physician|

This is simply embedding the complex dosing in the text component of ORC.7

Realizing that was not the intent of the question, I attempted to utilize the capabilities of the TQ data type, and came up with:

|0&Units^AC^^^^^BG<100^^A~5&Units^AC^^^^^BG=100 to 199^^A~10&Units^AC^^^^^BG=200 to 299^^A~15&Units^AC^^^^^BG=300 or more and call physician|

While this does further encode the timing sequence, it doesn't add much functionality. Each of the TQ repetitions express subsequent steps of the sliding scale, but the TQ.7 Condition component is limited to a textual representation of the scale criteria. (The "A" in TQ.8 indicates that the timing element are asynchronous - they all happen at the same time, but only the repetition where the condition is satisfied is performed.) It may be possible to codify the step criteria by breaking the elements of the sliding scale into separate ORC's, but that would create a series of interdependent orders, one for each step of the sliding scale (i.e., there would be a different prescription for each sliding scale step) and I considered that to be an inappropriate path to follow further.

v2.5 and later

The Timing Segments (TQ1/TQ2) are available starting in v2.5. TQ1 essentially replaces the TQ data type (TQ data type field are deprecated in v2.5). The advantage of TQ1 comes from promoting the TQ components to TQ1 fields. Fields can repeat, components cannot - which was an issue for some timing specifications. TQ2 allows the timing specification to reference the results/outcome/status of another order, which was not possible with the TQ data type. Unfortunately, the TQ1/TQ2 segments do not include codified criteria - TQ1.10 remains text. The equivalent of the last example above would be:

TQ1|1|0^Units|AC|||||||BG<100||A<cr>
TQ1|2|5^Units|AC|||||||BG=100 to 199||A<cr>
TQ1|3|10^Units|AC|||||||BG=200 to 299||A<cr>
TQ1|4|15^Units|AC|||||||BG=300 or more and call physician<cr>

email thread

File:HL7 v2x Insulin Sliding Scale.pdf


--Smrobertson 18:50, 16 November 2011 (UTC)