Difference between revisions of "HL7 v2.x Insulin Sliding Scales and Tapering"
Smrobertson (talk | contribs) |
Smrobertson (talk | contribs) |
||
| (3 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"> | + | :<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> | ||
| − | == | + | ==email thread== |
| − | [[HL7_v2x_Insulin_Sliding_Scale.pdf]] | + | [[file:HL7_v2x_Insulin_Sliding_Scale.pdf]] |
| − | --[[User:Smrobertson|Smrobertson]] 18: | + | --[[User:Smrobertson|Smrobertson]] 18:50, 16 November 2011 (UTC) |
Latest revision as of 18:56, 16 November 2011
|
Related Links |
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:
| 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)
