Difference between revisions of "HL7 v2.x Insulin Sliding Scales and Tapering"
Smrobertson (talk | contribs) (Created page with "{| style="width:100%; background-color:transparent;" |- | style="vertical-align:top; width:50%" | <!-- LEFT COLUMN --> __TOC__ | style="vertical-align:top; width:35%" | <!-- RI...") |
Smrobertson (talk | contribs) |
||
| Line 45: | Line 45: | ||
Without considering the clinical appropriateness, assume we are attempting to code the following (the blue text is the portion to be encoded). | Without considering the clinical appropriateness, assume we are attempting to code the following (the blue text is the portion to be encoded). | ||
| − | 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 | + | 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 | 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| | + | |^^^^^^^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 | 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: | 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| | + | |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. | 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. | ||
Revision as of 17:56, 16 November 2011
Contents |
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 (the blue text is the portion to be encoded).
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.
