Difference between revisions of "HL7 v2.x Insulin Sliding Scales and Tapering"
Smrobertson (talk | contribs) |
Smrobertson (talk | contribs) |
||
| Line 75: | Line 75: | ||
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. | 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: | ||
| + | :<font face=Courier style="color:darkred">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> | ||
| + | </font> | ||
| + | |||
| + | ==Complete email thread== | ||
| + | |||
| + | --[[User:Smrobertson|Smrobertson]] 18:36, 16 November 2011 (UTC) | ||
Revision as of 18:36, 16 November 2011
|
Related Links |
Question
(simplified) How do you represent a sliding/tapered dose in HL7 v2.x?
Response
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>
Complete email thread
--Smrobertson 18:36, 16 November 2011 (UTC)
