Electronic Pharmaceutical Messaging Standard
HISO 10030.2
To be used in conjunction with HISO 10030.1 Electronic Pharmaceutical Business Processes Standard
Copyright information
This document has been approved as a standard for the New Zealand health and disability sector by the Health Information Standards Organisation (HISO), a sub-committee of HISAC.
The copyright owner of this document is the Health Information Strategy Action Committee (HISAC), which is a ministerial committee appointed by the Minister of Health. HISO work on this document may be reproduced in any number of copies and in any format or medium provided:
• the content is not changed; • the material is not sold; • the material is not used to promote or endorse any product or service; • the material is not used in an inappropriate or a misleading context having regard to the nature of the material; • any disclaimers included on the published information are reproduced on the material; • a copyright acknowledgment to the Health Information Strategy Action Committee is included.
Permission to reproduce HISAC work does not extend to include any work identified in this document as the copyright material of a party other than HISAC. Authorisation to reproduce such material must be obtained from the copyright holders concerned.
Published in November 2008 by HISAC PO Box 5013, Wellington, New Zealand
ISBN 978-0-478-31780-0 (Online) This document is available on the HISAC website: http://www.hisac.govt.nz
Electronic Pharmaceutical Messaging Standard v1 November 2008 2
Contents
1 ...... Introduction ...... 13 1.1 Background ...... 13 1.2 Application...... 13 1.3 Backward Compatibility...... 14 1.4 Scope ...... 14 1.5 Privacy and Security ...... 15 1.6 Interpretation ...... 15 2 ...... HL7 Overview...... 16 2.1 Separators...... 16 2.2 Field Content - Blanks and Nulls...... 17 2.3 Use of Escape Sequences in Test Fields ...... 17 2.4 Conventions ...... 20 3 ...... Messages Related to Use-Cases ...... 21 3.1 Supported Messages Overview ...... 21 3.2 Message Exchange Principles...... 21 3.3 Exchange of Messages in an ePharmacy Context ...... 22 3.4 Use-Case Messages...... 25 4 ...... Electronic Pharmaceutical Messages ...... 44 4.1 Usage Notes for Pharmacy/Treatment Messages...... 44 4.2 OMP – Prescription Order Message (Event O09)...... 44 4.3 ORP – Pharmacy Order Response Message (Event O10) ...... 49 4.4 RGV – Administration Order Message (Event O15) ...... 50 4.5 RRG – Administration Order Response Message (Event O16)...... 52 4.6 RDS – Dispensing Notification Message (Event O13)...... 53 4.7 RRD – General Order Response Message (Event ^O14) ...... 56 4.8 RDE – Unsolicited Observation Message (Event O11) ...... 57 4.9 RRE – Acknowledgment (Event O12)...... 59 4.10 RAS – Treatment Administration Message (Event O17) ...... 60 4.11 RRA – Treatment Administration Response Message (Event O18)...... 62 4.12 Queries for Immunisation Records (QRF Segments)...... 63 4.13 VXQ – Vaccine Query Message (Event V01)...... 64 4.14 VXX – Response to Vaccine Query Returning Multiple PID Matches Message (Event V02) ... 65 4.15 VXR – Vaccine Record Message (Event V03) ...... 66 4.16 VXU – Unsolicited Vaccine Update Message (Event V04)...... 67 4.17 ACK – Acknowledgment (Event R01)...... 68 4.18 QBP/RSP – Query by Parameter and Segment Response...... 69 5 ...... Supplementary Information...... 70 5.1 Conventions ...... 70 5.2 PCC - Patient Category...... 70 5.3 FSC – Funding Status Code ...... 71 5.4 END – Endorsement Codes...... 71 5.5 ACC – Accident Information...... 72 5.6 ALRT – Administration Alerts and Warnings...... 75 5.7 ATT – Attachments ...... 76 6 ...... Query by Parameter and Segment Response...... 77 6.1 Query Development Methodology ...... 77 6.2 Query Specification Format...... 77 6.3 Response Format...... 78 6.4 Query/Response Conformance Statement ...... 78 6.5 Using the Conformance Statement...... 79 7 ...... Query To HMX Requesting an Order...... 83 7.1 Order Retrieval...... 83 7.2 Prescription Order Retrieval Conformance Statement...... 83 7.3 New Zealand Parameters ...... 86 8 ...... Query To SIR Requesting Medication Profile ...... 87 8.1 Order Retrieval...... 87 9 ...... Segment Definition...... 95 9.1 Conventions ...... 95 9.2 AL1 – Patient Allergy Information Segment...... 136 9.3 BLG – Billing Segment ...... 137
Electronic Pharmaceutical Messaging Standard v1 November 2008 3
9.4 CTI – Clinical Trial Identification Segment ...... 138 9.5 DSC – Continuation Pointer Segment ...... 139 9.6 ERR – Error Segment ...... 140 9.7 IN1 – Insurance Segment ...... 143 9.8 MSA – Message Acknowledgement Segment...... 148 9.9 MSH – Message Header Segment ...... 149 9.10 NK1 – Next of Kin / Associated Parties Segment...... 152 9.11 NTE – Notes and Comments Segment ...... 157 9.12 OBX – Observation Result Segment ...... 159 9.13 ORC – Order Common Segment...... 163 9.14 PD1 – Additional Patient Demographics Segment ...... 171 9.15 PID – Patient ID Segment...... 174 9.16 PV1 – Patient Visit Segment...... 180 9.17 PV2 – Patient Visit Additional Information Segment...... 188 9.18 QAK – Query Acknowledgment Segment...... 197 9.19 QPD – Query Parameter Definition Segment...... 198 9.20 QRD – Query Definition Segment...... 199 9.21 QRF – Original Style Query Filter Segment...... 203 9.22 RCP – Response Control Parameter Segment ...... 205 9.23 RXA – Pharmacy/Treatment Administration Segment ...... 207 9.24 RXC – Pharmacy/Treatment Component Segment ...... 212 9.25 RXD – Pharmacy/Treatment Dispense Segment ...... 213 9.26 RXE – Pharmacy/Treatment Encoded Order Segment...... 219 9.27 RXG – Pharmacy/Treatment Give Segment...... 226 9.28 RXO – Pharmacy/Treatment Order Segment...... 230 9.29 RXR – Pharmacy/Treatment Route Segment...... 236 9.30 SFT – Software Segment...... 240 9.31 TQ1 – Timing/Quantity Segment ...... 242 9.32 TQ2 – Timing/Quantity Relationship Segment ...... 246 Appendix A – Glossary ...... 251 Appendix B – Tables...... 262 Appendix C – Variance to HL7 v2.4 HISO Standards ...... 263 Appendix D: - Variance to HL7 Standard version 2.5...... 267
Table 1: Related documents in Pharmaceutical Standard ...... 13 Table 2: ePharmacy Lifecycle Processes...... 14 Table 3: Operating Systems ...... 16 Table 4: Delimiters...... 16 Table 5: Escape Sequences...... 17 Table 6: Formatted Text ...... 18 Table 7: Shaded Field Definitions...... 19 Table 8: Options ...... 19 Table 9: Repetitions...... 19 Table 10: Segment Parentheses and Brackets...... 20 Table 11: OMP^O09 Message Definition ...... 45 Table 12: ORP^O10 Message Definition...... 49 Table 13: RGV^O15 Message Definition...... 52 Table 14: RRG^O16 Message Definition ...... 53 Table 15: RDS^O13 Message Definition...... 55 Table 16: RDD ^O14 Message Definition...... 56 Table 17: RDE^O11 Message Definition...... 58 Table 18: RRE^O11 Message Definition...... 59 Table 19: RAS^O17 Message Definition ...... 61 Table 20: RRA^O18 Message Definition...... 62 Table 21: QRF Usage in Vaccination Messages...... 63 Table 22: VXQ^O09 Message Definition...... 64 Table 23: VXX^V02 Message Definition...... 65 Table 24: VXR^V03 Message Definition ...... 66 Table 25: VXU^V04 Message Definition ...... 68 Table 26: ACK^R01 Message Definition ...... 68 Table 27: QBP^Znn Query Message...... 69 Table 28: RSP^Znn Segment Response...... 69 Table 29: 99NZPCC – Patient Category Card ...... 70
Electronic Pharmaceutical Messaging Standard v1 November 2008 4
Table 30: 99NZFSC – Funding Status Code...... 71 Table 31: 99NZETY – Endorsement Types ...... 71 Table 32: 99NZEND – Endorsement Codes ...... 72 Table 33: User Defined Table 99NZACC – Accident Information ...... 73 Table 34: HL7 Table 0136 - Yes/No Indicator ...... 73 Table 35: User Defined Table 99NZALRT - Administration Alerts and Warnings...... 75 Table 36: User Defined Table 99NZATF – Format Codes...... 76 Table 37: Conformance Statement Specification ...... 79 Table 38: QBP^Znn Query Message...... 80 Table 39: RSP^Znn Response Message ...... 80 Table 40: QPD Input Parameter Specification ...... 81 Table 41: QPD Query Control Parameter Field Description and Commentary...... 82 Table 42: RCP Response Control Parameter Field Description and Commentary ...... 82 Table 43: Prescription Order Retrieval Conformance Statement...... 83 Table 44: QPB^Z60 Query Message...... 83 Table 45: Response Message Returning RDE or OMP Format...... 85 Table 46: Medication Profile (Display Format) Conformance Statement ...... 87 Table 47: Query Grammar...... 88 Table 48: Response Grammar ...... 88 Table 49: QPD Input Parameter Specification ...... 89 Table 50: QPD Input Parameter Field Description and Commentary ...... 89 Table 51: RCP Response Control Parameter Field Description and Commentary ...... 90 Table 52: Medication Profile (Segment Format) Conformance Statement ...... 91 Table 53: Query Grammar...... 91 Table 54: Response Grammar ...... 92 Table 55: QPD Input Parameter Specification ...... 93 Table 56: QPD Input Parameter Field Description and Commentary ...... 93 Table 57: RCP Response Control Parameter Field Description and Commentary ...... 94 Table 58: Conventions...... 95 Table 59: AD – Address Components...... 96 Table 60: HL7 Table 0190 – Address Type...... 97 Table 61: AUI – Authorisation Information Components...... 97 Table 62: CCD – Charge Code and Date Components ...... 97 Table 63: HL7 Table 0100 – Invocation Event ...... 97 Table 64: CE – Coded Element Components ...... 98 Table 65: HL7 User Defined Table 0396 – Coding Systems...... 99 Table 66: CF – Coded Element with Formatted Values Components ...... 100 Table 67: CP – Composite Price Components...... 100 Table 68: HL7 Table 0205 – Price Type...... 101 Table 69: HL7 Table 0298 – Range Type ...... 101 Table 70: CQ – Composite Quantity with Units Components ...... 101 Table 71: CWE – Coded with Exceptions Components...... 102 Table 72: CX – Extended Composite ID with Check Digit Components ...... 103 Table 73: HL7 Table 0061 – Check Digit Scheme ...... 103 Table 74: DLD – Discharge to Location and Date Components ...... 104 Table 75: DR – Date/Time Range Components...... 104 Table 76: DT – Date Component...... 104 Table 77: DTM – Date/Time Component...... 104 Table 78: ED – Encapsulated Data Components...... 105 Table 79: Constrained from HL7 Table 0191 – Type of Referenced Data...... 105 Table 80: HL7 User Defined Table 0291 - Subtype of referenced data ...... 106 Table 81: HL7 Table 0299 – Encoding...... 106 Table 82: EI – Entity Identifier Components...... 107 Table 83: HL7 Table 0301 – Universal ID Type ...... 107 Table 84 Order Number Identifier...... 108 Table 85: EIP – Entity Identifier Pair Components ...... 108 Table 86: ERL – Error Location Components ...... 108 Table 87: FC – Financial Class Components...... 109 Table 88: FN – Family Name Components ...... 109 Table 89: FT – Formatted Text Data Component ...... 110 Table 90: HD – Hierarchic Designator Components ...... 110 Table 91: No Suggested Values...... 110 Table 92: ID – Coded Value for HL7 Defined Tables Component ...... 110
Electronic Pharmaceutical Messaging Standard v1 November 2008 5
Table 93: IS – Coded Value for HL7 Defined Tables Component ...... 111 Table 94: LA1 – Location with Address Variation 1 Components ...... 112 Table 95: HL7 User Defined Table 0305 – Person Location Type...... 112 Table 96: LA2 - Location with Address Variation 2 Components...... 114 Table 97: MO – Money Components...... 114 Table 98: MSG – Message Type Components ...... 114 Table 99: NA – Numeric Array Components ...... 115 Table 100: NM – Numeric Component...... 115 Table 101: OSD – Order Sequence Definition Components...... 116 Table 102: HL7 User Defined Table 0524 – Sequence Condition ...... 116 Table 103: PL – Person Location Components...... 117 Table 104: PT – Processing Type Components...... 118 Table 105: HL7 Table 0103 – Processing ID ...... 118 Table 106: HL7 Table 0207 – Processing Mode ...... 118 Table 107: RI – Repeat Interval Components ...... 119 Table 108: HL7 User Defined Table 0335 Repeat Pattern...... 120 Table 109: RP Reference Pointer Components ...... 120 Table 110: SAD – Street Address Component...... 121 Table 111: SI - Sequence ID Component...... 121 Table 112: SN – Structured Numeric Component...... 122 Table 113: SRT – Sort Order Components ...... 122 Table 114: HL7 Table 0397 – Sequencing...... 122 Table 115: ST – String Data Component ...... 123 Table 116: TQ – Timing/Quantity Components...... 124 Table 117: TQ3 - Duration Sub-Component ...... 125 Table 118: TQ6 – Priority Sub Component ...... 125 Table 119: TQ6 – Timing Critical Sub Component Table...... 125 Table 120: TS – Time Stamp Components ...... 125 Table 121: HL7 Table 0529 – Precision ...... 126 Table 122: TX – Text Data Component...... 126 Table 123: VID – Version Identifier Components ...... 126 Table 124: VR – Value Range Components ...... 127 Table 125: XAD – Extended Address Components ...... 128 Table 126: XCN – Extended Composite ID Number and Name for Persons Components ...... 129 Table 127: XON – Extended Composite Name and ID Number for Organisations Components...... 130 Table 128: HL7 User Defined Table 0204 – Organisational Name Type...... 131 Table 129: HL7 User Defined Table 0363 – Assigning Authority...... 131 Table 130: HL7 Table 0465 – Name/Address Representation ...... 131 Table 131: XPN – Extended Person Name Component ...... 132 Table 132: HL7 Table 0200 – Name Type Code...... 133 Table 133: HL7 Table 0444 – Name Assembly Order ...... 133 Table 134: XTN – Extended Telecommunications Number Component ...... 134 Table 135: HL7 Table 0201 – Telecommunication Use Codes...... 134 Table 136: HL7 Table 0202 – Telecommunication Equipment Types ...... 135 Table 137: HL7 Attribute Table AL1 – Patient Allergy Information...... 136 Table 138: HL7 User-Defined Table 0127 – Allergen Type ...... 136 Table 139: HL7 User Defined Table 0128 – Allergy Severity...... 137 Table 140: HL7 Attribute Table BLG – Billing Segment ...... 137 Table 141: HL7 Table 0122 – Charge Type ...... 138 Table 142: HL7 User Defined Table 0475 – Charge Type Reason ...... 138 Table 143: HL7 Attribute Table CTI – Clinical Trial Identification...... 138 Table 144: HL7 Attribute Table DSC – Continuation Pointer ...... 139 Table 145: HL7 Table 0398 – Continuation Style Code...... 139 Table 146: HL7 Attribute Table ERR – Error...... 140 Table 147: HL7 Table 0357 – Message Error Condition Codes ...... 141 Table 148: HL7 Table 0516 – Error Severity...... 141 Table 149: HL7 User Defined Table 0517 – Inform Person Code ...... 142 Table 150: HL7 User Defined Table 0518 – Override Type...... 142 Table 151: HL7 Attribute Table IN1 – Insurance ...... 145 Table 152: HL7 User Defined Table 072 – Insurance Plan ID ...... 145 Table 153: 99NZFID – Funder ID ...... 145 Table 154: IN1-16 Authorisation Information Sub Components...... 146 Table 155: User Defined Table 99NZREL – Relationship...... 147
Electronic Pharmaceutical Messaging Standard v1 November 2008 6
Table 156: HL7 User Defined Table 0535 – Signature Code...... 148 Table 157: HL7 Attribute Table MSA – Message Acknowledgement ...... 148 Table 158: HL7 Table 0008 – Acknowledgement code...... 149 Table 159: HL7 Attribute Table MSH – Messaging Header ...... 150 Table 160: MSH-9 Message Type Components ...... 151 Table 161: HL7 Table 0211 – Alternative Character Sets...... 152 Table 162: HL7 Attribute Table NK1 – Next of Kin...... 154 Table 163: User Defined Table 99NZREL – Relationship...... 155 Table 164: HL7 User Defined Table 0131 – Contact Role Code ...... 156 Table 165: HL7 Attribute Table NTE – Notes and Comments ...... 157 Table 166: HL7 Table 0105 – Source of Comment...... 158 Table 167: HL7 User Defined Table 0364 – Comment Type ...... 158 Table 168: HL7 Attribute Table OBX – Observation Result ...... 159 Table 169: Constrained from HL7 Table 0125 – Value Type...... 160 Table 170: HL7 User Defined Table 0078 – Abnormal Flags...... 162 Table 171: HL7 Table 0080 – Nature of Abnormal Test...... 162 Table 172: HL7 Table 0085 – Observation Results Status ...... 163 Table 173: HL7 Attribute Table ORC – Order Common...... 164 Table 174: HL7 Table 0119 – Order Control Codes...... 165 Table 175: HL7 Table 0038 – Order Status...... 166 Table 176: Constrained from HL7 Table 0121 – Response Flag for Valid Entries ...... 167 Table 177: User Defined Table 99NZIN – NZ Specific ORC Groups...... 168 Table 178: User Defined Table 99NZPHARMSTAT – Pharmacy Specific ORC Groups ...... 168 Table 179: HL7 User Defined Table 0339 – Advanced Beneficiary Notice Code...... 169 Table 180: HL7 User Defined Table 0177 – Confidentiality Code ...... 170 Table 181: HL7 Table 0482 – HL7 Order Type ...... 170 Table 182: HL7 Table 0483 – Authorisation Mode...... 171 Table 183: HL7 Attribute Table PD1 – Additional Patient Demographics ...... 172 Table 184: HL7 User Defined Table 0223 - Living Dependency...... 172 Table 185: HL7 User Defined Table 0220 – Living Arrangement ...... 172 Table 186: HL7 User Defined Table 0295 – Handicap...... 173 Table 187: HL7 User Defined Table 0441 – Immunisation Registry Status...... 173 Table 188: HL7 Attribute Table PID – Patient ID Segment ...... 175 Table 189: HL7 User Defined Table 0001 – Administrative Sex...... 176 Table 190: User Defined Table 99NZETH – Ethnicity...... 177 Table 191: HL7 User Defined Table 0002 – Marital Status...... 178 Table 192: HL7 Table 0136 – Yes/No Indicator – Patient Death Indicator ...... 179 Table 193: HL7 Table 0136 – Yes/No Indicator – Identity Unknown Indicator...... 179 Table 194: HL7 User Defined Table 0445 – Identity Reliability Code ...... 179 Table 195: HL7 Attribute Table PV1 – Patient Visit...... 182 Table 196: HL7 User Defined Table 0004 – Patient Class...... 182 Table 197: HL7 User Defined Table 0116 – Bed Status ...... 183 Table 198: HL7 User Defined Table 0007 - Admission Type...... 183 Table 199: HL7 User Defined Table 0092 – Re-Admission Indicator ...... 184 Table 200: HL7 User Defined Table 0023 – Admit Source ...... 184 Table 201: HL7 User Defined Table 0009 – Ambulatory Status ...... 185 Table 202: HL7 User Defined Table 0064 – Financial Class ...... 186 Table 203: User Defined 99NZDIS – Discharge Disposition...... 187 Table 204: HL7 User Defined Table 0113 – Discharged To Location...... 187 Table 205: HL7 Attribute Table PV2 – Patient Visit Additional Information...... 190 Table 206: HL7 User Defined Table 0130 – Visit User Code...... 191 Table 207: HL7 User Defined Table 0213 – Purge Status Code ...... 192 Table 208: HL7 User Defined Table 0217 – Visit Priority Code ...... 193 Table 209: HL7 User Defined Table 0430 – Mode of Arrival Code...... 194 Table 210: HL7 User Defined Table 0431 – Recreational Drug Use Code...... 194 Table 211: HL7 User Defined Table 0432 – Admission Level of Care Code...... 194 Table 212: HL7 User Defined Table 0433 – Precaution Code...... 195 Table 213: HL7 User Defined Table 0434 – Patient Condition Code...... 195 Table 214: HL7 User Defined Table 0315 – Living Will Code...... 196 Table 215: HL7 User Defined Table 0316 – Organ Donor Code ...... 196 Table 216: HL7 User Defined Table 0435 – Advance Directive Code ...... 196 Table 217: HL7 Attribute Table QAK – Query Acknowledgment ...... 197 Table 218: HL7 Table 0208 – Query Response Status...... 197
Electronic Pharmaceutical Messaging Standard v1 November 2008 7
Table 219: HL7 Attribute Table QPD – Query Parameter Definition...... 198 Table 220: HL7 Attribute Table QRD – Query Definition...... 199 Table 221: HL7 Table 0106 – Query/Response Format Code...... 200 Table 222: HL7 Table 0091 – Query Priority...... 200 Table 223: HL7 Table 0126 – Quantity Limited Request ...... 200 Table 224: HL7 Table 0048 – What Subject Filter ...... 202 Table 225: HL7 Table 0108 – Query Results Level ...... 202 Table 226: HL7 Attribute Table QRF – Original Style Query Filter ...... 203 Table 227: HL7 Table 0156 – Which Date/Time Qualifier...... 204 Table 228: HL7 Table 0157 – Which Date/Time Status Qualifier ...... 204 Table 229: HL7 Table 0158 – Date/Time Selection Qualifier...... 204 Table 230: HL7 Attribute Table RCP – Response Control Parameter ...... 205 Table 231: HL7 Table 0394 – Response Modality ...... 206 Table 232: HL7 Table 0395 – Modify Indicator ...... 206 Table 233: HL7 Table 0391 – Segment Group ...... 206 Table 234: HL7 Attribute Table RXA – Pharmacy/Treatment Administration ...... 208 Table 235: HL7 Table 0322 – Completion Status ...... 210 Table 236: HL7 Table 0323 – Action Code ...... 210 Table 237: HL7 Table 0480 – Pharmacy Order Types...... 211 Table 238: HL7 Attribute Table RXC – Pharmacy/Treatment Component ...... 212 Table 239: HL7 Table 0166 – RX Component Type ...... 212 Table 240: HL7 Attribute Table RXD – Pharmacy/Treatment Dispense ...... 214 Table 241: HL7 Table 0167 – Substitution Status...... 216 Table 242: HL7 Table 0136 – Yes/No Indicator – Needs Human Review ...... 216 Table 243: HL7 Table 0321 – Dispense Method...... 218 Table 244: HL7 User Defined Table 0484 – Dispense Type...... 219 Table 245: HL7 Attribute Table RXE – Pharmacy/Treatment Encoded Order...... 221 Table 246: HL7 User Defined Table 0479...... 221 Table 247: Give Per (Time Unit) values ...... 223 Table 248: HL7 Table 0478 – Formulary Status ...... 225 Table 249: HL7 Attribute Table RXG – Pharmacy/Treatment Give ...... 227 Table 250: HL7 Attribute Table RXO – Pharmacy/Treatment Order...... 231 Table 251: RXO-8 Deliver-to Location Components ...... 233 Table 252: HL7 Table 0161 – Allow Substitutions...... 233 Table 253: HL7 Attribute Table RXR – Pharmacy/Treatment Route ...... 236 Table 254: HL7 Table 0162 – Route of Administration ...... 237 Table 255: HL7 Table 0163 – Body Site...... 238 Table 256: HL7 Table 0164 - Administration Device...... 238 Table 257: HL7 Table 0165 – Administration Method...... 239 Table 258: HL7 Table 0495 – Body Site Modifier...... 240 Table 259: HL7 Attribute Table SFT – Software ...... 240 Table 260: SFT-1 Software Vendor Organisations Components...... 241 Table 261: Assigning Authority and Assigning Facility Sub Components...... 241 Table 262: HL7 Attribute Table TQ1 – Timing/Quantity ...... 243 Table 263: HL7 User Defined Table 0485 – Extended Priority Codes...... 245 Table 264: HL7 Table 0472 – TQ Conjunction ID ...... 245 Table 265: HL7 Attribute Table TQ2 – Timing/Quantity Relationship ...... 246 Table 266: HL7 User Defined Table 0503 – Sequence/Results Flag ...... 247 Table 267: HL7 Table 0504 – Sequence Condition Code...... 248 Table 268: HL7 Table 0505 – Cyclic Entry/Exit Indicator...... 248 Table 269: Example of TQ2 – 6, 7 & 8 Usage...... 249 Table 270: HL7 Table 0506 – Service Request Relationship...... 250
Table B 1: 10006 HPI Code Set – Primary language...... 262 Table B 2: HL7 Table 0354 – Message structure...... 262 Table B 3: HL7 Table 0003 – Event type...... 262 Table B 4: HL7 Table 0076 – Message type ...... 262 Table B 5: Country Codes ISO 3166...... 262 Table B 6: HL7 Table 0074 - Diagnostic service section ID...... 262 Table B 7: HL7 User defined Table 0006 - Religion...... 262 Table B 8: HL7 User defined Table 0069 – Health specialty...... 262 Table B 9: HPI 10006 2.1.1 Identifier type...... 262 Table B 10: Common ISO derived units and ISO+ extensions ...... 262
Electronic Pharmaceutical Messaging Standard v1 November 2008 8
Table B 11: HL7 Table 0292 - Vaccines administered...... 262 Table B 12: HL7 Table 0550 Body Parts...... 262 Table B 13: HL7 User defined Table 0171 - Citizenship (Iwi affiliation) ...... 262
Electronic Pharmaceutical Messaging Standard v1 November 2008 9
Committee Representation
Committee 10030 was responsible for the preparation of this document. It comprised the following representatives of nominating organisations:
Nominating Organisation Representative
Accident Compensation Corporation Sunita Goyal
Auckland DHB Rob Ticehurst
Counties Manukau DHB Aaron Jackson
Genesis Consulting Group Shayne Hunter
Healthlink Ltd Edwin Ng
IBA Health (NZ) Ltd Jens Andreas
Medtech Ltd Peter Sergent
Ministry of Health Nicola Hill
NZ Guidelines Group Nicola Lee
NZ Pharmacovigilance Centre Janelle Ashton
Pegasus Health Martin Wilson
PHARMAC John Geering
Pharmaceutical Society of NZ Dale Griffiths
Pharmacy Advisory Group Lisa Teague
Pharmacy Guild NZ Alex Lees
Radius Pharmacy Megan Teusse
RNZCGP David Monks
Safe & Quality use of Medicines (SQM) Group Marilyn Crawley
South Link Health Chris Hilder
Toniq Clive Davidson
Waikato Community Pharmacy Group Steve Roberts
Whanganui Regional PHO Fiona Corbin
Electronic Pharmaceutical Messaging Standard v1 November 2008 10
Related Documents The documents listed below were referred to in developing this Standard. These documents should be consulted to clarify this Standard, if required. HISO HISO 10011.1:2007 Referral, Status and Discharges Business Process HISO 10011.2:2007 Referral, Status and Discharges Messaging Standard HISO 10011.3:2007 Referral, Status and Discharges Implementation Guide HISO 10008.2: 2007 Pathology and Radiology Messaging Standard
NZS Standard SNZ HB 8169:2002 Health Network Code of Practice
AS/NZS Standards AS/NZS 4700.3:2002 Implementation of Health Level Seven (HL7) version 2.3.1 – Electronic messages for exchange of information on drug prescription AS/NZS 4700.1-2005 Implementation of Health Level Seven (HL7) version 2.4 – Patient administration AS/NZS 4700.3:2005 Implementation of Health Level Seven (HL7) version 2.4 – Electronic messages for exchange of information on drug prescription AS/NZS 4360:2004 Risk management
AS Standards AS 4700.1:1998 Implementation of Health Level Seven (HL7) version 2.3 – Patient administration AS 4700.2-2004 Implementation of Health Level Seven (HL7) version 2.3.1 – Pathology orders and results AS 4700.6-2004 Implementation of Health Level Seven (HL7) version 2.3.1 – Referral and discharge summary AS 4700.7-2005 Implementation of Health Level Seven (HL7) version 2.3.1 – Diagnostic imaging orders and results AS 4700.3 (Int) – 2007 Implementation of Health Level Seven (HL7) version 2.5 – Electronic messages for exchange of information on drug prescription AS 4700.5 (Int) – 2007 Implementation of Health Level Seven (HL7) version 2.5 – Immunisation Messages
Other Standards HL7 V2.3.1 Health Level Seven Standard version 2.3.1: Health Level Seven Inc., Ann Arbor 1999 Health Level Seven Inc., HL7 Standard version 2.4 – 2000. An Application Protocol For Electronic Data Exchange in Healthcare Environments. Health Level Seven Inc, HL7 Standard version 2.5 – 2003. An Application Protocol For Electronic Data Exchange in Healthcare Environments1 ISO 3166: ISO 3166-1:1997 Codes for the representation of names of countries and their subdivisions – Part 1: Country Codes ISO 2955 Information processing – Representation of SI and other units in systems with limited character sets Canada Health Infoway. Canadian Clinical Drug (CeRx) Messaging Standard
Other Publications Code of Ethics 2004 – http://www.pharmacycouncil.org.nz/pharmacists/standard/documents/CODEofEthics20044preps.pdf Implementation Guide for Messaging with the National Immunisation Register
1 This document is referred to in the text as “HL7 v2.5”.
Electronic Pharmaceutical Messaging Standard v1 November 2008 11
Guidelines for the Development and Operation of Standing Orders, November 2002 (Revised April 2006); and Enabling the Therapeutic Products and Medicines Bill to Allow for the Development of Collaborative Prescribing – both of these are available on the Ministry of Health website, http://www.moh.govt.nz/publications
New Zealand Legislation Health Information Privacy Code 1994 Medicines Act 1981, section 29 Medicines Regulations 1984 Misuse of Drugs Act 1975, Regulation 41 (Medicines) Standing Order Regulations 2002 Privacy Act 1993 These are available on http://www.legislation.co.nz/ and http://www.legislation.govt.nz/
Electronic Pharmaceutical Messaging Standard v1 November 2008 12
1 INTRODUCTION
1.1 Background This Standard details the structure of electronic messages for pharmaceutical orders, dispensing and administration.
This Standard provides consistent data definitions. It includes the data segments and data elements that are mandatory (required), optional or conditional (required, based on a condition), together with commentary and relevant notes for usage in the New Zealand health environment and will include guidance for implementation. It excludes information specific to the systems that are used to create, deliver and receive messages.
This document is based on the HL7 v2.5 Standard. If more information is required, please consult that Standard on http://www.hl7.org/
This document is one of a set of two which will define a common set of business processes and the data elements that constitute a pharmaceutical transaction message.
Document Document Title Purpose Number 10030.1 Business Process Describes the business process supported by the Standard Messaging Standard
10030.2 Electronic Describes the structure and content of the message Pharmaceutical exchanges between sender and receiver, including Messaging Standard implementation guidance
Table 1: Related documents in Pharmaceutical Standard
This is a technical document generally intended for use by those implementing ePharmacy solutions. It should be read in conjunction with the Business Process Document referred to above. We recommend that people in both technical and non-technical roles read the Business Process document first.
1.2 Application This Standard is for use by New Zealand health authorities, health service providers, pharmacy providers, health institutions, health information technology vendors, health information technology consultants and the health informatics community.
The Pharmaceutical Messaging Standard has been reviewed by technical members of the Expert Advisory Committee who confirm that it will support the requirements of the Pharmaceutical Business Process Standard. However, it should be noted that implementing what is envisaged in the Business Process Standard is complex and must be robust once implemented. It is critical that the vendors and end-users have early and active participation in any implementation project, and that the implementation is carefully phased and rigorously tested during all phase
An ePharmacy solution will have a supporting implementation guide which is developed with reference to this Standard, where messaging forms part of the solution. The implementation guide generally covers the following topics: • Specific use of message segments, any alternative uses or derivations from the Standard including the enforcement of optional fields • Provision of all the technical information required for a health provider (or their system vendor) to make all the necessary system changes to support the solution • Specific requirements related to business rules e.g. legal requirements to be adhered to.
Electronic Pharmaceutical Messaging Standard v1 November 2008 13
1.3 Backward Compatibility This Standard is not generally compatible with current or previous messages used in New Zealand, as there has been no previous messaging standard adopted for pharmaceutical messages. However every attempt has been made to maintain compatibility with the implementation of the National Immunisation Register (NIR), except where there are gross deviations from the HL7 standard. Any instances of this are noted in the text.
A number of elements that were removed in other HL7 v2.4 standards as not being required in New Zealand have been reintroduced in this standard. Care must be exercised that the appropriate standard is used in each area (i.e. Referrals, Status and Discharges; or Pathology and Radiology) as implementations may not support these restored items. NOTE: All these elements are appropriately shaded (in green) along with new items introduced by v2.5 (in blue), refer Table 7.
1.4 Scope This Standard provides guidance to ensure that the right information is provided at the right time to the right person in the right place. With the appropriate security, continuity of patient information, with a reduction in the risk for miscommunication within a secure system and at the right cost, will be achieved.
The Electronic Pharmaceutical (ePharmaceutical) Messaging Standard may be used by other groups provided the validity of use is proven.
1.4.1 In scope The Standard covers the high-level business processes and information flows related to the sending and receiving of electronic information passed between parties within the prescribe, dispense and administer lifecycle. It focuses on: • generating and sending electronic Prescriptions (ePrescriptions) including normal attributes of paper prescriptions; • medicines dispensing and administering (where applicable); • the provision of a shared patient medication profile; between the following parties:
ePharmacy Lifecycle
Prescribe setting Dispense setting Administer setting Review setting
Primary Care Community Pharmacy Patient / Care Provider N/A Provider or Primary Care Provider
Primary Care Hospital Patient / Care Provider N/A Provider
Hospital Community Pharmacy Patient / Care Provider N/A
Hospital Hospital Hospital N/A
Table 2: ePharmacy Lifecycle Processes
Exceptions have been explored in order to allow for some future proofing of the Messaging Standard; for example the business process and associated information flows related to prescribing, dispensing and administering of pharmaceuticals in rest homes.
Other specific inclusions are: (a) Data, including minimum data sets; (b) Definition of the supporting Messaging Standard (messaging structure, content and
Electronic Pharmaceutical Messaging Standard v1 November 2008 14
transmission); (c) Ensuring compliance with relevant legislation is not compromised; (d) Assistance and guidance documentation to support implementation.
1.4.2 Out of scope The Standard does not cover the ePharmacy business processes and information flows related to: • the generation of invoices (claims) for assessing the patient initially and for the dispensing of medicines; • ordering and resulting of laboratory tests to determine appropriate drug therapies; • recording and reporting of controlled drugs as required by the regulations, including medicine recall notices and controlled drug dispense recording reporting, as required by regulation.
Other specific exclusions are: (a) Specifying or developing a pharmaceutical code set, terminology or reference information systems such as a dictionary of medicines, electronic schedule, etc; (b) Specifying or developing any message exchange or shared patient medication history capability including generalised repository reporting; (c) Developing an implementation programme to support the roll out of this standard; (d) The assessment of technologies and the merits of specific vendor products or emerging terminology standards; (e) Other required processes such as patient consent, privacy, practitioner and health consumer registries and authentication frameworks necessary to realise the business model.
1.5 Privacy and Security
Privacy and security of health information in the health and disability sector is important for the following reasons: (a) Most health information is collected in a situation of confidence and trust, often in the context of a health professional/patient relationship. Maintaining this confidence and trust is critical. (b) Health information is sensitive and needs to be protected. (c) Health information may be required by the health agency and by other providers treating the individual, long after it has ceased to be needed for the original episode of care and treatment. Ensuring that health information is available only on a need-to-know basis is therefore important. (d) The ability to exchange high quality health information in a safe and secure manner between partners in health care processes is vital for a health system focused on achieving improved health outcomes. (e) The implementation of privacy and security protection measures is an important factor for electronic referral, status, and discharge solutions.
The implementation of privacy and security protection measures shall be based on the Health Information Privacy Code 1994 and SNZ HB 8169:2002 Health Network Code of Practice (or any policy that builds on or replaces this).
1.6 Interpretation
For the purpose of this Standard, the words ‘shall’ and ‘will’ refer to the practices that are mandatory for compliance with this Standard. The words ‘should’ and ‘may’ refer to practices that are advised or recommended.
The terms ‘normative’ and ‘informative’ are used in Standards to define the application of an appendix. A ‘normative’ appendix is an integral part of a Standard, whereas an ‘informative’ appendix is for information and guidance. Informative provisions do not form part of the mandatory requirements of the Standard. Appendix A defines the terms used in both documents in this Standard.
Electronic Pharmaceutical Messaging Standard v1 November 2008 15
2 HL7 OVERVIEW
2.1 Separators
HL7 allows for considerable flexibility in the selection of separator characters used in generating and parsing messages.
Operating systems in general separate lines in the manner shown in Table 1, below. These systems often use the line separators of their operating system to separate HL7 segments.
The use of both a carriage return character (ASCII Hex 0D16) and a line feed (ASCII Hex 0A16) character to separate segments is strongly discouraged, as this will cause processing errors on some systems. The carriage return character (ASCII Hex 0D16, published in this document as
Operating System Line Separators
DOS and Windows Carriage Return and Line Feed
Macintosh Carriage Return
UNIX Line Feed
Table 3: Operating Systems Please take care to use only this carriage return character to separate segments.
For further details concerning message construction and separator characters refer to HL7 v2.5 Chapters 2.6 (Message Construction Rules) and 2.5.4 (Message Delimiters).
This implementation allows for the possibility of using message defined delimiters. However, it is recommended that HL7 characters are used for delimiting, as some implementations may not support alternatives. Delimiters are listed in the below.
Description Character Symbol ASCII Hex
Field separator "Vertical bar" or "Pipe" “|“ 7C16
Component separator "Hat" or "caret" “^“ 5E16
Sub-component separator "Ampersand" “ &“ 2616
Repetition separator "Tilde" “~“ 7E16
Escape character "Back-slash" “ \“ 5C16
Table 4: Delimiters These separators are used in the example messages throughout this Standard.
The system generating a message does not need to place field separators for empty fields that occur at the end of the segment. Instead, the final field that contains data may be terminated with a carriage return. Examples, 1 and 2 below are technically permissible, while example 3 illustrates the preferred usage.
Example 1 - Don't need trailing field separators where fields do not contain data: ...2.5^NZL|||||||
Example 2 - Don’t need to separate the final field with a field separator: ...2.5^NZL|
Electronic Pharmaceutical Messaging Standard v1 November 2008 16
Example 3 - Preferred option. Final field containing data terminated with carriage return: ...2.5^NZL
2.2 Field Content - Blanks and Nulls
When constructing a message, sometimes no information is available to be sent in a field. If the information is unknown or irrelevant then an empty field is sent. An empty field in a HL7 message is represented by "nothing" between the two delimiters, e.g. ...||.... The receiving system shall ignore this field and leave any information it already has unchanged. For example, if the PID-11 (patient address field) is empty, the existing patient address in the receiving system shall remain unchanged.
If a field is “null”, the effect on the receiving system is quite different. A value of “null” is represented in HL7 by a pair of double-quotes (...|""|...). When a receiving system receives a field containing “null”, it shall erase the value is has currently stored. For example, if PID-11 is “null” (e.g. .|""|...), then the patient address in the receiving system is erased.
NOTE: Mandatory fields must be populated. Spaces and blanks must not be used to circumvent this requirement.
2.3 Use of Escape Sequences in Test Fields
2.3.1 Formatting codes When a field of type TX, FT, or ST is being encoded, the escape character may be used to signal certain special characteristics of portions of the text field. The escape character is whatever display ASCII character is specified in the
Symbol Description \H\ Start highlighting
\N\ Normal text (end highlighting)
\F\ Field separator
\S\ Component separator
\T\ Sub component separator
\R\ Repetition separator
\E\ Escape character
\Xdddd…\ Hexadecimal data
\Zdddd…\ Locally defined escape sequence
Table 5: Escape Sequences
The escape sequences for field separator, component separator, subcomponent separator, repetition separator, and escape character are also correct within an ST data field. No escape sequence may contain a nested escape sequence.
Electronic Pharmaceutical Messaging Standard v1 November 2008 17
2.3.2 Formatted text If the field is the FT data type, the escape character may also surround formatting commands. Each command begins with the “.x” character. The following formatting commands are available:
Value Description .sp
.br Begin new output line. Set the horizontal position to the current left margin and increment the vertical position by 1.
.fi Begin word wrap or fill mode. This is the default state. It can be changed to a no-wrap mode using the .nf command.
.nf Begin no-wrap mode.
.in
.ti
.sk < number> Skip
.ce End current output line and centre the next line.
Table 6: Formatted Text
The component separator that marks each line defines the extent of the temporary indent command (.ti), and the beginning of each line in the no-wrap mode (.nf). Examples of formatting instructions that are NOT included in this data type include: width of display, position on page or screen and type of output devices. Here are two examples:
Example 1 – FT data type from a pharmacy impression section of a pharmacy report showing formatted text as transmitted: \.in+4\\.ti-4\ 1. The cardiomediastinal silhouette is now within normal limits.^\.sp\\.ti-4\ 2. Lung fields show minimal ground glass appearance.^\.sp\\.ti-4\ 3. A loop of colon visible in the left upper quadrant is distinctly abnormal with the appearance of mucosal effacement suggesting colitis.\.in-4\|
Example 2 – Another way of presenting the data in Example 1. The receiving system can create many other interpretations by varying the right margin:
1. The cardiomediastinal silhouette is now within normal limits. 2. Lung fields show minimal ground glass appearance. 3. A loop of colon visible in the left upper quadrant is distinctly abnormal with the appearance of mucosal effacement suggesting colitis.
The message segments in this Standard are defined by the alphabetical order of their three-letter tag. The definitions begin with a table of fields, followed by a section of field notes. The aim here is to clarify HL7 by only commenting on the fields with direct relevance to this implementation. Fields not commented on may still be used. Their usage is governed by HL7.
Electronic Pharmaceutical Messaging Standard v1 November 2008 18
In the tables that define the fields of the segments, shaded rows indicate entries not used in this implementation. HL7 v2.4 items that have been reintroduced since their removal in previous standards are shaded in green and new items introduced by HL7 v2.5 will be highlighted in blue.
Value Description Not Used Fields that are shaded are not used in this implementation
Re-introduced fields Fields that are shaded in green are HL7 v2.4 items that were not required in from HL7 v2.4 previous standards and have been re-introduced in this implementation
New fields in HL7 v2.5 Fields that are shaded in blue are new items from HL7 v2.5
Table 7: Shaded Field Definitions
The following values will be listed in the column “Opt” (Optional):
Value Description Explanation
R Required This field must always contain data.
O Optional This field does not have to have data.
C Conditional This field must contain data in certain situations that will be described in the field notes.
B Backward This field is left for backward compatibility with previous Compatibility versions of HL7.
X Not Used This field is not used in this implementation. Data sent in this field may be ignored by the receiving application.
W Withdrawn
Table 8: Options
The following values will be listed in the column “Rpt” (Repetitions):
Value Description Explanation
N No repetition This field does not repeat (default)
Y Allow repetition This field may repeat as many times as necessary
Yn Allow "n" repetitions This field may repeat the number of times specified by "n"
Table 9: Repetitions If the value in the Rpt column is a number, then the field will be allowed to repeat up to that number of times. If the Rpt column is blank, then a value of “N” should be assumed.
Values in the Length (Len) column always refer to the total length of the field. So if a field contains a composite data type such as XPN (patient name), then the length will refer to the entire field including any separators.
Example: ...|Fyodor^I^Dostoevsky|...
This field contains 19 characters including the separators. This data would be sufficient if the length of the patient name field was 19 characters or more, but would fail if the length was any less than 19 even though there are only 17 characters of actual data.
Electronic Pharmaceutical Messaging Standard v1 November 2008 19
NOTE: The length always refers to a single instance of an item. Thus, if an item repeats then it is allowed up to the maximum length for each individual repeat. The repetition delimiter (tilde "~", unless re-defined in MSH- 2) is not counted for the purposes of length validation.
2.4 Conventions
In message definition, any segment surrounded by parentheses ‘{ }’ is allowed to repeat, and shall have at least one occurrence. A segment surrounded by square brackets ‘[ ]’ is an optional segment. A segment without the surrounding square brackets should be considered as required. Segments that are both repeating and optional shall be surrounded by both square brackets and parentheses. Examples of parentheses and brackets are shown in the below.
Cardinality HL7 Notation
Required 1..1 MSH
Required, may repeat 1..n {OBX}
Optional 0..1 [PV1]
Optional, may repeat 0..n [{OBX}]
Table 10: Segment Parentheses and Brackets
Groups of segments that operate as complete units in the message (known as segment groups) shall also be surrounded by square brackets to indicate that the entire group is optional, and by parentheses to indicate that the entire group may repeat. If a segment is required (i.e. it has no square brackets) inside a group that is optional, then that segment is only required if the group is present. Wherever possible, segment groups are indicated by indentation of the segments that belong to that segment group.
Electronic Pharmaceutical Messaging Standard v1 November 2008 20
3 MESSAGES RELATED TO USE-CASES
3.1 Supported Messages Overview
The implementation of this Standard in New Zealand supports the use of pharmacy order messages (OMP^O09 for prescriptions or RGV^O15 for charting) and a series of responses (ORP^O10 from the pharmacy and RRG^O16 from the administrator).
Enquiry messages (QBP) are used to retrieve orders from a brokering server, or to obtain historical results from a repository. The reply will be in the form of a segmented HL7 message (RSP), which will be similar to the original order message.
Dispensing is reported in a dispense message (RDS^O13) at the time of collection by the patient. These are acknowledged using an acknowledgement message (RDD^O14).
Any remaining items or repeats on a prescription are reported back to the order broker using an encoded order message (RDE^O11) and acknowledged with the associated message (RRE^O12).
A record of the administration of a medicine is transmitted in an administration message (RAS^O17) and acknowledged with a RRA^018 message.
The request for a vaccination history uses a VXQ^V01 message which will result in a history being sent in a VXR^V03 message if the patient has been uniquely identified, or a list of possible patient identifiers being sent in a VXX^V02. A VXU^V04 message is used to update a vaccination record on a register. Each of these messages is acknowledged with an ACK^Vnn message, where Vnn matches the trigger code of the original message (i.e. V01, V02, V03, V04).
The request for a medication profile (medication history) uses a QBP^Z64 (formatted document) or QBP^Z66 (coded text) message, which will result in a history being sent in a RSP^Z65 (formatted document) or RSP^Z67 (coded text) message. Details on Medication History/Profile can be found in Chapter 8.
This Standard does not cover the generic HL7 message processing procedures. Chapter 2.9 of the HL7 v2.5 Standard defines generic message exchanges between the initiator and the receiver, as well as the processes to be followed with regard to accepting or rejecting messages and the creation of responses.
3.2 Message Exchange Principles
The following basic principles should be considered: (a) The mandatory segments identified in the Message Definitions shall always be sent, or the message will be rejected as invalid.2 (b) The mandatory data identified in the Segment Definitions shall always be sent, or the message will be rejected as invalid. (c) The sending system should send as much relevant information as possible in structured format. The receiving system can then select the data elements it requires. Unstructured free-form text should be avoided as much as possible. (d) The responding system should send back as much relevant information as possible, as this acts as a ‘safety check’ on the data of the sent message. The sending system can decide if it wants to compare the returned data with the original data sent or discard it.
Systems that generate messages should ensure that the message is validated and meets the mandatory requirements before being sent.
While the need for a message response is clearly defined by HL7, the amount of time allowed for a response message to be returned (‘message latency’) is not specified by HL7. The latency depends on the nature of
2 It may not only be the receiving application that rejects messages that are missing one or more required data items. Incomplete messages may be rejected by intermediary systems, such as message transport systems or interface engines.
Electronic Pharmaceutical Messaging Standard v1 November 2008 21
the sending and responding application and the communication mechanisms between both systems.3
3.3 Exchange of Messages in an ePharmacy Context
3.3.1 Overall principles Messaging is one way of addressing cross-organisational exchange of information related to ePharmacy. Where messaging based ePharmacy is implemented, a Health Message Exchange (HMX)4 is an intermediary service that provides two key services: (a) Message routing – a HMX simply routes a message to a target recipient. This message simply passes through a HMX. The router service is functionally equivalent to an email delivery system. The exchange looks at the message header and decides where to forward it to. For example, if the HMX receives a message requesting a medication profile, it forwards the message to the appropriate source of the information. (b) Order brokering – a HMX will store, manage, and distribute messages. The message does not simply pass through a HMX. The broker service is essentially an application that manages a database and takes specific actions based on messages based on a set of business rules. For example, if the broker receives a message requesting an order retrieval, it generates a reply message from its database of current orders; it sends the reply, locks the database record and updates the status of the database record.
As far as practicable, messages can be sent in any order and the system will not bounce one message because another party has not sent their message yet. In simple terms, a pharmacist should not be prevented from carrying on with their business because they are waiting for a prescriber to go online and perform an electronic transaction, and likewise, a prescriber should not be prevented from completing an electronic transaction by waiting for a pharmacist to complete one.
HMX services must support the coexistence of paper and electronic transactions.
3.3.1.1 Definitions An ePrescription is an order for a single prescription item that meets the legal requirements of a prescription, and is brokered by the HMX. The terms ePrescription and prescription are used interchangeably in this document. The terms ‘ePrescription’ has the same meaning as the HL7 term ‘order’.
An ePrescription group is a group of ePrescriptions that can be accessed with a single ID number or ‘token’. This corresponds to the traditional piece of paper with several prescriptions on it (loosely referred to as a prescription). The terms ePrescription group and prescription group are used interchangeably in this document. The term ‘ePrescription group’ has the same meaning as the HL7 term ‘order group’.
3.3.2 The principles of brokerage by the HMX
3.3.2.1 Prescribing An ePrescription must be a member of an ePrescription group, even if it is the only member of the group. An ePrescription group must consist of ePrescriptions that are all from the one prescriber and all for the one patient.
An ePrescription group will remain open on the HMX until all member ePrescriptions are closed (collected in full, cancelled, or expired).
An ePrescription can only be created or cancelled; it cannot be modified.
A HMX will update its records of the status of an ePrescription as appropriate (retrieved, declined, collected in full, collected with owe5, cancelled, expired).
3 More specifically, the allowed message response latency could range from seconds or minutes for two applications linked by a TCP/IP ‘socket’, up to a few days if the messages are transported by floppy disk or tape. 4 The term Health Message Exchange used in this document may change and is used for the purposes of defining its role in supporting the business processes outlined in the Business Process Standard and this Messaging Standard. 5 ‘Owes’ are where a prescription item quantity cannot be dispensed as prescribed (i.e. the quantity of a prescription item that is dispensed is less than the quantity prescribed) and where the balance is to be dispensed at a later date.
Electronic Pharmaceutical Messaging Standard v1 November 2008 22
An open ePrescription group can be modified. It can have new ePrescription members added, existing members cancelled and patient details can be updated.
A closed ePrescription group cannot be retrieved, dispensed or modified. ePrescriptions and ePrescription groups can only be created or modified by a prescriber. A dispenser cannot create an ePrescription but can modify an ePrescription in certain circumstances.
A prescriber can cancel an ePrescription, provided that it has not been retrieved (or after it has been both retrieved and declined). A dispenser can cancel an ePrescription once it has been retrieved by them.
When an ePrescription is cancelled, a reason must be given. Coding of reasons will assist in aggregation of prescribing data.
3.3.2.2 Retrieval and declining An open ePrescription group can be retrieved from the HMX by any authorised dispenser who has the required ePrescription group ID or ‘token’ for the group.
Retrieval indicates an intention to dispense all of the ePrescriptions in the group.
Once a group has been retrieved, the entire group is managed by the retrieving pharmacy. This means the pharmacy might make changes, both within and outside of their scope of practice, during the process of dispensing, but these changes do not need to be communicated in messages back to a HMX until the dispense message is sent.
A HMX will not allow another dispenser to retrieve the group until it receives a dispense message indicating that at least one of the prescription items in the group has been declined.
A pharmacy will usually decline a prescription item because it is out of stock.
A pharmacy will usually cancel a prescription item on the instruction of the prescriber, but there will be exceptions (e.g. cancelling a prescription item on the instructions of another prescriber or a patient).
When a prescription item or prescription order (meaning all prescription items) is declined, the prescription order will be returned to a HMX for retrieval by another dispenser, or by the same pharmacy at a later date. Any prescription items that have been dispensed will be flagged in the returned prescription order and will be unavailable for dispensing by any dispenser who subsequently downloads that prescription order.
3.3.2.3 Dispensing A dispense message gives: • the current status of each item in the group: o collected in full; o collected with owes; o declined; or o cancelled. • the current authorisation of each item in the group: o ePrescription (digital signature); o signed paper prescription received; o authorised by dispenser; or o confirmation of authorisation pending.
For ePrescriptions a dispense message will be sent when: • the patient collects the medicines.
A subsequent dispense message may be sent when: • an owe has been dispensed; • an error is being corrected; • a signed paper authorisation has been received for a dispensing that was authorisation-pending.
Electronic Pharmaceutical Messaging Standard v1 November 2008 23
For medicines supplied that do not require a prescription (emergency supply, pharmacist-only, general sales, etc), an ePrescription will not be created. The dispense message will not be brokered, but will be forwarded to a Shared Information Repository (SIR).
For medicines dispensed on receipt of a signed paper prescription and where there is no ePrescription, an ePrescription will not be created by the dispenser. Notice of the dispensing message will not be brokered, but will be forwarded to a SIR. Details of the prescription, including any ID number that may be present, will be included in that message.
For medicines dispensed on a promised prescription (phone/fax), an ePrescription will not be created, but the dispensing message will be brokered (the HMX will retain a copy of the authorisation-pending dispense message as well as forwarding copies to the prescriber and the SIR). If, in the future, a prescriber creates an ePrescription to authorise the dispensing (it could be a new ePrescription group, or an addition to an already open ePrescription group), the dispense message will be matched with that ePrescription and brokered accordingly. If, in the future, the dispenser receives a paper prescription to authorise the dispensing, they will be able to update the earlier dispense message with that information, which will remove the dispense message from brokering. Note the importance of the dispense notice ID number; this number will have to be generated by the dispenser’s system and sent in a message to the prescriber’s system. This number will become the group ID or ‘token’ when a new ePrescription group is created, so it needs to be generated with the same algorithm as prescriber systems use to create group IDs or ‘tokens’.
3.3.2.4 Administration Administration messages will not be brokered. They will be forwarded to the SIR.
3.3.2.5 Medication profile Medication profile messages will not be brokered. They will be forwarded to the SIR and responses will be forwarded to the requesting clinical system.
3.3.3 Modifications outside the scope of practice When a modification needs to be made to a prescription and that modification is outside the scope of practice of the dispenser, then the following scenario may transpire (a one-item group is assumed for the sake of simplicity): • Pharmacy system retrieves ePrescription group from HMX. • Pharmacist phones prescriber and prescriber advises new ePrescription details. • Pharmacist dispenses new ePrescription item. • Pharmacy system sends dispense message covering two items: o The original ePrescription item obtains a current status of cancelled and an authorisation of authorised-by-dispenser; o The new ePrescription item obtains a current status of collected-in-full and authorisation- pending. At this stage, the new ePrescription item exists only as a message that it was dispensed. The ePrescription does not itself yet exist. Also, the authorisation will need to be provided within a set timeframe, as defined in the relevant section of the Medicines Regulations. • HMX forwards an updated order message to the prescriber’s system, because it contains one or both of a cancelled item and an authorisation-pending item. The cancellation of the item could be handled automatically by the prescriber’s system on receipt of the order message. • Prescriber picks up the message (could be some time later), cancels the original ePrescription in their system if this has not already happened automatically and authorises the new ePrescription created by the dispenser (RDE, refer Chapter 4.8). • Prescriber’s system sends message to HMX to create the new ePrescription, as part of the same ePrescription group as the cancelled one and referring to the dispense notice ID. • HMX creates the new ePrescription and new ePrescription group, if one is required, and sets its status to collected-in-full or collected-with-owe, using the dispense notice which it has ‘on file’. • HMX sends the message to the dispenser’s system, confirming that the dispensing has now been authorised.
Electronic Pharmaceutical Messaging Standard v1 November 2008 24
Note: The new ePrescription with new ePrescription number and a status of authorisation-pending, waits on the HMX until such time as it is authorised.
3.4 Use-Case Messages
3.4.1 Introduction The use-cases have been developed to define the ‘prescribe, dispense administer’ lifecycle in various settings. The use-cases were used to determine the supporting information and information systems requirements. They are intended to provide guidance to the development of a New Zealand Pharmaceutical Business Process and Messaging Standard and for those implementing the Standard.
Each of the use-cases is followed by a detailed interaction diagram showing the specific message formats that are used.
Electronic Pharmaceutical Messaging Standard v1 November 2008 25
3.4.2 Use-Case 1: Community Prescribe, Dispense, Administer Overview Client / Patient Prescriber Health Message Shared Dispenser Administerer Exchange Information Repositories
Patient presents for 1.1 Patient consultation 1.1 Locate and send treatment and decision making Patient information
1.2 Generate Prescription Order
1.3 Lodge Prescription 1.4 Prescription Order Order / Cancel, Replace, acknowledge & process 1.4a Update patient Stop, Change, Authorise or return if invalid information Change Request
(e.g. Paper)
Physical Prescription Order 1.5a Locate and send 1.5 Receives / Reviews / Patient information Confirms or Returns Prescription Order Patient presents for medicine collection Physical Prescription Order (e.g. Paper )
Patient presents for emergency supply
1.8 1.7 Medicine Dispensed 1.6 Process Prescription GP / Nurse / Patient / Message lodged and Order & supply to Caregiver, etc status updated Patient administers medicines Message Legend 1.9 Advised that Medication Profile Inquiry Prescription Order has Prescription Order been fulfilled / modified 1.9 Update Patient Medication Dispense Information Prescription Order Returned Medication Profile Update
Figure 1: Use-Case 1 – Community Prescribed, Dispensed, Administered Lifecycle
Electronic Pharmaceutical Messaging Standard v1 November 2008 26
3.4.2.1 Use-Case 1: Community prescribe, dispense administer process steps
Medication Profile Request
Prescriber, Shared Dispenser, Information other authorised person Repository
Medication Profile Request QBP^Z64 (PDF) QBP^Z66 (Coded text)
Medication Profile Response RSP^Z65 (PDF) RSP^Z67 (Coded text)
Figure 2: Medication Profile Request Message
1. A medication profile request message can be initiated by any authorised person during a consultation with the patient and may also be initiated for the purpose of data collection and pharmacovigilance where authorised. 2. Data returned by the medication profile response message is not filtered. Specifically, it is not divided into current and historical medicines; it is the responsibility of the requesting software system to perform any filtering required by the user. However, entries in the response message should be sorted by date, with most recent first. 3. A medication profile request message can be sent to the HMX, which will forward it to the SIR.
Electronic Pharmaceutical Messaging Standard v1 November 2008 27
Figure 3: Medication Order/Return Message
1. A prescription item is a single common order segment (ORC), followed by a single pharmacy/treatment order segment (RXO). In HL7 terminology, this is an ‘order’. According to the Medicines Act, this is a ‘prescription’. In terms of this Standard, this is an ‘ePrescription’. 2. An ePrescription Group is a group of ePrescriptions that can be retrieved with a single ‘token’ or access key. In HL7 terminology, the ‘token’ is the ‘placer group number’. 3. A pharmacy order message (OMP) can contain ePrescriptions (ORC segments) of four types: new order (order control code NW); request to cancel order (order control code CA); discontinue (order control code DC); and change (order control code XO). NW and CA are valid only if the order has not yet been
Electronic Pharmaceutical Messaging Standard v1 November 2008 28
filled. DC and XO are valid only if the order has been filled, they indicate new instructions to the patient
or caregiver (see ‘Stop or change an existing medication regime’, refer to page 41).88888 4. If an ePrescription has not been retrieved, it can be cancelled. If it has been retrieved, it can be cancelled by the retrieving dispenser only. If it has been filled, it cannot be cancelled. 5. The dispenser retrieves the medication order with an order retrieval request (QBP^Z60). 6. The order retrieval request (QBP^Z60) requires that the dispenser has in their possession the placer group number. The placer group number acts as a ‘token’ that the patient must take to the pharmacy. It may be transported as a printed bar code, written down, faxed, emailed, spoken over the telephone, or electronically stored on a smart card. The order retrieval response will contain all prescription items (ORC segments) in the group, but those that have already been dispensed will be flagged as information only (control code IN). The retrieval of the prescription item locks it to prevent retrieval by any other party. The exception to this is when the original retriever repeats the retrieval with the same query identifier. This would be the case when the response does not arrive at the destination. 7. A prescription item can be returned as an ORC segment in an OMP message, with the original order control code (ORC-1) and a status code (ORC-16) of not actioned (NA). This indicates that the prescription item has not been accepted and is being returned to the HMX.
Electronic Pharmaceutical Messaging Standard v1 November 2008 29
Figure 4: Medication Dispense Message
1. The medication dispense message (RDS) must be sent when a prescription item is collected. 2. A medication dispense message can be one of two types: new or cancel. Cancel is used when an error has been made that needs to be corrected. 3. If the order cannot be filled in full, but the dispenser intends to complete the transaction, then the dispense message is sent with a status code (ORC-16) of OW (collected with owe). In this case, the order remains locked and will be released by the completing dispense notification. 4. If the item being dispensed requires authorisation by a prescriber, an RDE message is sent to the prescriber (refer to pages 38 to 40). NOTE: The HMX will not send RDS messages to the prescriber unless specific conditions are met. There is provision for including a request for these messages to be sent at the time the original OMP message is sent to the HMX.
Electronic Pharmaceutical Messaging Standard v1 November 2008 30
Figure 5: Medication Administration Message
1. A medication administration message is an optional part of the medication order lifecycle.
Electronic Pharmaceutical Messaging Standard v1 November 2008 31
3.4.3 Use-Case 2: Hospital Prescribe, Community Dispense, Administer Overview
Client / Patient Prescriber Health Shared Dispenser Administerer Message Exchange Information Repository
1.1 Patient Patient presents 1.1 Locate and send consultation and For treatment Patient information decision making
1.2 Generate Prescription Order
1.3 Discharge Patient &
Lodge Prescription Order Refer to Use Case 1 – / Cancel, Replace, Stop, Step 1.9 Change, Authorise Change Request
Paper) (e.g. Refer to Use Case 1 – Step 1.4 onwards Physical Prescription Order
Patient presents for Refer to Use Case 1 – medicine collection Step 1.5 onwards
Legend Medication Profile Inquiry Medication Profile Update Prescription Order Figure 6: Use-Case 2 – Hospital Prescribe, Community Dispense, Administer Lifecycle
Electronic Pharmaceutical Messaging Standard v1 November 2008 32
3.4.4 Use-Case 3: Hospital Prescribe, Dispense, Administer Overview
Client / Patient Prescriber Health Shared Dispenser Administerer Message Exchange Information Repository
1.1 Patient Patient Presents for consultation and 1.1 Locate and send treatment Patient information Decision Making
1.2 Hospital Related Hospital Administered Processes Medicines
1.3 Discharge Patient & Refer to Use Case 1 – Patient Discharged Lodge Cancel, Replace, Step 1.9 / On Leave Stop, Change
Refer to Use Case 1 – Step 1.4 onwards
Legend Medication Profile Inquiry Medication Profile Update Prescription Order
Figure 7: Use-Case 3 Hospital Prescribe, Dispense, Administer Lifecycle
Electronic Pharmaceutical Messaging Standard v1 November 2008 33
3.4.4.1 Use-Case 2 process steps During the time that a patient is in hospital, clinical staff may access the SIR to obtain a medication profile at any time. This process will follow the process for medication profile request for Use-Case 1, refer to Figure 1.
If the hospital chooses to keep the SIR up to date during the time the patient is in hospital, the appropriate give (RGV) and administration (RAS) messages can be sent to the SIR. The content of an administration message will be generally the same as when they are sent as part of Use-Case 1, although they will need to be identified as being of hospital origin and it is expected the SIR will treat them accordingly.
Part of keeping the SIR up to date while a patient is in hospital is stopping medicines that they may have been on at the time of admission, unless the hospital is continuing with the medicine. Stop (discontinue) messages (order control code DC) are sent as OMP^O09 messages to the SIR. For details of stopping medicines see the discharge interaction diagram, Figure 8 below.
At discharge or going on leave: (a) Hospitals will obtain a medication profile and send stop messages to stop any specific or unnecessary medicines still showing (unless they have asked the patient to continue taking them). Stop messages are sent as OMP^O09 (order control code DC) messages to the SIR. (b) It is expected that all hospitals will send a RGV message detailing medicines that a patient is being discharged with (in their possession). (c) Any medicines being prescribed on discharge will enter the system exactly as for Use-Case 1: normally via an OMP^O09 message to the HMX, but in some cases on paper.
NOTE: The hospital must make every effort to keep the medication profile up to date on the SIR. If the hospital can not keep the medication profile up to date on the SIR, for instance if they are not connected to the HMX/SIR system, then medicines prescribed on discharge will enter the system when they are entered by the community pharmacy at the time of dispensing. This does not provide for the stopping of any medicines patients were on at admission, which may have to be done by the GP or pharmacist at a medication review. It also means that medicines patients were given to take with them at discharge will potentially not be captured by the SIR.
Electronic Pharmaceutical Messaging Standard v1 November 2008 34
Discharge or On Leave Interaction diagram
Health Shared Hospital Message Dispenser Information Exchange Repository
Medication Profile Request Discharge report QBP^Z62 (PDF) being prepared QBP^Z64 (Coded text)
Medication Profile Response RSP^Z63 (PDF) RSP^Z65 (Coded text)
Pharmacy Order Pharmacy Order OMP^O09 OMP^O09 Stop orders sent for prescription items that are no longer being taken
Pharmacy Order Response ORP^O10 Pharmacy Order Response ORP^O10
Medication Profile Update RGV^O15 medicines that a patient is being discharged with (in their possession) Medication Profile Update Response RRG^O16
Pharmacy Order Pharmacy Order OMP^O09 medicines being OMP^O09 prescribed on discharge (start orders) Pharmacy Order Response ORP^O10 Pharmacy Order Response ORP^O10
Prescription is filled as per Use Case 1, by dispenser retrieving and accepting the order, and subsequently dispensing.
Figure 8: Discharge or On Leave Message
Electronic Pharmaceutical Messaging Standard v1 November 2008 35
3.4.4.2 Exceptions to above use-cases
Figure 9: Paper Prescriptions to Community Pharmacy Message
Electronic Pharmaceutical Messaging Standard v1 November 2008 36
ePrescription with modification requiring authorisation
Health Shared Prescriber Message Dispenser Information Exchange Repository
Patient visits doctor Medication Profile Request QBP^Z62 (PDF) QBP^Z64 (Coded text)
Medication Profile Response RSP^Z63 (PDF) RSP^Z65 (Coded text)
Doctor writes Pharmacy Order Pharmacy Order prescriptions for OMP^O09 OMP^O09 several items
Pharmacy Order Response ORP^O10 Pharmacy Order Response ORP^O10 Patient visits pharmacy Order Retrieval Request QBP^Z60
Order Retrieval Response RSP^K61
Pharmacist is out of stock of one item, contacts doctor by phone, is advised of substitute medication, fills order, patient collects
Pharmacy Order OMP^O09 cancel one item
Pharmacy Order Response ORP^O10
Medication Dispense Message RDS^O13 include new item
Medication Dispense Response RDD^O14
Medication Dispense Message RDS^O13
Medication Dispense Response RDD^O14
Continued on next page
Electronic Pharmaceutical Messaging Standard v1 November 2008 37
Health Shared Prescriber Message Dispenser Information Exchange Repository
Pharmacy Order Message RDE^O11
Doctor authorises the dispensed item
Pharmacy Order Message RDE^O11
Medication Dispense Message RDS^O13 update status
Medication Dispense Response RDD^O14
Medication Dispense Message RDS^O13
Medication Dispense Response RDD^O14
Figure 10: ePrescription Modification Requiring Authorisation
1. The modified order is sent to the presciber using a RDE message showing all the items in the group and at the same time an OMP message is sent to the HMX, cancelling the original ePrescription. 2. The particular items requiring authorisation will have a status code (ORC-16) of AR (authorisation requested). 3. The prescriber will change the status code (ORC-16) to AP (authorisation processed) and return the order to the dispenser as an RDE message. 4. The original prescription item (ORC segment containing RXO) ends up being cancelled and a new prescription item (ORC segment containing RXE) is created by the dispensing system. The new prescription item has a new unique prescription item number (placer order number) generated by the dispensing system, and the original prescription order number (placer group number). 5. The new prescription item (ORC segment containing RXE) is sent in both the RDE message to the prescribing system, and in the RDS message to the SIR.
Electronic Pharmaceutical Messaging Standard v1 November 2008 38
6. The new prescription item is not brokered. This is because there is no order that needs to be brokered, there is simply an order (RDE message) that flows from the dispenser to the prescriber and then from the prescriber to the dispenser. At that point, the dispenser holds authorisation for the dispensing, and because the dispensing has already been notified to the SIR with the correct placer order number and placer group number, no further notification to HMX or SIR is required. 7. Optionally, a status update message (RDS message) that contains the order control code SC (status change) and a status code (ORC-16) of AF (authorisation on file) may be sent to the SIR when the authorised RDE message arrives at the dispenser’s system.
Electronic Pharmaceutical Messaging Standard v1 November 2008 39
Figure 11: Paper Prescription Modification Requiring Authorisation
1. The optional status update message is an RDS message that contains order control code SC (status change) and a status code (ORC-16) of AF (authorisation on file).
Electronic Pharmaceutical Messaging Standard v1 November 2008 40
Figure 12: Stop or Change an Existing Medication Message
1. Stopping a medication regime requires sending DC (discontinue) as the ORC order control code. 2. Changing an existing medication regime requires sending XO (change order/service request) as the ORC order control code. 3. The SIR will accept medication regime change messages (DC or XO) within either message type OMP or RGV. 4. Generally it is appropriate to send an OMP if the medication regime is based on a prescription (originated with an OMP message), and RGV if it is based on charting or on the supply of a medicine where a prescription is not required, e.g. supply of pharmacy-only medicine (originated with an RGV or RDS message). In practice, both OMP and RGV message types are treated in the same way when the order control code is DC or XO: that is, when the message is received by the SIR it is treated as advice that the medication regime has been changed. 5. Note that OMP and RGV messages when received by other parties (e.g. within a hospital system) are usually treated as instructions to do something, but when received by the SIR they are treated as ‘courtesy copies’ and are for information only. This does not prevent the SIR being the only recipient of the message. 6. The HMX and SIR will not accept DC or XO order control codes for an order that has not been filled. The only valid order control code for existing orders that have not been filled is CA (request to cancel order). 7. The HMX and SIR will not accept CA (request to cancel order) order control codes for an order that has been filled (collected). The only valid order control codes for existing orders that have been filled are DC and XO, where the medication regime is being changed (not the medicine).
Electronic Pharmaceutical Messaging Standard v1 November 2008 41
Figure 13: Immunisation Record Request
1. If the VXQ message does not match any patients, then it will be acknowledged with an ACK message with an ERR detailing that no results were found.
Electronic Pharmaceutical Messaging Standard v1 November 2008 42
Figure 14: Immunisation Administration Message
1. For simplicity, ACK messages are not shown in these interaction diagrams. 2. An ACK message with an ERR will indicate that the message has not been successfully processed.
Electronic Pharmaceutical Messaging Standard v1 November 2008 43
4 ELECTRONIC PHARMACEUTICAL MESSAGES
4.1 Usage Notes for Pharmacy/Treatment Messages
For the RDS (pharmacy/treatment dispense), RGV (pharmacy/treatment give) and RAS (pharmacy/treatment administration) messages, the placer and filler order numbers are those of the parent RDE (pharmacy/treatment encoded order) or OMP (pharmacy order) message. In these messages, the filler order number does not provide a unique identification of the instance of the pharmacy/treatment action (dispense, give or administer). To correct this problem, each of the defining segments (RXD, RXG and RXA) has an appropriately named sub-ID field (dispense sub-ID counter, give sub-ID counter, and administration sub-ID counter). The combination of the filler order number (including its application ID component) and the appropriate sub-ID counter uniquely identifies the instance of the pharmacy/treatment action(s) present in these messages.
Although the default order control code for the RDE, RDS, RGV and RAS messages is RE (Results to follow), there are cases in which the pharmacy or treatment system and the receiving system must communicate changes in state. Depending on whether the pharmacy or treatment supplier’s relationship to the receiving system is that of placer or filler, the appropriate order control code may be substituted for the default value of RE. The receiving system can also use an appropriate order control code to report status back to the pharmacy or treatment system.
For example, if a pharmacy or treatment system is sending RGV messages to a nursing system that will administer the medicines and the pharmacy or treatment system needs to request that several instances of a give order be discontinued. To implement this request, the RGV message may be sent with a order control code DC (discontinue), and the appropriate RXG segments whose give sub-ID fields identify the instances to be discontinued. If a notification back to the pharmacy or treatment supplier is needed, the nursing system can initiate an RGV message with order control code DR (discontinued as requested) containing RXG segments whose give sub-ID fields identify the discontinued instances.
IV solution groups: An order for a group of IV solutions to be given sequentially can be supported in two similar ways - parent/child and separate orders. This HL7 Standard supports both methods of ordering. The method used at a particular site must be negotiated between the site institution and the various application vendors.
Examples of messages are given where appropriate. The messages are broken up into blocks for ease of explanation. These blocks make up an entire message if they are concatenated into one block of text. Only one example of a response is shown (ORP) as the all responses have the same minimum structure, just a different message type in the header. The medicine codes are shown as coming from the New Zealand Medicines Terminology code set. At the time of publication this is still only a recommendation and the actual codes have been arbitrarily assigned. Other coding sets such as Pharmacode or Mims can be used. All examples in this document are fictitious and are not held to be clinically correct.
4.2 OMP – Prescription Order Message (Event O09)
The prescription order message may be used to convey an order or authorisation of an amended order to a dispenser. The table below describes the structure of the OMP message:
Segment Name Description
MSH Message Header
[{SFT}] Software
[
PID Patient Identification
[PD1] Additional Demographics
Electronic Pharmaceutical Messaging Standard v1 November 2008 44
Segment Name Description
[PV1 Patient Visit
[PV2]] Patient Visit - Additional Info
[{IN1 Insurance or Subsidy Card
}]
[{AL1}] Allergy Information
]
{
ORC Common Order
[{TQ1 Timing Quantity
[{TQ2}] Additional Timing and Quantity information
}]
RXO Pharmacy/Treatment Order
{RXR} Pharmacy/Treatment Route
[
{RXC Pharmacy/Treatment Component
}]
[
{
OBX Observation/Result
[{NTE}] Notes and Comments (for OBX)
}
]
[BLG] Billing Segment
}
Table 11: OMP^O09 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.3 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
Electronic Pharmaceutical Messaging Standard v1 November 2008 45
4.2.1 Example of an OMP message used for placing a new order: This block is contains the message header identifying it as a medication order and who it is for. It also has the additional information detailing the community services card that applies to this order.
MSH|^~\&|PMSAPPLICATION|ACME MEDICAL CENTRE|HMX|HMX APPLICATION|200812121359||OMP^O09|00963425|P|2.5 PID|1||LLX0159||TESTING^Rosemary^||19551225|F||11|215 GRANGE RD^GREERTON^TAURANGA||^PRN^PH^^64^9^3454567|^WPN^PH^^64^9^3456123^ afternoons only~^NET^Internet^[email protected] IN1|1|CSC^Community Services Card^HL7072|MOH^99NZFID|Ministry of Health|12345-6789-1234-140|||20090905
The funding criteria are held in an ORC group of type IN (information). The RXO and RXR segments are required but contain dummy values in the mandatory fields.
ORC|IN|1234.0.1||1234||||||||07315^TESTDR^JOCK RXO||||||ignore RXR|U^Unknown^HL70162 OBX|1|CE| 410598002 ^ Person categorised by age^SCT_NZ_20080731 ||A^Adult^99NZPCC|||||||F OBX|2|CE| 224164009 ^ Benefit status ^SCT_NZ_20080731 ||1^CSC Holder^99NZFSC|||||||F
The next section contains endorsements that apply to the whole order. Again, dummy RXO and RXR segments are present.
ORC|IN|1234.0.2||1234||||||||07315^TESTDR^JOCK RXO||||||ignore RXR|U^Unknown^HL70162 OBX|3|CE| ENT^Endorsement ^99NZETY ||DSL^ Dispense stat list medicines once only unless under close control ^99NZEND |||||||F OBX|4|CE|ENT^Endorsement ^99NZETY ||NDE^ Note date of expiry of RX ^99NZEND |||||||F OBX|5|CE| ENT^Endorsement ^99NZETY ||GSP^ Generic Substitution allowed unless otherwise stated ^99NZEND |||||||F
This represents one prescription item. It is Dicloxacillin Sodium in 250 mg capsules to be taken three times a day for seven days (21 capsules). Furthermore it is endorsed as close control with the endorsement ‘dispense weekly in blister packs’. Note the code in ORC-16 which indicates the provider wishes to be informed when the medication is collected by the patient.
ORC|NW|1234.1||1234|||1^TID||||||07315^TESTDR^JOCK||||NP RXO|1234^Dicloxacillin Sodium^NZMT|250||mg|capsule||||G|21 RXR|MTH^Mouth^HL70162 OBX|6|CE|ENT^Endorsement ^99NZETY ||CCT^ Close Control ^99NZEND |||||||F OBX|6|ST|ENV ^99NZETY || dispense weekly in blister packs |||||||F
Electronic Pharmaceutical Messaging Standard v1 November 2008 46
This is an alternative way of encoding the previous block. In this case a TQ1 segment is used instead of ORC-7 and the close control instructions are concatenated to the code description.
ORC|NW|1234.1||1234|||||||||07315^TESTDR^JOCK| TQ1|1||TID|||7^D&day&ISO+ RXO|1234^Dicloxacillin Sodium^NZMT|250||mg|capsule||||G|21 RXR|MTH^Mouth^HL70162 OBX|6|CE|ENT^Endorsement ^99NZETY ||CC^ Close Control dispense - weekly in blister packs ^99NZEND |||||||F
The next medication required a special authority so this is recorded in the first endorsement, the authority number in the second and the expiry date in the third. Note that all these endorsements are linked by the OBX-1.
ORC|NW|1234.2|1234||||1^Q1W||||||07315^TESTDR^JOCK RXO|1222^Alendronate Sodium^NZMT|70||mg|tab||||G||4||11 RXR|MTH^Mouth^HL70162 OBX|7|CE|ENT^Endorsement ^99NZETY ||SPA^ Special Authority ^99NZEND |||||||F OBX|7|ST|ENV^Endorsement Value ^99NZETY ||123456 |||||||F OBX|7|DT|ENE^Endorsement Expiry ^99NZETY ||20091221 |||||||F
This medication has been prescribed to reduce inflammation as a result of an accident. The accident details are shown here immediately preceding the medication but it could be anywhere in the message. The BLG segment holds the HPI organisation code for ACC (actual one yet to be assigned) indicating that this item is funded by ACC.
ORC|IN|1234.0.3||1234||||||||07315^TESTDR^JOCK||||ACC RXO||||||ignore RXR|U^Unknown^HL70162 OBX|8|TS|ACCDTE^Accident date^99NZACC||20081211|||||||F OBX|8|ST|CLMNBR^ACC claim number^99NZACC||UP74307|||||||F ORC|NW|1234.3||1234|||1^TDS||||||07315^TESTDR^JOCK||||NP RXO|1244^Diclofenac Sodium^NZMT|50||mg|tab||||G||60 RXR|MTH^Mouth^HL70162 BLG|||ACC123^^^HO
This medication requires the recommendation of a specialist and the order is required to be endorsed accordingly.
ORC|NW|1234.4||1234|||1^OD||||||07315^TESTDR^JOCK RXO|1255^Omeprazole^NZMT|40||mg|capsule||||G||90 RXR|MTH^Mouth^HL70162 OBX|8|CE|ENT^Endorsement ^99NZETY ||SPR^ Specialist Recommended ^99NZEND |||||||F OBX|8|XCN|ENV ^99NZETY ||08442^TESTSP^FRED |||||||F OBX|8|DT|END^Endorsement Date ^99NZETY ||20081221 |||||||F
Electronic Pharmaceutical Messaging Standard v1 November 2008 47
4.2.2 Example of an OMP message when used to return a partially filled order: This block is contains the message header identifying it as a medication order and who it is for. It also has the additional information detailing the community services card that applies to this order.
MSH|^~\&|PMSAPPLICATION|ACME MEDICAL CENTRE|HMX|HMX APPLICATION|200812121359||OMP^O09|00963425|P|2.5 PID|1||LLX0159||TESTING^Rosemary^||19551225|F||11|215 GRANGE RD^GREERTON^TAURANGA||^PRN^PH^^64^9^3454567|^WPN^PH^^64^9^3456123^a fternoons only~^NET^Internet^[email protected] IN1|1|CSS^Community Services Card^99NZFSC|MOH^99NZFID|Ministry of Health|12345-6789-1234-140|||20090905
The funding criteria are held in an ORC group of type IN (information). The RXO and RXR segments are required but contain dummy values in the mandatory fields.
ORC|IN|1234.0.1||1234||||||||07315^TESTDR^JOCK RXO||||||ignore RXR|U^Unknown^HL70162 OBX|1|CE| 410598002 ^ Person categorised by age^SCT_NZ_20080731 |A^Adult^99NZPCC|||||||F OBX|2|CE| 224164009 ^ Benefit status ^SCT_NZ_20080731 ||1^CSC Holder^99NZFSC|||||||F
The next section contains endorsements that apply to the whole order. Once more dummy RXO and RXR segments are present.
ORC|IN|1234.0.2||1234||||||||07315^TESTDR^JOCK RXO||||||ignore RXR|U^Unknown^HL70162 OBX|3|CE| ENT^Endorsement ^99NZETY ||DSL^ Dispense stat list medicines once only unless under close control ^99NZEND |||||||F OBX|4|CE|ENT^Endorsement ^99NZETY ||NDE^ Note date of expiry of RX ^99NZEND |||||||F OBX|5|CE| ENT^Endorsement ^99NZETY ||GSP^ Generic Substitution allowed unless otherwise stated ^99NZEND |||||||F
This next section represents one prescription item. It is Dicloxacillin Sodium in 250 mg capsules to be taken three times a day for seven days (21 capsules). This item has been fully dispensed so the ORC-1 has been set to IN.
ORC|IN|1234.1||1234|||1^TID||||||07315^TESTDR^JOCK||||NP RXO|1234^Dicloxacillin Sodium^NZMT|250||mg|capsule||||G|21 RXR|MTH^Mouth^HL70162
Electronic Pharmaceutical Messaging Standard v1 November 2008 48
This represents the next prescription item which could not be dispensed. Note the code in ORC-1 which indicates that this item was not dispensed but returned to the HMX.
ORC|NA|1234.2||1234|||1^OD||||||07315^TESTDR^JOCK RXO|1255^Omeprazole^NZMT|40||mg|capsule||||G||90 RXR|MTH^Mouth^HL70162 OBX|8|CE|ENT^Endorsement ^99NZETY ||SPR^ Specialist Recommended ^99NZEND |||||||F OBX|8|XCN|ENV ^99NZETY ||08442^TESTSP^FRED |||||||F OBX|8|DT|END^Endorsement Date ^99NZETY ||20081221 |||||||F
4.3 ORP – Pharmacy Order Response Message (Event O10)
The function of the ORP message is to respond to the OMP message. The table below describes the structure of the ORP message:
Segment Name Description
MSH Message Header
MSA Message Acknowledgment
[{ERR}] Error
[{SFT}] Software
[
[PID Patient Identification
]
{
ORC Common Order
[
RXO Pharmacy/Treatment Order
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component
]
}
]
Table 12: ORP^O10 Message Definition NOTE: Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.4 for a full list of segments.
Electronic Pharmaceutical Messaging Standard v1 November 2008 49
4.3.1 Example of an ORP message: This block is contains the message header identifying it as a medication order response and indicating the original message contained an error. The MSA indicates the original order message number (example above for OMP). The ERR indicates the error is in the first occurrence of a RXO and in the first field (give code). If there are repeats or components in the field then the error location can be refined further. The error code (103) indicates the code could not be found but the receiving application has accepted the message with a warning. Version 2.4 of other standards used in New Zealand use ERR-1 instead of ERR-2 and ERR- 3. The usage here is an improved one but ERR-1 can continue to be used.
MSH|^~\&|PMSAPPLICATION|ACME MEDICAL CENTRE|HMX|HMX APPLICATION|200812121359||ORP^O10|00194825|P|2.5 MSA|AR|00963425 ERR||RXO^1^1|103|W PID|1||LLX0159||TESTING^Rosemary^||19551225|F||11|215 GRANGE RD^GREERTON^TAURANGA||^PRN^PH^^64^9^3454567|^WPN^PH^^64^9^3456123 ^afternoons only~^NET^Internet^[email protected]
4.4 RGV – Administration Order Message (Event O15)
The pharmacy order message may be used for the communication of pharmacy and other order messages and shall be used for pharmacy automation messages. The table below describes the structure of the RGV message:
Segment Name Description
MSH Message Header
[{SFT}] Software
[
PID Patient Identification
[PD1] Additional Patient Demographics
[{NK1}] Next of Kin
[{AL1}] Allergy Information
[PV1 Patient Visit
[PV2]] Patient Visit - Additional Info
]
{
ORC Common Order
[{TQ1 Timing and Quantity
[{TQ2}] Additional Timing and Quantity information
}]
Electronic Pharmaceutical Messaging Standard v1 November 2008 50
Segment Name Description
[
RXO Pharmacy /Treatment Order
[
{RXR} Pharmacy/Treatment Route
[
{RXC} Pharmacy/Treatment Component
]
]
]
[
RXE Pharmacy/Treatment Encoded Order
[{TQ1 Timing and Quantity
[{TQ2}] Additional Timing and Quantity information
}]
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component
]
{
RXG Pharmacy/Treatment Give
[{TQ1 Timing and Quantity
[{TQ2}] Additional timing
}]
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component
{
[OBX] Observation/Results
[{NTE}] Notes and Comments (for OBX)
}
}
Electronic Pharmaceutical Messaging Standard v1 November 2008 51
Segment Name Description
}
Table 13: RGV^O15 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.9 for a full list of segments. 2) The RXCs which follow the RXO may not be fully encoded, but those that follow the RXE must be fully encoded. 3) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting Variance to HL7: PD1 and NK1 segments are included for New Zealand specific requirements.
4.4.1 Example of an RGV message: This block is contains the message header identifying it as a administration order and who it is for.
MSH|^~\&|PMSAPPLICATION|ACME MEDICAL CENTRE|HMX|HMX APPLICATION|200812121359||RGV^O15|00963425|P|2.5 PID|1||LLX0159||TESTING^Rosemary^||19551225|F||11|215 GRANGE RD^GREERTON^TAURANGA||^PRN^PH^^64^9^3454567|^WPN^PH^^64^9^3456123^af ternoons only~^NET^Internet^[email protected]
The next section contains the order and instructions to administer 20mg per day for the first week, increasing to 30mg in the second week and increasing to 40mg on the third week and thereafter.
ORC|NW|1234.1||1234|||1^OD||||||07315^TESTDR^JOCK||||NP RXO|9234^Paroxetine Hydrochloride^NZMT|20|40|mg|tab||||N||46|tab| RXR|MTH^Mouth^HL70162 RXG|0||1^OD^1W^20081212^20081218|9234^Paroxetine Hydrochloride^NZMT|20||mg|tab RXG|0||1.5^OD^1W^20081219^20081225|9234^Paroxetine Hydrochloride^NZMT|20||mg|tab RXG|0||2^OD^^20081216|9234^Paroxetine Hydrochloride^NZMT|20||mg|tab
4.5 RRG – Administration Order Response Message (Event O16)
The function of the RRG message is to respond to the RGV message. The table below describes the structure of the RRG message:
Segment Name Description
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
[{SFT}] Software
[
[PID Patient Identification
Electronic Pharmaceutical Messaging Standard v1 November 2008 52
Segment Name Description
{
ORC Common Order
[{TQ1 Timing and Quantity
[{TQ2}] Additional Timing and Quantity information
}]
[
RXG Pharmacy/Treatment Give
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component
]
}
]
Table 14: RRG^O16 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.10 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
4.6 RDS – Dispensing Notification Message (Event O13)
The function of the RDS message is to initiate the transmission of information about the dispensing of an order, once it has been collected. The table below describes the structure of the RDS message.
The ORC must have the filler order number and the order control code RE (results to follow). The RXE and associated RXCs may be present if the receiving application needs any of their data. The RXD carries the dispense data for a given issuance of medicine: thus it may describe a single dose, a half-day dose, a daily dose, a refill of a prescription, etc. The RXD is not a complete record of an order. Use the RXO and RXE segments if a complete order is needed. It is a record from the pharmacy or treatment supplier to another application with drug/treatment dispense and administration instructions.
Segment Name Description
MSH Message Header
[{SFT}] Software
[
PID Patient Identification
[PD1] Additional Demographics
[{AL1}] Allergy Information
Electronic Pharmaceutical Messaging Standard v1 November 2008 53
Segment Name Description
[
PV1 Patient Visit
[PV2] Patient Visit - Additional Info
]
]
{
ORC Common Order
….[{TQ1 Timing and Quantity
……[{TQ2}] Additional Timing and Quantity information
….}]
[
RXO Pharmacy /Treatment Order
[
{RXR} Pharmacy/Treatment Route
[
{RXC} Pharmacy/Treatment Component
]
]
]
[
RXE Pharmacy/Treatment Encoded Order
….[{TQ1 Timing and Quantity
……[{TQ2}] Additional Timing and Quantity information
….}]
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component
]
RXD Pharmacy/Treatment Dispense
{RXR} Pharmacy/Treatment Route
Electronic Pharmaceutical Messaging Standard v1 November 2008 54
Segment Name Description
[{RXC}] Pharmacy/Treatment Component
[{
OBX Results
[{NTE}] Notes and Comments (for OBX)
}]
}
Table 15: RDS^O13 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.7 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
4.6.1 Example of an RDS message: This block is contains the message header identifying it as a medication dispense and who it is for.
MSH|^~\&|PMSAPPLICATION|ACME MEDICAL CENTRE|HMX|HMX APPLICATION|200812121359||RDS^O13|00963425|P|2.5 PID|1||LLX0159||TESTING^Rosemary^||19551225|F||11|215 GRANGE RD^GREERTON^TAURANGA||^PRN^PH^^64^9^3454567|^WPN^PH^^64^9^3456123 ^afternoons only~^NET^Internet^[email protected]
This next section represents one prescription item. It was for Dicloxacillin Sodium in 250 mg capsules to be taken three times a day for seven days (21 capsules) but the dispenser knew that the patient could not take this medication so Erythromycin Ethyl Succinate was substituted after consultation with the prescriber. Note that a RDE message is also sent to the prescriber to request authorisation of the change.
ORC|RE|1234.1||1234|||1^BD||||||07315^TESTDR^JOCK||||NP RXO|1234^Dicloxacillin Sodium^NZMT |250||mg|capsule||||G|21 RXR|MTH^Mouth^HL70162 RXD|1|1994^ Erythromycin Ethyl Succinate ^NZMT|200812121359|14|Tabs|| P555.1||T|||||400|mg
This section represents the next prescription item which was dispensed as requested.
ORC|RE|1234.2||1234|||1^OD||||||07315^TESTDR^JOCK RXO|1255^Omeprazole^NZMT|40||mg|capsule||||G||90 RXR|MTH^Mouth^HL70162 RXD|1|1255^Omeprazole^NZMT |200812121359|90|capsule|| P555.2||N|||||40|mg
Electronic Pharmaceutical Messaging Standard v1 November 2008 55
4.7 RRD – General Order Response Message (Event ^O14)
The function of the RRD message is to respond to an RDS message. The table below describes the structure of the RRD message:
Segment Name Description
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
[{SFT}] Software
[
[PID Patient Identification
]
{
ORC Common Order
[{TQ1 Timing and Quantity
[{TQ2}] Additional Timing and Quantity information
}]
[
RXD Pharmacy/Treatment Dispense
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component
]
}
]
Table 16: RDD ^O14 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.8 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
Electronic Pharmaceutical Messaging Standard v1 November 2008 56
4.8 RDE – Unsolicited Observation Message (Event O11)
The function of the RDE message is to transmit pharmacy encoding of the order to the placer when authorisation is required and then to update that authorisation. The table below describes the structure of the RDE message:
Segment Name Description
MSH Message Header
[{SFT}} Software
[
PID Patient Identification
[PD1] Additional Demographics
[PV1 Patient Visit
[PV2]] Patient Visit – Additional Info
[{IN1 Insurance or Subsidy Card
}]
[{AL1}] Allergy Information
]
{
ORC Common Order
….[{TQ1 Timing and Quantity
……[{TQ2}] Additional Timing and Quantity information
….}]
[
RXO Pharmacy/Treatment Prescription Order
{RXR} Pharmacy/Treatment Route
[{
{RXC} Pharmacy/Treatment Component (for RXO)
}]
]
RXE Pharmacy/Treatment Encoded Order
{TQ1 Timing and Quantity
Electronic Pharmaceutical Messaging Standard v1 November 2008 57
Segment Name Description
[{TQ2}] Additional Timing and Quantity information
}
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component (for RXE)
[{
OBX Results
[{NTE}] Notes and Comments (for OBX)
}]
[BLG] Billing
{[CTI]} Clinical Trial Identification
}
Table 17: RDE^O11 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.5 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting Variance to HL7: The repeating initial ORC /OBX group has been included to enable the inclusion of information specific to NZ processes that is not covered by HL7.
4.8.1 Example of an RDE message: This block is contains the message header identifying it as a medication dispense and who it is for.
MSH|^~\&|PMSAPPLICATION|ACME MEDICAL CENTRE|HMX|HMX APPLICATION|200812121359||RDE^O11|00963425|P|2.5 PID|1||LLX0159||TESTING^Rosemary^||19551225|F||11|215 GRANGE RD^GREERTON^TAURANGA||^PRN^PH^^64^9^3454567|^WPN^PH^^64^9^3456123 ^afternoons only~^NET^Internet^[email protected]
This next section represents one prescription item. It was for Dicloxacillin Sodium in 250 mg capsules to be taken three times a day for seven days (21 capsules) but the dispenser knew that the patient could not take this medication so Erythromycin Ethyl Succinate was substituted after consultation with the prescriber. The value of AR in ORC-1 indicates that authorisation is requested. The prescriber updates this to AP and returns it to the HMX.
ORC|AR|1234.1||1234|||1^TDS||||||07315^TESTDR^JOCK||||NP RXO|1234^Dicloxacillin Sodium^NZMT |250||mg|capsule||||G|21 RXR|MTH^Mouth^HL70162 RXE|1^BD|1994^ Erythromycin Ethyl Succinate ^NZMT|400||mg|Tabs|||T|14|Tabs||||P555.1|0|0|200812121359
This represents the next prescription item which was dispensed as requested and is included for information.
Electronic Pharmaceutical Messaging Standard v1 November 2008 58
ORC|IN|1234.2||1234|||1^OD||||||07315^TESTDR^JOCK RXO|1255^Omeprazole^NZMT|40||mg|capsule||||G||90 RXR|MTH^Mouth^HL70162 RXE|1^OD|1255^Omeprazole^NZMT |40||mg| capsule |||N|90| capsule ||||P555.2|0|0|200812121359
4.9 RRE – Acknowledgment (Event O12)
The function of the RRE message is to respond to an RDE message. The table below describes the structure of the RRE message:
Segment Name Description
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
[{SFT}] Software
[
[PID Patient Identification
]
{
ORC Common Order
[
RXE Pharmacy/Treatment Encoded Order
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component
]
}
]
Table 18: RRE^O11 Message Definition NOTE: Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.6 for a full list of segments.
Electronic Pharmaceutical Messaging Standard v1 November 2008 59
4.10 RAS – Treatment Administration Message (Event O17)
The pharmacy administration message may be used for the communication of the actual administration of individual doses as opposed to the prescribed dosage. The table below describes the structure of the RAS message:
Segment Name Description
MSH Message Header
[{SFT}] Software
[
PID Patient Identification
[PD1] Additional Demographics
[{AL1}] Allergy Information
[PV1 Patient Visit
[PV2]] Patient Visit – Additional Info
]
{
ORC Common Order
[{TQ1 Timing and Quantity
[{TQ2}] Additional timing
}]
[
RXO Pharmacy/Treatment Order
[
{RXR} Pharmacy/Treatment Route
[
{RXC} Pharmacy/Treatment Component
]
]
]
[
RXE Pharmacy/Treatment Encoded Order
Electronic Pharmaceutical Messaging Standard v1 November 2008 60
Segment Name Description
[{TQ1 Timing and Quantity
[{TQ2}] Additional timing
}]
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component
]
{{RXA} Pharmacy/Treatment Administration
RXR Pharmacy/Treatment Route
{[OBX Observation/Result
{[NTE]} Notes and Comments (for OBX)
]}}
{[CTI]} Clinical Trial Identification
}
Table 19: RAS^O17 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.11 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
4.10.1 Example of an RAS message: This block is contains the message header identifying it as an administration order and who it is for.
MSH|^~\&|PMSAPPLICATION|ACME MEDICAL CENTRE|HMX|HMX APPLICATION|200812121359||RAS^O17|00963425|P|2.5 PID|1||LLX0159||TESTING^Rosemary^||19551225|F||11|215 GRANGE RD^GREERTON^TAURANGA||^PRN^PH^^64^9^3454567|^WPN^PH^^64^9^3456123 ^afternoons only~^NET^Internet^[email protected]
The next section contains the order and an administration of 20mg.
ORC|RE|1234.1||1234|||1^OD||||||07315^TESTDR^JOCK||||NP RXO|9234^Paroxetine Hydrochloride^NZMT|20|40|mg|tab||||N||46|tab| RXR|MTH^Mouth^HL70162 RXA|0|2|200812121359|200812121359||20|mg|tab RXR|MTH^Mouth^HL70162
Electronic Pharmaceutical Messaging Standard v1 November 2008 61
4.11 RRA – Treatment Administration Response Message (Event O18)
The function of the RRA message is to respond to the RAS message. The table below describes the structure of the RRA message:
Segment Name Description
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
[{SFT}] Software
[
[PID Patient Identification
{
ORC Common Order
[{TQ1 Timing and Quantity
[{TQ2}] Additional timing
}]
[
{RXA} Pharmacy/Treatment Administration
RXR Pharmacy/Treatment Route
]
}
]
Table 20: RRA^O18 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.13.12 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
Electronic Pharmaceutical Messaging Standard v1 November 2008 62
4.12 Queries for Immunisation Records (QRF Segments)
The VXQ, VXX, and VXR messages defined below incorporate the QRF segment described at section 9.21, ‘QRF – Original Style Query Filter Segment’. ‘QRF-5-other query subject filter’ (section 9.21.5) concerns a locally defined filter for use between two systems which mutually agree on a definition. For transferring vaccination administration data, ‘QRF-5-other query subject filter’ should be structured as shown in Table 21, to transmit up to ten separate search ‘keys’. These search keys are only used to identify one patient’s immunisation record. The message provides for a wide variety of ‘identifying’ keys, including mother’s and/or father’s name and other identifiers; in some cases such information will be needed to identify a specific patient in the immunisation database.
The format of each of the possible ‘search keys’ is given below, and listed in a more structured form in Table 21. These keys are transmitted as strings separated by repeat delimiters. The position of the components within ‘QRF-5-other query subject filter’ is significant. The requester sends values for all the components that are known.
Pos Component Data Type
1 Patient NHI Number~ ST
2 Patient Birth Date~ DT
3 Patient Birth State~ ID
4 Patient Birth Registration Number~ ST
5 Patient Medicaid Number~ ST
6 Mother’s Name Last^First^Middle~ PN
7 Mother’s Maiden Name~ ST
8 Mother’s Social Security Number~ ST
9 Father’s Name Last^First^Middle~ PN
10 Father’s Social Security Number ST
11 Patient Age Range Lower Bound~ NM
12 Patient Age Range Upper Bound~ NM
13 Patient Gender~ ID
14 Search type IS
Table 21: QRF Usage in Vaccination Messages NOTE: Components that are shaded are not used in this implementation Variance to HL7: The search capacity is extended to meet local requirements.
Electronic Pharmaceutical Messaging Standard v1 November 2008 63
4.13 VXQ – Vaccine Query Message (Event V01)
Segment Name Description
MSH Message Header
[{SFT}} Software
QRD Query Definition Segment
[QRF] Query Filter Segment
Table 22: VXQ^O09 Message Definition NOTE: Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.17.3 for a full list of segments.
4.13.1 Example of query for record by NHI number: MSH|^~\&|Practice Manager 2.3|mygp|NIR|NIR|200311161016|| VXQ^V01^VXQ_V01|64816546|P|2.5^NZL QRD|200311161016|R|I|3216546|||1|NHI9290|VXI^Vaccine Information^HL70048
4.13.2 Example of query for record by name, age range and gender MSH|^~\&|Practice Manager 2.3|mygp|NIR|NIR|200311161016|| VXQ^V01^VXQ_V01|64816548|P|2.5^NZL QRD|200311161016|R|I|3216546|||1|^Sanchez^Maria^M|VXI^Vaccine Information^HL70048 QRF|NIR||||~~~~~~~~~~0~5~F
4.13.3 Example query response – no patients MSH|^~\&|NIR|NIR|Practice Manager 2.3|mygp|200309071232|| ACK^V01^ACK|ABC123445|P|2.5^NZL MSA|AR|2093439|No matching patient record found in NIR or NHI
Electronic Pharmaceutical Messaging Standard v1 November 2008 64
4.14 VXX – Response to Vaccine Query Returning Multiple PID Matches Message (Event V02)
The function of the VXX message is to respond to the VXQ message. The table below describes the structure of the VXX message:
Segment Name Description
MSH Message Header
MSA Message Acknowledgment
[{SFT}] Software
QRD Query Definition
[QRF] Query Filter
{PID Patient Identification
[{NK1}] Next of Kin/Associated Parties
}
Table 23: VXX^V02 Message Definition NOTE: Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.17.4 for a full list of segments.
4.14.1 Example query response – multiple patients MSH|^~\&|NIR|NIR|Practice Manager 2.3|mygp|200309071232|| VXX^V02^VXX_V02|ABC123445|P|2.5^NZL MSA|AA|2093439 QRD|200311161016|R|I|3216546|||1|^Sanchez^Maria^M |VXI^Vaccine Information^HL70048 QRF|NIR||||~~~~~~~~~~0~5~F PID|1||ABC0002||Sanchez^Maria^M||20020117|F||10 PID|1||DIS6452||Sanchez^Maria^M||20031206|F||53 PID|1||RAT2791||Sanchez^Maria^M||20010614|F||21
Electronic Pharmaceutical Messaging Standard v1 November 2008 65
4.15 VXR – Vaccine Record Message (Event V03)
The pharmacy order message may be used for the communication of pharmacy and other order messages and shall be used for pharmacy automation messages. The table below describes the structure of the VXR message: Segment Name Description
MSH Message Header
MSA Message Acknowledgment
[{SFT}] Software
QRD Query Definition
[QRF] Query Filter
PID Patient Identification
[PD1] Additional Demographics
[{NK1}] Next of Kin/Associated Parties
[PV1 Patient Visit
[PV2]] Patient Visit – Additional Info
[{IN1 Insurance or Subsidy Card
}]
[{
[ORC] Common Order
[{TQ1 Timing and Quantity
[{TQ2}] Additional timing
}]
RXA Pharmacy Administration
[RXR] Pharmacy Route
[{OBX Observation/Result
[{NTE}] Notes (Regarding Immunisation)
}]
}]
Table 24: VXR^V03 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.17.5 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
Electronic Pharmaceutical Messaging Standard v1 November 2008 66
4.15.1 Example query response – one patient MSH|^~\&|NIR|NIR|Practice Manager 2.3|mygp|200309071232|| VXR^V03^VXR_V03|ABC123445|P|2.5^NZL MSA|AA|2093439 > QRD|200311161016|R|I|3216546|||1|^Sanchez^Maria^M |VXI^Vaccine Information^HL70048 QRF|NIR||||~~~~~~~~~~0~5~F PID|1||ABC0002^^^NHI||Sanchez^Maria^M||20020117|F||10 NK1|1|Sanchez^Peter^K|02 PRD|GP|Smith^Karen^P|||||45564^McKenzie^Jock^^^^^^NZMC ORC|RE|""|16543||||^^^20030219|||||45564^McKenzie^Jock^^^^^^NZMC RXA|0|1|20030219|""|99001^DTaP-IPV^NZVX|1||||45564^McKenzie^Jock ^^^^^^NZMC|||||92834-A83|20030918|||6W|CP RXR|IM|LVL ORC|RE|""|16543||||^^^20030419|||||45564^McKenzie^Jock^^^^^^NZMC RXA|0|2|20030417|""|99001^DTaP-IPV^NZVX|1||||45564^McKenzie^Jock ^^^^^^NZMC|||||92834-B45|200402|||3M|CP RXR|IM|LVL
4.16 VXU – Unsolicited Vaccine Update Message (Event V04)
The function of the VXU message is to report the administration of a vaccine. The table below describes the structure of the VXU message:
Segment Name Description
MSH Message Header
PID Patient Identification Segment
[PD1] Additional Demographics
[{NK1}] Next of Kin/Associated Parties
[PV1 Patient Visit
[PV2]] Patient Visit – Additional Info
[{IN1 Insurance or Subsidy Card
}]
[{
[ORC] Common Order Segment
[{TQ1 Timing and Quantity
[{TQ2}] Additional timing
Electronic Pharmaceutical Messaging Standard v1 November 2008 67
Segment Name Description
}]
RXA Pharmacy Administration Segment
[RXR] Pharmacy Route
{[ OBX Observation/Result
[{NTE}] Notes (Regarding Immunisation)
]}
}]
Table 25: VXU^V04 Message Definition NOTE: 1) Only segments that are used in this message have been documented here. Refer to HL7 v2.5, Chapter 4.17.6 for a full list of segments. 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
4.17 ACK – Acknowledgment (Event R01)
The simple acknowledgment (ACK) can be used where the application does not define a special application level acknowledgment message, or where there has been an error that precludes application processing acknowledgment. It is also used for accept level acknowledgments. The table below shows the segments that are applicable for the acknowledgement message:
Segment Name Description
MSH Message Header
[{ SFT }] Software
MSA Message Acknowledgement
[{ ERR}] Error
Table 26: ACK^R01 Message Definition NOTE: For the general acknowledgment (ACK) message, the value of ‘MSH-9-2 Trigger event’ is equal to the value of ‘MSH-9-2 Trigger event’ in the message being acknowledged. The value of ‘MSH-9-3 Message structure’ for the general acknowledgment message is always ACK.
Electronic Pharmaceutical Messaging Standard v1 November 2008 68
4.18 QBP/RSP – Query by Parameter and Segment Response
Query by parameter and segment responses is one of the available methods in HL7 v2.5. The query consists of a message containing a number of parameters and the response is returned in a format not determined solely by the message structure, but defined in a published conformance statement.
4.18.1 Query
Segment Name Description
QBP^Znn^QBP_Qnn Query Grammar: QBP Message
MSH Message Header Segment
QPD Query Parameter Definition
RCP Response Control Parameter
[PID] Patient ID Segment
[ DSC ] Continuation Pointer
Table 27: QBP^Znn Query Message NOTE: Only segments that are used in this message have been documented here. Variance to HL7: The PID segment has been optionally added, as a more rigorous identification of the patient is often required in New Zealand.
4.18.2 Response
Segment name Description
RSP^Znn^RSP_Knn Response Grammar: Widget Dispense Message
MSH Message Header
MSA Message Acknowledgement
[ERR] Error
QAK Query Acknowledgement
QPD Query Parameter Definition
… Segments as specified in Conformance Statement
[ DSC ] Continuation Pointer
Table 28: RSP^Znn Segment Response
Electronic Pharmaceutical Messaging Standard v1 November 2008 69
5 SUPPLEMENTARY INFORMATION
5.1 Conventions
The following sections describe the use of use of ORC/OBX segments and User Defined tables to convey additional information. When supplementary information is provided in this manner, ORC-1 will be set to IN. This is a New Zealand and Australian extension to a number of existing standards. ORC-16 further clarifies the categories. As the standard required a RXO and RXR as part of this group, they are included, but the mandatory field RXO-6 will contain text suggesting it should be ignored and RXR-1 will contain the code U (unknown). It should be noted that when medicines have already been dispensed on an ePrescription group then these items are also indicated by the use of IN. ORC-16 is also used in other cases to indicate the status of a message.
5.2 PCC - Patient Category
The patient category code has been created to cater for New Zealand specific requirements.
The OBX segments will use the following fields: (a) OBX-2 – contains a standard HL7 data type code, specifying the type of data to follow in OBX-5; (b) OBX-3 – contains a code indicating the information in OBX-5 is patient category information. The SNOMED-CT code is 410598002 (person categorised by age); (c) OBX-5 – contains the patient category code from the table below.
Value Description
A Adult
J Juvenile
Y Child (under 6)
Z HUHC (High Use Health Card)
X Pharmaceutical (Prescription) Subsidy Card
O Oral contraceptive
H Hokianga Ward
Table 29: 99NZPCC – Patient Category Card NOTE: These are the current values at the time of publication. The values may be changed or increased for future use.
Electronic Pharmaceutical Messaging Standard v1 November 2008 70
5.3 FSC – Funding Status Code
The funding status code has been created to cater for New Zealand specific requirements. (a) OBX-2 – contains a standard HL7 data type code, specifying the type of data to follow in OBX-5; (b) OBX-3 – contains a code indicating the information in OBX-5 is funding status information The SNOMED-CT code is 224164009 (benefit status); (c) OBX-5 – contains the funding status code from the table below:
Value Description 1 Community Services Card Holder
3 Non Community Services Card holder
4 PHO Enrolee
Table 30: 99NZFSC – Funding Status Code NOTE: These are the current values at the time of publication. The values may be changed or increased for future use.
5.4 END – Endorsement Codes
The endorsement codes have been created to cater for New Zealand specific requirements. They are used to include structured endorsements that apply to the entire prescription group or each individual item in a prescription group (a) OBX-2 – contains a standard HL7 data type code, specifying the type of data to follow in OBX-5; (b) OBX-3 – contains a code indicating the information in OBX-5 is endorsement information;
Value Description ENT Endorsement
END Endorsement Date
ENE Endorsement Expiry
ENV Endorsement Value
Table 31: 99NZETY – Endorsement Types NOTES: 1) Where one endorsement is linked to another then they must be linked using the same value in OBX- 1 and non related ones must have unique values in OBX-1 2) At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting
(c) OBX-5 – contains the endorsement code from the table below, or supporting values as determined by OBX-3
Value Description CCT Close Control
CCD Certified Condition
Electronic Pharmaceutical Messaging Standard v1 November 2008 71
Value Description USM Unstable Medicine
SPR Specialist Recommended
SPA Special Authority
DSL Dispense stat list medicines once only unless under close control
GSP Generic Substitution allowed unless otherwise stated
GSN Generic Substitution not permitted
NDE Note date of expiry of RX
Table 32: 99NZEND – Endorsement Codes NOTES: 1) The description may have additional text appended to provide further information. For example CCT can be extended to Close Control – dispense weekly in blister packs 2) These are the current values at the time of publication. The values may be changed or increased for future use.
5.5 ACC – Accident Information
If detailed information is required, then the following OBX segments can be used following an ORC. Otherwise for general information applying to the whole order group, an IN1 segment can be used. (a) OBX-2 – contains a standard HL7 data type code, specifying the type of data to follow in OBX-5; (b) OBX-3 – contains a code from the table below, indicating that the subsequent section contains an accident event; (c) OBX-5 – contains the description of the accident event in OBX-3.
Value Element Name Type Opt Rpt (OBX-2)
ACCDTE Accident Date/Time TS O N
ACCCDE Accident Code CE O N
ACCLOC Accident Location ST O N
AUTOST Auto Accident State CE O N
ACCJOB Accident Job Related Indicator ID O N
ACCDTH Accident Death Indicator – ID O N Patient
DTHOTH Accident Death Indicator - ID O N Others
ENTRBY Entered By XCN O N
ACCDCR Accident Description ST O N
BRGTBY Brought in By ST O N
Electronic Pharmaceutical Messaging Standard v1 November 2008 72
Value Element Name Type Opt Rpt (OBX-2)
PLCNTD Police Notified Indicator ID O N
CLMNBR ACC Claim Number ST O N
CLMSTS ACC Claim status CE O N
SCNCDE Accident scene code CE O N
OCCCDE Occupation code CE O N
ACTVTY Activity at time of accident CE O N
Table 33: User Defined Table 99NZACC – Accident Information Example: OBX|1|TX| ACCDCR^Accident Description^99NZACC ||Fell over - broke toe.|||N|||F
5.5.1 ACCDTE – Accident date/time This field contains the date and time of the accident.
5.5.2 ACCCDE – Accident code This field contains the type of accident. Any diagnostic coding system may be used, as different types of facilities in New Zealand have their own preferences for these, e.g. SNOMED, Read, ICD-10.
5.5.3 ACCLOC – Accident location This field contains the location of the accident – city/town code.
5.5.4 AUTOST – Auto accident state This field indicates whether the accident involved a motor vehicle.
5.5.5 ACCJOB – Accident job related indicator This field indicates whether the accident was job related. The values for this field are in the table below:
Value Description
Y Yes
N No
Table 34: HL7 Table 0136 - Yes/No Indicator
5.5.6 ACCDTH – Accident death indicator (patient) This field indicates whether death occurred in the accident for the patient. The values for this field are in the table above.
Electronic Pharmaceutical Messaging Standard v1 November 2008 73
5.5.7 DTHOTH – Accident death indicator (others) This field indicates whether death occurred in the accident for others. The values for this field are in the table above.
5.5.8 ENTRBY – Entered by This field is used to identify the person who entered the information.
5.5.9 ACCDCR – Accident description This field is used to give a description of the accident.
5.5.10 BRGTBY – Brought in by This field indicates who brought the patient in.
5.5.11 PLCNTD – Police notified This field indicates if the police have been advised. The values for this field are in Table 34.
5.5.12 CLMNBR – ACC claim number This free text field contains the accident identifier/unique claim number.
5.5.13 CLMSTS – ACC claim status This field contains the ACC claim status code.
5.5.14 SCNCDE – Accident scene code This field contains the ACC scene code, e.g. home, sports event, road.
5.5.15 OCCCDE – Occupation code This field contains the ACC occupation code.
5.5.16 ACTVTY – Activity at time of accident This field contains the ACC activity code.
Electronic Pharmaceutical Messaging Standard v1 November 2008 74
5.6 ALRT – Administration Alerts and Warnings
As the AL1 segment (section 9.2) is intended for reporting adverse reactions only, an additional section is required for general alerts.
The OBX segments will use the following fields: (a) OBX-3 – will contain the code ‘ALRT’; (b) OBX-5 – will contain a code from the table below, indicating a specific warning or alert, or a code indicating ‘Other’, in the standard CE coding format:
Value Element Name
00 Other
01 Infection
02 Drug Sensitivity
03 Social/Behavioural
04 Non Drug Allergy
05 Patient Requirements
Table 35: User Defined Table 99NZALRT - Administration Alerts and Warnings NOTES: 1) This list is not comprehensive. 2) This usage is a variation to existing New Zealand HL7 v2.4 Standards, bought about by the absence of the OBR segment in this Standard.
(c) If the code in OBX-3 requires further explanation it will be contained in a following NTE as free text; (d) OBX-14 – may contain the date/time that the alert was recorded; (e) OBX-16 – may contain a standard provider identity, identifying the person that recorded the alert.
Example of the use of the ALRT message segment: OBX|1|CE|03 ALRT^administrative alerts and warnings^99NZIN ||03^Social/Behavioural^99NZALRT ||||||F NTE|1|| Uncommunicative
Electronic Pharmaceutical Messaging Standard v1 November 2008 75
5.7 ATT – Attachments
Attachments to the order, if required, shall be included as an OBX.
The OBX may be followed by a NTE segment describing the attachment.
Example 1: OBX|1|ED|PDF^Display format in PDF^99NZATF||^^PDF^Base64^AAEIHEiwoMGDCBMqX+...|||N|||F
Example 2: OBX|1|FT|XML^Display format in XML^99NZATF|| ...|||N|||F
5.7.1 OBX-2 – Value type This field contains the data type for the data in OBX-5, e.g. ED, FT.
5.7.2 OBX-3 – Observation identifier This field contains a code taken from the table below, describing the original format of the data in OBX-5:
Value Element Name Type (OBX-2) PDF Document file format developed by Adobe Systems ED
CDA Clinical Document Architecture format ED
TIFF File format for mainly photographic images ED
JPEG Compression file format for photographic images ED
MSWORD Document file format developed by Microsoft ED
RTF Document file format developed by Microsoft ED
TXT Plain-text file format FT
HTML HyperText Markup Language is a markup language for the creation FT of web pages
XML Extensible Markup Language is a markup language capable of FT describing different kinds of data for systems
Table 36: User Defined Table 99NZATF – Format Codes
5.7.3 OBX-5 – Observation value This field contains the actual attachment. The format is defined by OBX-2 and OBX-3.
Electronic Pharmaceutical Messaging Standard v1 November 2008 76
6 QUERY BY PARAMETER AND SEGMENT RESPONSE
6.1 Query Development Methodology
Typically, an individual HL7 conformant query would evolve as follows:
An institution or data owner decides it would like to make information available via a query. It decides precisely what data will be made available and how it will be offered. Knowing its own data, the data owner will define its query to return one of three representations of the data: (a) As traditional HL7 segments; (b) As rows and columns of data from a precisely defined Virtual Table; (c) As rows of human readable text ready to output to a screen or printer. NOTE: Only segmented pattern response is supported in this Standard. Human readable responses would be included as ED data types in an HL7 segment.
Next, the data owner specifies exactly which input variables the client can use to control the data that the server agrees to return.
The complete specification of what data are available, how the data will be returned and what variables can be valued or constrained in a query is called the conformance statement.
The conformance statement concept is critical to the proper usage of the query/response pair. In the absence of a conformance statement, the client would be unaware of the existence of the query, let alone how to use it or what to expect from it. The data owner advertises the existence of and support for a query, by publishing a conformance statement.
The conformance statement can contain the following broad structure:
(a) Introduction including title, trigger events, mode, characteristics and purpose; (b) Query grammar; (c) Response grammar; (d) Input specification and commentary; (e) Response control; (f) Output specifications and commentary. NOTE: Not all structures are used in this Standard.
6.2 Query Specification Format
This section discusses how the client may represent a query for information.
HL7 now recommends one primary method with three basic variants for specifying a query.
This query model with its variants is intended to assist implementers in translating specific query needs from the ordinary prose of the business model into an appropriate HL7 query paradigm. The paradigm selected will depend upon the philosophy of the institution; whether it will allow relative freedom to client systems in composing query expressions, or whether it will rigidly control the fields and operations to be offered. The following sections describe the features of the HL7 query variant model supported in this Standard.
The QBP_Q11 structure supports a segment pattern response and contains the MSH, QPD, RCP and DSC segments. Its default trigger event is Q11. A standard or site-defined query may use this trigger event, or may specify a unique trigger event value in its conformance statement. If a unique trigger event value is chosen for a site-defined query, that value must begin with ‘Z’.
Electronic Pharmaceutical Messaging Standard v1 November 2008 77
6.3 Response Format
6.3.1 Segment pattern response Segment pattern data responses reflect the traditional way of offering data within HL7. The server responds to queries by returning a pattern of HL7 segments. For example, the core of a response to a query for pharmacy data might be defined by the following segment grammar:
{PID ORC [{RXO}] } In other words, patient information will be returned in the PID segment, and pharmacy dispensing in ORC and RXO segments. In this style, the message returned by a server is often a close approximation to an existing dispensing notification HL7 message.
In creating a conformance statement for a segment pattern response, the data owner must decide on the exact segment grammar it will return. The output specification of the conformance statement for a segment pattern response will have a structure very similar to the message definition of a standard HL7 transaction. It must define a grammar of segments that will be returned. For each segment it should clarify, where necessary, the meaning of each field, the cardinality of the data and whether the data is optional or required.
The RSP_K11 supports a segment pattern response to the QBP and contains the MSH, MSA, ERR, QAK, QPD, variable content segments and the DSC. Its default trigger event is K11. A standard or site-defined response may use this trigger event or specify a unique trigger event value in its conformance statement. If a unique trigger event value is chosen for a site-defined response, that value must begin with ‘Z’.
6.3.2 Query by simple parameter In the simple parameter query variant, the input parameters are passed in order as successive fields of an HL7 segment. The server need only read them from the corresponding HL7 fields, and plug them into an internal function to evaluate the query.
This is the most basic form of the query, in which the server specifies a fixed list of parameters in its Conformance Statement. For example, the server may direct the querying system to specify a medical record number, a beginning date and an ending date. When invoking the query, the client passes a specific value for each parameter. This is analogous to invoking a stored procedure against a database.
The parameter definition segment (i.e. the QPD) can be seen as a generalisation of the QRD. Each field in the QRD corresponds to one parameter of the QPD instance. HL7 recommends that queries defined by QRD segments be recast as an HL7 v2.5 ‘Query By Parameter’.
The obvious implementation gain is that the server can simply map the input values to the parameters specified in the Conformance Statement. An already known function or procedure is called to evaluate the query and select data to be returned. The bulk of the work effort has already been invested in the development of this predefined function or procedure.
6.4 Query/Response Conformance Statement
The introduction of the query/response Conformance Statement concept is not intended to imply system certification. It is intended to promote the definition and implementation of well-specified queries. As in previous versions, support for queries is not required for HL7 conformance.
In the introduction, the data owner describes the data being made available and the purpose of the query. The data owner specifies the exact coded value “Query Name”, which the client must use to invoke this query.
The query grammar defines the exact segments the client may send. For each field of those segments, the
Electronic Pharmaceutical Messaging Standard v1 November 2008 78
Conformance Statement will define how the server will interpret client values. For example, the Patient Name field is interpreted as a regular expression match.
The response grammar defines the exact pattern of segments that the server will return. Each segment pattern response will specify its own pattern of segments. For example, pharmacy data queries will return patterns of ORC and OBX, while demographic queries may respond with patterns of PID, PV1 segments. NOTE: In the case of an HL7-defined query, a specific section of the HL7 Standard will define a Conformance Statement. By contrast, in the case of a site-defined query, the Conformance Statement is written by analysts and programmers of the server application/system and is available to the analysts and programmers of the client application/system.
6.5 Using the Conformance Statement
Critical to the proper usage of the new query/response pairs is the Conformance Statement concept. In the absence of a Conformance Statement, the client might not be aware of the existence of a query, or might not know how to use it or what to expect from it.
The server advertises the existence of, and support for, a query by publishing a Conformance Statement. The Conformance Statement identifies the query, specifies what items can be queried and describes what the response will look like.
6.5.1 Formal specification of the conformance statement The Conformance Statement begins with a table that summarises the characteristics and identifying information about the query to which the Conformance Statement applies:
Segment Name Description
Query Statement ID (Query The unique identifier applying to this Conformance Statement. This value is ID=Znn): transmitted as the first component of QPD-1 (message query name field).
Type: Usually “Query”, except for publish-and-subscribe Conformance Statements for which the value should be “Publish”.
Query Name: The name corresponding to the identifier in Query Statement ID. This value is transmitted as the second component of QPD-1 (message query name field).
Query Trigger ( = MSH-9): The exact value that the client will transmit in the MSH-9 Message Type field of the query message.
Query Mode: Whether the query may be sent in “Real Time” (including Bolus) or in “Batch”. The value “Both” indicates that both modes are acceptable.
Response Trigger ( = MSH- The exact value that the server will transmit in the MSH-9 Message Type 9): field of the response message.
Query Characteristics: Particular features of this query. This is free text intended to help the query implementer in selecting among queries.
Purpose: The end result that this query is intended to accomplish. Free text
Response Characteristics: Particular features of this response. This is free text intended to help the query implementer in selecting among queries.
Based on Segment Pattern: For queries that return a segment pattern response, this is the (non-query response) message type upon which the segment pattern is based.
Table 37: Conformance Statement Specification
Electronic Pharmaceutical Messaging Standard v1 November 2008 79
6.5.2 Query grammar The Conformance Statement shows a query grammar. This is a brief model of the segments used in the query message:
Segment Name Description QBP^Znn^QBP_Qnn Query Grammar: QBP Message
MSH Message Header Segment
QPD Query Parameter Definition
RCP Response Control Parameter
[PID] Patient Identifier
[ DSC ] Continuation Pointer
Table 38: QBP^Znn Query Message Variance to HL7: The PID segment has been optionally added, as a more rigorous identification of the patient is often required in New Zealand.
6.5.3 Response grammar The Conformance Statement always shows a response grammar. If the query response is segment pattern, the response grammar should specify the segments, order, optionality and repetition, equivalent to the message specifications within HL7 Standards:
Segment Description Group Comment Support Name Control Indicator RSP^Znn^ Response Grammar: RSP_Knn Diagnostic Response Message
MSH Message Header
MSA Message Acknowledgement
[ERR] Error
QAK Query Acknowledgement
QPD Query Parameter Definition
… Segments as specified in Conformance Statement
[ DSC ] Continuation Pointer
Table 39: RSP^Znn Response Message NOTE: The Conformance Statement for each QBP/RSP pair shall specify an explicit segment pattern grammar in place of the ellipses shown above in the RSP_K11 grammar.
Electronic Pharmaceutical Messaging Standard v1 November 2008 80
6.5.4 Group control The name of a segment group.
6.5.5 Comment Specifies the opening or closing of a segment group and the relevance of the segment in a Hit Count. NOTE: Only positive value is noted.
6.5.6 Support indicator Allows the server to indicate whether an optional segment or segment group will be supported, or whether the segment or segment group is dependant on an input parameter. NOTE: The default understanding is that is the server knows the information; it will be sent.
6.5.7 QPD input parameter specification The Input Parameter Specification section of the Conformance Statement looks very much like an attribute table and is followed by a commentary on the fields. Each row of the QPD Input Parameter Specification specifies one user parameter within the QPD segment. Values for user parameters are transmitted in successive fields of the QPD segment, beginning at QPD-3:
Field Seq (Query Name Key/ Sort Len Data Opt ID=Znn) Search Type
1 MessageQueryName . 60 CE R
2 QueryTag 32 ST R
3 InputItem . . .
Table 40: QPD Input Parameter Specification
6.5.7.1 Field seq The ordinal number of the element being discussed. Sequence 1 is always Message Query Name, and sequence 2 is always Query Tag. Sequence 3 and above are reserved for user parameters.
6.5.7.2 Name The user-defined name for the element as it will be used in the query.
For Conformance Statements published in the HL7 Standard, the Input Parameter Specification table includes the Conformance Statement ID in parentheses in the upper left-hand cell. This allows the table to be imported automatically into the HL7 database.
6.5.7.3 Key/search This field identifies which element is the key and which elements are searchable. The key field is designated by a value of ‘K’. A value of ‘S’ designates fields upon which an indexed search can be performed by the source. ‘L’ designates non-indexed fields. Searching on a non-indexed field requires the server to perform a linear scan of the database. If this column is left blank, the field may not be searched.
6.5.7.4 Sort Valued as ‘Y’ if the output of the query can be sorted on this field. This column should only be valued in Virtual Tables that are used as output specifications.
6.5.7.5 Len The maximum field length that will be transmitted by the source.
Electronic Pharmaceutical Messaging Standard v1 November 2008 81
6.5.7.6 Type The data type of this user parameter.
6.5.8 QPD input parameter field description and commentary The QPD input parameter field description and commentary provides a more detailed description of each of the fields transmitted in the QPD segment:
Input Parameter Component Data Description (Query ID=Znn) Name Type
MessageQueryName CE Must be valued Z99^WhoAmI^HL7 format
Query Tag ST Unique to each query message instance
InputItem CX
Table 41: QPD Query Control Parameter Field Description and Commentary NOTE: The indicated trigger events are the default values for MSH-9-2 Trigger Event. Standard and site- defined queries may use these trigger events or may specify unique trigger event values in their Conformance Statements. Unique trigger event values for site-defined queries must begin with “Z”.
6.5.8.1 Input parameter The name of the field whose value is being transmitted.
6.5.8.2 Component name When the input parameter is of a composite data type (e.g. XPN), this is the name of an individual component of the composite input parameter. Only those components that may be valued should be listed in this column.
6.5.8.3 Data yype The data type of the parameter or component.
6.5.8.4 Description A narrative description of the parameter or component and how it is to be used.
6.5.9 RCP input parameter field description and commentary Provides a more detailed description of each of the fields transmitted in the RCP (Response Control Parameters) segment:
Field Seq Data (Query Name Component Name Len Description ID=Znn) Type The position The name When the field referenced by “Name” The The data A narrative within the of the field is of a composite data type (e.g. maximum type of the description of RCP whose XPN), this is the name of an length of parameter the parameter segment that value is individual component of the the field or or component the field being composite input parameter. Only component and how it is occupies transmitted those components that may be to be used valued should be listed in this column.
Table 42: RCP Response Control Parameter Field Description and Commentary
Electronic Pharmaceutical Messaging Standard v1 November 2008 82
7 QUERY TO HMX REQUESTING AN ORDER
7.1 Order Retrieval
Requests for an order are submitted using a query by parameter (QBP) message. The response is a segment pattern response (RSP), containing the original order.
The names of the input and output fields are not specified in the query message, but according to the Conformance Statement, are identified by QPD-1(message query name). The MSH-9-2 (trigger event) and the QPD-1 (message query name) are this query's only distinguishing elements. The requesting system must refer to this query's Conformance Statement to learn more about the input and output fields.
There is a separate Conformance Statement for each of the different query types.
7.2 Prescription Order Retrieval Conformance Statement
The order retrieval query returns the original pharmacy order. The brokering systems will accept single- person queries only. Batch mode queries will not be supported. Segment Name Description
Query Statement ID (Query Z60 ID=Z60):
Type: Query
Query Name: Prescription Order Retrieval
Query Trigger ( = MSH-9): QBP^Q60^QBP_Q11
Query Mode: Both
Response Trigger ( = MSH-9): RSP^K61^RSP_K31
Query Characteristics: Placer order group number must be supplied.
Purpose: To retrieve prescription order from HMX
Response Characteristics:
Based on Segment Pattern: RDE^O11
Table 43: Prescription Order Retrieval Conformance Statement
Segment Name Description
QBP^Z60^QBP_Q11 Query Grammar: QBS Message
MSH Message Header Segment
QPD Query Parameter Definition
RCP Response Control Parameter
[ DSC ] Continuation Pointer
Table 44: QPB^Z60 Query Message
Electronic Pharmaceutical Messaging Standard v1 November 2008 83
RSP^Z61^RSP_Z61 Response Grammar: Group Comment Support Control Indicator
MSH Message Header
MSA Message Acknowledgement
[ERR] Error
QAK Query Acknowledgement
QPD Query Parameter Definition
[{SFT}} Software
[
PID Patient Identification PIDG Begin PID group
[PD1] Additional Demographics
[PV1 Patient Visit
[PV2]] Patient Visit - Additional Info
[{IN1 Insurance
}]
[{AL1}] Allergy Information
]
{
ORC Common Order ORCG Begin ORC group
….[{TQ1 Timing and Quantity
……[{TQ2}] Additional Timing
….}]
[
RXO Pharmacy/Treatment Prescription Order
{RXR} Pharmacy/Treatment Route
[
{RXC} Pharmacy/Treatment
Electronic Pharmaceutical Messaging Standard v1 November 2008 84
RSP^Z61^RSP_Z61 Response Grammar: Group Comment Support Control Indicator Component (for RXO)
]
]
[RXE Pharmacy/Treatment Encoded Order
{TQ1 Timing and Quantity
[{TQ2}] Additional Timing
}
{RXR} Pharmacy/Treatment Route
[{RXC}] Pharmacy/Treatment Component (for RXE)
]
[{
OBX Results OBXG Begin OBX group
[{NTE}] Notes and Comments (for End OBX Group OBX)
}] End ORC Group
[BLG] Billing
{[CTI]} Clinical Trial Identification
}
Table 45: Response Message Returning RDE or OMP Format NOTE: The extra RDE segments are shown as optional so an OMP formatted message can be returned using this format
7.2.1 QPD input parameter specification
Field Seq Name Key/ Len Type Opt Rep Element (Query ID=Z60) Search Name
1 MessageQuery 60 CE C Name
2 QueryTag 32 ST R
3 Placer Group S 250 ST R ORC-4 (Placer Number Group number)
Electronic Pharmaceutical Messaging Standard v1 November 2008 85
7.2.2 QPD input parameter field description and commentary
Input Parameter Component Type Description (Query ID=Z60) Name
MessageQueryName CE Must be valued Z60^ Prescription Order Retrieval^ HISO
QueryTag ST Unique to each query message instance. Suggest Identifier for order group concatenated with a date/time stamp.
PatientID CX The patient for who this order is to be retrieved. It is strongly recommended this should be the NHI number but could be any local scheme.
Placer Group Number ST The identifier of this order on the brokering server – and attached to the patient’s order form, or the specimens
7.2.3 RCP response control parameter field description and commentary
Field Seq Name Component Len Type Description (Query Name ID=Z60)
1 Query Priority 1 ID (D)eferred or (I)mmediate. Default is I.
2 Quantity 10 CQ Limited Request
Quantity NM Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment.
Units CE CHaracters, LInes, PaGes, or RecorDs. Default is LI.
3 Response 60 CE Real time or Batch. Default is R. Modality
7 Segment 256 ID What segment group(s) are to be group inclusion included. If this field is not valued, all segment groups will be included.
7.3 New Zealand Parameters
The broker will process a query for a pharmacy order in Immediate mode only. The response will be provided as a segmented OMP or RDE message. Therefore, the valid parameters in the RCP segment will be: (a) RCP-1 = I (Immediate); and (b) RCP-3 = R (Real Time) Other values will be ignored and extra parameters such as RCP-7 (segment group) will not be processed. If given incorrect or extra values, the system will assume the default values, or reject the query if the query contents are insufficient.
Electronic Pharmaceutical Messaging Standard v1 November 2008 86
8 QUERY TO SIR REQUESTING MEDICATION PROFILE
This messaging standard relates to the content related to transactional flows of information between parties. That the medication profile information sourced from a shared information repository (SIR) and what format the data is sent to and stored in a SIR is out of scope, and will be determined separately if and when a SIR is established. The messaging standard can support the exchange of structured and unstructured content formats such as PDF and XML which may be used by a SIR e.g. a SIR could provide a medication profile as a PDF or a XML document.
8.1 Order Retrieval
Requests for an order are submitted using a query by parameter (QBP) message. The response is a segment pattern response (RSP), either containing a series of observation segments or a single ORC/OBX group containing an agreed format rendition of the history.
The names of the input and output fields are not specified in the query message, but according to the Conformance Statement, are identified by QPD-1(message query name). The MSH-9-2 (trigger event) and the QPD-1 (message query name) are this query's only distinguishing elements. The requesting system must refer to this query's Conformance Statement to learn more about the input and output fields.
There is a separate Conformance Statement for each of the different query types.
8.1.1 Medication profile (display format) conformance statement The medication profile query returns medication profile in an agreed format, formatted in one of the SIR report layouts.
The SIR will accept single-person queries only; batch mode queries will not be supported. The SIR requires demographic details in addition to the patient identifier supplied in the query parameter list:
Query Statement ID (Query ID=Z64): Z64
Type: Query
Query Name: Medication Profile (display format)
Query Trigger (= MSH-9): QBP^Z64^QBP_Q11
Query Mode: Both
Response Trigger (= MSH-9): RSP^Z65^RSP_K11
Query Characteristics: Patient NHI must be supplied and supported by demographic information
Purpose: To retrieve patient medication profile in an agreed format
Response Characteristics:
Based on Segment Pattern: OMP^O09
Table 46: Medication Profile (Display Format) Conformance Statement
Electronic Pharmaceutical Messaging Standard v1 November 2008 87
QBP^Z64^QBP_Q11 Query Grammar: QBS Message MSH Message Header Segment
QPD Query Parameter Definition
RCP Response Control Parameter
[ DSC ] Continuation Pointer
Table 47: Query Grammar
RSP^Z65^RSP_K11 Response Group Comment Support Grammar: Control Indicator MSH Message Header
MSA Message Acknowledgement
[ERR] Error
QAK Query Acknowledgement
QPD Query Parameter Definition
{ Query Result Cluster
[ PIDG Begin PID Group
PID Patient Identification
] End PID Group
ORCG Begin ORC Group
ORC Observations Report ID
{ OBXG Begin OBX Group
[OBX] Observation/Result
} End OBX Group
} End Query Results
DSC Continuation Pointer
Table 48: Response Grammar
Electronic Pharmaceutical Messaging Standard v1 November 2008 88
8.1.1.1 QPD input parameter specification
Field Name Key/ Len Type Opt Table Element Name Seq Search (Query ID=Z64) 1 MessageQuery 60 CE R Name
2 QueryTag 32 ST R
3 Patient ID S 250 CX R PID-3 Patient Identifier
4 Patient Name 250 XPN R PID-5 Patient Name
5 DOB 26 TS R PID-8
6 Address 250 XAD O PID-11 Patient Address
7 Requestor ID S 250 XCN R OBX-6 Responsible Observer
Table 49: QPD Input Parameter Specification
8.1.1.2 QPD input parameter field description and commentary Input Component Type Description Parameter Name (Query ID=Z64) MessageQueryN CE Must be valued Z64^medication profile (display ame format)^HISO
QueryTag ST Unique to each query message instance (recommend it should be a unique id that exists over time)
Patient ID CX Patient for whom history is requested (Required)
Patient Name XPN Required
DOB TS Required
Address XAD Patient address where available
Requestor XCN The person requesting the profile
Table 50: QPD Input Parameter Field Description and Commentary
Electronic Pharmaceutical Messaging Standard v1 November 2008 89
8.1.1.3 RCP response control parameter field description and commentary
Field Name Component Len Type Description Seq Name (Query ID=Z64) 1 Query
1 Query 1 ID (D)eferred or (I)mmediate. Priority Default is I. New Zealand only accepts Immediate mode in this field.
2 Quantity 10 CQ Limited Request
Quantity NM Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment.
Units CE CHaracters, LInes, PaGes, or RecorDs. Default is LI.
3 Response 60 CE Real time or Batch. Default is R. Modality New Zealand only accepts Real time mode in this field.
7 Segment 256 ID What segment group(s) are to be group included. If this field is not inclusion valued, all segment groups will be included.
Table 51: RCP Response Control Parameter Field Description and Commentary NOTE: Values that New Zealand does not accept will be ignored and extra parameters such as RCP-7 (Segment Group) will not be processed. If given incorrect or extra values, the SIR will use the above values.
8.1.2 SIR query response message OBX-5 Embedded Data: If the Base 64 encoded data to be embedded in the HL7 message is split across multiple OBX segments, the OBX segments are ordered by the sequential Set-Id, in OBX-1.
There can only be one embedded file in each ORC/OBX set.
8.1.3 Medication profile (segmented format) conformance statement This mode is not supported currently but is included for future implementation.
The medication profile query returns medication profile information in the form of the Segment Pattern Response corresponding to the OMP^O09 – unsolicited transmission of an observation message. It returns all of the results which meet the criteria defined in the QPD – Query Parameter Definition Segment of the RSP^R11 – Segment Pattern Response message.
The SIR will accept single-person queries only; batch mode queries will not be supported. The SIR requires
Electronic Pharmaceutical Messaging Standard v1 November 2008 90
demographic details in addition to the patient identifier supplied in the query parameter list.
Query Statement ID (Query Z66 ID=Z66): Type: Query
Query Name: Medication Profile (segmented format)
Query Trigger ( = MSH-9): QBP^Z66^ QBP_Q11
Query Mode: Both
Response Trigger ( = MSH-9): RSP^Z67^RSP_K11
Query Characteristics: Patient NHI must be supplied and supported by demographic information
Purpose: To retrieve patient medication history as an HL7 formatted message
Response Characteristics:
Based on Segment Pattern: OMP^O09
Table 52: Medication Profile (Segment Format) Conformance Statement
QBP^Z66^QBP_Q11 Query Grammar: QBS Message MSH Message Header Segment
QPD Query Parameter Definition
RCP Response Control Parameter
[ DSC ] Continuation Pointer
Table 53: Query Grammar
RSP^Z67^RSP_K11 Response Grammar: Group Comment Support Control Indicator MSH Message Header
MSA Message Acknowledgement
[ERR] Error
QAK Query Acknowledgement
QPD Query Parameter Definition
{ Query Result Cluster
Electronic Pharmaceutical Messaging Standard v1 November 2008 91
RSP^Z67^RSP_K11 Response Grammar: Group Comment Support Control Indicator
[ PIDG Begin PID Group
PID Patient Identification
[PD1] Additional Demographics
[{NK1}] Next of Kin/Associated Parties
[PV1 Patient Visit
[PV2]] Patient Visit – Additional Information
] End PID Group
{ ORCG Begin ORC Group
…
Content by local agreement
…
} End Query Results
DSC Continuation Pointer
Table 54: Response Grammar
8.1.3.1 QPD input parameter specification Field Seq Name Key/ Len Type Opt Element (Query Search Name ID=Z66) 1 MessageQuery 60 CE R Name
2 QueryTag 32 ST R
3 Patient ID S 250 CX R PID-3 Patient Identifier
4 Patient Name 250 XPN R PID-5 Patient Name
5 DOB 26 TS R PID-8
Electronic Pharmaceutical Messaging Standard v1 November 2008 92
Field Seq Name Key/ Len Type Opt Element (Query Search Name ID=Z66)
6 Address 250 XAD O PID-11 Patient Address
7 Requestor ID 250 XCN R OBX-16 Responsible Observer
Table 55: QPD Input Parameter Specification
8.1.3.2 QPD input parameter field description and commentary Input Parameter Component Type Description (Query ID=Z66) Name MessageQueryName CE Must be valued Z66^ medication profile (segmented format^HISO)
QueryTag ST Unique to each query message instance. (recommend it should be a unique id that exists over time)
Patient ID CX Patient for whom history is requested
Patient Name XPN Required
DOB TS Required
Address XAD Patient address when available
Requestor XCN The person requesting the history.
Table 56: QPD Input Parameter Field Description and Commentary
8.1.3.3 RCP response control parameter field description and commentary Field Seq Name Component Len Type Description (Query Name ID=Z66) 1 Query 1 ID (D)eferred or (I)mmediate. Default Priority is I. New Zealand will only accept Immediate mode in this field
2 Quantity 10 CQ Limited Request
Quantity NM Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment.
Electronic Pharmaceutical Messaging Standard v1 November 2008 93
Field Seq Name Component Len Type Description (Query Name ID=Z66)
Units CE CHaracters, LInes, PaGes, or RecorDs. Default is LI.
3 Response 60 CE Real time or Batch. Default is R. Modality New Zealand will only accept Real time mode in this field.
7 Segment 256 ID What segment group(s) are to be Group included. If this field is not valued, inclusion all segment groups will be included.
Table 57: RCP Response Control Parameter Field Description and Commentary NOTE: Values that New Zealand does not accept will be ignored and extra parameters such as RCP-7 (Segment Group) will not be processed. If given incorrect or extra values, the SIR will reject the query.
8.1.4 SIR query response message ORC-2 Placer Order Number: The Query Tag from QPD-2 should be a unique value (at least for each facility). This value can be used for the Placer Order Number in the query response for ORC-2.
Electronic Pharmaceutical Messaging Standard v1 November 2008 94
9 SEGMENT DEFINITION
9.1 Conventions
The following table structure has been defined for the fields within each segment. Fields that have been shaded are not supported in this Standard:
Seq Element Name Len Type Opt Rpt Table
Table 58: Conventions
9.1.1 Seq Column 1. Identifies the position of the data within the segment.
9.1.2 Element name Column 2. Descriptive name of the field.
9.1.3 Len Column 3. Defines the total length of the field. The maximum length of a field is calculated to include the component and subcomponent separators. The repetition separator is not included in calculating the maximum length, since the maximum length is that of a single occurrence. A composite data type may not have a maximum length less than the maximum length of its largest component data type (i.e., in PID-3, CX includes HD, which in turn includes an IS, ID, and ST).
9.1.4 Opt Column 5. Refer to Table 8 for the allowed values for the Option field.
9.1.5 Rpt Column 6. Refer to Table 9 for allowed values in the Repeat field.
9.1.6 Table Column 7. Contain a link to any table referenced in this document.
9.1.7 Data types Column 4. Not all the data types are listed here. For full details of all data types, refer to HL7 v2.5, Chapter 2A.
9.1.7.1 AD – address This data type specifies the address of a person, place or organisation. The maximum length is 415.
Component Seq Name Len Type Opt Table Comments
1 Street 120 ST O Specifies the street or mailing address of a Address person or institution. When referencing an institution, this first component is used to specify the institution name. When used in
Electronic Pharmaceutical Messaging Standard v1 November 2008 95
Component Seq Name Len Type Opt Table Comments connection with a person, this component specifies the first line of the address.
2 Other 120 ST O Specifies the second line of address. In Designation general, it qualifies address, for example Fourth Floor. When referencing an institution, this component specifies the street address.
3 City 50 ST O Specifies the city, district or place where the addressee is located
4 State or 50 ST O Specifies the state or province where the Province addressee is located
5 Postal Code 12 ST O Specifies the zip or postal code where the addressee is located
6 Country 3 ID O Table B 5
7 Address 3 ID O Table 60 Specifies the kind or type of address Type
8 Other 50 ST O Specifies any other geographic Geographic designation that may be necessary. It Designation includes county, etc.
Table 59: AD – Address Components NOTE: AD is only used in the LA1 data type. Replaced elsewhere by the XAD data type as of HL7 v2.3.
Value Description
BA Bad address
N Birth (nee) (birth address, not otherwise specified)
BDL Birth delivery location (address where birth occurred)
F Country Of Origin
C Current Or Temporary
B Firm/Business
H Home
L Legal Address
M Mailing
O Office
P Permanent
RH Registry home. Refers to the information system, typically managed by a public health agency, that stores patient information such as immunisation histories or
Electronic Pharmaceutical Messaging Standard v1 November 2008 96
Value Description cancer data, regardless of where the patient obtains services.
BR Residence at birth (home address at time of birth)
Table 60: HL7 Table 0190 – Address Type
9.1.7.2 AUI – authorisation information This data type specifies the identifier or code for an insurance authorisation instance and its associated detail. The maximum length is 239.
Seq Component Len Type Opt Table Comments Name 1 Authorisation 30 ST O Identifier assigned to the Number authorisation. 2 Date 8 DT O Date of authorisation. 3 Source 199 ST O Source of authorisation
Table 61: AUI – Authorisation Information Components NOTE: Replaces the CM data type used in HL7 Chapter 6.5.6.14 IN1-14, as of v 2.5.
9.1.7.3 CCD – charge code and date The CCD data type specifies whether a charge action is based on an invocation event or is time-based. The maximum length of this field is 28.
Component Seq Name Len Type Opt Table Comments
1 Invocation 1 ID R Table 63 Specifies the code for the event Event precipitating/triggering the charge activity
2 Date/time 26 TS O The second component is used to express the exact time to charge for the ordered service; it is used only when the CCD-1 value is T. When used, it is expressed as a TS data type.
Table 62: CCD – Charge Code and Date Components NOTE: Replaces the CM data type used in HL7 Chapter 4.5.2.1 BLG-1, as of v 2.5.
Value Description
D On discharge
O On receipt of order
R At time service is completed
S At time service is started
T At a designated date/time
Table 63: HL7 Table 0100 – Invocation Event
Electronic Pharmaceutical Messaging Standard v1 November 2008 97
9.1.7.4 CE – coded element The CE data type transmits codes, and the text associated with the code. The maximum length is 483 in v2.5.
Component Seq Name Len Type Opt Table Comments
1 Identifier 20 ST O Sequence of characters (the code) that uniquely identifies the item being referenced by the
2 Text 199 ST O Name or description of the item in question.
3 Name of Coding 20 ID O Table 65 Each coding system is assigned a unique System identifier.
4 Alternate 20 ST O Analogous to Identifier, see note above. Identifier
5 Alternate Text 199 ST O Analogous to Text, see note above.
6 Name of 20 ID O Table 65 Identifies the coding scheme being used in Alternate the alternative identifier component. Coding system
Table 64: CE – Coded Element Components NOTES: 1) This has been replaced by CNE and CWE as of HL7 v2.3.1 – retained for backwards compatibility as of HL7 v2.5. 2) The length of this component has increased from 250 to 483.
The most common Coding System values are provided in the table below: This table is not comprehensive.
Value Description
99zzz Local general code (where z is an alphanumeric character)
RC Read Classification
NZPOCs New Zealand Pathology Order Codes
LN Logical Observation Identifier Names and Codes (LOINC®)
DSM4 Diagnostic and Statistical Manual of Mental Disorders – Fourth Edition
HF HPI Facility number
HI HPI Identifier for individuals (CPN)
HL7nnnn HL7 Defined Codes where nnnn is the HL7 table number
HO HPI Organisation number
SNM-ccyy Systemised Nomenclature of Medicine (SNOMED), where ccyy is the year of the code set version. At the time this Standard was published
Electronic Pharmaceutical Messaging Standard v1 November 2008 98
Value Description these were 1986 and 1993.
SCT_NZ_yyyymm SNOMED – CT (Clinical Terms), where yyyymmdd is the date of the dd code set version. At the time this Standard was published this was 20080731
BTH-ccyy Bethesda Codes, where ccyy is the year of the code set version. (At the time this standard was published, these were 1991 and 2001).
ICD-v ICD-10 CM, where v is the version number. At the time this Standard was published, these were 3, 4, 5, 6
ISOnnnn International Standards Organisation, where nnnn is the ISO table number
ISO + Refer Table B 10
Table 65: HL7 User Defined Table 0396 – Coding Systems
9.1.7.5 CF - coded element with formatted values This data type transmits codes and the formatted text associated with the code. This data type can be used to transmit for the first time the formatted text for the canned text portion of a report, for example, a standard radiological description for a normal chest X-ray. The receiving system can store this information and in subsequent messages only the identifier need be sent. Another potential use of this data type is transmitting master file records that contain formatted text. The maximum length is 65536.
The components, primary and alternate, are defined exactly as in the CE data type with the exception of the second and fifth components, which are of the formatted text data type.
This data type has six components as follows:
Seq Component Len Type Opt Table Comments Name
1 Identifier 20 ST O Sequence of characters (the code) that uniquely identifies the item being referenced by the
2 Formatted 65536 FT O Name or description of the item in question Text with the addition of embedded formatting instructions.
3 Name of 20 ID O Table 65 Contains the name of the coding system Coding employed. System
4 Alternate 20 ST O Alternate sequence of characters (the Identifier code) that uniquely identifies the item being referenced by the
5 Alternate 65536 FT O Name or description of the alternate Formatted identifier in question with the addition of Text embedded formatting instructions.
Electronic Pharmaceutical Messaging Standard v1 November 2008 99
Seq Component Len Type Opt Table Comments Name
6 Name of 20 ID O Table 65 Contains the name of the coding system Alternative employed for the alternate identifier. Coding System
Table 66: CF – Coded Element with Formatted Values Components
9.1.7.6 CM – composite This component has been withdrawn from use as of HL7 v2.5.
9.1.7.7 CN – composite ID number and name This component has been withdrawn from use as of HL7 v2.5.
9.1.7.8 CP – composite price The CP data type is used to indicate the composite price of the service. The maximum length is 543.
Component Seq Name Len Type Opt Table Comments
1 Price 20 MO O The only required component; usually containing a decimal point.
2 Price Type 2 ID O Table 68 A coded value, data type ID
3 From Value 16 NM O Each is a NM data type and together they specify the ‘range’. The range can be defined as either time or quantity. For example, the range can indicate that the first 10 minutes of the procedure has one price. Another repetition of the data type can use the range to specify that the following 10 to 60 minutes of the procedure is charged at another price per. A final repetition can specify the final 60 to n minutes of the procedure at a third price.
4 To Value 16 NM O See From Value, above
5 Range Units 483 CE O A coded value defined by the standard table of units for either time or quantity. This describes the units associated with the range, e.g. seconds, minutes, hours, days, quantity (i.e. count). It is required if
6 Range Type 1 ID O Table 69
Table 67: CP – Composite Price Components NOTE: This data type is often used to define a repeating field within a given segment.
Electronic Pharmaceutical Messaging Standard v1 November 2008 100
Value Description
AP Administrative price or handling fee
DC Direct unit cost
IC Indirect unit cost
PF Professional fee for performing provider
TF Technology fee for use of equipment
TP Total price
UP Unit price, may be based on length of procedure or service
Table 68: HL7 Table 0205 – Price Type
Value Description
P Pro-rata. Apply this price to this interval, pro-rated by whatever portion of the interval has occurred/ been consumed.
F Flat-rate. Apply the entire price to this interval, do not pro-rate the price if the full interval has not occurred/been consumed.
Table 69: HL7 Table 0298 – Range Type
9.1.7.9 CQ – composite quantity with units Component Seq Name Len Type Opt Table Comments
1 Quantity 16 NM O Specifies the numeric quantity or amount of an entity
2 Units 483 CE O The units in which the quantity is expressed. Field-by-field, default units may be defined within the specifications.
Table 70: CQ – Composite Quantity with Units Components NOTE: CQ cannot be legally expressed when embedded within another data type. Its use is constrained to a segment field.
9.1.7.10 CWE - coded with exceptions Specifies a coded element and its associated detail. The CWE data type is used when (a) More than one table may be applicable; or (b) The specified HL7 or externally defined table may be extended with local values; or (c) When text is in place, the code may be omitted.
Component Seq Name Len Type Opt Table Comments
1 Identifier 20 ST O Sequence of characters (the code) that uniquely identifies the item being referenced. Different coding schemes will
Electronic Pharmaceutical Messaging Standard v1 November 2008 101
Component Seq Name Len Type Opt Table Comments have different elements here.
2 Text 199 ST O The descriptive or textual name of the identifier
3 Name of 20 ID O Table 65 Each coding system is assigned a unique coding system identifier
4 Alternate 20 ST O Analogous to Identifier, see note above identifier
5 Alternate text 199 ST O Analogous to Text, see note above
6 Name of 20 ID O Table 65 Analogous to Name of coding system, see alternate note above coding system
7 Coding system 10 ST C Version ID for the coding system identified version ID by first three sub components, above. Retained for backward compatibility.
8 Alternate 10 ST O Version ID for the coding system identified coding system by last three sub components, above. version ID Retained for backward compatibility.
9 Original text 199 ST O The original text that was available to an automated process or a human before a specific code was assigned.
Table 71: CWE – Coded with Exceptions Components NOTE: The length of this component has increased from 250 to 705
9.1.7.11 CX – extended composite ID with check digit The CX data type is used for specifying an identifier with its associated administrative detail.
Component Seq Name Len Type Opt Table Comments
1 ID Number 15 ST R The value of the identifier itself
2 Check Digit 1 ST O This is not an add-on produced by the message processor. It is the check digit that is part of the identifying number used in the sending application. If the sending application does not include a self-generated check digit in the identifying number, this component should be valued “null”.
3 Check Digit 3 ID O Table 73 Contains the code identifying the check digit Scheme scheme employed
4 Assigning 227 HD O Table 129 The assigning authority is the system, Authority application or body that actually generates the ID number. If this field is blank, then the value in the first component is assumed to be the National Health Index (NHI) number. In this case the assigning authority is the Ministry of
Electronic Pharmaceutical Messaging Standard v1 November 2008 102
Component Seq Name Len Type Opt Table Comments Health (NZLMOH). If another identifier is being messaged then this field must be filled in.
5 Identifier Type 5 ID O Table B 9 A code corresponding to the type of identifier. Code In some cases, this code may be used as a qualifier to the Assigning Authority component.
6 Assigning 227 HD O The place or location identifier where the Facility identifier was first assigned to the patient
7 Effective Date 8 DT O The first date, if known, on which the identifier is valid and active
8 Expiration Date 8 DT O The last date, if known, on which the identifier is valid and active
9 Assigning 705 CWE O The geo-political body that assigned the Jurisdiction identifier in component 1
10 Assigning 705 CWE O The agency or department that assigned the Agency or identifier in component 1 Department
Table 72: CX – Extended Composite ID with Check Digit Components NOTE: The length of this component has increased from 250 to 1913
Value Description
NHI Check digit algorithm in the New Zealand National Health Index (NHI)
ISO ISO 7064: 1983
M10 Mod 10 algorithm
M11 Mod 11 algorithm
Table 73: HL7 Table 0061 – Check Digit Scheme NOTE: The check digit and code identifying check digit scheme are “null” if ID is alphanumeric.
9.1.7.12 DLD – discharge to location and date Specifies the healthcare facility to which the patient was discharged and the date. The maximum length is 53.
Component Seq Name Len Type Opt Table Comments
1 Discharge 20 IS R Specifies the healthcare facility to which Location the patient was discharged. Use HPI Facility Code.
2 Effective 26 TS O Specifies the date on which the patient was Date discharged to a healthcare facility
Electronic Pharmaceutical Messaging Standard v1 November 2008 103
Table 74: DLD – Discharge to Location and Date Components NOTE: Replaces the CM data type used in HL7 Chapter 3.4.3.37 PV1-37, as of v 2.5.
9.1.7.13 DR – date/time range The maximum length is 53.
Component Seq Name Len Type Opt Table Comments
1 Range Start 26 TS O The first component contains the earliest Date/Time date/time (time stamp) in the specified range
2 Range End 26 TS O The second component contains the latest Date/Time date/time in the specified range. Note that the TS (time stamp) data type allows the specification of precision.
Table 75: DR – Date/Time Range Components NOTE: DR cannot be legally expressed when embedded within another data type. Its use is constrained to a segment field.
9.1.7.14 DT – date This specifies the century and year with optional precision to month and day. The maximum length is 8.
Component Seq Name Len Type Opt Table Comments
1 Date 8 The precision of a date may be expressed by limiting the number of digits used with the format specification YYYY[MM[DD]]. Thus, YYYY is used to specify a precision of year, YYYYMM specifies a precision of month, and YYYYMMDD specifies a precision of day.
Table 76: DT – Date Component NOTE: Prior to HL7 v 2.3, this data type was specified in the format YYYYMMDD. As of HL7 v2.3, month and days are no longer required. By site-specific agreement, YYYYMMDD may be used where backward compatibility shall be maintained.
9.1.7.15 DTM - date/time Specifies a point in time using a 24-hour clock notation. The maximum length is 24.
Component Seq Name Len Type Opt Table Comments
Date/Time 24
Table 77: DTM – Date/Time Component
The number of characters populated (excluding the time zone specification) specifies the precision. If the time zone (+/-ZZZZ) is not included, the time zone defaults to that of the local time zone of the sender.
Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]. Thus:
Electronic Pharmaceutical Messaging Standard v1 November 2008 104
(a) only the first four are used to specify a precision of "year"; (b) the first six are used to specify a precision of "month"; (c) the first eight are used to specify a precision of "day"; (d) the first ten are used to specify a precision of "hour”; (e) the first twelve are used to specify a precision of "minute”; (f) the first fourteen are used to specify a precision of "second”; (g) the first sixteen are used to specify a precision of "one tenth of a second”; (h) the first nineteen are used to specify a precision of "one ten thousandths of a second”.
9.1.7.16 ED – encapsulated data The ED data type transmits encapsulated data from a source system to a destination system. It contains the identity of the source system, the type of data, the encoding method of the data, and the data itself. It contains the data that is to be sent to that system. The maximum length is 65536.
Component Seq Name Len Type Opt Table Comments
1 Source 227 HD O A unique name that identifies the system application that was the source of the data
2 Type of data 9 ID R Table 79 Identical to ‘type of data’ component in the reference pointer (RP) data type. An ID type that declares the general type of data (from HL7 v2.4).
3 Data subtype 18 ID O Table 80 Identical to ‘subtype’ component in the reference pointer (RP) data type. An ID data type declaring the format for the data of sub component types (from HL7 v2.4).
4 Encoding 6 ID R Table 81 The type of encoding, if present, used to represent successive octets of binary data as displayable ASCII characters.
5 Data 65536 TX R Displayable ASCII characters which constitute the data to be sent from source application to destination application.
Table 78: ED – Encapsulated Data Components
Value Description
AP Other application data, typically uninterpreted binary data (HL7 v2.3 and later)
AU Audio data (HL7 v2.3 and later)
IM Image data (HL7 v2.3 and later)
multipart Multipurpose Internet Mail Extension (MIME) multipart package
TEXT Machine readable text document (HL7 v2.3.1 and later)
Table 79: Constrained from HL7 Table 0191 – Type of Referenced Data
Electronic Pharmaceutical Messaging Standard v1 November 2008 105
Value Description BASIC ISDN PCM audio data
DICOM Digital Imaging and Communications in Medicine
FAX Facsimile data
GIF Graphics Interchange Format
HTML Hypertext Markup Language
JOT Electronic ink data (Jot 1.0 standard)
JPEG Joint Photographic Experts Group
Octet-stream Uninterpreted binary data
PDF Print Document Format
PICT PICT format image data
PostScript PostScript program
RTF Rich Text Format
SGML Standard Generalised Markup Language (HL7 v2.3.1 and later)
TIFF TIFF (Tagged Image File Format) image data
x-hl7-cdalevel-one HL7 Clinical Document Architecture Level One document
XML Extensible Markup Language (HL7 v2.3.1 and later)
Table 80: HL7 User Defined Table 0291 - Subtype of referenced data
Value Description
A A – no encoding – data are displayable ASCII characters
Hex Hexadecimal encoding – consecutive pairs of hexadecimal digits represent consecutive single octets
Base64 Encoding as defined by MIME Standard RFC 1521. Four consecutive ASCII characters represent three consecutive octets of binary data. Base64 utilises a 65-character subset of US-ASCII, consisting of both the upper and lower case alphabetic characters, digits “0” through “9”, “+”, “/”, and “=”.
Table 81: HL7 Table 0299 – Encoding
9.1.7.17 EI – entity identifier The entity identifier defines a given entity within a specified series of identifiers. The maximum length is 427.
Component Seq Name Len Type Opt Table Comments
1 Entity 199 ST O This is usually defined to be unique within the series of identifiers created
Electronic Pharmaceutical Messaging Standard v1 November 2008 106
Component Seq Name Len Type Opt Table Comments identifier by the Assigning Authority, defined by a hierarchic designator.
2 Namespace 20 IS O Used as the HL7 identifier for the user- ID defined table of values for this component
3 Universal ID 199 ST C Is a string formatted according to the scheme defined by the Universal ID Type
4 Universal ID 6 ID C Table 83 type
Table 82: EI – Entity Identifier Components
Value Description
DNS An Internet dotted name, either in ASCII or as integers
GUID Same as UUID
The CEN Healthcare Coding Scheme Designator; identifiers used in DICOM HCD follow this assignment scheme
HL7 Reserved for future HL7 registration schemes
ISO An International Standards Organisation Object Identifier
L, M, N These are reserved for locally defined coding schemes
Random Usually a base64 encoded string of random bits. The uniqueness depends on the length of the bits. Mail systems often generate ASCII string ‘unique names’, from a combination of random bits and system names. Such identifiers will not be constrained to the base64 character set.
UUID The DCE Universal Unique Identifier
x400 An X.400 MHS format identifier
x500 An X.500 directory name
Table 83: HL7 Table 0301 – Universal ID Type NOTE: X400, X500, and DNS are not technically universally valid in perpetuity. Names may be de-registered from an existing user and registered to a new user. In the case of order numbers the following usage is recommended:
Sub Component Type Notes
Electronic Pharmaceutical Messaging Standard v1 November 2008 107
Sub Component Type Notes dispenser
Table 84 Order Number Identifier
9.1.7.18 EIP – entity identifier pair Specifies an identifier assigned to an entity by either the placer or the filler system. If both components are populated, the identifiers must refer to the same entity. The maximum length is 855.
Component Seq Name Len Type Opt Table Comments
1 Placer Assigned 427 EI O Specifies an identifier assigned to an Identifier entity by the placer system
2 Filler Assigned 427 EI O Specifies an identifier assigned to an Identifier entity by the filler system
Table 85: EIP – Entity Identifier Pair Components NOTE: Replaces the CM data type used in HL7 Chapter 4.5.1.8 – ORC-8, as of v2.5.
9.1.7.19 ERL – error location This data type identifies the segment and its constituent where an error has occurred. The maximum length is 18.
Component Seq Name Len Type Opt Table Comments
1 Segment ID 3 ST R Specifies the 3-letter name for the segment
2 Segment 2 NM R Identifies the segment occurrence Sequence within the message
3 Field Position 2 NM O Identifies the number of the field within the segment. The first field is assigned a number of 1.
4 Field Repetition 2 NM O Identifies the repetition number of the field
5 Component 2 NM O Identifies the number of the Number component within the field
6 Sub Component 2 NM O Identifies the number of the sub- Number component within the component
Table 86: ERL – Error Location Components
Electronic Pharmaceutical Messaging Standard v1 November 2008 108
9.1.7.20 FC - financial class This component contains the financial class assigned to a person. The maximum length is 47.
Component Seq Name Len Type Opt Table Comments
1 Financial Class 20 IS R This component contains the financial class Code assigned to a person
2 Effective Date 26 TS O This component contains the effective date/time of the person’s assignment to the financial class specified in the first component
Table 87: FC – Financial Class Components
9.1.7.21 FN - family name This data type allows full specification of the surname of a person. Where appropriate, it differentiates the person's own surname from that of the person's partner or spouse, in cases where the person's name may contain elements from either name. It also permits messages to distinguish the surname prefix (such as "van" or "de") from the surname root. The maximum length is 194.
Component Seq Name Len Type Opt Table Comments
1 Surname 50 ST R The person's family name, usually the person's last name
2 Own 20 ST O Optional component for a Surname Prefix, Surname for example the "van" in "Ludwig van Prefix Beethoven".
3 Own 50 ST O The portion of the surname that is derived Surname from the person's own surname, as distinguished from any portion that is derived from the surname of the person's partner or spouse. If the person's surname has legally changed to become (or incorporate) the surname of the person's partner or spouse, this is the person's surname immediately prior to such change. Often this is the person's "maiden name".
4 Surname 20 ST O Refer Surname Prefix, above Prefix From Partner / Spouse
5 Surname 50 ST O The portion of the person's surname that is From Partner derived from the surname of the person's / Spouse partner or spouse, as distinguished from the part derived from the person's own surname. If no portion of the person's surname is derived from the surname of the person's partner or spouse, this component is not valued.
Table 88: FN – Family Name Components NOTE: Appears ONLY in the XCN and XPN data types.
Electronic Pharmaceutical Messaging Standard v1 November 2008 109
9.1.7.22 FT – formatted text data
Component Seq Name Len Type Opt Table Comments
Coded Value 65536 This data type is derived from the string data type by for HL7 allowing the addition of embedded formatting Defined instructions. These instructions are limited to those Tables that are intrinsic and independent of the circumstances under which the field is being used. The FT field is of arbitrary length (up to 64k) and may contain formatting commands enclosed in escape characters.
Table 89: FT – Formatted Text Data Component
9.1.7.23 HD – hierarchic designator This field identifies an entity, either administrative, system, application, or other, with responsibility for managing or assigning a defined set of instance identifiers (e.g. placer or filler number, patient identifiers, provider identifiers, etc.). This entity may be a particular health care application such as a registration system that assigns patient identifiers, a governmental entity such as a licensing authority that assigns professional identifiers or drivers’ license numbers, or a facility where such identifiers are assigned. The maximum length is 227.
Component Seq Name Len Type Opt Table Comments
1 Namespace 20 IS O Table 91 Used as the HL7 identifier for the user ID defined table of values for this component
2 Universal ID 199 ST C A string, formatted according to the scheme defined by the Universal ID type
3 Universal ID 6 ID C Table 83 type
Table 90: HD – Hierarchic Designator Components
Value Description
No suggested values defined
Table 91: No Suggested Values At the time of publication there were no defined values for this component.
9.1.7.24 ID – coded value for HL7 defined tables The value of such a field follows the formatting rules for an ST field, except that it is drawn from a table of valid values. There will be a HL7 table number associated with ID data types. The maximum length varies and is dependent on the length of the longest code in the code set.
Seq Component Name Len Type Opt Table Comments
Coded Value for HL7 Defined Tables
Table 92: ID – Coded Value for HL7 Defined Tables Component
Electronic Pharmaceutical Messaging Standard v1 November 2008 110
9.1.7.25 IS – coded value for user defined tables The value of such a field follows the formatting rules for a ST field, except that it is drawn from a site-defined (or user defined) table of valid values. There will be a HL7 table number associated with IS data types. The maximum length is 20.
Seq Component Name Len Type Opt Table Comments
Coded Value for HL7 20 User Defined Tables
Table 93: IS – Coded Value for HL7 Defined Tables Component
9.1.7.26 LA1 - location with address variation 1 Specifies a location and its address. The maximum length is 790.
Seq Component Len Type Opt Table Comment Table
1 Point of 20 IS O Table 91 Specifies the code for the point Care where patient care is administered. It is conditional on person location type (e.g., nursing unit or department or clinic). After floor, it is the most general patient location designation.
2 Room 20 IS O Table 91 Specifies the code for the patient room. After point of care, it is the most general person location designation.
3 Bed 20 IS O Table 91 Specifies the code for the patient bed. After room, it is the most general person location designation.
4 Facility 227 HD O This is subject to site interpretation but generally describes the highest level physical designation of an institution or medical centre, etc. It is the most general person location designation.
5 Location 20 IS O Table 91 Specifies the code for the status Status or availability of the location. For example, it may convey bed status.
6 Patient 20 IS O Table 95 Person location type is the Location categorisation of the person’s Type location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field.
Electronic Pharmaceutical Messaging Standard v1 November 2008 111
Seq Component Len Type Opt Table Comment Table
7 Building 20 IS O Table 91 Specifies the code for the building where the person is located. After facility, it is the most general person location designation.
8 Floor 20 IS O Table 91 Specifies the code for the floor where the person is located. After building, it is the most general person location designation.
9 Address 415 AD O Specifies the address of a location
Table 94: LA1 – Location with Address Variation 1 Components NOTE: Replaces the CM data type used in HL7 Chapters 4.14.1.8 RXO-8 and 4.14.4.8 RXE-8 as of v 2.5. Retained for backward compatibility only as of v 2.5.
Value Description
C Clinic
D Department
H Home
N Nursing Unit
O Provider’s Office
P Phone
S SNF
Table 95: HL7 User Defined Table 0305 – Person Location Type
9.1.7.27 LA2 – location with address variation 2 Specifies a location and its address. The maximum length allowed is 790.
Seq Component Len Type Opt Table Comment Name
1 Point of Care 20 IS O Table 91 Specifies the code for the point where patient care is administered. It is conditional on LA2 6 Person Location Type (e.g., nursing unit or department or clinic). After floor, it is the most general patient location designation.
2 Room 20 IS O Table 91 Specifies the code for the patient room. After point of care, it is the most general person location designation.
3 Bed 20 IS O Table 91 Specifies the code for the patient's bed. After room, it is the most general
Electronic Pharmaceutical Messaging Standard v1 November 2008 112
Seq Component Len Type Opt Table Comment Name person location designation.
4 Facility 227 HD O This is subject to site interpretation but generally describes the highest level physical designation of an institution, medical centre or enterprise. It is the most general person location designation.
5 Location 20 IS O Table 91 Specifies the code for the status or Status availability of the location. For example, it may convey bed status.
6 Patient 20 IS O Table 95 Person location type is the Location categorisation of the person’s location Type defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. It usually includes values such as nursing unit, department, clinic, etc.
7 Building 20 IS O Table 91 Specifies the code for the building where the person is located. After facility, it is the most general person location designation.
8 Floor 20 IS O Table 91 Specifies the code for the floor where the person is located. After building, it is the most general person location designation.
9 Street 120 ST O Specifies the street or mailing address Address of a person or institution. When referencing an institution, it is used to specify the institution name. When used in connection with a person, it specifies the first line of the address.
10 Other 120 ST O Specifies the second line of an address. Designation In general, it qualifies address. For example, Fourth Floor. When referencing an institution, this component specifies the street address.
11 City 50 ST O Specifies the city, or district or place where the person or institution is located
12 State or 50 ST O Specifies the state or province where Province the person or institution is located
13 Zip or Postal 12 ST O Specifies the zip or postal code where Code the person or institution is located
14 Country 3 ID O Table B 5
15 Address 3 ID O Table 60 Specifies the kind or type of address Type
Electronic Pharmaceutical Messaging Standard v1 November 2008 113
Seq Component Len Type Opt Table Comment Name
16 Other 50 ST O Specifies any other geographic Geographic designation that may be necessary Designation
Table 96: LA2 - Location with Address Variation 2 Components NOTE: Replaces the CM data type used in HL7 Chapters 4.14.5.13 RXD-13, 4.14.6.11 RXG-11 and 4.14.7.11 RXA-11 as of v 2.5. Retained for backward compatibility only as of v 2.5.
9.1.7.28 MO – money This data type specifies an amount of money and the denomination in which it is expressed. The maximum length is 20.
Seq Component Len Type Opt Table Comment Name
1 Quantity 16 NM O The first component is a quantity
2 Denomination 3 ID O The second component is the denomination in which the quantity is expressed. If the denomination is not specified, MSH-17 country code is used to determine the default.
Table 97: MO – Money Components
9.1.7.29 MSG - message type This field contains the message type, trigger event, and the message structure ID for the message. The maximum length is 15.
Seq Component Len Type Opt Table Comments Name
1 Message Code 3 ID R Table B 4 Specifies the message type code
2 Trigger Event 3 ID R Table B 3 Specifies the trigger event code
3 Message 7 ID R Table B 2 Specifies the abstract message Structure structure code
Table 98: MSG – Message Type Components NOTE: Replaces the CM data type used in HL7 Chapter 2.16.9.9 MSH-9 as of v 2.5.
9.1.7.30 NA –numeric array This is used to represent a series (array) of numeric values, each one having a data type of NM. The maximum length is 65536.
Seq Component Len Type Opt Table Comment Name
1 Value1 16 NM R
2 Value2 16 NM O
Electronic Pharmaceutical Messaging Standard v1 November 2008 114
Seq Component Len Type Opt Table Comment Name
3 Value3 16 NM O
4 Value4 16 NM O
...
Table 99: NA – Numeric Array Components
9.1.7.31 NM – numeric Seq Component Len Type Opt Table Comment Name
1 Numeric 16 A number represented as a series of ASCII numeric characters consisting of an optional leading sign (+ or -), the digits and an optional decimal point. In the absence of a sign, the number is assumed to be positive. If there is no decimal point, the number is assumed to be an integer.
Table 100: NM – Numeric Component
9.1.7.32 OSD – order sequence definition This data type specifies a fully coded version for forming a relationship between an order and one or more other orders. The relationship may be sequential or a cyclical pattern. The maximum length is 110.
Seq Component Len Type Opt Table Comment Name
1 Sequence/Results 1 ID R Table 102 Identifies whether sequence Flag conditions or a repeating cycle of orders is defined
2 Placer Order 15 ST R Contains the first component of Number: Entity the placer order number, entity Identifier identifier
3 Placer Order 6 IS O Table 129 Contains the second component Number: of the placer order number, Namespace ID namespace ID
4 Filler Order 15 ST R Contains the first component of Number: Entity the filler order number, entity Identifier identifier.
5 Filler Order 6 IS O Table 129 Contains the second component Number: of the filler order number, Namespace ID namespace ID.
6 Sequence 12 ST O Defines the relationship between Condition Value the start/end of the related predecessor or successor order and the current order from ORC- 2, 3 or 4.
Electronic Pharmaceutical Messaging Standard v1 November 2008 115
Seq Component Len Type Opt Table Comment Name
7 Maximum Number 3 NM O The maximum number of repeats of Repeats to be used only on cyclic groups. The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first.
8 Placer Order 15 ST R Contains the next to the last Number: Universal component of the placer order ID number, universal ID
9 Placer Order 6 ID O Table 83 Contains the last component of Number: Universal the placer order number ID Type
10 Filler Order 15 ST R Contains the next to the last Number: Universal component of the filler order ID number, universal ID
11 Filler Order 6 ID O Table 83 Contains the last component of Number: Universal the placer order number ID Type
Table 101: OSD – Order Sequence Definition Components NOTES: 1) Usage of the OSD is restricted to the TQ data type (especially as it is applied to the ORC-7). Retained for backward compatibility only as of v 2.5. 2) Replaces the CM data type used in the TQ data type, component 10, as of v 2.5. Value Description
S Sequence conditions
C Repeating cycle of orders
R Reserved for possible future use
Table 102: HL7 User Defined Table 0524 – Sequence Condition
9.1.7.33 PL – person location This data type is used to specify a patient location within a particular health care institution. Which components are valued depends on the needs of the site. Seq Component Len Type Opt Table Comment Name
1 Point of Care 20 IS O Table 91 Conditional on person location type (e.g. nursing unit, department, clinic). After Floor, the most general patient location designation.
2 Room 20 IS O Table 91 Specifies the code for the patient room. After point of care, it is the most general person location designation.
Electronic Pharmaceutical Messaging Standard v1 November 2008 116
Seq Component Len Type Opt Table Comment Name
3 Bed 20 IS O Table 91 Specifies the code for the patient's bed. After room, it is the most general person location designation.
4 Facility 227 HD O This is subject to site interpretation, but generally describes the highest level physical designation of an institution, medical centre or enterprise. It is the most general person location designation.
5 Location Status 20 IS O Table 91 Specifies the code for the status or availability of the location. For example, it may convey bed status.
6 Patient Location 20 IS C Table 95 Person location type is the Type categorisation of the person’s location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. It usually includes values such as nursing unit, department, clinic, etc.
7 Building 20 IS O Table 91 Specifies the code for the building where the person is located. After facility, it is the most general person location designation.
8 Floor 20 IS O Table 91 Specifies the code for the floor where the person is located. After building, it is the most general person location designation.
9 Location 199 ST O Describes the location in free text Description
10 Comprehensive 427 EI O The unique identifier that Location represents the physical location Identifier as a whole without regard for the individual components. This accommodates sites that may have a different method of defining physical units or who may code at a less granular level. For example, point of care, room, and bed may be 1 indivisible code.
11 Assigning 227 HD O The entity that creates the data Authority for for the individual physical location Location components
Table 103: PL – Person Location Components
Electronic Pharmaceutical Messaging Standard v1 November 2008 117
9.1.7.34 PT - processing type This data type indicates whether to process a message as defined in HL7 Application (level 7) Processing rules.
Seq Component Len Type Opt Table Comment Name
1 Processing 1 ID O Table 105 A value that defines whether the ID message is part of a production, training, or debugging system
2 Processing 1 ID O Table 106 A value that defines whether the Mode message is part of an archival process or an initial load
Table 104: PT – Processing Type Components
Value Description
P Process this message as normal
D This message is being used for debugging purposes. It should be properly acknowledged but all data contained within this message should be ignored.
T This message is being used for training purposes. It should be properly acknowledged and data may be used to populate a training database (optional).
Table 105: HL7 Table 0103 – Processing ID
Value Description
A Archive
R Restore from archive
I Initial load
Current processing, transmitted at intervals (scheduled or on T demand)
Not present Not present (the default, meaning current processing)
Table 106: HL7 Table 0207 – Processing Mode
9.1.7.35 RI – repeat interval Contains the interval between repeated services. The maximum length is 206.
Seq Component Len Type Opt Table Comment Name
1 Repeat 6 IS O Table 108 The repeating frequency with which Pattern the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems. The first component may repeat, with
Electronic Pharmaceutical Messaging Standard v1 November 2008 118
Seq Component Len Type Opt Table Comment Name repeat values separated by a space. The repeats are interpreted as connected by logical ANDs.
2 Explicit Time 199 ST O This component explicitly lists the Interval actual times referenced by the code in the first component, in the following format: HHMM,HHMM,HHMM. It will be used to clarify the first component in cases where the actual times vary within an institution.
Table 107: RI – Repeat Interval Components
Value Description
Q
Q
Q
Q
Q
Q
Q
OD Once a day (same as Q1D)
BID twice a day at institution-specified times (e.g. 9AM-4PM)
TID three times a day at institution-specified times (e.g. 9AM-4PM-9PM)
QID four times a day at institution-specified times (e.g. 9AM-11AM-4PM-9PM) xID “X” times per day at institution-specified times, where X is a numeral 5 or greater, e.g. 5ID=five times per day; 8ID=eight times per day
QAM in the morning at institution-specified time
QSHIFT during each of three eight-hour shifts at institution-specified times
QOD every other day (same as Q2D)
QHS every day before the hour of sleep
QPM in the evening at institution-specified time
C service is provided continuously between start time and stop time
U
Electronic Pharmaceutical Messaging Standard v1 November 2008 119
Value Description cron specification
PRN given as needed
PRNxxx where xxx is some frequency code (e.g. PRNQ6H); given as needed over the frequency period
Once one time only. This is also the default when this component is null.
Meal Related Timings
A Ante (before)
P Post (after)
I Inter (e.g. between this meal and the next, between dinner and sleep)
M Cibus Matutinus (breakfast)
D Cibus Diurnus (lunch)
V Cibus Vespertinus (dinner)
Table 108: HL7 User Defined Table 0335 Repeat Pattern
9.1.7.36 RP - reference pointer This data type transmits information about data stored on another system. It contains a reference pointer that uniquely identifies the data on the other system, the identity of the other system, and the type of data. The maximum length is 273.
Seq Component Len Type Opt Table Comment Name
1 Pointer 15 ST O A unique key assigned by the system that stores the data. The key, which is a ST data type, is used to identify and access the data
2 Application 227 HD O A unique designator of the system that stores ID the data. Application ID’s must be unique across a given HL7 implementation.
3 Type of Data 9 ID O Table 79 An ID data type that declares the general type of data.
4 Subtype 19 ID O Table 80 An ID data type declaring the format for the data of subcomponent
Table 109: RP Reference Pointer Components
Type-subtype Combinations
Possible subtypes are specific to main types (though in principle the same subtype could be used for more than one main type), and so are defined under their main types.
Additional subtypes may be added to this Standard. In addition, private, non-standard subtypes may be defined by agreement between cooperating parties. All private, non-standard subtypes should begin with the letter Z to distinguish them from the standard subtypes.
Electronic Pharmaceutical Messaging Standard v1 November 2008 120
9.1.7.37 SAD – street address This data type specifies an entity's street address and associated detail. The maximum length is 184.
Seq Component Len Type Opt Table Comment Name
1 Street or Mailing 120 ST O This component specifies the street Address or mailing address of a person or institution. When referencing an institution, this first component is used to specify the institution name. When used in connection with a person, this component specifies the first line of the address.
2 Street Name 50 ST O
3 Dwelling Number 12 ST O
Table 110: SAD – Street Address Component NOTE: Appears ONLY in the XAD data type.
9.1.7.38 SI – sequence ID
Seq Component Len Type Opt Table Comment Name
Sequence ID 4 A non-negative integer in the form of a NM field. The uses of this data type are defined in the sections defining the segments and messages in which it appears.
Table 111: SI - Sequence ID Component NOTE: The maximum length of 4 allows for a number between 0 and 9999 to be specified.
9.1.7.39 SN - structured numeric The structured numeric data type is used to unambiguously express numeric clinical results along with qualifications. This enables receiving systems to store the components separately, and facilitates the use of numeric database queries. The corresponding sets of values indicated with the
If
Seq Component Len Type Opt Table Comment Name
1 Comparator 2 ST O Defined as greater than, less than, greater than or equal, less than or equal, equal, and not equal, respectively (= ">" or "<" or ">=" or "<=" or "=" or "<>" If this component is not valued, it defaults to
Electronic Pharmaceutical Messaging Standard v1 November 2008 121
Seq Component Len Type Opt Table Comment Name equal ("=").
2 Num1 15 NM O A number.
3 Separator/Suffix 1 ST O "-" or "+" or "/" or "." or ":" Examples: |>^100| (greater than 100) |^100^-^200| (equal to range of 100 through 200) |^1^:^228| ratio of 1 to 128, e.g., the results of a serological test) |^2^+| (categorical response, e.g., occult blood positivity)
4 Num2 15 NM O A number or null depending on the measurement.
Table 112: SN – Structured Numeric Component
9.1.7.40 SRT – sort order Specifies those parameters by which the response will be sorted and by what method. The maximum length is 15.
Seq Component Len Type Opt Table Comment Name
1 Sort by Field 12 ST R Identifies the field by which the response will be sorted. In a tabular response, this will be the column name to sort by. In the segment pattern and the display response, this will be the segment field name to sort by.
2 Sequencing 2 ID O Table 114 Identifies how the field or parameter will be sorted and, if sorted, whether the sort will be case sensitive (the default) or not.
Table 113: SRT – Sort Order Components
Value Description
A Ascending
AN Ascending, case insensitive
D Descending
DN Descending, case insensitive
N None
Table 114: HL7 Table 0397 – Sequencing
Electronic Pharmaceutical Messaging Standard v1 November 2008 122
9.1.7.41 ST – string data
Seq Component Len Type Opt Table Comment Name
String Data 199 String data is left justified with trailing blanks optional. Any displayable (printable) ACSII characters (hexadecimal values between 20 and 7E inclusive, or ASCII decimal values between 32 and 126), except the defined escape characters and defined delimiter characters.
Table 115: ST – String Data Component NOTE: The ST data type is intended for short strings (e.g. less than 200 characters). For longer strings, the TX or FT data types should be used.
9.1.7.42 TQ –timing quantity Describes when a service should be performed and how frequently. The TQ data type is retained for backward compatibility only as of v2.5. Refer to TQ1 and TQ2 segments.
Component Seq Name Len Type Opt Table Notes
1 Quantity 267 CQ O Specifies the quantity of the service that should be provided at each service interval. The default value is 1. When units are required, they can be added, specified by a subcomponent delimiter.
2 Interval 206 RI O Determines the interval between repeated services. The default is one time only. NOTE: Data type RI replaces CM
3 Duration 6 ST O Table 117 Indicates how long the service should continue after it is started. The default is INDEF.
4 Start Date/Time 26 TS O May be specified by the orderer, in which case it indicates the earliest date/time at which the services should be started, if not specified elsewhere.
5 End Date/Time 26 TS O When filled in by the requester of the service, this component should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time.
6 Priority 6 ST O Table 118 This component describes the urgency of the request. The default for Priority is R.
Electronic Pharmaceutical Messaging Standard v1 November 2008 123
Component Seq Name Len Type Opt Table Notes
7 Condition 199 ST O A free text component that describes the conditions under which the drug is to be given. The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given.
8 Text 200 TX O Free text field for an optional full text version of the instruction
9 Conjunction 1 ID O Table 264 This non-null component indicates that a second timing specification is to follow using the repeat delimiter
10 Order 110 OSD O There are many situations, such as the Sequencing creation of an order for a group of intravenous (IV) solutions, where the sequence of the individual intravenous solutions (each a service in itself) needs to be specified. NOTE: Data type OSD replaces CM
11 Occurrence 483 CE O This component contains the duration for Duration a single performance of a service
12 Total 4 NM O This component contains the total number Occurrences of occurrences of a service that should result from this order. It is optional within TQ and does not repeat. If both the end date/time and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.
Table 116: TQ – Timing/Quantity Components
Value Description Comment
S
M
H
D
W
L
X
Electronic Pharmaceutical Messaging Standard v1 November 2008 124
Value Description Comment
T
INDEF do indefinitely The default code
Table 117: TQ3 - Duration Sub-Component
Value Description Comment
S Stat With highest priority
A ASAP Fill after S orders
R Routine Default
P Preop
C Callback
A request implying that it is critical to come as close as possible to the T Timing Critical requested time. Refer Table 119.
PRN As needed
Table 118: TQ6 – Priority Sub Component
Value Description
TS
TM
TH
TD
TW
TL
Table 119: TQ6 – Timing Critical Sub Component Table
9.1.7.43 TS – time stamp Contains the exact time of an event, including the date and time.
Component Seq Name Len Type Opt Table Notes
1 Time 24 DTM R The point in time
2 Degree of 1 ID B Table 121 Indicates the degree of precision of the Precision time stamp. Retained only for purposes of backward compatibility as of v 2.3.
Table 120: TS – Time Stamp Components
Electronic Pharmaceutical Messaging Standard v1 November 2008 125
Value Description Comment
Y Year Retained for backward compatibility only
L Month Retained for backward compatibility only
D Day Retained for backward compatibility only
H Hour Retained for backward compatibility only
M Minute Retained for backward compatibility only
S Second Retained for backward compatibility only
Table 121: HL7 Table 0529 – Precision
9.1.7.44 TX – text data Since TX data is intended for display purposes, the repeat delimiter, when used with a TX data field, implies a series of repeating lines to be displayed on a printer or terminal. Therefore, the repeat delimiters are regarded as paragraph terminators or hard carriage returns.
A receiving system would word-wrap the text between repeat delimiters in order to fit it into an arbitrarily sized display window but start any line beginning with a repeat delimiter on a new line.
Component Seq Name Len Type Opt Table Notes String data meant for user display (on a Text Data Up to terminal or printer). Since TX data is intended 64k for display purposes, it may contain certain escape character sequences designed to control the display. Leading spaces should be included. Trailing spaces should be removed. Table 122: TX – Text Data Component
9.1.7.45 VID – version identifier
Component Seq Name Len Type Opt Table Notes
1 Version ID 5 ID O Used to identify the HL7 version. This implementation is based on HL7 v2.5. Use “2.5” in this field.
2 Internationalisation 483 CE O Table B 5 Used to identify the international affiliated Code country code. This implementation is for New Zealand; use “NZL”.
3 International 483 CE O This specification is local version “1.0” Version ID
Table 123: VID – Version Identifier Components
Electronic Pharmaceutical Messaging Standard v1 November 2008 126
9.1.7.46 VR – value range This data type contains the lower bound value and upper bound values that constitute a range. Either or both components may be populated. The Maximum Length is 13.
Component Seq Name Len Type Opt Table Notes
1 First Data Code 6 ST O Specifies the lower bound value.
2 Last data Code 6 ST O Specifies the upper bound value
Table 124: VR – Value Range Components NOTE: Replaces the CM data type used in HL7 Chapter 5.10.5.3.11 QRD-11 as of v 2.5.
The VR differs from the Numeric Range (NR) data type only in that the values are not restricted to numbers. If the range is not numeric, the set must be orderable in some intuitive way such as alpha or the order must be defined in the field where the data type is used.
9.1.7.47 XAD – extended address The field identifies the components of a postal address. The maximum length of this field is increased to 632 as of v2.5.
Seq Component Name Len Type Opt Table Notes
1 Street address 184 SAD O Address. All address information up to the suburb fits in here.
2 Other Designation 120 ST O Suburb
3 City 50 ST O Specifies the city, district or place where the addressee is located
4 State or Province 50 ST O Specifies the state or province where the addressee is located
5 Zip or Postal Code 12 ST O Specifies the zip or postal code where the addressee is located
6 Country 3 ID O Table B 5 Country. If left blank, the country is assumed to be New Zealand. Otherwise use values from table in Appendix B.
7 Address type 3 ID O Table 60 Specifies the kind or type of address
8 Other geographical 50 ST O GeoCode X:Y coordinates. Both are designation entered here, separated by a colon.
9 County/Parish Code 20 IS X
10 Census Tract 20 IS O New Zealand domicile code
11 Address 1 ID O Different Electronic Pharmaceutical Messaging Standard v1 November 2008 127 Seq Component Name Len Type Opt Table Notes representation> component. NOTE: This component is represented in an alphabetic character set 12 Address Validity 53 DR X Range 13 Effective Date 26 TS O The first date, if known, on which the address is valid and active 14 Expiration Date 26 TS O The last date, if known, on which the address is valid and active Table 125: XAD – Extended Address Components Variance to HL7: The extended Street Address type in the first component is not used in this implementation. New Zealand use should follow HPI. 9.1.7.48 XCN extended composite ID number and name for persons This field is usually reserved for the identification of health care providers. The maximum length of this field is increased to 3002 as of v2.5. XCN replaces CN data type as of v2.3. Component Seq Name Len Type Opt Table Notes 1 ID Number 15 ST O This string refers to the coded ID according to a user-defined table, defined by the 9th component. If the first component is present, either the source table or the assigning authority must be valued. For example, CPN, MCNZ, NZNC or APC number. 2 Family Name 194 FN O This component allows full specification of the surname of a person 3 Given Name 30 ST O First name 4 Middle Initial or 30 ST O Second and Further Given Names or Name Initials. Multiple middle names may be included by separating them with spaces. 5 Suffix 20 ST O Used to specify a name suffix (e.g. Jr. or III). 6 Prefix 20 ST O Used to specify a name prefix (e.g. Dr.). 7 Degree 5 IS B 360 Retained for backward compatibility only as of v 2.5 8 Source Table 4 IS X 9 Assigning 227 HD O 363 A code corresponding to the type of Authority identifier. In some cases, this code may be used as a qualifier to the Electronic Pharmaceutical Messaging Standard v1 November 2008 128 Component Seq Name Len Type Opt Table Notes 10 Name Type Code 1 ID X 11 Identifier Check 1 ST X Digit 12 Check Digit 3 ID X Scheme 13 Identifier Type 5 ID X Code 14 Assigning Facility 227 HD X 15 Name 1 ID X Representation Code 16 Name Context 483 CE X 17 Name Validity 53 DR X Range 18 Name Assembly 1 ID X Order 19 Effective Date 26 TS O The first date, if known, on which the address is valid and active 20 Expiration Date 26 TS O The last date, if known, on which the address is valid and active 21 Professional Suffix 199 ST O Used to specify an abbreviation, or a string of abbreviations denoting qualifications that support the person’s profession, (e.g. licenses, certificates, degrees, affiliations with professional societies, etc). The Professional Suffix normally follows the Family Name when the Person Name is used for display purposes. Please note that this component is an unformatted string and is used for display purposes only. 22 Assigning 705 CWE O The geo-political body that assigned the Jurisdiction identifier in component 1 23 Assigning Agency 705 CWE O The agency or department that assigned or Department the identifier in component 1 Table 126: XCN – Extended Composite ID Number and Name for Persons Components 9.1.7.49 XON – extended composite name and identification number for organisations This data type is used in fields (e.g. PV2-23) to specify the name and ID number of an organisation. The maximum length is increased to 567, as of v2.5. Electronic Pharmaceutical Messaging Standard v1 November 2008 129 Seq Component Len Type Opt Table Notes Name 1 Organisation 50 ST O The name of the specified organisation Name 2 Organisation 20 IS O Table 128 A code that represents the type of name, Name Type Code i.e. legal name, display name 3 ID number 4 NM B This component has been retained for backward compatibility only as of v 2.5. Use component 10 Organisation Identifier that accommodates alphanumeric identifiers. 4 Check digit 1 NM O This is not an add-on produced by the message processor. It is part of the identifying number used in the sending application. If the sending application does not include a self-generated check digit in the identifying number, this component should be valued “null”. 5 Check Digit 3 ID O Table 73 The code identifying the check digit Scheme scheme employed 6 Assigning 227 HD O Table 129 The Assigning Authority is a unique Authority identifier of the system (or organisation or agency or department) that creates the data. Assigning authorities are unique across a given HL7 implementation. 7 Identifier Type 5 ID O Table B 9 A code corresponding to the type of Code identifier. In some cases, this code may be used as a qualifier to the Assigning Authority component. 8 Assigning Facility 227 HD O The place or location identifier where the ID identifier was first assigned to the person. This component is not an inherent part of the identifier but rather part of the history of the identifier. As part of this data type, its existence is a convenience for certain intercommunicating systems. 9 Name 1 ID O Table 130 Different Name/address types and Representation representations of the same Code Name/address should be described by repeating of this field, with different values of the Name/address type and/or Name/address representation component. 10 Organisation 20 ST O This component contains the sequence of Identifier characters (the code) that uniquely identifies the item being referenced by XON-1 Organisation Name. NOTE: The check digit and code identifying check digit scheme are null if Organisation Identifier is alphanumeric Table 127: XON – Extended Composite Name and ID Number for Organisations Components Electronic Pharmaceutical Messaging Standard v1 November 2008 130 Value Description A Alias Name L Legal Name D Display Name SL Stock Exchange Listing Name Table 128: HL7 User Defined Table 0204 – Organisational Name Type Value Description AUSDVA Australia – Dept. of Veterans Affairs AUSHIC Australia – Health Insurance Commission NZLACC New Zealand – Accident Compensation Commission NZLMOH New Zealand – Ministry of Health LOCAL Local to Sender Table 129: HL7 User Defined Table 0363 – Assigning Authority Value Description I Ideographic (i.e. Kanji) A Alphabetic (i.e., Default or some single-byte) P Phonetic (i.e., ASCII, Katakana, Hiragana, etc.) Table 130: HL7 Table 0465 – Name/Address Representation 9.1.7.50 XPN - extended person name The maximum length of this field is increased to 1103 as of v2.5. Seq Component Len Type Opt Table Notes Name 1 Family Name 194 FN O This component allows full specification of the surname of a person 2 Given Name 30 ST O First name 3 Middle name or 30 ST O Second and Further Given Names or Initials Initials. Multiple middle names may be included by separating them with spaces. 4 Suffix 20 ST O Used to specify a name suffix (e.g. Jr. or III) 5 Prefix 20 ST O Used to specify a name prefix (e.g. Dr.) 6 Degree 6 IS B Retained for backward compatibility only as of v 2.5 Electronic Pharmaceutical Messaging Standard v1 November 2008 131 Seq Component Len Type Opt Table Notes Name 7 Name Type Code 1 ID O Table 132 A code that represents the type of name 8 Name 1 ID O Table 130 Different Name/address types and Representation representations of the same Name/address Code should be described by repeating of this field, with different values of the Name/address type and/or Name/address representation component. 9 Name Context 483 CE O This component is used to designate the context in which a name is used. 10 Name Validity 53 DR B Retained for backward compatibility only as Range of v 2.5 11 Name Assembly 1 ID O Table 133 A code that represents the preferred Order display order of the components of this person name 12 Effective Date 26 TS O The first date, if known, on which the address is valid and active 13 Expiration Date 26 TS O The last date, if known, on which the address is valid and active 14 Professional 199 ST O Used to specify an abbreviation, or a string Suffix of abbreviations denoting qualifications that support the person’s profession, (e.g. licenses, certificates, degrees, affiliations with professional societies, etc). The Professional Suffix normally follows the Family Name when the Person Name is used for display purposes. Please note that this component is an unformatted string and is used for display purposes only. Table 131: XPN – Extended Person Name Component Value Description A Alias Name B Name at Birth C Adopted Name D Display Name I Licensing Name L Legal Name M Maiden Name N Nickname, ”Call me”, Name/Street Name P Name of Partner/Spouse (retained for backward Electronic Pharmaceutical Messaging Standard v1 November 2008 132 Value Description compatibility only) R Registered Name (animals only) S Coded Pseudo-Name to ensure anonymity T Indigenous/Tribal/Community Name U Unspecified Table 132: HL7 Table 0200 – Name Type Code Value Description G Prefix Given Middle Family Suffix F Prefix Family Middle Given Suffix Table 133: HL7 Table 0444 – Name Assembly Order 9.1.7.51 XTN extended telecommunications number The maximum length of this field is increased to 850 as of v2.5. Seq Component Name Len Type Opt Table Notes 1 Telephone Number 199 ST B Deprecated as of v2.3 2 Telecommunication 3 ID O Table 135 A code that represents a specific use Use Code of a telecommunication number 3 Telecommunication 8 ID O Table 136 A code that represents the type of Equipment Type telecommunication equipment 4 Email Address 199 ST O The presence of an email address is specified by the addition of the value NET to the Phone Use Code table, and the type of Internet address is specified with the value Internet to the Phone Equipment Type table. When used for an Internet address, the first component of the XTN data type will be null. If the @-sign is being used as a subcomponent delimiter, the HL7 subcomponent escape sequence may be used when encoding an Internet address. 5 Country Code 3 NM O Table B 5 6 Area Code 5 NM O 7 Number 9 NM O 8 Extension 5 NM O 9 Any Text 199 ST O Contains comments with respect to Electronic Pharmaceutical Messaging Standard v1 November 2008 133 Seq Component Name Len Type Opt Table Notes the telephone number. Example: |^^^^^^^^Do not use after 5pm 10 Extension Prefix 4 ST O The characters established within a company’s internal telephone system network used as a prefix to the Extension component for internal dialling. Note that the use of Extension Prefix requires that the Extension component be valued and that digits, as well as special characters (e.g. *, #) may be used. 11 Speed Dial Number 8 ST O The characters established within a company’s internal telephone system used in place of the (external) telephone number to facilitate calling because its length is shorter than that of the telephone number. Note that digits, as well as special characters (e.g. *, #) may be used. 12 Unformatted 199 ST C An expression of the telephone Telephone Number number as an unparsible string Table 134: XTN – Extended Telecommunications Number Component Examples of the use of telecommunication equipment types: (a) Home phone number: ...|^PRN^PH^^64^9^3456789|... (b) Email address: ...|^NET^Internet^[email protected]|... (c) Work phone number. Note use of text field to qualify number: ...|^WPN^PH^^64^9^3456789^320^Afternoons only|... (d) work fax number: ...|^WPN^FX^^64^9^3456059|... 9.1.7.51.1 Telecommunication use codes Use one of the values from the table below. The most common values used are provided here: Value Description PRN Primary Residence Number ORN Other Residence Number WPN Work Phone Number NET Network Address (use for email addresses) Table 135: HL7 Table 0201 – Telecommunication Use Codes NOTE: This table is not comprehensive. Electronic Pharmaceutical Messaging Standard v1 November 2008 134 9.1.7.51.2 Telecommunication equipment types Use one of the following values from the table below. The most common values used are provided here. Value Description PH Phone FX Fax CP Cellular Phone Internet Internet (use for email addresses or domain names) Table 136: HL7 Table 0202 – Telecommunication Equipment Types NOTE: This table is not comprehensive. Electronic Pharmaceutical Messaging Standard v1 November 2008 135 9.2 AL1 – Patient Allergy Information Segment This segment contains details of patient allergies. The table below shows the AL1 attributes: Seq Element Name Len Type Opt Rpt Table 1 Set ID – AL1 4 SI R 2 Allergen Type Code 250 CE O Table 138 3 Allergen Code/ Mnemonic/ Description 250 CE R 4 Allergy Severity Code 250 CE O Table 139 5 Allergy Reaction Code 15 ST O Y 6 Identification Date 8 DT X Table 137: HL7 Attribute Table AL1 – Patient Allergy Information 9.2.1 AL1-1 set ID – AL1 This field identifies the repeat of the AL1 as it pertains to a separate patient. The first AL1 segment will have a Set ID of “1”. This will increase for each subsequent allergy reported. 9.2.2 AL1-2 allergen type code This field indicates a general allergy category (drug, food, pollen, etc). Refer to the table below for allergen types: Value Description DA Drug allergy FA Food allergy MA Miscellaneous allergy MC Miscellaneous contraindication EA Environmental Allergy AA Animal Allergy PA Plant Allergy LA Pollen Allergy Table 138: HL7 User-Defined Table 0127 – Allergen Type 9.2.3 AL1-3 Allergen Code / Mnemonic / Description This field uniquely identifies a particular allergen. This element may conform to some external, standard coding system (that shall be identified), or it may conform to local, largely textual or mnemonic descriptions. Electronic Pharmaceutical Messaging Standard v1 November 2008 136 9.2.4 AL1-4 Allergy Severity Code This field indicates the general severity of the allergy. This field may contain one of the following values. Refer to the table below for allowed values: Value Description SV Severe reaction MO Moderate reaction MI Mild reaction U Unknown Table 139: HL7 User Defined Table 0128 – Allergy Severity 9.2.5 AL1-5 Allergy Reaction Code This field contains a short textual description of the reaction to the allergy. Multiple reactions should be sent in repeats, e.g. convulsions, rash, etc. 9.3 BLG – Billing Segment The BLG segment is used to provide billing information, on the ordered service, to the filling application. Seq Element Name Len Type Opt Rpt Table 1 When to Charge 40 CCD O Table 63 2 Charge Type 50 ID O Table 141 3 Account ID 100 CX O 4 Charge Type Reason 60 CWE O Table 142 Table 140: HL7 Attribute Table BLG – Billing Segment 9.3.1 BLG-1 When to Charge This field specifies when to charge for the ordered service. 9.3.2 BLG-2 Charge Type This field identifies someone or something other than the patient to be billed for this service. It is used in conjunction with BLG-3 Account ID. Value Description CO Contract CR Credit DP Department GR Grant Electronic Pharmaceutical Messaging Standard v1 November 2008 137 Value Description NC No Charge PC Professional RS Research Table 141: HL7 Table 0122 – Charge Type 9.3.3 BLG-3 Account ID This field identifies the account to be billed. It is used in conjunction with BLG-2 Charge Type. The HPI organisation code should be used. 9.3.4 BLG-4 Charge Type Reason This field explains the choice of, and provides the clinical rationale for, the selected charge type identified in BLG-2. Value Description 01 Allergy 02 Intolerance 03 Treatment Failure 04 Patient Request 05 No Exception Table 142: HL7 User Defined Table 0475 – Charge Type Reason 9.4 CTI – Clinical Trial Identification Segment This segment is an optional segment that contains information to identify the clinical trial, phase and time point with which an order or result is associated. Refer to the table below for CTI attributes: Seq Element Name Len Opt Rpt 1 Sponsor Study ID 60 EI R 2 Study Phase Identifier 250 CE C 3 Study Scheduled Time Point 250 CE O Table 143: HL7 Attribute Table CTI – Clinical Trial Identification 9.4.1 CTI-1 Sponsor Study ID This field contains the universal identifier for the clinical test. 9.4.2 CTI-2 Study Phase Identifier This field identifies the phase of the study that a patient has entered. This field is used when a study has Electronic Pharmaceutical Messaging Standard v1 November 2008 138 different evaluation intervals within it. 9.4.3 CTI-3 Study Scheduled Time Point This field identifies a time point in the clinical trial phase. CTI-2 shall be valued if this field is valued. 9.5 DSC – Continuation Pointer Segment The DSC segment is used in the continuation protocol. Seq Element Name Len Type Opt Rpt Table 1 Continuation Pointer 180 ST O 2 Continuation Style 1 ID O Table 145 Table 144: HL7 Attribute Table DSC – Continuation Pointer 9.5.1 DSC-1 Continuation Pointer This field contains the continuation pointer. In an initial query, this field is not present. If the responder returns a value of “null” or “not present”, then there is no more data to fulfil any future continuation requests. NOTE: For use with continuations of unsolicited messages. Continuation protocols work with both display- and record-oriented messages. 9.5.2 DSC-2 Continuation Style Indicates whether this is a fragmented message or part of an interactive continuation message. Refer to the table below for allowed values: Value Description F Fragmentation I Interactive Continuation Table 145: HL7 Table 0398 – Continuation Style Code Electronic Pharmaceutical Messaging Standard v1 November 2008 139 9.6 ERR – Error Segment The ERR segment is used to add error comments to acknowledgment messages. Seq Element Name Len Type Opt Rpt Table 1 Error Code and Location 493 ELD B Y 2 Error Location 18 ERL O Y 3 HL7 Error Code 705 CWE R Table 147 4 Severity 2 ID R Table 148 5 Application Error Code 705 CWE O 6 Application Error Parameter 80 ST O Y/10 7 Diagnostic Information 2048 TX O 8 User Message 250 TX O 9 Inform Person Indicator 20 IS O Y Table 149 10 Override Type 705 CWE O Table 150 11 Override Reason Code 705 CWE O Y 12 Help Desk Contact Point 652 XTN O Y Table 146: HL7 Attribute Table ERR – Error 9.6.1 ERR-1 Error Code and Location This field identifies an erroneous segment in another message. Retained for backward compatibility only as of v 2.5; refer to ERR-2 and ERR-3 instead. 9.6.2 ERR-2 Error Location Identifies the location in a message related to the identified error, warning or message. If multiple repetitions are present, the error results from the values in a combination of places. 9.6.3 ERR-3 HL7 Error Code Identifies the HL7 (communications) error code. Error Condition Code Error Condition Text Description/Comment Success 0 Message accepted Success. Optional, as the acknowledgement code AA conveys success. Used for systems that must always return a status code. Errors Electronic Pharmaceutical Messaging Standard v1 November 2008 140 Error Condition Code Error Condition Text Description/Comment 100 Segment sequence error The message segments were not in the proper order, or required segments are missing 101 Required field missing A required field is missing from a segment 102 Data type error The field contained data of the wrong data type 103 Table value not found A field of data type ID or IS was compared against the corresponding table, and no match was found Rejection 200 Unsupported message The Message Type is not supported type 201 Unsupported event code The event code is not supported 202 Unsupported processing The processing ID is not supported ID 203 Unsupported version ID The version ID is not supported 204 Unknown key identifier The ID of the patient, order, etc was not found. Used for transactions other than additions, e.g. transfer of a non-existent patient 205 Duplicate key identifier The ID of the patient, order, etc already exists. Used in response to addition transactions (Admit, New Order, etc) 206 Application record The transaction could not be performed at the locked application storage level, e.g. database locked 207 Application internal error A catchall for internal errors not explicitly covered by other codes Table 147: HL7 Table 0357 – Message Error Condition Codes 9.6.4 ERR-4 Severity Identifies the severity of an application error. Knowing if something is Error, Warning or Information is intrinsic to how an application handles the content. If ERR-3 has a value of "0", ERR-4 will have a value of "I". Value Description Comment W Warning Transaction successful, but there may be issues I Information Transaction was successful but includes information e.g., inform patient E Error Transaction was unsuccessful Table 148: HL7 Table 0516 – Error Severity 9.6.5 ERR-5 Application Error Code 5 Application-specific code identifying the specific error that occurred. Electronic Pharmaceutical Messaging Standard v1 November 2008 141 9.6.6 ERR-6 Application Error Parameter Additional information to be used, together with the Application Error Code, to understand a particular error condition/warning/etc. This field can repeat to allow for up to 10 parameters. Example: if the application error code specified in ERR-5 corresponded with the English message "The patient has a remaining deductible of {0, number, currency} for the period ending {1, date, medium}", and the first two repetitions of ERR-6 were "250" and "20021231", then a receiving application would display the message as "The patient has a remaining deductible of $250.00 for the period ending Dec 31, 2002". 9.6.7 ERR-7 Diagnostic Information Information that may be used by help desk or other support personnel to diagnose a problem. 9.6.8 ERR-8 User Message The text message to be displayed to the application user. This differs from the actual error code and may provide more diagnostic information. 9.6.9 ERR-9 Inform Person Indicator A code to indicate who (if anyone) should be informed of the error. This field may also be used to indicate that a particular person should NOT be informed of the error (e.g. Do NOT inform patient). Value Description PAT Inform patient NPAT Do NOT inform patient USR Inform User HD Inform help desk Table 149: HL7 User Defined Table 0517 – Inform Person Code 9.6.10 ERR-10 Override Type Identifies what type of override can be used to override the specific error identified. Value Description Comment EXTN Extension Override Identifies an override where a service is being performed for longer than the ordered period of time INLV Interval Override Identifies an override where a repetition of service is being performed sooner than the ordered frequency EQV Equivalence Override Identifies an override where a service is being performed against an order that the system does not recognise as equivalent to the ordered service Table 150: HL7 User Defined Table 0518 – Override Type Electronic Pharmaceutical Messaging Standard v1 November 2008 142 9.6.11 ERR-11 Override Reason Code Provides a list of potential override codes that can be used to override enforcement of the application rule that generated the error. 9.6.12 ERR-12 Help Desk Contact Point Lists phone, email, fax and other relevant numbers for helpdesk support related to the specified error. 9.7 IN1 – Insurance Segment The IN1 segment contains insurance policy coverage information necessary to produce properly pro-rata patient and insurance bills. The allowed values are in the table below: Seq Element Name Len Type Opt Rpt Table No 1 Set ID – IN1 4 SI R 2 Insurance Plan ID 250 CE R Table 152 3 Insurance Company ID 250 CX R Y Table 153 4 Insurance Company Name 250 XON O Y 5 Insurance Company Address 250 XAD O Y 6 Insurance Co Contact Person 250 XPN O Y 7 Insurance Co Phone Number 250 XTN O Y 8 Group Number 12 ST X 9 Group Name 250 XON X Y 10 Insured’s Group Emp ID 250 CX O Y (Exemption or Subsidy card) 11 Insured’s Group Emp Name 250 XON X Y 12 Plan Effective Date 8 DT X 13 Plan or Card Expiration Date 8 DT O 14 Authorisation Information 239 AUI O Table 154 15 Plan Type 3 IS X 16 Name Of Insured 250 XPN O Y 17 Insured’s Relationship To Patient 250 CE O Table 155 18 Insured’s Date Of Birth 26 TS X 19 Insured’s Address 250 XAD X Y 20 Assignment Of Benefits 2 IS X 21 Coordination Of Benefits 2 IS X Electronic Pharmaceutical Messaging Standard v1 November 2008 143 Seq Element Name Len Type Opt Rpt Table No 22 Coordination Of Benefits, Priority 2 ST X 23 Notice Of Admission Flag 1 ID X 24 Notice Of Admission Date 8 DT X 25 Report Of Eligibility Flag 1 ID X 26 Report Of Eligibility Date 8 DT X 27 Release Information Code 2 IS X 28 Pre-Admit Cert (PAC) 15 ST X 29 Verification Date/Time 26 TS X 30 Verification By 250 XCN X Y 31 Type Of Agreement Code 2 SI X 32 Billing Status 2 IS X 33 Lifetime Reserve Days 4 NM X 34 Delay Before L.R. Day 4 NM X 35 Company Plan Code 8 IS X 36 Policy Number 15 ST O 37 Policy Deductible 12 CP X 38 Policy Limit - Amount 12 CP X 39 Policy Limit - Days 4 NM X 40 Room Rate - Semi-Private 12 CP X 41 Room Rate - Private 12 CP X 42 Insured’s Employment Status 250 CE X 43 Insured’s Administrative Sex 1 IS X 44 Insured’s Employer’s Address 250 XAD X Y 45 Verification Status 2 ST X 46 Prior Insurance Plan ID 8 IS X 47 Coverage Type 3 IS X 48 Handicap 2 IS X Y 49 Insured’s ID Number 250 CX X 50 Signature Code 1 IS O Table 156 Electronic Pharmaceutical Messaging Standard v1 November 2008 144 Seq Element Name Len Type Opt Rpt Table No 51 Signature Code Date 8 DT O 52 Insured’s Birth Place 250 ST O 53 VIP Indicator 2 IS X Table 151: HL7 Attribute Table IN1 – Insurance 9.7.1 IN1-1 - Set ID This field contains the number that identifies this transaction. For the first occurrence the sequence number shall be “1”, for the second occurrence it shall be “2”, etc. 9.7.2 IN1-2 - Insurance Plan ID This field contains a unique identifier for the insurance plan. In the case of government organisations this will include funder codes such as High User Cards. Refer to the table below for valid values Value Description HUHC High Use Health Card CSC Community Service Card PSC Prescription Sub Card Table 152: HL7 User Defined Table 072 – Insurance Plan ID NOTE: These are the codes at time of publication and may be extended in the future. 9.7.3 IN1-3 Insurance Company ID This field contains unique identifiers for the insurance company. In New Zealand, this is extended to include a number of government agencies. The assigning authority and identifier type code are strongly recommended for all CX data types. These are the codes at time of publication and may be extended in the future. Value Description MoH Ministry of Health ACC Accident Compensation Corporation Table 153: 99NZFID – Funder ID 9.7.4 IN1-4 Insurance Company Name This field contains the name of the insurance company. Multiple names for the same insurance company may be sent in this field. The legal name is assumed to be in the first repetition. When the legal name is not sent, a repeat delimiter must be sent first for the first repetition. In the case of government agencies, this will be the name contained in Table 153. 9.7.5 IN1-5 Insurance Company Address This field contains the address of the insurance company. Multiple addresses for the same insurance Electronic Pharmaceutical Messaging Standard v1 November 2008 145 company may be sent in this field. The mailing address is assumed to be in the first repetition. When the mailing address is not sent, a repeat delimiter must be sent first for the first repetition. 9.7.6 IN1-6 Insurance Company Contact Person This field contains the name of the person who should be contacted at the insurance company. Multiple names for the same contact person may be sent in this field. The legal name is assumed to be in the first repetition. When the legal name is not sent, a repeat delimiter must be sent first for the first repetition. 9.7.7 IN1-7 Insurance Company Phone Number This field contains the phone number of the insurance company. Multiple phone numbers for the same insurance company may be sent in this field. The primary phone number is assumed to be in the first repetition. When the primary phone number is not sent, a repeat delimiter must be sent first for the first repetition. 9.7.8 IN1-10 Insured’s Group Employer ID (Exemption or Subsidy Card) This field holds the group employer ID for the insured’s insurance. The assigning authority and identifier type code are strongly recommended for all CX data types. In the case of government agencies, this is the exemption or subsidy card number. Variance to HL7: The length of the first component of this field is constrained by HL7 to 15. This restraint has been removed in New Zealand, providing that the total length of the field is still complied with. 9.7.9 IN1-13 Plan or Card Expiration Date This field indicates the last date of eligibility that the plan will cover or be responsible for. 9.7.10 IN1-14 Authorisation Information Based on the type of insurance, some coverage plans require that an authorisation number or code be obtained prior to all non-emergency admissions, and within 48 hours of an emergency admission. Insurance billing would not be permitted without this number. The date and source of authorisation are the components of this field. Sub Component Type Notes Table 154: IN1-16 Authorisation Information Sub Components 9.7.11 IN1-16 Name of Insured This field contains the name of the insured person. The insured is the person who has an agreement with the insurance company to provide health care services to persons covered by the insurance policy. Multiple names for the same insured person may be sent in this field. The legal name is assumed to be in the first repetition. When the legal name is not sent, a repeat delimiter must be sent first for the first repetition. Electronic Pharmaceutical Messaging Standard v1 November 2008 146 9.7.12 IN1-17 Insured’s Relationship to Patient This field indicates the insured’s relationship to the patient. Value Description 01 Mother 02 Father 03 Sister 04 Brother 05 Son 06 Daughter 07 Uncle 08 Aunt 09 Nephew 10 Niece 11 Cousin 12 Grandfather 13 Grandmother 14 Employer 15 Other 16 Spouse 91 Foster Father 92 Foster Mother 93 Stepfather 94 Stepmother 99 Self Table 155: User Defined Table 99NZREL – Relationship Variance to HL7: HL7 uses values from HL7 User Defined Table 0063 – Relationship in this field. 9.7.13 IN1-36 Policy Number This field contains the individual policy number of the insured to uniquely identify this patient’s plan. 9.7.14 IN1-50 Signature Code This field contains the code to indicate how the patient/subscriber authorisation signature was obtained and how it is being retained by the provider. Electronic Pharmaceutical Messaging Standard v1 November 2008 147 Value Description C Signed CMS-1500 claim form on file, e.g. authorisation for release of any medical or other information necessary to process this claim and assignment of benefits S Signed authorisation for release of any medical or other information necessary to process this claim on file M Signed authorisation for assignment of benefits on file P Signature generated by provider because the patient was not physically present for services Table 156: HL7 User Defined Table 0535 – Signature Code 9.7.15 IN1-51 Signature Code Date The date the patient/subscriber authorisation signature was obtained. 9.7.16 IN1-52 Insured’s Birth Place This field contains the description of the insured’s birth place, for example “St. Francis Community Hospital of Lower South Side”. The actual address is reported in IN1-19 – Insured’s Address, with an identifier of “N”. 9.8 MSA – Message Acknowledgement Segment The MSA segment contains information sent in acknowledging another message. Refer to the table below for MSA attributes. Example of MSA message: MSA|AR|12367|Application reject – Required field missing ||| Seq Element Name Len Type Opt Rpt Table 1 Acknowledgement Code 2 ID R Table 158 2 Message Control ID 20 ST R 3 Text Message 80 ST B 4 Expected Sequence Number 15 NM X 5 Delayed Acknowledgement Type W 6 Error Condition 250 CE B Table 147 Table 157: HL7 Attribute Table MSA – Message Acknowledgement NOTE: The ERR segment is used to return user defined error codes to further specify AR or AE type acknowledgements. 9.8.1 MSA-1 Acknowledgement Code This field contains the acknowledgement code. The most common values used are provided in the table below: Electronic Pharmaceutical Messaging Standard v1 November 2008 148 Value Description AA Application Accept AE Application Error AR Application Reject Table 158: HL7 Table 0008 – Acknowledgement code NOTE: This list is not comprehensive. 9.8.2 MSA-2 Message Control ID This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended. 9.8.3 MSA-3 Text Message This field further describes an error condition. The MSA-3 was deprecated as of v2.4. Refer to the ERR segment, which allows for richer descriptions of the erroneous conditions. 9.8.4 MSA-5 Delayed Acknowledgment Type The MSA-5 was deprecated as of v2.2 and the detail was withdrawn and removed from the Standard as of v2.5. 9.8.5 MSA-6 Error Condition This field allows the acknowledging system to use a user-defined error code to further specify AR or AE type acknowledgments. The MSA-6 was deprecated as of v2.4. Refer to the ERR segment. 9.9 MSH – Message Header Segment The MSH Segment contains the information about the message including sender, recipient and some syntactical information. Refer to the table below for MSH attributes. MSH Example: MSH|^~\&|PLACER_APPLICATION|PLACER_FACILITY|FILLER_APPLICATION|FILLER_FACILITY|1 99511200950||OMP^O09|199511200950.001|P|2.5 Seq Element Name Len Type Opt Rpt Table 1 Field Separator 1 ST R 2 Encoding Characters 4 ST R 3 Sending Application 227 HD O 4 Sending Facility 227 HD R 5 Receiving Application 227 HD O 6 Receiving Facility 227 HD R 7 Date/Time Of Message 26 TS R Electronic Pharmaceutical Messaging Standard v1 November 2008 149 Seq Element Name Len Type Opt Rpt Table 8 Security 40 ST O 9 Message Type 15 MSG R Table 160 10 Message Control ID 20 ST R 11 Processing ID 3 PT R Table 105 12 Version ID 60 VID R Table 123 13 Sequence Number 15 NM X 14 Continuation Pointer 180 ST X 15 Accept Acknowledgment Type 2 ID X 16 Application Acknowledgment Type 2 ID X 17 Country Code 3 ID X 18 Character Set 16 ID O Y Table 161 19 Principal Language of Message 250 CE X 20 Alternate Character Set Handling 20 ID X Scheme 21 Conformance Statement ID (Message 10 ID X Y Profile Identifier) Table 159: HL7 Attribute Table MSH – Messaging Header 9.9.1 MSH-1 Field Separator The field separator character will be “|”. 9.9.2 MSH-2 Encoding Characters This field contains the separator characters for component, sub component, repeat and the user defined character. It is strongly recommended that this field contain “^~\&”. 9.9.3 MSH-3 Sending Application This field identifies the application responsible for generating this message. 9.9.4 MSH-4 Sending Facility This field should uniquely identify the facility that sends the message. The complete facility name should be used to avoid any ambiguity in identification. Variance to HL7: This field is optional in HL7. 9.9.5 MSH-5 Receiving Application This field identifies the receiving application. Electronic Pharmaceutical Messaging Standard v1 November 2008 150 9.9.6 MSH-6 Receiving Facility This field should uniquely identify the facility that will receive the message. The complete facility name should be used to avoid any ambiguity in identification. Variance to HL7: This field is optional in HL7. 9.9.7 MSH-7 Date/Time of Message Date and time that the sending system created the message. NOTE: This field was made required in v2.4. 9.9.8 MSH-8 Security HL7 does not define any requirements for the use of this field. If the message has been secured, it is recommended that the name of the encryption system used be entered here, depending on the type of implementation used. 9.9.9 MSH-9 Message Type This field contains the message type, trigger event, and the message structure ID for the message. Refer to the table below for MSH-9 sub components: Sub Component Type Notes Table 160: MSH-9 Message Type Components 9.9.10 MSH-10 Message Control ID This field is a number or other identifier that uniquely identifies the message. Message Control IDs will be unique to messages that have come from a particular site. 9.9.11 MSH-11 Processing ID This field indicates how a receiving system should process this message. The allowed values for the first component are in Table 105. The second component is not used. 9.9.12 MSH-12 Version ID Used to identify the version of the message specification used. Refer to Table 123 for allowed values. 9.9.13 MSH-18 Character Set. This field contains the character set for the entire message: Value Description ASCII The printable 7-bit ASCII character set (the default if this field is omitted) Electronic Pharmaceutical Messaging Standard v1 November 2008 151 Value Description 8859/1 Not used in this implementation 8859/2 Not used in this implementation 8859/3 Not used in this implementation 8859/4 Not used in this implementation 8859/5 Not used in this implementation 8859/6 Not used in this implementation 8859/7 Not used in this implementation 8859/8 Not used in this implementation 8859/9 Not used in this implementation UNICODE Not used in this implementation UNICODE Transformation Format, 8-bit form UTF-8 is a variable-length encoding; each code value UTF-8 UCS is represented by 1, 2 or 3 bytes, depending on the code value. 7 bit ASCII is a proper subset of UTF-8. Note that the code contains a space before UTF but not before and after the hyphen. UNICODE Not used in this implementation UTF-16 UCS UNICODE Not used in this implementation UTF-32 UCS Table 161: HL7 Table 0211 – Alternative Character Sets NOTE: The field separator character must still be chosen from the printable 7-bit ASCII character set. Variance to HL7: In this implementation the character sets are restricted to ASCII and Unicode UTF-8 in compliance with the e-GIF New Zealand interoperability Framework version 3, Chapter 3, section 2.2, paragraph 2.2.1 Data Integration Layer. The repetitions of this field to specify different character sets apply only to fields of the FT, ST and TX data types. If the field is not valued, the default single-byte character set (ASCII (“ISO IR6”)) should be assumed. No other character sets are allowed in the message. If the field repeats, but the first element is “null” (i.e. present but unvalued), the single-byte ASCII (“ISO IR6”) is assumed as the default character set. 9.10 NK1 – Next of Kin / Associated Parties Segment This segment is used in the referral and discharge context to communicate next of kin and/or caregiver information. Example: NK1|1|Hamilton^Hugh^^^Prof^MCE^L|05^Son^99NZREL|24 Jones Road^^Tauranga|^PRN^PH^^^07^4649820^^After 5:30 Weekdays|^WPN^PH^^^07^1654846^2||||Engineer Electronic Pharmaceutical Messaging Standard v1 November 2008 152 Seq Element Name Len Type Opt Rpt Table No 1 Set ID 4 SI R 2 Name 250 XPN R Y Table 132 3 Relationship 250 CE R Table 163 4 Address 250 XAD O Y 5 Phone Number 250 XTN O Y 6 Business Phone Number 250 XTN O Y 7 Contact Role 250 CE O Table 164 8 Start Date 8 DT X 9 End Date 8 DT X 10 Job Title 60 ST X 11 Job Code/Class 20 JCC X 12 Employee Number 250 CX X 13 Organisation Name 250 XON X 14 Marital Status 250 CE O Table 191 15 Administrative Sex 1 IS O Table 189 16 Date/Time of Birth 26 TS O 17 Living Dependency 2 IS X Y 18 Ambulatory Status 2 IS X Y 19 Citizenship 250 CE O Y Table B 5 20 Primary Language 250 CE O Table B 1 21 Living Arrangement 2 IS X 22 Publicity Code 250 CE X 23 Protection Indicator 1 ID X 24 Student Indicator 2 IS X 25 Religion 250 CE X 26 Mother’s Maiden Name 250 XPN O Y 27 Nationality 250 CE X 28 Ethnic Group 250 CE X Y 29 Contact Reason 250 CE X Electronic Pharmaceutical Messaging Standard v1 November 2008 153 Seq Element Name Len Type Opt Rpt Table No 30 Contact Person's Name 250 XPN X 31 Contact Person’s 250 XTN X Telephone number 32 Contact Person’s Address 250 XAD X 33 Next of Kin/Associated 250 CX O Y Party’s Identifiers 34 Job Status 2 IS X 35 Ethnicity 250 CE O Y Table 190 36 Handicap 2 IS X 37 Contact Person’s Social X 16 ST Security Number 38 Next of Kin Birth Place 250 ST O 39 VIP Indicator 2 IS X Table 162: HL7 Attribute Table NK1 – Next of Kin 9.10.1 NK1-1 Set ID This field is used to identify repeats of this segment within a message. The first segment has a value of one. Numbering then increases incrementally for the following segment, etc. 9.10.2 NK1-2 Name This field identifies the name of the caregiver or next of kin. Where more than one name is recorded for each person, a name type code is required to distinguish the names. The first name sent in such instances will be the primary name. See Table 132 for valid name type codes. Refer also to the XPN definition in section 9.1.7.50. Variance to HL7: This field is optional in HL7 9.10.3 NK1-3 - Relationship This field identifies the relationship of the caregiver or next of kin to the person being treated. Use one of the following values from the NZHIS relationship tables: Value Description 01 Mother 02 Father 03 Sister 04 Brother 05 Son Electronic Pharmaceutical Messaging Standard v1 November 2008 154 Value Description 06 Daughter 07 Uncle 08 Aunt 09 Nephew 10 Niece 11 Cousin 12 Grandfather 13 Grandmother 14 Employer 15 Other 16 Spouse 91 Foster Father 92 Foster Mother 93 Stepfather 94 Stepmother 99 Self Table 163: User Defined Table 99NZREL – Relationship Variances to HL7: This is optional in HL7. HL7 uses values from HL7 Table 0063 in this field. 9.10.4 NK1-4 Address Reports the address of the next of kin and/or caregiver. 9.10.5 NK1-5 Phone Number This field contains the phone number of the next of kin and/or caregiver. 9.10.6 NK1-6 Business Phone Number This field contains the business phone number of the next of kin and/or caregiver. 9.10.7 NK1-7 Contact Role This field contains the role of the next of kin and/or caregiver. Use one of the values from the table below: Value Description IGR Information Guardian or Caregiver Electronic Pharmaceutical Messaging Standard v1 November 2008 155 Value Description CSP Clinical Service Provider LGR Legal Guardian ADV Advocate DOM Partner – De Facto FCH Foster Child NBR Neighbour COL Colleague FND Friend EPOA (PCW) Enduring Power of Attorney (Personal Care & Welfare) WG Welfare Guardian Table 164: HL7 User Defined Table 0131 – Contact Role Code 9.10.8 NK1-14 Marital Status This field contains the next of kin marital status. Use one of the values from Table 191. 9.10.9 NK1-15 Administrative Sex This field contains the next of kin’s sex. Use one of the values from Table 189. 9.10.10 NK1-16 Date/Time of Birth This field contains the next of kin’s birth date and time of birth. 9.10.11 NK1-19 Citizenship This field contains the code to identify the next of kin’s citizenship. Use one of the values from Table B 5. 9.10.12 NK1-20 Primary Language This field contains the code to identify the next of kin’s primary language. Use the values from Table B 1. 9.10.13 NK1-26 Mother’s Maiden Name This field indicates the maiden name of the next of kin’s mother. 9.10.14 NK1-33 Identifiers If an NHI number is present for next of kin, it should be included here. 9.10.15 NK1-35 Ethnicity This field is used to record the ethnicity of the next of kin. Refer to Table 190 for allowed values. Electronic Pharmaceutical Messaging Standard v1 November 2008 156 9.10.16 NK1-38 Next-of-Kin Birth Place This field indicates the location of the next-of-kin’s birth, for example “St. Francis Community Hospital of Lower South Side”. The actual address is reported in NK1-4– Address, with an identifier of “N”. 9.11 NTE – Notes and Comments Segment An NTE segment always provides information regarding the segment that it immediately follows. The NTE should contain notes or comments that extend the information provided in the segment it follows. The comment may contain multiple lines of text, using the line-break escape character to demark end-of-line. The preference should be to use a single NTE to contain the entire text where possible (see Set ID below). Seq Element Name Len Type Opt Rpt HL7 Table 1 Set ID 4 SI R 2 Source of comment 8 ID O Table 166 3 Comment 64k FT O Y 4 Comment Type 250 CE O Table 167 Table 165: HL7 Attribute Table NTE – Notes and Comments 9.11.1 NTE-1 Set ID The number system used is as follows: When several NTE segments are used to transmit a larger block (greater than 64k) of related text these segments would use the same Set IDs. Different Set IDs indicate unrelated text. The first NTE in a sequence will have a Set ID of one (“1”) and increment sequentially for the next unrelated NTE segment that pertains to the same segment. If more comments are required for any given segment, then the subsequent NTE segments will increment the Set ID by 1. Variance to HL7: This implementation requires the use of Set IDs for NTE segments. Example 1: The following example shows the Set IDs from the same comment split across two NTE segments. Please be aware that comments of this length may not be stored on some systems. OBX|… Example 2: The following example shows the Set IDs from two unrelated comments for a single OBX segment. OBX|… Example 3: The following example shows the Set IDs from two unrelated NTE segments pertaining to two different OBX segments. OBX|… Electronic Pharmaceutical Messaging Standard v1 November 2008 157 OBX|… NOTES: 1) Where possible, a NTE should not exceed 64k. The use of lengthy comments/notes that are required to be split is strongly discouraged. 2) NTE that has been split as shown in the example 1 above may not be supported by some systems. As a result information may be truncated. 3) The use of NTEs for important information is discouraged, particularly where truncation may occur. Consideration should be given to using an OBX. 9.11.2 NTE-2 Source of Comment Identifies the source of the comment. Refer to the table below for allowed NTE-2 values: Value Description L Ancillary (filler) department is source of comment P Placer is source of comment O Other system Table 166: HL7 Table 0105 – Source of Comment 9.11.3 NTE-3 Comment This field contains the comment contained in the segment. 9.11.4 NTE-4 Comment Type This field contains a value to identify the type of comment text being sent in the specific comment record. Value Description PI Patient Instructions AI Ancillary Instructions GI General Instructions 1R Primary Reason 2R Secondary Reason GR General Reason RE Remark DR Duplicate/Interaction Reason Table 167: HL7 User Defined Table 0364 – Comment Type Electronic Pharmaceutical Messaging Standard v1 November 2008 158 9.12 OBX – Observation Result Segment The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. Refer to the table below for OBX attributes: Example of an OBX message: OBX|0001|ST|1003^Haemoglobin^L^718-7^^LN||214|g/L|135-180|H|||F Seq Element Name Len Type Opt Rpt Table 1 Set ID 4 SI O 2 Value Type 3 ID C Table 169 3 Observation Identifier 250 CE R 4 Observation Sub-ID 20 ST C 5 Observation Value * varies C Y/3 6 Units 250 CE O 7 Reference Ranges 60 ST O 8 Abnormal Flags 5 ID O Y/5 Table 170 9 Probability 5 NM O 10 Nature of Abnormal Test 2 ID O Y Table 171 11 Observation Result Status 1 ID R Table 172 12 Date Last Observation Normal Values 26 TS X 13 User Defined Access Checks 20 ST X 14 Date/Time of Observation 26 TS O 15 Producer’s ID 250 CE O 16 Responsible Observer 250 XCN O 17 Observation Method 250 CE O Y 18 Equipment Instance Identifier 22 EI X 19 Date/Time of the Analysis 26 TS X Table 168: HL7 Attribute Table OBX – Observation Result 9.12.1 OBX-1 Set ID This field is used to identify repeats of this segment within a message. The first segment has a value of one (“1”), which will increase by one for each subsequent OBX segment. Electronic Pharmaceutical Messaging Standard v1 November 2008 159 9.12.2 OBX-2 - Value Type This field contains the format of the observation value in OBX-5. This field must contain a value unless OBX-11, below, contains an “X” to indicate that this segment does not report any results. The valid values for this field are listed in the table below: Value Description Comment AD Address CE Coded Entry Retained for Backward Compatibility only. Use CWE or CNE CF Coded Element with Formatted Values CP Composite Price CX Extended Composite ID with Check Digit DT Date ED Encapsulated Data FT Formatted Text (Display) MO Money NM Numeric PN Person Name Replaced by XPN as of HL7 v2.3 RP Reference Pointer SN Structured Numeric ST String Data TM Time TN Telephone Number Replaced by XTN as of HL7 v2.3 TS Time Stamp (Date and Time) TX Text Data (Display) XAD Extended Address XCN Extended Composite Name And Number For Persons XON Extended Composite Name And Number For Organisations XPN Extended Person Name XTN Extended Telecommunications Number Table 169: Constrained from HL7 Table 0125 – Value Type Variance to HL7: The length of this field has been increased to cater for 3 digit data types. Electronic Pharmaceutical Messaging Standard v1 November 2008 160 9.12.3 OBX-3 Observation Identifier This field contains a unique identifier for the observation. In most systems this identifier will point to a master observation table that will provide other attributes of the observation. It is recommended that if local codes are used as the first identifier, an equivalent universal identifier is also sent. This will allow receivers to compare results from different providers of the same service. Where possible, this implementation advocates the use of the NZPOCS or LOINC codes as a universal identifier. 9.12.4 OBX-4 Observation Sub-ID This field is used to distinguish between multiple OBX segments with the same observation ID organised under one RXO. This frequently occurs when a single test measures multiple parameters and thus produces multiple results. Where there is only one result per test, this field should be empty. This is required where there are multiple observations. 9.12.5 OBX-5 Observation Value This field contains the value observed (the actual result). This field is formatted according to the data type in OBX-2 (the value type field). This implementation allows 3 repeats. This is required when OBX-3 does not contain sufficient information to convey the result. Variance to HL7: The length of OBX-5 is unlimited, but consideration must be given to restrictions imposed by the message transport system. NOTE: May repeat for multipart, single answer results with appropriate data types, e.g. CE, TX and FT data types. 9.12.6 OBX-6 Units This field specifies the measurement units used within the OBX segment. Refer to Table B 10. 9.12.7 OBX-7 Reference Ranges The reference range is the range in which normal values fall. 9.12.8 OBX-8 Abnormal Flags This field contains a table lookup indicating the normality status of the result. It is recommended, when applicable, that this value be sent. A repeat delimiter should separate multiple codes. The most common values are listed in the table below: Value Description L Low H High LL Below Lower Panic Limit HH Above Upper Panic Limit Electronic Pharmaceutical Messaging Standard v1 November 2008 161 Value Description N Normal, applies only to Non-Numeric Values A Abnormal AA Extremely Abnormal Susceptible. Indicates for microbiology S susceptibilities only. Resistant. Indicates for microbiology susceptibilities R only. Intermediate. Indicates for microbiology I susceptibilities only. Table 170: HL7 User Defined Table 0078 – Abnormal Flags NOTE: This table is not comprehensive. 9.12.9 OBX-9 Probability This field contains the probability of a result being true for results with categorical values. It mainly applies to discrete coded results. This shall be a decimal number between 0 and 1, inclusive. 9.12.10 OBX-10 Nature of Abnormal Test This field contains the nature of the abnormal test. As many of the codes as apply may be included, separated by repeat delimiters. Refer to the table below for allowed values: Value Description A An age-based population N None – generic normal range R A race-based population S A sex-based population Table 171: HL7 Table 0080 – Nature of Abnormal Test NOTE: This table is not comprehensive. 9.12.11 OBX-11 Observation Result Status This field reflects the current status of the results for one observation identifier. The table below shows the most common values: Value Description F Final results. Can only be changed with a corrected result. P Preliminary results R Results entered – not verified S Partial results Electronic Pharmaceutical Messaging Standard v1 November 2008 162 Value Description O Order detail description only (no result) C Record coming over is a correction and thus replaces a final result D Deletes the OBX record X Results cannot be obtained for this observation W Post original as wrong, e.g. transmitted for wrong patient Table 172: HL7 Table 0085 – Observation Results Status 9.12.12 OBX-14 Date/Time of Observation This field is the physiologically relevant date/time or the closest approximation to that time. In the case of tests performed on specimens, the relevant date-time is the specimen’s collection date/time. In the case of observations taken directly on the patient, the observation date/time is the date/time that the observation was performed. 9.12.13 OBX-15 Producer’s ID This field contains the unique identifier of the responsible producing service. 9.12.14 OBX-16 Responsible Observer This field contains the identity of the individual directly responsible for the observation. This is the person who either performed the test or verified the result. It is used for audit trail information. 9.12.15 OBX-17 Observation Method This field is used to transmit the method or procedure by which an observation was obtained when the sending system wishes to distinguish one measurement obtained by different methods and the distinction is not implicit in the test ID. 9.13 ORC – Order Common Segment The Common Order Segment (ORC) is common to all pathology and pharmacy orders. Refer to the table below for ORC attributes. Example of the use of an ORC message: ORC|NW|230462123.0001||230462123|||||199708071000|||12346^Doctor^Ordering^M^^Dr^^HPI Seq Element Name Len Type Opt Rpt Table 1 Order Control 2 ID R Table 174 2 Placer Order Number 50 EI R 3 Filler Order Number 50 EI C 4 Placer Group Number 50 EI O 5 Order Status 2 ID O Table 175 Electronic Pharmaceutical Messaging Standard v1 November 2008 163 Seq Element Name Len Type Opt Rpt Table 6 Response Flag 1 ID O Table 176 7 Quantity/Timing 200 TQ B Y 8 Parent 200 EIP X 9 Date/Time of Transaction 26 TS O 10 Entered By 250 XCN O Y 11 Verified By 250 XCN O Y 12 Ordering Provider 250 XCN R Y 13 Enterer’s Location 80 PL X 14 Call Back Phone Number 250 XTN O Y/2 15 Order Effective Date/Time 26 TS O 16 Order Control Reason Code 250 CE O Table 178 17 Entering Organisation 250 CE O 18 Entering Device 250 CE X 19 Action By 250 XCN O Y 20 Advanced Beneficiary Notice 250 CE O Table 179 Code 21 Ordering Facility Name 250 XON O Y 22 Ordering Facility Address 250 XAD X Y 23 Ordering Facility Phone Number 250 XTN X Y 24 Ordering Provider Address 250 XAD X Y 25 Order Status Number 250 CWE O 26 Advanced Beneficiary Notice 60 CWE C Override Reason 27 Filler's Expected Availability 26 TS O Date/Time 28 Confidentiality Code 250 CWE O Table 180 29 HL7 Order Type 250 CWE O Table 181 30 Enterer Authorisation Mode 250 CNE O Table 182 Table 173: HL7 Attribute Table ORC – Order Common NOTES: 1) Placer order groups: The HL7 v2.5 Standard supports a mechanism to collect several orders together in a group. Most often this is used to represent an ‘ordering session’ for a single Patient. An order group is a list of orders (ORCs) associated with an ORC-4 Placer Group Number. A group is Electronic Pharmaceutical Messaging Standard v1 November 2008 164 established when the placer supplies a placer group number with the original order. The order group consists of all the ORCs and order detail segments that have the same placer group number. Orders can be removed from the group using Cancel. New orders cannot otherwise be added to the group. 2) Duplicate fields: Although the ORC is intended to uniformly define the fields common to all orders, it does duplicate some fields in the order detail (OBR) segment, e.g. ORC 2 Placer Order Number has the same meaning and purpose as OBR-2 Placer Order Number. The rule for using these fields is that the value shall appear in the OBR segment if it does not appear in the ORC. The HL7 v2.5 Standard recommends transmitting the field value in both places to avoid confusion. We strongly endorse the HL7 recommendation. 3) ORC-6 is specifically used in New Zealand to indicate if the prescriber wishes to be notified on dispensing of this item. Variance to HL7: The length of the ORC-2 Placer Order Number, ORC-3 Filler Order Number and ORC-4 Placer Group Number filler have been increased to 50. 9.13.1 ORC-1 Order Control This field determines the function of the order segment. The standard code table for ORC-1 provides for approximately 45 control modes, such as “new order”, “cancel request”, “order cancelled”, etc. The order control code used in ORC-1 will determine the ORC-5 Order Status Code and ORC-16 Order Control Reason. Value Sender Description NW Placer (P) New order OK Filler (F) New order accepted UA Filler (F) Unable to accept CA Placer (P) Request to cancel order CR Filler (F) Order cancelled as requested DC Placer (P) Discontinue DR Filler (F) Discontinued as requested IN Placer or Filler Information RU Filler (F) Replaced unsolicited UC Filler (F) Unable to cancel RE Filler (F) Results to follow SC Placer or Filler Status Change XO Placer (P) Change Order/Service Request Table 174: HL7 Table 0119 – Order Control Codes NOTES: 1) This list is not comprehensive. Refer to HL7 v2.5 Chapter 4.23.1 for a full list of Order Control Codes. 2) “F”: values originate from the filler and are not restricted for sending only to the placer. “P”: values originate from the placer or other application with placer privileges (as agreed in interface negotiation). Electronic Pharmaceutical Messaging Standard v1 November 2008 165 9.13.2 ORC-2 Placer Order Number This field is the unique number that the placer application has assigned to this order. This uniqueness shall persist over time. Variance to HL7: This field is required in this implementation but is conditional in HL7. 9.13.3 ORC-3 Filler Order Number This field contains the order number as assigned by the filling application. This filler order number shall uniquely identify the order from other orders in a particular filling application and this uniqueness shall persist over time. 9.13.4 ORC-4 Placer Group Number Allows an order placing application to group sets of orders together and subsequently identify them. 9.13.5 ORC-5 - Order Status This field specifies the status of an order and should be completed so the receiving system knows if the medication is current or historic. The following status codes are used when standard HL7 Order Control codes are used in ORC-1. Refer to the table below for allowed ORC-5 values: Value Description A Some, but not all, results available CA Order was cancelled CM Order is completed DC Order was discontinued ER Error, order not found HD Order is on hold IP In process, unspecified RP Order has been replaced SC In process, scheduled Table 175: HL7 Table 0038 – Order Status 9.13.6 ORC-6 Response Flag This field allows the sending application to determine the amount of information to be returned from the filler. When the field is null, E is the default value of the field. Value Description E Report exceptions only R Report exceptions only also Replacement and Parent-Child D Report exceptions only, also Replacement and Parent-Child and also other associated Electronic Pharmaceutical Messaging Standard v1 November 2008 166 Value Description segments F Report exceptions only, also Replacement and Parent-Child and also other associated segments plus confirmations explicitly N Only the MSA segment is returned Table 176: Constrained from HL7 Table 0121 – Response Flag for Valid Entries NOTE: When this field is set to F it will always cause a RDS^O13 message to be sent to the prescriber otherwise the prescriber is only notified of exceptions requiring attention. 9.13.7 ORC-7 - Quantity/Timing This field is retained for backward compatibility only . Refer to the TQ1 and TQ2 segments. 9.13.8 ORC-9 Date/Time of Transaction This field is the date and time of the event the current transaction was initiated. This message is not equivalent to MSH-7, which reflects the date/time of the physical message. 9.13.9 ORC-10 Entered By This field identifies the person who actually keyed the request into the application. It provides an audit trail in the event that clarification of the request is required. 9.13.10 ORC-11 Verified By This field contains the identity of the person who verified the accuracy of the entered request. 9.13.11 ORC-12 Ordering Provider This field is the identity of the person who is responsible for creating the request. It is used in cases where the request is entered by a technician and needs to be verified by a higher authority. Variance to HL7: this field is optional in HL7 but required in this implementation. 9.13.12 ORC-14 Call Back Phone Number This field is the telephone number to call for clarification of an order. 9.13.13 ORC-15 Order Effective Date/Time This field contains the date/time that the changes to the request took effect. 9.13.14 ORC-16 Order Control Reason This contains the status for the order event described in the order control. When the ORC-1 code of IN is used in a pharmacy message, then codes from the following table are used to indicate the nature of the information that follows: Value Description PCC Patient Category Card Electronic Pharmaceutical Messaging Standard v1 November 2008 167 Value Description FSC Funding Status Code ACC Accident details ALRT Administrative alerts and warnings ATT Attachment FAM Family history MEDLT Long term medication details MEDCU Current medication MEDIP Inpatient medication (not continued after discharge) MEDDS Discharge prescription MEDHS Historical medication (GP-prescribed medication prior to creating referral) REFER Main text of the referral OBS Observations GENERAL Contains information that may be required for the clinician for this referral LIT Use if there is a requirement to include, within the message, a copy of how the prescription appeared visually to the prescriber XMLATTACH An attachment that contains XML data and refers to the XSD Table 177: User Defined Table 99NZIN – NZ Specific ORC Groups Value Description Notes CF Collected in full OW Collected with “owe” In this case the order remains locked. AR Authorisation Request Change needs Authorisation from the prescriber AP Authorisation Processed Electronic Authorisation NA Not Actioned OF Authorisation on file Paper authorisation has been received and is held at the dispenser NP Notify Prescriber In this case the prescriber requires notification of dispensing UF Unable to fill Items being returned to the HMX for filling by another dispenser Table 178: User Defined Table 99NZPHARMSTAT – Pharmacy Specific ORC Groups Electronic Pharmaceutical Messaging Standard v1 November 2008 168 9.13.15 ORC-17 Entering Organisation This field identifies the organisation that the enterer belonged to at the time of entering/maintaining of the order. 9.13.16 ORC-19 Action By This field identifies the person who initiated the event represented by the corresponding order control code. 9.13.17 ORC-20 Advanced Beneficiary Notice Code This field indicates the status of the patient’s or the patient’s representative’s consent for responsibility to pay for potentially uninsured services. Refer to the table below for allowed ORC-20 values: Value Description 1 Service is subject to medical necessity procedures 2 Patient has been informed of responsibility, and agrees to pay for service 3 Patient has been informed of responsibility, and asks that the payer be billed 4 Advanced Beneficiary Notice has not been signed Table 179: HL7 User Defined Table 0339 – Advanced Beneficiary Notice Code 9.13.18 ORC-21 Ordering Facility Name This field is a unique identifier for a facility assigned by the data source. The facility identifier is assigned by the Health Practitioner Index (HPI) system at the time that the facility record in the HPI is created. The data type is has field size of 6 and is alphanumeric. The layout is FXNNN where F is a constant prefix and X is either an alpha or numeric. 9.13.19 ORC-25 Order Status Modifier This field is a modifier or refiner of the ORC-5 Order Status field. This field may be used to provide additional levels of specificity or additional information for the defined order status codes. NOTE: This field may only be populated if the ORC-5 Order Status field is valued. 9.13.20 ORC-26 Advanced Beneficiary Notice Override Reason This field contains the reason why the patient did not sign an Advanced Beneficiary Notice. This field is required if the value of ORC-20 Advanced Beneficiary Notice Code indicates that the notice was not signed. 9.13.21 ORC-27 Filler's Expected Availability Date/Time This field specifies the date/time the filler expects the services to be available. For example, when a prescription is ready for pickup or when a supply will be sent or picked up. 9.13.22 ORC-28 Confidentiality Code This field contains information about the level of security and/or sensitivity surrounding the order (e.g. highly Electronic Pharmaceutical Messaging Standard v1 November 2008 169 sensitive, not sensitive, sensitive, etc). Refer to table below for allowed values: Value Description V Very restricted R Restricted U Usual control EMP Employee UWM Unwed mother VIP Very important person or celebrity PSY Psychiatric patient AID AIDS patient HIV HIV(+) patient ETH Alcohol/drug treatment patient Table 180: HL7 User Defined Table 0177 – Confidentiality Code 9.13.23 ORC-29 HL7 Order Type This field indicates whether the order is to be executed in an inpatient, an outpatient or community setting. If this field is not valued, the system default is assumed. Refer to the table below for suggested values: Value Description I Inpatient Order O Outpatient Order C Community Table 181: HL7 Table 0482 – HL7 Order Type Variance to HL7: Code ‘C’ has been added to the table to indicate Community setting Variance to HL7: This is called HL7 Order Type to avoid conflict usage with existing terms used in Pharmaceutical Transaction Data Specification. 9.13.24 ORC-30 Enterer Authorisation Mode This field indicates the form of authorisation a recorder had from the responsible practitioner to create or change an order. Refer to table below for suggested values: Value Description EL Electronic EM E-mail FX Fax Electronic Pharmaceutical Messaging Standard v1 November 2008 170 Value Description IP In Person MA Mail PA Paper PH Phone RE Reflexive (Automated system) VC Video-conference VO Voice Table 182: HL7 Table 0483 – Authorisation Mode 9.14 PD1 – Additional Patient Demographics Segment This segment contains additional patient demographic information that is subject to change. Refer to the table below: Seq Element Name Len Type Opt Rpt Table 1 Living Dependency 2 IS O Y Table 184 2 Living Arrangement 2 IS O Table 185 3 Patient Primary Facility 250 XON O Y 4 Patient Primary Care 250 XCN B Y Provider Name & ID No. 5 Student Indicator 2 IS X 6 Handicap 2 IS O Table 186 7 Living Will Code 2 IS X 8 Organ Donor Code 2 IS X 9 Separate Bill 1 ID X 10 Duplicate Patient 250 CX X Y 11 Publicity Code 250 CE X 12 Protection Indicator 1 ID X 13 Protection Indicator Effective X 8 DT Date 14 Place of Worship 250 XON X Y 15 Advance Directive Code 250 CE X Y 16 Immunisation Registry Status 1 IS O Table 187 Electronic Pharmaceutical Messaging Standard v1 November 2008 171 Seq Element Name Len Type Opt Rpt Table 17 Immunisation Registry Status 8 DT O Effective Date 18 Publicity Code Effective Date 8 DT X 19 Military Branch 5 IS X 20 Military Rank/Grade 2 IS X 21 Military Status 3 IS X Table 183: HL7 Attribute Table PD1 – Additional Patient Demographics 9.14.1 PD1-1 Living Dependency This field identifies specific living conditions relevant to an evaluation of the patient’s health care needs, including discharge planning. This field repeats because, e.g. “Spouse Dependent” and “Medical Supervision Required” can apply at the same time. Refer to the table below, for suggested values: Value Description S Spouse Dependent M Medical Supervision Required C Small Children Dependent O Other U Unknown Table 184: HL7 User Defined Table 0223 - Living Dependency 9.14.2 PD1-2 Living Arrangement This field identifies the situation in which the patient lives at his residential address. Refer to the table below for suggested values: Value Description A Alone F Family I Institution R Relative S Spouse only U Unknown Table 185: HL7 User Defined Table 0220 – Living Arrangement Electronic Pharmaceutical Messaging Standard v1 November 2008 172 9.14.3 PD1-3 Patient Primary Facility This field contains the name and identifier that specifies the primary care health care facility selected by the patient at the time of enrolment in an insurance plan. 9.14.4 PD1-4 Patient Primary Care Provider Name & ID No. This field is retained for backward compatibility only. It is envisaged that the ROL segment will be used for future implementations. 9.14.5 PD1-6 Handicap This field indicates the nature of the patient’s permanent physical or mental disability (e.g. deaf, blind). Refer to the table below, for suggested values. For transient disabilities, refer to the PV1-15 (ambulatory status field). Value Description A0 No functional limitations A1 Ambulates with assistive device A2 Wheelchair/stretcher bound A5 Vision impaired A6 Hearing impaired A7 Speech impaired A9 Functional level unknown B3 Amputee B4 Mastectomy B5 Paraplegic Table 186: HL7 User Defined Table 0295 – Handicap NOTE: This list is not comprehensive. 9.14.6 PD1-16 Immunisation Registry Status This code identifies the patient’s current status on (or opted off) the Registry. Use values from the following table: Value Description A Active P Provisional Opt Off Table 187: HL7 User Defined Table 0441 – Immunisation Registry Status NOTE: This list is not comprehensive. Electronic Pharmaceutical Messaging Standard v1 November 2008 173 9.14.7 PD1-17 Immunisation Registry Status Effective Date The date that the registry status in PD1-16 came into effect. 9.15 PID – Patient ID Segment The PID segment is the primary means of communicating patient identification information. Refer to the table below for PID attributes. PID Example: PID|||ABC1234^^^NZLMOH||TEST^PATIENT||19650205|M|||1 Road^Suburb^City Seq Element Name Len Type Opt Rpt Table 1 Set ID 4 SI O 2 Patient ID 20 CX X 3 Patient Identifier List 250 CX R Y Table 72 4 Alternate Patient ID 20 CX X Y 5 Patient Name 250 XPN R Y Table 132 6 Mother’s Maiden Name 250 XPN O Y 7 Date of Birth 26 TS O 8 Sex 1 IS O Table 189 9 Patient Alias 250 XPN X Y 10 Ethnicity 250 CE O Y3 Table 190 11 Patient Address 250 XAD R Y 12 Country Code 4 IS X 13 Home Phone 250 XTN O Y 14 Business Phone 250 XTN O Y 15 Primary Language 250 CE O Table B 1 16 Marital Status 250 CE O Table 191 17 Religion 250 CE O Table B 7 18 Patient Account Number 250 CX O 19 SSN Number 16 ST X 20 Driver’s License Number 25 DLN X 21 Mother’s Identifier 250 CX O Y Table 73 22 Ethnic Group 250 CE O Y Electronic Pharmaceutical Messaging Standard v1 November 2008 174 Seq Element Name Len Type Opt Rpt Table 23 Birth Place 250 ST O 24 Multiple Birth Indicator 1 ID O Table 34 25 Birth Order 2 NM O 26 Citizenship 250 CE O Y Table B 5 27 Veterans Military Status 250 CE X 28 Nationality 250 CE X 29 Patient Death Date and Time 26 TS O 30 Patient Death Indicator 1 ID O Table 192 31 Identity Unknown Indicator 1 ID O Table 193 32 Identity Reliability Code 20 IS O Y Table 194 33 Last Update Date/Time 26 TS X 34 Last Update Facility 40 HD X 35 Species Code 250 CE C 36 Breed Code 250 CE C 37 Strain 80 ST X 38 Production Class Code 250 CE X 2 39 Iwi 250 CWE O Y Table B 13 Table 188: HL7 Attribute Table PID – Patient ID Segment 9.15.1 PID-1 Set ID This field is used to identify repeats of this segment within a message. 9.15.2 PID-3 Patient Identifier List This field contains the list of identifiers used by the health care facility to uniquely identify a patient. It is strongly recommended that the patient’s NHI number is used as the identifier. 9.15.3 PID-5 Patient Name Records the names and aliases of a particular patient. Where more than one name is recorded for each patient, a name type code is required to distinguish the names. The first name sent in such instances will be the primary name. Refer to Table 132 or the most common values: 9.15.4 PID-6 Mother’s Maiden Name This field contains the family name under which the mother was born (i.e. before marriage). It is used to distinguish between patients with the same last name. Electronic Pharmaceutical Messaging Standard v1 November 2008 175 9.15.5 PID-7 Date of Birth This field contains the patient’s date and time of birth. NOTE: This information should be sent where it is available. 9.15.6 PID-8 Administrative Sex This field contains the Patient’s gender. It is strongly recommended that “M” or “F” be used, except where this is clearly impossible. Refer to the table below for PID-8 values: Value Description F Female M Male I Indeterminate U Unknown Table 189: HL7 User Defined Table 0001 – Administrative Sex 9.15.7 PID-10 Ethnicity This field is used to record the ethnicity of the patient. Refer to the table below for allowed values: Value Description 10 European Not Further Defined 11 New Zealand European/Pakeha 12 Other European 21 New Zealand Māori 30 Pacific Peoples Not Further Defined 31 Samoan 32 Cook Island Māori 33 Tongan 34 Niuean 35 Tokelauan 36 Fijian 37 Other Pacific Peoples 40 Asian Not Further Defined 41 Southeast Asian 42 Chinese Electronic Pharmaceutical Messaging Standard v1 November 2008 176 Value Description 43 Indian 44 Other Asian 51 Middle Eastern 52 Latin American/Hispanic 53 African (or cultural group of African origin) 54 Other 99 Not stated Table 190: User Defined Table 99NZETH – Ethnicity NOTE: This field is called Race in HL7 v2.5. Variance to HL7: HL7 allows this field to repeat as many times as necessary. New Zealand usage allows only 3 repeats of this field. 9.15.8 PID-11 Patient Address This field contains the address information of the Patient. The mailing address shall always be sent first. If the first address is not the mailing address, then a repeat delimiter should be sent to indicate an empty mailing address. NOTE: This field is required under Medicines Regulations, Reg 41 (d) (i) Variance to HL7: This field is optional in HL7 but a required field in this implementation. 9.15.9 PID-13 Home Phone This field contains the patient’s personal contact phone numbers. 9.15.10 PID-14 Business Phone This field contains the patient’s business phone numbers. All business phone numbers for the patient are sent in this sequence. An email address may be sent if the telecommunications use code is “NET”. 9.15.11 PID-15 Primary Language This field contains the patient’s primary language. Refer to Table B 1. 9.15.12 PID-16 Marital Status This field contains the patient’s marital (civil) status. Use one of the values from the table below: Value Description A Separated D Divorced M Married Electronic Pharmaceutical Messaging Standard v1 November 2008 177 Value Description S Single W Widowed C Common Law G Living Together P Domestic Partner R Registered Domestic Partner E Legally Separated N Annulled I Interlocutory B Unmarried U Unknown V Civil Union O Other T Unreported Table 191: HL7 User Defined Table 0002 – Marital Status NOTE: This has been extended for New Zealand purposes to include Civil Union. 9.15.13 PID-17 Religion This field contains the patient’s religion. Use one of the values from Table B 7. 9.15.14 PID-18 Patient Account Number This field contains the patient account number assigned by accounting, to which all charges, payments, etc are recorded. It is used to identify the patient’s account. 9.15.15 PID-21 - Mother’s Identifier This field is used, e.g. as a link for newborns. Typically, a patient ID or account number may be used. This field can contain multiple identifiers for the same mother. Refer to Table 73 for valid values. 9.15.16 PID-22 Ethnic Group This field further defines the patient’s ancestry, e.g. iwi. The values required for this optional field should be agreed between the parties exchanging this information. 9.15.17 PID-23 Birth Place This field indicates the location of the patient’s birth. The actual address is reported in PID-11 with an identifier of "N". Electronic Pharmaceutical Messaging Standard v1 November 2008 178 9.15.18 PID-24 Multiple Birth Indicator This field indicates whether the patient was part of a multiple birth. 9.15.19 PID-25 Birth Order This field indicates numerically the patient’s birth order if part of a multiple birth. 9.15.20 PID-26 Citizenship This field contains the patient’s country of citizenship. Refer to Table B 5. 9.15.21 PID-29 Patient Death Date and Time This field contains the date and time at which the patient death occurred. 9.15.22 PID-30 Patient Death Indicator This field indicates whether the patient is deceased. Refer to the table below for allowed values: Value Description Y The patient is deceased N The patient is not deceased Table 192: HL7 Table 0136 – Yes/No Indicator – Patient Death Indicator 9.15.23 PID-31 Identity Unknown Indicator This field indicates whether or not the patient’s/person’s identity is known. Refer to the table below for suggested values: Value Description Y The patient’s/person’s identity is unknown N The patient’s/person’s identity is known Table 193: HL7 Table 0136 – Yes/No Indicator – Identity Unknown Indicator 9.15.24 PID-32 Identity Reliability Code This field contains a coded value used to communicate information regarding the reliability of the patient/person identifying data in a transmission. Values could indicate that certain fields on a PID segment for a given patient/person are known to be false. Refer to the table below for suggested values: Value Description US Unknown/Default Social Security Number UD Unknown/Default Date of Birth UA Unknown/Default Address AL Patient/Person Name is an Alias Table 194: HL7 User Defined Table 0445 – Identity Reliability Code Electronic Pharmaceutical Messaging Standard v1 November 2008 179 9.15.25 PID-35 Species Code This field indicates the species of living organism. HL7 recommends SNOMED. If the field is not valued, a human is assumed. 9.15.26 PID-36 Breed Code This field indicated the specific breed of animal. This field is specific to animals and cannot be generally used for all living organisms. HL7 recommends SNOMED. 9.15.27 PID-39 Iwi This field contains the information related to a person's iwi affiliation. Refer to Table B 13. Variance to HL7: This field is called Tribal Citizenship in HL7. 9.16 PV1 – Patient Visit Segment This segment is used to communicate information on a visit or account specific basis. Example: PV1||O|Renal||||12345^Doctor^Attending^M^^Dr^^HPI Seq Element Name Len Type Opt Rpt Table 1 Set ID 4 SI O 2 Patient Class 1 IS R Table 196 3 Assigned Patient Location 80 PL O Table 197 4 Admission Type 2 IS O Table 198 5 Pre-admit Number 250 CX O 6 Prior Patient Location 80 PL O 7 Attending Practitioner 250 XCN O Y 8 Referring Practitioner 250 XCN O Y 9 Consulting Practitioner 250 XCN O Y 10 Health Specialty 3 IS O Table B 8 11 Temporary Location 80 PL O 12 Pre-admit Test Indicator 2 IS O 13 Readmission Indicator 2 IS O Table 199 14 Admit Source 6 IS O Table 200 15 Ambulatory Status 2 IS O Y Table 201 16 VIP Indicator 2 IS X Electronic Pharmaceutical Messaging Standard v1 November 2008 180 Seq Element Name Len Type Opt Rpt Table 17 Admitting Practitioner 250 XCN O Y 18 Patient Type 2 IS O 19 Visit Number 250 CX O 20 Financial Class 50 FC O Y Table 202 21 Charge Price Indicator 2 IS X 22 Courtesy Code 2 IS X 23 Credit Rating 2 IS X 24 Contract Code 2 IS X Y 25 Contract Effective Date 8 DT O Y 26 Contract Amount 12 NM X Y 27 Contract Period 3 NM O Y 28 Interest Code 2 IS X 29 Transfer to Bad Debt Code 1 IS X 30 Transfer to Bad Debt Date 8 DT X 31 Bad Debt Agency Code 10 IS X 32 Bad Debt Transfer Amount 12 NM X 33 Bad Debt Recovery Amount 12 NM X 34 Delete Account Indicator 1 IS X 35 Delete Account Date 8 DT X 36 Discharge Disposition 3 IS O Table 203 37 Discharged to Location 47 DLD O Table 204 38 Diet Type 250 CE O 39 Servicing Facility 2 IS O 40 Bed Status 1 IS B 41 Account Status 2 IS O 42 Pending Location 80 PL O 43 Prior Temporary Location 80 PL O 44 Admit Date/Time 26 TS O 45 Discharge Date/Time 26 TS O Y Electronic Pharmaceutical Messaging Standard v1 November 2008 181 Seq Element Name Len Type Opt Rpt Table 46 Current Patient Balance 12 NM X 47 Total Charges 12 NM O 48 Total Adjustments 12 NM O 49 Total Payments 12 NM O 50 Alternate Visit ID 250 CX X 51 Visit Indicator 1 IS X 52 Other Health Care Provider 250 XCN B Y Table 195: HL7 Attribute Table PV1 – Patient Visit 9.16.1 PV1-1 Set ID This field is used to identify repeats of this segment within a message. The first segment has a value of one (“1”). Numbering then increases incrementally for the next segment. 9.16.2 PV1-2 Patient Class This field is used by systems to categorise patients. Allowed values are in the table below: Value Description E Emergency I InPatient O OutPatient P Pre-admit B Obstetrics U Unknown N Not Applicable. Table 196: HL7 User Defined Table 0004 – Patient Class NOTE: This table is not comprehensive. 9.16.3 PV1-3 Assigned Patient Location This field contains the patient’s assigned location. The information for status of the bed is in Value Description C Closed H Housekeeping Electronic Pharmaceutical Messaging Standard v1 November 2008 182 Value Description O Occupied U Unoccupied K Contaminated I Isolated Table 197: HL7 User Defined Table 0116 – Bed Status 9.16.4 PV1-4 Admission Type This field indicates the circumstances under which the patient was or will be admitted. Value Description A Accident E Emergency L Labour and Delivery R Routine Newborn (Birth in Health Care N Facility) U Urgent C Elective Table 198: HL7 User Defined Table 0007 - Admission Type 9.16.5 PV1-5 Pre-admit Number This field uniquely identifies the patient’s pre-admit account. Some systems will continue to use the Pre- admit Number as the billing number after the patient has been admitted. To maintain backward compatibility, a ST data type may be sent. However, HL7 recommends use of the CX data type, such as the account number, for new implementations. 9.16.6 PV1-6 Prior Patient Location This field contains the prior patient location if the patient is being transferred. The old location is “null” if the patient is new. 9.16.7 PV1-7 Attending Practitioner This field contains the attending practitioner information. 9.16.8 PV1-8 Referring Practitioner This field contains the referring practitioner information. Electronic Pharmaceutical Messaging Standard v1 November 2008 183 9.16.9 PV1-9 Consulting Practitioner This field has been retained for backward compatibility only. It is envisaged that the ROL segment will be used for future implementations. 9.16.10 PV1-10 Health Specialty This field contains the treatment or type of surgery that the patient is scheduled to receive. It is a required field, with trigger events A01 (admit/visit notification), A02 (transfer a patient), A14 (pending admit), A15 (pending transfer). Refer to Table B 8 for valid values. Variance to HL7: This field is called Hospital Service in HL7. 9.16.11 PV1-11 Temporary Location This field contains a location other than the assigned location, if required for a temporary period of time (e.g. OR, operating theatre, etc). 9.16.12 PV1-12 Pre-admit Test Indicator This field indicates whether the patient must have pre-admission testing done in order to be admitted. 9.16.13 PV1-13 Re-Admission Indicator This field indicates that a patient is being re-admitted to the health care facility and gives the circumstances. It is suggested that "R" for re-admission is used, otherwise “null”. Value Description R Re-admission Table 199: HL7 User Defined Table 0092 – Re-Admission Indicator 9.16.14 PV1-14 Admit Source This field indicates where the patient was admitted. Refer to the table below: Value Description 1 Physician referral 2 Clinic referral 3 HMO referral 4 Transfer from a hospital 5 Transfer from a skilled nursing facility 6 Transfer from another health care facility 7 Emergency room 8 Court/law enforcement 9 Information not available Table 200: HL7 User Defined Table 0023 – Admit Source Electronic Pharmaceutical Messaging Standard v1 November 2008 184 9.16.15 PV1-15 Ambulatory Status This field indicates permanent or transient ambulatory status. Refer to the table below: Value Description A0 No functional limitations A1 Ambulates with assistive device A2 Wheelchair/stretcher bound A3 Comatose; non-responsive A4 Disoriented A5 Vision impaired A6 Hearing impaired A7 Speech impaired A8 Non-English speaking A9 Functional level unknown B1 Oxygen therapy B2 Special equipment (tubes, IVs, catheters) B3 Amputee B4 Mastectomy B5 Paraplegic B6 Pregnant Table 201: HL7 User Defined Table 0009 – Ambulatory Status Variance to HL7: This field is called Transient Handicapped Condition in HL7. 9.16.16 PV1-17 Admitting Practitioner This field contains the admitting physician information. Multiple names and identifiers for the same physician may be sent. The field sequences are not used to indicate multiple admitting practitioners. The legal name must be sent in the first sequence. If the legal name is not sent, then a repeat delimiter must be sent in the first sequence. By local agreement, the name or ID may be absent in this field. 9.16.17 PV1-18 Patient Type This field contains site-specific values that identify patient type. No suggested values are defined. 9.16.18 PV1-19 Visit Number This field contains the unique number assigned to each patient visit/encounter. Electronic Pharmaceutical Messaging Standard v1 November 2008 185 9.16.19 PV1-20 Financial Class This field contains the financial class(es) assigned to the patient for the purpose of identifying sources of reimbursement. Refer to the table below, for suggested values: Value Description 01 ACC 02 Private health insurance 03 Self-funded 04 Clinical trial 05 Public funded 06 Other Table 202: HL7 User Defined Table 0064 – Financial Class 9.16.20 PV1-25 Contract Effective Date This field contains the date that the contract is to start, or has started. 9.16.21 PV1-27 Contract Period This field specifies the duration of the contract for user defined periods. 9.16.22 PV1-36 Discharge Disposition This field contains the disposition of the patient at time of discharge. Value Description DA Discharge to acute specialist facility (neonates and burns only) DC Psychiatric patient discharged to community care DD Died DF Statistical discharge for change in funder DI Self discharge from hospital, indemnity signed DL Committed psychiatric patient discharged to leave for more than 10 days DN Psychiatric remand patient discharged without committal DO Discharge of a patient for organ donation DP Psychiatric patient transferred for further psychiatric care DR Ended routinely DS Self-discharge from hospital (no indemnity) DT Discharge of non-psychiatric patient to another health care facility Electronic Pharmaceutical Messaging Standard v1 November 2008 186 Value Description DW Discharge to other service within same facility between the following specialties: Advanced Therapy and Rehabilitation (AT&R), mental health, obstetrics, and personal health. Not to be used for transfer between surgical and medical. Table 203: User Defined 99NZDIS – Discharge Disposition Variance to HL7: HL7 uses values from HL7 User Defined Table 0112 in this field. 9.16.23 PV1-37 Discharged To Location This field indicates the health care facility to which the patient was discharged and the date. The health care facility is identified by the Facility Identifier (as defined by the HPI); refer to table below: Value Description FXXNNN Facility Identifier as defined by the HPI Table 204: HL7 User Defined Table 0113 – Discharged To Location The data type is has field size of 6 and is alphanumeric. The layout is FXNNN, where F is a constant prefix and X is either an alpha or numeric. 9.16.24 PV1-38 Diet Type This field indicates a special diet type for a patient. 9.16.25 PV1-39 Servicing Facility This field is used in a multiple facility environment to indicate the health care facility with which this visit is associated. 9.16.26 PV1-40 Bed Status This field has been retained for backward compatibility. It is superseded by the fifth component of PV1-3, 9.16.27 PV1-41 Account Status This field contains the account status. 9.16.28 PV1-42 Pending Location This field indicates the point of care, room, bed, health care facility ID, and bed status to which the patient may be moved. The first component may be the nursing station for inpatient locations, or the clinic, department, or home for locations other than inpatient. 9.16.29 PV1-43 Prior Temporary Location This field is used to reflect the patient’s temporary location (such as the operating room/theatre or x-ray), prior to a transfer from a temporary location to an actual location, or from a temporary location to another temporary location. The first component may be the nursing station for inpatient locations, or the clinic, department, or home for locations other than inpatient. Electronic Pharmaceutical Messaging Standard v1 November 2008 187 9.16.30 PV1-44 Admit Date/Time This field contains the admit date/time of a patient. 9.16.31 PV1-45 Discharge Date/Time This field contains the discharge date/time of a patient. 9.16.32 PV1-47 Total Charges This field contains the total visit charges. 9.16.33 PV1-48 Total Adjustments This field contains the total adjustments for visit. 9.16.34 PV1-49 Total Payments This field contains the total payments for visit. 9.16.35 PV1-52 Other Health Care Providers This field has been retained to maintain backward compatibility only. It is envisaged that the ROL segment will be used for future implementations. 9.17 PV2 – Patient Visit Additional Information Segment The PV2 segment is a continuation of information contained on the PV1 segment. Refer the table below: Seq Element name Len Type Opt Rpt Table 1 Prior Pending Location 80 PL C 2 Accommodation Code 250 CE O 3 Admit Reason 250 CE O 4 Transfer Reason 250 CE O 5 Patient Valuables 25 ST O Y 6 Patient Valuables Location 25 ST O 7 Visit User Code 2 IS O Y Table 206 8 Expected Admit Date/Time 26 TS O 9 Expected Discharge 26 TS O Date/Time 10 Estimated Length of 3 NM O Inpatient Stay 11 Actual Length of Inpatient 3 NM O Stay Electronic Pharmaceutical Messaging Standard v1 November 2008 188 Seq Element name Len Type Opt Rpt Table 12 Visit Description 50 ST O 13 Referral Source Code 250 XCN O Y 14 Previous Service Date 8 DT O 15 Employment Illness 1 ID O Table 34 Related Indicator 16 Purge Status Code 1 IS O Table 207 17 Purge Status Date 8 DT O 18 Special Programme Code 2 IS O 19 Retention Indicator 1 ID O 20 Expected Number of 1 NM O Insurance Plans 21 Visit Publicity Code 1 IS O Table 34 22 Visit Protection Indicator 1 ID O Table 34 23 Clinic Organisation Name 250 XON O Y 24 Patient Status Code 2 IS O 25 Visit Priority Code 1 IS O Table 208 26 Previous Treatment Date 8 DT O 27 Expected Discharge 2 IS X Disposition 28 Signature on File Date 8 DT O 29 First Similar Illness Date 8 DT O 30 Patient Charge Adjustment 250 CE O Code 31 Recurring Service Code 2 IS O 32 Billing Media Code 1 ID O 33 Expected Surgery Date and 26 TS O Time 34 Military Partnership Code 1 ID X 35 Military Non-Availability 1 ID X Code 36 Newborn Baby Indicator 1 ID O 37 Baby Detained Indicator 1 ID O Electronic Pharmaceutical Messaging Standard v1 November 2008 189 Seq Element name Len Type Opt Rpt Table 38 Mode of Arrival Code 250 CE O Table 209 39 Recreational Drug Use 250 CE O Y Table 210 Code 40 Admission Level of Care 250 CE O Table 211 Code 41 Precaution Code 250 CE O Y Table 212 42 Patient Condition Code 250 CE O Table 213 43 Living Will Code 2 IS O Table 214 44 Organ Donor Code 2 IS O Table 215 45 Advance Directive Code 250 CE O Y Table 216 46 Patient Status Effective 8 DT O Date 47 Expected Leave of 26 TS C Absence Return Date/Time 48 Expected Pre-admission 26 TS O Testing Date/Time 49 Notify Clergy Code 20 IS O Y Table 205: HL7 Attribute Table PV2 – Patient Visit Additional Information 9.17.1 PV2-1 Prior Pending Location This field is required for cancel pending transfer (A26) messages. In all other events it is optional. 9.17.2 PV2-2 Accommodation Code This field indicates the specific accommodations for this patient visit. 9.17.3 PV2-3 Admit Reason This field contains the short description of the reason for patient admission. 9.17.4 PV2-4 Transfer Reason This field contains the short description of the reason for a patient location change. 9.17.5 PV2-5 Patient Valuables This field contains the short description of patient valuables checked in during admission. 9.17.6 PV2-6 Patient Valuables Location This field indicates the location of the patient’s valuables. Electronic Pharmaceutical Messaging Standard v1 November 2008 190 9.17.7 PV2-7 Visit User Code This field further categorises a patient’s visit with respect to an individual institution’s needs, and is expected to be site-specific. Refer to the table below: Value Description TE Teaching HO Home MO Mobile Unit PH Phone Table 206: HL7 User Defined Table 0130 – Visit User Code 9.17.8 PV2-8 Expected Admit Date/Time This field contains the date and time that the patient is expected to be admitted. This field is also used to reflect the date/time of an outpatient/emergency patient registration. 9.17.9 PV2-9 Expected Discharge Date/Time This field contains the date and time that the patient is expected to be discharged. This field is also used to reflect the anticipated discharge date/time of an outpatient/emergency patient, or an inpatient. It may be used by ancillaries to determine projected workloads more accurately. 9.17.10 PV2-10 Estimated Length of Inpatient Stay This field contains the estimated length of inpatient stay, in days. 9.17.11 PV2-11 Actual Length of Inpatient Stay This field contains the actual length of inpatient stays, in days. The actual length of the inpatient stay may not be calculable from the admission and discharge dates because of possible leaves of absence. 9.17.12 PV2-12 Visit Description This field contains a brief user-defined description of the visit. 9.17.13 PV2-13 Referral Source Code This field contains the name and the identification numbers of the person or organisation that made the referral. This person/organisation is not the same as the referring practitioner. 9.17.14 PV2-14 Previous Service Date This field contains the date of previous service for the same recurring condition. This may be a required field for billing around certain illnesses (e.g. accident related), to a third party. 9.17.15 PV2-15 Employment Illness Related Indicator This field specifies whether a patient’s illness was job-related. Refer to Table 34. Electronic Pharmaceutical Messaging Standard v1 November 2008 191 9.17.16 PV2-16 Purge Status Code This field contains the purge status code for the account. It is used by the application programme to determine purge processing. Refer to the table below: Value Description P Marked for purge. User is no longer able to update the visit. D The visit is marked for deletion and the user shall not enter new data against it I The visit is marked inactive and the user shall not enter new data against it Table 207: HL7 User Defined Table 0213 – Purge Status Code 9.17.17 PV2-17 Purge Status Date This field contains the date on which the data will be purged from the system. 9.17.18 PV2-18 Special Programme Code This field designates the specific health insurance programme for a visit required for health care reimbursement. For example, “Child Health Assistance”, “Elective Surgery Programme”, “Family Planning”, etc. 9.17.19 PV2-19 Retention Indicator This field allows the user to control the financial and demographic purge processes at the visit. It is used to preserve demographic and financial data on specific, high priority visits. 9.17.20 PV2-20 Expected Number of Insurance Plans This field contains the number of insurance plans that may provide coverage for this visit. 9.17.21 PV2-21 Visit Publicity Code This field contains a user-defined code indicating what level of publicity is allowed (e.g. “No Publicity”, “Family Only”), for a specific visit. Refer to Table 34 for values. 9.17.22 PV2-22 Visit Protection Indicator This field identifies the patient’s protection. This determines, in turn, whether access to information about this patient should be kept from unauthorised users, for a specific visit. Refer to Table 34 for values. 9.17.23 PV2-23 Clinic Organisation Name This field contains the organisation name or sub-unit and identifier associated with the (visit) episode of care. 9.17.24 PV2-24 Patient Status Code This field indicates the status of the episode of care. Electronic Pharmaceutical Messaging Standard v1 November 2008 192 9.17.25 PV2-25 Visit Priority Code This field identifies the priority of the visit. Refer to the table below: Value Description 1 Emergency 2 Urgent 3 Elective Table 208: HL7 User Defined Table 0217 – Visit Priority Code 9.17.26 PV2-26 Previous Treatment Date This field contains the date that the patient last had treatment for any condition prior to this visit. 9.17.27 PV2-28 Signature On File Date This field contains the date on which a signature was obtained for insurance billing purposes. 9.17.28 PV2-29 First Similar Illness Date This field is used to determine if the patient has a pre-existing condition. 9.17.29 PV2-30 Patient Charge Adjustment Code This field contains a user-defined code indicating any adjustments that should be made to this patient’s charges. 9.17.30 PV2-31 Recurring Service Code This field indicates whether the treatment is continuous. 9.17.31 PV2-32 Billing Media Code This field indicates if the account is to be rejected from tape billing. 9.17.32 PV2-33 Expected Surgery Date and Time This field contains the date and time on which the surgery is expected to occur. 9.17.33 PV2-36 Newborn Baby Indicator This field indicates whether the patient is a baby. 9.17.34 PV2-37 Baby Detained Indicator This field indicates if the baby is being detained after the mother’s discharge. 9.17.35 PV2-38 Mode of Arrival Code Identifies how the patient was brought to the health care facility. Refer to the table below: Electronic Pharmaceutical Messaging Standard v1 November 2008 193 Value Description A Ambulance C Car F On foot H Helicopter P Public transport O Other U Unknown Table 209: HL7 User Defined Table 0430 – Mode of Arrival Code 9.17.36 PV2-39 Recreational Drug Use Code This field indicates what recreational drugs the patient uses. It is used for the purpose of room assignment. Refer to the table below: Value Description A Alcohol K Kava M Marijuana T Tobacco – smoked C Tobacco – chewed O Other U Unknown Table 210: HL7 User Defined Table 0431 – Recreational Drug Use Code 9.17.37 PV2-40 Admission Level of Care Code This field indicates the acuity level assigned to the patient at the time of admission. Refer to the table below: Value Description AC Acute CH Chronic CO Comatose CR Critical IM Improved MO Moribund Table 211: HL7 User Defined Table 0432 – Admission Level of Care Code Electronic Pharmaceutical Messaging Standard v1 November 2008 194 9.17.38 PV2-41 Precaution Code This field indicates non-clinical precautions that need to be taken with the patient. Refer to the table below: Value Description A Aggressive B Blind C Confused D Deaf I On IV P Paraplegic O Other U Unknown Table 212: HL7 User Defined Table 0433 – Precaution Code 9.17.39 PV2-42 Patient Condition Code This field indicates the patient’s current medical condition for the purpose of communicating with non- medical outside parties, e.g. family, employer, religious minister, media, etc. Refer to the table below: Value Description A Satisfactory C Critical P Poor O Other U Unknown Table 213: HL7 User Defined Table 0434 – Patient Condition Code 9.17.40 PV2-43 Living Will Code This field indicates whether or not the patient has a living will and if so, whether a copy of the living will is on file at the health care facility. If the patient does not have a living will, the value of this field indicates whether the patient was provided with information on living wills. Refer to the table below: Value Description Y Yes, patient has a living will and it is on file F Yes, patient has a living will but it is not on file N No, patient does not have a living will and no information was provided Electronic Pharmaceutical Messaging Standard v1 November 2008 195 Value Description I No, patient does not have a living will but information was provided U Unknown Table 214: HL7 User Defined Table 0315 – Living Will Code 9.17.41 PV2-44 Organ Donor Code This field indicates whether the patient wants to donate his/her organs and whether an organ donor card or similar documentation is on file with the health care organisation. Refer to the table below: Value Description Y Yes, patient is a documented donor and documentation is on file F Yes, patient is a documented donor, but documentation is not on file N No, patient has not agreed to be a donor I No, patient is not a documented donor, but information was provided R Patient leaves organ donation decision to relatives P Patient leaves organ donation decision to a specific person U Unknown Table 215: HL7 User Defined Table 0316 – Organ Donor Code 9.17.42 PV2-45 Advance Directive Code This field indicates the patient’s instructions to the health care facility: Value Description Y Yes, patient has an Advance Directive and it is on file F Yes, patient has an Advance Directive and it is not on file N No, patient does not have an Advance Directive and no information has been provided I No, patient does not have an Advance Directive but information was provided U It is not known if the patient has an Advance Directive Table 216: HL7 User Defined Table 0435 – Advance Directive Code 9.17.43 PV2-46 Patient Status Effective Date This field indicates the effective date for PV2-24 (patient status field). 9.17.44 PV2-47 Expected Leave of Absence Return Date/Time This field contains the date/time that the patient is expected to return from LOA. This field, when populated, is associated with a number of event triggers. These include A21 Patient Goes on Leave of Absence; A22 Electronic Pharmaceutical Messaging Standard v1 November 2008 196 Patient Returns from LOA; A53 Cancel LOA for a Patient; and A54 Cancel Patient Returns from LOA. A full list of event types can be found in Table B 2. 9.17.45 PV2-48 Expected Preadmission Testing Date/Time This field contains the date/time that the patient is expected for pre-admission testing. 9.18 QAK – Query Acknowledgment Segment The QAK segment contains information sent with responses to a query. Although the QAK segment is required in the responses to the enhanced queries, it may appear as an optional segment placed after the (optional) ERR segment in any query response (message) to any original mode query. Seq Element Name Len Type Opt Rpt Table 1 Query Tag 32 ST C 2 Query Response Status 2 ID O Table 218 3 Message Query Name 250 CE O 4 Hit Count 10 NM O 5 This payload 10 NM O 6 Hits remaining 10 NM O Table 217: HL7 Attribute Table QAK – Query Acknowledgment 9.18.1 QAK-1 Query Tag This field may be valued by the initiating system to identify the query and may be used to match response messages to the originating query. If it is valued, the responding system is required to echo it back as the first field in the query acknowledgment segment (QAK). 9.18.2 QAK-2 Query Response Status This field allows the responding system to return a precise response status. It is especially useful in the case where no data is found that matches the query parameters, but where there is also no error. Value Description OK Data found, no errors (this is the default) NF No data found, no errors AE Application error AR Application reject Table 218: HL7 Table 0208 – Query Response Status 9.18.3 QAK-3 Message Query Name This field contains the name of the query. These names are assigned by the function-specific sections of this specification. Site-specific event replay query names begin with the letter “Z”. Electronic Pharmaceutical Messaging Standard v1 November 2008 197 9.18.4 QAK-4 Hit Count Total This field, when used, contains the total number of records found by the server that matched the query. For tabular responses, this is the number of rows found. For other response types, the Conformance Statement defines the meaning of a ‘hit’. 9.18.5 QAK-5 This Payload This field, when used, contains the total number of matching records that the server sent in the current response. Where the continuation protocol is used to transmit the response in partial instalments, this number will differ from the value sent in QAK-4 Hit Count Total. 9.18.6 QAK-6 Hits Remaining This field, when used, contains the number of matching records found by the server that have yet to be sent. It is only meaningful when the server uses the continuation protocol to transmit partial responses. 9.19 QPD – Query Parameter Definition Segment The QPD segment defines the parameters of the query. Seq Element Name Len Type Opt Rpt Table 1 Message Query Name 250 CE R 2 Query Tag 32 ST C 3-n User Parameters (in successive fields) 256 varies Table 219: HL7 Attribute Table QPD – Query Parameter Definition 9.19.1 QPD-1 Message Query Name This field contains the name of the query. These names are assigned by the function-specific sections of this specification. QPD-1 is one-to-one with the Conformance Statement; it is in fact an identifier for that Conformance Statement. Site-specific query names begin with the letter “Z”. 9.19.2 QPD-2 Query Tag This field may be valued by the initiating system to identify the query, and may be used to match response messages to the originating query. If this field is valued, the responding system is required to echo it back as the first field in the query acknowledgement segment (QAK). This field differs from MSA-2 Message Control ID in that its value remains constant for each message (i.e. all continuation messages) associated with the query, whereas MSA-2 Message Control ID may vary with each continuation message, since it is associated with each individual message, not the query as a whole. 9.19.3 QPD-3 User Parameters These successive parameter fields hold the values that the client passes to the server. The client data is presented as a sequence of HL7 fields. Beginning at QPD-3 User Parameters, the remaining fields of the QPD segment carry user parameter data. Each QPD user parameter field corresponds to one parameter defined in the Conformance Statement, where the name, type, optionality and repetition of each parameter is specified. While it is understood that these parameters are usually strung Electronic Pharmaceutical Messaging Standard v1 November 2008 198 together, the user must inspect the required Conformance Statement to properly understand each parameter. Except in the QSC variant, the parameter names do not need to be stated in the query; they are understood to be positional, based on the Conformance Statement. Each parameter field may be specified in the Conformance Statement to be of any single data type, including the complex QIP and QSC types. Parameter fields in the QPD segment appear in the same order as in the Conformance Statement. 9.20 QRD – Query Definition Segment The QRD segment defines the parameters of the query. For more information, refer to HL7 v2.5, Chapter 5.10.5.3. Seq Element Name Len Type Opt Rpt Table 1 Query Date/Time 26 TS R 2 Query Format Code 1 ID R Table 221 3 Query Priority 1 ID R Table 222 4 Query ID 10 ST R 5 Deferred Response Type 1 ID X 6 Deferred Response 26 TS X Date/Time 7 Quantity Limited Request 10 CQ R Table 223 8 Who Subject Filter 250 XCN R 9 What Subject Filter 250 CE R Y Table 224 10 What Department Data Code 250 CE B Y 11 What Data Code Value Qual. 20 VR O Y 12 Query Results Level 1 ID O Table 225 Table 220: HL7 Attribute Table QRD – Query Definition 9.20.1 QRD-1 Query Date/Time The date and time the query was formed. This may be the same as MSH-7 Date Time of Message. 9.20.2 QRD-2 Query Format Code The format of the query. This implementation only uses "R" for record oriented format. Value Description D Response is in display format R Response is in record-oriented format Electronic Pharmaceutical Messaging Standard v1 November 2008 199 T Response is in tabular format Table 221: HL7 Table 0106 – Query/Response Format Code Variance to HL7: D and T values are not used in this implementation. 9.20.3 QRD-3 Query Priority This field contains the time frame in which the response is expected. In this implementation, this will be "I" for immediate processing, as per the table below. This implementation does not allow deferred processing of queries. Value Description D Deferred I Immediate Table 222: HL7 Table 0091 – Query Priority 9.20.4 QRD-4 Query ID This field contains a unique identifier for the query, assigned by the querying application, and returned intact by the responding application. It is recommended that sequential numbers be used for ease of tracking. 9.20.5 QRD-7 Quantity Limited Request The maximum quantity of records that can be accepted by the requesting system. Valid responses are numerical values (in the first component), given in the units specified in the second component. The valid values for the second component are in the table below: Value Description CH Characters LI Lines PG Pages RD Records ZO Locally defined Table 223: HL7 Table 0126 – Quantity Limited Request NOTE: The number of records may be limited by individual implementations. 9.20.6 QRD-8 Who Subject Filter This field holds information regarding the patient for whom the SIR is being searched. This implementation supports only a single instance of this field, i.e. this field must not repeat. 9.20.7 QRD-9 What Subject Filter This field describes the kind of information that is required to satisfy the request. Valid values define the type of transaction inquiry and may be extended locally during implementation. Electronic Pharmaceutical Messaging Standard v1 November 2008 200 Value Description ADV Advice/diagnosis ANU Nursing unit lookup (returns patients in beds, excluding empty beds) APN Patient name lookup APP Physician lookup ARN Nursing unit lookup (returns patients in beds, including empty beds) APM Medical record number query, returns visits for a medical record number APA Account number query, return matching visit CAN Cancel. Used to cancel a query DEM Demographics FIN Financial GID Generate new identifier GOL Goals MRI Most recent inpatient MRO Most recent outpatient NCK Network clock NSC Network status change NST Network statistic ORD Order OTH Other PRB Problems PRO Procedure RES Result RAR Pharmacy administration information RER Pharmacy encoded order information RDR Pharmacy dispense information RGR Pharmacy give information ROR Pharmacy prescription information Electronic Pharmaceutical Messaging Standard v1 November 2008 201 Value Description SAL All schedule related information, including open slots, booked slots, blocked slots SBK Booked slots on the identified schedule SBL Blocked slots on the identified schedule SOF First open slot on the identified schedule after the start date/time SOP Open slots on the identified schedule between the begin and end of the start date/time range SSA Time slots available for a single appointment SSR Time slots available for a recurring appointment STA Status VXI Vaccine Information XID Get cross-referenced identifiers Table 224: HL7 Table 0048 – What Subject Filter 9.20.8 QRD-10 What Department Data Code Variance to HL7: HL7 erroneously required this field when the QRD segment was first defined and it remains required for backwards compatibility. Since backwards compatibility is not a concern, this field is not required in this implementation. 9.20.9 QRD-11 What Data Code Value Qual. This field contains start and stop values separated by a component separator. These values constitute a window or range to further refine the inquiry. 9.20.10 QRD-12 Query Results Level This field is used to control level of detail in results. Refer to Table 225 for valid values: Value Description Comment O Order plus order status R Results without bulk text S Status only T Full results Table 225: HL7 Table 0108 – Query Results Level Electronic Pharmaceutical Messaging Standard v1 November 2008 202 9.21 QRF – Original Style Query Filter Segment The QRF segment is used with the QRD segment to further refine the content of an original style query. Seq Element Name Len Type Opt Rep Table 1 Where Subject Filter 20 ST R Y 2 When Data Start Date/Time 26 TS B 3 When Data End Date/Time 26 TS B 4 What User Qualifier 60 ST O Y 5 Other QRY Subject Filter 60 ST O Y 6 Which Date/Time Qualifier 12 ID O Y Table 227 7 Which Date/Time Status Qualifier 12 ID O Y Table 228 8 Date/Time Selection Qualifier 12 ID O Y Table 229 9 When Quantity/Timing Qualifier 60 TQ O 10 Search Confidence Threshold 10 NM O Table 226: HL7 Attribute Table QRF – Original Style Query Filter 9.21.1 QRF-1 Where Subject Filter This field identifies the department, system or subsystem to which the query pertains. This field may repeat. 9.21.2 QRF-2 When Data Start Date/Time This field has been retained for backward compatibility only. It is recommended to use QRF-9 When Quantity/Timing Qualifier. When used for backward compatibility, this field contains the dates and times equal to or following when this value should be included. 9.21.3 QRF-3 When Data End Date/Time This field has been retained for backward compatibility only. It is recommended to use QRF-9 When Quantity/Timing Qualifier. When used for backward compatibility, this field contains the dates and times equal to or following when this value should be included. 9.21.4 QRF-4 What User Qualifier This field contains an identifier to further define characteristics of the data of interest. 9.21.5 QRF-5 Other QRY Subject Filter This field contains a filter defined locally for use between two systems. This filter uses codes and field definitions that have specific meaning only to the applications and/or site involved. 9.21.6 QRF-6 Which Date/Time Qualifier This field specifies the type of date referred to in QRF-2 When Data Start Date/Time and QRF-3 When Data Electronic Pharmaceutical Messaging Standard v1 November 2008 203 End Date/Time. Refer to the values in the table below: Value Description ANY Any date/time within a range COL Collection date/time, equivalent to film or sample collection date/time ORD Order date/time RCT Specimen receipt date/time, receipt of specimen in filling ancillary (Lab) REP Report date/time, report date/time at filing ancillary (i.e. Lab) SCHED Schedule date/time Table 227: HL7 Table 0156 – Which Date/Time Qualifier 9.21.7 QRF-7 Which Date/Time Status Qualifier This field specifies the status type of objects selected in date range defined by QRF-2 When Data Start Date/Time and QRF-3 When Data End Date/Time. Value Description ANY Any status CFN Current final value, whether final or corrected COR Corrected only (no final with corrections) FIN Final only (no corrections) PRE Preliminary REP Report completion date/time Table 228: HL7 Table 0157 – Which Date/Time Status Qualifier 9.21.8 QRF-8 Date/Time Selection Qualifier This field allows the specification of certain types of values within the date/time range. Value Description 1ST First value within range ALL All values within the range LST Last value within the range REV All values within the range returned in reverse chronological order (this is the default if not otherwise specified) Table 229: HL7 Table 0158 – Date/Time Selection Qualifier Electronic Pharmaceutical Messaging Standard v1 November 2008 204 9.21.9 QRF-9 When Quantity/Timing Qualifier This field allows an interval definition to be used for specifying multiple responses to a query. With the addition of this filter, new query specifications should no longer use QRF-2 When Data Start Date/Time and QRF-3 When Data End Date/Time in future implementations. NOTE: This field is of data type TQ, which has been deprecated in v2.5. 9.21.10 QRF-10 Search Confidence Threshold This field contains a numeric value used to establish the minimum threshold match. The value instructs the responding system to return no records for patients whose “match weight” on the look-up was lower than this user-defined value. 9.22 RCP – Response Control Parameter Segment The RCP segment is used to restrict the amount of data that should be returned in response to query. Seq Element Name Len Type Opt Rpt Table 1 Query Priority 1 ID O Table 222 2 Quantity Limited Request 10 CQ O Table 223 3 Response Modality 250 CE O Table 231 4 Execution and Delivery Time 26 TS C 5 Modify Indicator 1 ID O Table 232 6 Sort-by Field 512 SRT O Y 7 Segment group inclusion 256 ID Y Table 230: HL7 Attribute Table RCP – Response Control Parameter 9.22.1 RCP-1 Query Priority This field contains the time frame in which the response is expected. Refer to Table 222 for valid values. Table values and subsequent fields specify time frames for response. 9.22.2 RCP-2 Quantity Limited Request This field contains the maximum length of the response that can be accepted by the requesting system. Valid entries are numerical values (in the first component), given in the units specified in the second component. Default is LI (lines). Refer to Table 223 for valid entries for the second component. In a segment pattern response, a line is defined as a single segment. 9.22.3 RCP-3 Response Modality This field specifies the timing and grouping of the response message(s). Refer to the table below for valid values: Electronic Pharmaceutical Messaging Standard v1 November 2008 205 Value Description R Real Time T Bolus (a series of responses sent at the same time without use of batch formatting) B Batch Table 231: HL7 Table 0394 – Response Modality 9.22.4 RCP-4 Execution and Delivery Time Specifies the time the response is to be returned. This field is only valued when RCP-1 Query Priority contains the value “D” (Deferred). 9.22.5 RCP-5 Modify Indicator This field specifies whether the subscription is new or is being modified. Refer to the table below for valid values: Value Description N New Subscription M Modified Subscription Table 232: HL7 Table 0395 – Modify Indicator 9.22.6 RCP-6 Sort-By Field For queries requesting a tabular response, this field specifies by which fields the response is to be sorted, and the order(s) in which sorting is to be performed. When the QSC variant is not in use, the values specified for the first component in this field are derived from the ColName field of the Output Specification and Commentary; see HL7 v2.4, Chapter 5.9.4.1. Each repetition of this field specifies a single sort field. Thus, the first repetition of this field specifies the primary sort field, the second repetition specifies the secondary sort field, etc. 9.22.7 RCP-7 Segment Group Inclusion Specifies those optional segment groups which are to be included in the response. Refer to the table below for values for Segment Group. This is a repeating field, to accommodate inclusion of multiple segment groups. The default for this field, Not Present, means that all relevant groups are included. NOTE: Although the codes for segment groups are taken from the table below, the exact segment level definition of a segment group (e.g. PIDG) is given only in the Conformance Statement of the query in which this segment group appears. Value Description PIDG PID group ORCG ORC group OBXG OBX group etc Table 233: HL7 Table 0391 – Segment Group Electronic Pharmaceutical Messaging Standard v1 November 2008 206 9.23 RXA – Pharmacy/Treatment Administration Segment The RXA Segment is optional in the pharmacy order segment group. Its function is to include start and end dates and other information relevant to medication administration. The table below contains a description of the relevant fields: Seq Element Name Len Type R/O Rpt Table 1 Give Sub-ID Counter 4 NM R 2 Administration Sub-ID 4 NM R Counter 3 Date/Time Start of 26 TS R Administration 4 Date/Time End of 26 TS R Administration 5 Administered Code 250 CE O Table B 11 6 Administered Amount 20 NM O 7 Administered Units 250 CE C 8 Administered Dosage Form 250 CE O 9 Administration Notes 250 CE O Y 10 Administering Provider 250 XCN O Y 11 Administered-at Location 200 LA2 C 12 Administered Per (Time 20 ST O Unit) 13 Administered Strength 20 NM O 14 Administered Strength 250 CE O Units 15 Substance Lot Number 20 ST O Y 16 Substance Expiration Date 26 TS O Y 17 Substance Manufacturer 250 CE O Y Name 18 Substance/Treatment 250 CE O Y Refusal Reason 19 Indication 250 CE O Y 20 Completion Status 2 ID O Table 235 21 Action Code-RXA 2 ID O Table 236 22 System Entry Date/Time 26 TS O Electronic Pharmaceutical Messaging Standard v1 November 2008 207 Seq Element Name Len Type R/O Rpt Table 23 Administered Drug Strength 5 NM O Volume 24 Administered Drug Strength 250 CWE O Volume Units 25 Administered Barcode 60 CWE O Identifier 26 Pharmacy Order Type 1 ID O Table 237 Table 234: HL7 Attribute Table RXA – Pharmacy/Treatment Administration Variance to HL7: For this implementation, RXA-5 and RXA-6 are optional, whereas segments RXA-5 and RXA-6 are mandatory in HL7. 9.23.1 RXA-1 Give Sub-ID Counter Use this field if matching this RXA segment to its corresponding RXG segment. If the two applications are not matching RXG and RXA segments, this field's value is zero (0). 9.23.2 RXA-2 Administration Sub-ID Counter This field starts with one (“1”) the first time that medicine/treatment is administered for this order and increases by one with each additional administration of medicine/treatment. NOTE: More than one RXA segment can be "matched" to a single RXG segment, as is the case when recording a change of the rate of administration of an IV solution. 9.23.3 RXA-3 Date/Time Start of Administration The date and time this administration commenced. If the dosage rate was changed in the case of an IV, for example, then a further RXA segment would be provided. 9.23.4 RXA-4 Date/time End of Administration (if applicable) If null, the date/time of the RXA-3 field for the start of administration is assumed. Example: RXA|0|1|20051019091500|20051019091530 9.23.5 RXA-5 Administered Code This field contains the identifier of the medical substance/treatment administered. It is equivalent to OBR-4 in function. If the substance administered is a vaccine, CVX codes may be used. Refer to Table B 11 for valid values. 9.23.6 RXA-6 - Administered Amount This field contains the amount administered. Example: RXA|0|1|20051019091500|20051019091530|43^Hep B,adult^HL70292|1..... 9.23.7 RXA-7 Administered Units This field is conditional because it is required if the administered amount code does not imply units. This Electronic Pharmaceutical Messaging Standard v1 November 2008 208 field must be in simple units that reflect the actual quantity of the substance administered. It does not include compound units. 9.23.8 RXA-8 Administered Dosage Form The dosage form indicates the manner in which the medicine/treatment is aggregated for dispensing, e.g. tablets, capsules, suppositories. In some cases, this information is implied by the dispense/give code in RXA-5 Administered Code. Use this field when the administered code does not specify the dosage form. 9.23.9 RXA-9 Administration Notes This field contains notes from the provider administering the medicine/treatment. If coded, it requires a user- defined table. If it is free text (e.g. describing a custom IV, mixture, or salve), place a null in the first component and the text in the second. Example: |^this is a free text administration note|. 9.23.10 RXA-10 Administering Provider This field contains the provider ID of the person administering the pharmaceutical/treatment. 9.23.11 RXA-11 Administered-at Location The first component contains the inpatient or outpatient location at which the drug or treatment was administered (if applicable). The default (null) value is the current census location for the patient. The table is site-specific. The first eight components have the same form as the first eight components of PV1-3 Assigned Patient Location. The final eight components replace the ninth component of PV1-3 and represent the full address specification. 9.23.12 RXA-12 Administered Per (Time Unit) This field contains the rate at which this medicine/treatment was administered as calculated by using RXA-6 Administered Amount and RXA-7 Administered Units. This field is conditional, because it is required when a treatment is administered continuously at a prescribed rate, e.g. certain IV solutions. 9.23.13 RXA-13 Administered Strength Use when RXA-5 Administered Code does not specify the strength. This is the numeric part of the strength, used in combination with RXA-14 Administered Strength Units. 9.23.14 RXA-14 Administered Strength Units Use when RXA-5 Administered Code does not specify the strength. This is the unit of the strength, used in combination with RXA-13 Administered Strength. NOTE: These units can be a "compound quantity;" i.e. the units may express a quantity per unit of time. 9.23.15 RXA-15 Substance Lot Number This field contains the lot number of the medical substance administered. NOTE: The lot number is the number printed on the label attached to the container holding the substance and on the packaging that houses the container. If the substance is a vaccine, for example, and a diluent is required, a lot number may appear on the vial containing the diluent; however, any such identifier associated with a diluent is not the identifier of interest. The substance lot number should be reported, not that of the diluent. Electronic Pharmaceutical Messaging Standard v1 November 2008 209 9.23.16 RXA-16 Substance Expiration Date This field contains the expiration date of the medical substance administered. NOTE: Vaccine expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM. 9.23.17 RXA-17 Substance Manufacturer Name This field contains the manufacturer of the medical substance administered. NOTE: For vaccines, code system MVX may be used to code this field. This field may be used if the manufacturer of the substance is not identified by the code used in RXA-5 Administered Code. 9.23.18 RXA-18 Substance/Treatment Refusal Reason This field contains the reason the patient refused the medical substance/treatment. Any entry in the field indicates that the patient did not take the substance. 9.23.19 RXA-19 Indication This field contains the identifier of the condition or problem for which the drug/treatment was prescribed. May repeat if multiple indications are relevant. 9.23.20 RXA-20 Completion Status Status of treatment administration event. Refer to the table below for valid values: Value Description CP Complete RE Refused NA Not Administered PA Partially Administered Table 235: HL7 Table 0322 – Completion Status 9.23.21 RXA-21 Action Code – RXA Status of record. The information in this field enables the use of the RXA in the vaccine messages, where a method of correcting vaccination information, transmitted with incorrect patient identifying information, is needed. Refer to the table below for valid values: Value Description A Add D Delete U Update Table 236: HL7 Table 0323 – Action Code Electronic Pharmaceutical Messaging Standard v1 November 2008 210 9.23.22 RXA-22 System Entry Date/Time Date/time the administration information was entered into the source system. This field is used to detect instances where treatment administration information is inadvertently entered multiple times, by providing a unique identification field. Under usual circumstances, this field would be provided automatically by the computer system rather than being entered by a person. 9.23.23 RXA-23 Administered Drug Strength Volume This numeric field defines the volume measurement in which the drug strength concentration is contained. 9.23.24 RXA-24 Administered Drug Strength Volume Units This field indicates the volumetric unit associated with RXA-23 Administered Drug Strength Volume. 9.23.25 RXA-25 Administered Barcode Identifier This field contains the pharmacy system's assigned barcode number for the give occurrence. The maximum length of the first component of this field is 40 characters, to allow for the maximum existing barcode length in use today. The second component contains the description of the item being coded and the third component may define the barcode type. Example: 12345678901^IV bottle^3X9 9.23.26 RXA-26 Pharmacy Order Type The Pharmacy Order Type field defines the general category of pharmacy order that may be used to determine the processing path the order will take. Refer to the table below for valid values. This field may also be used for grouping of related orders for processing and/or reports. Value Description Comment M Medication Default value. Includes, but is not limited to, tables, capsules, powders, puffs, and other non-injected/non- infused products. S IV Large Volume Solutions Includes, but is not limited to TPNs, admixtures, solutions and drips O Other solution as prescription orders Includes, but is not limited to, piggybacks and syringes Table 237: HL7 Table 0480 – Pharmacy Order Types NOTE: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed. Electronic Pharmaceutical Messaging Standard v1 November 2008 211 9.24 RXC – Pharmacy/Treatment Component Segment This segment should only be sent if the prescribed item is a specially mixed compound. In that case send one RXC segment for each component. Refer to the table below: Seq Element Name Len Type R/O Rpt Table 1 RX Component Type 1 ID R Table 239 2 Component Code 250 CE R 3 Component Amount 20 NM R 4 Component Units 250 CE R 5 Component Strength 20 NM O 6 Component Strength Units 250 CE O 7 Supplementary Code 250 CE O Y 8 Component Drug Strength 5 NM O Volume 9 Component Drug Strength 250 CWE O Volume Units Table 238: HL7 Attribute Table RXC – Pharmacy/Treatment Component 9.24.1 RXC-1 Component Type The following table contains the values for this field: Value Description A Additive component B Base component Table 239: HL7 Table 0166 – RX Component Type NOTE: this field is required. 9.24.2 RXC-2 Component Code This is the code that identifies the component in the mixture. NOTE: This field is required. 9.24.3 RXC-3 Component Amount This field identifies the amount of the component to be added to the base. If this component is the base, then it specifies the amount of base to start with. NOTE: This field is required. Electronic Pharmaceutical Messaging Standard v1 November 2008 212 9.24.4 RXC-4 Component Amount Units This field identifies the units of the value of the compound in RXC-3. NOTE: This field is required. 9.24.5 RXC-5 Component Strength Use when RXC-2 does not specify the strength. This is a numerical value for the strength. Use in combination with RXC-6. 9.24.6 RXC-6 Component Strength Units Use when RXC-2 does not specify the strength. This is a unit value for the strength. Use in combination with RXC-5. 9.24.7 RXC-7 Supplementary Code This field accommodates any codes that might be associated with pharmaceuticals or other substances used in treatment. 9.24.8 RXC-8 Component Drug Strength Volume This numeric field defines the volume measurement in which the drug strength concentration is contained. 9.24.9 RXC-9 Component Drug Strength Volume Units This field indicates the volumetric unit associated with RXC-8 Component Drug Strength Volume. 9.25 RXD – Pharmacy/Treatment Dispense Segment Seq Element Name Len Type Opt Rpt Table 1 Dispense Sub-ID Counter 4 NM R 2 Dispense/Give Code 250 CE R Table B 11 3 Date/Time Dispensed 26 TS R 4 Actual Dispense Amount 20 NM R 5 Actual Dispense Units 250 CE C 6 Actual Dosage Form 250 CE O 7 Prescription Number 20 ST R 8 Number of Refills Remaining 20 NM C 9 Dispense Notes 200 ST O Y 10 Dispensing Provider 200 XCN O Y 11 Substitution Status 1 ID O Table 241 Electronic Pharmaceutical Messaging Standard v1 November 2008 213 Seq Element Name Len Type Opt Rpt Table 12 Total Daily Dose 10 CQ O 13 Dispense-to Location 200 LA2 C 14 Needs Human Review 1 ID O Table 242 15 Pharmacy/Treatment Supplier's Special 250 CE O Y Dispensing Instructions 16 Actual Strength 20 NM O 17 Actual Strength Unit 250 CE O 18 Substance Lot Number 20 ST O Y 19 Substance Expiration Date 26 TS O Y 20 Substance Manufacturer Name 250 CE O Y 21 Indication 250 CE O Y 22 Dispense Package Size 20 NM O 23 Dispense Package Size Unit 250 CE O 24 Dispense Package Method 2 ID O Table 243 25 Supplementary Code 250 CE O Y 26 Initiating Location 250 CE O 27 Packaging/Assembly Location 250 CE O 28 Actual Drug Strength Volume 5 NM O 29 Actual Drug Strength Volume Units 250 CWE O 30 Dispense-to Pharmacy 180 CWE O 31 Dispense-to Pharmacy Address 106 XAD O 32 Pharmacy Order Type 1 ID O Table 237 33 Dispense Type 250 CWE O Table 244 Table 240: HL7 Attribute Table RXD – Pharmacy/Treatment Dispense 9.25.1 RXD-1 Dispense Sub-ID Counter This field starts with 1 the first time that medicine/treatment is delivered/dispensed for this order. It increments by one with each additional issuance. 9.25.2 RXD-2 Dispense/Give Code This field identifies the medical substance or treatment ordered, to be given to the patient; it is equivalent to OBR-4 Universal Service ID. Electronic Pharmaceutical Messaging Standard v1 November 2008 214 NOTE: The contents of RXD-2 Dispense/Give Code should be compatible with the comparable field in the RXE (RXE-2 Give Code). The RDS message refers ONLY to the dispensing of the drug or treatment by the pharmacy or treatment supplier. NOTE: NZMT codes must be used in this field once the NZMT exists. 9.25.3 RXD-3 Date/Time Dispensed This field indicates when the pharmaceutical/treatment is dispensed from the pharmacy or treatment supplier. 9.25.4 RXD-4 Actual Dispense Amount This field indicates the amount dispensed. 9.25.5 RXD-5 Actual Dispense Units This field indicates the units dispensed. The table is site-defined. This field is required if the units are not implied by the actual dispense code. If present, it overrides units implied by the actual dispense code. This must be in simple units that reflect the actual quantity of the substance dispensed. It does not include compound units. 9.25.6 RXD-6 Actual Dosage Form The dosage form indicates the manner in which the medicine/treatment is aggregated for dispensing, e.g. tablets, capsules, suppositories. Use this field when the give code and the dispense code do not specify the dosage form. 9.25.7 RXD-7 Prescription Number This field is equivalent in uniqueness to the pharmacy/treatment supplier filler order number. 9.25.8 RXD-8 Number of Refills Remaining This field is conditional, because it is required when a prescription is dispensed to an outpatient. It is not relevant to inpatient treatment orders. 9.25.9 RXD-9 Dispense Notes This field contains free text notes to the person dispensing the medicine/treatment (may include the ordering provider's original notes, as well as any notes from the formulary or the pharmacy or treatment supplier). 9.25.10 RXD-10 Dispensing Provider This field contains the provider ID of the person dispensing the pharmaceutical. 9.25.11 RXD-11 Substitution Status Refer to the following table for suggested values: Value Description N No substitute was dispensed. This is equivalent to the default (null) value. G A generic substitution was dispensed Electronic Pharmaceutical Messaging Standard v1 November 2008 215 Value Description T A therapeutic substitution was dispensed 0 No product selection indicated 1 Substitution not allowed by prescriber 2 Substitution allowed – patient requested product dispensed 3 Substitution allowed – pharmacist selected product dispensed 4 Substitution allowed – generic drug not in stock 5 Substitution allowed – brand drug dispensed as a generic 7 Substitution not allowed – brand drug mandated by law 8 Substitution allowed – generic drug not available in marketplace Table 241: HL7 Table 0167 – Substitution Status 9.25.12 RXD-12 Total Daily Dose This field contains the total daily dose being dispensed, as expressed in terms of the actual dispense units. NOTE: The next two fields are equivalent to the corresponding fields of the RXE segment. They are included (optionally) in the RXD so that it may "stand alone" as a dispense result instruction segment. 9.25.13 RXD-13 Dispense-to Location The first component (which is of PL data type with the component delimiters demoted to subcomponents), contains the inpatient or outpatient location where the drug or treatment was dispensed (if applicable). The default (null) value is the current census location for the patient. The table is site-specific. The first eight components have the same form as the first eight components of PV1-3 Assigned Patient Location. The final eight components replace the ninth component of PV1-3 and represent the full address specification. 9.25.14 RXD-14 Needs Human Review The values in the following table express meaning for this field: Values Description Y Yes – indicates that a warning is present. The application receiving the dispense order needs to warn the person dispensing/administering the drug or treatment to pay attention to the text in RXD-15. N No – indicates no warning is present. This is the equivalent default (null) value. Table 242: HL7 Table 0136 – Yes/No Indicator – Needs Human Review 9.25.15 RXD-15 Pharmacy/Treatment Supplier's Special Dispensing Instructions This field contains pharmacy or treatment supplier-generated special instructions to the provider dispensing/administering the order. Electronic Pharmaceutical Messaging Standard v1 November 2008 216 9.25.16 RXD-16 Actual Strength Use when RXD-2 Dispense/Give Code does not specify the strength. This is the numeric part of the strength, of a single dosage unit of the dispensed product, used in combination with RXD-17 Actual Strength Unit. 9.25.17 RXD-17 Actual Strength Unit Use when RXD-2 Dispense/Give Code does not specify the strength. This is the unit of the strength of a single dosage unit of the dispensed product, used in combination with RXD-16. NOTE: These units can be a "compound quantity”, i.e. the units may express a quantity per unit of time. 9.25.18 RXD-18 Substance Lot Number This field contains the lot number of the medical substance administered. NOTE: The lot number is the number printed on the label attached to the container holding the substance and on the packaging that houses the container. 9.25.19 RXD-19 Substance Expiration Date This field contains the expiration date of the medical substance administered. NOTE: Vaccine expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM^L. 9.25.20 RXD-20 Substance Manufacturer Name This field contains the manufacturer of the medical substance administered when it is a manufactured substance. NOTE: For vaccines, code system MVX may be used to code this field. This field may be used if the manufacturer of the substance is not identified by the code used in RXA-5 Administered Code. 9.25.21 RXD-21 Indication This field contains the identifier of the condition or problem for which the drug/treatment was prescribed. It may repeat if multiple indications are relevant. 9.25.22 RXD-22 Dispense Package Size This field contains the size of package to be dispensed. Units are transmitted in RXD-23. 9.25.23 RXD-23 Dispense Package Size Unit This field contains the units in which RXE-28 Dispense Package Size is denominated in terms of the advertised number of units in the manufacturers’ package, i.e. the package as it comes from the supplier. 9.25.24 RXD-24 Dispense Package Method This field contains the method by which treatment is dispensed. Refer to the following table for valid values: Value Description TR Traditional Electronic Pharmaceutical Messaging Standard v1 November 2008 217 Value Description UD Unit Dose F Floor Stock AD Automatic Dispensing Table 243: HL7 Table 0321 – Dispense Method 9.25.25 RXD-25 Supplementary Code This field accommodates the identification of any codes that might be associated with the pharmaceutical substance. 9.25.26 RXD-26 Initiating Location This field identifies the pharmacy or other treatment dispensing service (e.g. respiratory), that received the initial request. 9.25.27 RXD-27 Packaging/Assembly Location This field identifies the pharmacy which packaged/assembled the request. 9.25.28 RXD-28 Actual Drug Strength Volume This numeric field defines the volume measurement in which the drug strength concentration is contained. 9.25.29 RXD-29 Actual Drug Strength Volume Units This field indicates the volumetric unit associated with RXD-28. 9.25.30 RXD-30 Dispense-to Pharmacy This field specifies the pharmacy that will dispense the prescription. 9.25.31 RXD-31 Dispense-to Pharmacy Address This field specifies the address of the dispensing facility or the patient's location where the dispensing will occur. 9.25.32 RXD-32 Pharmacy Order Type This field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to Table 237 for allowed values. This field may also be used for grouping of related orders for processing and/or reports. NOTE: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed. 9.25.33 RXD-33 Dispense Type This is the type of dispensing event that occurred. Refer to the table below for suggested values: Electronic Pharmaceutical Messaging Standard v1 November 2008 218 Value Description B Trial Quantity Balance C Compassionate Fill N New/Renew – Full Fill P New/Renew – Part Fill Q Refill – Part Fill R Refill – Full Fill S Manufacturer Sample T Trial Quantity Z Non-Prescription Fill Table 244: HL7 User Defined Table 0484 – Dispense Type 9.26 RXE – Pharmacy/Treatment Encoded Order Segment The RXE segment details the pharmacy or treatment application's encoding of the order. It also contains several pharmacy-specific order status fields. Seq Element Name Len Type Opt Rpt Table 1 Quantity/Timing 200 TQ C 2 Give Code 250 CE R Table B 11 3 Give Amount - Minimum 20 NM R 4 Give Amount - Maximum 20 NM O 5 Give Units 250 CE R 6 Give Dosage Form 250 CE O 7 Provider's Administration Instructions 250 CE O Y 8 Deliver-to Location 200 LA1 B 9 Substitution Status 1 ID O Table 241 10 Dispense Amount 20 NM C 11 Dispense Units 250 CE C 12 Number of Refills 3 NM O 13 Ordering Provider's Authorisation Number 250 XCN C Y 14 Pharmacist/Treatment Supplier's Verifier ID 250 XCN O Y 15 Prescription Number 20 ST C Electronic Pharmaceutical Messaging Standard v1 November 2008 219 Seq Element Name Len Type Opt Rpt Table 16 Number of Refills Remaining 20 NM C 17 Number of Refills/Doses Dispensed 20 NM C D/T of Most Recent Refill or Dose 18 Dispensed 26 TS C 19 Total Daily Dose 10 CQ C 20 Needs Human Review 1 ID O Table 242 Pharmacy/Treatment Supplier's Special 21 Dispensing Instructions 250 CE O Y 22 Give Per (Time Unit) 20 ST C 23 Give Rate Amount 6 ST O 24 Give Rate Units 250 CE O 25 Give Strength 20 NM O 26 Give Strength Units 250 CE O 27 Give Indication 250 CE O Y 28 Dispense Package Size 20 NM O 29 Dispense Package Size Unit 250 CE O Table 247 30 Dispense Package Method 2 ID O Table 243 31 Supplementary Code 250 CE O Y 32 Original Order Date/Time 26 TS O 33 Give Drug Strength Volume 5 NM O 34 Give Drug Strength Volume Units 250 CWE O 35 Controlled Substance Schedule 60 CWE O 36 Formulary Status 1 ID O Table 248 37 Pharmaceutical Substance Alternative 60 CWE O Y 38 Pharmacy of Most Recent Fill 250 CWE O 39 Initial Dispense Amount 250 NM O 40 Dispensing Pharmacy 250 CWE O 41 Dispensing Pharmacy Address 250 XAD O 42 Deliver-to Patient Location 80 PL O 43 Deliver-to Address 250 XAD O Electronic Pharmaceutical Messaging Standard v1 November 2008 220 Seq Element Name Len Type Opt Rpt Table 44 Pharmacy Order Type 1 ID O Table 237 Table 245: HL7 Attribute Table RXE – Pharmacy/Treatment Encoded Order 9.26.1 RXE-1 Quantity/Timing At the time of publication, this field is retained for community messaging. Refer to TQ1 and TQ2 segments for use in a hospital setting. Variance to HL7: This field is retained for backward compatibility only in HL7. 9.26.2 RXE-2 Give Code This field identifies the medical substance or treatment that has been ordered to be given to the patient, as encoded by the pharmacy or treatment supplier; it is equivalent to OBR-4 Universal Service ID in function. In the RXE segment, this give code must be fully encoded. The coding system used is conditional on both the nature of the medical substance or treatment ordered and site-specific implementation considerations. For vaccines, refer to Table B 11. For non-vaccine products, the coding system may be a local implementation. Refer to Table 246 for allowed values. NOTE: NZMT codes must be used in this field once the NZMT exists. Value Description No suggested values Table 246: HL7 User Defined Table 0479 9.26.3 RXE-3 Give Amount – Minimum This field contains the ordered amount as encoded by the pharmacy or treatment supplier. In a variable dose order, this is the minimum ordered amount. In a non-varying dose order, this is the exact amount of the order. NOTE: This field is not a duplication of the first component of the quantity/timing field, since in non- pharmacy/treatment orders, that component can be used to specify multiples of an ordered amount. 9.26.4 RXE-4 Give Amount – Maximum In a variable dose order, this is the maximum ordered amount. In a non-varying dose, this field is not used. 9.26.5 RXE-5 Give Units This field contains the units for the give amount as encoded by the pharmacy or treatment (e.g. respiratory therapy) application. NOTE: These units can be a "compound quantity"; i.e. the units may contain the word "per". A table of standard units that contains compound units is needed. Until such a table is agreed on, a user defined table is needed for each site. 9.26.6 RXE-6 Give Dosage Form The dosage form indicates the manner in which the medicine or treatment is aggregated for dispensing, e.g. Electronic Pharmaceutical Messaging Standard v1 November 2008 221 tablets, capsules, suppositories. In some cases, this information is implied by the give code in RXE-2. NOTE: Use the RXE-6 Give Dosage Form when the give code does not specify the dosage form. 9.26.7 RXE-7 Provider's Administration Instructions This field contains the ordering provider's instructions to the patient or the provider administering the drug or treatment. If coded, a user defined table must be used; if free text (e.g. describing a custom IV, mixture, or salve), place the text in the second component. 9.26.8 RXE-8 Deliver-to Location This field is retained for backward compatibility only. Refer to RXE-40, RXE- 41, RXE-42 and RXE-43. 9.26.9 RXE-9 Substitution Status If a substitution has been made, and a record of the original requested give code (RXO-1 Requested Give Code) is needed, the optional RXO segment can be included in the RDE message. Refer to Table 241 for valid values. 9.26.10 RXE-10 Dispense Amount This field contains the amount to be dispensed, as encoded by the pharmacy or treatment supplier. 9.26.11 RXE-11 Dispense Units This field contains the units for the dispense amount as encoded by the pharmacy or treatment supplier. This field is required if the units are not implied by the actual dispense code. This must be in simple units that reflect the actual quantity of the substance dispensed. It does not include compound units. 9.26.12 RXE-12 Number of Refills This field contains the total original number of refills. Outpatient only. 9.26.13 RXE-13 Ordering Provider's Authorisation Number This field is defined as conditional because it is required when the substance requested is a controlled substance (e.g. a narcotic). 9.26.14 RXE-14 Pharmacist/Treatment Supplier's Verifier ID This field contains the provider ID of the pharmacist/treatment supplier's verifier. Use if required by the pharmacy or treatment application or site on orders (or some subgroup of orders). 9.26.15 RXE-15 Prescription Number This field contains the prescription number as assigned by the pharmacy or treatment application. It is equivalent in uniqueness to the pharmacy/treatment filler order number. This is a required field in RXE when used in pharmacy/treatment messages, but it is not required when used in product experience messages 9.26.16 RXE-16 Number of Refills Remaining This field is conditional because it is required when a prescription is dispensed to an outpatient. It is not relevant to inpatient treatment orders. Electronic Pharmaceutical Messaging Standard v1 November 2008 222 9.26.17 RXE-17 Number of Refills/Doses Dispensed This field is conditional because it is required when a prescription is dispensed to an outpatient. It is not relevant to inpatient treatment orders. 9.26.18 RXE-18 D/T of Most Recent Refill or Dose Dispensed Date/time of the most recent refill or dose dispensed. 9.26.19 RXE-19 Total Daily Dose This field contains the total daily dose for this particular pharmaceutical, as expressed in terms of actual dispense units. 9.26.20 RXE-20 Needs Human Review Refer to Table 242 for valid values. 9.26.21 RXE-21 Pharmacy/Treatment Supplier's Special Dispensing Instructions This field contains the pharmacy or treatment supplier's provider-generated special instructions to the provider dispensing/administering the order. 9.26.22 RXE-22 Give Per (Time Unit) This field contains the time unit to use to calculate the rate at which the pharmaceutical is to be administered. This field is defined as conditional, because it is required when the ordered substance is to be administered continuously at a prescribed rate (e.g. certain IVs). Value Description S M H D W L T INDEF do indefinitely. The default code. Table 247: Give Per (Time Unit) values This is the same as the format specified for the DURATION component of the quantity/timing field, excluding the "X" specification. 9.26.23 RXE-23 Give Rate Amount This field contains the rate at which the substance should be administered. Electronic Pharmaceutical Messaging Standard v1 November 2008 223 9.26.24 RXE-24 Give Rate Units This field contains the units for RXE-23. May be composite. The ratio of the RXE-23 and RXE-24 defines the actual rate of administration. 9.26.25 RXE-25 Give Strength Use when RXE-2 does not specify the strength. This is the numeric part of the strength, used in combination with RXE-26. 9.26.26 RXE-26 Give Strength Units Use when RXE-2 does not specify the strength. This is the unit of the strength, used in combination with RXE-25. NOTE: These units can be a "compound quantity"; i.e. the units may express a quantity per unit of time. 9.26.27 RXE-27 Give Indication This field identifies the condition or problem for which the drug/treatment was prescribed. May repeat if multiple indications are relevant. 9.26.28 RXE-28 Dispense Package Size This field contains the size of package to be dispensed. Units are transmitted in RXE-29. 9.26.29 RXE-29 Dispense Package Size Unit This field contains the units in which RXE-28 is denominated. 9.26.30 RXE-30 Dispense Package Method This field contains the method by which treatment is dispensed. Refer to Table 243 for valid values. 9.26.31 RXE-31 Supplementary Code This field accommodates the identification of any codes that might be associated with the pharmaceutical substance. 9.26.32 RXE-32 Original Order Date/Time This field contains the date/time of the original order (ORC-9) when a refill authorisation is being requested. This was represented in the ORC-9 of the original order transaction. 9.26.33 RXE-33 Give Drug Strength Volume ( This numeric field defines the volume measurement in which the drug strength concentration is contained. 9.26.34 RXE-34 Give Drug Strength Volume Units This field indicates the volumetric unit associated with RXE-33. 9.26.35 RXE-35 Controlled Substance Schedule This field specifies the class of the drug or other substance if its usage is controlled by legislation. Refer to Pharmac Schedule. Electronic Pharmaceutical Messaging Standard v1 November 2008 224 9.26.36 RXE-36 Formulary Status This field specifies whether or not the pharmaceutical substance is part of the local formulary. Refer to following table for valid values: Value Description Y Pharmaceutical substance is in the formulary N Pharmaceutical substance is NOT in the formulary R Pharmaceutical substance is in the formulary, but restrictions apply G Pharmaceutical substance is in the formulary, but guidelines apply Table 248: HL7 Table 0478 – Formulary Status 9.26.37 RXE-37 Pharmaceutical Substance Alternative This field specifies a pharmaceutical substance that is in the formulary that could be prescribed in lieu of the substance being prescribed. In the case where the specified medicine is non-formulary, this field would contain therapeutic alternatives that are on the formulary. 9.26.38 RXE-38 Pharmacy of Most Recent Fill This field specifies the pharmacy that last filled the prescription. 9.26.39 RXE-39 Initial Dispense Amount This field specifies the quantity dispensed on the original fill (first fill) of a prescription when that amount is not the same as the quantity to be used in refills. One use case is when a new medicine is being prescribed and the prescriber wants to determine if the patient will tolerate the medicine. The prescriber indicates that the medicine should be filled for an initial amount of 30 tablets and, if tolerated, refilled using a quantity of 100 tablets. 9.26.40 RXE-40 Dispensing Pharmacy This field specifies the pharmacy that will dispense the prescription. 9.26.41 RXE-41 Dispensing Pharmacy Address This field specifies the address of the dispensing facility. 9.26.42 RXE-42 Deliver-to patient location This field specifies the location of the patient to whom the pharmaceutical substance is to be delivered. 9.26.43 RXE-43 Deliver-to Address This field specifies the address, either mailing or physical, to which the prescription should be mailed or delivered. Electronic Pharmaceutical Messaging Standard v1 November 2008 225 9.26.44 RXE-44 Pharmacy Order Type This field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to Table 237 for valid values. This field may also be used for grouping of related orders for processing and/or reports. NOTE: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed. 9.27 RXG – Pharmacy/Treatment Give Segment Seq Element Name Len Type Opt Rpt Table 1 Give Sub-ID Counter 4 NM R 2 Dispense Sub-ID Counter 4 NM O 3 Quantity/Timing 200 TQ C 4 Give Code 250 CE R Table B 11 5 Give Amount - Minimum 20 NM R 6 Give Amount - Maximum 20 NM O 7 Give Units 250 CE R 8 Give Dosage Form 250 CE O 9 Administration Notes 250 CE O Y 10 Substitution Status 1 ID O Table 241 11 Dispense-to Location 200 LA2 O 12 Needs Human Review 1 ID O Table 242 13 Pharmacy/Treatment Supplier's Special 250 CE O Y Administration Instructions 14 Give Per (Time Unit) 20 ST C 15 Give Rate Amount 6 ST O 16 Give Rate Units 250 CE O 17 Give Strength 20 NM O 18 Give Strength Units 250 CE O 19 Substance Lot Number 20 ST O Y 20 Substance Expiration Date 26 TS O Y 21 Substance Manufacturer Name 250 CE O Y 22 Indication 250 CE O Y Electronic Pharmaceutical Messaging Standard v1 November 2008 226 Seq Element Name Len Type Opt Rpt Table 23 Give Drug Strength Volume 5 NM O 24 Give Drug Strength Volume Units 250 CWE O 25 Give Barcode Identifier 60 CWE O 26 Pharmacy Order Type 1 ID O Table 237 Table 249: HL7 Attribute Table RXG – Pharmacy/Treatment Give 9.27.1 RXG-1 Give Sub-ID Counter Use if this RXG segment carries information about a single administration. This field must contain a unique number for the placer order number. This field, along with the placer order number, provides a unique reference to the specific scheduled give date/time transmitted by the pharmacy/treatment supplier for this order. If the RXG segment carries information about multiple administrations, this field's value is zero (0), since in this case a one-to-one matching with the RXA segment is ambiguous. 9.27.2 RXG-2 Dispense Sub-ID Counter This is the dispense sub-ID to which this give message is related. 9.27.3 RXG-3 Quantity/Timing At the time of publication, this field is retained for community messaging. Refer to TQ1 and TQ2 segments for use in a hospital setting. Variance to HL7: This field is retained for backward compatibility only in HL7. 9.27.4 RXG-4 Give Code This field is the identifier of the medical substance/treatment ordered to be given to the patient; it is equivalent to OBR-4 Universal Service ID in function. If the substance given is a vaccine, CVX codes may be used to code this field; refer to Table B 11. NOTE: NZMT codes must be used in this field once the NZMT exists. 9.27.5 RXG-5 Give Amount – Minimum This field contains the ordered amount as encoded by the pharmacy/treatment supplier. In a variable dose order, this is the minimum ordered amount. In a non-varying dose order, this is the exact amount of the order. NOTE: This field is not a duplication of the first component of the quantity/timing field, since in non- pharmacy/treatment orders, that component can be used to specify multiples of an ordered amount. 9.27.6 RXG-6 Give Amount – Maximum In a variable dose order, this is the maximum ordered amount. In a non-varying dose order, this field is not used. Electronic Pharmaceutical Messaging Standard v1 November 2008 227 9.27.7 RXG-7 Give Units This field contains the units for the give amount. NOTE: These units can be a "compound quantity”; i.e. the units may contain the word "per”. 9.27.8 RXG-8 Give Dosage Form The dosage form indicates the manner in which the medicine/treatment is aggregated for dispensing, e.g. tablets, capsules, suppositories. 9.27.9 RXG-9 Administration Notes This field contains notes to the person administering the medicine/treatment (may include the ordering provider's original notes, as well as any notes from the formulary or the pharmacy or treatment supplier). If coded, a user defined table must be used. If free text, place a null in the first component and the text in the second. 9.27.10 RXG-10 Substitution Status Refer to Table 241 for valid values. NOTE: The next two fields are equivalent to the corresponding fields of the RXE segment. They are included (optionally) in the RXG so that it may "stand alone" as a "give" instruction segment. 9.27.11 RXG-11 Dispense-to Location The first component contains the inpatient or outpatient location where the drug or treatment was dispensed (if applicable). The default (null) value is the current census location for the patient. 9.27.12 RXG-12 Needs Human Review Refer to Table 242 for valid values. 9.27.13 RXG-13 Pharmacy/Treatment Supplier's Special Administration Instructions This field contains pharmacy/treatment supplier-generated special instructions to the provider administering the order. 9.27.14 RXG-14 Give Per (Time Unit) This field contains the time unit to use to calculate the rate at which the pharmaceutical/treatment is to be administered. Required when relevant (e.g. certain IVs). Refer Table 247 for allowed values. 9.27.15 RXG-15 Give Rate Amount This field contains the amount (number) of substance/treatment to be administered. 9.27.16 RXG-16 Give Rate Units This field contains the units for RXG-15 Give Rate Amount. May be composite. The ratio of the RXG-15 and RXG-16 fields define the actual rate of administration. 9.27.17 RXG-17 Give Strength Use when RXG-4 does not specify the strength. This is the numeric part of the strength, used in Electronic Pharmaceutical Messaging Standard v1 November 2008 228 combination with RXG-18. 9.27.18 RXG-18 Give Strength Units Use when RXG-4 does not specify the strength. This is the unit of the strength, used in combination with RXG-17. NOTE: These units can be a "compound quantity"; i.e. the units may express a quantity per unit of time. 9.27.19 RXG-19 Substance Lot Number This field contains the lot number of the medical substance administered. NOTE: The lot number is the number printed on the label attached to the container holding the substance and on the packaging that houses the container. 9.27.20 RXG-20 Substance Expiration Date This field contains the expiration date of the medical substance administered. 9.27.21 RXG-21 Substance Manufacturer Name This field contains the manufacturer of the medical substance administered. 9.27.22 RXG-22 Indication This field contains the identifier of the condition or problem for which the drug/treatment was prescribed. May repeat if multiple indications are relevant. 9.27.23 RXG-23 Give Drug Strength Volume This numeric field defines the volume measurement in which the drug strength concentration is contained. 9.27.24 RXG-24 Give Drug Strength Volume Units This field indicates the volumetric unit associated with RXG-23. 9.27.25 RXG-25 Give Barcode Identifier This field contains the pharmacy system's assigned barcode number for the give occurrence. For IV orders, many pharmacy systems generate a barcode number to identify a specific bag/bottle of the order. This number can be an instance identifier; unique for the patient, drug combination and schedule instance, or it may be just a drug identifier. 9.27.26 RXG-26 Pharmacy Order Type This field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to Table 237 for valid values. NOTE: This field is optional for all Pharmacy transactions. When not populated, a default value of "M" is assumed. Electronic Pharmaceutical Messaging Standard v1 November 2008 229 9.28 RXO – Pharmacy/Treatment Order Segment This is the ‘master’ pharmacy/treatment order segment. It contains order data not specific to components or additives. Unlike the OBR, it does not contain status fields or other data that are results-only. Example: RXO|^Aspirin^L|100||^Mg^L|^Tab^L|^Aspirin 100 Mg Tab SIGS : 100mg, In the morning Scripts requested Stat QTY: 30^L|||G Seq Element Name Len Type R/O Rpt Table 1 Requested Give Code 250 CE C 2 Requested Give Amount Minimum 20 NM C 3 Requested Give Amount Maximum 20 NM O 4 Requested Give Units 250 CE C Table B 10 5 Requested Dosage Form 250 CE C 6 Provider’s Pharmacy/Treatment Instructions 250 CE C Y 7 Provider’s Administration Instructions 250 CE O Y 8 Deliver-to Location 200 LA1 O Table 251 9 Allow Substitutions 1 ID O Table 252 10 Requested Dispense Code 250 CE O 11 Requested Dispense Amount 20 NM O 12 Requested Dispense Units 250 CE O 13 Number of Refills 3 NM O 14 Ordering Provider’s Authorisation Number 250 XCN O Y 15 Pharmacist/Treatment Supplier’s Verifier ID 250 XCN O Y 16 Needs Human Review 1 ID O Table 242 17 Requested Give Per Time Unit 20 ST C 18 Requested Give Strength 20 NM O 19 Requested Give Strength Units 250 CE O 20 Indication 250 CE O Y 21 Requested Give Rate Amount 6 ST O 22 Requested Give Rate Units 250 CE O 23 Total Daily Dose 10 CQ C 24 Supplementary Code 250 CE O Y Electronic Pharmaceutical Messaging Standard v1 November 2008 230 Seq Element Name Len Type R/O Rpt Table 25 Requested Drug Strength Volume 5 NM O 26 Requested Drug Strength Volume Units 250 CWE O 27 Pharmacy Order Type 1 ID O Table 237 28 Dispensing Interval 20 NM O Table 250: HL7 Attribute Table RXO – Pharmacy/Treatment Order NOTE: This implementation follows HL7, in allowing for free text orders to be sent in the second component of RXO-6. If the system uses free text, then RXO-1, RXO-2 and RXO-4 should not contain values. Alternatively, if the information on the substance, amount and units are not provided in RXO-6, then RXO-1, RXO-2 and RXO-4 are required. 9.28.1 RXO-1 Requested Give Code This field contains the details of the prescribed item. This field is required if NZMT exists and the code must be taken from the NZMT. Otherwise, it is mandatory, unless the drug is identified in RXO-6, in which case it is left blank. NOTE: New Zealand Medicines Terminology (NZMT) codes must be used in this field once the NZMT exists. 9.28.2 RXO-2 Requested Give Amount – Minimum This field contains the ordered amount for this particular pharmaceutical. In a variable dose order, this is the minimum ordered amount. In a non-varying dose order, this is the exact amount of the order. The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription/treatment is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first subcomponent of RXO-6 must be blank. The Medicines Regulations 1984 (Reg 41) require that the frequency of dose must be stated on a prescription. It is preferable that this is determined by dividing the RXO-2 Requested Give Amount into the RXO-23 Total Daily Dose. To enable this, the units used in this field must be the same as the units used in RXO-23. If RXO-2 and RXO-23 fields are not used then the frequency of dose must be specified in RXO-6, in which case both may be left blank. The use of RXO-6 for free text instructions on frequency of dose is not encouraged. NOTE: This field is not a duplication of the first component of the TQ1 quantity/timing field, since in non- pharmacy/treatment orders, that component may be used to specify multiples of an ordered amount. Variance to HL7: This field is required if the frequency of dose is not specified in RXO-6. 9.28.3 RXO-3 Requested Give Amount - Maximum In a variable dose order, this is the maximum ordered amount. In a non-varying dose order, this field is not used. 9.28.4 RXO-4 Requested Give Units This field indicates the units for the give amount. This field is mandatory unless the prescription/treatment is transmitted as free text using RXO-6, in which case this field may be left blank. NOTE: These units may be a “compound quantity”; i.e. the units may contain the word “per”. Electronic Pharmaceutical Messaging Standard v1 November 2008 231 9.28.5 RXO-5 Requested Dosage Form This field indicates the physical form of the medical substance, e.g. syrup, tablets, etc. It is required when both RXO-1 and RXO-10 do not specify the form of the drug/treatment. Otherwise, this field is optional. A table of valid values will be produced as part of the New Zealand Medicines Terminology project, still under development at the time of publication. This table will be included in future releases. 9.28.6 RXO-6 - Provider's Pharmacy Treatment Instructions This field contains any instructions that the ordering provider wishes to give to the pharmacist or the non- pharmacist treatment provider, e.g. respiratory therapy. It may be either coded or free text. If transmitted as free text, place a null in the first component and the text in the second. This field may repeat as many times as necessary to communicate the instructions. The Medicines Regulations 1984 (Reg 41) require that the frequency of dose must be stated on a prescription. It is preferable that this is determined by dividing the RXO-2 Requested Give Amount into the RXO-23 Total Daily Dose. However, if these fields are not used then the frequency of dose must be specified in RXO-6. This is not encouraged but if it is transmitted as free text using RXO-6, then RXO-1, RXO-2, RXO-4 and RXO-23 may be left blank and the first component of RXO-6 must be blank. NOTE: New Zealand Medicines Terminology (NZMT) codes must be used in this field once the NZMT exists. Variance to HL7: This field is optional in HL7. In this implementation, RXO-6 should only be used for frequency of dose if this is not specified in RXO-2 and RXO-23. 9.28.7 RXO-7 - Provider’s Administration Instructions This field identifies the ordering provider’s instructions to the patient, or to the provider administering the drug or treatment. This may be either coded or free text. If transmitted as free text, place a null in the first component and the text in the second component. 9.28.8 RXO-8 Deliver-to Location The first components, modelled after the PL data type, contain the inpatient or outpatient location to which the pharmacy provider or treatment supplier will deliver the drug or treatment device (if applicable). The default (null) value is the current census location for the patient. This component has the same form as PV1- 3 Assigned Patient Location Component Type Notes Electronic Pharmaceutical Messaging Standard v1 November 2008 232 Component Type Notes
Table 251: RXO-8 Deliver-to Location Components
9.28.9 RXO-9 Allow Substitutions Refer to the table below for allowed values:
Value Description
N Substitutions are NOT authorised
G Allow generic substitutions (This is the default – null)
T Allow therapeutic substitutions
Table 252: HL7 Table 0161 – Allow Substitutions Variance to HL7: This implementation uses ‘G’ as the default value; HL7 uses ‘N’.
9.28.10 RXO-10 Requested Dispense Code This field indicates what is to be/was dispensed. It may be present in the order or not, depending on the application. If not present, and values are given for RXO-11 and RXO-12, then the RXO-1 value is assumed to apply. If RXO-10 does not include the form of the dosage, then RXO-5 is required.
9.28.11 RXO-11 Requested Dispense Amount This field specifies the amount to be dispensed.
9.28.12 RXO-12 Requested Dispense Units This field identifies the units for the dispense amount. This must be in simple units that reflect the actual quantity of the substance to be dispensed. It shall not include compound units.
9.28.13 RXO-13 Number of Refills This field defines the number of times the requested dispense amount may be given to the patient, subject to local regulation. Refers to outpatient only.
9.28.14 RXO-14 Ordering Provider’s Authorisation Number This field identifies the provider’s controlled substance number, if required, by site. It is required when the
Electronic Pharmaceutical Messaging Standard v1 November 2008 233
substance being requested is a controlled substance (e.g. a narcotic).
9.28.15 RXO-15 Pharmacist/Treatment Supplier’s Verifier ID Use if required by the pharmacy, treatment application, or site on any orders (or any subgroup of orders), in addition to ORC-11.
9.28.16 RXO-16 Needs Human Review Refer to Table 242 for valid values.
9.28.17 RXO-17 Requested Give Per (Time Unit) This field identifies the time unit to use to calculate the rate at which the pharmaceutical is to be administered.
Value Description
S
M
H
D
W
L
This field is only required when the ordered substance is to be administered continuously at a prescribed rate (e.g. certain IVs).
9.28.18 RXO-18 Requested Give Strength This field is required when RXO-1 does not specify the strength. Otherwise, it is optional.
9.28.19 RXO-19 Requested Give Strength Units This field is required when both RXO-1 and RXO-10 do not specify the strength. Otherwise, it is optional.
9.28.20 RXO-20 Indication This field identifies the condition or problem for which the drug/treatment was prescribed. It may repeat if multiple indications are relevant.
9.28.21 RXO-21 Requested Give Rate Amount This field contains the rate at which to administer a treatment.
9.28.22 RXO-22 Requested Give Rate Units This field contains the units for RXO-21.
Electronic Pharmaceutical Messaging Standard v1 November 2008 234
9.28.23 RXO-23 Total Daily Dose This field contains the total daily dose for this particular pharmaceutical as expressed in terms of actual dispensed units.
The Medicines Regulations 1984 (Reg 41) require that the frequency of use must be stated on a prescription. It is preferable that this is determined by dividing the RXO-2 Requested Give Amount into the RXO-23 Total Daily Dose. To enable this, the units used in this field must be the same as the units used in RXO-2.
If RXO-2 and RXO-23 fields are not used then the frequency must be specified in RXO-6, in which case both may be left blank. The use of RXO-6 for free text instructions on frequency of dose is not encouraged.
Variance to HL7: This field is optional in HL7 but required in this implementation if the frequency of dose is not specified in RXO-6.
9.28.24 RXO-24 Supplementary Code This field includes the identification of any codes that might be associated with the pharmaceutical substance.
9.28.25 RXO-25 Requested Drug Strength Volume This numeric field defines the volume measurement in which the drug strength concentration is contained.
9.28.26 RXO-26 Requested Drug Strength Volume Units This field indicates the volumetric unit associated with RXO-25.
9.28.27 RXO-27 Pharmacy Order Type This field defines the general category of pharmacy order which may be used to determine the processing path the order will take. Refer to Table 237 for valid values.
This field may also be used for grouping of related orders for processing and/or reports. NOTE: This field is optional for all pharmacy transactions. When not populated, a default value of "M" is assumed.
9.28.28 RXO-28 Dispensing Interval This field specifies the minimum number of days that must occur between dispensing events
Electronic Pharmaceutical Messaging Standard v1 November 2008 235
9.29 RXR – Pharmacy/Treatment Route Segment
The route information concerns how and where the pharmacy or treatment is administered.
Example: RXR|IV^Intravenous^HL70162|LUA^Left Upper Arm^HL70163|IVP^Intravenous Pump^HL70164|IVP^Intravenous Push^HL70165
Seq Element Name Len Type Opt Rpt HL7 Table
1 Route 250 CE R Table 254
2 Site 250 CWE O Table 255 Table B 12
3 Administration Device 250 CE O Table 256
4 Administration Method 250 CWE O Table 257
5 Routing Instruction 250 CE O
6 Administration Site Modifier 250 CWE O Table 258
Table 253: HL7 Attribute Table RXR – Pharmacy/Treatment Route
9.29.1 RXR-1 Route This field describes the route of administration.
Value Description Value Description
AP Apply Externally MM Mucous Membrane
B Buccal NS Nasal
DT Dental NG Nasogastric
EP Epidural NP Nasal Prongs*
ET Endotrachial Tube* NT Nasotrachial Tube
GTT Gastrostomy Tube OP Ophthalmic
GU GU Irrigant OT Otic
IMR Immerse (Soak) Body Part OTH Other/Miscellaneous
IA Intra-arterial PF Perfusion
IB Intrabursal PO Oral
IC Intracardiac PR Rectal
ICV Intracervical (uterus) RM Rebreather Mask*
ID Intradermal SD Soaked Dressing
Electronic Pharmaceutical Messaging Standard v1 November 2008 236
Value Description Value Description
IH Inhalation SC Subcutaneous
IHA Intrahepatic Artery SL Sublingual
IM Intramuscular TP Topical
IN Intranasal TRA Tracheostomy*
IO Intraocular TD Transdermal
IP Intraperitoneal TL Translingual
IS Intrasynovial UR Urethral
IT Intrathecal VG Vaginal
IU Intrauterine VM Ventimask
IV Intravenous WND Wound
MTH Mouth/Throat U Unknown
Table 254: HL7 Table 0162 – Route of Administration Variance to HL7: Code “U” has been added to the table to indicate unknown route. NOTE: * Used primarily for respiratory therapy and anaesthesia delivery.
9.29.2 RXR-2 Site This field contains the body site affected by the administration route. For backwards compatibility, refer to the table below. Otherwise use HL7 Table 0550 – Body Parts Table B 12.
Value Description Value Description
BE Bilateral Ears LVL Left Vastus Lateralis
OU Bilateral Eyes NB Nebulised
BN Bilateral Nares PA Perianal
BU Buttock PERIN Perineal
CT Chest Tube RA Right Arm
LA Left Arm RAC Right Anterior Chest
LAC Left Anterior Chest RACF Right Antecubital Fossa
LACF Left Antecubital Fossa RD Right Deltoid
LD Left Deltoid RE Right Ear
LE Left Ear REJ Right External Jugular
LEJ Left External Jugular OD Right Eye
OS Left Eye RF Right Foot
Electronic Pharmaceutical Messaging Standard v1 November 2008 237
Value Description Value Description
LF Left Foot RG Right Gluteus Medius
LG Left Gluteus Medius RH Right Hand
LH Left Hand RIJ Right Internal Jugular
LIJ Left Internal Jugular RLAQ Rt Lower Abd Quadrant
LLAQ Left Lower Abd Quadrant RLFA Right Lower Forearm
LLFA Left Lower Forearm RMFA Right Mid Forearm
LMFA Left Mid Forearm RN Right Naris
LN Left Naris RPC Right Posterior Chest
LPC Left Posterior Chest RSC Right Subclavian
LSC Left Subclavian RT Right Thigh
LT Left Thigh RUA Right Upper Arm
LUA Left Upper Arm RUAQ Right Upper Abd Quadrant
LUAQ Left Upper Abd Quadrant RUFA Right Upper Forearm
LUFA Left Upper Forearm RVL Right Vastus Lateralis
LVG Left Ventragluteal RVG Right Ventragluteal
Table 255: HL7 Table 0163 – Body Site
9.29.3 RXR-3 Administration Device This field contains the mechanical device used to aid in the administration of the drug or other treatment. Common examples are IV sets of different types.
Value Description Value Description
AP Applicator IVS Soluset
BT Buretrol MI Metered Inhaler
HL Heparin Lock NEB Nebuliser
IPPB IPPB PCA PCA Pump
IVP IV Pump
Table 256: HL7 Table 0164 - Administration Device
9.29.4 RXR-4 Administration Method This field identifies the specific method requested for the administration of the drug or treatment to the patient.
Electronic Pharmaceutical Messaging Standard v1 November 2008 238
Value Description Value Description
CH Chew PT Paint
DI Dissolve PF Perfuse
DU Dust RUB Rub
IF Infiltrate SH Shampoo
IS Insert SO Soak
IR Irrigate SU Suck
IVPB IV Piggyback SW Swallow
IVP IV Push WA Wash
NB Nebulised WI Wipe
Table 257: HL7 Table 0165 – Administration Method
9.29.5 RXR-5 Routing Instruction This field provides instructions on administration routing, especially in cases where more than one route of administration is possible.
9.29.6 RXR-6 Administration Site Modifier This field contains a modifier which modifies the meaning of RXR-2 Administration Site.
The code table used in this field is dependent upon the code table used in RXR-2 Administration Site. If RXR-2 employs HL7 Table 0550 – Body Parts, Table B 12 then this field may only be populated with values from HL7 Table 0495 – Body Parts Modifier, see table below for values. If RXR-2 employs HL7 Table 0163 – Body Site, then RXR-6 should not be populated. In the case of other code sets (e.g. SNOMED) in RXR-2, RXR-6 may only be populated if modifiers are defined within, or related to, that code set.
Value Description
ANT Anterior
BIL Bilateral
DIS Distal
EXT External
LAT Lateral
L Left
LOW Lower
MED Medial
POS Posterior
PRO Proximal
Electronic Pharmaceutical Messaging Standard v1 November 2008 239
Value Description
LLQ Quadrant, Left Lower
LUQ Quadrant, Left Upper
RLQ Quadrant, Right Lower
RUQ Quadrant, Right Upper
R Right
UPP Upper
Table 258: HL7 Table 0495 – Body Site Modifier NOTE: Only for use with HL7 Table 0550 – Body Parts. Do not use with HL7 Table 0163 – Body Site. NOTE: This field may only be populated if RXR-2 Administration Site is populated. This field is not required if RXR-2 is populated.
9.30 SFT – Software Segment
This segment provides additional information about the software product(s) used as a sending application. The primary purpose of this segment is for diagnostic use. There may be additional uses per site-specific agreements.
Seq Element Name Len Type OPT Rpt Table
1 Software Vendor Organisation 567 XON R
2 Software Certified Version or Release 15 ST R Number
3 Software Product Name 20 ST R
4 Software Binary ID 20 ST R
5 Software Product Information 1024 TX O
6 Software Install Date 26 TS O
Table 259: HL7 Attribute Table SFT – Software
9.30.1 SFT-1 Software Vendor Organisation Organisation identification information for the software vendor that created this transaction. The purpose of this field, along with the remaining fields in this segment, is to provide a more complete picture of applications that are sending HL7 messages. The Software Vendor Organisation field would allow the identification of the vendor who is responsible for maintaining the application.
Component Type Notes
Electronic Pharmaceutical Messaging Standard v1 November 2008 240
Component Type Notes
Table 260: SFT-1 Software Vendor Organisations Components
Sub-Component Type Notes
Table 261: Assigning Authority and Assigning Facility Sub Components
9.30.2 SFT-2 Software Certified Version or Release Number Latest software version number of the sending system that has been compliance tested and accepted. Software Certified Version or Release Number helps to provide a complete picture of the application that is sending/receiving HL7 messages. Versions are important in identifying a specific ‘release’ of an application. In some situations, the receiving application validates the Software Certified Version or Release Number against a list of "certified" versions/releases of the particular software, to determine if the sending application adheres to specific business rules required by the receiving application.
Alternatively, the software may perform different processing depending on the version of the sending software.
9.30.3 SFT-3 Software Product Name The name of the software product that submitted the transaction. A key component in the identification of an application is its Software Product Name. This is a key piece of information in identifying an application.
9.30.4 SFT-4 Software Binary ID Issued by a vendor for each unique software version instance to distinguish between like versions of the same software, e.g. a checksum. Software Binary IDs are issued for each unique software version instance. As such, this information helps to differentiate between differing versions of the same software. Identical Primary IDs indicate that the software is identical at the binary level (configuration settings may differ).
9.30.5 SFT-5 Software Product Information Software identification information that can be supplied by a software vendor with their transaction. Might include configuration settings, etc.
This field would contain any additional information an application provides with the transaction it has
Electronic Pharmaceutical Messaging Standard v1 November 2008 241
submitted. This information could be used for diagnostic purposes and provides greater flexibility in identifying a piece of software. Possibilities include setup or configuration parameter information. This field should not be sent unless performing diagnostics.
9.30.6 SFT-6 Software Install Date Date the submitting software was installed at the sending site.
A Software Install Date on its own can often provide key information about the behaviour of the application, it is necessary to provide a complete picture of the sending application.
9.31 TQ1 – Timing/Quantity Segment
The TQ1 segment is used to specify the complex timing of events and actions such as those that occur in order management and scheduling systems. This segment determines the quantity, frequency, priority, and timing of a service. By allowing the segment to repeat, it is possible to have service requests that vary the quantity, frequency and priority of a service request over time.
Use cases showing when TQ1 may need to repeat: (a) Cardiac enzymes STAT and then q 4 hours.
(b) Streptokinase studies, draw 1st Stat and run Stat, then draw q 4 hours and run Stat. (c) Gentamicin 100mg Now and 80mg q12h second dose (First 80mg dose) given exactly 12 hours after the 100mg dose. (Might be 2 service requests). (d) Activase 15mg bolus Stat then 50mg over 30 minutes, then 35mg over the next 60 minutes. (Might be 2 service requests). (e) Imodium 4mg (2 caps) po initially, then 2mg (1cap) after each unformed stool to a maximum of 16 mg per day. (Might be 2 service requests). (f) Zithromax 500mg (2tabs) po on the first day then 250mg (1tab) po qd for 5 days. (Might be 2 service requests). (g) Zyban (Bupropion) Start 150mg po qam x 3 days, then increase to 150mg po bid for 7 to 12 weeks. (h) Colchicine 1mg (2 tabs) po now then 1 tablet q1 to 2 hours until pain relief or undesirable side effects (Diarrhoea, GI upset). (Might be 2 service requests). (i) doxycylcine 100mg po bid on the first day then 100mg po qd. (j) scopolamine, xxx mg, 1 hour before surgery. Relative time = -1^hour, priority = P (preop), or alternately repeat pattern = P1H^Preop, 1 Hour before Surgery^99LocalCode, Relative time would be empty and priority would be P (preop).
NOTE: At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting.
Seq Element Name Len Type Opt Rep Table
1 Set ID – TQ1 4 SI O
2 Quantity 20 CQ R
3 Repeat Pattern 540 RPT R Y Table 108
4 Explicit Time 20 TM O Y
5 Relative Time and Units 20 CQ O Y
6 Service Duration 20 CQ O
7 Start Date/Time 26 TS O
Electronic Pharmaceutical Messaging Standard v1 November 2008 242
Seq Element Name Len Type Opt Rep Table
8 End Date/Time 26 TS O
9 Priority 250 CWE O Y Table 263
10 Condition Text 250 TX O
11 Text Instruction 250 TX O
12 Conjunction 10 ID C Table 264
13 Occurrence Duration 20 CQ O
14 Total Occurrences 10 NM O
Table 262: HL7 Attribute Table TQ1 – Timing/Quantity
9.31.1 TQ1-1 Set ID – TQ1 For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on.
9.31.2 TQ1-2 – Quantity This field specifies the numeric quantity of the service that should be provided at each service interval. For example, if two blood cultures are to be obtained every 4 hours, the quantity would be 2 or if three units of blood are to be typed and cross-matched, the quantity would be 3. The default value for this field is 1.
If multiple identical services are to be requested, it is strongly recommended that multiple service requests are placed; giving each service request its own unique placer/filler number.
Variance to HL7: Medicines Regulations 1984 Reg 41 require that prescriptions must state the frequency of dose. Therefore this field is required in this implementation but optional in HL7.
9.31.3 TQ1-3 Repeat Pattern The repeating frequency with which the treatment is to be administered.
This field may be repeated to build up more complex repeat patterns.
When the quantity timing specification must change to a different repeat pattern after some period of time, a new TQ1 segment must be used to show the new repeat pattern. Note that the end date of the current TQ1 will show when the current timing specification ends, and the start date of the next TQ1 shows when the new timing specification begins. The Conjunction field, TQ1-12, determines if the next TQ1 segment is to be performed sequentially or in parallel.
Variance to HL7: Medicines Regulations 1984 Reg 41 require that prescriptions must state the frequency of dose. Therefore this field is required in this implementation but optional in HL7.
9.31.4 TQ1-4 Explicit Time This field explicitly lists the actual times referenced by the code in TQ1-3. NOTE: This field is not valued if a Repeat Pattern is not present.
9.31.5 TQ1-5 Relative Time and Units This field is used to define the interval between schedules for service request or bottle records. If this field
Electronic Pharmaceutical Messaging Standard v1 November 2008 243
contains a value, it overrides any value in the explicit time interval field. The units component of the CQ data type is constrained to units of time.
9.31.6 TQ1-6 Service Duration This field contains the duration for which the service is requested.
The quantity component of this field must be a positive, non-zero number. The unit's portion of this field is constrained to units of time.
9.31.7 TQ1-7 Start Date/Time This field may be specified by the requester, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start date/time will be implied or will be defined by other fields in the service request record (e.g. urgency – STAT). In such a case, this field will be empty.
The filling service will often record a value in this field after receipt of the service request, however, and compute an end time on the basis of the start date/time for the filling service's internal use.
9.31.8 TQ1-8 End Date/Time When filled in by the requester of the service, this field should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time.
Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time.
9.31.9 TQ1-9 Priority This field describes the urgency of the request. If this field is blank, the default is R. Refer to table below for suggested values:
Value Description Comment
S Stat With highest priority
A ASAP Fill after S orders
R Routine Default
P Preop
C Callback
T Timing critical A request implying that it is critical to come as close as possible to the requested time, e.g. for a trough antimicrobial level
TS
TM
TH
TD
TW
Electronic Pharmaceutical Messaging Standard v1 November 2008 244
TL
PRN As needed
Table 263: HL7 User Defined Table 0485 – Extended Priority Codes
9.31.10 TQ1-10 Condition Text This is a free text field that describes the conditions under which the drug is to be given.
The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given.
For complex codified conditions, see the TQ2 segment below.
9.31.11 TQ1-11 Text Instruction This field is a full text version of the instruction (optional).
9.31.12 TQ1-12 Conjunction This field indicates that a second TQ1 segment is to follow. Refer to the following table ID for allowed values:
Value Description Comment
S Synchronous Do the next specification after this one (unless otherwise constrained by the following fields: TQ1-7 Start Date/Time and TQ1-8 End Date/Time). An "S" specification implies that the second timing sequence follows the first, e.g. when a service request is written to measure blood pressure Q15 minutes for the 1st hour, then every 2 hours for the next day.
A Asynchronous Do the next specification in parallel with this one (unless otherwise constrained by the following fields: TQ1-7 Start Date/Time and TQ1-8 End Date/Time). The conjunction of "A" specifies two parallel instructions, as are sometimes used in medication, e.g. prednisone given at 1 tab on Monday, Wednesday, Friday, and at 1/2 tab on Tuesday, Thursday, Saturday, Sunday.
C Actuation Time It will be followed by a completion time for the service. This code allows one to distinguish between the time and priority at which a service should be actuated (e.g. blood should be drawn) and the time and priority at which a service should be completed (e.g. results should be reported).
Table 264: HL7 Table 0472 – TQ Conjunction ID NOTE: If the TQ1 segment is repeated in the message, this field must be populated with the appropriate Conjunction code, indicating the sequencing of the following TQ1 segment.
9.31.13 TQ1-13 Occurrence Duration This field contains the duration for which a single performance of a service is requested. The quantity component of this field must be a positive, non-zero number when populated. The units component is constrained to be units of time.
Electronic Pharmaceutical Messaging Standard v1 November 2008 245
9.31.14 TQ1-14 Total Occurrences This field contains the total number of occurrences of a service that should result from this service request. If both the end date/time (TQ1-8) and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise, the number of occurrences takes precedence.
9.32 TQ2 – Timing/Quantity Relationship Segment
The TQ2 segment is used to form a relationship between the service request the TQ1/TQ2 segments are associated with and other service requests. The TQ2 segment will link the current service request with one or more other service requests.
Seq Element Name Len Type Opt Rpt Table
1 Set ID - TQ2 4 SI O
2 Sequence/Results Flag 1 ID O Table 266
3 Related Placer Number 22 EI C Y
4 Related Filler Number 22 EI C Y
5 Related Placer Group Number 22 EI C Y
6 Sequence Condition Code 2 ID C Table 267
7 Cyclic Entry/Exit Indicator 1 ID C Table 268
8 Sequence Condition Time Interval 20 CQ O
9 Cyclic Group Maximum Number of Repeats 10 NM O
10 Special Service Request Relationship 1 ID C Table 270
Table 265: HL7 Attribute Table TQ2 – Timing/Quantity Relationship
NOTE: At the time of publication, the use of TQ1 and TQ2 segments are for use in a hospital setting.
TQ2 Usage notes: (a) Cyclic placer service request groups To implement a cyclic group of four IV service requests using the parent/child paradigm, the parent specifies a custom group of IVs, and the following occurs: • TQ2 of the second child service request specifies that it follow the first child service request. • TQ2 of the third child service request specifies that it follow the second child service request. • TQ2 of the fourth child service request specifies that it follow the third service request.
To repeat the group of four child service requests in a cyclic manner, the following occurs: • TQ2 of the first child service request specifies that it is to be executed once without any dependence on the completion of other service requests. Its second execution follows the completion of the fourth service request.
This scheme allows the following to be tracked: • The status of the whole group of service requests to be reported back at the level of the parent service request.
Electronic Pharmaceutical Messaging Standard v1 November 2008 246
• The status for each individual IV service request by following the status of the corresponding child service request.
Separate service requests example: • The same group of service requests can be sent as a group of four service requests (without a common parent), linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7 method of transmitting the service request status of the group as a whole, without transmitting the status of each of the four separate service requests.
(b) Inheritance of service request status Cancellation/discontinuation/hold service request control events: • this logic implies the normal execution of the referenced predecessor service request. Thus a cancel (or discontinuation or hold) of a predecessor service request implies the cancellation (or discontinuation or hold) of all subsequent service requests in the chain. • if the referenced service request has been cancelled (or discontinued or held), the current service request inherits that same status. • in the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given service request (which can then be executed according to the specification in the TQ2 segment).
9.32.1 TQ2-1 Set ID For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on.
9.32.2 TQ2-2 Sequence/Results Flag This flag defines the sequencing relationship between the current service request, and the related service request(s) specified in this TQ2 segment. See the table below for values:
Value Description Comment
S Sequential Default value if no other value present
C Cyclical Used for indicating a repeating cycle of service requests; for example, individual intravenous solutions used in a cyclical sequence (a.k.a. "Alternating IVs"). This value would be compatible with linking separate service requests or with having all cyclical service request components in a single service request. Likewise, the value would be compatible with either Parent-Child messages or a single service request message to communicate the service requests' sequencing.
R Reserved for future use
Table 266: HL7 User Defined Table 0503 – Sequence/Results Flag
9.32.3 TQ2-3 Related Placer Number The placer numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "placer number" from the current service request. For orders, the Placer Order Number from ORC-2 is the appropriate "placer number".
Repeats of this field indicate the current service request is related to multiple service requests. NOTE: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
Electronic Pharmaceutical Messaging Standard v1 November 2008 247
9.32.4 TQ2-4 Related Filler Number The filler numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "filler number" from the current service request. For orders, the Filler Order Number from ORC-3 is the appropriate "filler number".
Repeats of this field indicate the current service request is related to multiple service requests. NOTE: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
9.32.5 TQ2-5 Related Placer Group Number The placer group numbers of the service request(s) to which this TQ2 segment links the current service request. NOTE: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
9.32.6 TQ2-6 Sequence Condition Code Defines the relationship between the start/end of the related service request(s) (from TQ2-3, TQ2-4, or TQ2- 5) and the current service request from ORC-2, 3 or 4. See table below for allowed values:
Value Description
EE End related service request(s), end current service request
ES End related service request(s), start current service request
SS Start related service request(s), start current service request
SE Start related service request(s), end current service request
Table 267: HL7 Table 0504 – Sequence Condition Code NOTE: Either this field or TQ2-10 must be present.
9.32.7 TQ2-7 Cyclic Entry/Exit Indicator Indicates if this service request is the first or last service request in a cyclic series of service requests. If null or not present, this field indicates that the current service request is neither the first or last service request in a cyclic series of service requests. Refer to table below for allowed values:
Value Description
* The first service request in a cyclic group
# The last service request in a cyclic group
Table 268: HL7 Table 0505 – Cyclic Entry/Exit Indicator NOTE: Should not be populated when TQ2-2 (Sequence/Results Flag) is not equal to a “C” (cyclic service request).
Electronic Pharmaceutical Messaging Standard v1 November 2008 248
Example Translation
...|ES|*|+10^min|... Translates to: execute this service request the first time without evaluating the condition specified in the TQ2 segment; but repeat only its execution when the specified external service request's start or finish date/time has met this condition. This specification generates a repetition of the service request for each iteration of the cycle.
Table 269: Example of TQ2 – 6, 7 & 8 Usage NOTE: This requires that the requesting application be able to specify the placer/filler/placer group number of the last service request in the cycle in the first service request's quantity/timing specification.
9.32.8 TQ2-8 Sequence Condition Time Interval Defines the interval of time between the start/end of the related service request(s) and the start/end of the current service request. The unit's component is constrained to units of time. If this field is not populated, then there should be no interruption between start/ending the current service request, and the related service request(s).
9.32.9 TQ2-9 Cyclic Group Maximum Number of Repeats The maximum number of repeats for a cyclic group.
The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first. For example, if the total number or repeats is valued at 10 and the group has already repeated 5 times, the current order will not be repeated again if either the current order, or the prior order in the cycle, has reached its end date/time.
9.32.10 TQ2-10 Special Service Request Relationship This defines an additional or alternate relationship between this service request and other service requests. Its primary intended use is for pharmacy administration service requests, but it may be useful for other domains. See table below for allowed values:
Value Description Comment
N Nurse prerogative Where a set of two or more orders exist and the nurse or other caregiver has the prerogative to choose which order will be administered at a particular point in time. For example, magnesium hydroxide PO 30 ml nocte (at bedtime) bisacodyl supp PR nocte prn docusate 100 mg capsule PO bd. The nurse would be administering magnesium hydroxide, but may add the docusate and may also give the bisacodyl Supp as needed to promote and maintain regularity.
C Compound A compound is an extempore order that may be made up of multiple drugs. For example, many hospitals have a standard item called "Pink Lady". The item is ordered that way by the physician. The extempore items will contain multiple products, such as Gaviscon, Xylocaine, etc. They will all be mixed together and will be dispensed in a single container.
T Tapering A tapering order is one in which the same drug is used, but it has a declining dosage over a number of days. For example, Dexamethasone 0.5 mg is often ordered this way. The order would look like this: Dexamethasone 0.5 mg qid (four times a day) for 2 days, then Dexamethasone 0.5 mg td (three times a day) for 2 days, then
Electronic Pharmaceutical Messaging Standard v1 November 2008 249
Value Description Comment Dexamethasone 0.5 mg bd (twice a day) for 2 days, then Dexamethasone 0.5 mg once daily for 2 days, then stop.
E Exclusive An exclusive order is an order where only one of the multiple items should be administered at any one dosage time. The nurse may chose between the alternatives, but should only give ONE of them. An example would be: promethazine 25 mg PO, IM or R q6h prn (orally, intramuscularly, or rectally every 6 hours as needed).
S Simultaneous A simultaneous order is 2 or more drugs that are ordered to be given at the same time. A common example of this would be pethidine and promethazine (promethazine is given with the pethidine to control the nausea that pethidine can cause). The order could be: pethidine 50 mg IM with promethazine 25 mg IM q4h prn (every 4 hours as needed).
Table 270: HL7 Table 0506 – Service Request Relationship NOTE: Either this field or TQ2-6 must be present.
Electronic Pharmaceutical Messaging Standard v1 November 2008 250
Appendix A – Glossary
Terms defined in this Glossary apply to both this document and the Business Process document. Not all terms are used in both documents.
Term Definition Reference
ACC Accident Compensation Corporation
ACC Identifier Alpha numeric code which is allocated to a claimant to verify claims against ACC
Administer To take, give or apply medicine, be it orally, by Medicines Act 1981 injections or by some other means, to a patient or by a patient
Administration History The timing and other details of a single patient’s past medicine administrations
Administrative Message This is a type of status message and relates to the sharing of non-clinical/administrative status information
ADR Adverse Drug Reaction
APC Annual Practicing Certificate
ARC Aged Residential Care facility
Authentication This allows one or more parties to have confidence in the identity of the other in an electronic transaction and is a way for individuals and organisations to access electronic health and disability information electronically while assisting to maintain security and privacy
Authorised Prescriber Authorised prescriber means a medical Medicines Act 1981 practitioner, registered mid-wife, or designated
prescriber
Bar-code A bar-code is a way of representing data in a machine-readable form
CARM Centre for Adverse Reactions Monitoring Group within NZ Pharmacovigilance Centre
Clinical Decision Support Clinical Decision Support Systems are "active System knowledge systems which use two or more items of patient data to generate case-specific advice".
Clinical Message This is a type of administrative message and relates to the sharing of clinical status information
Clinical Status Report- A collection of information about events during care, reported by a health care provider
Close Control Close Control is a mechanism to permit subsidised medicines to be dispensed more
Electronic Pharmaceutical Messaging Standard v1 November 2008 251
Term Definition Reference frequently than the default period permits
Collaborative Care Sharing the care of a patient in a shared collaborative manner.
Collect Patient or representative has physically taken possession of prescribed medicine
Community Pharmacy Any place under the direct supervision of a pharmacist where the practice of pharmacy occurs or where prescription orders are compounded and dispensed other than a hospital pharmacy
Community Services Community Services Cards are issued by Card (CSC) Work and Income NZ to individuals on reduced income
Conformance Statement A declaration which sets forth the name of the query supported by the server, the logical structures of the information that can be queried, and the logical structure of what can be returned
Contraindication A clinical reason not to give a medicine
Controlled Drug Certain drugs listed in the Misuse of Drugs Act Misuse of Drugs Act 1975 1975. These drugs may not be prescribed, supplied or administered other than in accordance with the Misuse of Drugs Act 1975
CPN The common person number issued from the Health Practitioner Index. Health Practitioner Index
Data Element A single piece of data, e.g. first name, last name, etc.
Data Group Collection of data elements which are related
Data Set Collection of data groups used for specific purposes.
Designated Prescriber A person, other than a medical practitioner, Medicines Act 1981 dentist or a registered midwife, who
a.) Belongs to a class of registered health professionals authorised by regulations made under the Medicines Act 1981 to prescribe any specified class or description of prescription medicines subject to the satisfaction of requirements specified in or imposed under those regulations and b.) Satisfies any applicable requirement relating to competency, qualifications, or training specified in or imposed under regulations made under the Medicines Act 1981
DHB District Health Board
Electronic Pharmaceutical Messaging Standard v1 November 2008 252
Term Definition Reference
Did Not Collect A failure to physically collect
Digital Signature A digital signature is data appended to (or a Health Network Code of Practice cryptographic transformation of) a data unit to
prove the source and integrity of the data unit and to protect against forgery
Discharge The relinquishing of patient care in whole or in part by a health care provider or organisation
Discharge Summary A collection of information, reported by a provider or organisation about events at the point of discharge
Dispensing In relation to a medicine includes, without Medicines Act 1981 limitation, a) the preparation of that medicine for sale to the public (whether in response to the issue of a prescription or a request by an individual to be supplied with the medicine); and b) the packaging, labelling, recording, and delivery of that medicine
Dose A specified quantity of a medicine prescribed to be taken at one time or at stated intervals
eClaiming An electronically enabled process for validating and administering claims for direct credit payment of subsidised services upon receipt of accurately completed documentation, within contractual timeframes that supports contract administration, payments, information reporting, auditing and counter-fraud, and patient eligibility services and other functions overseen by HealthPAC
ECP Extemporaneous Compounding of a medicine that is not commercially available In the context of pharmacy, this is where the pharmacist is required to mix or ‘compound’ the medicine in the pharmacy for the specific needs of the patient.
EHR Electronic Health Record
Emergency Supply A person who has previously been supplied Medicines Regulations 1984 with the medicine on the prescription of an authorised prescriber (except a dentist) for a particular condition, and is so sold or dispensed— (i) By a pharmacist who is satisfied that the person requires an emergency supply of the medicine for that condition; and (ii) In an amount not exceeding the quantity reasonably required by that person for a period of 72 hours, or a minimum pack of a special container from which it is not
Electronic Pharmaceutical Messaging Standard v1 November 2008 253
Term Definition Reference practicable to dispense a lesser amount
ePharmacy A holistic system of transactions governing the pharmaceutical supply chain, including Patient and clinical services, payment and electronic records administration, management and reporting and other functions
ePrescription The electronic transmission of prescription information on pharmaceutical products from legally and professionally qualified / registered health practitioners to licensed pharmacies (or dispensing system)
eSignature In relation to information in electronic form, this Electronic Transactions Act is a method used to identify a person and to (2002) indicate that person's approval of that
information
Exemption Card Refer to Pharmaceutical Subsidy Card
Facility A single physical location from which health HPI Data Set goods and/or services are provided
Filler The filler is the technical term referring to the HL7 v2.5 system that is responsible for filling the order
Filler Order Number An acceptance or receipt number from the pharmacy system to acknowledge that an order has been received and accepted
Form The description of the presentation of a medicine e.g. tablet, injection, suspension etc.
Generic drug name The chemical or approved name of a medicine as opposed to the proprietary or brand name given to a particular product
GP General Practitioner
Health Care Provider A person, facility or organisation that provides patient health care services, including services to promote health, to protect health, to prevent disease or ill-health, treatment services, nursing services, rehabilitative services or diagnostic services
Health Message An HMX manage the flow of messages to and Exchange (HMX) from parties who are participating in the business process lifecycle. Refer to 10030.1 EPharmaceutical Business Process document for detailed definition
Health Network Code of Released in 2002, amended October 2006 SNZ HB 8169:2002 Practice The Health Network Code of Practice details the security practices needed to comply with the Health Information Privacy Code for health providers and health and disability information users
Electronic Pharmaceutical Messaging Standard v1 November 2008 254
Term Definition Reference
Historical Medication Medicines a patient has been prescribed in the Profile past but is not currently taking
HL7 Health Level 7 – An Application Protocol For Electronic Data Exchange In Healthcare Environments
HMX Health Message Exchange
Hospital Specialist Health provider, recognised by MCNZ as a specialist, who works in a secondary or tertiary care facility
Health Practitioner Index The HPI provides identifiers that uniquely HPI Data Set (HPI) describe the registered practitioner, health 6 HPI Code Set care worker , delivery location and facility or organisation who authorises a health transaction
HUHC High Use Health Card
ICD-10 I10 (ICD–10 CM). A coding system based on International Classification of Diseases
IMMP Intensive Medicines Monitoring Programme Programme administered by NZ Pharmacovigilance Centre
IPD Individual Patient Dispensing
IVMP Intensive Vaccines Monitoring Programme Programme administered by NZ Pharmacovigilance Centre
JPEG (.jpeg) Joint Photographic Experts Group. A file used for photographic images
Life Cycle A periodically repeated sequence of events within a course of treatment
LOINC Logical Observation Identifiers Names and Codes. A coding system
Long Term Medication Ongoing medication the patient has been prescribed
MCNZ The Medical Council of New Zealand
Medication A treatment or therapy using medicines
Medication Chart A list of prescribed medicines that a patient is currently taking, or intended to be taking. Generally applies to a hospital, an aged care facility, a hospice, or a residential facility for mentally or physical disabled where a caregiver is responsible for managing patient medication
6 Health care workers who are not registered with an authority, but who deliver healthcare (such as social workers) are proposed to be included on the HPI in the medium to longer term.
Electronic Pharmaceutical Messaging Standard v1 November 2008 255
Term Definition Reference
Medication History History of a patient’s medication treatment or therapy using medicines
Medication Profile For the purposes of this Standard, a medication profile is a list of medicines that the patient has been prescribed, has picked up, or has taken or had administered. A full medication history may include both current medicines and historical medicines
Medical Device Any device, instrument, apparatus, or Medicines Act 1981 contrivance, including component parts and accessories thereof, that is manufactured, imported, sold, or supplied for use wholly or principally on or by one or more human beings for a therapeutic purpose; and includes bandages and other surgical dressings, except medicated dressings where the medication has a curative function that is not limited to sterilising the dressing
Medicine Medicine means any substance for Medicines Act 1981 administering to one or more human beings for a therapeutic purpose; or any substance for use as an ingredient in a medicine
Medicine Order Refer to Prescription Order
Medicines Dictionary Collection of information pertaining to a specific medicine
Medicines Encyclopaedia Extensive, clinically determined information about a specific medicine
Medicines Terminology A set of terms that provide human readable (Terminology) and computer processable (Codes) capable of identifying all drugs by active ingredients, generic and proprietary drug names, drug classification or grouping structures, and at the pack (Distribution) and individual dose (Prescribing) level
Mitte Instruction to the dispenser to provide/supply Latin term meaning send patient with ‘x’ amount, e.g. “Mitte 1/12” is to supply one months supply
Modify Where a prescriber or dispenser makes a change to the original prescription for various allowable reasons
MoH Ministry of Health
MPSO Refer PSO Practitioners Supply Order
MSD Ministry of Social Development
MWS Medical Warning System
Electronic Pharmaceutical Messaging Standard v1 November 2008 256
Term Definition Reference
National Health Index An alpha-numeric New Zealand National (NHI) Patient identifier comprising three letters and four numbers
NCCLS AUTO4 National Committee for Clinical Pharmacy Standards; the Subcommittee on System Status (AUTO4)
NZHIS New Zealand Health Information Service
NZMT New Zealand Medicines Terminology
NZNC New Zealand Nursing Council
NZPhvC New Zealand Pharmacovigilance Centre – Incorporates CARM, IMMP and national centre for monitoring adverse events IVMP associated with medicines, vaccines or any product for medicinal use
Order The request for service from which the messages are derived independent of transport mechanism In this context refer to Prescribe
Order Number This uniquely identifies the order
Owe Where the quantity supplied is less than the quantity prescribed for any given period and where the balance is to be dispensed at a further date. The ‘owe’ must be dispensed within the designated time period of the prescription
Partial dispense Where a Dispenser is unauthorised or unable to fill part of the prescription order
PHARMAC New Zealand Pharmaceutical Management Agency
Pharmacist A health practitioner who is, or is deemed to Medicines Act 1981 be, registered with the Pharmacy Council
established by the Health Practitioners Competence Assurance Act 2003 as a practitioner of the profession of pharmacy
Pharmacode The Pharmacy Guild of NZ coding system used to rationalise the ordering procedure for pharmacies throughout New Zealand. Pharmacode is a registered trademark
Pharmaceutical Subsidy The prescription exemption card given once a Health Entitlement Card Card family reaches 20 new prescriptions (items) in Regulations any given prescription year (1st Feb to 31st Jan)
Pharmacy A place where pharmacy practice is carried Medicines Act 1981 out
Pharmacy Council of NZ The Pharmacy Council is responsible for Health Practitioners
Electronic Pharmaceutical Messaging Standard v1 November 2008 257
Term Definition Reference registration of pharmacists, the setting of Competence Assurance Act standards for pharmacists’ education, scopes 2003 (HPCAA) of practice and conduct
Pharmacy Only Medicine A medicine declared by regulations, may be Medicine Act 1981 sold by retail only by a person under the supervision of a pharmacist in a pharmacy or a hospital or by a person in a shop with a licence to sell that medicine
Pharmacy Practice Includes, without limitation, the following Medicines Act 1981 a) the compounding and dispensing of prescription medicines, restricted medicines, or pharmacy only medicines: b) the supply of a medicine by a pharmacist to suit the needs of a particular person: c) the sale of prescription medicines, restricted medicines, or pharmacy only medicines
Pharmhouse Now known as Pharms DM
Pharmaceutical Claims Pharms DM contains claim and payment Data Mart (Pharms DM) information from pharmacists for subsidised dispensing that have been processed by the
HealthPAC General Transaction Processing System (jointly owned by the Ministry of Health and PHARMAC)
PHO Primary Health Organisation
PHO Enrolment Enrolment with a PHO or provider means that the person enrolling intends to use that PHO or provider as their preferred provider
Placer The placer is the system that has placed the order
Placer Group Number Used to identify a particular episode and to link all tests that comprise that episode. All tests from a particular episode should have the same placer group number. Referred to as prescription order number in this document
Placer Order Number Order reference number generated by placer
PMS Practice Management System
POD Patients own drugs (brought from home)
PSO Practitioner’s Supply Order - a written order New Zealand Pharmaceutical made by a practitioner on a form supplied by Schedule, April 2008 the Ministry of Health, or approved by HealthPAC, for the supply of community pharmaceuticals to the practitioner, which the practitioner requires to ensure medical supplies are available for emergency use, teaching and demonstration purposes, and for provision to certain patient groups where
Electronic Pharmaceutical Messaging Standard v1 November 2008 258
Term Definition Reference individual prescription is not practicable
Prescribe In medical practice, the act of authorising an order to supply or administer a substance used or capable of being used to prevent, treat, or palliate a disease, or the symptoms or effects of a disease for the purposes of clinical treatment of a patient under the authorising person’s care. The provision, by a prescriber, of a authorisation to a person under their care allowing them to receive, possess and use prescription medicines for the purposes of treating a diagnosed condition. In health sector practice, the act of authorising an order to supply, possess or administer a prescription, pharmacist-only, pharmacy or general sale medicine used or capable of being used to prevent, treat, or palliate a disease, or the symptoms or effects of a disease for the purposes of clinical treatment of a patient under the authorising person’s care
Prescription Prescriptions are legal documents written within a regulated framework to order a medicine for a patient
Prescription Item Each item on a prescription order
Prescription Item Number Each prescription item in a prescription order will be assigned a prescription item number
Prescription Life Cycle A prescription is valid for a defined period from initial creation until final dispense. After final dispense the prescription is flagged as “historical”. The length of time for which the supply/administration on a prescription is authorised
Prescription Number A unique identifier assigned to every prescription
Prescription Order A prescription is recorded in a prescription order. A prescription order can contain one or more prescription items. By definition a prescription item must meet the requirements set out in the Medicines Regulations
Prescription Order Refer to placer order number Number
Public Funded Funding derived from local or central government
READ Codes A therapeutic and diagnostic coding system designed for use in primary care
Referral The intent to transfer care of a patient, in part
Electronic Pharmaceutical Messaging Standard v1 November 2008 259
Term Definition Reference or in whole, by one health care provider to another health care provider
Referring Specialist A ‘referred To’ health care provider who is referring a patient for advice or treatment but not back into the care of the referring health care provider
Registered Midwife A health practitioner who is, or is deemed to Medicines Act 1981 be, registered with the Midwifery Council established by section 114(3) of the Health Practitioners Competence Assurance Act 2003 as a practitioner of the profession of midwifery
Repeat Prescription A prescription (both an order to supply for a pharmacist and instructions to a patient on how to administer) that contains an authorisation to dispense the medicine on more than one occasion. After the authorised number (or a set duration) has been reached, a new prescription must be obtained
Report A report is a set of one or more results and any associated interpretation usually generated in response to a request for a laboratory test or radiology examination. A report may include results previously reported and in some instances results from another request
Route a) Licensed routes - the routes by which a drug is licensed for administration to a patient b) Route of administration - the actual route of administration for a given medicine i.e. this describes which route the administered medicine should take to get into the body or into contact with the body and constitutes part of the “where” (the other part being site). It is the “way in” or the course the medicine must take to get to its destination
Rc Latin term meaning ‘seek instruction’.
Rx Prescribers write Rx in the heading of prescriptions as an instruction to the dispenser to "take" a medicine and prepare it for the patient.
Script Shortened term for prescription
Section 29 An unregistered medicine. It has an Medicines Act 1981 exemption from Ministerial Consent requirements for medicine required by medical practitioner
Sector Health and Disability Sector
SIR (Shared Information A Shared Information Repository (SIR) hold up Repository) to date information related to a patients’ history that is accessed by authorised parties
Electronic Pharmaceutical Messaging Standard v1 November 2008 260
Term Definition Reference with a need to know information related to a patient
SNOMED Systemised Nomenclature of Medicine. A coding system
Special Authority Special Authority is an application process administered by PHARMAC in which a prescriber requests government subsidy for a particular person. Once approved, the prescriber and the patient are provided a Special Authority number that must appear on the prescription
Specialist An individual administering specialist treatment or advice. A specialist cannot be a facility
Standing Order A Standing Order is a written instruction The Medicines (Standing Order) issued by a medical practitioner or dentist in Regulations 2002/373 accordance with the Medicines (Standing Order) Regulations, which authorises specified health professionals such as registered nurses and paramedics, with specified competencies, to supply and administer specified medicines in specified circumstances
Start The first step in the prescribe, dispense, administer lifecycle
Start date The intended date/ time when a medicine should start being administered to a Patient. Not necessarily the same as the prescribing date
Status The current situation
Stop Where the prescription order or a prescription item is stopped by either a prescriber or dispenser and a change is made to the medication regime
Stop date The date/ time when an intervention was/ should be ceased
System Message A message for computer system consumption that is automatically initiated by a trigger event, e.g. electronic notification receipt of a prescription order by a HMX which transmitted to the originator of the prescription order i.e. without intervention by any user.
Electronic Pharmaceutical Messaging Standard v1 November 2008 261
Appendix B – Tables
10006 HPI Code Set - Primary language Table B 1: 10006 HPI Code Set – Primary language
HL7 Table 0354 – Message Structure Table B 2: HL7 Table 0354 – Message structure
HL7 Table 0003 – Event type Table B 3: HL7 Table 0003 – Event type
HL7 Table 0076 Message type Table B 4: HL7 Table 0076 – Message type
ISO Country Codes Table B 5: Country Codes ISO 3166
HL7 Table 0074 - Diagnostic service section ID Table B 6: HL7 Table 0074 - Diagnostic service section ID
HL7 User defined Table 0006 – Religion Table B 7: HL7 User defined Table 0006 - Religion
HL7 User defined Table 0069 – Health specialty Table B 8: HL7 User defined Table 0069 – Health specialty
HPI 10006 2.1.1 Identifier type Table B 9: HPI 10006 2.1.1 Identifier type
Common ISO derived units and ISO+ extensions Table B 10: Common ISO derived units and ISO+ extensions
HL7 Table 0292 - Vaccines administered Table B 11: HL7 Table 0292 - Vaccines administered
HL7 Table 0550 – Body Parts Table B 12: HL7 Table 0550 Body Parts
HL7 User defined Table 0171 – Citizenship (Iwi affiliation) Table B 13: HL7 User defined Table 0171 - Citizenship (Iwi affiliation)
Electronic Pharmaceutical Messaging Standard v1 November 2008 262
Appendix C – Variance to HL7 v2.4 HISO Standards
The following are new Data Types or Data Type components introduced in HL7 v2.5
Data Component Name Type AUI Authorisation Information
CCD Replaces CM data type used in BLG-1, as of v 2.5.
CM Withdrawn as of v2.5
CN Withdrawn as of v2.5
CX-9 Assigning Jurisdiction
CX-10 Assigning Agency or Department
DLD Discharge to location and date
DTM Date/Time
EIP Entity Identifier Pair
ERL Error Location
LA1 Location with Address Variation 1
LA2 Location with Address Variation 2
MSG Message type
OSD Order sequence Definition
PL-10 Comprehensive Location Identifier
PL-11 Assigning Authority for Location
SPS Specimen Source
VR Value Range
XAD-13 Effective Date
XAD-14 Expiration Date
XCN-19 Effective Date
XCN-20 Expiration Date
XCN-21 Professional Suffix
XCN-22 Assigning Jurisdiction
XCN-23 Assigning Agency or Department
XON-10 Organisation Identifier
Electronic Pharmaceutical Messaging Standard v1 November 2008 263
Data Component Name Type XPN-12 Effective Date
XPN-13 Expiration Date
XPN-14 Professional Suffix
XTN-10 Extension Prefix
XTN-11 Speed Dial Number
XTN-12 Unformatted Telephone Number
Appendix C 1: New Data Type or Date Type Components for HL7 v2.5
The following table lists all the increases in the length of the Data Type:
Code Length v2.4 Length v2.5 CE 250 483
CWE 250 705
CX 250 1913
XAD 250 632
XCN 250 3002
XON 250 567
XPN 250 1103
XTN 250 850
IN1-14 250 239
MSH-3 180 227
MSH-4 180 227
MSH-5 180 227
MSH-6 180 227
PV1-37 25 47
Appendix C 2: Different Lengths between HL7 v2.4 and HL7 v2.5
The following table lists all the new segment elements introduced in HL7 v2.5 and are used in the Pharmaceutical Messaging Standard:
Code Segment Element Name ERR-10 Override Type
ERR-11 Override Reason Code
Electronic Pharmaceutical Messaging Standard v1 November 2008 264
Code Segment Element Name ERR-12 Help Desk Contact Point
ERR-2 Error Location
ERR-3 HL7 Error Code
ERR-4 Severity
ERR-5 Application Error Code
ERR-6 Application Error Parameter
ERR-7 Diagnostic Information
ERR-8 User Message
ERR-9 Inform Person Indicator
IN1-50 Signature Code
IN1-51 Signature Code Date
IN1-52 Insured’s Birth Place
IN1-53 VIP Indicator
NK1-38 Next of Kin Birth Place
NK1-39 VIP Indicator
ORC-25 Order Status Number
ORC-26 Advanced Beneficiary Notice Override Reason
ORC-27 Filler's Expected Availability Date/Time
ORC-28 Confidentiality Code
ORC-29 Order Type
ORC-30 Enterer Authorisation Mode
PID-39 Tribal Citizenship
PV2-48 Expected Pre-admission Testing Date/Time
PV2-49 Notify Clergy Code
RXA-23 Administered Drug Strength Volume
RXA-24 Administered Drug Strength Volume Units
RXA-25 Administered Barcode Identifier
RXA-26 Pharmacy Order Type
RXC-8 Component Drug Strength Volume
Electronic Pharmaceutical Messaging Standard v1 November 2008 265
Code Segment Element Name RXC-9 Component Drug Strength Volume Units
RXO-25 Requested Drug Strength Volume
RXO-26 Requested Drug Strength Volume Units
RXO-27 Pharmacy Order Type
RXO-28 Dispensing Interval
RXR-6 Administration site modifier
Appendix C 3: New Segment Components in HL7 v2.5
Segments not required in previous HISO messaging standards but re-introduced for Pharmaceutical Messaging. These are shaded green in the document.
Seq Element Name Len Type Opt Rpt IN1-10 Insured’s Group Emp ID 250 CX X Y
IN1-13 Plan Expiration Date 8 DT X
RXA-7 Administered Units 250 CE C
RXA-8 Administered Dosage Form 250 CE O
RXA-9 Administration Notes 250 CE O Y
RXA-10 Administering Provider 250 XCN O Y
RXA-11 Administered-at Location 200 LA2 C
RXA-12 Administered Per (Time Unit) 20 ST O
RXA-13 Administered Strength 20 NM O
RXA-14 Administered Strength Units 250 CE O
RXA-15 Substance Lot Number 20 ST O Y
RXA-16 Substance Expiration Date 26 TS O Y
RXA-17 Substance Manufacturer Name 250 CE O Y
RXA-18 Substance/Treatment Refusal Reason 250 CE O Y
RXA-19 Indication 250 CE O Y
RXA-20 Completion Status 2 ID O
RXA-21 Action Code-RXA 2 ID O
RXA-22 System Entry Date/Time 26 TS O
Appendix C 4: Re-introduced Segment Components
Electronic Pharmaceutical Messaging Standard v1 November 2008 266
Appendix D: - Variance to HL7 Standard version 2.5 (Informative) Variances to HL7 Standard Version 2.5 - An Application Protocol for Electronic Data Exchange in Healthcare Environments are listed below. The chapter and table numbers and segments refer to the Messaging Standard.
Chapter # Table # Difference Variance containing containing (Segment) Details Variance Variance RGV – PD1 and NK1 segments are included for New 4.4 Table 13 Administration Order Zealand specific requirements Message
RDE – Unsolicited The repeating initial ORC /OBX group has been 4.8 Table 17 Observation included to enable the inclusion of NZ specific Message requirements that are not covered by HL7
Queries for Immunisation The search capacity is extended to meet NZ 4.12 Table 21 Records (QRF specific requirements Segment)
The PID segment has been optionally added, as 4.18.1 Table 27 Query by Parameter a more rigorous identification of the patient is often required in New Zealand.
The PID segment has been optionally added, as 6.5.2 Table 38 Query Grammar a more rigorous identification of the patient is often required in New Zealand.
The extended Street Address type in the first 9.1.7.47 Table 125 XAD component is not used in New Zealand
The HL7 constrained length of the first component to 15 has been removed in New 9.7.8 IN1-10 Zealand, providing that the total length of the field is still complied with
HL7 uses values from User Defined Table 0063 9.7.12 Table 155 IN1-35 in this field
This field is optional in HL7 but required in this 9.9.4 MSH-4 implementation
This field is optional in HL7 but required in this 9.9.6 MSH-6 implementation
The character sets are restricted to ASCII and 9.9.13 Table 161 MSH-18 Unicode UTF-8 in compliance with the e-GIF New Zealand interoperability Framework
This field is optional in HL7 but required in this 9.10.2 NK1-2 implementation
This field is optional in HL7 but required in this implantation. 9.10.3 Table 163 NK1-3 HL7 uses values from User Defined Table 0063 in this field.
Electronic Pharmaceutical Messaging Standard v1 November 2008 267
Chapter # Table # Difference Variance containing containing (Segment) Details Variance Variance This implementation requires the use of Set IDs 9.11.1 NTE-1 for NTE segments
9.12.2 Table 169 OBX-2 The length of this field has been extended to 3
The length of this field is unlimited, but 9.12.5 OBX-5 consideration must be given to restrictions imposed by the message transport system.
This field is extended to ORC-1 is extended to include the code ‘IN’ for specific information 9.13.1 Table 174 ORC-1 requirements for Medications, Alerts, Family History and Accident details.
The length of this field has been extended to 50 9.13.2 ORC-2 This field is required in this implementation but is conditional in HL7
9.13.3 ORC-3 The length of this field has been extended to 50
9.13.4 ORC-4 The length of this field has been extended to 50
This field is optional in HL7 but required in this 9.13.11 ORC-12 implementation.
Code ‘C’ has been added to the table to indicate Community setting 9.13.23 Table 181 ORC-29 This is called HL7 Order Type to avoid conflict usage with existing terms used in Pharmaceutical Transaction Data Specification.
New Zealand usage allows only 3 repeats of this 9.15.7 Table 190 PID-10 field. This field is called “Race” in HL7 v2.5.
This field is optional in HL7 but required in this 9.15.8 PID-11 implementation under Medicines Regulations, Reg 41 (d) (i)
9.15.27 PID-39 This field is called Tribal Citizenship in HL7 v2.5.
9.16.10 PV1-10 This field is called Hospital Service in HL7.
HL7 uses the term ‘Transient Handicapped 9.16.15 Table 201 PV1-15 Condition’
HL7 uses values from User Defined Table 0112 9.16.22 Table 203 PV1-36 in this field.
This implementation only uses "R" value for 9.20.2 Table 221 QRD-2 record oriented format. No other values are allowed
9.20.8 QRD-10 This field is not required in this implementation.
Electronic Pharmaceutical Messaging Standard v1 November 2008 268
Chapter # Table # Difference Variance containing containing (Segment) Details Variance Variance This field is required in HL7 but optional in this 9.23.5 RXA-5 implementation
This field is required in HL7 but optional in this 9.23.6 RXA-6 implementation
This field is retained for backward compatibility 9.26.1 RXE-1 only in HL7, but required for community messaging in this implementation.
This field is retained for backward compatibility 9.27.3 RXG-3 only in HL7, but required for community messaging in this implementation.
This field is optional in HL7 but conditional in this 9.28.6 RXO-6 implementation
This implementation uses ‘G’ as the default 9.28.9 Table 252 RXO-9 value.
This field is optional in HL7 but conditional in this 9.28.21 RXO-23 implementation
Code “U” has been added to the table to indicate 9.29.1 Table 254 RXR-1 unknown route
This field is optional in HL7 but required in this 9.31.2 TQ1-2 implementation
This field is optional in HL7 but required in this 9.31.3 TQ1-3 implementation
Electronic Pharmaceutical Messaging Standard v1 November 2008 269