Home

HL7 Implementation Guide

Contents

1. mom 18 01115 Date Product Returned to TS 26 ERE ee AAA EE 19 01116 Device Operator Qualifications mp D TI 0242 20 01117 Relatedness Assessment ID D aam 21 01118 Action Taken in Response to the ID 2 0251 Event 22 01119 EventCasuality Observations ID o Of 3 Copa 23 01120 Indirect Exposure Mechanism ID D Ot UST B 1 66 PD1 Patient Additional Demographic 1 00755 LiingDpeneny I Q Ol 2 Cp 2 0072 Living Arrangement JL IS y 3 00756 Patient Primary Facility XON 90 10 0 Zh 4 00757 Patient Primary Care Provider Name XCN 90 amp ID Number 5 00745 StudentIndicator IS Q sy 6 00753 Hadep 1 pS Q 3 2 2 Q95 7 00759 Livingwil pS Q 3 Coos 8 00760 OrganDonor IS Sowo 9 00761 SepmaeBill ID Q USR 10 00762 Duplicate Patient CX Q OTI 11 00743 Publicity Indicator CE rs 12 01283 ProtectionIndicator TE ID QD CTT 0129 Page B 36 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 A
2. Name Department Date Application Extension Project Interface Mail Code Propose to HL7 Yes No Use this Z segment form to initiate the development of a new Z segment or to add data to an existing Z segment This form consists of three sections The first section is an administrative section the second section is the data section that provides a template for documenting the data and the third section is a dictionary to assist in the completion of the data section 1 Business Requirement Purpose 2 Is the data defined on an existing HL7 Segment Yes No If yes please indicate the segment s 3 Is the data defined on an existing Z Segment Yes No If yes please indicate the segment s 4 Indicate the message s the Z segment applies to and the placement of the Z segment in the message s Page A 98 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist Section 2 Data Section Segment Name Item Note Health Level Seven Implementation Support Guide Page A 99 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist DATA DEFINITIONS ATTACHED YES NO WILL BE FORWARDED SEPARATELY Dictionary The following are descriptions of the information on the segment template COLUMN NAME DESCRIPT
3. PL ss 5 01168 Contact Communication Info 1 XIN a ss 6 01170 Preferred Method of Contact CE ou I Ce Health Level Seven Implementation Support Guide Page B 9 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 7 01171 ContactIdentifiers CM 0 C jJ o Jo y B 1 23 DB1 Disability Information L3 1 01283 saD DB R SED ox s s OT 2 01284 Disabled PersonCode pS 3 01285 Disabled Identifier CX G 3 S 7 4 01286 Disabled Indicator ID D UDR 5 01287 DisabilityStartDae JL DT II 6 01288 DisabilityEndDate DT 7 01289 Disability Return to WorkDae DT II 8 01200 DisabilityUnableto Work Date DT III B 1 24 DG1 Diagnosis Information 1 095 SeID Damos PR 8 amp To HS 2 00376 Diagnosis Coding Method R o Tooo o Tooo 3 00377 Diagnosis Code pa 49 L1 999 4 00378 Diagnosis Description Sr mn A 5 00379 Diagnosis Date Time TS eo SOS SOS 6 00380 DigmossDRGTpe r s o 0 o T 7 0058 MajrDignsicCaegoy CE 9 SST s 00382 Diagnost
4. 5 SIO 49 01230 Insured DNumber R 2 1 T Ll Page B 18 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 38 IN2 Insurance Additional Information Len Max Sender Variable Receiver Variable 00472 Insured s Employee ID EA 59 00473 Insured s Social Security RTE MIETEN E AA AAA IE CP LU O A Insured s Employer Name 0047 Employer Information Data He e ie 00474 XCN 5 00476 Mail Claim Pary IS 00477 Medicare Health Ins Card Number ST 7 00478 Medicaid Case Name Teen 00479 Medicaid Case Number ST 00480 ChampusSponsorName Teen 10 00481 ChampusIDNumber ST 00482 Dependent of Champus Repnt Tee 12 00483 Champus Organization ST Q 3 13 00484 Champus Station sT III 14 00485 ChampusService LPL TL owo 15 00486 ChampusRank Grade IS oan 16 0048 ChampusStaus IS 5 142 17 00488 ChampusRetireDate DT 18 00489 ChampusNACertonFile ID D TL ue 19 00490 BabyCoverage ID D
5. 2 Luten 4 00312 Administration Method CE en UST B 1 92 SCH Schedule Activity Information Len Max Sender Variable Receiver Variable Health Level Seven Implementation Support Guide Page B 53 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 1 0080 Placer Appointment ID R EL C9 III 2 00861 Filler Appointment D OH LO II S 3 0082 Occurrence Number C NM j DD 4 00868 PlaerGrupNumer IL EH J 49 0 4 S 7 5 00864 ScheduleID LEI 6 00883 EventReason R CE e P l 7 00866 AppointmentReason CE ew P URL 8 00867 AppointmentType LI CE ew UT 9 00868 Appointment Duration pp NM QO J 9 J S 7 10 01304 Appointment Duration Units CE Q0 ss 11 00884 Appointment Timing Quantity R TO e CTT S 7 12 00874 PlacerContactPerson XCN 489 Ys 13 00875 Placer Contact Phone Numer XTN on ss 14 00876 Placer Contact Address JL XAD a II S 15 00877 PlaerConactLocaion PL 890 16 00885 FillerContactPerson R XON og ss 17 00886 FillrConactPhoe Numer XTN
6. A 56 A 4 5 15 P07 Unsolicited Initial Individual Product Experience Report PEX A 57 A 4 5 16 PUR Unsolicited Update Individual Product Experience Report PEX A 58 A 4 5 17 F09 Summary Product Experience Report SUR sese A 59 A 4 6 Master File Maintenance sss oid eee eee A 59 A 4 6 1 MEN Master Files Notification MAD MDL MUP MDC MAC REP WV ED EE A 59 A 4 6 2 MFK Master File Acknowledgment esee A 59 A 4 6 3 MED Master File Delayed ACK MFA eese A 59 A 4 6 4 MSA Message Acknowledgment sss sees eee eee ee eee A 60 A 4 6 5 MEO Master Files Query OR Y ii A A 60 A 4 6 6 MPFR Master Files Response sse eee eee eee A 60 A 4 6 7 MEN Staff and Practitioner Notification M02 sese A 60 A 4 6 8 MEN Test Observation Master File M03 sss A 61 A 4 6 9 MEN Patient Location Master File MUST sse A 61 A 4 6 10 MEN Charge Description Master File M04 sse A 61 A 4 6 11 CMA Clinical Study with Phases and Schedules M06 A 62 A 4 6 12 CMB Clinical Study without Phases but with Schedules MO6 A 62 A 4 7 Medical Records Information Management A 62 A 4 7 TOI Original Document Notification MDM A A 62 A 4 7 2 T02 Original Document Notification and Content MDM A 63 A 4 7 3 T03 Document Status Change Notification MDM ou cece eee A
7. J 7 5 00561 Observation Results C ST 65539 0 0 y 005 Units E E 7 00563 ReferenceRange ST 8 00564 AbnormalFlags ST O Come 9 00639 Probability JL NM j 9 J 7 10 00565 Nature of AbnormalTest_ ID Q2 Ofl Cem 11 00566 Observ ResultSatus R ID D Lues 12 00567 Date Last Normal Value TS Q9 0 5 13 00581 User Defined Access Checks ST e 9 9 S 14 00582 Date Time of Observation TS Ge 7 0 S 15 00583 Producer sID JL CE 60 5 0 0 S 16 00584 Responsible Observer LL SCHT 80 TI 17 00936 ObservationMethod CE 6 CTT B 1 56 ODS Dietary Orders HUERTA AI Lh SD pO 2 00270 SeviePeriod JCT 00 JOf 3 00271 Diet Supplement or Pref Code R CE 60 Z amp 2 S 4 00272 TextInstruction TST TBO Page B 30 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 57 ODT Diet Tray Instructions 1 00273 TrayType R ID 00
8. TL ue 20 00491 Combine Baby Bill ID D A4 e 9 d oo 21 00492 Blood Deductible ST QD 22 00493 Special Coverage Apprv Name XPN a LIT 23 00494 Special Coverage Apprv Tite ST e III TI 24 00495 Non CoveredIns Code IS 9 ol 25 00496 PayorID CT 9 LIT 26 00497 Payor SubscriberiD Lo 69 Jol 3 27 00498 Eligibility Source IS QD Loan 28 00499 Room Coverage Type Amount_ 1 CM Q9 Jol Loge 29 00500 Policy Type Amount_ ot 68 Jol J TI 30 00501 DalyDeutibe Loo III TI 31 00755 LivingDependeny IS Q jJ jo vn Health Level Seven Implementation Support Guide Page B 19 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 32 00145 Ambulatory Status s III TL 009 33 00129 Citizenship IS 0 I 34 00118 PrimaryLanguage CE 600 0305 TL 9 i 35 00742 Living Arrangement s 5 020 36 00743 Publicity Indicator CE 80 DIST 37 00744 Protection Indicator ID A Jp Q5 3
9. 4 00048 R U What Subject Definition CE 60 LI Com 5 0009 R U What Department Code CE 600 Os 6 00050 R UDislyPrnlos ST QO EC A3 49 4 7 7 00051 R UReulsLevl CT o j jy o 0108 Page B 58 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 99 URS Unsolicited Selection 1 00608 R U Where Subiect Def R ST CG S 9 2 00609 R U When Start Date Time TS Ass 3 00610 R U When End Date Time TS Ass 4 00611 R U What User Qualifier Cer OY 5 00612 R U Other Results Def s Qo CTT d B 1 100 VTQ Virtual Table Query Request WEE EE E EE glo eo E DN 2 00697 Query Response Format Code R ID 9 Come 3 00698 VTQueryName_ R CE 00 S 4 00609 Virtual TableName R CE 60 0 5 00700 Selection Cens B 1 101 Z Z segment Hospital specific Len Max Sender Variable Receiver Variable 1 j jDaaElmetName TE CO po Health Level Seven Implementation Support Guide Page B 59 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 2 APPLICATION INTEGRATION M
10. As stated above some applications require that the virtual circuits be created on a transient basis For those applications processing rules below show steps for creating or releasing the virtual circuits Where transient virtual circuits are used the Network Name and certain other communications parameters are determined as discussed under Network Parameter Table NPT on page ch These steps should be omitted for environments not requiring them Initiating and Responding By definition the initiating system sends the initiate message and the responding system sends back a response message Each of these messages is formatted into a single LLP data block In the usual case where there are no errors the initiating system will send a message and receive the response The responding system will receive the initiate message and send the response Initiating System Processing The following steps are performed on the initiating system which first sends a message and then receives a response 1 Accept initial message from encoding rule module and form into block 2 Optional Perform connection specific initialization based on the contents of the message header and the NPT see page cf 3 Optional Connect as required by the implementation This may require several attempts before a circuit is made if so specified in the NPT entry 4 Sendthe data block that contains the message 5 Receive the response from the responding s
11. ow 2 00100 Date Time Even R TS Q9 j 9 7 3 00101 Date Time Planned Event PTAS Rs 4 00102 EvetReasonCoe JL D 0 J 4 5 00103 OperatorID CDI j Lee 6 01278 EventOccurred TS YH Page B 12 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 32 FAC Facility 1 01262 FacilityID PREPA 2 01263 FacilityType ID D A Copa 3 01264 Facility Address R XAD Q0 ss 4 01265 Facility Telecommunication R XTN 40 III 5 01266 ConaxtPeson RN T 600 Jol o S 9 6 01267 ContactTitle ST 60 5 0 0 jp 7 01268 Contact Address LA Q0 ll S 8 01269 Contact Telecommunication XTN on TI y 9 01270 Signature Authority R xmn 600 III S 10 01271 Signature Authority Tile ST 60 III S 11 01272 Signature Authority Address XAD om III 12 01273 Signature Authority XTN 44 Telecommunication B 1 33 FHS File Header 1 00067 File Field Separators R ST 2 00068 File Encoding Characters R ST 0
12. A 71 A 4 8 25 S26 Notification that Patient Did Not Show Up for Scheduled Appointment TT A 71 A4 8 26 S25 Schedule Query SQM SOR sucio ii A 71 A49 Patient Relfertal anre Desa ie a a ence GPa Gan engi have de A 73 A 4 9 1 101 Request for Insurance Information RQURPD sese A 73 A 4 9 2 102 Request Receipt of Patient Selection Display List RQI RPL A 74 A 4 9 3 103 Request Receipt of Patient Selection List RQI RPR A 75 A 4 9 4 104 Request for Patient Demographic Data ROP IR PID sese A 76 A 4 9 5 105 Request for Patient Clinical Information RQC RCT A 77 A 4 9 6 106 RQC RCL Request Receipt of Clinical Data Listing A 78 A 4 9 7 107 Unsolicited Insurance Information PIN sss sss A 79 A 4 9 8 108 Request for Treatment Authorization Information RQA RPA A 80 A 4 9 9 109 Request for Modification to an Authorization eee A 81 A 4 9 10 I10 Request for Cancellation of an Authorization eee A 81 A 4 9 11 112 Patient Referral REE RRA ais A 82 A 4 9 12_I13 Modify Patient Referral era etic cee nnn A 83 AAO 13 114 Cancel Patient Referral ciu A 83 A4 0 14 I15 Request Patient Referral Status sese eee eee eese tort do Reuse een A 83 AT IU Patient Gare once uta ce tole de e iq std eode ds A 84 AIT PCp PC Patient Goal POL teu ien aieo eda dos A 84 Health
13. I III Con 35 00165 Delete AccountDate DT e J 0 0 S 36 00166 Discharge Disposition LI IS J JJ Co 37 00167 DischargedtoLocation CM O59 rs 38 00168 DietType 8 is Q Cool 39 00169 Servicing Facility IS 2 OS 40 00170 1 Bed Sas I D Ce 41 00171 AccountStaus JL IS 2 5 5 Con 42 00172 PendingLocation PL 80 Y 43 00173 Prior Temporary Location PL 80 J 4 S 44 00174 Admit Date Time TS 45 00175 Discharge DateTime TS Q9 J 0 46 00176 Current Patient Balance NM a L 47 00177 Total Charges WM 2 E D 48 00178 Total Adjustments NM D j 9 9 49 00179 TotalPayments TL NM 2 II 50 00180 Alternate Visit ID LI CX QO rs 51 0126 VisitIndicator PAS D owo 52 01224 Other Health Care Provider TL XCN 60 ol ooo B 1 76 1 PV2 Patient Visit Additional Information 1 00181 Prior Pending Location PL 890 PP 4 o 2 00182 Accommodation Code LCE
14. S16 Notification of Appointment Discontinuation See A 4 8 12 A 4 8 17 S17 Notification of Appointment Deletion See A 4 8 12 Page A 70 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 8 18 18 Notification of Addition of Service Resource on Appointment See A 4 8 12 A 4 8 19 S19 Notification of Modification of Service Resource on Appointment See A 4 8 12 A 4 8 20 S20 Notification of Cancellation of Service Resource on Appointment See A 4 8 12 A 4 8 21 S21 Notification of Discontinuation of Service Resource on Appointment See A 4 8 12 A 4 8 22 S22 Notification of Deletion of Service Resource on Appointment See A 4 8 12 A 4 8 23 23 Notification of Blocked Schedule Time Slots See A 4 8 12 A 4 8 24 S24 Notification of Opened Unblocked Schedule Time Slots See A 4 8 12 A 4 8 25 S26 Notification that Patient Did Not Show Up for Scheduled Appointment See A 4 8 12 A 4 8 26 S25 Schedule Query SQM SQR A 4 8 26 1 SQM Originator A or B Message Header Query Definition Query Filter Appointment Request Appointment Preferences Patient Identification Resource Group Appointment Information Services Appointment Preferences Appointment Information General Resource Health Level Seven Implementation Support Guide Page A 71 for HL7 Standard Version 2
15. e We have discussed the negative ballot and clarified the meaning of the spec and the voter has agreed to withdraw the negative e We have agreed to a minor clarification of the document that is not a substantial change and the voter has agreed to withdraw the negative e Or the Technical Committee has voted that it does not find the negative ballot persuasive for reasons stated in the response Technically a ballot may be declared passed if thirty days have elapsed from the mailing of the ballot and a quorum of 60 of the ballot group responded and 67 of the respondents voted affirmatively In practice technical committees work with the voters to reach an understanding so they will withdraw almost every negative ballot Since the ballot group is different than the group that wrote the chapter this normally involves at least one revision and reballot of the chapter In some cases chapters have been substantially rewritten as a result of the comments from the ballot group When the chapters have been approved they are assembled into a draft standard The editor will strive to achieve a common look and organization at this time The draft standard balloted by the same process Any HL7 member can register an interest in balloting the draft document and will be offered the opportunity to vote by mail without any need to attend any meetings The procedure for dealing with negative ballots at this level is essentially the same as at the chapter
16. 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 64 ORC Common Order 1 00215 OrderConrol R ID Q 2 00216 Placer Order Number IL EH QD op 3 00217 Pier Order Number E QD 0 9 J7 4 00218 Placer Order Number gt E QD 3 S 7 5 00219 OrderStaus I j A4 6 00220 ResponseFlag ID 0 Con 7 00221 Quantity Timing TO e J 39 9 S 7 8 002 Parent Tm QU 9 0023 Date Time of Transaction TS Q6 9 0 0 10 0024 BEneedBy 1 LI XeON aw 11 0025 VerifiedBy XENA 12 0026 Ordering Provider LL XCN a 13 0027 Enterer sLocation PL 80 5 0 0 14 0028 CalBackPhoeNumer XIN w Os 15 00229 Order Effective Date Time TS Ge o 16 00230 Order Control Code Reason CE ew J 17 00231 Entering Organization CE 60 5 0 0 S 18 00232 EnteringDevice CB 60 4 0 p 19 00233 ActionBy d doa 2 TTT B 1 65 PCR Possible Casual
17. 5 32 5 3 12 3 Are there any functional issues that should be addressed prior to implementing this chapter oi ce pti eei ean 5 33 APPENDIX A HL7 TRANSACTION CHECKLIST AJ HLT TRANSACTION CHECKLIST ii eerte erbe in A 1 A2 HL7 INTERFACE CHECKLIST COVER SHEET A 3 A 3 GENERAL INTERFACE DESCRIPTION ccsccosssesesotessscnsetssoseeraseaorsnssonsenaseaeens A 4 AST EDD A ceo nh EE A 4 A 3 2 Data Type Descriptions cesis etr ae INA SSMO datada A 4 A183 3 Presentat On nois O E I a een a le oe ae An oeste ee Bin the eed A 9 Ad MESSAGE CHECKLIST iria A 9 A4 T Control Section eiii A 10 A 4 1 1 ACK General Acknowledgment eee eee eee A 10 A 4 1 2 MCF Delayed Acknowledgment eee A 10 E S ORY UCI EE EE A 10 AA 14 DSR Display Response ssec eee eee A 11 A 4 1 5 Q05 Unsolicited Display Update Message UDM sss A 11 A 4 2 Admission Discharge and Transfer Messages A 11 A421 A01 Admit a Patient ADT ea etes aree eror is ede i etra ee dei edis A 11 A 4 2 2 A02 Transfer a Patient ADT ocnnnnnnncoconnnoncnnnannnononnnnncononnnnnnonononocnononnnnonoss A 12 Health Level Seven Implementation Support Guide Page TOC 7 for HL7 Standard Version 2 3 1998 Allrights reserved Final Version 6 98 Table of Contents HL7 Implementation Support Guide A 4 2 3 A 4 2 4 A 4 2 5 A 4 2 6 A 4 2 7 A 4 2 8 A 4 2 9 A 4 2 10 A 4 2 11 A 4 2 12 A 4 2 13 A 4 2 14 A 4 2 15 A
18. 800 Jol y 30 00748 Contact Person Name XPN og 31 00749 Contact Person Phone Numer XTN 40 O 5 32 00750 Contact Person Address XAD a 33 00751 NOK AP s Identifiers CX G2 O 34 00752 R IS Q2 Cp p Be 00H3 Rag E ip M M 11 900 36 00753 Handicap IS o sy 37 00754 Contact Person Social Sec Number ST ue III Health Level Seven Implementation Support Guide Page B 27 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 52 NPU Bed Status Update 1 00209 BedLocaion LE PL 80 n on ri 2 00170 BedStams Ce To TTT Come B 1 53 NTE Notes and Comments 1 00573 SetID NTE S dal o 2 00574 SowceofComen ID 9 j 9 105 3 00575 Commen KE B 1 54 OBR Observation Request 1 00237 SetID ObservationRequest_ C SM 2 00216 Placer Order Number C E II S 3 00217 Pier Oder Mute C H GS 5 4 00238 Universal ServiceID R CE ew 5 S 9 1 000397 Basa TB ae cy AL E ore n i 6 00240 Requested Date Time LS TS e S 7 00241 Obs
19. EA E IX RXO 14 Ordering physician s DEA TT QN RXO 15 Pharmacists treatment Data type changed from CN to XCN PON E PETIT RXO 18 Requested give strength Lu RXO 19 Requested give strength units RXO 20 Indication RXO 21 Requested give rate amount RXO 22 Requested give rate units Length changed from 20 to 60 Component strength Component strength units RXE2 Givecode JL X Added table 0292 RXE 8_ Delivertolocation X_ Length changed from 12 to 200 RXE 13 Ordering provider s DEA X Data type changed from CN to XCN number Pharmacist treatment Data type changed from CN to XCN supplier s verifier number optionality changed from C to O element name changed from Pharmacist Verifier ID to Pharmacist Treatment Supplier s Verifier Number RXE 15 Prescription number IX Optionality changed from R to C Page 5 18 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Segment Seq Pharmacy treatment X Element name changed from Pharmacy supplier s special Special Dispensing Instructions to dispensing instructions Pharmacy Treatment Supplier s Special Dispensing Instructions RXE25 Givestength DG TI RXE26 Give strength units X TI RXE27 Give indication X TI RXE28 Dispense package size X TI RXE 29 Dispense package size X units RXE 30 Dispense pack
20. Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page A 89 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 10 16 PCA Patient Goal Response PPV Originator A or B Message Header Message Acknowledgment Error Query Definition Patient Identification Patient Visit Patient Visit Additional Info Detail Goal Notes and Comments Goal Variance Goal Role Goal Variance Role Detail Pathway Variance Pathway Observation Notes and Comments Detail Problem Notes and Comments Variance Problem Role Variance Role Observation Result Notes and Comments Common Order Order Detail Notes and Order Detail Comments Variance Order Observation Result Notes and Comments Observation Variance Observation Result Page A 90 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 10 17 PCE Patient Pathway Problem Oriented Query QRY Originator A or B Message Header Query Definition Query Filter A 4 10 18 PCF Patient Pathway Problem Oriented Response PTR Originator A or B Message Header Message Acknowledgment Error Query Definition Patient Identification Patient Visit Patient Visit Additional Info Detail Pathway Notes and Comments Variance Pathway Role Variance Ro
21. Identify any major hardware and systems software components that will be necessary to support the intended environment Note User needs required technologies and transaction volumes should be considered in this phase Health Level Seven Implementation Support Guide Page 2 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 2 Planning Methodology 2 5 2 Communications Network Strategy 2 5 2 1 Establish Communications Strategy Establish an overall communications strategy in order to provide a framework for interfacing various systems HL7 interfaces can be supported in a variety of communications environments including local area network direct connect or single processor environments Note User needs required technologies and transaction volumes should be considered in establishing the network strategy and in selecting components 2 5 2 2 Define Communications Protocols Define the communications protocols including HL7 to be utilized through all 7 levels of the OSI model The costs and benefits of using HL7 versus other standards and or individual interfaces should be understood and evaluated In situations where multiple standards will be permitted all such protocols should be defined This will help ensure compatibility and enable easier incorporation of future systems applications If standards other than HL7 will be accepted at the 7th level the process for any necessary translations s
22. c C 2 C 2 1 C 2 1 1 Many environments consist of simple RS 232 circuits where flow control and error recovery issues dominate the communication design For these environments a protocol based on the American National Standards Institute Standard X3 28 is provided It is described in section E 3bf this appendix Some LAN based networking environments provide a reliable byte stream but insufficient session control to support HL7 Environments based on the TCP protocol of the Internet Suite are in this category For these a very simple protocol is provided that simply delimits messages It is described in section Some environments are hybrids where communications occur primarily over LANs but host connections to the LAN may be made over RS 232 ports on terminal servers Environments such as this have some of the same problems as those operating entirely with RS 232 circuits but the bit error rates are generally lower and flow control is available from the network The lower layer protocol described in section C2 pr this appendix is significantly more efficient than the X3 28 based protocol for these environments HYBRID LOWER LAYER PROTOCOL Introduction Goals and Assumptions The goal of this lower level protocol LLP is to provide an interface between HL7 and the network that accommodates these real world restrictions Since the source or destination of a message may be a terminal server all HL7 interfaces to the network must p
23. pS Os 4 00966 SpecialtyType S R CE 00 OTI S 9 5 01237 Location Characteristic Value R CE 890 Po 6 00675 Active InactiveFlag lpm ss 7 0069 ActivationDate TS J 0 5 0 0 8 00970 Inactivation Date LDP TS Bss 9 00971 Inactivated Reason ST 80 III S 10 00976 VisitingHours VH 80 CP 11 00978 ContactPhone Cl w y B 1 43 LOC Location Identification 1 01307 Primary Key Value LOC R PL Q00 0 2 00944 Location Description ST 489 III S 3 00945 LocationType KURT o Ol Coen o o eee 4 00947 OrganizaionNam xo II 5 00948 Location Address RAD a 6 00949 LocationPhone XIN on ss 7 0051 LicenseNumber CE 0 JOll amp LQ 7 8 00953 LocaionEqupmen TTS Health Level Seven Implementation Support Guide Page B 23 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 44 LRL Location Relationship 1 00943 Primary Key Value LRL R PL e ss 2 00763 SegmntAcinCode ID Coupe 3 00764 Segment UniqueKey JL EL 80 0
24. 0 J Jo oy B 1 17 CM2 Clinical Study Schedule Master WE A Spree ol plo o cx une o EE 2 01025 Scheduled Time Point R CE 60 S 3 01026 Description of Time ban ST e J S 4 01027 Events Scheduled This Time ban R CE 609 III B 1 18 CSR Clinical Study Registration 1 0105 Sponsor StudyID R EH 60 A S 9 2 01036 Alternate sway D CET en III S 3 01037 Institution Registration Patient CE ss 4 0108 Sponsor Patient ID R CS GO J S 7 5 01039 Alternate Patient ID CSR CS GO ss 6 01040 Date Time of Patient Study Reg TS Ge 0 7 01041 Person Performing Study Reg XCN 60 Y 8 01042 Study Authorizing Provider R XCN 600 III S 01043 Date Time Patient Study Consent C TS 26 Signed 10 01044 Patient Study Eligibility Status C CE 60 III 0 11 01045 Study Randomization Date Time TS Ge C 0 S 12 01046 Randomized Study Arm TE CE ew CP Page B 8 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event C
25. 1988 Information Processing Latin Alphabet No 4 1988 Information Processing Latin Cyrillic Alphabet 1988 Information Processing Latin Arabic Alphabet 1988 Information Processing Latin Greek Alphabet 1988 Information Processing Latin Hebrew Alphabet 1988 Information Processing Latin Alphabet No 5 A subset of ISO2020 used for most Kanji transmissions ISO 2022 with escape sequences for Kanji 1 6 3 Codes and Terminology Sources ACR CPT4 CAS EUCLIDES Home Health HIBCC Index for Radiological Diagnosis Revised 3rd Edition Current Procedural Terminolog USAN 1990 and the USP dictionary of drug named European standard for clinical laboratory data exchange Home Healthcare Classification System Virginia Saba EdD RN Georgetown U School of Nursing Washington DC Standard for electronic business data interchange 1 Available from American National Standards Institute 11 West 4274 Street New York NY 10036 2 Available from ISO 1 Rue de Varembe Case Postale 56 CH 1211 Geneve Switzerland 3 Available from American Medical Association P O Box 10946 Chicago IL 60610 4William M Heller Ph D Executive Editor Available from United States Pharmacopeial Convention Inc 12601 Twinbrook Parkway Rockville MD 20852 5 Available from G De Moor M D Dept of Medical Informatics 5K3 State University Hospital Gent De Pintelaan 185 B 9000 GENT BELGIUM Page 1 8 Final Version 6 98 Health Level Seven Impleme
26. 1998 All rights reserved 3 3 2 3 3 3 2 4 3 3 3 3 3 4 3 3 5 3 3 6 3 3 7 3 3 8 Chapter 3 Implementation Methodology Identify Data Elements Characteristics For each segment define the data elements that will be utilized and indicate whether they are required or optional Reconcile naming differences lengths data types table values and internal segmentation for each element Identify Extra Z Segment Requirements Identify required data elements not available within the HL7 specification Define and document extra Z segments across applications to include these elements The use of Z Segments is highly discouraged as they are extremely costly to maintain especially as the application and HL7 advance over time They should be used only if there is no other way in HL7 to communicate the information Document And Resolve Functional Interface Issues Document and resolve inconsistencies between applications These may include data elements of different types text vs code non passable edits or error correction and non automatable processes These inconsistencies may be handled manually with modified user procedures by customization of one or more vendors code or by the use of an interface engine Develop Restart Recovery Approach Develop procedures to handle downtime situations system and interface restart recovery and re synchronization and disaster or contingency planning If inst
27. 2 00708 Query Response Status LI ol 0208 B 1 78 QRD Query Definition 1 00025 QuryDae Tim R TS Q9 2 00026 QueryFormatCode R ID D Ce 3 0027 QueryPriority R ID D 5 Soon 4 00028 QueryID R ST o J 3p 5 00029 Deferred Response Tye ID D 5 Com 6 00030 Def Resp Dae Tim TS Bss 7 00031 Quantity Limited Request POR CQ 10 Ce 8 0002 Who Subject Filter R xmn 600 2 34 9 7 9 00033 WhaSubjectFiler R CE 600 ofl J e ow 10 00034 What Dept Das Coie R CE 600 OY 11 00035 WhatData Cd Value Qua ST QO O 12 00036 Query ResultsLevel o ITT Ce B 1 79 QRF Query Filter Reps 1 00037 Where Subject Die R T 09 Ol pp 2 00038 When Data Start Date Time TS o J 0 0 0 3 00039 When Data End Date Time TS Rss 4 00040 What User Qualifier ST 60 JOf 4 AAA 5 00041 Other Query Subject Filter ST 60 Off EA 6 00042 Which Date Time Qualifier PD 02 EC P0156 7 00043 Which Date Time Status Qualifier ID 19 Cc UST 8
28. 9 0022 Substitution Stas PB ss 10 0023 Dispense Amount PO NM QO III S 1 0024 Dispense Units C CE 60 Y 12 00304 NumberofRefills Cal o III S 13 00305 Ordering Providers DEA C XCN 600 III LJ 14 00306 Pharmacist VerifierID XCN 600 0 0 15 00325 Prescription Number C ST Rss 16 00326 NumberofRefills Remaining C NM e A9 S 17 00327 Number of Doses Dispensed Cal QO S 9 18 00328 Date Time of Dose Dispensed C TS eo o 19 0029 TotalDailyDose C CQ aa 7 20 00307 Needs Human Reien ID III y 21 00330 Pharmacy Special Instructions CE Q0 Os 22 00331 GivePer Tim Unity C ST QO lp 23 00332 GiveRateAmount ST J T S 24 00333 GiveRateUnits l QO J 0 S 25 01126 Give Strength NM j A pp 26 01127 Give Strength Units LI CE Os 27 01128 Givelndicaion TE CE ew TTT Health Level Seven Implementation Support Guide Page B 51 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 28 01220 Dispense Package Size NM on 29
29. C 2 6 3 The Network Parameter Table NPT Communication over the network requires establishing some parameters The parameters for any given circuit depend on the organization of the network at the site the type of computers running and the type of message being sent Some common parameters are Network Name the network name to call based on the destination information in the MSH segment Connect Retry Count the number of times to try to connect to a destination Connect Pause the amount of time to wait between connect attempts Receive Timeout the amount of time to wait for a response data block Send Retry Count the number of times to resend a data block after receive errors The values of these parameters need to be specific to a site and to message type They should be easily configurable to allow tuning once the network has started functioning One easy way to do this is by using a Network Parameter Table or NPT The NPT is a simple text table that is read in by the application The table contains values for each of these parameters indexed by message type receiving facility receiving application and processing ID In the communication step which calls for connection specific initialization these values are looked up in the NPT and then control the rest of the communication attempt The use of an NPT is recommended but it is not a requirement for HL7 Health Level Seven Implementation Support Guide Page C 7 for HL7
30. Con 19 00604 Report Subheader CE ew TI pus L 20 00605 Report Dispay Order AA A AAA 21 00606 Date Time Stamp for Any Change in 26 Def Attri for Observation 22 00607 Effective Date Time of Change TS eo jJ o Jo Health Level Seven Implementation Support Guide Page B 31 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 23 00608 Typical Turn Around Time PAM QO P o S 24 00609 ProcessingTime m QO III S 25 00610 Processing Priority ID w III teg 26 00611 Reporting Priority CDI CO O69 27 00612 Outside Site s Where Obs may be CE 200 performed 0063 Address of Outside Site s ao III 00614 Phone Number of Outside Site s X 4o pp JJ TL 0615 Confidentiality Code xS EDO xe ccm AO 0616 Observation Req d to Interpret Obs l 0617 Interpretation of Observation T i T T T T T U gt 5 0 0 2 3 EA 7 A 8 0255 9 AE 0 SE RA c Q9 1 GD H c amp Q9 S R 8259 00942 Modality of Imaging Measurement 0 0 5 U oo TN IS CE X CE CE X CE X CE X ST X CE CE X CE CE CE ENG NUT A pui p ji Ey e D se 00623 Procedure Medication 0 W pni p p Eg PUN i c fe 29 30 31 32 33 34 35 36 37 38 39
31. Development Environment 7 6 1 Requirements Documentation Development Development Environment Draft 7 6 1 1 Network Requirements 7 6 1 2 Disk Requirements 7 6 1 3 Memory Requirements 7 6 1 4 Additional peripherals 7 6 1 5 Software requirements 7 6 1 6 Number of Tapes needed 7 6 2 Requirements Documentation Development Development Environment Final 7 6 3 Obtain Development Environment Requirements Signoff 7 7 Requirements Analysis Security 7 7 1 Identify Security Requirements Health Level Seven Implementation Support Guide Page F 67 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 7 7 1 1 7 7 1 2 7 7 1 3 7 7 1 4 7 8 7 9 7 10 7 10 1 7 10 2 7 10 3 7 10 4 7 10 5 7 10 6 7 10 7 7 10 8 7 11 7 11 1 7 11 2 7 11 3 7 11 4 7 11 5 7 11 6 7 11 7 7 11 8 7 12 Page F 68 Final Version 6 98 Conduct Regional Security Meetings Requirements Documentation Development Regional Security Draft Requirements Documentation Development Regional Security Final Obtain Regional Security Requirements Signoff Create Application Function Matrix Create Access DB of HL7 Generic or purchase from HL7 Requirements Analysis ADT Review Existing ADT Documentation Review Existing ADT I F Specs Prepare Access DB table for ADT Requirements Documentation Development ADT Requirements Mtgs Conduct ADT Requirement
32. Embedded query language using SQL virtual table and stored procedure queries with tabular response 2 25 4 2 2 Embedded query language query 2 25 4 2 3 Virtual table query 2 25 4 2 4 Stored procedure request 2 25 4 2 6 Embedded query language continuation 2 25 4 2 7 Virtual table query continuation 2 25 2 8 Stored procedure request query continuation 2 25 4 2 12 Embedded query language EQL virtual table and store procedure error response 2 25 4 2 13 Event replay error response 5 3 3 3 Messages Segments Q01 EQQ embedded query X Message language query VQQ virtual table query X Message Q01 SPQ stored procedure X Message request RQQ event replay query X Message 5 3 3 4 Data Elements Segment Seq Name New Change Description MSH 3 Sending application X Length changed from 15 to 180 Data type changed from ST to HD MSH 4 Sending facility ID X Length changed from 20 to 180 data type changed from ST to HD eee TT Ar type changed from ST to HD E Dee UU Lee type changed from ST to HD changed from ID to PT MSH 18 x qp DAMM CM message type changed from ST to XCN NE l changed from ID to CE type changed from ST to CE Ae ie ee ee URD 3 R U who subject definition Length changed from 20 to 60 data type changed from ST to XCN ee Mc Length changed from 3 to 60 data type changed from ID to CE RE ca fl Length changed
33. F 1 9 6 Training Recommended Training List the training classes recommended for each type of AIE support person POSITION RECOMMENDED TRAINING CLASSES Cost of Training Describe the training available both on and off site Indicate whether the training is included in the purchase of the proposed solution If it is included indicate any limits on the number of staff members for whom training will be provided and the cost of adding additional staff Provide the cost for obtaining that training again in the future and for training that is not included with the purchase Describe any assumptions and or additional information that will help to clarify the proposed pricing INCLUDED NOTINCLUDED FUTURE INCLUDED FUTURE TRAINING CLASS COST COST PER LOCATION ES T E L TION ER TUDENT Page F 54 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates F 1 9 7 Installation Assistance 1 Describe any assistance you will provide with the installation and implementation of the proposed solution 2 Describe any assistance you will provide at an cost in addition to the price of the proposed solution F 1 9 8 Ongoing Support Maintenance and Enhancements 1 Warranty a How long is the system Category I interfaces under warranty Include warranties for all major hardware and software components b Will there be additional warr
34. K Frequently Asked Questions The Support Guide represents the efforts of the HL7 Implementation Committee to develop support materials for organizations implementing or considering implementation of HL7 interfaces Comments and suggestions regarding content or format are welcomed and should be directed to the Implementation Committee Chairperson s listed at the end of the guide Please keep in mind that both the planning and design implementation methodologies are intended to serve as general guides to help in planning and implementing HL7 interfaces This guide should be used in conjunction with your standard systems development methodology This guide is also intended for use in conjunction with the HL7 interface standards specification document The specification document is provided to all members of the HL7 organization To join this organization and receive a registered copy of the current specification document send a membership enrollment form and the appropriate fees to Health Level Seven This guide is not intended as a tool to validate or certify HL7 interfaces As an American National Standards Institute ANSI accredited standards developing organization HL7 has stated that the specification should be used as a tool in the development of interfaces There currently exists no test or approved process by which an HL7 interface can be validated as compliant to the written specification This is a function and responsibility of the ind
35. NM QO J S 10 00894 DurationUnis CE e 11 00895 Allow SubstitutionCode C IS um J 2 9 279 12 00889 FillerSttusCode C CE ew j Ten B 1 5 AIP Appointment Information Personnel 1 00906 SetID AIP CT R SI o J III 2 00763 Segment ActionCode C ID III J 0200 3 00913 Personnel ResourceID c xw e y 4 00907 ResourceRole R CE e j e 5 0089 ResourceGroup LEI om j e 6 01202 Start Date Time C TS e 5 d 5 j 7 00893 Start Date Time Offset c m QO III 8 00804 Start Date Time Offset Units C CE ew III 9 0085 Duration S Sw o J e 10 00889 DurtionUnts CE ew III 11 00895 Allow SubstitutionCode C I um J 12 00889 FillerStatusCode C CE Qo Jp zen Health Level Seven Implementation Support Guide Page B 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 6 AIS Appointment Information Service 1 00890 StID AIS CT RTS o III 2 00763 Segment ActionCode C ID 0206
36. Patient Visit Additional Info Product Experience Sender Product Experience Observation Potential Causal Relationship Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Administration Pharmacy Treatment Route Detail Problem Observation Result Notes and Comments Associated Parties Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Administration Pharmacy Treatment Route Detail Problem Observation Result Clinical Study Registration Clinical Study Phase Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved P07 Unsolicited Initial Individual Product Experience Report PEX Originator A or B Page A 57 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 5 16 P08 Unsolicited Update Individual Product Experience Report PEX Originator A or B Message Header Event Type Patient Identification Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Product Experience Sender Product Experience Observation Potential Causal Relationship Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Administration Pharmacy Treatment Route Detail Problem Observation Result Notes and Comments Associated Parties Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Administration Pharm
37. 0 S 4 01230 Location RelationshipID R CE 80 A 9 ss 5 01301 Organizational Location Rel C XON 80 ss 6 01292 Patien Location Relationship Value C PL e III B 1 45 MFA Master File Acknowledgment 1 00664 Record LevelEventCode R ID 180 2 00665 MEN Coml ID C SO lp 3 00668 Event Completion Date Time _ TS Rss 4 00669 BmorRetmCodeandorText R CE 60 UID 5 00670 Primary Key Value MFA_ R CE wo III _ B 1 46 MEE Master File Entry 1 00664 Record LevelEventCode R ID J Cem 2 0066 MFNControl ID ST TO 3 00662 Effective Date Time TS op 4 00667 PrimayKeyValue MEE R varies 0 j o Jo y Page B 24 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 47 MFI Master File Identification 1 00658 Master File Identifier POR CE 60 II Ca 2 00659 MasterFileAppliation ID JD 80 PP 3 00660 File LevelEventCode R ID Log EE pup 4 00661 Entered Date Time TS 689 TI 5 00662 Effective DateTime TS Bss 6 00663 ResposelevlCode LEI III Cool B 1 48 MRG Merge
38. 00129 E 00501 saD PR gt AMORES ON Health Level Seven Implementation Support Guide Page B 39 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 2 00392 Procedure CodingMethod B IS CP 0089 3 00393 ProcedureCode R CE 0 ol 9 Leg 4 00394 Procedure Description B ST 40 OL 5 00395 Procedure Date Time R TS Q9 0 J 6 00396 ProcedureType R IS 0230 7 00397 Procedure Minutes LI NM ss 8 00398 Anesthesiologist B XON 20 Off Sooo 9 00399 AnesthesiaCode IS 019 10 00400 AnesthesiaMinutes IL NM j 0 S 11 00401 Surgeon n B J XeNN Q20 Off Com 12 00402 Resident Code B xN o Off Com 13 00403 Consen Coe LCE Ten owo 14 00404 Procedure Priority WI o J 0 S 15 00772 Associated Diagnosis Code CE e __ ___ B 1 72 PRA Practitioner Detail 1 00685 PRA PrimaryKeyValue R ST QO 1 2 00686 PractitionerGroup LCE 600 Jol o 3 00687 PractitionerCategory IS o Ofl 5 0180 4 00688 ProviderBilling ID D
39. 1 00079 FileBatchCount m 100 ame AE MEE 2 00080 File TrailerComment_ ST 89 J jJ B 1 36 GT1 Guarantor 1 os semen lb LE LL 2 00406 Guarantor Number X 69 ll 3 0407 GuarantorName r XN o O T 1 4 00408 Guarantor Spouse Name RN o O T 1 5 00409 Guaramor Address 1 XAb as 49 OT H 6 00410 GmrmrPhone Hom XIN mp To JS 7 oon Guarantor Phone Bus xn O T J SY s 0042 Guarantor Date Time of Binh TS eo oOo Too 1 9 ooms GuaramorSex SST 10 0014 Guarantor Type O OQ OoOo mee Cu 0045 GuarantorRelationship 15 Si 996 12 00416 GumworssN o pr oo T 1 13 0047 GurmorDae Begm Pr O 14 0048 GurmorDae Ed 1 Pr o 0 Tooo O ToS 15 0019 Guarantor Prioty O NM o 1 T 16 00020 Guarantor Employer Name XPN mm ll 17 0043 Guarantor Employer Adar XAb 09 PO Oo Too 1 18 00422 Guarantor Employer Phone 1 XIN mp PO o Tooo 19 0003 Guarantor Employee ID 1 x PO 20 0044 Guarantor Employment H i5 Q o O Too Lee 21 0005 Guarantor Organization RON man OI To 1 1 2 00773 Guaramor Billing Hold Flag D D O To
40. 3 Include an identifier for the Z segment indicating the object of the data ora Z segment preceding it to address identification 4 Document whether the data should be proposed to the HL7 committee for inclusion in the Standard If it is not a unique data requirement fitting a unique use then it should be proposed for the Standard Health Level Seven Implementation Support Guide Page A 93 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 11 3 Creating Z Segments for New Releases of HL7 HL7 encoding and interpreting rules apply to Z segments Segment compatibility must be maintained within releases of HL7 2 X but not necessarily within versions of HL7 V 3 0 Add data elements to the end of currently defined Z segments for associated attributes of defined entities if data is related to that segment For example if you have defined an insurance Z segment ZIN An interface requires additional insurance data that HL7 does not support for example insured s dog s name Add this additional data insured s dog s name to the end of the currently defined ZIN segment This process should prevent transaction rejections since HL7 rules say you should ignore fields you don t expect It will also make management easier for both the developer and the customer Once HL7 includes within the Standard the data contained on Z segments the interface may send dat
41. 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 8 7 S07 Request Addition of Service Resource on Appointment See A 4 8 1 A 4 8 8 S08 Request Modification of Service Resource on Appointment See A 4 8 1 A 4 8 9 S09 Request Cancellation of Service Resource on Appointment See A 4 8 1 A 4 8 10 S10 Request Discontinuation of Service Resource on Appointment See A 4 8 1 A 4 8 11 S11 Request Deletion of Service Resource on Appointment See A 4 8 1 Health Level Seven Implementation Support Guide Page A 69 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 8 12 12 Notification of New Appointment SIU Originator A or B Message Header Schedule Activity Information Notes and Comments Patient Identification Patient Visit Patient Visit Additional Info Observation Diagnosis Information Resource Group Appointment Information Service Notes and Comments Appointment Information General Resource Notes and Comments Appointment Information Location Resource Notes and Comments Appointment Information Personnel Resource Notes and Comments A 4 8 13 S13 Notification of Appointment Rescheduling See A 4 8 12 A 4 8 14 S14 Notification of Appointment Modification See A 4 8 12 A 4 8 15 15 Notification of Appointment Cancellation See A 4 8 12 A 4 8 16
42. 600 3 rs 3 00183 AdmitReason 0 CE 60 0 9 4 00184 TransferReason LCE 60 0 5 00185 Patient Valuables T Os 6 00186 Patient Valuables Location ST QS ss 7 00187 VisitUserCode IS Com 8 00188 Expected AdmitDate TS TH Page B 44 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists 9 00189 ExpectedDischargeDate TS QO TI 10 00711 Estimated Length ot Up stay NM pp 11 00712 AcualLenghofPSay NM 12 00713 VisitDescription ST om J 13 00714 ReferralSourceCode XCN om III 14 00715 PreviousServiceDate DT 9 pp S 15 00716 Employment Illness Related Indicator 1 ID doo 16 00717 Purge Status Code IS D Tou 17 00718 PurgeStatusDate orl 9 J hAe i 18 00719 Special Progam Code IS Tom 19 00720 RetentionIndicator ID D 0136 20 00721 Expected Number of Insurance Plans T NM D pp 21 00722 VisitPublicityCode
43. BAR eese nennen nennen eese nennen nns A 51 A 4 5 Ancillary Data Reporting eus eeneg A 52 A 4 5 1 ROI Unsolicited Transmission of an Observation Message ORU A 52 Health Level Seven Implementation Support Guide Page TOC 9 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Table of Contents HL7 Implementation Support Guide Final Version 6 98 A 4 5 2 R02 R04 Query for Results of Observation QRF sees A 52 A 4 5 3 C01 Clinical Study Registration CRM eene A 53 A 4 5 4 C02 Cancel Patient Registration on Clinical Trial CRM A 53 A 4 5 5 C03 Correct Update Registration Information CRM ssec A 53 A 4 5 6 C04 Patient Has Gone Off Clinical Trail CRM seen A 53 A 4 5 7 C05 Patient Enters Phase of Clinical Trail CRM sees A 54 A 4 5 8 C06 Cancel Patient Entering a Phase CRM eene A 54 A 4 5 9 C07 Correct Update Phase Information CRM eee A 54 A 4 5 10 C08 Patient Has Gone Off Phase of Clinical Trial CRM A 54 A 4 5 11 C09 Automated Time Intervals for Reporting CU A 55 A 4 5 12 C10 Patient Completes Clinical Trail CSU esee A 55 A 4 5 13 C11 Patient Completes a Phase of Clinical Trail CSU A 56 A 4 5 14 C12 Update Correction of Patient Order Result Information CSU
44. DUP entry in field RI ACTION in Table 20b An ad hoc search uses the lowest frequency keyword approach described earlier to select a keyword in order to search the database more efficiently The keyword used in the search is surrounded by brackets CT in the printed report as shown in Table 21 Lines 4 and 5 show two existing LOINC records that come fairly close 5 out of 6 words to matching the submission The first LOINC term 1694 9 differs only in the Property field which explains the three asterisks in Line 3 Line 5 is simply another near match Filter may print up to a maximum of 10 near match terms as part of an ad hoc search If there was a perfect match between the submission and an existing LOINC record there would only be four lines of output for the term and the LOINC SZ column would have the matching LOINC number displayed in the column The Filter program replicates the data in Tables 2a and 2b for each submitted term Conclusion There may be a need to communicate with you about your submission To simplify this communication we may return your submission as an Access database with queries comments about specific terms in the submission You may edit the S fields returned to you with the exception of the S LOCAL CD field which should remain unchanged Page H 52 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC
45. Define one individual on your staff who will have overall responsibility for the total implementation and conversion Health Level Seven Implementation Support Guide Page F 19 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates e How many installations are you currently supporting f How many installations do you anticipate installing throughout the next 12 months 2 Method a Describe your methodology for installation and frequency of product releases Provide a history of product release for the last 18 months b Describe your method of identifying documenting and providing software modifications F 1 6 5 Documentation and Training 1 Documentation a Describe the documentation provided as part of your standard installation approach including b Manager and user reference manuals c User operator manuals d Will copies of user and system documentation manuals be provided for review during the system evaluation process e Canon line documentation manuals be printed on demand f How often is application documentation updated How often are updates made available to the user How is documentation updated memo revised manuals etc g Do you customize end user documentation to reflect St Anybodys Medical Center modifications h In what media is the documentation provided e g CD ROM Help Files Paper Manuals etc i Is necessary hardware
46. Diagnosis Information Diagnosis Related Group Allergy Information Procedure Authorization Contact Data Observation Request Notes and Comments Observation Result Note and Comments Patient Visit Patient Visit Additional Info Notes and Comments A 4 9 9 109 Request for Modification to an Authorization A 4 9 10 110 Request for Cancellation of an Authorization See A 4 9 8 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page A 81 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 9 11 112 Patient Referral REF RRI A 4 9 11 1 REF Originator A or B Page A 82 Final Version 6 98 Message Header Referral Information Authorization Information Contact Data Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert Accident Information Diagnosis Information Diagnosis Related Group Allergy Information Procedure Authorization Contact Data Observation Request Notes and Comments Observation Result Note and Comments Patient Visit Patient Visit Additional Info Patient Visit Patient Visit Additional Info Notes and Comments Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checkli
47. History and physical findings and given a real stretch even culture results could be structured in the panel or multiple choice multiple answer format A single lab may report red blood cell antigens in either way as a binary panel or a multiple choice result depending upon the purpose of the test The routine cross and type are reported out in the multiple choice pattern format only positives from a modest fixed set of tested antigens are reported But if the tests are being used to prove fatherhood the results are usually reported as a binary panel Blood cultures could in theory be regarded as panels Test Name Value E Coli absent Staph aureus present Diptheroids absent Pneumococcal pneumonia absent Pseudomonas present although in practice such tests are almost always reported in the multiple choice multiple answer format as follows Test Name Values Blood culture Pseudomonas Staph aureus Page H 32 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 We bring up these issues to explain why we use a somewhat different data format for some types of tests and why we sometimes provide for both reporting methods e g HLA blood cell antigen tests in the LOINC database When a binary scale is used the kind of property will usually be arbitrary concentration ACNC When the multiple choice multiple answer approa
48. Image Management http www mcis duke edu standards HL7 committees image management im home html Object Broker Technologies ttp www mcis duke edu standards HL7 committees SIGOB T obt html Quality Assurance www mcis duke edu standards HL7 committees quality assurance missions missions htm Secure Transactions http www mcis duke edu standards HL7 committees secure index html SGML XML www mcis duke edu standards HL7 committees sg Page 1 22 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 1 Introduction 1 12 SUGGESTIONS AND COMMENTS The HL7 Implementation Committee welcomes comments and suggestions for improving the implementation support guide Feedback should be sent to Scott Councilman MEDIWARE Information Systems Inc Ph 408 438 4735 Fax 408 438 8422 Email scott mediware com Health Level Seven Implementation Support Guide Page 1 23 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 2 Planning Methodology L 2 1 INTRODUCTION The planning component of the methodology is structured as a general guide that outlines key activities that should be considered by a health care organization when planning for the acquisition and or replacement of various systems applications in an HL7 environment It begins with project planning and organization considerations
49. LA e April 27 May 1 1998 Baltimore MD e September 14 18 1998 San Diego CA G 9 3 6 How Can Get More Information about the Next Working Group Meeting Contact HL7 Headquarters G 9 4 HL7 Information Resources G 9 4 1 How Can I Learn More about HL7 Contact HL7 Administrative Headquarters for information about membership or to be placed on the HL7 mailing list You will receive meeting announcements and a quarterly newsletter which contains authoritative summaries of the work of the Technical Committees The HL7 Implementation Guide only available to members provides significant information about how to implement HL7 The best tutorial information can be seen by attending HL7 meetings Each meeting includes two days of tutorial and case studies Health Level Seven Implementation Support Guide Page G 19 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions G 9 4 2 How Can Contact the HL7 Administrative Headquarters Health Level Seven 3300 Washtenaw Avenue Suite 227 Ann Arbor MI 48104 4250 Fax 313 677 6622 hq 2 hl7 win net G 9 4 3 What HL7 Information Resources are Available on the Internet To join the List Server send E mail to majordomo virginia edu the subject can be anything you want The first line must say exactly subscribe HL7 without the quotation marks Duke University maintains a World Wide Web server at lt http
50. Message E A36 Merge patient information X Message a A37 Unlink patient information x Message PV2 Patient visit additional X Segment a ALI Allergy x Segment 0003 Event codes X Table many new values added A25 thru 0004 Patient Class x Table new values added R B 4 3 2 2 Data Elements EE Segment Seq Name New Change Description g EVN 2 Date Time of event x Length changed from 19 to 26 EVN 3 Date Time Planned Event x Length changed from 19 to 26 EVN 3 Operator ID PID 3 Patient ID internal ID may repeat datatype changed from CK to CM PID 4 x 8 DT changed to 26 TS PID 21 PID 25 PID 26 PID 27 PID 22 PID 24 PID 23 PID 12 County Code Kept in for backwards compatibility only PV1 3 Assigned patient location X Datatype changed from ID to CM PVI 6 Prior patient location LI x Datatype changed from ID to CM Page 4 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 4 HL7 Version 2 2 Overview PV 1 36 PV1 37 PV 1 42 PV1 43 ENT PV 1 45 PV1 50 NK1 3 NK1 6 NKI 7 NK1 8 NK1 9 NK1 10 NK1 11 NK1 12 Next of kin employee number NK1 13 NPU 1 Datatype changed from ID to CM MRG 1 Changed from 16 CK to 20 CM MRG 2 Datatype changed from CK to ST MRG 4 Prior patient ID external x 4 3 3 Chapter 4 Order Entry 4 3 3 1 Messages Segmen
51. Observation Variance Observation Result A 4 10 11 PCH PC Pathway Goal Oriented Update PPG A 4 10 12 PCJ PC Pathway Goal Oriented Delete PPG See A 4 10 10 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page A 87 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 10 13 PC4 Patient Care Problem Query QRY Originator A or B Message Header Query Definition Query Filter A 4 10 14 PC5 Patient Problem Response PRR Originator A or B Message Header Message Acknowledgment Error Query Definition Patient Identification Patient Visit Patient Visit Additional Info Detail Problem Notes and Comments Problem Variance Problem Role Problem Variance Role Detail Pathway Variance Pathway Observation Notes and Comments Detail Goal Notes and Comments Variance Goal Page A 88 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist Role Variance Role Observation Result Notes and Comments Common Order Order Detail Notes and Order Detail Comments Variance Order Observation Result Notes and Comments Observation Variance Observation Result A 4 10 15 PC9 Patient Goal Query QRY Originator A or B Message Header Query Definition Query Filter
52. ParntPacerAppnme D EH P po 23 00882 Parent Filler AppointmentID EI III B 1 10 AUT Authorization Information 1 01146 Authorizing Payor PlanID CE ew II mm 2 01147 Authorizing Payor Company D R CE eo J mg DEEP NN 3 01148 Authorizing Payor Company Name ST 45 4 01149 Authorization BffectiveDate TS e III 5 01150 Authorization Expiration Da TS eo ITT Health Level Seven Implementation Support Guide Page B 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 6 01151 Authorization Identifier C EL GO FP TI 7 01152 ReimbursementLimit_ CP 8 01153 Requested Number of Treatments wl J JJ 5 5 9 01154 Authorized Number of Treatments NM 0 dq 10 j 01145 ProcessDate STI bl B 1 11 BHS Batch Header 1 00081 Batch Field Separator R ST Ds 2 00082 BatchEncodingCharters R ST III 3 00083 Batch Sending Application ST 19 III S 4 00084 Bateh Sending Paciliy ST QO 4 5 00085 BatchReving Application ST 19 Y 6 00086 BatchReceivingFac
53. S 7 00007 Date Time of Message TS eo 5 jJ 5 TI 00008 Serrat gt LL ESE ASAS OOO 9 00009 Message Tye ROM III 10 00010 Message Control ID R OT ST e III 11 00011 ProcessingID R PT III 12 00012 VersionIb______________ R TB III Coon 13 00013 Sequence Number Lulu III TI 14 00014 Continuation Pointer f s aw III 15 00015 Accept Acknowledgment Type ID III 015 16 00016 Application Acknowledge Tyre ID oss 17 00017 CountryCode 1D Q j 9 J LI 18 00692 Laser Se 8 t 19 00693 Principal Language of Message TET B 1 51 NK1 Next of Kin Associated Parties LT 4 00190 SCEIDENKL 1 10 R S 0 1 AAA o o o Nr cs 2 009 Name XPN 49 II S 3 00192 Relationship CE 600 2 Cen 4 0013 Address XAD aw 111 5 0014 PhoneNumber PO XIN 40 CO 6 00195 Business Phone Numer XIN on 9 0 9 7 00196 ContactRole LEI 60 e on 8 0017 StartDate ET Page B 26 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment an
54. ST suffix e g JR or III ST gt prefix e g DR ST degree e g MD ST name type code ID gt Page A 6 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist Sa Data Data Type Name Notes Format Application A Application B ype X Extended organization name ST composite name organization name type code and ID number IS ID number NM for organizations check digit NM code identifying the check digit scheme employed ID assigning authority HD identifier type code IS assigning facility ID HD ON XTN Extended In Version 2 3 replaces the TN telecommunicati data type NNN 999 999 ons number 9999 X99999 B99999 C any text telecommunication use code ID gt telecommunication equipment type ID email address ST gt country code NM gt area city code NM gt phone number NM gt extension NM gt any text ST gt Specialty Chapter Specific Waveform Channel For waveform data only see definition Chapter 7 Section 7 15 3 channel identifier gt channel number NM gt amp channel name ST gt gt electrode names channel sensitivity units gt calibration parameters sampling frequency NM minimum maxim
55. Send Immunization Information with HL7 The CDC data management division in support of the Immunization information system initiative is working with HL7 s committees to add segments to handle the transmission of the immunization events and reaction information HL7 will be the standard for immunization information exchange at the state level e g from state to state and in some cases intrastate It is also used for lab information reporting as well as inter facility reporting The IMMNET L list server can be a source of more information on this topic Please contact me if I can be of any further help John Barthle 75522 3032 compuserve com There is a draft version of part of the HL7 specification related to the needs of the CDC and state departments of public health available on the Duke ftp site in the section on version 2 3 draft ballots Norman Daoust How Would Send Public Health Communicable Disease Data with HL7 There has been some discussion on the List Server that implies that the CDC effort that led to a proposal for transmitting immunization information also supports the public health reporting associated with communicable disease cases This does not seem to be the case The formats in Chapter 7 are very general and could probably be used for this application given the establishment of a suitable set of codes for Observation ID The author is not aware of any specific effort to establish those codes or verify that the
56. Universal Bill Information Universal Bill 92 Information Continuation Pointer A 4 2 20 A20 Bed Status Update ADT Originator A or B Message Header Event Type Non Patient Update A 4 2 21 A21 Patient Goes on Leave Of Absence ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Health Level Seven Implementation Support Guide Page A 23 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 2 202 A22 Patient Returns from LOA ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Originator A or B PS E Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Beg A 4 2 23 A 4 2 24 A24 Create a Patient Link ADT Originator A or B Page A 24 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Message Header Event Type Patient Identification Additional Demographics Patient Visit Disability Information Patient Identification Additional Demographics Pa
57. added PD1 DB1 DRG and ROL patient segments ADT ACK pre admit a Message added PD1 DB1 DRG and ROL patient segments ADT ACK change an Message added PD1 DB1 DRG and ROL outpatient to an inpatient segments Changed name from Transfer an outpatient to inpatient to Change an outpatient to an inpatient Health Level Seven Implementation Support Guide Page 5 9 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview ADT ACK change an X Message added PD1 DB1 DRG and ROL inpatient to an outpatient segments Changed name from Transfer a inpatient to outpatient to Change an inpatient to an outpatient Bl AEN Leeman en OEY patient information segments A09 ADT ACK patient X Message added PD1 and DB1 segments departing tracking message name changed from Patient Departing to Patient Departing Tracking ADT ACK patient X Message Added PD1 and DB1 segments arriving tracking Changed name from patient arriving to Patient arriving tracking ADT ACK cancel X Message Added PD1 and DB1 segments admit visit notification Changed name from Cancel admit to Cancel admit visit notification ADT ACK cancel X Message added PD1 and DB1 segments transfer A13 ADT ACK cancel X Message added PD1 DB1 DRG and ROL discharge end visit segments Changed name from Cancel discharge to Cancel discharge end visit ei NI admit segments A ADT ACK pending
58. data type indicator 87 changed from ID to CE UB1 17 Occurrence span 33 Length changed from 2 to 60 data type changed from ID to CE UB2 3 Condition code 24 30 ME Data type changed from IS to ID UB2 6 Value amount amp code E Data type changed 39 41 added table 0153 Health Level Seven Implementation Support Guide Page 5 27 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview 5 3 7 Chapter 7 Observation Reporting 5 3 7 1 Messages Segments New E P08 Summary product Message Col CRM register a patient X Message C02 CRM cancel a patient registration on clinical trial C03 CRM correct update Message registration information off a clinical trial C05 CRM patient enter phase X of clinical trial C06 CRM cancel patient entering a phase C07 CRM correct update X phase information C08 CRM patient has gone X off phase of clinical trial CSU automated time X intervals for reporting like monthly CSU patient completed X the clinical trial C12 CSU update correction X of patient order result information Clinical study registration Clinical study phase Clinical study data CTI CMI Clinical study phase EF l CM2 Clinical study schedule master ES EO Product experience PCR Possible causal P P Cll CSU patient completes a X Message phase of the clinical trial kal E pal E El E ES
59. for 33 do forever do wait for listen to complete successfully status listen port while status OK for 33 loop until disconnected status receive message if status OK application_code message reply send reply else if status DISCONNECTED break break out of inner loop else ERROR some other error disconnect disconnect if error or done C 6 3 Permanent Virtual Circuits A permanent virtual circuit is a virtual circuit which remains established even when there are no pending message transactions It is the responsibility of the module which performs the network Page C 30 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols call operation to maintain the circuit This module must be prepared to re establish the circuit in the event it is disconnected either accidentally or because of errors The use of permanent virtual circuits must be agreed upon in order to avoid situations in which one module permanently ties up another module which is meant to be used on a transient basis C 6 4 Assumptions and Guidelines The following assumptions and guidelines should be noted 1 It is assumed that the initiating module performs the call operation This implies that it is the initiating module s responsibility to maintain a permanen
60. no external blocking protocol requirement The C layer dynamically allocates enough buffer space to receive the entire message no matter how large John May How Do Find the End of an HL7 Message HL 7 relies on the lower layer protocol to signal when it has received the last byte of a message There is no specific content in the message that serves as an end statement Most lower layer protocol implementations use special characters to indicate the start and end of a message Start of message and end of message characters come as a pair in the HL7 Minimal Lower Layer Protocol Strictly speaking this is not a part of the HL7 standard but was a recommendation to be used in the absence of the full functional support from the lower layers in real word environments It was thought to be necessary for TCP which is a stream oriented protocol but not for LU6 2 which inherently provides message blocking One function of these characters was to provide the receiving routines with a way to signal when the message was complete without waiting for another message to start For some environments another function was to deal with the possibility that partial messages had slipped through This latter problem was more prevalent when HL7 messages were being sent over Local Area Networks and then from a communications server into a serial port of the receiving system Because the Minimal LLP is not part of the Standard there is nothing that requires a system
61. product announcements or other written sources of information on the test or measurement described by the LOINC record Exact core component synonym This field contains an exact synonym for the core component of the LOINC component name We have included the mixed case and superscript form of blood bank and HLA antigens e g Lu here As there is no ASCII representation for superscript letters we use the hat to signify superscripts in this field E g if the core component is represented as L LITTLE U LITTLE SUPER A in the LOINC component analyte name field it is represented in the Exact Core Synonym field as Lu a In a future release we will add more exact synonyms for the core components Molecular weights This field contains the molecular weights of chemical moieties when they are provided to us This release contains values kindly contributed by IUPAC IUPAC analyte code This field contains the Chemical Abstract service number or the Enzyme Nomenclature number for the chemical components for chemicals and or enzymes These were also contributed by IUPAC These two fields provide an overflow for ANSWERLIST values that exceed the 254 characters allowable in most 16 bit spreadsheet and database programs such as Excel 5 0 95 and FoxPro 2 5 ANSWERLIST3 CLASSTYPE FORMULA MULTUM CD Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved 1 Lab
62. relational conjunction ID lt field name ST gt lt value ST amp value2 ST amp value3 ST gt lt HL7 item number ST lt HL7 data type ST gt maximum column width NM gt license number ST gt issuing state province country IS gt expiration date DT job code IS job class IS gt start day range ID end day range ID start hour range TM end hour range TM gt Medical Records Information Management Performing person time stamp Time Series Page A 8 Final Version 6 98 Date time range ID number ST gt family name ST given name ST gt middle initial or name ST suffix e g JR or III ST prefix e g DR ST degree e g MD ST gt source table IS assigning authority HD name type code ID identifier check digit ST gt code identifying the check digit scheme employed ID gt identifier type code IS assigning facility HD lt date time action performed TS gt Scheduling Chapter Only range start date time TS gt range end date time TS Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist Repeat interval Scheduling Chapter Only repeat pattern IS explicit time interval ST Scheduling cl
63. when used in the context of the messaging standards will allow the exchange of clinical laboratory data between heterogeneous computing environments To facilitate this process each identifier needs a fully specified name that is created in a standard way so that users can create long names for their tests that can be linked to the universal test identifier using semi automated methods We have either begun or plan to link other code systems for tests observations such as the IUPAC IFCC2 ASTM E1238 94 SNOMED and Euclides codes to the LOINC codes You will see a field in the LOINC database labeled for each of these related codes We decided to focus on creating names for results of reportable tests or clinical measurements rather than requestable batteries as our first effort because the issues involved in naming results of tests are less complex than those involved in naming the batteries Furthermore defining the individual results is a prerequisite for defining the batteries that contain these individual tests In addition we can begin the process of transferring and pooling results once we have created unique identifiers for results We do have a proposed approach to some orderable test batteries Our goal is to create a universal master file of elected test names that will cover most of the entries in master files of operational laboratory systems so that the terms in these operational master files could be mapped directly into
64. 00770 DRGPayor IS D 32 5 9 00771 Outlier Reimbursement CP o j 0 0 5 S 10 00767 Confidential Indicator TT DE OY B 1 26 DSC Continuation Pointer 1 00014 Continuation Pointer sr aao _ __l B 1 27 DSP Display Data 1 0001 SetID DisplayData SI 0 2 00062 DipayLevel LL ll 3 00063 Dataline R TX om 4 00064 Logical Break Point IL ST 5 00065 ResutID TX Q9 TTT f Health Level Seven Implementation Support Guide Page B 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 28 EOL Embedded Query Language 1 00696 QueryTag CT ST G2 o 2 00697 Query Response Format Code R ID D 3 owo 3 00709 EQLQueryName_ R CE 0 J 4 00710 EQL Query Statement R ST 409 PP B 1 29 ERQ Event Query 1 00696 QueryTag S SI eoa J Lp 2 00706 EventIdentifier LK ID D Come 3 00705 InputParamterList Col 5 CTT __ B 1 30 ERR Error 1 00024 Error Code and Location Col 89 J CP B 1 31 EVN Event Type 1 00099 EventTypeCode R ID Xe
65. 01221 Dispense Package Size Unt CE en ss 30 01222 Dispense Package Method DY 0320 B 1 89 RXG Pharmacy Give 1 0042 GiveSub IDCoumter_ R NM 0 j 0 5 2 00334 Dispense Sub ID Counter NM D j 9 S 3 00221 Quantity Timing R TO ew J 4 AJ 7 4 0017 GieCoe R CE aw 3w Loge 5 00318 Give Amount Minimum R NM QO S 9 6 00319 Give Amount Maximum NM QO S 7 7 0020 GiveUnits rR CEJ 60 S 9 8 00321 GiveDosageForm Ce 60 O S 7 9 00351 AdministrationNotes CE e CT S 10 0022 Substitution Stas ID D P UIT 11 01303 Dispene ToLoaion CM Q0 12 00307 NeedsHumanReview ID D 0130 13 00343 Special Admin Instructions CE ew Cc 9 S 14 00331 GivePer Tim Unity c ST QO 3 S 97 15 00332 GiveRateAmount ST J 16 00333 GiveRateUniss CE 60 P 1 0 17 01126 Give Strength m S 18 01127 Give Strengt
66. 2 3 1998 All rights reserved Final Version 6 98 Chapier 1 Introduction Wayne Tracy Health Patterns Ph 913 685 0600 Fax 913 897 6889 Email wrtracy wrt win net Mission The goal of the Automated Data SIG is to support the message development efforts of the Technical Committees with respect to the transfer of automated physiologic data in particular waveforms The scope of the SIG will be limited to insuring that the V2 3 content relative to the transmission of waveform data is carried forward in V3 of the standard Projects Support the technical committees to insure that V2 3 content relative to the transmission of Waveform data Chapters 2 and 7 is carried forward in V3 of the HL7 standard CONFORMANCE Jack Harrington Hewlett Packard Ph 508 659 3517 Fax 508 686 1319 Email jackhGhpangr07 an hp com Chris Melo Hewlett Packard Ph 508 659 3235 Fax 508 686 1319 Email chris melo hp com Mission The SIG Conformance will provide mechanisms for e Specification of conformance to HL7 via message profiles e Registration of HL7 message profiles by HL7 Projects e Define the form and content of an HL7 message profile document which is to be submitted for registration This will include both static and dynamic conformance statements e Establish criteria for the submission of profiles including but not limited to evidence of implementation by two or more independent vendors e With approval of the HL7 Ex
67. 2 6 Identify Translation Requirements of Messages Segments Patient Demographics to Lab 8 5 3 Complete Final Specification Patient Demographics to Lab 8 5 4 Obtain Patient Demographics to Lab Spec Signoff 8 6 Clinician Master File Update to Lab Specification 8 6 1 Identify Messages Trigger Events Patient Master File Update to Lab 8 6 2 Negotiate Modifications 8 6 2 1 Negotiate Mod Unique Clinician ID Clinician Master File Update to Lab 8 6 2 2 Negotiate Mod Unique Application ID Clinician Master File Update to Lab 8 6 2 3 Negot Mod Unique User ID Across Systems Clinician Master File Update to Lab 8 6 2 4 Identify Code Values Translations Clinician Master File Update to Lab 8 6 2 5 Identify Translation Requirements of Messages Segments Clinician Master File Update to Lab 8 6 3 Complete Final Specification Clinician Master File Update to Lab 8 6 4 Obtain Clinician Master File Update to Lab Spec Signoff 8 7 Lab Orders Results TO Clinical Data Repository Specification 8 7 1 Identify Messages Trigger Events Lab Orders Results to Clinical Data Repository 8 7 2 Negotiate Modifications 8 7 2 1 Negotiate Mod Unique Patient ID Lab Orders Results to Clinical Data Repository Page F 72 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 8 7 2 2 Negotiate Mod Unique Encounter ID Lab Orders Results to Clinical Data Repo
68. 2 RPR Originator A or B Message Header Message Acknowledgment Provider Data Contact Data Patient Identification Notes and Comments Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page A 75 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 9 4 104 Request for Patient Demographic Data RQP RPI A 4 9 4 1 RQP Originator A or B Message Header Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Notes and Comments A 4 9 4 2 RPI Originator A or B Message Header Message Acknowledgment Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert Notes and Comments Page A 76 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 9 5 105 Request for Patient Clinical Information RQC RCI A 4 9 551 RQC Originator A or B Message Header Query Definition Query Filter Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Notes and Comments A 4 9 52 RCI Originator A or B Message Header Message Acknowledgment Query Definition Query
69. 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist Appointment Preferences Appointment Information Personnel Resource Appointment Preferences Appointment Information Location Resource Appointment Preferences Originator A or B A 4 8 26 2 SQR Message Header Message Acknowledgment Error Query Acknowledgment Schedule Activity Information Notes and Comments Patient Identification Patient Visit Patient Visit Additional Info Diagnosis Information Resource Group Appointment Information Service Notes and Comments Appointment Information General Resource Notes and Comments Appointment Information Personnel Resource Notes and Comments Appointment Information Location Resource Notes and Comments Continuation Pointer Page A 72 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 9 Patient Referral A 4 9 1 A 4 9 1 1 RO Message Header Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert Notes and Comments A 4 9 1 2 RPL 101 Request for Insurance Information RQI RPI Originator A or B Originator A or B Message Header Message Acknowledgment Provider Data Cont
70. 3 00238 Universal Service Identifier R ew J J 4 01202 Start DateTime S C TS oe III 5 00893 Start Date Time Oft C NM QO III 6 00894 Start Date Time Offset Units C CE ew J 3 7 00895 Duration NM QO j e 8 0089 Duration Units J ew A J 3 9 00895 Allow SubstitutionCode C IS um 10 00889 FillerSttusCode C CE ew j l O B 1 7 ALI Patient Allergy Information 1 00203 sem ati LEI 50 q 5 e 2 100204 Allergy Te E Us 0 1 05 OB 3 00205 Allergy Code Mnemonic Desc R CE 09 III 4 00206 AllergySeverity J IS Q 3 5 3 oe 5 00207 AllergyReaction LST a J 49 J e 6 00208 IdentificationDate o A y B 1 8 Appointment Information Preferences 1 00908 Time Selection Criteria SVC e III 2 00909 Resource Selection Criteria SVC om 020 6 EA EEN 3 00910 Location Selection Criteria SVC o 4 00911 SltSpaingCrteria Lal o ss 5 00912 Filler Override Criteria Lac e III ze Page B 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All right
71. 3 1 Assess Current Purge Criteria if any 8 3 2 Assess Current Security Criteria 8 3 3 Determine Additional Purge Security Criteria 8 3 4 Complete Purge Security Specs 8 3 5 Obtain Purge Security Spec Signoff 8 4 ADT HL7 TO Lab Specification 8 4 1 Identify Messages Trigger Events ADT to Lab 8 4 2 Negotiate Modifications 8 4 2 1 Negotiate Mod Unique Patient ID ADT to Lab 8 4 2 2 Negotiate Mod Unique Encounter ID ADT to Lab 8 4 2 3 Negotiate Mod Unique Application ID ADT to Lab 8 4 2 4 Negot Mod Unique User ID Across Systems ADT to Lab 8 4 2 5 Identify Code Values Translations ADT to Lab 8 4 2 6 Identify Translation Requirements of Messages Segments ADT to Lab 8 4 3 Complete Final Specification ADT to Lab 8 4 4 Obtain ADT to Lab Spec Signoff 8 5 Patient Demographics to Lab Specification 8 5 1 Identify Messages Trigger Events Patient Demographics to Lab 8 5 2 Negotiate Modifications 8 5 2 1 Negotiate Mod Unique Patient ID Patient Demographics to Lab 8 5 2 2 Negotiate Mod Unique Encounter ID Patient Demographics to Lab Health Level Seven Implementation Support Guide Page F 71 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 8 5 2 3 Negotiate Mod Unique Application ID Patient Demographics to Lab 8 5 2 4 Negot Mod Unique User ID Across Systems Patient Demographics to Lab 8 5 2 5 Identify Code Values Translations Patient Demographics to Lab 8 5
72. 3 7 3 3 7 3 1 3 7 3 2 3 8 Data Conversion Perform data conversion which may include initial data load or conversion of data format Go Live Using the conversion checklist developed in section disconnect old or previous system and run full production under the new interfaces integrated systems Post Implementation Support Help Desk Establish the help desk as planned in section Posi o Live Planning Staff the help desk with support people trained in the environment applications and HL7 The help desk should provide assistance to users troubleshoot problems and answer general questions Track help desk calls by department user and application to identify shortcomings in training or systematic problems Maintenance Transfer system maintenance to the resources identified and trained in section B 6 7 2 2 BENEFITS REALIZATION 3 8 1 Benefits Realization Review cost benefit analysis completed at the start of the project and analyze each anticipated benefit for realization Document how this benefit was achieved or why it was not and quantify Page 3 12 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 3 Implementation Methodology the realized benefits List additional benefits realized that were not detailed at the project start Summarize intangible benefits such as improved employee morale 3 8 1 1 1 Ongoing Review Evalu
73. 3 Other Queues 2 1 2 4 Requirements Draft Documentation Development Queues 2 1 2 5 Requirements Final Documentation Queues 2 1 2 6 Obtain Queues Requirements Signoff 2 1 3 Define DB Requirements 2 1 3 1 Patient Demographics 2 1 3 2 Translation Tables 2 1 3 3 Clinician Holdover Table 2 1 3 4 Others 2 1 3 5 Requirements Draft Documentation Development DB 2 1 3 6 Requirements Final Documentation Development DB 2 1 3 7 Obtain DB Requirements Signoff 2 2 Develop Interactive RFP 2 3 Develop UE Test Criteria 2 4 Meet with I E Vendors 2 5 Bring Evaluation Copy of UE In house 2 6 Run Pre established Tests 2 7 Create Evaluation Matrix and Findings Document 2 8 Present Findings Recommendations to Interface Engine Selection Committee 2 9 Select Interface Engine Vendor 2 10 Return Evaluation Software to Non selected Vendors 3 SITE AND NETWORK PREPARATION 3 1 Determine Environment Configuration 3 2 Order Hardware and Software Health Level Seven Implementation Support Guide Page F 61 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 3 2 1 Order Hardware 3 2 1 1 Order Interface Engine Development Testing HW 3 2 1 2 Receive Interface Engine Development Testing HW 3 2 1 3 Order Interface Engine Production HW 3 2 1 4 Receive Interface Engine Production HW 3 2 2 Order Software 3 2 2 1 Order Software 3 2 2 2 Receive Software 3 2 2 3 Order Software Development T
74. 4 2 16 A 4 2 17 A 4 2 18 A 4 2 19 A 4 2 20 A 4 2 21 A 4 2 22 A 4 2 23 A 4 2 24 A 4 2 25 A 4 2 26 A 4 2 27 A 4 2 28 A 4 2 29 A 4 2 30 A 4 2 3 A 4 2 32 A 4 2 33 A 4 2 34 A 4 2 35 A 4 2 36 A 4 2 37 A 4 2 38 A 4 2 39 A 4 2 40 A 4 2 41 A 4 2 42 A 4 2 43 A 4 2 44 A 4 2 45 A 4 2 46 Page TOC 8 Final Version 6 98 A03 Discharge a Patient ADT cuina A 12 A04 Register A Patient ADIT rrr hende sae Sapa ehe Peto Phe esie Gen A 13 AU Pre Aduiit a Patient ADT sees A 14 A06 Transfer an Outpatient to Inpatient ADT een A 15 A07 Transfer an Inpatient to Outpatient ADT eene A 16 A08 Update Patient Information A DT A 17 A09 Patient Departing ADT sii A A 17 A10 Patient Arriving ADT ouest ecuador nnn nae A 18 ATI Cancel Admit ADT sisi e iiaa A 18 AT2 Cancel Transfer CAD NR BEER A 18 A13 Cancel Discharge ADT EEN A 19 A14 Pending Admit ADT E A 20 A15 Pending Transfer ADT EE A 20 A16 Pending Discharge ADT sese A 21 AI Swap Patients ADT E A 21 A18 Merge Patient Information ADT eese A 22 A19 Patient Query OR Y ADT sese A 22 A20 Bed Status Update AD D iii lindaa A 23 A2 Patient Goes on Leave Of Absence ADT A 23 A22 Patient Returns from LOA ADT sss A 24 A23 Delete a Patient Record ADT sse A 24 A24 Create a Patient Link T E HHT A 24 A25 Cancel Pending Discharge ADT viii iia A 24
75. 4 7 10 T10 Document Replacement Notification and Content MDM Originator A or B CAC EE Message Header Event Type Patient Identification Patient Visit Document Notification Observation Result one or more required D Y D D om om A 4 7 11 T11 Document Cancel Notification MDM Originator A or B Message Header Event Type Patient Identification Patient Visit Document Notification D D UU om Health Level Seven Implementation Support Guide Page A 65 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 7 12 T12 Document Query QRY DOC A 4 7 12 1 QRY Originator A or B Message Header Query Definition Query Filter A 4 7 12 2 DOC Originator A or B Message Header Message Acknowledgment Error Query Definition Event Type Patient Identification Patient Visit Document Notification Observation Continuation Pointer Page A 66 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 8 Scheduling A 4 8 1 S01 Request New Appointment Booking SRM SRR A 4 8 1 1 Schedule Request SRM Originator A or B Message Header Appointment Request Information Appointment Preferences Notes and Comments Patient Identification Patient Visit Patient Visit Additional Info Observation Diagnos
76. 400 with Pascal code and the FTP subcommands with IBM Control Language programs Our physical connection between the AS 400 and the Tandem is a direct Ethernet connection Functional Requirements Our intent when designing the interface was to make it as much like a utility as possible therefore making future implementations of any TPC IP interface easier whether it be ADT Orders or Results The HL7 ADT interface program is an RPG program that responds to ADT trigger events in our financial system It will reside active in a subsystem on the AS 400 and will not end until it is forced to by a request from operations or by detecting an error from the receiving system A second RPG program also resides active in the same subsystem and when called is passed parameters containing the names of the data queues containing the messages the addresses and ports necessary to establish the communication connection and a text description of the interface As each message is developed the HL7 program writes the data and its length out to a sending data queue The second RPG program reads the sending data queue and executes segments of a Pascal program which in turn performs the TCP IP functions and sends the data to the Tandem After each send the TCP IP interface program receives an acknowledgment back from the line that the data hit the line successfully and then an acknowledgment back from the application system identifying whether or not they received the da
77. 63 A 4 7 4 T04 Document Status Change Notification and Content MDM A 63 A 4 7 5 TOS Document Addendum Notification MDM sese A 64 A 4 7 6 T06 Document Addendum Notification and Content MDM cccccnnnnninonnnnn A 64 A 4 7 7 TO7 Document Edit Notification MDM sse A 64 A 4 7 8 TOS Document Edit Notification and Content MDM A 64 A 4 7 9 T09 Document Replacement Notification MDM A A 65 A 4 7 10 TIO Document Replacement Notification and Content MDM A 65 A 4 7 11 T11 Document Cancel Notification MDM sss eee A 65 A 4 7 12 T12 Document Query OR ER E A 66 AAS OCC IT A 67 Page TOC 10 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Table of Contents HL7 Implementation Support Guide A 4 8 1 S01 Request New Appointment Booking SRM SRR sees A 67 A 4 8 2 S02 Request Appointment Rescheduling eene A 68 A 4 8 3 S03 Request Appointment Modification seen A 68 A 4 8 4 S04 Request Appointment Cancellation eene A 68 A 4 8 5 S05 Request Appointment Discontinuation eese A 68 A 4 8 6 S06 Request Appointment Deleton sss eee eee eee eee A 68 A 4 8 7 S07 Request Addition of Service Resource on Appointment A 69 A 4 8 8 S08 Request Modification of Service Resource o
78. A or B OPT Message Header R Event Type R Patient Identification R Additional Demographics Patient Visit R Patient Visit Additional Info Disability Information Health Information A 4 2 33 A33 Cancel Patient Departing ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information A 4 2 34 A34 Merge Patient Information ID Only ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Page A 28 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 2 35 A35 Merge Patient Info Acct Only ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information A 4 2 36 A36 Merge Pat Info Pat ID amp Acct ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information A 4 2 37 A37 Un Link Patient Information ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Identification Patient Visit Health Level Seven Implementation Support Guide Page A 29 for HL7 Standard Version 2 3 1998 A
79. A26 Cancel Pending Transfer ADT iii it edens A 25 A27 Cancel Pending Admit ADT sss A 25 A28 Add Person Information ADT sss A 26 A29 Delete Person Information ADT sss A 26 A30 Merge Person Information ADT eene A 27 A3 Update Person Information ADT eee A 27 A32 Cancel Patient Arriving ADT sss sees A 28 A33 Cancel Patient Departing ADT Did ts A 28 A34 Merge Patient Information ID Only ADT eee A 28 A35 Merge Patient Info Acct Only ADT eee A 29 A36 Merge Pat Info Pat ID amp Acct ADT eee A 29 A37 Un Link Patient Information ADT esee A 29 A38 Cancel Pre Admit ADT uos etia or o Eb EF ana Dpto der o aci MN A 29 A39 Merge Person External ID ADT sss sese A 30 A40 Merge Person Internal ID ADT eene A 30 A4 Merge Account Patient Account Number ADT A 31 A42 Merge Visit Visit Number ADT sees A 31 A43 Move Patient Information Internal ID ADT sss ss sese A 31 A44 Move Account Information Patient Account Number ADT A 31 A45 Move Visit Information Visit Number ADT sss sese A 32 AAG Change External ID ADT 242 cute duse doceri re ea ae Dude nie eels A 32 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Table of Content
80. Anybody s Medical Center is interested in knowing them Please describe any changes you would propose to our interface category definitions or our approach to the implementation If your recommendations affect your proposed solution and or the cost of implementing of implementing it please note the changes Page F 58 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates F 2 SAMPLE INTEGRATION PROJECT PLAN FOR A CLINICAL LAB PROJECT 1 PLANNING AND ADMINISTRATION 1 1 Plan and Cost Estimate 1 1 1 Lab Vendor Contract or Contract Addendum 1 1 1 1 Review Contract 1 1 1 2 Signoff Contract 1 2 Prepare Project Plan 1 2 1 Define Project Scope 1 2 2 Prepare Preliminary Project Plan 1 2 3 Prepare Project Management Guide 1 2 3 1 Distribute Outline 1 2 3 2 First Draft 1 2 3 3 Final Release 1 2 4 Prepare Detail Enterprise Project Plan 1 2 4 1 First Draft 1 2 4 2 Final Release 1 2 5 Lab to Deliver Project Plan 1 2 6 Integrate Enterprise and Vendor Project Plans 1 2 6 1 First Draft 1 2 6 2 Final Release 1 2 7 Obtain Approvals amp Signoffs Project Plan 1 3 Determine Project Organization 1 3 1 Establish Committees Teams 1 3 1 1 Project Oversight Committee 1 3 1 2 Interface Engine Selection Committee 1 3 1 3 Lab Advisory Committee Health Level Seven Implementation Support Guide Page F 59 for HL7 Standard Version 2 3 19
81. Application Acknowledgment Error Original mode Application Reject Enhanced mode Application Acknowledgement Reject Enhanced mode Accept Acknowledgment Commit Accept Enhanced mode Accept Acknowledgment Commit Error Enhanced mode Accept Acknowledgment Commit Reject Optionality A new value conditional on the trigger event has been defined in addition to the current values of required and optional Table usage and definition has been extended and clarified Appearance of different types of tables in the text has been standardized Changes to HL7 Datatypes Minor changes or extensions have been made to the following datatypes TS time stamp AD address CK composite ID with check digit CN composite ID number and name CE coded element 4 2 3 1 3 4 2 3 1 4 New HL7 Datatypes CF coded element with formatted values extension of CE for coded standard text RP reference pointer allows reference to non ASCII data object on another system e g image TQ timing quantity moved from chapter 4 to Control Query MO money allows non US denominations Use of escape sequences in text fields documentation has been improved The former Chapter 5 queries and display messages has been integrated into chapter 2 Acknowledging batches a new explanatory section on this topic has been added 4 2 3 1 5 Other New Fields 4 2 3 1 5 1 MSH segment Country code Definition Defines the country of origin for the message
82. Available via FTP Gopher dumccss mc duke edu standards HL7 termcode loinclab and the World Wide Web http dumccss mc duke edu standards HL7 termcode loinclab 15 Available from American Society for Testing and Materials ASTM 1916 Race St Philadelphia PA 19103 1187 16 Available from American Society for Testing and Materials ASTM 1916 Race St Philadelphia PA 19103 1187 17 Available from American Society for Testing and Materials ASTM 1916 Race St Philadelphia PA 19103 1187 18 Available from American Society for Testing and Materials ASTM 1916 Race St Philadelphia PA 19103 1187 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page 1 9 Final Version 6 98 Chapier 1 Introduction dumccss mc duke edu standards HL7 termcode loinclab and the World Wide Web http dumccss mc duke edu standards HL7 termcode loinclab Forrey AF McDonald CJ DeMoor G Huff SM Leavelle D Leleand D et al Logical Observation Identifier Names and Codes LOINC database A public use set of codes and names for electronic reporting of clinical laboratory test results Clin Chem 1996 42 81 90 1 7 PUBLISHED HEALTH CARE INFORMATICS STANDARDS e Application Protocol for Electronic Exchange in Healthcare Environments Version 1 0 1987 e Application Protocol for Electronic Exchange in Healthcare Environments Version 2 0 1989 e Application Protocol for Electronic Exchang
83. C ID D oa 26 00259 ParentResult CM 40 j 9 7 27 0021 Quantity Timing LI TO Rs 28 00260 ResultCopiesto IL CN aw TI S 29 00261 ParentNumber CM w 30 00262 TransportationMode ID QO 124 31 00268 ReasonforStudy CE ew Os 32 00264 Principal Result Interpreter CM Rss 33 00265 Assistant Result Interpreter CM ew CTT 34 00266 Technician CM om CTT S 35 00267 Transcriptionist JL CM om TI S YA BE NM fay 38 01029 Transport Logistics of Collected 60 Sample L9 013 Colfector s CE ew Oof 40 01031 Transport Arrangement 60 Responsibility 01032 Transport Arranged PRD LB J Top 42 01033 EscortRequired ID D 32 Co 43 01034 Planned Patient Transport Comment CE 00 CTT Health Level Seven Implementation Support Guide Page B 29 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 55 OBX Observation Result 1 0059 SetID OBX S 2 00676 ValueType S C 0125 3 00560 Observation Identifier LK CE 90 P Q4 4 00769 Observation sabta ST QO
84. CE gt quantity with units Money quantity NM gt denomination 6 Numeri ee Structured comparator num1 NM gt numeric lt separator suffix gt lt num2 Identifier Coded values for HL7 tables IS Coded value for user defined Hierarchic namespace ID IS designator universal ID ST universal ID type ID gt Used only as part of El and other data types Page A 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Category Data Type EI Data Type Name Entity identifier Reference pointer Person location ical SS Date Time Appendix A HL7 Transaction Checklist Notes Format Application A Application B entity identifier ST namespace ID IS universal ID ST gt universal ID type ID gt pointer ST application ID HD gt type of data ID gt subtype ID point of care IS room IS bed IS gt facility HD location status IS person location type IS building IS gt floor IS gt location description S T processing ID ID processing mode ID Ld Code Values Coded element Coded element with formatted values Composite ID with check digit Composite ID number and name Extended composite ID with check digit Health Level Seven Implementation
85. CM om II 2 14 00307 Needs HimnReview ID D 5 5 5 0139 15 00330 Special Dispensing Instructions I CE om Cy 5 16 0112 ActualStrength wl QOO S 17 01133 Actual strength Unit f o 0 0 0 0 Y 18 01129 Substance Lot Number ST 19 01130 Substance Expiration Date TS 20 01131 Substance Manufacturer Name CE 21 01123 Indication ET 200 Page B 50 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists 22 01220 Dispense Package gz NM QO 23 01221 Dispense Package Size Unit CE en III 24 01222 Dispense Package Method ID o III 0320 B 1 88 RXE Pharmacy Encoded 1 00221 Quantity Timing R TO QU PP 2 0017 GiveCode 1 R CE Q0 jp 3 00318 Give Amount Minimum R NM QO S 9 4 00319 Give Amount Maximum NM QO S 7 5 0020 GiveUnits R CE 60 5 5 J 6 00321 GiveDosageForm Ce 60 0o 9 7 00208 Administration Instructions CE Rss 8 00299 Deliver toLocation C CM a S
86. Care facilities and other non inpatient admitted facilities Projects e The group will develop its own use cases and scenarios to use as a reference for the members when representing the group s interests at Technical Committee meetings e We will advance the model of Home Health Hospice and Long Term and other non hospital based care through collaboration with technical committee and inclusion of our needs in the committee s DIM IMAGE MANAGEMENT Dean Bidgood Jr MD UOHSC Center for Telemedicine Ph 919 403 0703 Fax 919 403 0703 Email bidgood nlm nih gov Yasser alSafadi Philips Research Ph 914 945 6294 Fax 914 945 6583 Email yhaCphilabs research phillips com Health Level Seven Implementation Support Guide Page 1 19 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Chapter 1 Introduction Mission The purpose of the Image Management SIG is to provide a focus for convergence of HL7 and DICOM The College of American Pathologists and the American Society for Gastrointestinal Endoscopy will participate in the SIG along with the American College of Radiology and other professional specialty societies Strong multi specialty participation will ensure that HL7 specifications for the Imaging System Information System ISIS interface will be compatible with DICOM MEDICOM and JIRA standards and that all diagnostic and therapeutic imaging contexts are supported The Image Management SIG recom
87. Cen 5 00689 Specialty Ioa aow O ey 6 00690 Practitioner ID Numbers CM aw Off Cu 7 00691 Privileges cm Q0 Jol 9 jp 8 01296 Date Entered Practice CT III Page B 40 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 73 PRC Pricing 1 00982 PrimaryKeyValue PRC_ CE ew P0132 125 100995 Basi E E EE 3 00996 Department LEI Jol o S 7 4 0097 Valid PatientClasses IS D Of 3 Comp 5 0098 Price 1 0 C CP 1D Os 6 00999 Formula ST Q0 CP jp r 7 0100 Minimum Quantity NM 0 j 5 S E 8 01000 Maximum Quantity NM 0 S Jf 9 01002 MinimumPrice MO 10 01003 MaximumPrice n mof D j 7 11 01004 EffetiveStr Dae IAS QO 0 12 01005 BffeeiveEndDae _ TS lp 13 01006 PriceOverideFag JL IS D 5 0268 14 01007 BillingCategory CE 600 ol i Coupe 15 01008 ChargeableFlag LJ ID D 0130 16 00675 Active inactiveFlag ID D 8
88. Center is interested in compressing the development cycle by utilizing other standardized interface message templates that may be a part of the AIE Describe in detail how and in what module your system provides the following capabilities and facilities Health Level Seven Implementation Support Guide Page F 29 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates Support for HL7 1 8 Support for HL7 version 2 1 a Recognizing and supporting all HL7 trigger events v2 1 b Recognizing and supporting all HL7 message types v2 1 c Recognizing and supporting all HL7 segments v2 1 Support for HL7 version 2 2 a Recognizing and supporting all HL7 trigger events v2 2 b Recognizing and supporting all HL7 message types v2 2 c Recognizing and supporting all HL7 segments v2 2 When will support for HL7 v2 3 trigger events message types and segments be available Support for user defined elements a Recognizing and supporting user defined trigger events b Recognizing and supporting user defined message types c Recognizing and supporting user defined segments Supporting HL7 encoding and decoding rules Supporting multiple versions of HL7 Supporting HL7 if the AIE does not specifically recognize HL7 standards Does it support the sequence protocol Support for non HL7 Interfaces 1 2 Page F 30 Does your AIE support multiple message formats t
89. Comments Order Common Observations Report ID Notes and Comments Result Notes and Comments Clinical Trial Identification Continuation Pointer Page A 52 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 5 3 C01 Clinical Study Registration CRM Originator A or B Message Header Patient Identification Patient Visit Clinical Study Registration Clinical Study Phase A 4 5 4 C02 Cancel Patient Registration on Clinical Trial CRM Originator A or B Message Header Patient Identification Patient Visit Clinical Study Registration Clinical Study Phase A 4 5 5 C03 Correct Update Registration Information CRM Originator A or B Message Header Patient Identification Patient Visit Clinical Study Registration Clinical Study Phase A 4 5 6 C04 Patient Has Gone Off Clinical Trail CRM Originator A or B Message Header Patient Identification Patient Visit Clinical Study Registration Clinical Study Phase Health Level Seven Implementation Support Guide Page A 53 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 5 7 C05 Patient Enters Phase of Clinical Trail CRM Originator A or B PT appa Message Header Patient Identification Patient Visit Clinical Study Registration Clinical Study P
90. Credit and Collection General Accounting Payroll Personnel Charge Entry Order Communication Outpatient Scheduling Nursing Acuity Laboratory Radiology Pharmacy Retail Pharmacy Inpatient Operating Room Nurse Scheduling Health Level Seven Implementation Support Guide Page F 7 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 4 4 Application Interface Environment Current Application Interfaces The following point to point interfaces are currently installed SENDING RECEIVING COMM RECORD RECORD VOLUME SYSTEM SYSTEM TYPE PROTOCOL SIZE Page F 8 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates Future Application Interfaces Point to point interfaces that will be installed in the future include but are not limited to SENDING RECEIVING COMM RECORD RECORD VOLUME SYSTEM SYSTEM TYPE PROTOCOL SIZE F 1 4 5 Network Environment 1 Local Area Network a a Current Network b b Plans Strategy 2 Wide Metropolitan Area Network c a Current Network d b Plans Strategy F 1 5 Proposed Environment and Development Plan F 1 5 1 Proposed Environment The proposed AIE environment at St Anybodys Medical Center will ultimately include all of the interactions represented in the three Data Interaction Matrices that follow as
91. Data Repository Documentation 7 13 2 Review Existing Clinical Data Repository I F Specs 7 13 3 Prepare Access DB Table for Clinical Data Repository 7 13 4 Requirements Documentation Development Clinical Data Repository Requirements Mtgs 7 13 5 Conduct Clinical Data Repository Requirements Meetings 7 13 6 Prepare Clinical Data Repository Requirements Document Draft 7 13 7 Prepare Clinical Data Repository Requirements Document Final 7 13 8 Obtain Clinical Data Repository Requirements Signoff 7 14 Requirements Analysis Lab Vendor HL7 ADT Results Orders Master File Updates Queries 7 14 1 Lab Vendor Delivers HL7 Interface Specification 7 14 2 Prepare Access DB Columns for Lab System 7 14 3 Review Existing Lab Documentation 7 14 4 Review Exist Lab System Interface Specs if any point to point etc 7 14 5 Review Existing LAB Reports patients results orders etc Health Level Seven Implementation Support Guide Page F 69 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 7 14 6 7 14 7 7 14 8 7 14 9 7 14 10 7 15 7 15 1 7 15 2 7 16 7 16 1 7 16 2 7 16 3 7 16 4 7 16 5 7 16 6 7 17 7 17 1 7 17 2 7 17 2 1 7 17 2 2 7 17 3 7 17 4 7 17 5 7 17 6 Page F 70 Final Version 6 98 Prepare Documents for LAB Interface Requirements Mtgs Conduct LAB Interface Requirements Meetings Prepare LAB Interface Requir
92. Define Application Facility Names Define and document application or facility names for identification during interface development testing and implementation These names may be used in interface lookup tables or in the messaging of the protocol Design Programs Lower Level Protocol Design programs to interact or operate with the lower level protocol This may include programs at the transport level to communicate with the hardware or using the application program interface of third party lower level protocol software Application Level HL7 Design programs to format or translate messages into HL7 format This will come directly from the analysis of the trigger events segments and data elements completed in section 3 3 2 Design should include specifics regarding message acknowledgment procedures Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved 3 4 6 1 3 4 7 3 4 8 3 4 8 1 3 4 8 2 3 4 8 3 3 4 8 4 Chapter 3 Implementation Methodology Application Code Modifications As Needed Design modifications to vendor application code and interface engine configuration files as needed to resolve inconsistencies or support special needs Define Document Specifications Develop detailed specifications per the above analysis and design This should include who vendor internal consultant will be involved and what specifically will be done D
93. Description System Diagram Transaction Data Translation Splitting and Combining This function converts a transaction received from one computer platform and repackages that transaction into a format the receiving application system platform can interpret and use It involves reformatting and changing record lengths along with communication protocol conversion if needed All transactions routed through the AIE must be validated for format and content An initial validation screening must ensure that all parts of a transaction arrived from a sending system Any security authorization checking should be performed at this time An acknowledgment should be sent to the sending system indicating that a legitimate transaction has arrived for AIE processing Communications protocol translation must be performed between disparate computer platforms Protocol conversion should occur prior to data reformatting and transmission of the transaction to the receiving system The AIE will look like a dedicated network resource to each major computer platform to which it is attached Each message or transaction sent to the AIE once received must be formatted to the specifications of the receiving systems Describe in detail how and in what module your system provides each of the following capabilities and facilities Transaction Data Handling Ensuring that all parts of a transaction arrive from a sending system Sending an acknowledgment to the se
94. E T E uus ue EE c oc o oes ref 2 00915 DocumentType R IS Jof Com A e Com een JE fey ff 4 0017 Activity DateTime A fff 5 00918 Primary Activity Provider 60 Code Name 6 00919 Origination Date Time TS QO9 Ys 7 00920 Transcription Date Time C TS Bss 8 00921 Edit Date Time TS Jol S 9 0092 OriginatorCode Name XCN ss 10 00923 Assigned Document Authenticator XCN en TI y 11 00924 Transcriptionist Code Name C XCN a 0 L S 12 0095 Unique Document Number R E GO III 13 00926 Parent Document Numer C E GO III 14 00216 Placer Order Number EH QD CTT 15 00217 FillerOrderNumber H QD 2 BE NNNM EA EA 16 00927 Unique Document FileName ST eo 17 00928 Document Completion Status R ID 0271 18 00929 Document Confidentiality Status ID 0272 19 00930 Document Availability Status ID UT 00932 Document Storage Status ID Q LI D 00933 Document Change Reason Go al p Md e ER 00934 Authentication Person Time Stamp 6 E EE WG E T O 00935 Distributed Copies JUXON a wen EN B 1 96 UB1 UB82 Data Len Max Sender Variable Receiver Variable Page B 56 Health
95. Files Response Originator A or B Message Header Message Acknowledgment Error Query Definition Query Filter Master File Identification Master File Entry Continuation A 4 6 7 MEN Staff and Practitioner Notification M02 Originator A or B Message Header Master File Identification Master File Entry Staff Identification Practitioner Detail Page A 60 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 6 8 MEN Test Observation Master File M03 Originator A or B Message Header Master File Identification Master File Entry General Segment Numeric Observation Categorical Test Observation Observations That Require Specimens Observation Batteries Observations Calculated From Other Observations A 4 6 9 MFN Patient Location Master File M05 Originator A or B Message Header Master File Identification Master File Entry Patient Location Master Location Characteristics Location Relationship Location Department Location Characteristics Location Charge Code A 4 6 10 MEN Charge Description Master File M04 Originator A or B Message Header Master File Identification Master File Entry Charge Description Master Price Health Level Seven Implementation Support Guide Page A 61 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 App
96. Filter Provider Data Contact Data Patient Identification Diagnosis Information Diagnosis Related Group Allergy Information Observation Request Notes and Comments Observation Result Notes and Comments Notes and Comments Health Level Seven Implementation Support Guide Page A 77 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 9 6 106 RQC RCL Request Receipt of Clinical Data Listing A 4 9 6 1 RQC Originator A or B Message Header Query Definition Query Filter Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Notes and Comments A 4 9 6 2 RCL Originator A or B Message Header Message Acknowledgment Query Definition Query Filter Provider Data Contact Data Patient Identification Diagnosis Information Diagnosis Related Group Allergy Information Notes and Comments Display Data Continuation Pointer Page A 78 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist 107 Unsolicited Insurance Information PIN Originator A or B Message Header Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert No
97. G 7 3 Where Does the Accession Number Go in a Lab Order AA G 8 G 7 4 How Do I Send Pharmacy Orders like BID Every M W amp P e G 8 Page TOC 18 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Table of Contents HL7 Implementation Support Guide G 7 5 How Would I Send Immunization Information with HU II G 9 G 7 6 How Would I Send Public Health Communicable Disease Data with HL 7 G 9 GS OTHER AREAS OP INTERBS Lacon eco Ro EM See bo Meet no E aapi G 9 IS 0 pr O CT EE G 9 G 8 1 1 What is the Special Interest Group on Object Brokering Technologies G 9 G 8 1 2 What Approach is SIGOBT Using sese eee eee G 10 G 8 1 3 How Does the SIGOBT Work Relate to the HL7 Data Modeling and bici TT G 11 5 2 Implementing HL7 usina ee tercii i ross EA S Seed esc Hd Evae G 11 G 8 2 1 As an Institution How Do I Implement HIT G 11 G 8 2 2 Asan Information Systems Developer How Do I Develop HL7 Interfaces G 12 G 8 2 3 Is There Software Available to Help Build HL7 Interfaces G 12 5 3 F t r Versions of HL eise t e i Epl iy teta t ded puse ps des G 13 G 8 3 1 What Will be in Version 2 37 iuis eese te nete asa o e Pese Pea er aae ERES ea pee sede deeg G 13 6 GENERAL INFORMATION ca G 13 C9 T The Goals and Scope of HET EE G 13 E P Whats EE G 13 G 9 1 2 What is the Functional Scope of the HL7 Standard G 14 G 9 1 3
98. Health Level Seven Implementation Support Guide Page 5 19 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Segment Seq RXA 15 Substance lot number E IA AE A RXA 16 Substance Expiration Date X gt o y RXA 17 Substance manufacturer X name RXA 18 Substance refusal reason X Indication RXA 20 Completion status X II RXA 21 Actioncode xX LI RXA 22 System entry date time X Td 5 3 6 Chapter 6 Financial Management 5 3 6 1 Messages Segments BAR ACK add patient X Message name changed from Add and update record patient accounts to add patient account Message added PD1 DB1 DRG ROL par ee accounts R financial transactions DRG GT1 IN1 IN2 IN3 ACC A E A account Pl AAA P06 Diagnosis related group X Segment 5 3 6 2 Data Elements Rr Leen financial transaction to Set ID FT1 HEN NN E MI changed from DT to TS HEN JE TU Lee changed from DT to ST FT 1 6 Transaction type LL Dain type changed from ID to IS FT 1 7 Transaction description X Length changed from 20 to 80 data type changed from ID to CE FT1 8 Transaction description X Optionality changed from C to O alot FT1 10 Transaction quantity X Length changed from 4 to 6 FT1 11 Transaction amount X Data Type changed from NM to CP extended FT1 12 Transaction amount unit X Data type changed from NM to CP FT1 14 Ins
99. I Get More Information about the Next Working Group Meeting G 19 GOA EE eene RE G 19 G 9 4 1 How Can I Learn More about HLT G 19 G 9 4 2 How Can I Contact the HL7 Administrative Headquarters T G 20 G 9 4 3 What HL7 Information Resources are Available on the Internet G 20 G 10 RELATIONSHIP TO OTHER STANDARD G 20 Health Level Seven Implementation Support Guide Page TOC 19 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Table of Contents HL7 Implementation Support Guide APPENDIX H LOGICAL OBSERVATION IDENTIFIER NAMES AND CODES H LOINC Users IT H1 57 Page TOC 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved 1 Introduction 1 1 PURPOSE This document provides assistance to health care institutions hospital information systems vendors consultants and other support groups that are considering systems development and implementation activities in a multi system environment using the Health Level Seven HL7 protocol This support guide includes the following information A Planning Methodology B Design and Implementation Methodology Overview of HL7 Version 2 2 Overview of HL7 Version 2 3 HL Transaction Checklist HL7 Message Diagrams Lower Layer Protocols Helpful Hints SG RE Fa Case Studies Sample Templates RFI RFP Contract Points
100. III 3 00069 FileSending Application ST ui S 4 00070 FileSendngFacilty ST QO Po LJ S 5 00071 FileRcvingAppicaion ST 19 J 64 6 00072 FieReceivingFacility ST QO J 0 0 7 00073 File CreationDate Time TS o J 4 o 8 00074 FileSecurity ST op 39 3 Z4 J 9 00075 FileNam IDType dT QO DJ 3 S 7 10 00076 FileHeaderComment IL ST 80 ss 11 0077 Fie God D IT QO Qj 9 J7 12 00078 Reference File Contri D ST o Health Level Seven Implementation Support Guide Page B 13 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 34 FT1 Financial Transaction 1 00355 SetID Financial Trans SET o y 2 00356 Tanacion DD ST Q2 ooo A 3 00357 TransactionBatchID ST a III S 4 00358 TransactionDate R TS Bss 5 00359 Transaction Posting Date IL TS e 4 S 6 00360 TransactionType R IS 9 Con 7 00361 TransactionCode R CE 80 UID 8 00362 Transaction D
101. Institute ANSI to write these standards As with almost all United States standards HL7 standards are voluntary consensus standards There is no governmental mandate to use HL7 except in very limited circumstances HL7 follows procedures that have been approved by ANSI for review and ballot of its standards to ensure that the standard represents a consensus view of a balance of users and producers of health care information systems HL 7 is also the name of the group that publishes these standards HL7 sanctioned national groups also exist in many other countries outside of the United States including Australia Germany Japan the Netherlands and New Zealand Health Level Seven Implementation Support Guide Page G 13 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions G 9 1 2 What is the Functional Scope of the HL7 Standard The Standard currently addresses the interfaces among various systems that send or receive patient admissions registration discharge or transfer ADT data queries orders results clinical observations billing and master file update information The next version of the standard 2 3 will expand on the current coverage of these areas and will include new coverage for patient care medical records and automated instruments Work is also underway to produce HL7 standards for recording immunizations and drug reactions Adapted from the
102. Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 2 4 A04 Register A Patient ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Next of Kin Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information Health Level Seven Implementation Support Guide Page A 13 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 2 5 A05 Pre Admit a Patient ADT Page A 14 Final Version 6 98 Message Header Event Type Patient Identification Additional Demographics Next of Kin Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information Originator A or B Health Level
103. Method ID 5 0329 9 01241 Quantity Distributed Comment FT 00 J o 0 0 10 01242 QuantityinUse n CQ ME SE EE CMM TTT 12 01244 Quantity in Use Comment LI FT 600 TI Ba cad E R LO NN Reports Filed by Facility Reports Filed by Distributors Page B 42 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 76 PV1 Patient Visit 1 00131 Stld PVI IA THI 2 00132 PatientClass R IS D 0004 3 00133 Assigned PatientLocation PL 80 ss 4 0034 AdmissionType IS Q2 0007 5 00135 Pre AdmitNumber CX QO j S 6 00136 Jo Paten Location IL PL Bss 7 00137 AttendingDoctor RN Il 600 0 0 Com 8 00138 RefemngDotr LOCH 600 TC Com 9 00139 Consulting Doctor RN T 600 C 2 A ooo 10 00140 HospialSevice PSA 0 f 0009 11 00141 TemporaryLocation PL Bss 12 00142 Pre AdmitTestIndicator IS o 0 008 13 00143 ReAdmissonInditor IL IS Ce 14 00144 Ad
104. Observation Name The fully specified name of a test result or clinical observation has five or six main parts including the name of the component or analyte measured e g glucose propranolol the property observed e g substance concentration mass volume the timing of the measurement e g is it over time or momentary the type of sample e g urine serum the scale of measurement e g qualitative vs quantitative and where relevant the method of the measurement e g radioimmune assay immune blot These can be described formally with the following syntax Page H 12 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 lt Analyte component gt lt kind of property of observation or measurement gt lt time aspect gt system sample gt lt scale gt lt method gt n n The colon character is part of the name and is used to separate the main parts of the name The first part of the name can be further divided up into three subparts separated by carats The first subpart can contain up to three levels of increasing taxonomic specification separated by dots The hierarchical structure is outlined in Table 1 with references to the section numbers where each item is explained in detail We used Tietz Henry IUPAC EUCLIDES diagnostic microbiology textbooks such as Mahon and Manuselis
105. Optionality changed fromOtoB DG1 12 l Outlier days X OptionalitychangedfromOtoB__ DG1 13 Outlier cost X Data Type changed from NM to CP optionality changed from O to B DG1 14 Grouper version and type Optionality changed from O to B DG1 15 Diagnosis priority Element Name changed from Diagnosis DRG Priority to Diagnosis Priority Optionality changed from O to B DG1 16 Diagnosing clinician Data type changed from CN to XCN repetition changed to Y DGI 17 Diagnosis classification X HG CCS DG1 18 Confidential indicator X DGI I9 Attestation date time X PRI 1 Set ID PRI X Element name changed from Set ID Procedure to Set ID PRI PR1 2 Procedure coding method X Data type changed from ID to IS no longer repeats Procedure code X Length changed from 10 to 80 data type changed from ID to CE no longer repeats PR1 4 Procedure description X Optionality changed from O to B no longer repeats Procedure functional type X Data type changed from ID to IS table changed from 0090 to 0230 element name changed from Procedure Type to Procedure Functional Type Health Level Seven Implementation Support Guide Page 5 21 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Segment Seq Anesthesiologist X Length changed from 60 to 120 data type changed from CN to XCN optionality changed from O to B repetition changed to Y PRI 9 Anesth
106. PD1 PV2 IN1 IN2 IN3 GT1 DGland CTI X Message added CTI Message added PD1 PV2 INI IN2 IN3 and GTI Message added PD1 PV2 INI IN2 IN3 and GTI Message added PD1 PV2 INI IN2 IN3 and GTI Message added PD1 PV2 INI IN2 IN3 and GTI X Message added PD1 PV2 INI IN2 IN3 GTI and CTI X X Message added PV2 Message added PD1 and PV2 Message added PD1 PV2 CTI Message eg gt o ol o o PS Z Z 2 vol 02 V Gei Page 5 16 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview ERME EE FS V04 VXU unsolicited X Message vaccination record update 5 3 5 2 Data Elements Segment Seq ORC 2 ORC 3 ORC 4 ORC 10 ORC 11 ORC 12 ORC 13 ORC 14 ORC 19 BLG 1 BLG 3 OBR 1 Placer order number L Filler order number KE Placer group number C Entered by E Verified by NE Ordering provider i Enterer s location f Call Back phone number Action by Gd When the charge Account ID EE Set ID OBR m Length changed from 75 to 22 data type changed from CM to EI Length changed from 75 to 22 data type changed from CM to EI Length changed from 75 to 22 data type changed from CM to EI Length changed from 80 to 120 data type changed from CN to XCN Length changed from 80 to 120 data type changed from CN to XCN Length changed from 80
107. Page 5 28 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 01997 All rights reserved Chapter 5 HL7 Version 2 3 Overview FAC Facility TXT Segment 5 3 7 2 Data Elements Segment Seq New Description OBR 2 Placer order number Length changed from 75 to 22 data type changed from CM to EI OBR 3 Filler order number Length changed from 75 to 22 Data Type changed from CM to EI OBR 10 Collector identifier NE Data type changed from CN to XCN OBR 16 Ordering provider I OBR 17 Order callback phone number Length changed from 60 to 80 data type changed from CN to XCN Data type changed from TN to XTN Length changed from 200 to 400 Data type changed from CN to XCN Length changed from 60 to 200 OBR 32 Principal result interpreter OBR 37 Number of sample containers OBR 38 Transport logistics of X collected sample OBR 40 Transport arrangement X responsibility OBR 41 Transport arranged OBR 43 Planned patient transport X comment OBX 1 Set ID OBX BN OBX 3 Observation identifier p Length changed from 60 to 200 Length changed from 60 to 200 X Length changed from 60 to 200 X Gei Length changed from 4 to 10 X Length changed from 80 to 590 Length changed from 60 to 10 Length changed from 10 to 5 OBX 8 Abnormal flags OBX 10 Nature of abnormal test Health Level Seven Implementation Support Guide Page 5 29 for HL7 Standard Version 2 3 1998 All rights res
108. RQA RPA Request for resubmission of an authorization RQA RPA Request for cancellation of an authorization REF RRI Patient referral REF RRI Modify patient referral REF RRI Cancel patient referral REF RRI Request patient referral status Health Level Seven Implementation Support Guide Page B 63 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists M02 M03 Varies M04 M05 M06 M07 M08 Mog M10 M11 Page B 64 Final Version 6 98 MFN MFK Master file not otherwise specified for backward compatibility only MFN MFK Master file Staff Practitioner MFN MFK Master file Test Observation for backward compatibility only MFQ MFR Master files query use event same as asking for e g MOD location MFN MFK Master files charge description MFN MFK Patient location master file MFN MFK Clinical study with phases and schedules master file MFN MFK Clinical study without phases but with schedules master file MFN MFK Test observation Numeric master file MFN MFK Test Observation Categorical master file MFN MFK Test observation batteries master file MFN MFK Test calculated observations master file ORM Order message also RDE RDS RGV RAS ORR Order response also RRE RRD RRG RRA BAR ACK Add patient accounts BAR ACK Purge patient accounts DFT ACK Post detail financ
109. Seven Implementation Support Guide Page 2 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 2 Planning Methodology 2 7 2 HL7 Transition Strategy 2 7 2 1 Establish An Overall Transition Plan The transition plan for the migration to an HL7 environment should include e The approach for integrating current systems with planned systems including an assessment of how migration to HL7 will affect the functionality of the systems involved with the implementation s e The approach for conversion Decide if any current systems will be migrated to the HL7 environment before any new systems will be implemented or if the new systems will be implemented in this environment first with the current systems to follow e Identification of any required HL7 translation products that may be necessary during the transition period or on an on going basis e The versions and chapters of HL7 that will be implemented 2 7 2 2 Determine Interface Environment Based upon the technical architecture established earlier a decision will need to be made regarding whether the HL7 interfaces will be developed in a network environment a point to point environment or some combination Decide whether HL7 interfaces will be implemented at the lower level protocol the encoding rules level the abstract message level or some combination 2 8 COST BENEFIT ANALYSIS The purpose of this section is to conduct a high level cos
110. Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page H 23 Final Version 6 98 Appendix H LOINC Table 7 Kind of Property Time THRESHOLD Thresdhold Date TITR Dilution Factor Titer Time e g seconds TYPE Type Time Stamp Date and Time VEL Velocity Time Ratio VELRAT Velocity Rate Reciprocal Relative Time VELRTO Velocity Ratio Relative Time VISC Viscosity Starred items are adopted from the IUPAC Silver Book non starred items are extensions Properties tend to be the most foreign to new users of LOINC Appendix E provides more explanation and many detailed examples 2 4 Time Aspect Point or moment in time vs time interval 3rd part One can measure a property at a moment point in time or over a time interval and integrate in the mathematical sense over time In the latter case we aggregate a series of physiologic states into a single scalar value that reflects some average property measured over the specified time interval Intervals also have relevance for rate measurements such as excretion substance rate or mass rate or clearances volume rates The amount over an interval is often expressed as a mass rate MRAT or a substance rate SRAT e g mol 24h Interval measurements often apply to urine and stool e g collection over 24 h and calculation of a concentration total amount or clearance They also apply to clinical measurements such as urine outputs where
111. Tools 6 4 2 3 Receive Synchronization Tools 6 4 2 4 Install Synchronization Tools 6 4 2 5 Configure Synchronization Tools 6 4 2 6 Implement Synchronization Tools 7 REQUIREMENTS ANALYSIS 7 1 Vendor Education 7 1 1 Develop Education Schedules 7 1 2 Attend Initial Team Training 7 1 2 1 Analysis Training 7 1 2 2 Interface Engine Training 7 1 2 3 Clinical Database Configuration Training if necessary 7 1 2 4 Lab System Functionality 7 1 3 Attend Intermediate Team Training 7 1 4 Attend Advanced Team Training 7 2 Requirements Analysis Communications 7 2 1 Develop Communications Requirements Document 7 2 1 1 Development Environment 7 2 1 2 QA Environment 7 2 1 3 Production Environment 7 2 2 Obtain Communication Requirements Signoff Page F 66 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 7 3 Request IP Addresses 7 3 1 Dev IDs Unix Alphas amp Workstations 7 3 2 QA IDs Unix and Alphas 7 3 3 User Env IDs Unix and Alphas 7 3 4 Acceptance Env IDs Unix and Alphas 7 3 5 Regional Production Evn IDs Unix and Alphas 7 3 6 Vallejo Production Env IDs Unix and Alphas 7 4 Requirements Analysis Hardware 7 4 1 Sizing 7 4 1 1 Development 7 4 1 2 Test 7 4 1 3 Production 7 4 2 Obtain Hardware Requirements Signoff 7 5 Requirements Analysis Production Benchmark 7 6 Requirements Analysis
112. Variance Observation Result A 4 10 2 PC7 PC Goal Update PGL See A 4 10 1 A 4 40 3 PC8 PC Goal Delete PGL See A 4 10 1 Page A 84 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 10 4 PC1 PC Patient Problem Add PPR Originator A or B Message Header Patient Identification Patient Visit Patient Visit Additional Info Detail Problem Notes and Comments Problem Variance Problem Role Problem Variance Role Detail Pathway Variance Pathway Observation Result Notes and Comments Detail Goal Notes and Comments Goal Variance Goal Role Goal Variance Role Observation Notes and Comments Common Order Order Detail Notes and Order Detail Comments Variance Order Observation Result Notes and Comments Observation Variance Observation Result A 4 10 5 PC2 PC Problem Update PPR See A 4 10 4 A 4 40 6 PC3 PC Problem Delete PPR See A 4 10 4 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page A 85 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 10 7 PCB PC Patient Pathway Problem Oriented Add PPP Originator A or B Message Header Patient Identification Patient Visit Patient Visit Additional Info Pathway Detail Notes and Comm
113. Version 2 3 1998 All rights reserved Chapter 4 HL7 Version 2 2 Overview 4 3 7 Chapter 8 Master Files 4 3 7 1 Messages Segments Tables Msg Segment Description MEN Masterfilenotification x Message MFD Master files delayed application acknowledgement x Message MFQ Master file query x Message MFK Master file application acknowledgement x Message MFR Message MFI Segment MFE Segment MFA Segment STF Segment PRA Practitioner detail x Segment ai X X X Description Message Message Message Message x Message x Segment x Segment x Segment x Segment Segment gt Health Level Seven Implementation Support Guide Page 4 15 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 5 HL7 Version 2 3 Overview 5 1 INTRODUCTION The purpose of this chapter is to provide information regarding new features and capabilities present in Version 2 3 of the HL7 specification migration considerations and future focus areas The first section contains a question and answer section authored by HL7 technical committee co chairs The second section contains a listing of new and changed tables and chapter by chapter descriptions of the differences between the HL7 Version 2 3 Standard and the HL7 Version 2 2 Standard and provides descriptions of chapters new with Version 2 3 5 2 VERSION 2 3 QUES
114. What Application Architecture is HL7 Based oni G 14 G 9 1 4 What is Implied by the Phrase Level ven G 14 G 9 1 5 What are the Goals of the HL7 Effort I E ala aed Seer ed es saad G 14 G92 The Governance of HI Tunisia ln G 15 G 9 2 1 What is the HL 7 Working Group ette tpe todo pec bep ident G 15 G 9 2 2 What is a Technical Committee of the Working Group G 16 G 9 2 3 What is a Special Interest Group of the Working Group G 16 G 9 2 4 What is the HL7 Executive Committee essere eene G 16 G 9 2 5 What is the HL7 Technical Steering Committee esses G 16 G 9 2 6 What is the Role of the HL7 Executive Director and Administrative Staff G 16 G 9 2 7 How are HL7 Standards Written Balloted and Published G 17 G 9 2 8 Who May Use the HL7 Standard Do I Have to be a Member G 17 45929 How Do I Get a Copy of the Standard aseo pei ero dd G 18 G 9 2 10 What are the Sources of HL7 Funding and How is the Money Used G 18 9 3 The HL7 Working Group sese eee eee G 18 G 9 3 1 How Do I Join the HL7 Working Group T G 18 G 9 3 2 Why Should I Join the HL7 Working Gronn G 18 G 9 3 3 How Big is the HL7 Working Group EE G 18 G 9 3 4 Who are the Principle Contacts for Questions and Comments about HL7T G 19 G 9 3 5 When and Where are the Next Working Group Meetings E G 19 G 9 3 6 How Can
115. What is your company s policy regarding maintenance contracts that do not automatically renew e g is positive action required to renew the maintenance contract 2 Capabilities a Does your system have the capability for dial up diagnosis of system trouble b Under your software maintenance agreement can St Anybodys Medical Center develop its own separate systems that could access but not modify data contained in your system 3 Field Support a Where is the field office nearest to St Anybodys Medical Center for software support b With how many and what types of employees is it staffed c What office is responsible for the maintenance of the following hardware what is the location of that office and what is the average response time to calls for hardware support that your company is prepared to guarantee mE RESPONSIBLE PARTY OFFICE LOCATION a m TERMINALS AND WORKSTATIONS Page F 18 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates COMMUNICATIONS EQUIPMENT d Is emergency hardware and software support available 24 hours a day seven days a week on site or by telephone Define types of response timeframes and additional cost if there is one e Whatis the availability of spare parts and standby equipment should it be required by St Anybodys Medical Center What timeframe should be expected for
116. allocate for research development on your AIE for 1994 e Percent of Revenue Health Level Seven Implementation Support Guide Page F 13 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates e Dollars D Have any of your customers canceled a contract before during or after an installation If yes why Specify hospital and location E Whatis the name and version of your operating system Is the operating system standard or tailored for the vendor F Isany part of your system written by a third party If so what applications Who wrote it Who supports it What is your companies relationship with the third party 6 AIE Customer Base Identify by hospital size the number of hospitals currently using the AIE you propose e 0 300 Beds e 301 500 Beds e 501 700 Beds e Over 700 Beds 7 References Identify the following items for at least three hospitals that are currently using your AJE for the system you are proposing for St Anybodys Medical Center The hospitals listed should be using the same HIS vendor or have environments similar to ours Pe al FACILITY 1 FACILITY 2 FACILITY 3 NUMBER OF BEDS IS DIRECTOR PHONE AVAILABLE FOR A SITE VISIT A Describe each of the facilities referenced Facility 1 e The hospital environment and system configuration Page F 14 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standa
117. any copies of the LOINC database that they distribute 4 If new records are added to the LOINC database as distributed to deal with local requirements these records must be assigned a LOINC code containing a leading alphabetic X so that the new term cannot be confused with new LOINC codes as they are assigned by the LOINC committee 5 Those who incorporate any part of the LOINC database into another laboratory test definition database for distribution outside of their corporation must include the LOINC code field 1 all six name fields 2 7 the related terms field 8 and the answer list field 19 and include this copyright notice on the electronic document that incorporates the LOINC database Regenstrief Institute and the members of the LOINC Consortium do not accept liability for any omissions or errors in the LOINC database and all EXPRESS AND IMPLIED WARRANTIES INCLUDING THOSE RELATING TO MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED LOINC is a trademark of the Regenstrief Institute This legend should be displayed on every copy of the database both on the diskette itself and in a text file loaded onto the diskette or onto the Internet and on all user manuals and other materials used in connection with the LOINC database Page H 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Pref
118. are accomplished by the receiving station s transmitting a RINT sequence in lieu of the normal affirmative acknowledgment This reply is interpreted as an affirmative reply to the last transmission and it signals a request by the receiving station that the sending station terminate the transmission sequence in progress as soon as the sending station is in such status that it can receive a message without destroying or losing information that may have previously been stored in buffers The RINT sequence may not be repeated by the receiving station to successive transmission blocks without transmitting intervening affirmative acknowledgments ACKN Upon receipt of RINT the sending station should terminate the transmission by transmitting EOT after it has completed transmitting all data that would prevent it from receiving a message The number of transmission blocks to be transmitted prior to termination is variable and dependent upon station design The receipt of RINT as a response to a sending station s ENQ should be treated as a repeated duplicate response if the last valid response received was ACKN The sending station should continue by transmitting the next block or EOT If the last valid response was RINT the sending station must assume that the last transmitted block was garbled The sending station should retransmit the previous block Health Level Seven Implementation Support Guide Page C 19 for HL7 Standard Version 2 3 1998 A
119. as the receiving buffer is available to receive the next frame Flow control XON XOFF is not needed since a synchronous block acknowledgment scheme is used and a receiver s buffer is guaranteed to hold a block of maximum block size Buffer overruns do not cause loss of data Aborts and Interrupts At times during data interchange the sending station may need to end a transmission block in an unusual manner such that the receiving station disregards that portion of the block or transmission that has been received This procedure is called an abort At other times during data interchange a receiving station may wish to cause the sending station to stop sending either temporarily to permit the receiving station to send or permanently This procedure is called an interrupt Block Abort Description The sending station in the process of sending a block but before the end of the block decides to end the block in an unusual manner such that the receiving station will Health Level Seven Implementation Support Guide Page C 17 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols Application Procedures discard the block Such a procedure is called a block abort Block abort may be used by a sending station when in the process of sending data there occurs an indication that the data being sent may not be valid Block abort may be used in the message transfer state to c
120. assumption is that its been preceded by a SQ control message of 0 or 1 Thus this is a start of sequencing actual message and the receiving system is synchronized to this incoming SQ as its ESN and ESN State is ESN gt 1 No further SQ checking but do regular application processing on this message Send MSA with AA or AE accordingly Page C 26 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols This chart is a continuation from the Sequence Number Processing Chart on the previous page It details the Sequence Number Process when there is an ESN and the ESN state ESN gt 1 MESSAGE WITH SEQUENCE NUMBER Sending system sends a message with a sequence number SQ v Receiving System tracks Expected Sequence Number ESN and ESN state compares SQ with ESN SQ ESN SQ ESN Sends MSA with AA or Sends MSA with AR acknowledgment code an error message the Expected AE acknowledgment Sequence Number ESN and the message sequence number SQ code and contains the received SQ ESN Sending system Sar ESN SO 1 ESN Sar gt ESN Increments SQ by 1 Assumes the previous 1 ADT tries to recover by Freezes the link acknowledgment is lost starting at the ESN in the The message sent is a MSA duplication Increments SQ by 1 Or 2 Freezes the link Processes the next Process
121. at all or do so at a prohibitively high price Interface engines can also link systems which have lower level protocol incompatibilities e g one vendor uses TCP IP and another vendor RS232 or data model incompatibilities e g accommodation code is a two character field in the registration system but only a one character field in the order entry system Finally interface engines can serve as message routers determining which systems on the network should receive messages and delivering them accordingly Routing may be simple based solely on HL7 trigger event e g lab and pharmacy always receive admit messages or complex based on the data contained within the message e g ICU receives admit data only if patient service is ICU It is critical when planning for implementation of a multi system environment that an overall systems strategy and technical architecture be established These strategies will help guide the health care institution through critical issues such as how information technology will be utilized to support business goals and objectives whether an HL7 approach is appropriate for your organization and what the overall technical architecture of the organization will be Considerations related to these activities are included within this section of the methodology However these considerations are not intended to be comprehensive The planning methodology contains the following sections A Planning and Organization B B
122. base you should use this template to be sure the field names are right A blank Access database template named SUBMIT MDB is included in the RELMA software package You should be diligent in filling in the first 13 fields of the table for each term in your submission Along with the database file for your submission you should also include a cover letter or email that contains the following information The name of the organization making the submission A contact name and their telephone number A contact FAX phone number A contact email address eg Including this information will help us to respond to your request in a more efficient manner Access Database and Excel Submissions You may make a submission in the form of a Microsoft Access database or an Excel spreadsheet Most of the actual processing of a submission ends up in the form of an Access database so when feasible send the submission as an Access database file If you wish to submit an Access database the fields described in Table 20 of this appendix must be used as the field names in the database You may also use the field names presented in Table 20 as column names in an Excel spreadsheet We will assume for purposes of illustration that the submission is in the form of an Access database Note that the field names are stored in uppercase letters and must be spelled exactly as shown in Table 20 Once you have created an empty database with the fields specified in Tabl
123. code sets where they are defined and we recognize that movement toward more standardized codes is essential for seamless communications Other Applications Protocols The Working Group has given considerable attention to the relationship of the HL7 protocol and other protocols A considerable liaison effort is underway This is described below 1 ACR NEMA DICOM The HL7 Working Group maintains an on going liaison with the ACR NEMA DICOM working group HL7 and ACR NEMA DICOM are both members of ANSI s HISB 2 ASC X12 Standards for Electronic Document Interchange X12 is a family of Standards that provide both general and specific descriptions for data interchange within a number of industries The HL7 Encoding Rules are modeled on the X12 Standards although there are differences The HL7 Standard needs to accommodate on line exchange of individual transactions on LANs This difference and certain applications issues are responsible for the variance from X12 X12 has recently decided to follow the UN EDIFACT encoding rules for all X12 standards produced in 1995 or later However at this time this decision will not require retroactive maintenance activity on all existing X12 Standards Transaction Sets X12N transactions that facilitate the transfer of health care claims and remittance information as well as benefit coordination enrollment and verification are enjoying dramatically increased use HL7 has elected to assume that all busi
124. control of the line to become the master sender 2 When a station desires to transmit a message the station requests to be the master by sending an ENQ supervisory sequence to the remote station 2 It is possible for both stations to bid for master status simultaneously Indicated by receipt of an ENQ after sending an ENQ In this case priority is given to the station that is designated by local agreement as the primary for contention purposes e The secondary station grants the line to the primary station by sending an ACKO e The primary station waits for receipt of ACKO If ACKO is received prior to expiration of Timer A the primary has been granted master status and begins transmitting data If Timer A expires the primary station again requests master status by transmitting an ENQ sequence A Station that has not sent ENQ but has received ENQ takes the following action 1 Inhibits the sending of ENQ to bid for master status 2 Ifready to receive assumes slave status and sends an optional prefix See section on Prefixes followed by ACKO 3 3 If not ready to receive sends an optional prefix followed by NAK 4 Upon receipt of an affirmative reply the bidding station assumes master status and proceeds with message transfer 12 Upon receipt of NAK the bidding station reinitiates a bid for master status 2 The station reinitiates its bid M times 5 and then exits to a recovery procedure 6 Page C 14 Hea
125. demographic update to patients that do not have current orders pending There are many such individual concerns Rather than enumerate them all and treat each as a separate set of messages the approach of the technical committees has been to create a flexible standard that can be applied in Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix G Frequently Asked Questions these situations through bilateral negotiations e The HL7 group has as a policy attempted to avoid dictating changes in the design of user systems in order to implement HL7 interfaces For example very few systems can deal with variation in order content between a physician s pharmacy order and that of a pharmacist Options exist that can be adapted to systems that can and those that cannot Another example of this system variability has to do with the assignment of order numbers Some systems assume that they are the only source of order numbers where others recognize that numbers may be assigned by other systems Options exist to accommodate both approaches In extremes this policy has meant accommodating systems that have conceptual anomalies such as identifying the patient only by a visit number or systems that can accept orders but cannot assign an order number e There are optional features of the HL7 protocol including the assignment of serial numbers to transactions se
126. does it offer Additional messages were added and message constructs were extended to allow greater specificity in the intent of the message and to report additional information Segments were added or extended to provide improved reporting capability For example DG1 and DRG information previously reported in a single segment is now reported via two separate segments Person attribute information was added for the Guarantor GT1 segment and Insured IN2 segment The insurance segments were extended to improve reporting capability What does version 2 3 not address at this time Will these issues be covered in the next release Version 2 3 plans are to address internationalization of the standard for demographic information Inclusion of additional financial claim type information is also being evaluated The identification of data for billing or administrative purposes versus clinical purposes is needed for harmonization of the model The PAFM working group continues to gain representation from different groups such as X12 Home Care Physician Practice Management etc Hopefully this will be a positive influence to broaden the scope of the Finance chapter to address the needs of varied markets What key criteria should be used in determining if members should upgrade to version 2 3 or stay with version 2 2 What key functional issues would drive this migration The need for use of the additional message or extended constructs defined
127. e g moles while most U S labs report in mass concentration We have applied the IUPAC code for substance concentration to mass concentration because IUPAC has no code for the mass concentration variant Page H 41 Final Version 6 98 Appendix H LOINC Field Name Type Width Description 14 DT_LAST_CH Char 8 Date last changed in the format Y Y Y YMMDD 15 CHNG_REAS Char 254 Reason term was changed If a term has been changed the reason for the change is detailed here 16 CHNG_TYPE Char 3 Change Type Code DEL Delete ADD add NAM change to Analyte Component field 2 MAJ change to name field other than 2 3 7 MIN change to field other than name 17 COMMENTS Char 254 Free text comments relating to the test result 18 ANSWERLIST Char 254 The list of answers for results that are reportable from a multiple choice list e g the answers for the term DISPOSITION OF BLOOD PACK are GIVEN PARTIALLY GIVEN DISCARDED This field provides examples not required answer lists 19 STATUS Char 3 Deprecated or superseded status indicated by DEL in this field otherwise blank Used to mark terms as the database evolves LOINC codes will not ever be re used nor will they be removed from the database they will instead be cross referenced to superseding terms in Field 20 20 MAP TO Char 7 Used when a field has been dropped from the active database by entering DEL in the Status field because it has been repla
128. escape sequences to switch between ASCII and 8 bit or multibyte character sets within text fields Mark Shafarman How Should Midnight Be Represented in HL7 HL7 explicitly states that midnight should be represented as 00 00 See the definition of the TM data type in HL7 Version 2 3 Chapter 2 Wes Rishel Why Isn t HL7 Plug and Play When two parties agree to implement HL7 they must write an auxiliary specification that describes how they will apply it to their specific interface The requisite time for analysis programming and testing significantly delays and adds costs to interfaces Why is this e There are differences in the information needs of different institutions depending on locale size and practices These dictate the need for optionality in the interface Some examples of the kinds of differences that exist include the requirement to capture specific demographic data elements based on local regulations or special populations We could not imagining telling health care system A that they can t send Patient s County or Primary Nurse or health care system B that they must collect Patient s County or use the primary nursing system because HL 7 requires it A similar concern relates to reference labs We cannot imagine telling a reference lab that it must maintain a database of all patients that it has seen each uniquely identified so it can accept updates to demographics separate from what is contained in an order or apply a
129. find answers to frequently asked questions before posting them on the List Server Its first priority is to support newbies by answering common questions or pointing them to information resources At this stage in its publication there are still many frequently asked questions that are not answered here A secondary purpose of the FAQ is to serve as a stimulus for people other than the editors to contribute answers This FAQ will includes answers to questions on the interpretation of the HL7 standard It is important to recognize that the FAQ itself is not a sanctioned document of the HL7 group has not been balloted and carries no normative weight in deciding whether an implementation of HL7 is conformant Much of this material is an excerpt from the HL7 List Server For this reason some contributors to this may not be aware they have been cited The editors of the FAQ presume that by publishing on the List Server the authors will assent to an edited version being included in the FAQ We will of course remove or correct any such contribution at the request of the author G 4 2 What are the Design Goals of this FAQ The contents of the FAQ should be attributed and the FAQ should provide information on how to reach the contributors We would expect this FAQ document to be available as World Wide Web document and as a text Page G 2 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1
130. formats in chapter 7 are complete I addition there are probably issues of patient identification and patient privacy that would have to be addressed OTHER AREAS OF INTEREST G 8 1 SIGOBT G 8 1 1 What is the Special Interest Group on Object Brokering Technologies Object and object oriented are two of the most overloaded terms since user friendly Object Health Level Seven Implementation Support Guide Page G 9 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions Brokering generally refers to a model of communication among cooperating programs that is a based on some of the concepts of Object Oriented Programming and b includes a broker to help the cooperating applications find one another using symbolic names rather than physical locations Two important object brokers that are being actively used today are Microsoft OLE and the Common Object Request Broker Architecture CORBA OLE is the method of choice for developing cooperating applications within a workstation running any of the Windows operating systems Through OLE users have the ability to access data and control applications using a wide and expanding set of productivity tools It is a basis for componentized software Users are able to access data and control other applications from any package that can be en OLE controller CORBA is being used today to communicate among applications running on hete
131. from 20 to 60 data type changed from ST to CE Page 5 8 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Segment Seq New URS 9 R U quantity timing X qualifier DSP 1 Set ID DSP EE NTE 1 Set ID NTE NE EQL 1 Querytag X EQL 2 Query response format code EQL 3 EQL query name EQL 4 EQL query statement VTQ 1 VTQ 2 Query response format code VTQ 3 VT query name VTQ 4 Virtual table name Oo EE EE PRDT 1 Columnvalue X TI SPRI Ouen ag 3 LI SPR 2 SPR Stored procedure mame X II SPR4 Input parameter list X EROI Qeyug RA ERQ2 Pvmidmiir PR PERQ 3 Inptpaameeri X SSS Element Name changed from Set ID Display Data to Set ID DSP Element Name changed from Set ID Notes and Comments to Set ID NTE gt gt gt gt 5 3 4 Chapter 3 Patient Administration Changed name of chapter from Admission Discharge and Transfer to Patient Administration 5 3 4 1 Messages Segments Tables ADT ACK admit visit X Message added PD1 DB1 DRG and ROL notification segments Changed name from Admit a patient to admit visit notification EN RENE E ee patient ADT ACK Message added PD1 DB1 DG1 DRG PRI discharge end visit and ROL segments Changed name from Discharge a patient to Discharge end visit A04 ADT ACK register a Message
132. from ID to IS Data type changed from ID to IS d gl E E E PA po NE E RES Health Level Seven Implementation Support Guide Page 5 15 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Segment Seq New a NPU 2 MRG 1 Prior patient ID internal MRG 2 Prior alternate patient ID gt Length changed from 12 to 80 data type changed from CM to PL removed table 0079 X Data type changed from ID to IS repetition changed to Y Length changed from 16 to 20 data type changed from ST to CX repetition changed to Y X Data type changed from CK to CX X Length changed from 16 to 20 data type changed from CK to CX MRG 3 Prior patient account number MRG 4 Prior patient ID external MRG 5 MRG 6 Prior alternate visit ID MRG 7 5 3 5 Chapter 4 Order Entry 5 3 5 1 Messages Segments Event w 002 ORR general order response for order status Stock requisition order Nonstock requisition order Pharmacy prescription message O01 RDE RRE pharmacy 002 treatment encoded order message 001 00 RGV pharmacy treatment give message RDS pharmacy treatment dispense message O01 RAS RRA pharmacy 002 treatment administration message VXO query for vaccination record VXX returning multiple PID matches V03 VXR vaccination record hange Description Message added
133. from TN to XTN Optionality changed from C to O Optionality changed from O to C Optionality changed from C to O Optionality changed from O to C Length changed from 200 to 400 Data type changed from CN to XCN Field name changed from Parent Number to Parent Health Level Seven Implementation Support Guide Page 5 17 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Segment Seq Change OBR 35 containers collected sample OBR 39 Length changed from 60 to 200 OBR 40 Transport arrangement SE Le NE OBR 43 Planned patient transport comment ODT 2 RQD 2 RQD 3 Item code external Dept cost center Item natural account code Manufactured ID Manufacturer s catalog RQ1 4 Vendor ID RQI 5 Vendor catalog ao p pO HA A EJ Length changed from 3010 60 jl EA EA m i Po We EA EA Ei Length changed from 30 to 60 Optionality changed from O to C Optionality changed from O to Optionality changed from O to C table 0319 table 0320 Optionality changed from O to Optionality changed from O to Optionality changed from O to C Optionality changed from O to C Length changed from 12 to 200 Optionality changed from C to O Optionality changed from C to O Change EZ Requested dispense code Requested dispense amount Optionality changed from C to O Optionality changed from C to O EA EH E
134. introduction to the HL7 Specifications G 9 1 3 What Application Architecture is HL7 Based on It tries not to assume a particular architecture with respect to the placement of data within applications In particular it is designed to support a central patient care system as well as more distributed environment where data resides in departmental systems There is support for environments where there is no order entry system a central order entry system or multiple systems that can originate orders There is support for environments where results data and observations reside on a single system or where they are distributed among several systems Adapted from the introduction to the HL7 Specifications G 9 1 4 What is Implied by the Phrase Level Seven The term Level 7 refers to the highest level of the Open System Interconnection OSD model of the International Standards Organization ISO In the OSI conceptual model the communications functions are separated into seven levels Those developing the HL7 Standard are primarily focused on the issues that occur within the seventh or application level These are the definitions of the application data to be exchanged the timing of the exchanges and the communication of certain application specific errors between the applications Specifications at this level are referred to in the HL7 argot as abstract message specifications However as a matter of pragmatic necessity the HL7 specific
135. is available as LNC1MDB ZIP The database was created using Microsoft Access 2 0 Y The LOINC Users Guide is also available both as a WordPerfect 6 0 or Word 95 file The Users Guide this document explains the structure of the database its rationale and the rules we used for naming test results It is not compressed d Brief Users Guide The introduction to the Users Guide is available as a separate ASCII text file Y RELMA In addition to the basic LOINC files we also produce a Windows based mapping utility called the Regenstrief LOINC Mapping Assistant RELMATV This program is also available for free use and may be downloaded from http www mcis duke edu standards termcode relma zip The RELMA package includes the LOINC table in the database plus several large index tables Zipped the program and database files exceed 12M not including the manual Note that you must unzip the LOINC database after running the SETUP EXE program All of the RELMA files will need almost 80 meg of disk space 4 RELMA Users Guide There is a separate Users Guide documenting the RELMA program which is included in this ZIP file We welcome corrections or extensions to the database We are not interested in adding terms that might be needed in some future situation but we are interested in adding test observations that are actively being reported today Appendix C provides instructions about submitting new terms Clem McDonald MD Stan Huff Chai
136. it is necessary to provide a fault tolerant environment in order to eliminate or minimize the potential of downtime 1 Describe what attributes you deem important for fault tolerance when implementing the AIE product 2 Whatlevels of fault tolerance are available for the recommended platform 3 Can fault tolerance be incorporated incrementally e g disk mirroring disk duplexing etc 4 What auditing features are available for tracking faults 5 How are staff members alerted to faults 6 How is the hardware vendor alerted to faults 7 Does the system automatically detect faults and reroute to backup systems 8 Can faults be corrected dynamically or is down time and or operator intervention required for servicing 9 Describe how the system provides continuous up time 10 Does can the system utilize swappable Components as its redundancy mechanism What components can utilize this form of redundancy Is this hot swappable 11 Does the system utilize shadowed disks 12 Does the system contain a redundant power supply 13 Describe how the fault tolerant features of the system can be phased in F 1 8 7 Backup Restore Journaling System Recovery In the event of disk damage downtime or corruption to data files or disaster recovery circumstances the system must be capable of performing backups and restores In a traditional environment this requires the system to be dormant for a period of time in order to b
137. many paragraphs of text We are aware of two deviations from this specification that have been frequently implemented Both were legal in version 2 1 e Some sites agree to have the textual material sent as one line of text per OBX This minimizes the size of a single segment In this case the universal service ID repeats in each successive OBX Changes in the suffix of a universal service ID is one way to separate segments under this scheme e Some sites send the report without distinguishing the sections This is frequently done where the reports are transcribed from dictation with no systematic enforcement of section names Both variations may occur together Version 2 3 offers additional support for tracking the transcription through its stages from initial dictation to final approved report This includes the ability to send the voice embedded in an HL7 message Refer to HL7 Version 2 3 Chapter 7 for details Wes Rishel and Clem McDonald Health Level Seven Implementation Support Guide Page G 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions G 7 3 G 7 4 Page G 8 Where Does the Accession Number Go in a Lab Order There is no explicit place for it although it is frequently used as part of the filler s order number In this case it is combined with some additional characters to ensure that the order number won t repeat when the accession numbers recy
138. master station may send another block or it may terminate If the reply is negative the master station immediately retransmits the block that was not accepted The numbers in parentheses in the following discussion refer to Figure C 3 Health Level Seven Implementation Support Guide Page C 15 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 3 3 1 Transmission Blocks The transmission of blocks is initiated by the master after a master slave relationship has been established If the message has a heading See section on Headings the master station begins the transmission with SOH 2 If the message has no heading 3 the master station begins the transmission with STX 4 An intermediate block that continues a heading 7 2 is started with SOH An intermediate block that either begins or continues a text 7 3 4 is started with STX If the last information character of a heading ends on a block boundary ended by ETB the subsequent block may be started by either SOH or STX Note that in such a case the receiver must be able to handle both situations ESTABLISHMENT PROCEDURE MESSAGE TRANSFER PROCEDURE TERMINATION PROCEDURE Prefix 8 10 Invalid or no reply 13 To recovery 7 procedures NOTE Crosshatched area is slave response Figure C 3 Message Transfer for Procedure A block that ends at an intermediate point within the me
139. message Both the single and multiple byte characters use only the low order 7 bits in JIS Kanji code with JIS X 0202 in order to ensure transparency over all standard communication systems When HL7 messages are sent as JIS X 0202 all HL7 delimiters must be sent as single byte ASCII characters and the Health Level Seven Implementation Support Guide Page 1 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 1 Introduction 1 5 2 1 5 3 Page 1 4 escape sequence from ASCII to Kanji and back again must occur within delimiters In most cases the use of Kanji will be restricted to text fields There are other parts of the JIS X series that support Katakana JIS X 0201 ISO IR 13 Romaji JIS X 0201 ISO IR 14 and Kanji JIS X 0208 ISO IR 87 and JIS X 0212 ISO IR 159 that can be used in HL7 messages in the same manner as JIS X 0202 c In the case that a single country uses conflicting rules for representing multi byte characters it is up to the communicants to ensure that they are using the same set of rules The encoding rules distinguish between data fields that have the null value and those that are not present The former are represented by two adjacent quotation marks the latter by no data at all i e two consecutive separator characters The distinction between null values and those that are not present is important when a record is being updated In the former case the field in the datab
140. message transactions and disconnects If there is a send or receive error it disconnects Connect errors and Health Level Seven Implementation Support Guide Page C 29 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols send or receive errors must be passed back to the application in a suitable form In particular receive time outs should be detected and reported do call until successful or too many retries status call network address if status OK break out of loop if successful break retries retries 1 sleep for configurable of seconds 1 sec while retries gt 0 if status OK return if calls failed return status while messages to send to this destination status send next message send the message if status OK goto disconnect status receive reply get the reply if status OK goto disconnect application code to process reply disconnect disconnect disconnect if error or done return status C 6 2 Accepting Modules The following pseudo code shows the procedure that the accepting task uses The task first puts up a listen When the listen completes successfully it receives the initiating message The message is passed to the application which generates a reply message The reply message is then sent back The accepting task receives messages until it is disconnected
141. n lt SIMIHIDIW gt where n is a number possibly a decimal S denotes seconds M denotes minutes H denotes hours D denotes days and W denotes weeks The time delay can be preceded by a greater than gt sign e g gt 4H Table 4 lists some possible values for time difference but any time specification that follows the above syntax would be legal The second subpart can also be used to specify the ordering of specimens e g 1ST SPECIMEN 1 2ND SPECIMEN Use this syntax to indicate pre and post immunization specimens acute and convalescent specimens or a series of specimens for which no more detailed information is available More general terms of the form analyte POST CHALLENGE are available to transmit information about challenges for which pre coordinated terms do not exist in the LOINC database The second subpart is also used to describe measurements taken at a specified point after the beginning of an ongoing treatment such as peritoneal dialysis e g CREATININE 12H POST PERITONEAL DIALYSIS Health Level Seven Implementation Support Guide Page H 17 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC Table 4 Time Delay Post Challenge Baseline time just before the challenge The time post drug dose at which the highest drug level is reached differs by drug The time post drug dose at which the lowest drug level is reached varies with drug Time from the ch
142. need to be complete messages of any particular type The message can consist of just a valid MSH segment with appropriate headers and trailers Similarly the reply message can be an acknowledgment message consisting of just the MSH and MSA segments with appropriate headers and trailers Page C 28 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols C 5 10Responsibility for Initiating Synchronization The receiving system never initiates the synchronization of a link Note Sequence numbers will range from to 2 billion C 5 11 Acknowledgment Codes C 6 The following are the acknowledgment codes for Initiating Application Accepting Application messages using sequence number protocol AA As described in the HL7 Specification AR In addition to the uses described in the HL7 Specification this code is used to signify sequence number errors AE As described in the HL7 Specification this code is used to signify that the message passed all checks which would cause an AR code but could not be processed for some other reason Note In the case of an AE or an AR the sending system will determine the appropriate action PSEUDO CODE FOR HL7 TCP The following is pseudo code for circuit control and message passing by initiating and accepting software modules Two types of virtual circuits are used to exchange data tr
143. of response time p Maximum acceptable software and hardware support response time q Definition of escalation procedures r Incorporation of specification in the RFP as part of the contract s Assignment clauses t Source code escrow options and invocation criteria u Verification that the software has no key locks or software disabling capabilities v Disclosure of all third party relationships w Warranty of ownership and or right to sub license e Describe the contracting options that you offer to your clients e Will you stipulate that your contract will be entered into under and governed by the laws of the State of state e How and when before or after the contract is signed are the detailed specifications for each system developed Can installation costs be changed based on these specifications Do both parties sign off on specifications When is this done e Is your company willing to post a performance bond to insure successful installation and operation e Will you contract fixed prices for software systems which are currently under development and not yet installed e Will you support the re incorporation of custom modifications done for St Anybodys Medical Center into all new software releases e What is your company s position regarding the inclusion of a 30 day cancellation clause in your contracts 2 Warranty a Please provide a copy of your standard hardware and software warranty b If yo
144. of the same code Health Level Seven Implementation Support Guide Page E 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 SAMPLE RFP FOR AN APPLICATION INTERFACE ENGINE This appendix contains a Request for Proposal RFP for the selection of an Application Interface Engine AIE for the fictitious St Anybodys Medical Center The RFP is meant to serve as a model for developing your own RFP Successful selection of an AIE is dependent upon how well the requirements in your RFP reflect the needs of your environment and on the evaluation of the product s ability to meet these requirements Several paragraphs of the model RFP have been left blank These sections are purely site specific and it is left up to members of the organization to determine what information should be included Most of these paragraphs are in sections II through V These sections contain a description of the organization its systems its strategic direction how the selection process will be conducted and how the AIE will be implemented Italicized words in the RFP are meant to be substituted with words appropriate to the organization and the selection process Health Level Seven Implementation Support Guide Page F 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates St Anybodys Medical Center Request for Proposal for an Application Int
145. on J 3 7 18 00887 FillerContact Address XAD a TI S 19 00888 FillerContactLocation PL 890 4 A 20 00878 EnteredByPerson R xmn a S 9 21 00879 Entered By Phone Numer XTN w Os 22 00880 Entered ByLocation r on TI S 23 00881 Parent Placer Appointment ID E C59 0 24 O0882 ParntFillrAppoinmenID EI 759 ss 25 00889 FillrSttusCode CT ew Jg 0278 Page B 54 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 93 SPR Stored Procedure Request Definition 1 00696 QueryTag d ST GD j A4 0 S 9 2 00697 Query Response Format Code R ID D O Sow Eo o ee 3 00704 Stored Procedure Name R CE 60 4 00705 InputParamterList Col Q59 CTT B 1 94 STF Staff Identification 1 00671 STF PrimayKeyVale R l o ooo S S 2 0062 StaffIDCode LL LO 0 jp 3 00673 SuffNam XPN a j 49 4 00674 StaffType OA I Q2 C0J c J 18 5 jo Sx I D j 2 oo L 35 9010 Dareo
146. operations 4 2 10 3 Load Relational Database Product 4 2 10 3 1 Raw Disk Requirements 4 2 10 3 2 Log data master device locations 4 2 10 3 3 Install SQL Server Software 4 2 10 3 4 Create databases 4 2 10 3 5 Create dump devices 4 2 10 3 6 Create logins Health Level Seven Implementation Support Guide Page F 63 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 4 2 10 3 7 Setup Replication srvr components 4 2 10 3 8 Develop Automatic Dump Log Scripts 4 2 11 Install Lab Vendor Software 4 3 Workstations and Software All Sites 4 3 1 Order Workstations amp software 4 3 2 Receive Workstations 4 3 3 Workstation Setup each 4 3 3 1 Load Software 4 3 3 2 Configure Workstation 4 3 3 3 Connect to Network 4 3 3 4 Test Access to Mainframe if necessary 4 3 3 5 Test Access to Minis if necessary 4 3 3 6 Test Access to UNIX box if necessary 4 3 3 7 Test Access to Novell Server or other Network product 5 STANDARDS DEVELOPMENT 5 1 Create Standards Document subjects see below 5 1 1 First Draft 5 1 2 Final Release 5 2 Documentation Standards 5 3 Project Plan Standards 5 4 Development Environment 5 4 1 Directory Structure 5 4 1 1 Test Environment Directory Structure 5 4 1 2 Interface Engine Development Directory Structure 5 4 2 Quality Assurance Standards 5 4 3 Version Control Standards 5 5 Hardware Standards Page F 64 Health Level Seven Implementati
147. order to effect a normal termination of the transmission End current master slave transmission relationship e EOT is sent by a master station prior to the completion of the message transfer phase in order to effect a sending station abort function Sent between blocks of a multi block message e EOT is sent by a slave station in place of ACK NAK in order to effect a termination interrupt function It serves to NAK the current block and causes the current master slave relationship to be ended Enquiry ENQ is used to request master status e ENQ is used to solicit a response from a remote station e ENQ may be used to obtain identification of the remote station e ENQ is the last character of a polling or selection supervisory sequence s ENQ is used by the master station in block abort procedures Negative Acknowledgment NAK is transmitted as a negative response to the sender e NAK is used during the establishment phase to indicate that the station is not ready to receive e During message transfer NAK indicates that the last message or transmission block wasnot accepted but the station is ready to receive Acknowledgment N ACKO is transmitted during the establishment phase as a response indicating a readiness to receive become slave ACKN is transmitted by a slave station as a numbered affirmative reply to a transmission block ACKI is sent as a reply to the first block after the establishment phase ACK2 is
148. property The new kinds of property are what you might expect from the new kinds of dimensions being measured e g resistance voltage work per beat However we have also introduced three important new properties ANAT isa special case of PRID or taxon which applies to anatomic sites only IMP impression is a diagnostic statement always an interpretation or abstraction of some other observation a series of test results an image a total patient and almost always generated by a professional We could also consider the EKG carte automated diagnoses as impressions Impressions are used in laboratory medicine as well as clinical medicine so you will see them appearing there as well FIND Finding is an atomic clinical observation not a summary statement as an impression Physical historical review of systems and other such observations have a property of Finding These may have a scale of NOM for coded findings or NAR for findings reported in narrative text In clinical measures super systems the second subpart of the system component is widely used For example we distinguish a head circumference of the patient versus a fetus as follows CIRCUMFERENCE LEN PT HEAD CIRCUMFERENCE LEN PT HEAD FETUS QN 4 2 Atomic versus molecular pre coordinated names With clinical terms we almost always have two ways of reporting Using the first we can report an observation by Page H 38 Health Level Seven Implementation Support Guide Fin
149. replied to the next block Sequencing continues through ACK7 and then wraps to ACKO C 3 1 5 Block Number A block number BLK is used to sequence message blocks It immediately follows the first start of block delimiter SOH or STX The BLK character is a single ASCII numeric character that varies from zero through seven The first transmission block after establishment of master slave is Page C 12 Final Version 6 98 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols assigned the numeric character one hex 31 Subsequent transmission blocks will use sequential numbers 2 3 4 5 6 7 0 1 2 etc The BLK character is added by the transmitting station and is functionally deleted by the receiving station It is not considered as part of the end to end heading or text The BCC must be correct before BLK is used to determine proper block sequencing BLK is reset to one upon a timer D timeout or upon transmission or reception of EOT C 3 1 6 Text Length The Text Length TL is the number of bytes of message text that are present in the block It immediately follows BLK and is a decimal number in ASCII characters It is always 5 characters long right justified zero filled See the example message below C 3 1 7 Block Checking Characters Two block check characters BCC are added at the end of each transmission block to facilitat
150. responses 6 Begin Date End Date Complete vendor evaluations and select systems for further review 7 Begin Date End Date Conduct vendor demos 8 Begin Date End Date Conduct site visits 9 Date Select vendor of choice F 1 4 Current Operational and Technical Environment F 1 4 1 Current Information Systems Environment The current systems environment is The primary development language is F 1 4 2 Strategic Technological Direction St Anybodys Medical Center is pursing a strategy of selecting best of breed solutions especially those with good interoperability characteristics This strategy anticipates solutions built on standards and protocols or systems with the ability to intemperate with system built on standards and protocols The strategy favors robust platforms with good to excellent fault tolerance scaleable architectures and broad networking options Included in this direction is implementing An Application Interface Engine AIE e A Common User Interface CUI Connectivity to community physician systems Page F 6 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 O 1998 All rights reserved Appendix F Sample Templates F 1 4 3 Application Systems Environment Applications currently supported include RELEASE HARDWARE FACILITY S USING APPLICATION VENDOR PRODUCT NAME VERSION PLATFORM THIS SYSTEM COMMENTS ADT OP Registration Medical Records Patient Billing
151. s are underlined Header lt CR gt MSH segment lt CR gt 150 char segment lt CR gt 200 chars lt CR gt 200 chars lt CR gt 200 chars lt CR gt 200 chars lt CR gt 200 chars lt CR gt lt CR gt Trailer lt CR gt The carriage returns at the end of most HL7 segments mean that most of the time no carriage returns will need to be stuffed Notice that at one place there are two carriage returns in a row The first is the stuffed carriage return the second is the carriage return that is part of the HL7 message Even if a carriage return is stuffed where there already is a carriage return in the message the carriage return that is part of the original message must still be transmitted The receiving system will receive the data and note where 200 charsacters in a row appear without a carriage return It then knows that the next character is a stuffed carriage return and should be thrown out This recreates the original block Flow Through Processing The HL7 Standard may be applied in situations where queries will be made on behalf of a user who is waiting to view the response at a terminal In such cases the communicating applications and implementations of the higher levels may agree to overlap transmitting the early portion of the response with the retrieving and formatting of later portions so that the user can view the initial part of the message before the entire message has been sent This section describes an option that suppor
152. selection criteria parameter class codes 0295 Handicap 0296 Page 5 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Point of care 0304 Bed 0305 Person location type 0306 Location status 0307 Building 0308 Floor 0309 Coverage type 0311 Job status 0312 Policy scope 0313 Policy source 0315 Living will 0316 Organ donor 0317 Annotations 0319 Department cost center 0320 Item natural account code 0321 Dispense method 0322 Completion status 0323 Action code 0324 Location characteristic ID 0325 Location relationship ID 0326 Visit indicator 0327 Job class 0328 Employee classification 0329 Quality method 0330 0331 Facility type 0333 0334 Disabled person 0335 Repeat pattern 0336 Referral reason 0337 Certification status 0338 Practitioner ID number type 4001 Repeat pattern Health Level Seven Implementation Support Guide Page 5 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview 5 3 2 Changes To Existing Tables Table Table Name Description of Change 0003 Event type code Added the following values A38 M03 M08 RAR RDR RER RGR ROR POS PO6 Q03 S01 S05 T01 TO9 V01 V04 WO1 W02 X01 0017 Added the following suggested values CG CD PY AJ 0036 Table deleted 0038 Added the following value A 0048 What
153. staffing and organization Page 2 6 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved 2 6 1 2 6 2 2 6 3 2 7 Chapter 2 Planning Methodology Organizational Considerations Consider and document the potential impact of the overall systems direction on current organization structure and human resource policies and procedures For example will new jobs positions be required or will existing jobs positions be changed as a result of the selected system s architecture user and MIS Assess the ability of the organization to undergo the operational changes enabled by implementation of any system s Based upon this assessment develop an action to facilitate this process In addition establish an organization that will help the organization maximize system benefits Consider and document the potential impact of a different overall systems strategy in terms of data ownership integrity and responsibility This may have implications related to the division of traditional systems responsibilities between MIS and user departments For example establish or change responsibilities for systems development and maintenance to reflect the overall system s direction Project Staffing And Organization Identify the necessary personnel skills and resources to implement and operate maintain the new system s and establish plans to obtain these skills and resources Als
154. such program named Filter is used to scan the information looking for duplicates with existing LOINC tests errors and similar inconsistencies The output of Filter can be printed and RI may send you a copy of the Filter program output as part of our communication with you The purpose of this section is to explain the information that is presented in the Filter report Table21 Filter Reports SUBMITTER SMITH FILE TEST MDB DATE SUBMITTED 2 98 14911 LOINC RECORDS Index Comment LOINC Component Property Time System Scale Method 1 Hit 5 of 8 micromol L A123 5 HYDROXYINDOLEACETATE SCNC PT UR QN ADD 5 HYDROXYINDOLEACETATE SCNC PI UR QN 5 HYDROXYINDOLEACETATE MCNC PT UR QN 5 HYDROXYINDOLEACETATE MCRTO PT UR QN CREATININE At the beginning of Line 1 Table 21 is the index number which is actually the value stored in the REGEN ROW field of the submitted database after being processed by the Filter program Next is the comment Hit 5 of 8 Each submission record is decomposed by the filter program into words For the submission with the local code name of A123 which you can see in Line 1 there were six words 5 HYDROXYINDOLEACETATE SCNC PT UR and QN Notice that hyphens as well as several other special characters are temporarily ignored by Filter when the words are parsed Therefore Filter sees six words in the submission with a local code of A123 Table 21 also
155. test is run on a combination of types of system such as a ratio of substance found in CSF and plasma the codes are joined with a CSF PLAS CSF SER etc We will be specific about the type of system to distinguish at least among blood urine cerebrospinal fluid pleural fluid synovial fluid and peritoneal fluid Details about the exact source and collection method e g blood drawn from the right arm and maintained on ice are not a proper part of the test name and are reported in other parts of the message e g OBX and OBR of the HL7 definition Page H 26 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved AMN ANAL ASP BPH BIFL BLDA BBL BLDC BLDCO BLDMV BPU BLDV BON BRAIN BRTH BRO BRN CALC CDM CNL CTP CSF CVM CVX COL CNJT CUR CRN CYST DENTIN DIAFP DIAF DOSE DRN DUFL EAR EARW ELT ENDC ENDM EOS RBC EYE EXG FIB FLT FIST Abcess Amniotic fluid Anus Aspirate Basophils Bile fluid Blood arterial Blood bag Blood capillary Blood cord Blood Mixed Venous Blood product unit Blood venous Bone Brain Breath use EXG Bronchial Bum Calculus Stone Cardiac muscle Cannula Catheter tip Cerebral spinal fluid Cervical mucus Cervix Colostrum Conjunctiva Curettage Cornea Cyst Dentin Peritoneal Dialysis fluid Dialysis fluid Dose med or substance Drain Duodenal fluid Ear Ear wax ceru
156. that since midnight the ADT system has been in a loop trying to resend the same faulty admission Careful attention to detecting and dealing with errors intelligently is critical to a successful interface Frequently the analysts will decide they need to add fields to an existing message or add new messages If you are developing an in house interface how much recoding and testing will be required The ideal is to drive the contents of messages from tables and give the analysts the tools to change these tables without any reprogramming If you are receiving HL7 transactions remember that the sending system is allowed under HL7 to add new information to messages and your program must accept the messages with no programming changes whatsoever Your program may not store the information in the database if the field was added after the message was implemented But it must not fail or reject the message A standard method for testing for amateur hour interfaces is to add a field on the end of a segment and see if the receiver complains or crashes Is There Software Available to Help Build HL7 Interfaces There are several HL7 toolkits available for those developing HL7 interfaces in C or C 1 Gunter Schadow of the Universitaetsklinikum Steglitz Berlin has developed a C class generator called ProtoGenHL7 His home page is lt http fub46 zedat fu berlin de 8080 gusw gt 2 The author has not tried it but it seems an order of magnitude
157. the HL7 interface s 2 9 2 3 Software Modification Review Identify any modifications to the vendor s application software which will be required to enable the HL7 interface s Estimate the cost of required modifications as well as the impact on the application system functionality Identify those modifications that could be handled by an interface engine and estimate the effort to configure the engine in house or the cost to contract that effort out to the vendor Health Level Seven Implementation Support Guide Page 2 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 3 Implementation Methodology 3 1 INTRODUCTION The implementation methodology outlines key activities that should be considered and planned for when developing and or implementing an HL7 interface It also includes some activities specific to the installation of an interface engine It begins with the design and development activities involved in creating an HL7 interface then outlines the planning steps required for an organization to install and support HL7 interfaces HL7 as a specification provides a guideline to develop and implement interfaces between various applications The implementation of these interfaces will be specific to the site and applications involved It is therefore necessary for the health care organization implementing HL7 interfaces to manage the application of the HL7 specification with all parties involved H
158. the length of a segment Many languages or operating systems have terminal oriented input disciplines that place a limit on the number of characters that can be received before they must receive a carriage return character To overcome this problem Carriage Return Stuffing may be used If a certain number of characters has been transmitted without a carriage return the sending system inserts a carriage return character into the output stream The receiving system is also counting characters from the last carriage return seen If the limit is reached the receiving system knows that the next character is a stuffed carriage return and must be removed from the data Stuffed carriage returns are not used in calculations of block length or checksum The line length for carriage return stuffing is configurable on a site specific basis As an example consider an imaginary HL7 message with a 150 character segment and a 1000 character segment Suppose that the maximum numbers of characters that can be received without a carriage return is 200 Then the original message will look like this Header lt CR gt MSH segment lt CR gt Health Level Seven Implementation Support Guide Page C 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 2 5 C 2 5 1 150 char segment lt CR gt 1000 char segment lt CR gt Trailer lt CR gt The transmitted data will look like this stuffed lt CR gt
159. the need for a method of reporting by panel and by multiple answer mechanism The LOINC database provides observation names for both kinds of reporting B AG ACNC PT RBC BPU ORD AGGL RBC ANTIGENS ABSENT PRID PT BBL BPU ORD The LOINC database provides other observations for reporting the status of each blood pack e g held given discarded and for reporting that information when HIS and medical records systems want it how much of each type of blood product was given at a moment in time the type of each pack any adverse reaction to that pack and the pack number to accommodate laboratories that send this information as discrete observations BLOOD PRODUCT DISPOSITION TYPE PT BPU NOM BLOOD PRODUCT TYPE TYPE PT BBL NOM 3 3 Immunocompetence studies The T cell markers in the LOINC database include all of the single markers and the most commonly reported combinations e g CD10 CD20 Most of these are really measuring the number or percent of lymphocytes which bear the specific T cell marker pattern So they should be specified as a subtype of a lymphocyte e g Lymphocytes CD10 CD20 Health Level Seven Implementation Support Guide Page H 33 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC Two kinds of measures are of interest The absolute number of such cells per cubic millemeer These are represented as number concentrations e g Lymphocytes CD10 CD20 NCNC PT BLD QN
160. the property when the evaluation is a mental abstraction based on one a collection of measurements and or data For example if several measurements are made relative to immunoglobin levels in SERUM and CSF in a myasthenia gravis panel and if by examining all of the evidence a pathologist decided that this pattern of findings represented active disease which could be represented as a coded value the result of the pathologist thought process would be represented as Possible Values text Property Precision Myasthenia Evaluation No disease chronic disease IMP NOM Page H 56 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 If the pathologist evaluation was free text or a paragraph of information the representation would be Myasthenia Evaluation No disease chronic disease IMP NAR 12 Methods are only used to distinguish things that are identical in the other five LOINC fields but may differ because the sensitivity or specificity is different for the given methods 13 Need to be careful in distinguishing end point detection method from property For example if sodium is measured using an ion specific electrode the property is not a voltage difference The voltage difference is just a method for indirectly measuring the sodium concentration Concentration is the real property Likewise many antigens and antibodies are now mea
161. the user to interface with the system software 4 Supporting mapping services e g providing common screen layout and function key services for all users regardless of the application or system 5 Supporting hot key services e g the ability to maintain multiple sessions and switch back and forth between applications 6 Supporting windowing services e g the ability to display multiple sessions on the screen at once with cut and paste features 7 Supporting object oriented graphical user interface e g a client server application where data from multiple application processors is retrieved and processed at the user workstation for display based on a user sign on 8 Ability to monitor the AIE remotely e g availability of multiple or remote console If the environment is distributed can all the processors be seen in one window F 1 7 7 Standard Interfaces Health Level 7 HL7 is a standard for interfacing health care environments The focus of HL7 is the seventh layer the application level of the System Interconnection OSI model of the International Standards Organization ISO As such HL7 has focused on communication issues related to the definition and format of data to be exchanged and to the timing of the data exchange St Anybodys Medical Center is committed to using HL7 for standardization of all interfaces However some of its current systems require proprietary system interfaces St Anybodys Medical
162. then takes the reader through vendor evaluation and selection The implementation methodology begins with interface design and continues through to interface testing and conversion Multiple vendor systems can be implemented using the HL7 Standard Point to point interfaces can be implemented with a direct physical connection or over a shared physical connection such as a LAN Interfaced applications from disparate vendors may even reside on the same CPU Linking applications in any environment requires the development of interfaces This component of the methodology has been developed in a manner that is intended to be comprehensive enough to be utilized in both types of environments In addition to addressing some of the general issues associated with any type of systems planning project the methodology also addresses many of the planning issues specifically associated with implementation of an HL7 environment and developing interfaces in this type of environment The methodology has been enhanced to include the evaluation and implementation of interface engine products There is a broad array of interface engine products now in the marketplace offered by both HIS vendors and niche vendors These products have been growing in popularity and usage as they can facilitate the integration of multiple systems Interface engines can address the problems created by vendors speaking different flavors of HL7 as well as vendors who do not support HL7
163. this point forward and adjustments made as necessary depending on the project s progress Testing Acceptance Alert all vendors beforehand to your testing dates so that they can schedule the required resources to support you during the testing phases Conversion Testing Test all conversion processes both automated and manual Compare actual results to expected results Validate actual results during the functional interface and parallel testing activities Functional Interface Testing Functional interface testing involves testing the data flow from all systems through the interface s to the receiving system This will take on various forms depending on whether the system includes a series of point to point interfaces or uses a broadcast store and forward machine Interface testing and interface engine configuration testing will be closely linked as it will be difficult to test interfaces without the interface engine and vice versa Stress Volume Testing Following functional testing the interfaces and the interface engine if applicable should be stress tested by simulating peak transaction volumes Carefully monitor interface throughputs during the test to assess the interfaces and interface engine s abilities to keep up during peaks in transaction processing Restart Recovery Testing Using restart recovery procedures developed in section 3 6 6 2 2 force downtime situations and recover using documented procedures Paral
164. to a multi vendor environment particularly in a decentralized environment 2 3 2 Performance Measures 2 3 2 1 Develop Benefits Checklist Develop a checklist of criteria for evaluating benefits impacts costs and priorities for the subsequent systems development projects applications Review this information with executive Health Level Seven Implementation Support Guide Page 2 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 2 Planning Methodology management in order to obtain their approval and support This information should be used to help guide subsequent project direction and decisions 2 3 2 2 Establish Benefit Criteria Establish measurement tools and specific benefit benchmarks e g existing baseline measures in order to assess and determine the level of success that is being achieved during the selection and implementation processes 2 4 INFORMATION NEEDS AND APPLICATION REQUIREMENTS The purpose of this section is to ensure that the current systems status and functional requirements of the institution are understood and are being taken into consideration during the planning process During these activities existing and planned transaction volumes should be determined in order to anticipate data storage and communication requirements 2 4 1 Current Status Assessment Information Needs And Systems 2 4 1 1 Document Current Environment Document the overall current systems stat
165. to report values For example blood cell antigens might be presented as a panel with separate tests which report each possible antigen as present or absent if the test is to establish paternity for cross matching the result would be reported as a list of antigens found We try to provide for both methods of reporting in the LOINC databases by including codes for both types of test identifiers The Regenstrief Institute and the LOINC committee will maintain the database while grant support is available at least until January 1 2001 We expect to find longer term support or another home for the database before then The LOINC database which identifies over 13 000 different lab tests and clinical observations and supporting documentation is available through the Duke standards Internet site Anonymous FTP and Gopher access is available at www mcis duke edu The LOINC database and accompanying files are in the directory standards termcode loinclab The World Wide Web URL http www mcis duke edu standards termcode loinc htm provides links to all the LOINC files The LOINC databases are stored in a number of file formats In each of them the first part of the file contains the copyright notice with permission to use the database for any purpose without charge or written permission We have copyrighted the databases and this document to assure that multiple variants of the codes do not emerge Having many variants would defeat the purpose of a univ
166. usually reported per low power fields smaller entities per high power fields Page H 36 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 The other way such entities are reported is as a pure ordinal e g none few moderate loaded These would be specified as ACNC properties with ordinal scale e g ERYTHROCYTES ACNC PT URNS ORD MICROSCOPY LIGHT 3 8 Skin tests These follow the pattern of a challenge test For a TB skin test 1t would be TUBERCULOSIS REACTION WHEAL 3D POST 25 U TU ID LEN PT SKN QN Where TU means tuberculin units ID means intradermal LEN indicates a measure of length the diameter of the wheal and so on 4 Clinical observations and measures 4 1 Introduction For most of the measures we include separate observations for summary data e g shift and twenty four hour urine output totals We also provide varying degrees of pre coordination for the observation the body site at which it was obtained and the method E g a cardiac output based on the Fick method is distinguished from a cardiac output computed from 2D cardiac echo data Physiologic measures are often monitored continuously over time and the instrument reports summary statistics over that reporting period For vital signs these can include minimum maximum and mean value over a time period For intake and output the total is the summa
167. utilized may vary For example an application supporting a problem oriented view would be sent the Problem Oriented Add Delete Update query whereas a application supporting a goal oriented view would be sent Goal Oriented add delete update query messages Health Level Seven Implementation Support Guide Page 5 33 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 1 HL7 TRANSACTION CHECKLIST The message transaction checklist documents the trigger events and messages defined by Version 2 3 of the HL7 standard The checklist contains e acover sheet describing the products being interfaced and the general characteristics of the interface e a message checklist to help establish which HL 7 transactions will be used in the interface who will be the originator of each message the required and optional segments that will be sent in each of the messages e a detailed list of all HL7 segment types identifying by field sequence number item number field name required field indicator or placeholder for selecting optional fields data type field length gt maximum used gt maximum allowable repeating field indicator or placeholder for maximum number of repetitions variable name assigned to field on the sending system variable name of field on the receiving system table number if applicable notes The checklist can be used during the development of an HL7 interfa
168. we have shift totals and 24 h totals and event counts on physiologic monitors such as the number of premature ventricular contractions PVCs over 24 h on a Holter monitor The allowed values are defined as a syntax exactly like the syntax for the times in challenge tests e g numeric value SIMIHIW The most common one is 24H Table 8 gives some other examples For 24H urine collection is the standard integrated measure and these are almost always reported as mass MRAT amount of substance SRAT or catalytic CRAT rates These would contrast with spot or random urines which are represented as point PT measures in our nomenclature and usually reported as concentrations MCNC CCNC or SCNC for mass catalytic and substance concentrations respectively However we can also report the average concentration on a 24 hour specimen and a 24 hour average concentration must be distinguished from the point concentration The designation of 24 h collection is maintained for tests that traditionally have reference ranges based on amount of substance of a component cleared or excreted in 24 h However a given specimen could have a 23 h collection time and would still be called as a 24 h study Depending upon the policies and procedures of the lab they might extrapolate the reported value to what it would have been if the collection was the full 24 hours and report it as moles per day We allow indirect specifications of a time window STDY ide
169. 0 56 4 Assumptions and Guidelimes ee Ai ds diete At C 31 APPENDIX D HELPFUL HINTS D t INTRODUCTION teinte ret rrt a id D 1 D 2 VENDOR NEGOTIATIONS FOR HL7 INTERFACES eee D 1 APPENDIX E SAMPLE CASE STUDIES RI INTRODUCTION edem aere NIE PRA Deele E ENSE EUER Ad I UHR ERAS E 1 Ez e ERT E EE E 1 E 2 1 B gmiing Ob PLO E E 1 E 2 2 Th Project Management Process sese seer E 1 E 2 3 The ADT and Charge Interface Projects sss sees E 2 E 2 4 HET and TCP IP Implementation sss sees sees sese eee eee E 2 E2 5 Tunoctonal Requirements ia E 2 E 2 6 Implementation E EE EE E 3 Beet The EE E 3 Page TOC 16 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Table of Contents HL7 Implementation Support Guide APPENDIX F SAMPLE TEMPLATES F 1 SAMPLE RFP FOR AN APPLICATION INTERFACE ENGINE eee F 1 ELE Introduction EE F 3 F 1 2 Background and Strategic Direction sss sees F 4 F 1 2 1 Current Environ it F 4 IS UAC SIC K e STT F 4 F 1 3 Instructions Scope and Methodology sss sss seene F 4 F 1 3 1 Project Objectives and Scope of the Request for Proposal F 4 F 1 3 2 Vendor Reourements lnstructons eese ener F 4 FA Number OL Proposals uud on ote epic bee edo que toca a AA F 5 I L34 Projet Re EE F 6 F 1 4 Current Operational and Technical Environment F 6 F 1 4 1 Current Information Systems Environm
170. 00044 Date Time Selection Qualifier ID 19 TI Ce 9 00694 When Quantity Timing Qualifier Col en ITT Page B 46 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 80 RDF Table Row Definition 1 00701 Number ofColumnsPerRow R NM S 7 2 00702 Column Description R ro w CTT y B 1 81 RDT Table Row Data 1 00703 CoumnVale R Var Variable _ __l__ B 1 82 RF1 Referral Information 1 01137 RefemlSaus JL CE Q0 URT 2 01138 Referral Po CE Q0 Coupen 3 01139 Referral Type CE Q0 URU 4 01140 Referral Disposition IL CE ew 2 URT 5 01141 RefemlCaegry l Q0 0 6 01142 Originating Referral Identifier R EI eo Po o J S 7 01143 BffectiveDate TS 5 0 0 5 8 01144 ExpirationDate TS 9 0115 ProcessDate TS E HE 10 01228 Reie Keen CE Q0 o 0336 11 01300 ExtemalRefemalldenifier a 609 C Jo Jo oy Health Level Seven Implementation Support Guide Page B 47 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 S
171. 00431 Insurance Co Contact Person XPN 489 III y 7 00432 Insurance Co Phone Numer XTN on ss 8 0433 GroupNumber JL ST D S 9 0434 GroupName oul aw S 10 00435 InurdsGrupEmp DD CX a 0 0 0 S 11 00436 InsuredsGroppEmp Nam oul aso ss 12 00437 PlanEffectiveDate LI DT e 5 0 0 S 13 00438 PlanExpirationDate DT j 5 5 0 0 14 00439 Authorization Information CM 659 ss 15 00440 PlanType CT IS GO 5 7 ow 16 00441 Nameoflmued JL XPN a A J 17 00442 Insured sRelationtoPat IS Coupen 18 00443 InurdsDateofBith PIS Ge PP 19 00444 Insured s Address XAD aw II 20 00445 Assignmentof Benefis IS Cer 21 00446 Coordination of Benefits IS Ca 22 00447 Coord of Ben Priority ST 23 00448 No ceofAdmisionFlag ID 0136 24 00449 Notice of AdmissionDate DT ss 25 00450 Rpt of Eligibility Flag DT 26 00451 RptofElgiblityDae DT 8 J 0 0 27 00452 Release Information Code P
172. 00586 SequenceNumber NM ss 2 00642 Derived Specimen ID D Com 3 00643 Container Description IL TX 60 0 4 00644 Container Volume m P T S 5 00645 Container Units CE 60 LI 6 00646 Specimen l Dj 39e 9 2 4 9 7 00647 Additive CE 60 0 S 9 8 00648 Preparation TX aw TI S 9 00649 Special Handling Requirements TX aw ss 10 00650 Normal Collection Volume CQ e J 4 9 S 9 11 00651 Minimum Collection Volume CQ QO 49 S 12 00652 Specimen Requirements TX aw j i 0 0 S 13 00653 SpecimenPriorities ID D C2 0 Con 14 00654 Specimen Retention Tim c on 1 y B 1 62 OM5 Observation Batteries sets 1 00586 Sequence Number NM 2 00655 Test Observation Included with CE 200 Ordered Test 00656 Observation ID Suffixes AR EE B 1 68 OM6 Observations That Are Calculated From Others 8 48 1 00586 SequenceNumber m D UT 2 00657 DerivationRule____________ ___ Tx ow Page B 34 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3
173. 078 EventEndedDat Tim TS Ge TP JJ HET 7 01079 EventLocation Occurred Address XAD ao EA 8 01080 Event Qualification S DT 02377 9 01081 EventSerious 1 ID D 0238 10 01082 EventExpected ID D j y 11 01083 EventOutcome ID D Of BJ Q40 12 01084 PatientOutcome ID D 3 Con 13 01085 EventDescripionfromOthers FT 600 CTT coy Health Level Seven Implementation Support Guide Page B 37 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 14 01086 Event From Original Reporter FT 600 O IT 15 01087 EventDescripionfromPatien TI FT 600 CTT 16 01088 Event Description from Practitioner FT 600 CTT 17 01089 Event Description from Autopsy FT 00 Off h G0 0 29 18 01090 CameofDeah LCE 00 OY 19 01091 Primary ObserverName XPN 49 III S 20 01092 Primary Observer Address RAD a Off 0 S 21 01093 Primary Observer Telephone XIN w LOs 22 01094 Primary Observer s Qualification ID D III Cup ee rtm Poi is c A A 2 L 24 01096 Pri
174. 11 30 9 T Conversion KE EE 3 11 3 6 9 2 Functional Interface Tests uec eot oen eren ehe ceder ae ed tens ed pev Dicas vesica 3 11 3 0 9 3 Stress Vol me Testing oes ine EE ta eve Prae sea eh Lue dd cv a ea S URS 3 11 O Restart Recovery KE EE 3 11 3 0 9 AO oa 3 11 03 0 Test Results eine ini ip ll lala 3 12 36 9 7 UsermReview Ang ELSE e ade evi ac eg 3 12 ER EE nee ee E eset raster ee ees ee 3 12 ST PRODUCTION CUTOVER td 3 12 Page TOC 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Table of Contents HL7 Implementation Support Guide 3 7 L Data Convers vom T 3 12 A e EE 3 12 3 7 3 Post Implementation Support sese sees eee ee o ee eee 3 12 6 70 Help Des A EE 3 12 E Ee Fre 3 12 3 8 BENEFITS REALIZA TON cintia Celo AE 3 12 ole Benefits Eeer 3 12 CHAPTER 4 HL7 VERSION 2 2 OVERVIEW AA INTRODUCTION EE 4 4 2 VERSION 2 2 QUESTIONS AND ANSWERG ccccccssscssssessssencssssessccesnceenssesseessneeaees 4 1 4 2 1 ADT Finance responses by Robert Evola eese 4 1 4 2 1 1 What was the driving force behind the creation of version 2 2 In comparison with version 2 1 what advantages does it offer 4 1 4 2 1 2 What does version 2 2 not address at this time Will they be covered 112 2 e A estas gga cae le ode edn a ede eee 4 1 4 2 1 3 What key criteria should be used in determining if members should upgrade to 2 2 or stay with 2 1 What key fun
175. 16 C SEIEN 2 00270 Service Period l GO CT 3 0027 TextInstruction TST op B 1 58 OM General Observation 1 00586 Sequence Number R NM 0 OTP 2 00587 Producer s Test ObservationID R CE 200 P 5 3 00588 Permitted DataTypes ID 2D CT Cou 4 00589 SpecimenRequired R ID D Ce 5 00590 Producer D o R CE 00 6 00591 Observation Description TX Q0 II 7 00592 Other Test ObservationIds CE w P 01 8 0053 OtherNames R ST QD TI S 9 00594 Preferred Report Name forthe Obs ST GO S 10 00595 Preferred Short Name amp Mnemonic ST o o 0 S 11 00596 Preferred Long Name for the Obs ST ou Po 12 00597 Orderability ID D P Ce TU Neetu TIET CT Perform Study 14 00599 Coded Representation of Method _ CE Q00 G4 0 0 A3 S 15 00600 Portable ID D 0136 16 00601 Observation Producing Dept Section CE CTT y 17 00602 Telephone Number of Section XTN on III 18 00603 Nature of Tes Observation R IS D
176. 1998 All rights reserved Appendix C Lower Layer Protocols C 3 4 3 Termination Interrupt Description Application Procedures C 3 4 4 Reverse Interrupt Description Application Procedures The receiving station after receipt of a message or transmission block causes the sending station to cease transmission Such a procedure is called a termination interrupt Termination interrupt may be used by the receiving station to cause the transmission to be interrupted because it is not in a condition to receive Cause for such inability to receive could include a hardware malfunction loss of an additional network connection etc Termination interrupt procedures are accomplished by the receiving station s transmitting EOT in lieu of one of its normal responses This response indicates a negative acknowledgment of the last transmission and the conclusion of a transmission A receiving station may request the sending station to terminate the transmission in progress prematurely in order to facilitate a reversal in the direction of data transfer Such a procedure is called reverse interrupt Reverse interrupt procedures may be used by a receiving station to interrupt its receiving of a message stream so that it may transmit a priority message or messages to the original sending station Reverse interrupt procedures may be used by a receiving station only after reception of a block with a valid BCC Reverse interrupt procedures
177. 2 3 1998 All rights reserved Final Version 6 98 Chapter 3 Implementation Methodology 3 4 3 4 1 3 4 2 3 4 2 1 3 4 2 2 3 4 3 3 4 4 3 4 5 3 4 6 Page 3 4 TECHNICAL DESIGN Define Required Hardware Platforms Document existing hardware environment for applications to be interfaced Document modifications as needed to each system Document Communications Design Select Lower Level Protocol The interface will be built on top of some media and access method HL7 interfaces exist at the seventh or application layer of the OSI model As such they require the support of some lower level protocol LLP It is important for each site to select an LLP that meets the needs of the interface and fits into the overall telecommunications strategy and architecture of the company Things to consider include the time frame for installation existing staff experience expertise long range communications strategy and cost Also there may be existing LLP that can be utilized with little or no disruption to the overall environment Define Communications Hardware Once the lower level protocol has been identified define any additional communications hardware required This may include network adapter cards wiring hubs bridges routers repeaters additional cabling or specialized communications servers Define Workstation Requirements Determine requirements for workstations to be used with the interfaced systems
178. 3 17 0989 Bose MI 1D amp 9 S 9 18 01009 ChargeOnIndicatr TS o ITT 0269 Health Level Seven Implementation Support Guide Page B 41 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 74 PRD Provider Data tf oss Roe LE CE Q0 P0286 2 01156 ProviderName LL XPN a Off 5 5 3 01157 ProiderAddess XAD ss 4 01158 ProviderLocation PL 60 PP 5 01159 ProviderCommunicationInfo XTN aow III 6 01161 Preferred Method of Contact CE ew 2 Ce 7 01162 Providerldeniiers CM aw TI S 8 01163 Effective Start DateofRole TS Ge 4 J 9 01164 Effective EndDateofRole TS Ge III B 1 75 PSH Product Summary Heade L3 01083 Report Type 0 m ISSEY HT c 2 01297 Report Form Identifier ST 60 III S 3 0125 ReportDate 8 1 R TS QGQ o 1 4 01236 Report Interval StartDate TS o II S 5 01294 Report Interval Start Det TS Q9 Ys 6 0128 Quantity Manufactured CQ 7 01239 Quantity Distributed Cool a 0 J 8 01240 Quantity Distributed
179. 30 minutes 18 hours 2 months 45 minutes 24 hours 3 months 90 minutes 772 hours 1 hour 1 day 2 hours 2 days 2 hours 3 days 3 hours 4 days 4 hours 5 days 5 hours 6 days 6 hours 1 week Table 9 shows the allowable time aspect codes The second and optional subpart of the time component allows an indication of some sub selection or integration of the measures taken over the defined period of time so SH MAX heart rate would be the highest heart rate observed over 8H Shift MIN MAX FIRST LAST MEAN are the other possible values for this subpart When nothing is stored in this subpart we assume a mean value over the time period in questions Table 9 Time Aspect Codes Time Definition MIN Minimum value over interval MAX Maximum value over interval FRST First value observed during an interval LAST Last value observed during an interval MEAN Mean of all of the values observed on the interval This is the default selection 2 5 System Sample Type 4th part System sample type is the fourth part of the fully specified test name It consists of two subparts the first names the system the optional second delimited with a indicates the super system source of the sample if it is not the patient e g fetus blood product unit donor etc Sample type should be represented with the abbreviations in Table 10 which include most of the sample types defined in ASTM E1238 and HL 7 We define different tests for t
180. 37 Mail claim party Added the following values E G I O P 0156 Which date time qualifier Table name changed from Date time qualifier to Which date time qualifier deleted the following value CAN 0162 Route of administration Added the following values EP ET IMR IB ICV MM NP NT OTH PF RM SD VM WND deleted the following values IM IN IO IP IS IT IV 0166 Rx component type Added the following values 0 1 2 3 Page 5 6 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Table Table Name Description of Change 0167 Added the following values 4 5 7 8 0171 Table name changed from Country code to Citizenship 0173 Coordination of benefits Added the following values CO IN 0174 Nature of test observation Added the following values P f A SC Master file identifier code Added the following values CMA CMB LOC OMA OMB OMC OMD deleted the following values OM1 OM6 0190 Address type Added the following values N F 0191 Type of data Added the following values image audio application 0193 Added the following values AT LM PC UL 5 3 3 Chapter 2 Control Query 5 3 3 1 New Data Types SN Structured numeric IS Coded value for user defined tables HD Hierarchic designator EI Entity identifier PL Person location PT Processing type CX Extended composite ID wi
181. 4 Interfaces And Interface Engine Support staff should understand the interfaces that will be implemented and the specific usage and role of the interface engine in your environment 3 6 7 2 5 Develop Support Reference Manual Library Develop manual for support staff that applies the technical education received to specific operations for each system affected by the transition to HL7 This manual should assist help desk personnel in addressing support calls Establish a library of related materials to assist in problem resolution Page 3 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 3 Implementation Methodology 3 6 8 3 6 8 1 3 6 8 2 3 6 9 3 6 9 1 3 6 9 2 3 6 9 3 3 6 9 4 3 6 9 5 Go Live Planning Finalize Support Staffing Plan Develop a list of all of the support responsibilities for the new system s and interfaces including items such as end user help desk support routine maintenance and interface monitoring Determine FTE and skill requirements for all support responsibilities Identify personnel who will be responsible for support and develop training program to address any skills deficiencies Conversion Preparation Develop a checklist to be used during the cutover to the new environment Re assess go live dates resource requirements etc Go live dates and resources will need to be consistently monitored from
182. 40 41 42 43 44 45 46 47 Page B 32 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 59 OM2 Numeric Observation 1 00586 SequenceNumber NM 2 00627 UnitsofMeasure CE 60 4 0 S 3 00628 Range of decimal Precision NM 0 TI S 4 00629 Corresponding SI Units of Measure CE 60 III 5 00630 SIConversion Factor TX 60 P S eee femp um qo Iro Tq o A y amp Continuous Observation AP ERASE E Continuous Observation ER 100 epe coq c Continuous Observation 9 00634 Delta Check Criteria CM ew Sf Cc 10 00635 Minimum Meaningful Increments NM e TTT B 1 60 OMS Categorical Test Observation 1 00586 SequenceNumber m Ms 2 00636 Preferred Coding System CE 600 ss 3 00637 ValidCoded Answr CB 4 00638 Normal Text Codes for Categorical CE 200 Observations TU LL Categorical Observations EO e a THT E Observations 7 00570 ValueType 0125 Health Level Seven Implementation Support Guide Page B 33 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 61 OM4 Observations That Require Specimens 1
183. 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Message Header Message Acknowledgment Query Definition Query Filter Ae Appendix A HL7 Transaction Checklist A 4 3 27 V03 Vaccination Record Response VXR Originator A or B Message Header Message Acknowledgment Query Definition Query Filter Patient Identification Additional Demographics Next of Kin Associated Parties Patient Visit Patient Visit Additional Info Insurance Information Insurance Information Add l Info Insurance Information Cert Common Order Pharmacy Treatment Administration Pharmacy Treatment Route Observation Result Notes and Comments A 4 3 28 V04 Unsolicited Vaccination Record Update VXU Originator A or B Message Header Patient Identification Additional Demographics Next of Kin Associated Parties Patient Visit Patient Visit Additional Info Insurance Information Insurance Information Add l Info Insurance Information Cert Common Order Pharmacy Treatment Administration Pharmacy Treatment Route Observation Result Notes and Comments Page A 48 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 4 Financial Management A 4 4 1 A 4 4 2 P01 Add Patient Accounts BAR Message Header Event Type Patient Identification Additional Demograp
184. 7 Implementation Support Guide C 3 6 3 Parameters and Defaults ioe sss sese eee seene C 22 CA MINIMAL LOWER LAYER PROTOCOL AAA C 22 CET ATMO AGEN EE C 22 CATI O C 23 CALZ Goals and ASSUIiptlOns E C 23 CALI Differences accion da C 23 C414 Notation Conventos da C 23 C42 Block EE C 23 24 5 Processing Rules edente recti e o diia C 24 C 5 HL7 SEQUENCE NUMBER PROTOCOL IMPLEMENTATION C 24 ol Sequence Number R T eoe vei eege C 24 C52 sequence Number DeSerrpllOtbs ia C 24 C 5 3 State of the Receiving Eege ee EE C 24 C 5 3 1 Sequence Number Processing by the Receiving System sees sese ee eee C 25 554 Normal Operations de i a same aa aie iv aan upon Lam Cb eee C 25 C 5 4 1 The Message Sequence Number Sent Equals the Expected Sequence A C 25 C 5 4 2 The Message Sequence Number Sent does not Equal the Expected Sequence et C 25 CO sequence Nimbernns Chartae a deer C 26 Cao To Ee C 27 C 5 7 To Synehronize the BSN cocino eee hn EXC Tn Y Suae es RUE E S ERAS ERR EE ee cositas C 27 C 5 8 Overview of the Sequence Number Protocol esee C 28 C 5 9 Link Management Messages eerta eae ep Ru ENEE C 28 C 5 10 Responsibility for Initiating Synchronization eese C 28 CT Acknowledgment Codes ist eee es Rn DRE a RI UO EPOR DEF CR a eK NERIS eet C 29 C6 PSEUDO CODE BOR EE TT TARO ia C 29 ESL nitatins o E o e C 29 C 6 2 gt Accepting Modules ondas dee dE deeg C 30 C 6 3 Permanent Virtual Circuits eree eee C 3
185. 7 Transaction Checklist A 4 4 5 P05 Update Account BAR Originator A or B OPT Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Diagnosis Related Group Procedures Role Guarantor Information Next of Kin Associated Parties Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information OPT A 4 4 6 POG End Account BAR Originator A or B Message Header Event Type Patient Identification Patient Visit Health Level Seven Implementation Support Guide Page A 51 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 5 Ancillary Data Reporting A 4 5 1 R01 Unsolicited Transmission of an Observation Message ORU Originator A or B Message Header Patient Identification Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Order Common Observations Report ID Notes and Comments Result Notes and Comments Clinical Trial Identification Continuation Pointer A 4 5 2 R02 R04 Query for Results of Observation QRF Originator A or B Message Header Message Acknowledgment Query Definition Query Filter Patient Identification Notes and
186. 7 Transaction Checklist A01 Admit a Patient with Z Segment Usage Segment Segment Name MSH Message Header EVN Event Type PID Patient Identification NK1 Next of Kin PV1 Patient Visit PV2 Patient Visit Additional Info OBX Observation Result AL1 Allergy Information DG1 Diagnosis Information PR1 Procedures GT1 Guarantor Information IN Insurance Information N2 Insurance Information Addit Info N3 Insurance Information Cert ZIN for IN1 IN2 IN3 Z Additional Insurance User Record ACC Accident Information UB1 B82 Information ZVS Z Additional Visit Information Page A 96 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist ORU Unsolicited Transmission of an Observation with Z Usage Segment Segment Name MSH Message Header PID Patient Identifier NTE Notes and Comments PV1 Patient Visit ZVS Z Additional Visit Info ORC Order Common OBR Observations Report ID NTE Notes and Comments ZBR Z Additional Observation Info OBX Result INTE Notes and Comments DSC Continuation Pointer The any seg slot can be filled by a segment appropriate to the type of order being placed e g OBR ORO RX1 in V2 2 2 Zsegments should always appear in the same order Order may effectively be defined by development date For example the A01 message V
187. 7 message C 4 1 4 Notation Conventions 1 Single ASCII characters are enclosed in single quotes 2 Special characters or non printing ASCII characters are enclosed in angle brackets lt gt Special characters are the LLP Start Block and End Block characters Non printing ASCII characters may be written as their abbreviation e g ESC for the Escape character They also may be written as their hex value in the form OxXX where X is a hexadecimal digit For example in Standard ASCII lt ESC gt is lt 0x1B gt C 4 2 Block Format HL7 messages are enclosed by special characters to form a block The format is as follows lt SB gt dddd lt EB gt lt CR gt SB Start Block character 1 byte ASCII VT i e lt 0x0B gt This should not be confused with the ASCII characters SOH or STX dddd Data variable number of bytes This is the HL7 data content of the block The data can contain any displayable ASCII characters and the carriage return character lt CR gt lt EB gt End Block character 1 byte ASCII FS i e 0x1C This should not be confused with the ASCII characters ETX or EOT lt CR gt Carriage Return 1 byte The ASCII carriage return character i e 0x0D C 4 3 Processing Rules The rules governing circuit control and processing of messages for these blocks are the same as for Hybrid HL7 LLP blocks with the following exceptions Health Level Seven Implementation Support Guide Page C 23 for HL7 Stan
188. 7070 Fax 317 630 6962 Email clem regen rg iupui edu Wayne Tracy Health Patterns Ph 913 685 0600 Fax 913 685 0911 Email rtracy Q wrt win net Debra Weiss Kaiser Permanente Ph 503 778 2447 Fax 503 778 2491 Email Mission The goal of the Orders Observations Technical Committee is to define messages to support the order communication and observation reporting processing requirements between the stakeholders in the health care organization regarding patients non patients people other species or inanimate objects These messages are not limited to intra organizational transactions but may cross organizational boundaries Projects The initial scope of this committee is to migrate the contents of Chapters 4 and 7 from V2 3 to V3 0 To that end the committee will define the respective models as described in the Message Development Framework e Migration e Short term fixes e Medical device interfacing project proposal Health Level Seven Implementation Support Guide Page 1 15 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapier 1 Introduction e Non patient orders PATIENT ADMINISTRATION FINANCIAL MANAGEMENT Freida Hall HBO amp Company Ph 770 668 5949 Fax 770 395 4302 Email freida hall hboc com Mission The goal of the Patient Administration and Financial Management PAFM technical committee is to define messages to support the administrative that is pati
189. 8 Appendix F Sample Templates 4 Does the system allow for multiple adapters to be active simultaneously Are there any limitations to the number allowed 5 What type of internal bus accommodates the communications adapters What are the performance 6 What type of communications adapters are you recommending for St Anybodys Medical Center What are the performance ratings for these adapters 7 What types of terminal servers controllers are available 8 What types of communications software is available for connecting this platform to the Sr Anybodys Medical Center proposed enterprise network 9 Describe what happens to the AIE or its interfaces if one of the interface processor nodes fails 10 Describe what happens to the AIE or its interfaces if communications is broken with one of its processor partners 11 Can the product communicate using a DECnet Phase IV b TCP IP c RS232 d 051 e Novell f Appletalk g Pathworks h Any others Describe all central network management capabilities F 1 8 4 Operating System The operating system utilized by the AIE processor is responsible for providing services to the applications and system components The operating system is also responsible for maintaining and coordinating all tasks and processes on the system 1 Describe the attributes you deem important for the operating system when implementing the AIE product 2 Whattype of operating system are
190. 8 00745 StudentIndicator LL IS 3 o 39 0020 Religion I f 4 TL 40 00746 MothersMaidenNam XPN d Do 3 4 41 0079 Nationality 1 1 CE G0 3 Q3 33 lt 42 00125 Bh cGroup IS QD TL 18 43 00119 Maritai Staus IS QD 5 0 TL 02D 44 00787 Insurd SEmploymmtStatDae DT 9 0 0 45 00783 Insured s Employment Stop Date DT 9 49 49 46 00785 JobTile 0 30 ST 47 00786 JobCode Class xece o 0327 0328 48 00752 JobStaus 8 I o A To 49 00789 Employer Contact Person Name REN 48 LIT 50 00790 Employer Contact Person Phone XIN w Jol J 51 00791 Employer Contact Reason IS Q TI 52 00792 Insured s Contact PersonName _ XPN 48 Ol S j 53 00793 Insured s Contact Person Phone XTN 49 Jol S L7 54 00794 Insured s Contact Person Reason I 5 d 022 55 00795 Relationship to Patient Start Date DT 5 9 56 00796 Relationship
191. 960 Fax 317 630 6962 Email gunther aurora rg iupui edu Mission This group will focus on the use of HL7 in communications environments where there is a need for authentication encryption non repudiation and digital signature This group will focus on the mechanisms for secure HL7 transactions and not on standardizing security policies It will however ensure that the mechanisms are present to implement security policies It will report to HL7 on available options and recommend actions that the organization may take to address these needs The early activities of the group will include reviewing the work of other standards groups in this area including but not necessarily limited to ANSI X3 ASTM CEN CPRI X12 HL7 Germany U N Edifact and the general Internet community Projects The Scope of the Secure Transactions SIG is network and internet security of HL7 transactions at the application level independent of underlying transport SGML XML Dan Chudnov Yale University Ph 203 785 4347 Fax 203 785 4369 Email daniel chudnov yale edu John Mattison MD Kaiser Foundation Health Plan Inc Ph 818 405 5091 Fax 818 405 6991 Email john e mattison kp org Rachel Sokolowski iTrust Ph 781 646 8877 Fax 781 646 5377 Email rsokolowski itrust net Mission The HL7 SGML Initiative is a special interest group of HL7 formed to create the standard for the use of Health Level Seven Implementation Support Guide Page 1 21 fo
192. 98 The sending station in the process of sending several blocks per message text decides to terminate transmission prematurely at the end of a block and after receipt of the proper acknowledgment reply Such a procedure is called a sending station abort Sending station abort procedures may be used by a sending station when in the process of sending multiple blocks per message text it determines that it should prematurely terminate transmission to the particular receiving station Such a determination might be made if the sending process did not receive the remaining blocks in time from the higher level needed to send a higher priority message or was temporarily unable to continue transmission etc Sending station abort procedures may be used following block abort procedures to accomplish a transmission abort condition that is the sending station prematurely terminates the transmission within a transmission block Sending station abort procedures are accomplished by the sending station completing the transmission of a block for example ETB ENQ Then upon receipt of the proper acknowledgment reply ACK NAK etc or a Timer A time out the sending station transmits EOT to terminate the transmission to the receiving station The receiving station detects this sending station abort procedure by recognizing receipt of EOT following ETB or ENQ instead of ETX Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3
193. 98 All rights reserved Final Version 6 98 Appendix F Sample Templates 1 3 1 4 Implementation Team 1 3 2 Define Roles Responsibilities 1 3 3 Establish Meeting Schedules 1 3 4 Obtain Approvals amp Signoffs Project Organization 1 4 Prepare Project Orientation 1 4 1 Review Issue Track Problem Reporting 1 4 2 Review Change Control Mechanism 1 4 3 Project Administration 2 INTERFACE ENGINE SELECTION 2 1 Requirements Analysis Interface Engine 2 1 1 Define Communication Manager Client Requirements 2 1 1 1 ADT LU 6 2 Accept 2 1 1 2 Patient Registration Accept 2 1 1 3 Patient Demographics Accept 2 1 1 4 Clinician Master File Update Accept 2 1 1 5 Remote Solicit Query to Patient Demographics 2 1 1 6 Clinical Data Repository Query for Information 2 1 1 7 Benefits Eligibility Query for Eligibility 2 1 1 8 Clinical Data Repository Initialize from Queues 2 1 1 9 Ordering System Accept 2 1 1 10 Lab HL7 Results Accept 2 1 1 11 Lab HL7 Orders Accept 2 1 1 12 Requirements Draft Documentation Development Communication Manager 2 1 1 13 Requirements Final Documentation Communication Manager 2 1 1 14 Obtain Communication Manager Requirement Signoff 2 1 2 Define Queues Requirements Page F 60 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 2 1 2 1 STAT Order Queue 2 1 2 2 STAT Result Queue 2 1 2
194. 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix G Frequently Asked Questions e The Standard should support exchanges among systems implemented in the widest variety of technical environments Its implementation should be practical in a wide variety of programming languages and operating systems It should also support communications in a wide variety of communications environments ranging from a TCP IP network stack to point to point RS 232C interconnections as well as the transfer of data by batch media such as floppy disk and tape e Immediate transfer of single transactions should be supported along with bulk transfers of multiple transactions e The greatest possible degree of standardization should be achieved consistent with site variations in the usage and format of certain data elements The Standard should accommodate necessary site specific variations This will include at least site specific tables code definitions and possibly site specific message segments e The Standard must support evolutionary growth as new requirements are recognized This includes support of the process of introducing extensions and new releases into existing operational environments e The Standard should be built upon the experience of existing production protocols and accepted industry wide standard protocols It should not however favor the proprietary interests of specific companies to the detriment of other users of the
195. 998 All rights reserved G 5 G 5 1 G 5 2 G 5 3 G 5 4 Appendix G Frequently Asked Questions file or at most a small number of text files In the Web version it should provide the benefits associated with the Web including links within the document and to other Internet resources that are cited within the document The text version should have the same material as the Web version but for the occasional diagram The user should be able to navigate it using hierarchically numbered question topic headings Where the Web document has a link to a URL the text of the URL will be available in the text version GENERAL HL7 MESSAGE FORMAT What is the Current Version of HL7 Version 2 3 was published in April 1997 Does the HL7 Standard Specify a Maximum Segment Length and or a Maximum Message Length Not really although the maximum field length suggested in Version 2 3 is 64k and the use of very large fields probably requires site specific negotiations since actual implementations of lower layer protocols usually have some length maximums defined Mark Shafarman How Do Get Around the 512 Byte Maximum Read in Digital Standard Mumps TCP Sunquest uses a C based layer of communications that initiates manages and reads the TCP IP socket The MUMPS component of the interface talks to the C layer receiving digestible chunks of data and storing them in a MUMPS global until the entire message has been received There is
196. A Data Modeling group to work with all HL7 working committees to produce an object oriented model of health care data In this model the objects are things like Person Patient Encounter Result etc as well as objects to deal with messages and trigger events This group is making great progress Its ultimate realization will be HL7 Version 3 Joint discussions between SIGOBT and QA Data Modeling are helping to ensure that the current SIGOBT efforts will help guide the QA Data Modeling approach to achieve pragmatic results We also feel that the OMS will provide one important basis for developing some or all of the technical approaches for Version 3 Implementing HL7 As an Institution How Do Implement HL7 There is considerable room for discussion on the approaches but the steps will include these Get your vendors to agree to HL7 Establish your provisions for maintaining the interface as part of the initial contract Establish an auxiliary specification that specifies what trigger events messages and optional fields you will use what special options from the control chapter will be used sequence numbers transaction batching etc and how and when the systems will interconnect for example they will use TCP IP and the ADT system will create the circuit every time it reinitializes the interface Specify what you will require from the implementing systems in terms of operational support of an interface for example can you t
197. AS 2 5 Cen 28 00453 Pre AdmitCert PAC ST a op 29 00454 Verification DateTime TS Bss 30 00455 VerificaionBy RN LI S 31 00456 TypeofAgreementCode IS Lues 32 00457 BillingStaus TS o jJ Con Health Level Seven Implementation Support Guide Page B 17 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 33 00458 Lifetime Reserve Days NM Ill 34 0059 Delay Before Ki Ium O 35 00460 Company Plan ode 1 i5 4 A 0 36 00461 PoiyNumer pr o OCS 37 00462 Policy Deductible 1 CP o T 38 00463 eicyLimt Amux 1 B cp Ill 3 00464 PeicyLimt Das NM 0 0 o T o To 40 00465 ReomRae Sem Pivas B CP uy Sd 4i 00466 ReomRee Pivae B CP 29 T 1 42 00467 lwwedsEmpoySuu CE 9 T Lee 43 00468 IwwedsSex To 5 D 44 00469 Insureds Employer Add xAD me Ill 45 0470 Verification Status Sr o DO 0 T O OT 46 7I Prior Insurance Plan ID 55 o A 0o OT o Too ar o Coverage Tye 5 o DO oO To o Too a8 0053 Handicap
198. ASTS ACNC PT URNS ORD MICROSCOPY LIGHT RBC CASTS ACNC PT URNS ORD MICROSCOPY LIGHT EPITHELIAL CELLS ACNC PT URNS ORD MICROSCOPY LIGHT 3 7 Cellcounts The following convention will be used to represent microscopic examinations WBC CASTS ACNC PT URNS SQ MICROSCOPY LIGHT RBC CASTS ACNC PT URNS SQ MICROSCOPY LIGHT EPITHELIAL CELLS ACNC PT URNS SQ MICROSCOPY LIGHT Counts of various entities and cells in urinalysis and CSF and other body fluids may be performed and reported in one of three ways They may be reported as absolute counts per unit volume then they have the property of NCNC or as percents of a general cell type e g percent eosinophils then they have the property of NFR Blood cells are usually reported in such a manner via a manual or automated count method Counts on urine and other body fluids can also be done as direct counts and reported as NCNC or NFR However they are more often reported as the number of entities or cells per microscopic high power or low power field e g 5 10 cells per high power field These are really numbers per area NARIC E g the number of erythrocytes per low power field would be reported as follows ERYTHROCYTE CASTS NARIC PT URNS QN MICROSCOPY LIGHT LPF Note that even though the values are reported as a range the scale is still QN because the values can be related through a ratio We use HPF or LPF to identify high power and low power fields respectively Large entities such as casts are
199. ATEGORY II INTERFACES Interface Category III Include all hardware and cabling that is required to implement Category III interfaces and is in addition to what is proposed for Category I and II interfaces Hardware that has been listed as required for Categories I and II but will require additional components for Category III interfaces should be included TOTAL PROPOSED COST OF HARDWARE FOR CATEGORY III INTERFACES Health Level Seven Implementation Support Guide Page F 45 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 9 3 Documentation List of all of the documentation you provide in support of the proposed solution Indicate whether the documentation is included in the purchase price of the product or if it must be purchased at additional cost If the documentation is included indicate how many copies are included and the cost of additional copies Describe any assumptions and or additional information that will help to clarify the proposed pricing Interface Category I Include all document to implement and support Category I interfaces COPIES PRICE DOCUMENT NAME PART NO SOURCE INCLUDED MEDIA COPY NOTES TOTAL PROPOSED COST OF DOCUMENTATION FOR CATEGORY I INTERFACES Interface Category II Include all additional document to implement and support Category II interfaces TOTAL PROPOSED COST OF DOCUMENTATION FOR CATEGORY II INTERFACES Page
200. ATRIX The following matrix is provided as a quick look for what systems support what Trigger Events The columns in the following table are defined as follows Value the HL7 Event Type as defined in HL7 Table 0003 Page B 60 Description Enterprise Event Event the HL7 description of the event as defined in HL7 Table 0003 put the description of your enterprise s event that corresponds You may have more than one enterprise event for each HL7 Application A B indicate the supportability of the trigger event by each application e F trigger event is sent from this application e T trigger event is received by this application e X trigger event is not supported ADT ACK Admit visit notification ADT ACK ADT ACK ADT ACK ADT ACK ADT ACK inpatient ADT ACK outpatient ADT ACK ADT ACK ADT ACK ADT ACK ADT ACK ADT ACK ADT ACK ADT ACK Final Version 6 98 Transfer a patient Discharge end visit Register a patient Pre admit a patient Change an outpatient to an Change an inpatient to an Update patient information Patient departing tracking Patient arriving tracking Cancel admit visit notification Cancel transfer Cancel discharge end visit Pending admit Pending transfer Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists ADT ACK Pending disch
201. Appendix E Examples for LOINC Property Matching 1 Content CNT Like concentration except that volume in the denominator is replaced by mass By extension CCNT Catalytic Content catalytic activity of a component per unit mass of a sample system 1813 SIALPHA GALACTOSIDASE CCNC PT PLAS QN MCNT Mass Content mass of component per unit mass of a sample system 9435 9IISOPROPANOL MCNT PT TISS QN NCNT Number Content number of component entities per unit mass of a sample system Hypothetical Number of organisms per gram of tissue Note All of the heavy metal measurements in hair nails and tissue should all be mass contents Example Should be 8157 OIARSENIC MCNT PT NAIL QN 2 Fraction FR Fraction of component A in group of entities B C Y N in system 1 By extension CFR Catalytic Fraction 2536 1IILACTATE DEHYDROGENASE FRACTION 1 CFR PT SER QN NFR Number Fraction 10602 1ISPERMATOZOA ABNORMAL HEAD 100 NFR PT SMN QN 764 1INEUTROPHILS BAND FORM 100 NFR PT BLD QN MANUAL COUNT MFR Mass Fraction 2614 6IMETHEMOGLOBIN MFR PT BLD QN Note Hematocrit is a volume fraction 4545 0IHEMATOCRIT VFR PT BLD QN SPUN Note CK BB also MB MM is a catalytic fraction Current Bad 9642 OICREATINE KINASE BB CREATINE KINASE TOTAL PCT PT SER QN 3 Ratio RTO Ratio of component A to component B in system 1 By extension CRTO Catalytic Concentration Ratio 2325 91GAMMA GLUTAMYL TRANSFERASE ASPARTATE AMINO TRANSFERASE CCRTO PT SER QN
202. B 1 85 RXA Pharmacy Administration 1 00342 Give Sub ID Counter PORO NM 0 j 0 5 5 2 0044 Sub ID Counter R NM 2 J 2 jp Z4 3 00345 Date Time Admin sat R TS III S 4 00346 Date Time Admin End R TS QO9 III 5 00347 AdministeredCode R CE aw URT 6 00348 Administered Amount R NM QO S 7 00349 Administered Units pe CE ss 8 00350 Administered DosageForm CE ss 9 00351 AdminsratinNoes CE ew TI S 10 00352 Administering Provider Y XCN om ss 11 00353 Administered AtLocation C CM Q0 III 12 00354 Administered Per Time Unity C ST e 0 S 13 01134 Administered Strength NM QO j 0 S 14 01135 Administered StrengthUse CE ss 15 01129 Substance La Muer ST om ss 16 01130 Substance ExpirationDate TS Ge CC 0 5 5 17 01131 Substance Manufacturer Name CE 600 TC 2 2 Q275 18 01136 Substance RefusalReason CE ew 2 5 S 19 01123 Indication 1 CE e fC Pf 20 0123 Completion Status ID Com 21 01224 ActionCode ID Q j sa
203. CT PLAN FOR A CLINICAL LAB PROJECT F 59 APPENDIX G HL7 FAQ G 1 WHAT S NEW AUTHORS CONTRIBUTORS sese G 1 G 2 WHO ARE THE AUTHORS AND CONTRIBUTORS TO THIS FAQ G 1 G 3 HOW CAN I CONTRIBUTE TO THE FAOT G 1 G 4 DESIGN AND DISCLAIMERS etri ro teoria er ton PR gege G 2 G 4 1 What is the Purpose of this FAQ and What Disclaimers Does it Carry G 2 G 4 2 What are the Design Goals of this FAOT G 2 G 5 GENERAL HL7 MESSAGE FORMAT G 3 Goel Whatis the Current Version HET er en Ra E E E TE N G 3 G 5 2 Does the HL7 Standard Specify a Maximum Segment Length and or a Maximum Message Length uiis nat etas th ae inii aaia G 3 G 5 3 How Do I Get Around the 512 Byte Maximum Read in Digital Standard NA OP a E a G 3 G 5 4 How Do I Find the End of an HL7 Message G 3 G 5 5 How Can I Send Binary Data in HL7 Messages G 4 G 5 6 Are there Provisions in HL7 for European and Asian Character Sets G 4 G 5 7 How Should Midnight Be Represented in HLT G 4 G58 Why Isnt HL7 Plug and Play Eat geet Eegen eege ege G 4 G 6 PATIENT ADMINISTRATION MESSAGES eee G 6 G 6 1 Error in Trigger Event A18 Merge Patient Information sess G 6 G7 GCLINICAL DATA CON NEE G 6 G 7 1 ICannot Locate the HL7 Field Where I Put Glucose or Height and Weight or Outcome or Whatever ias G 6 G 7 2 How Do I Send Narrative Reports such as History and Physical or Discharge ERD G 6
204. Change alternate patient ID ADT ACK Change patient account number ADT ACK Change visit number ADT ACK Change alternate visit ID CRM Register a patient on a clinical trial CRM Cancel a patient registration on clinical trial for clerical mistakes only CRM Correct update registration information CRM Patient has gone off a clinical trial CRM Patient enters phase of clinical trial CRM Cancel patient entering a phase clerical mistake CRM Correct update phase information CRM Patient has gone off phase of clinical trial CSU Automated time intervals for reporting like monthly Page B 62 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists CSU Patient completes the clinical trial CSU Patient completes a phase of the clinical trial CSU Update correction of patient order result information QRY EQQ SPQ VQQ RQQ Cancel query RQI RPI Request for insurance information RQI RPL Request receipt of patient selection display list RQI RPR Request receipt of patient selection list RQD RPI Request for patient demographic data RQC RCI Request for patient clinical information RQC RCL Request receipt of clinical data listing PIN ACK Unsolicited insurance information RQA RPA Request for treatment authorization information RQA RPA Request for modification to an authorization
205. Code LEI 600 S 8 00675__ Active Inactive Indicator ID D P Cen 9 00990 IwenoyNumer 1 CE 00 OY 10 00991 ResourceLoad NMT D j S 1 0092 ContractNumber_ CK om ol 0 S 9 12 00993 Contract Organization PONLO ss 13 00994 RoomFeeIndiaor DEMOS B 1 15 CMO Clinical Study Master pe St OLD Set E psp ee A AAA ASA 2 01011 Sponsor StudyID R EH 60 QJ 3 S 7 3 01012 Alternate SwdyIds CE 60 Jos E 01018 TileoiSmdy E Sp GY dps ip Bee 5 01014 ChairmanofStudy RN ss 6 01015 LasIRBAppovalDae DT ss 7 01016 Total AccrualtoDate NM j 5 S 8 01017 LastAcemalDate dor ITT S Health Level Seven Implementation Support Guide Page B 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 9 01018 ConatforSudy CT XEN IT 10 01019 Conact sPhoeNumer XIN on III S 11 01020 Contacts Address XAD uo y B 1 16 CM1 Clinical Study Phase Master LE ET E EE A A 2 01022 StudyPhase ener R CE 60 III 3 01023 Description of Study Phases R ST
206. Columbia are considering following in its footsteps Page H 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 The LOINC codes have are being incorporated into the National Library of Medicine s ULMS They are the basis for HCFA s ICD10 PCS laboratory codes They have been incorporated in HCFA s quality assurance testing pilot programs and they have been adopted by the Center for Disease Control and Preventions State and Territorial Epidemiologist s project for reporting transmitting communicable diseases electronically SNOMED collaboration LOINC and SNOMED are supporting a collaboration that will ensure a consistent unambiguous clinical reference terminology that builds upon the strengths of each The SNOMED Editorial Board and the LOINC Committee have agreed on the following method for linking the SNOMED and LOINC terminologies in a synergistic way and preventing overlap The detailed names of laboratory tests provided by LOINC will all be incorporated into the P3 SNOMED axis These codes will retain the full LOINC code number and check digit but will include a prefix to identify the SNOMED axis The LOINC committee will continue to have editorial control over these terms and will continue to distribute them on the Internet for public use S SNOMED will not define laboratory test names that overlap in meaning with fully
207. D T eo s E SEG EN A E A 2 00503 Certification Number CX 69 PP 3 00504 CertifiedBy xn 60 Jol 3S 4 00505 CemifiaionReqireed ID D y 5 00506 Penalty LLN 0 j J A ts 6 00507 Certification Date Time TS Bss 7 00508 Certification Modify DT TS Bss 8 00509 Operator RN Il OY 9 00510 CemifiaionBeginDae DT Ass 10 00511 CertificationEndDate DT ss 1 00512 Days 0 CcM Q 9 49 12 00513 Non ConcurCode Dese CE 60 Copa 13 00514 Non ConcurEffectiveD T TS e 0 0 14 00515 PhysianReviewr xmn 00 TC 0 J 7 15 00516 CemifiaionConact ST 489 J o 16 00517 CemificaionConactPhone XTN w 2 5 0 S 17 00518 AppealReason CE 60 18 00519 CertificationAgency LEI 60 S 19 00520 Certification Agency Phone XTN w 20 00521 Pre CertificationReg Window CM om Ol T 21 00522 CaseManager TST Ts Health Level Seven Implementation Support Guide Page B 21 for HL7 Standard Version 2 3 1998 All right
208. DE Originator A or B Seg Name oP appa Repeat apps Repeat Message Header Notes and Comments Patient Identification Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Insurance Information Insurance Information Add Info Insurance Information Cert Guarantor Information Allergy Information Common Order Pharmacy Treatment Prescription Order Notes and Comments Pharmacy Treatment Route Pharmacy Treatment Component for RXO Notes and Comments Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component for RXE Results Notes and Comments Clinical Trial Identification Page A 40 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 8 13 002 Pharmacy Prescription Response RRE Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Originator A or B Page A 41 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 3 14 001 Pharmacy Treatment Dispense T Originator A or B Message Header Notes and Comment
209. DLE 1 10 31 ACK2 DLE 2 10 32 ACK3 DLE 3 10 33 ACK4 DLE 4 10 34 ACK5 DLE 5 10 35 ACK6 DLE 6 10 36 ACK7 DLE 7 10 37 SOH Start of Heading SOH delimits the start of a message heading If the heading is subdivided into multiple transmission blocks SOH delimits the start of each block that continues transmission of the heading STX Start of Text STX precedes a sequence of characters that is to be treated as an entity and entirely transmitted through to the ultimate destination Such a sequence is referred to as text If a heading precedes the text STX delimits the end of the message heading If the text is subdivided into transmission blocks STX delimits the start of each block that continues transmission of the text ETX End of Text ETX delimits the end of a message text In multi block messages ETX indicates the last block of the message ETB End of Block ETB delimits the end of a block that is not the last block of a message EOT End of Transmission EOT indicates the conclusion of a transmission that contained one or more Health Level Seven Implementation Support Guide Page C 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols ENQ NAK ACKN message texts and any associated headings e EOT cancels any previous master slave assignment e FOT must never have a prefix e EOT is sent by a master station after the completion of the message transfer phase in
210. Discharge and Transfer 4 3 2 1 Message Segments Tables AU A02 A03 A04 A05 A06 A07 A08 A09 A10 All A12 A13 Al4 Al5 A16 Health Le Admit a patient Transfer a patient Discharge a patient Register a patient Preadmitapaten Transfer an outpatient to inpatient Transfer an inpatient to outpatient Update patient information _ Patient departing Patient arriving f Canceladmit f Cancel transfer Cancel discharge Pendingadmit Pending transfer Pending discharge vel Seven Implementation Support Guide ls gt lt ES gt X for HL7 Standard Version 2 3 1998 All rights reserved Description Message Message Message Message Message Message Message Message Message Message Message Message Message Message Message Message Page 4 9 Final Version 6 98 Chapter 4 HL7 Version 2 2 Overview AI7 Swap patients x Message Merge patient info a x Message NO LONGER USED S T A NN absence of absence Message sd Delete a patient record x Message Link Patient Information g A25 Cancel pending discharge x Message A26 Cancel pending transfer x Message A27 Message A28 Message A29 Message A30 Message A31 Message A32 Message A33 Message A34 Merge patient information Message E A35 Merge patient information
211. E FOR SUBMITTING ADDITIONS CHANGES TO THE DATABASE ss sss ee ee eene eee to oeste tns e een 38 APPENDIX D LOINC PRINTED REPORT DESCRIPTION sss ee eee eo sss ento e ee soso oeoo ene seen aee seen Pese eene e enses se een 44 APPENDIX E EXAMPLES FOR LOINC PROPERTY MATCHING eee esee eese ee eese enne soso sss aes seen sese eese eee eaae eese tn nes 45 Health Level Seven Implementation Support Guide Page H 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC Copyright and Terms of Use Copyright 1995 1996 1997 Regenstrief Institute and the Logical Observation Identifier Names and Codes LOINC Committee All rights reserved Permission is hereby granted without written agreement and without license or royalty fees to use copy or distribute the LOINC codes LOINC Users Guide and the contents of the LOINC database for any purpose so long as this copyright notice appears on any copies of the LOINC database and Users Guide and that the following conditions are met Users of the LOINC codes agree to the following conditions 1 They will not change the meanings of any of the LOINC codes 2 They will not change any contents in the defined LOINC Fields Users may add their own new fields to the database if they want to attach additional information to the existing LOINC record 3 They will include this notice of copyright and terms of use in
212. ER LAYER PROTOCOL C 4 1 Introduction This section describes a minimal HL7 lower level protocol to be used in a pure network environment It is an adaptation of the hybrid lower layer protocol C 4 1 1 Background It is assumed that this HL7 protocol will be used only in a network environment Most of the details of error detection and correction are handled by the lower levels of any reasonable network protocol and do not require any supplementation Page C 22 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols C 4 1 2 Goals and Assumptions The goal of this lower level protocol LLP is to provide an interface between HL7 and the network that uses minimal overhead while remaining compatible with other lower level protocols By remaining compatible with other LLP s vendors will need to make minimal changes to existing code to use this LLP It is assumed that there are only direct connections to the network Any other types of links such as RS 232 to a communication server will require another protocol to guarantee their integrity C 4 1 3 Differences This version of the LLP differs significantly from other LLPs in that it has only a single byte to signal the start of a message and two bytes to signal the end of a message There is no other lower level header or trailer information There are no other characters added to the HL
213. F 1 8 Hardware Operating System Technical Specifications sss sees sees eee ee eee F 32 Pell PROCESSOR EE F 32 Be np OU DUE cise eae deele F 33 F 1 8 3 Network and Communication Protocols eee F 33 E 1 8 4 Operating System sete e tU RR ER OU EOS RU eec Ree e etiaro ide ee F 34 FE 1 8 3 Performance Die 1 a qon petiere wed tur datu idad F 35 Foto Fault Tolerance Re od eee ae F 36 F 1 8 7 Backup Restore Journaling System Recovery seen F 36 Health Level Seven Implementation Support Guide Page TOC 17 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Table of Contents HL7 Implementation Support Guide RLSR Disaster RECOV ELY tia F 37 e RE ee F 37 PETS Cable Plant eate be tete tuam edi esent F 38 E lT 8 LT Security SpeciiCauOns acento ns pda Sandee adit pea te Senda F 38 F 1 9 Implementation Cost Schedules iia oa F 39 INE ME ODD ii il F 41 ABMS and ruo F 44 POS AA A EAER F 46 F 1 9 4 Modifications io iced Eoo eiii deeg F 48 F 1 9 5 Support and Implementation Staff F 50 DOLO RE F 54 PS Installation Assistance ns aee pee eege ee F 55 F 1 9 8 Ongoing Support Maintenance and Enhancements esses F 55 E 1 9 9 Shipping and N coe tte aan irse F 56 E L910 Total Lite yele COSI A eoe nau nde de ra tede eee odi e dinge uude F 57 F 1 9 11 Vendor Recommended Categories Approach F 58 F 2 SAMPLE INTEGRATION PROJE
214. F 46 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates Interface Category III Include all document to implement and support Category III interfaces COPIES PRICE DOCUMENT NAME PART NO SOURCE INCLUDED MEDIA COPY NOTES eer po ll LL TOTAL PROPOSED COST OF DOCUMENTATION FOR CATEGORY III INTERFACES Health Level Seven Implementation Support Guide Page F 47 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 9 4 Modifications Provide a description of all custom modifications that will be required to meet the requirements of the proposed solutions Include who will make the modifications the number of man hours estimated to make them and the time frame for completion Describe any assumptions and or additional information that will help to clarify the proposed pricing Interface Category I Include all modifications required to implement Category I interfaces DESCRIPTION OF MODIFICATION ESTIMATED COMPLETION PERFORMED BY COST MAN HOURS TIMEFRAME NOTES TOTAL PROPOSED COST OF MODIFICATIONS FOR CATEGORY I INTERFACES Page F 48 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates Interface Category II Include all modifications req
215. GULATION REPTILASE INDUCED TIME PT PPP PATIENT QN TILT TUBE COAGULATION REPTILASE INDUCED TIME PT PPP CONTROL QN TILT TUBE Blood banks often report red blood cell antigens for the patient and for each blood product pack assigned to that patient So we have RHESUS NOS AG ACNC PT SER PATIENT ORD AGGL RHESUS NOS AG ACNC PT SER BPU ORD AGGL The super system does not have to be valued and usually is not Assume patient when the super system is null Note the inclusion of the super system as part of the system represents a change from an earlier version of LOINC Earlier versions included this information in the 3 subparts of the component 2 6 Type of Scale 5th part The fifth data part of the test name specifies the scale of the measure and is a required part The abbreviation of the type of scale previously called precision given in Table 12 should be used in the fully specified name Note we have changed the codes for these from SQ to ORD and from QL to NOM to more accurately identify the meaning We have five kinds of scales Quantitative QN identify scales that can be tied to some physical quantity through a linear equation This means that if we have two reports for the same quantity one with a value of 5 and the other a value of 10 we know that the two are related in amount through the linear equation Y aX b When the intercept b is non zero we have a difference scale Fahrenheit temperature is a difference scale When it is zer
216. ION SQ SEQUENCE the number assigned to the data element for identifying the location of the data element on the segment FIELD NAME The entity name that may or may not be the same as the application name for the data element For example the LDM name would appear in this column and the application name would appear in the FIELD NAME column TYPE the data type of the generic data element Allowable values ST string TX text FT formatted text data NM numeric DT date TM time TS time stamp PN person name TN telephone number AD address ID coded value SI sequence CM composite CK composite check digit CN composite number and name CQ composite quantity with units CE coded element CF coded element with formatted values RP reference pointer TQ timing quantity MO money LENGTH the number of positions of the generic data element OPTIONALITY indicates if the generic data element is required optional or conditional in a segment Allowable values R required O optional C conditional REPETITION indicates if the generic data type may repeat Allowable values N no repetition Y the field may repeat an indefinite number of times integer the field may repeat up to the number of times specified in the integer TBL ID TABLE ID the identification number for the table of allowable values for the generic data element A table is not necessarily created for each data e
217. IS D 4 0S 22 0072 Visit Protection Indicator ID D J 0136 23 00724 Clinic Organization Name XON om gt J 24 00725 PatientStausCode IS o Toten 25 00726 VisitPriorityCode IS D TI Top 26 00727 Previous Treatment Date DT 9 III 27 00728 Expected Discharge Disposition IS To 28 00729 SignatureonFileDate DT 9 J pp i 29 00730 FirstSimilar Nness Date DT o pp 30 00731 PatientCharge Adjustment Code IS o 34 Toy 31 00732 RecurringServiceCode IS 3O9 Top 32 00733 BillingMediaCode LI ID D J A34 3 0136 33 00734 Expected Surgery Date Time TS QO III 34 00735 Military Partnership Code ID 0136 35 00736 MilitryNon AvalablityCoe ml doo 36 00737 Newborn Baby Indicator LI ID doo 37 00738 BabyDetainedIndicator ID 0136 B 1 77 QAK Query Acknowledgment Health Level Seven Implementation Support Guide Page B 45 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists Past 100096 Tones I HT EE H Wo AE
218. ISC or CISC 4 What architecture family is the processor 5 What is the design and performance of the internal BUS 6 What are the performance ratings for this processor 7 Does the processor allow an upgrade path If so what is it Page F 32 Final Version 6 98 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 8 Describe processor data integrity and error recovery features 9 Can the platform be incorporated into a cluster Open VMS or Unix F 1 8 2 Input Output Because of the high transaction loads expected to be performed on the AJE the system must be designed with high speed buses and 1 0 devices The majority of the 1 0 devices will be to the network adapter and the disk and for this reason St Anybody s Medical Center feels the system must be architected such that the network bus and 1 0 bus be capable of sustained handling of large bandwidths at high speeds While performance is a key attribute so is integrity therefore the system and its components must also maintain data integrity throughout all operations 1 Describe the attributes you deem important as 10 features when implementing the AIE product 2 What type of disk subsystem is used by the recommended processor 3 What are the benchmarks bandwidth bus etc associated with the recommended disk subsystem 4 What are optional disk subsystems available with
219. Internet in April of 1996 Since then we have released ten revisions of the LOINC data base and it now includes nearly 14 000 observation concepts The LOINC codes have been endorsed by the American Clinical Laboratory Association ACLA and recommended for adoption by its members and by the informatics committee of the College of American Pathologists The ACLA is the association of large referral laboratories and its members are responsible for more than 60 of US outpatient laboratory volume Quest Diagnostics formerly Corning MetPath and LabCorp two of the largest commercial laboratories have adopted LOINC as their code system for reportable test results as has LifeChem and ARUP Associated Regional and University Pathologists In addition University of Colorado Intermountain Health Care Promedica Kaiser Permanante Clarian Partners Indiana University Methodist Hospital and Riley Hospital Partners Healthcare System of Boston Brigham and Women s and Mass General Hospital Care Group of Boston and the United States Navy are adopting the LOINC codes for laboratory reporting Insurance carriers such as Empire Blue Cross are also adopting LOINC for internal purposes Internationally LOINC has also met success Geneva Switzerland is adopting LOINC in a trial preliminary to country wide adoption The province of Ontario Canada is adopting LOINC codes for a pilot study of a province wide laboratory data base and both Newfoundland and British
220. It will be used primarily to specify default elements such as currency denominations ISO 3166 provides a list of country codes that may be used 4 2 3 1 5 2 MSA segment Error condition Definition CE field allowing the acknowledging system to use a user defined error code to further specify AR or AE type acknowledgments This field is a generalized replacement for MSA 3 text message Page 4 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 4 HL7 Version 2 2 Overview 4 2 3 1 6 QRF segment additional query filters 4 2 3 1 6 1 Which date time qualifier Definition Specifies type of date referred to in QRF 2 when data start date time and QRF 3 when data end date time Order date time Cancellation date time Schedule date time Collection date time equivalent to film or sample collection date time Specimen receipt date time receipt of specimen in filling ancillary 1 e Lab Report date time report date time at filling ancillary i e Lab Any date time within a range 4 2 3 1 6 2 Which date time status qualifier Definition Specifies 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 Preliminary Report completion date time Current final value whether final or corrected Final only no corrections Corrected only no final with correction
221. L7 may be implemented to replace an existing custom interface for a new application or as part of a total system replacement The level to which the HL7 interface is visible to users will vary with the nature and extent of the implementation This guide takes a broad brush approach by attempting to cover a wide variety of possible implementations Readers of this guide should therefore review and apply those sections which are most appropriate 3 2 INTERFACE DEVELOPMENT 3 2 1 Project Planning 3 2 1 1 Identify Tasks Document tasks to be completed during the implementation phase of the project Also determine interdependencies among tasks to assist in scheduling and resource allocation Depending on the number of interrelated projects going on at your institution external projects e g network design and installation and interface engine selection and installation may have a direct impact on your application and interface installation Make sure that interdependencies between the projects are understood and that resource requirements and dates are determined with the global picture in mind 3 2 1 2 Identify Resources Identify those resources necessary to complete the tasks defined including resources under your direct control and those from other internal or external areas e g networking or communications department technical services and consultants Use the output from section 2 6 1 Organizational Considerations Heal
222. LOINC database So how is the database search done Simply stated Filter looks at each word in the submission e g 5 HYDROXYINDOLEACETATE SCNC and selects one to use as the keyword in the query for searching the database To speed up the search process every word in the LOINC database is indexed along with how many times that word appears in the database In our example Filter looks at the word count for each word eg 5 HYDROXYINDOLEACETATE SCNC etc and selects the one with the lowest frequency count as the keyword In this example HYDROXYINDOLEACETATE has the lowest count so it was used to return all LOINC records that contain this keyword For example the word 5 has 66 occurrences in the database but HYDROXYINDOLEACETATE has only 7 at the present time By contrast PT has 13 887 instances By using HYDROXYINDOLEACETATE as the keyword Filter only has to return 7 records from the database search Keywords for searches are almost always found in the Component field The Filter program is fairly complex and performs numerous probes on the submitted data However we can categorize the probes into two broad types of database search 1 perfect match searches and 2 ad hoc searches A search for a perfect match means that the Filter program is looking to see if your submission already exists in the database If Filter did find a perfect match it would be marked as such in your submission file A
223. Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists Pros sean 0882 SSCS H H H HTH H H H H 2 RR a NM o H H H 3 00532 BicdFum Pmsotd NM o D T O OT 4 00533 Blood Replaced Pims 1 Pame OO T y 5 00534 BlooiNotRephee amp PinsG NM Ill 6 0055 Co Insurance Dayse LI D T H 7 00536 Condition Code 35 39 15 a O O T s 053 CweedDasOQ NM o OO 0 L H 9 00538 NomCeerdDasQO NM D 0O o Too OSC 10 00539 Value Amount Code 46 49 CM 2 ll 1 00540 Number of Grace Days 1 NM o D Oo L1 12 00541 Spee Prog Indicator d4y CE 9 T 13 00542 PSRO URAppowlId 8 CE en SCS SSS 14 00543 PSRO URAppwdSuyFmGS pt amp OT 1 15 00544 PSRO UR Apprvd Stay To 89 pr ep 16 00545 OcuremeQ832 ea 49 T 1 17 00546 OccwremeSpmG3 pa o O T 18 00547 OccwSpanSurDaeG3 DT o O H H 19 00548 Occur Span End Deeg DT o SCS OOS 20 0049 UB 82 Locatora ST G9 H H 21 00550 UR 2Louor9 1 T o A T 2 005 UB 2Loaorz T 49 T 1 23 00552 UB 82 Locators O Sr n HL LLL Health Leve
224. Level Seven Implementation Support Guide Page TOC 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Table of Contents HL7 Implementation Support Guide A 4 10 2 3 PCT PC Goal Update PGL miii A 84 AIS PCS PC Goal Delete POL una A 84 A 4 10 4 PCI PC Patient Problem Add PPR eee A 85 AA LOS PC2 PC Problem Update PPR sse A 85 A 4 10 6 PC3 PC Problem Delete PPR sese A 85 A 4 10 7 PCB PC Patient Pathway Problem Oriented Add PPP A 86 A 4 10 8 PCC PC Pathway Problem Oriented Update PPP A 86 A 4 10 9 PCD PC Pathway Problem Oriented Delete PPP A 87 A 4 10 10 PCG PC Patient Pathway Goal Oriented Add PPG A 87 A 4 10 11 PCH PC Pathway Goal Oriented Update PPG A 87 A 4 10 12 PCJ PC Pathway Goal Oriented Delete PPG A 88 A 4 10 13 PC4 Patient Care Problem Query QRY eene A 88 A 4 10 14 PC5 Patient Problem Response PRR A A 88 A 4 10 15 PC9 Patient Goal Query QRY seene A 89 A 4 10 16 PCA Patient Goal Response PPV sese A 90 A 4 10 17 PCE Patient Pathway Problem Oriented Query QRY A 91 A 4 10 18 PCF Patient Pathway Problem Oriented Response PTR A 91 A 4 10 19 PCK QRY Patient Pathway Goal O
225. Message added PD1 and DB1 segments transfer A ADT ACK pending Message added PD1 DB1 and DRG discharge segments A17 ADT ACK swap patients Message added PD1 and DB1 segments A18 ADT ACK merge Message added PD1 segment BE c AN A QRY ADR patient query Message added segment QRF PD1 DB1 Kat A21 ADT ACK patient goes Message added PD1 and DB1 segments mE on a leave of absence ADT ACK patient returns from a leave of absence A ADT ACK delete a patient record A ADT ACK link patient information A ADT ACK cancel pending discharge A ADT ACK cancel pending transfer Message added PD1 and DB1 segments X Message added PD1 and DB1 segments Message added PD1 and DB1 segments Message added PD1 and DB1 segments X Message added PD1 and DB1 segments Message added PD1 and DB1 segments Message added PD1 DB1 DRG and ROL segments Message added PD1 and DB1 segments X Message added PD1 segment Message added PD1 DB1 DRG and ROL ADT ACK cancel pending admit ADT ACK add person information ADT ACK delete person information ADT ACK merge person information ADT ACK update A10 All A12 14 15 16 19 22 23 24 25 26 27 28 29 30 3l Page 5 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Change Message added PD1 a
226. N User Insurance Record 5 CK Employer insurance Code 2 20 CK Employer Identification Mumper 3 25 CK Employer Name 2 is __ Employer information Code 5 5 CK jmsPariD e 4 ek Ins Payor SubID_ 7 1 ck X Ins Eligibility Source _ Interface ABC requires additional insurance data not defined on any HL7 segment Add the data to the end of the ZIN Segment ZIN User Insurance Record 5 CK Employer insurance Code 2 20 CK Employer Identification Number 3 25 CK fEtmporrName 2 is Employer informationCode s 5 CK X timsPayoriD e 4 CK InmsPayorsubID z 1 CK TT ins Eligibility Source je 1 TX GuisReiCovCode 9 10 rx l GG ENTC Co Phone Number A 4 12 How to Use Z Segments in Messages Use Z Segments in the following ways e Appended to an existing HL7 message e Within aZ message A 4 12 1 Placing Z Segments in Existing HL7 Messages Use the following guideline when placing Z segments in existing HL7 messages 1 Place Z Segments at the end of the hierarchy to which they pertain The following examples illustrate the placement of Z segments in a message Health Level Seven Implementation Support Guide Page A 95 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL
227. ND Finding Arbitrary Count FORCE Mechanical Force Number FREQ Frequency Number Areic number per area IMP Impression interpretation of study Number Concentration count vol ID Identifier Number Content Count Mass HX History Number Fraction KINV Kinematic Viscosity Number Rate Count Time LEN Length Number Ratio LENRTO Length Ratio LINC Length Increment Relative Substance Concentration LIQ Liquifaction Substance Amount METHOD Method Substance Concentration MGFLUX Magnetic flux Substance Concentration Ratio MORPH Morphology Substance Content MOTIL Motility Substance Content Rate OD Optical density Substance Fraction OSMOL Osmolality Substance Concentration Increment Substance Rate PCT Percent Substance Ratio PRCTL Percentile Threshold Substance Concentration PRID Presence or Identity PPRES Pressure partial Volume PRES Pressure Volume Content PRESRTO Pressure Ratio Volume Fraction RANGE Ranges Volume Rate RATIO Ratios Volume Ratio RDEN Relative Density Energy Area REL Relative Resistance Area ROUTE Route of RX Volume Area SATFR Saturation Fraction Volume Rate Ratio SHAPE Shape Volume Rate Area SMELL Smell SUSC Susceptibility ACNC Concentration Arbitrary Substance TASTE Taste ACNT Arbitrary Content TEMP Temperature AFR Arbitrary Fraction TEMPDF Temperature Difference THRACNC Threshold Arbitrary Concentration TEMPIN Temperature Increment ARAT Arbitrary Rate TEXT Text Health Level Seven Implementation
228. NIZATION socorristas 2 2 2 4 1 Project Organization coser tpe IUe REY RA RES SEA QUU CURE EA CSS AE geed 2 2 22 1 DelmeScope Ut Proein ia a 2 2 2 2 1 2 Determine Resource Requirements ii ds 2 2 2 3 1 3 Establish Advisory Committee din cats ee eee 2 2 2 2 2 Work EE eege 2 2 2 2 2 1 Develop Project EEN 2 2 2 2 2 2 Assign Resource Requirement so encoded ed en nie alie d dee ee 2 2 2 2 2 3 Define Status Reporting Reoutrementg eese 2 3 2 2 2 4 Prototype Deronstratlon deele dte ttp pereat ole be Peg ape aes HE LO pL eed 2 3 2 3 BUSINESS STRATEGY PERFORMANCE MEASURES eee 2 3 Health Level Seven Implementation Support Guide Page TOC 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Table of Contents HL7 Implementation Support Guide 2 3 1 BUSINESS Strategy os 2 3 1 1 Prototvpe DermonsitatlOn iode Pete date bo db 2 3 1 2 Streamline Current Operations aen eec t Ho E IR RORIS e D E tr iate 2 23 1 25 SS EE 2 9 T Develop SECULAR 2 3 2 Performance Measures 3o dee EI cec is 2 3 2 1 Develop Benefits ala lt P ec once decere rubi ta tende odas eds 2 35 22 Establish Benefit UA eodera ee eon e Ree ree 2 4 INFORMATION NEEDS AND APPLICATION REQUIREMENTS eee 2 4 1 Current Status Assessment Information Needs And Systems 2 4 1 1 Document Current Environment esee ees i a A A A a 2 4 1 2 Identify Functional Information Reoutrementg eene 2 4 2 Current Status Asses
229. OF DIRECTORS Chair George Woody Beeler Jr Ph D Mayo Foundation Phone 507 284 9135 Fax 507 284 0796 Email beeler mayo edu Past Chair Ed Hammond Ph D Duke University Medical Center Phone 919 684 6421 Fax 919 684 8675 Email hammo001 mc duke edu Treasurer Mark Shafarman Oacis Healthcare Systems Inc Phone 415 925 4570 Fax 415 925 4455 Email mshafarm oacis com Secretary Karen Keeter IBM Global Healthcare Solutions Phone 770 835 7945 Fax 770 835 7972 Email kkeeter vnet ibm com Technical Committee Chair John Quinn Ernst amp Young LLP Phone 216 737 1242 Fax 216 622 0198 Email john quinn ey com Technical Vice Chair Wes Rishel Wes Rishel Consulting Phone 510 522 8135 Fax 510 521 2423 Email wes rishel com Directors at Large Stan Huff MD Intermountain Health Care Phone 801 442 4885 Fax 801 263 3657 Email coshuff ihc com Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page 1 11 Final Version 6 98 Chapier 1 Introduction Debbie Murray Catholic Healthcare West Phone 650 917 4524 Fax Email dmurray2 chw edu Abdul Malik Shakir The Huntington Group Phone 510 865 3900 Fax 510 271 6859 Email abdul malik_shakir idx com Mead Walker Shared Medical Systems Phone 610 219 3160 Fax 610 219 3512 Email mead walker 2 smed com International Representati
230. OW LONG 4 Row number of this term in submitter s file This submitted row number will be preserved even when outputs are sorted differently 2 S_LOCAL_CD TEXT 50 The submitter s local code used to identify the test observation in the submitter s master file This can be any string of up to 50 characters 3 S_COMPO TEXT 150 Submitter s Analytes Component Mandatory User Guide 2 2 4 S_PROP TEXT 10 Submitter s Kind of Property Mandatory but we can help if you provide enough details User Guide 23 5 S_TIME TEXT 10 Submitter s Time Aspect Mandatory User Guide 2 4 6 S_SYS TEXT 35 Submitter s System Sample Type Mandatory User Guide 2 5 7 S_SCALE TEXT 30 Submitter s Type of Scale Mandatory User Guide 2 6 8 S_METH TEXT 50 Submitter s Type of Method If required User Guide 2 7 9 S_REL_NAM TEXT 250 Submitter s Related Names Strongly recommended Common names acronyms or synonyms User Guide Appendix A 10 S_LOINC TEXT 10 Submitter s LOINC number Strongly recommended This is the LOINC number that is similar but not the same as the submitter s test 11 S_RESULTS TEXT 50 Submitter s Example Results Strongly recommended As reported by your lab 12 S_UNITS TEXT 20 Submitter s Example Units Strongly recommended As reported by your lab 13 S_ID TEXT 50 If the submitter includes a reference code ID for each unique submission to LOINC record that ID here and this will be returned with questions or a
231. POST DOSE PO MCNC PT SER QN The actual dose might then be sent as a comment or as a separate test that carries the dose as its value To accommodate laboratories that wish to transmit the relevant challenge dose as a separate observation we also define separate test names and codes for reporting such doses This dose could then be sent by the reporting service as a separate result in a separate OBX segment The name of the observation that identifies the value of the dose would have the form drug or challenge substance time post dose challenge substance Examples GLUCOSE PO MASS PT DOSE QN GENTAMICIN IV MASS PT DOSE QN Page H 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Thus we distinguish a drug concentration from the drug dose by means of the system sample 4th part of the test name see Section 2 5 You can find the observations that carry the dose of drugs or challenges grouped in the class DRUG within the LOINC database This approach has the advantages of parsimony and practicality It also provides an observation ID for the piece of information that must be transmitted along with the request for the observation Another example would be OXYGEN PRES PT BLDA QN OXYGEN INHALED VRAT PT IHG QN liters minute or milliliters second OXYGEN INHALED MECHANISM TYPE PT DOSE NOM to report kind
232. Patient Information 1 00211 Prior Patient ID Inteml R CX QO Os 2 00212 Prior Alternate Patient ID CX OY 3 00213 Prior Patient Account Numer CX QO ss 4 00214 PriorPatient ID Exemal CX QO Y 5 0127 Prior Visit Number LI CX QO 9 6 01280 Prior Alternate VisitID CX QO ss 7 01281 Prior PatientName_ xN 8 III B 1 49 MSA Message Acknowledgment 1 00018 AcknowledgmentCode R p 0008 2 0000 MessageContol ID R ST Qo P 9 3 00020 TextMessage ST 80 00 jp 4 00021 Expected Sequence Numer NM 59 0 0 0 5 0022 Delayed ACK Type 1 B ID D Com 6 0003 EmorCondton TE CE 0 PT Health Level Seven Implementation Support Guide Page B 25 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 50 MSH Message Header Required segment 1 0000 Field Separator R ST 2 0000 EncodingChaacers R ST MY 3 00003 Sending Application HD BO TI S 4 00004 Sending Facility m aw PP 5 00005 Receiving Application HD 80 TI 6 00006 Receiving Facility BD 80 0
233. Process e a E E R E C 6 C 2 5 1 Initiating System Processing A a A C 6 C 2 5 2 Responding System Processing ss re o A oet dp eae ode cada C 7 C 2 6 Implementation System and Site Specific Issues sene C 7 C 2 6 1 Connect Retries for Optional Transient Virtual Crceuts C 7 2 9 RECEIVE Limeout TOS dd sd C 7 C 2 6 3 The Network Parameter Table NPT C 7 C 2 6 4 Error Reporting and Logging sss sees sese C 8 C33 X328 BASED DATA LINK PROTOCOL 1er trist eden entia ned inet see decida C 8 O O PE RN C 8 oT Introduction EE C 8 C 3 1 2 Requirements and ASSUMPTIONS KEREN C 9 C3 1 3 Environment Model inser ede bred geli bed ud ee optet e he C 10 C 3 1 4 Communication Control Characters sese sees eee C 11 ES Block e Hee C 13 C316 Text Length TT C 13 CILT BlockGherk ime T Te T C 13 C 3 2 Establishment of Master Slave Relaponczhup eene C 14 LE E TT Transfert E C 15 C 3 3 Transmission BlOCkS ee e C 16 E33 2 Replies T C 16 LR ADOS ATA S TR eT C 17 C34 TU Block ADO EE C 17 C 3 4 2 Sending Station ABOT sese C 18 C 3 4 Termination teruel cias C 19 344 ROVER C 19 C 3 5 Block Headings and Acknowledgment Prefixes eese C 20 E TEE C 20 WB E EE C 20 C 3 6 Timers and Recovery Procedures sss sss C 20 A KE C 20 326 2 RECOVETY EE C 21 Health Level Seven Implementation Support Guide Page TOC 15 for HL7 Standard Version 2 3 1998 Allrights reserved Final Version 6 98 Table of Contents HL
234. Rationalization and clarification of event structures Now part of scope for HL7 v 3 Creation of a network server for HL7 tables so that updates to them can be made public immediately rather than waiting until the publication of the next version of the standard 4 2 3 2 2 Now part of scope for HL7 v 3 Extensions to the encoding rules Allowing more than a single set of coding rules Now part of scope for HL7 v 3 Message construction and modeling rules Now part of scope for HL7 v 3 Usage of Object brokering paradigms in creating and managing HL7 objects e g OLE and CORBA Now part of scope for HL7 v 3 4 2 3 3 What are the advantages of HL7 Control Query v 2 2 over v 2 1 The main advantage comes with the flexibility that the new acknowledgment paradigms give implementors Depending on the need of the implementors other new features may be of critical importance the new datatypes or enhanced datatypes the new query filter fields the new optionality value of conditional other new fields in various segments as noted above 4 2 3 3 1 How to decide whether to upgrade from v 2 1 If one of the new features is critical to your implementation or to future implementations this is a good reason to upgrade 4 2 3 3 2 Key functional issues in migration from v 2 1 The control query issues tend to be less concerned with the application areas and more concerned with the structure of data or generic inter application message
235. Reis Wizdom Systems Inc Ph 630 357 3000 Email 71045 14 compuserve com Mark Tucker Regenstrief Institute Ph 317 630 2606 Fax 317 630 2669 Email tucker mQGregenstrief iupui edu Mission Draft The Control Query committee is responsible for defining the details of the message transport services including encoding rules and auxiliary protocols maintenance of common datatypes definition of the query framework and definition of the framework for master files support There is a process meta model for control query For each main topic project project described below we will determine the use cases and work with the M amp M TC to complete the process meta model Projects e Network Protocol e Data Type Definition e Security e Interversion Compatibility Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page 1 13 Final Version 6 98 Chapier 1 Introduction e Query Mechanism e Master Files IMPLEMENTATION Scott Councilman MEDIWARE Information Systems Inc Ph 408 438 4735 Fax 408 438 8422 Email scott mediware com Mission Develop and update the Implementation and Support Guide The guide provides assistance to health care institutions hospital information system vendors consultants and other support groups that are considering system development and implementation activities using the HL7 protocol The guide will be published in conjunct
236. Relationship 1 01098 ImplicatedProduct_ R CE 60 J Jf 2 01099 Generic Produet IS D y 3 01100 ProductClass CET 00 9 43 4 01101 Total Duration of Therapy CQ 9 4 n S J7 5 01102 Product Manufacture Dae TS Rss 6 01103 Product Expiration Date TS Q9 J 0 0 S 7 01104 ProductImplantationDate TS o II S 8 01105 ProdutExplamtionDae TS eo J 0 0 0 0 0 9 01106 SingleUseDeviee_________ ___ 18 e ITT UST Health Level Seven Implementation Support Guide Page B 35 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 10 01107 Indication For Product Use CE 60 5 0 11 01108 Product Problem IS 9 J 0239 12 01109 Product Serial LotNumber__ ST GO Jol S 13 01110 ProdutAvalableforInpection IS D y 14 01111 Product Evaluation Performed CE 6 ss 15 01112 Product Evaluation Status CE Is 16 01113 Product Evaluation Resis CE ep III 17 01114 Evaluated ProductSouce ID
237. SCRTO Substance Concentration Ratio 2958 7 SODIUM POTASSIUM SCRTO PT SWT QN MCRTO Mass Concentration Ratio 2768 OIPHEN Y LALANINE TY ROSINE MCRTO PT SER QN Note CSF SERUM Protein calculation is not a ratio because the measured components are not in the same system It should be a relative mass concentration RLMCNC e g 2858 9IPROTEIN CSF PROTEIN SERUM RLMCNC PT CSF SER QN Page H 54 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 4 Relative RL Relative amount of component A in system 1 compared to system 0 By extension RLCCNC Relative Catalytic Concentration RLMCNC Relative Mass Concentration RLSCNC Relative Substance Concentration RL should be used anywhere an actual measurement is divided by a measurement on a normal or control It should also be used when a quotient is created by dividing a measured substance in SERUM by the same substance measured in CSF URINE etc RLCCNC Relative Catalytic Concentration 6302 4ICOAGULATION TISSUE FACTOR INDUCED NORMAL ACTUAL RLCCNC PT PPP PATIENT QN RLM Relative mass 3278 9IKININOGEN HIGH MOLECULAR WEIGHT ACTUAL NORMALIRLMIPT PPP QN RLMCNC Relative Mass Concentration as noted previously 2858 9IPROTEIN CSF PROTEIN SERUM RLMCNC PT CSF SER QN RLSCNC Relative Substance Concentration 3190 6ICOAGULATION FACTOR IX AG ACTUAL NORMAL RLSCNC PT QN 5 CMPLX Other divisions of on
238. Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved R R R R Appendix A HL7 Transaction Checklist A 4 2 6 A06 Transfer an Outpatient to Inpatient ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Next of Kin Patient Visit Patient Visit Additional Info Disability Information Diagnosis Related Group Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information Health Level Seven Implementation Support Guide Page A 15 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 2 7 A07 Transfer an Inpatient to Outpatient ADT Originator A or B Page A 16 Final Version 6 98 Message Header Event Type Patient Identification Additional Demographics Merge Information Next of Kin Patient Visit Patient Visit Additional Info Disability Information Diagnosis Related Group Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Add l Info Insurance Informati
239. Standard e Initial versions of the standard focused on information systems within hospitals versions 2 2 and 2 3 substantially expand coverage to define formats and protocols for computer applications in all health care environments e The very nature of the diverse business processes that exist within the health care delivery system prevents the development of either a universally agreed on process or data model to support a definition of HL7 s target environments In addition HL7 does not make a priori assumptions about the architecture of health care information systems nor does it attempt to resolve architectural differences between health care information systems For these reasons HL7 cannot be a true plug and play interface standard These differences at HL7 sites will require site negotiated agreements See Why isn t HL7 Plug and Play for further comments on this issue e The initial interest of the HL7 Working Group was to employ the Standard as soon as possible Having achieved this HL7 has been approved by the American National Standards Institute ANSD to be recognized as an Accredited Standards Organization ASO e Cooperation with other related health care standards efforts eg ACR NEMA DICOM ASC X12 ASTM IEEE NCPDP etc has become a priority activity of HL7 Adapted from the introduction to the HL7 Specifications G 9 2 The Governance of HL7 G 9 2 1 What is the HL7 Working Group The HL7 Working Group is
240. Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 2 6 4 C 3 C 3 1 C 3 1 1 Page C 8 Error Reporting and Logging An important feature of any software package that does data interchange is its ability to log and report errors to the operator and other system administrators These are however local matters since they do not affect the data formats or processing rule They are not specified by this Standard X3 28 BASED DATA LINK PROTOCOL Overview Introduction The communications protocol described in this section may be used to transfer HL7 messages between systems Much of the language contained in this protocol specification is based on or reproduced from the ANSI X3 28 1976 Standards document These portions are reproduced with permission from American National Standard X3 28 copyright 1976 by the American National Standards Institute Copies of the complete X3 28 Standard may be purchased from American National Standards Institute 11 West 42 Street New York NY 10036 212 642 4900 X3 28 has a collection of options to support various communications requirements This section is mainly comprised of a selection of these options appropriate for HL7 use Specific local implementations may require functionality that is not provided by the protocol described in this document It is strongly recommended that any additional functionality be implemented using options fro
241. StudentIndicator IS 0231 41 00120 Religion IS or Come 42 00746 Mothers Maiden Name IL XPN 489 TP cE op S EE SEN 43 WE 44 00125 EthnicGrop IS 45 00748 Contact Person s Name XPN 8 46 00749 Contact Person s Phone Numer XTN GO 47 00747 ContactReason CE 80 y 48 00784 ContactRelationship PAS 2 0063 49 00785 ConactJobTile ST J 8 51 01299 Guarantor Employer s Organization XON 130 52 00753 Handicap 0 IS 0310 53 00752 R H I Q2 3 54 01231 Guarantor Financial Class FC 6 VA 55 01291 GuarantorRace TS 0005 Page B 16 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 37 IN1 Insurance aI toopi psam N O 1 TH O p A A EA AN 2 00368 Insurance Pian D R 9 0072 3 00428 Insurance Compan ID R CX ss 4 00429 Insurance CompanyName RON 30 S 2 00430 Insurance Company Address XAD 09 ss 6
242. Support Guide for HL7 Standard Version 2 3 1998 All rights reserved YYYY MM DD HHMNM SS S S SISI Z Z ZZ degree of precision gt identifier ST gt text ST gt name of coding system ST gt alternate identifier ST gt alternate text ST name of alternate coding system ST gt identifier ID formatted text FT gt name of coding system ST gt alternate identifier ID gt alternate formatted text FT name of alternate coding system ST gt ID number NM gt check digit NM code identifying the check digit scheme employed ID gt lt assigning authority HD gt ID number ST gt family name ST given name ST gt middle initial or name ST gt suffix e g JR or III ST prefix e g DR ST degree e g MD ST source table IS assigning authority HD ID ST gt check digit ST gt code identifying the check digit scheme employed ID gt assigning authority HD gt identifier type code IS assigning facility HD Page A 5 Final Version 6 98 Appendix A HL7 Transaction Checklist GE Data Data Type Name Notes Format Application A Application B ype XCN Extended In Version 2 3 use instead of composite ID the CN data type lt ID number number and ST family name ST name given name ST middle initial or
243. T Originator A or B Originator A or B Page A 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved A 4 2 15 A15 Pending Transfer ADT Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information App A Message Header Event Type Patient Identification Additional Demographics Next of Kin Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information AA Diagnosis Information Appendix A HL7 Transaction Checklist A 4 2 16 Pending Discharge ADT Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Diagnosis Information Diagnosis Related Group A 4 2 17 A17 Swap Patients ADT Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Patient Identification Additional Demographics Pat
244. TAIN Names for results of staining procedures performed on organisms that are growing in culture will use Isolate ISLT as the system sample type For example MICROORGANISM IDENTIFIED PRID PT ISLT NOM FUNGAL SUBTYPING Names for organism specific cultures BRUCELLA SP PRID PT BLD NOM ORGANISM SPECIFIC CULTURE BORDETELLA PERTUSSIS ACNC PT THRT ORD ORGANISM SPECIFIC CULTURE CHLAMYDIA SP PRID PT GEN NOM ORGANISM SPECIFIC CULTURE LEGIONELLA SP PRID PT SPT NOM ORGANISM SPECIFIC CULTURE Names for method for general class of organism FUNGUS IDENTIFIED PRID PT WND NOM ROUTINE FUNGAL CULTURE MICROORGANISM IDENTIFIED PRID PT CSF NOM STERILE BODY FLUID CULTURE Again the Result Value of these tests would be either organism names or other statements of culture outcome Table 15 contains valid values of the culture result OBX segment Table 15 Example Culture Results No growth Gram positive cocci Small Gram negative rod Escherichia coli Normal flora Candida albicans Note if a test applies to a specific species of organism the component should include the genus AND species at least If the measure applies to a series of species in the same family the string SP must be included If it applies to as subgroup of the genus then that subgroup should be named PRID as a property should be used when the value of a test can identify one set of alternative infectious agents If the culture is for herpes virus and the culture can have resu
245. TIONS AND ANSWERS 5 2 1 Control Query responses by Mark Shafarman 5 2 1 1 What was the driving force behind the creation of version 2 3 In comparison with version 2 2 what advantages does it offer Version 2 3 offers e New datatypes especially the x tended versions of PN CN etc and the encapsulated data used in wave form transmissions in chapter 7 of the Standard e Enhanced query functionality especially virtual table queries and encapsulated query language queries note some new segments too e Clearer definitions of tables including the ID IS datatype distinctions e Support for other character sets 5 2 1 2 Are there any functional issues that should be addressed prior to implementing this chapter Users should implement Version 2 3 if they need the new functionality The primary implementation issues are not in backwards compatibility because most new information is just that new and the 2 3 backwards compatibility clarified definition covers how to interpret those areas where it is an issue Health Level Seven Implementation Support Guide Page 5 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview 5 2 2 5 2 2 1 5 2 2 2 5 2 2 3 5 2 3 5 2 3 1 5 2 3 2 Page 5 2 Financial Management responses by Freida Hall What was the driving force behind the creation of version 2 3 In comparison with version 2 2 what advantages
246. TN to XTN number GT1 19 Guarantor employee ID number repetition changed to Y Data type changed from ST to CX repetition changed from Y 3 to Y element Name changed from Guarantor Employee ID Num to Guarantor Employee ID Number Data Type changed from ID to IS Length changed from 60 to 130 data type changed from ST to XON GT1 20 Guarantor employment status GT1 21 Guarantor organization name Page 5 22 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Segment Seq repetition changed to Y element name changed from Guarantor Organization to Guarantor Organization Name GT1 22 Guarantor billing hold flag X J S O zv eee ed 0 code ee time po GTI 25 Guarantor death flag IX GT1 26 Guarantor charge X Ee demum IA GT1 27 Guarantor household X EY Imus qu GTI 28 Guarantor household size X J ___ ____________________ A T number GT1 30 Guarantor marital status X code GT1 31 Guarantor hire effective X date po GTI 32 Employment stop date X Citizenship Student indicator Religion Nationality GT1 44 Ethnic group X GTI 45 Contact person s name X GT1 46 Contact person s telephone number Contact relationship Job title GT1 51 Guarantor employer s organization name PGTI S2 Handicap E o T O PGTI S3 Jobstatus TX GTI 54 l Gu
247. TSIS_UNITSIS_IDIS_COMMENT lt CRLF gt Each field is separated from the other by a Tab character That is each vertical bar above would actually be a Tab character i e an ASCII 9 Each line is terminated by a carriage return line feed pair i e the lt CRLF gt above Therefore each lt CRLF gt terminated line in the ASCII file becomes a submission record Note that the field lengths presented in Table 20 still apply to ASCII file submissions because we read the ASCII file data you submit into an Access database as described in Tables 20a and 20b Using the previous example one line might appear as 1IG23IGLUCOSE 90m POST 50g LACTOSE POIMCNCIPTIURIORDITEST STRIPIII6762 9IIMG DLII where the vertical bars represent the Tab character Notice that two vertical bars appear between TEST STRIP and 6762 9 In this example this means that the related names field is empty i e a null field value The example also shows that fields S RESULTS S_ID and 5 COMMENT are also empty Without the empty field the field information would get out of sync and it would appear that the related names for this submission was actually the closest LOINC number for the submission i e 6762 9 Therefore the ordering of the fields and the use of the Tab character to delimit the fields is very important Printed Reports Submissions ultimately end up being processed by various software programs at RI to help evaluate the submissions One
248. Table of Contents CHAPTER 1 INTRODUCTION Wal PURPOSE EE 1 1 1 2 HL BACKGROUND ra t fth Se e Saat Ho t it ett 1 2 1 3 HL7 TRANSACTIONS reise deae cab tene tereti is 1 2 1 4 COOPERATION WITH OTHER STANDARDS DEVELOPING ORGANIZATIONS 1 2 LS OVERVIEW Ca ss illa dl lll idol ed 1 3 1 51 He Encoding Rules iii A EEN bi 1 3 15 2 Local Vattalfolls eege 1 4 1 5 3 Evolutionary Changes to the Standards iii is 1 4 1 5 4 Applicability to File Transfers Batch Processing sss sese 1 5 1 5 5 Relationship to Other Protocols tai nd 1 5 1 5 5 1 Lower Layer Protocol T 1 5 15 52 Other Applications EE 1 6 133 3 Proprieta E 1 7 1 6 REFERENCE DOCUMENTS coiusdaiiancii ere eite eae osa cet e iii 1 8 1 63 ANSI Standards ni oet coeds le iio oA onde tei he 1 8 1 62 ISO Standards sc ed e RH uentus e e HR Ree RD RENS 1 8 1 6 3 Codes and Terminology SOUIEES a A A AA IA A 1 8 1 6 4 Other Applicable Documents ni iio noise 1 9 1 7 PUBLISHED HEALTH CARE INFORMATICS STANDARDS eee 1 10 13 EXPECTED PUBLICATIONS ias A A A AA Ad 1 10 1 9 JHE SPONSORED MEETINGS cout ds 1 10 1 10 KEY CONTACTS cooninisiaiian 1 11 TAL INTERNET RESOURCES usd tad 1 22 LE I General Informations iu orte IE 1 22 1 11 2 Homepages for Technical Committees and Special Interest Groups 1 22 1 12 SUGGESTIONS AND COMMENTS eerste eege Eegeregie E 1 23 CHAPTER 2 PLANNING METHODOLOGY 21 INTRODUCTION eeen iode iiio ooa a 2 1 2 2 PLANNING AND ORGA
249. The other quantity of interest is the percent of these cells per 100 lymphocytes These are represented as number fractions e g Lymphocytes CD10 CD20 100 lymphocytes NFR PT BLD QN The database also includes fully specified names for all of the commonly reported HLA antigens These are grouped in the class HLA Experimental methods can define many subtypes of many antigens so this list is not exhaustive and is also likely to expand with time Example HLA AI ACNC PT BLD PATIENT ORD 3 4 Naming results of microbiological culture The inherent complex structure of results of microbiological culture presents unique challenges for standard names Result Status Preliminary Final will be indicated in the OBR segment of HL7 segment with the Result Status field OBR 25 not as part of the name Specimen Type Serum Blood Urine etc will be indicated in the HL7 OBR segment with the Specimen Source field OBR 15 but may also be represented in the name Details of specimen collection will usually be noted as OBX segments or comment segments that accompany the culture result message The observation identifier for the OBX segment will have the fully specified name of Specimen Collection Description NOS NOMS and the Observation Sub ID field will be used to order or group sets of observations That is if the material was collected by swabbing a wound of the right upper arm multiple OBX segments would be created each with the name Specimen Co
250. Users Guide April 16 1998 Appendix D LOINC Printed Report Description Changes to standard report format We have changed the content of the printable WordPerfect and Word LOINC reports in the following ways The ASTM Code IUPAC Code MetPath Code and Comments columns are no longer displayed They are still maintained in the database they are just not printed on the word processing reports Columns representing the Exact Core Component Synonym Change Reason IUPAC Analyte Code and Molar Mass have been added to the report The Exact Core Component Synonym IUPAC Analyte Code and Molar Mass fields are new to LOINC with Release 1 0h see Section 4 for a description We stress that this is a change to the printed reports only we have not and never will change the order of the fields in the database itself in either the tab delimited ASCII LOINDBT1 TXT or the dBase LOINC DBF formats Table 22 Columns Appearing on Printed Reports The order of the columns on the reports is Status Class Loinc Number Map To Analyte Component Name Type of Property Time Aspect System Specimen Type of Scale Method Related Names Exact Core Component Synonym Date Last Changed Reason for Change Answer List EUCLIDES Code IUPAC Analyte Code Molar Mass Health Level Seven Implementation Support Guide Page H 53 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC
251. Version 2 3 1998 All rights reserved C 2 3 C 2 3 1 Appendix C Lower Layer Protocols C character count wrong in previous data block received X checksum wrong in previous data block received B data too long for input buffer in previous block received G Error not covered elsewhere ccecce Block Size 5 bytes Character count of all characters so far in the data block up to and including the last data character For this version of the protocol this is 5 the size of the dddd field Note HL7 message ends with a lt CR gt character This character is considered as part of the data XXX Checksum 3 bytes Exclusive OR checksum of all characters in the block up to and including the last data character The checksum is expressed as a decimal number in three ASCII digits If the value of this field is 999 the checksum should not be computed Processing will proceed as if it were correct This feature is used for applications where the messages will be translated from one character set to another during transmission lt EB gt End Block character 1 byte Configurable on a site specific basis Unless there is a conflict the value should be ASCII FS i e 0x1C This should not be confused with the ASCII characters ETX or EOT lt CR gt Carriage Return 1 byte The ASCII carriage return character i e 0x0D Processing Rules Optional Connection and Disconnection When two entities
252. Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC the information is sent over networks that may apply case conversion To identify parts of the few names that by international convention are case sensitive such as red blood cell antigens we use the word LITTLE in front of the letter that is lower case We use a similar convention to indicate superscripts with the word SUPER See examples in Table 3 Since some systems are capable of distinguishing upper and lower case we provide mixed case names in the EXT CP SY Exact Component Synonym field Field 33 However the available character set does not permit direct representation of superscripts these are recorded in the EXT CP SY field as a carat e g Lu a Table 3 Case Specifying Conventions Our conventions Standard mixed case A LITTLE U LITTLE A AB Au a AB L LITTLE U LITTLE SUPER A Lu LITTLEI 1 AB I 1 AB 2 4 5 Roman numerals vs arabic numerals Whenever possible numerals shall be represented in their arabic form However when the conventional name uses Roman numerals as is the case for clotting factors such as factor VIII the LOINC primary name will use Roman numerals and we define a synonym containing Arabic numerals 2 0 Component analyte 1st part The first main part consists of three subparts 1 the principal name e g the name of the analyte or the measurement 2 the challenge or provocation if relevant including t
253. When the HL7 committee met on the topic of clinical order numbers it imposed the new requirement on HL7 participants that the order numbers sent and received over the protocol be unique through all time As more data is stored on line longer in repositories for example this has been an important requirement Lab systems have taken several approaches Some may have decided not to recycle their accession numbers and used them as order numbers Where this is not seen as practical or desirable they typically have done something like prepending another field to the accession number to create a filler s order number for external communications The Julian date of the order is one such possible qualifier It is somewhat wasteful of space since not every combination of the four digit date and the appended accession number will be used but disk is cheap processors are fast and the disruption on a system and an organization of changing the accession number scheme does not seem to be justified by the waste of a few digits I believe that in situations where the physician is talking to a lab person and looking at the Sender Order Number on the report lab personnel are frequently saying what are the last six digits of the order number or something similar to get an accession number to put into their computer screen to look up the test Similarly if the accession number or filler s order number is needed as a reference on a bill there is a place in the financi
254. Y BY CHAPTER OF CHANGES FROM VERSION 2 1 TO 22 4 8 4 3 1 Chapter 2 Conttol QUE EE 4 8 ASU New Data Types ii D eo ORE HI n SQ IIR Orte ees Deli aaa aa 4 8 d e EE 4 8 4 3 13 EE 4 8 T3143 Data Elements T 4 8 Health Level Seven Implementation Support Guide Page TOC 5 for HL7 Standard Version 2 3 1998 Allrights reserved Final Version 6 98 Table of Contents HL7 Implementation Support Guide 4 3 2 Chapter 3 Admission Discharge and Transfer seen 4 9 4 3 2 1 M ssaserSesments ET 4 9 43 2 2 Data Elements eegene ed 4 10 4 Chapter 4 Order Entry catch A NAN 4 11 4 3 3 1 Messases Segments Lables o deese UIS reet uod seen eU Run fece dare ge 0a 4 11 2 5 3 2 Data El ments eoe eee eccesso de ee dd eee 4 12 34 O O 4 13 43 5 WE e ATOE TTE E 4 13 4 3 5 1 Messases Segmients Tables see et scare dE RS Lei d cR Ed eue Sad tae UR 4 13 4 33 22 A naa E E E 4 13 4 3 6 Chapter 7 Observation Reporting at 4 14 4 3 6 1 Messages Segments Tables oie el Du 4 14 102 Dala Element e Clio ie te act Mi neater etn ati 4 14 4 3 7 Chapter 8 Master Files encon aan ans ines 4 15 4 3 7 1 Messages Segments Tables icio A ee 4 15 CHAPTER 5 HL7 VERSION 2 3 OVERVIEW 5 1 INTRODUCTION cua ta 5 1 5 2 VERSION 2 3 QUESTIONS AND ANSWERS ur Ai 5 1 5 2 1 Control Query responses by Mark Shafarman esee 5 1 5 2 1 1 What was the driving force behind the creation of version 2 3 In c
255. a on both the HL7 segment and the Z segments This will support backward compatibility for existing users of the interface software The following examplehnustrates the process Version 2 1 ZIN User Insurance Record 5 CK Employer insurance Code 2 20 CK Employer Identification Number 3 25 cK X EmployerName a 2 is Employenformation Code 5 5 CK lS Payal e 4 ek Ins Payor SubID_ 7 1 ek Ins Eligibility Source HL7 defines the following data on the IN2 effective with HL7 Version 2 3 IN2 insurance additional information ELEMENT NAME 2 59 CX JlInsured sEmployelD a 1 IS 0139 Employer Information Data Version 2 3 Define the Following Z Segment ZIN The standard implementation requires the interface to send identical values of the data on the IN2 and the ZIN segment The interface may send null values on the ZIN for positions 2 and 4 if the interface does not need to support prior releases 2 1 of the interface The examples in this text are to assist in the understanding of the standard implementation It is not intended for the examples to represent a specific application interpretation Page A 94 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist ZI
256. a type changed from AD to XAD STF 17 STF 18 STF 19 STF 20 STF 21 STF 22 Driver s license number staff STE23 STEO4 Autoins expires PR STE25 Date last DMV review x o o o STE26 Date next DMV review PX Primary key value PRA X Element name changed from PRA Primary Key Value to Primary Key Value PRA PRA 8 Date entered practice____ X__ ___ ____ 5 3 9 Chapter 9 responses by Wayne Tracy 5 3 9 1 What was the driving force behind the creation of chapter 9 The Medical Records Information Management technical committee was formed to provide input and content to the HL7 standard that would support information exchange between systems supporting the medical records department and other systems within the health care enterprise These systems could include functionality delivered within more general purpose systems or stand alone departmental systems 5 3 9 2 What functionality does it offer The chapter exists for the first time within Version 2 3 The scope of the content includes messages concerning the distribution of the content and status of transcribed documents that are treated as content of the medical record and are thus limited to documents about a single patient typically dictated by a physician or allied health professional In the typical setting a number of documents are generated in this fashion including Health Level Seven Implementation Support Guide Page 5 31 for HL7 Standa
257. ablishing a channel signaling path between two or more stations nor does it provide a session interface It does prescribe control procedures used to send and receive data once a channel has been established C 3 1 2 Requirements and Assumptions 1 The protocol must support point to point connection with guaranteed delivery It does not require that the message be processed before it is acknowledged 2 Simplicity of implementation has priority over throughput 3 The protocol software need not accept another transmission request from a higher level while it is completing a previous transmission request 4 Only one physical line is required to accommodate the request and application level reply for a given remote operation 5 The data link protocol must allow different types of remote operations to be sent over a single physical line Data link acknowledgment of a message must not wait for the application level reply This would hang the link and prevent all types of messages from being delivered ACKs must be sent independent of application replies 6 Data transmission may be initiated by either side although not simultaneously 7 One side may use a driver that recognizes only a single termination character 8 A system may lack flow control XON XOFF capabilities 9 Blocking must be done to accommodate limitations of some systems 10 Block transmissions must be synchronous and duplicates recognized 11 The receiver must b
258. ace and Introduction The LOINC databases provide sets of universal names and ID codes for identifying laboratory and clinical test results The purpose is to facilitate the exchange and pooling of results such as blood hemoglobin serum potassium or vital signs for clinical care outcomes management and research Currently many laboratories are using ASTM 1238 or its sister standard HL7 to send laboratory results electronically from producer laboratories to clinical care systems in hospitals Most laboratories identify tests in these messages by means of their internal and idiosyncratic code values So the receiving medical informatics systems cannot fully understand the results they receive unless they either adopt the producer s laboratory codes which is impossible if they receive results from multiple source laboratories e g the hospital lab the local commercial lab and a nursing home lab or invest in work to map each laboratory s code system to their internal code system If medical information producers who wish to communicate with each other used the LOINC codes to identify their results in data transmissions this problem would disappear The receiving system with LOINC codes in its master vocabulary file would be able to understand and properly file HL7 results messages that identify clinical observations via LOINC codes Similarly government agencies would be able to pool results within limits for tests from many sites if the
259. ach subsection of questions is prefaced with the St Anybodys Medical Center definition of the feature function The AIE vendor must address each subsection s questions in their proposed solution If specific features or functionality are unavailable the AIE vendor must identify these as unavailable and propose alternative solutions that meet St Anybodys Medical Center s integration requirements If a feature is available in a future release please note the anticipated release date Again the questions must be printed along with the answer and identify in what module your system provides each of the features Questions are presented in the following sequence of subsections A System Overview B Transaction Data Translation Splitting and Combining C Transaction Routing D Application Interface Engine Development and Maintenance Tools E Product Architecture F Customer User Interface Front End G Standard Interfaces H Data repository I Administration F 1 7 1 System Overview Based on your knowledge of the St Anybodys Medical Center environment please provide an overview description of the system interface solution you are proposing Include a schematic and or a conceptual overview diagram of the system Health Level Seven Implementation Support Guide Page F 21 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 1 F 1 7 2 9 10 Page F 22 System
260. ackup or restore given files however because of the nature and dependence of other systems on the AIE this must either be eliminated or be made very short Page F 36 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 1 Describe the attributes you deem important for backup restore features when implementing the AIE product 2 How are backup restore functions incorporated into your system 3 Does backup require system downtime 4 How are backups tracked 5 Can the recommended platform perform unattended backup with the product active and still maintain data integrity If so how 6 What medium is recommended for backup 7 What media options exist for backup 8 Describe in detail the process for recovery of production from backup media 9 Describe in detail transaction journaling 10 Describe in detail recovery procedures using backup and journal files F 1 8 8 Disaster Recovery St Anybody s Medical Center requires a disaster recovery plan to be incorporated at all levels within the institution This is even more critical at St Anybody s Medical Center than at most corporations due to the business St Anybody s Medical Center is in Our health care staff and patients rely on St Anybody s Medical Center s information systems to provide timely and accurate information for patient care In the event of a disast
261. act Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert Notes and Comments Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page A 73 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 9 2 102 Request Receipt of Patient Selection Display List RQI RPL A 4 9 2 1 RO Originator A or B Message Header Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert Notes and Comments A 4 9 2 2 RPL Originator A or B Message Header Message Acknowledgment Provider Data Contact Data Notes and Comments Display Data Continuation Pointer Page A 74 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 O 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 9 3 103 Request Receipt of Patient Selection List RQI RPR A 4 9 3 1 RO Originator A or B Message Header Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert Notes and Comments A 4 9 3
262. acy Treatment Route Detail Problem Observation Result Clinical Study Registration Clinical Study Phase Page A 58 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 5 17 F09 Summary Product Experience Report SUR Originator A or B Message Header Facility Product Summary Header Product Detail Country Product Summary Header Facility Product Detail Country Notes for PCR Encapsulated Data A 4 6 Master File Maintenance A 4 6 1 MEN Master Files Notification MAD MDL MUP MDC MAC REP WPD Originator A or B Message Header Master File Identification Master File Entry A 4 6 2 MFK Master File Acknowledgment Originator A or B Message Header Acknowledgment Error Master File Identification Master File Acknowledgment A 4 6 3 MFD Master File Delayed ACK MFA Originator A or B Message Header Master File Identification Master File Acknowledgment Health Level Seven Implementation Support Guide Page A 59 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 6 4 MSA Message Acknowledgment Originator A or B Message Header Acknowledgment A 4 6 5 MFQ Master Files Query QRY Originator A or B Message Header Query Definition Query Filter Continuation A 4 6 6 MFR Master
263. age method X __ Added table 0292 RXD 2 Dispense givecode XP RXD 7 Prescription number X Data type changed from NM to ST EHE e LU Lee RXD 9 Dispense notes X Data type changed from CE to ST M orem T AA RXD I0 Dispensing provider IX Data type changed from CN to XCN RXD 13 Dispensetolocation IX Lengthchangedfrom 1210200 RXD 16 Actual strength x II RXD 17 Actual strength unit x II RXD 18 Substance lot number EE SA RXD 19 Substance expiration date X S O RXD 20 Substance manufacturer X date RXD 21 Indication X RXD 22 Dispense package size X RXD 23 Dispense package size X AEN uns EE NE E RXD 24 Dispense package method X RXG 4 Givecoe X Addedtable0292 RXG 9 Administration notes IX OptionalitychangedfromCtoO RXG 10 Substitution aam X Lengthchangedfrom20to 1 RXG 11 Dispense to location Length changed from12 to 200 data type changed from ID to CM RXG 13 Pharmacy treatment Element name changed from Pharmacy supplier special administration instructions 1 Special Administration Instructions to RXG 17 i Pharmacy Treatment Supplier Special Administration Instructions RXG 18 RXG 19 Substance lot number RXG 20 Substance expiration date RXG 21 Substance manufacturer name RXA 5 Administered code RXA 11 Administered at location Length changed from 12 to 200 data p QU AO a
264. ake the chapters more complete and easier to read What does version 2 2 NOT address at this time What known needs will NOT be covered and will they be in future releases such as 2 3 or 3 0 Version 2 2 does not address some of the event triggering order result status synchronization and order occurrence instances issues that have been brought up It is my expectation that these will not be addressed until version 3 0 since these issues touch on the structure of current HL7 order result messages and segments Version 2 3 will provide extensions to Observation Master File segments Pharmacy segments and various other segments New messages will be introduced for Clinical Trial communication What key criteria should be used in determining if members should upgrade to 2 2 or stay with 2 1 What key functional issues would drive this migrations Some basic criteria are obvious If one wants to support any of the new segments it is best to upgrade The question is much more difficult for other areas If someone has Z segments to address data elements that are now in the standard and that s all you need why upgrade I cannot define any criteria other than market pressure from vendors who did implement 2 2 as a driving force to upgrade If an interface works and provides the features you want why mess with it If known when is version 2 2 likely to be available from vendors When should members look for these features in vendor interfaces Will v
265. al Center Each question is prefaced with the St Anybodys Medical Center definition of the specification The AIE vendor must address each subsection s questions in their proposed solution if specific features or functionality are unavailable the AIE vendor must identify these as unavailable and propose alternative solutions that meet St Anybodys Medical Center s integration requirements If a feature is available in a future release please note the anticipated release date Again the questions must be printed along with the answer and identify in what module your system provides each of the features Questions are presented in the following sequence of subsections A B ES T Q Fa F 1 8 1 Processor Input Output Network and Communication Protocols Operating System Performance Integrity Fault Tolerance Backup Restore Journaling System Recovery Disaster Recovery Environment Cable Plant Processor In order for the AIE product to perform the integration processing at St Anybodys Medical Center it must be coupled with a processor that is capable of delivering the required services in a time efficient manner with a high degree of integrity 1 Describe the attributes you deem important for a processor when implementing the AIE product 2 Isthe processor designed to accommodate a high volume transaction processing environment If so what are the specifications on the recommended processor 3 Is the processor R
266. al Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 reporting a number of atomic variables which together fully describe the observation For example we have the following atomic observations for circumference measures These variables let us deal with all of the odd ball kinds of circumferences for which we have not yet defined a pre coordinated term CIRCUMFERENCE LEN PT BODYPART XXX QN The actual measure of some circumference CIRCUMFERENCE SITE ANAT PT QL Identifies the body part measured specifies the system CIRCUMFERENCE METHOD TYPE PT BODY PART XXX Identifies the measuring technique used to obtain the circumference answers tape measure derived imaging We also provide pre coordinated terms that combine some of the atomic variables into one LOINC code For example we have 8279 2 CIRCUMFERENCE AT NIPPLE LINE LEN PT CHEST QN and 8290 2 CIRCUMFERENCE INSPIRATION LEN PT CHEST QN which provide more specificity and permit the key components of the measure to be expressed as one variable as is the convention in many clinical systems We call these pre coordinated codes molecular variables Within the LOINC database molecular variables will vary with respect to how many atomic components are aggregated As is true in some laboratory areas methods often not included as part of a name nor are they always reported The commonest molecular aggregation is between fun
267. al transactions to send this How Do I Send Pharmacy Orders like BID Every M W amp F It seems that version 2 2 does not provide a means for sending orders that have two patterns of repetition for an indefinite duration except to create a stream of serial orders and extend them from time to time Some sites have reported using the following approach to this on the List Server The are adding a third subcomponent to the Interval component of the Quantity Timing field in the RXE segment This subcomponent might be called Schedule Interval It is drawn from the same set of values as the Repeat Pattern subcomponent of the Interval component Some examples of reasonable value are e QD for daily type orders probably 99 of orders meet this type Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved G 7 5 G 7 6 G 8 Appendix G Frequently Asked Questions QOD for every other day QJ135 for every Monday Wednesday amp Friday So currently an order for BID at 8 00 AM and 8 00 PM every Tuesday Thursday amp Saturday would contain the following interval component BID amp 0800 2000 amp QJ246 Note that the placing the value QD in this new Schedule Interval subcomponent is redundant Receiving systems should treat BID with the other subcomponents null as the same as BID amp amp QD for compatibility with the standard Tim Tracy How Would
268. allenge or dose not specified random 1 minute post challenge 6 hours post challenge 2 minutes post challenge 7 hours post challenge 3 minutes post challenge 8 hours post challenge 4 minutes post challenge 8 hours alligned on nursing shifts 5 minutes post challenge 12 hours post challenge 6 minutes post challenge 24 hours post challenge 7 minutes post challenge 2 days 8 minutes post challenge 3 days 9 minutes post challenge 4 days 10 minutes post challenge 5 days 15 minutes post challenge 6 days 20 minutes post challenge 7 days 25 minutes post challenge 1 week 30 minutes post challenge 10 days 1 hour post challenge 2 weeks 2 hours post challenge 3 weeks 2 1 2 hours post challenge 4 weeks 3 hours post challenge 1 month 30 days post challenge 4 hours post challenge 2 months 60 days post challenge 5 hours post challenge 3 months 90 days post challenge 2 2 2 Reporting the baseline measure as part of a challenge test We define one baseline term for different challenge batteries when the challenge is given by the same dose and route So we define one baseline test for the 100 gm oral glucose tolerance test regardless of the number of separate measurements defined in the battery For example the baseline serum glucose for 100 g oral glucose by mouth would be GLUCOSE BS 100 G GLUCOSE PO A laboratory could use this same test identifier to identify the baseline result of a 2 h glucose tolerance and a 3 h glucose tolera
269. alling an interface engine develop comprehensive procedures for downtime and recovery keeping in mind that interface engine downtime will mean that all of your interfaces passing through the engine will also be down Analyze potential points of failure and consider keeping spare parts to facilitate quick recovery Develop Failure Mode Response Approach Review the ability of each system to detect correct errors and report those errors to the remote system Since the set of error codes in the current version of HL7 is user defined a set of error codes should be agreed upon to represent certain failure conditions The failure condition that is represented by each code must be understood and the handling of each error condition must be specified Develop Migration Approach Define overall approach for migration of the developed interfaces to production Include separate communications mechanisms if needed parallel testing and acceptance criteria Develop User Access Security Approach Define overall approach for user access to and the security of interfaced systems Include single vs multiple point of entry and number of log ins and passwords Obtain User Review And Acceptance Document and present for approval the entire functional design documentation including applied HL7 specifications new modified manual procedures and any vendor code modifications Health Level Seven Implementation Support Guide Page 3 3 for HL7 Standard Version
270. andard Version 2 3 1998 All rights reserved Table of Contents HL7 Implementation Support Guide B 1 15 CMO Clinical Study Master 45 5 sees B 7 B 1 16 CMI Clinical Study Phase Master sss sese B 8 B 1 17 CM2 Clinical Study Schedule Masters essen B 8 B 1 18 CSR Clinical Study Registration NEE B 8 B 1 19 CSS Clinical Study Data Schedule E B 9 B 120 CSP Clinical Study Phase eet reto rne RES INI d e dE de EN Edel B 9 B 1 21 CTI Clinical Trial Identification uode seien d eet axe teda deed Ee pota eodera B 9 IA PD tact DA E sa eut neues B 9 B 1 23 DB1 Disability Information sss sees sees eee eee B 10 B 1 24 DGI Diagnosis reg EE B 10 B 1 25 DRG Diagnosis Related OTOUD eoe deen B 11 B26 DSC Contimuatlon Pointer T B 11 Bl DSP Display R TT B 11 B 1 28 EQL Embedded Query Language B 12 SEENEN B 12 BT SOUR Roe T B 12 B 1 31 EVN Event Type T B 12 B 1 32 PAC Facility lid B 13 B133 FHS File EE E B 13 Baloo TL Financial Re EE B 14 AGIS S FISA PMS EE B 15 B 1 36 GT1 Guarantor TTT B 15 BIST e BEEN B 17 B 1 38 IN2 Insurance Additional Intormaton sese sss sese B 19 B 1 39 IN3 Insurance Certification Info B 21 B 1 40 LCC Location Charge e EE B 22 B 131 LCH Location CARACAS esos FU NEA RE E B 22 B42 DP Location Department one nter aieo adeo EE B 23 B 1 43 LOC Location Identilca Oasis deefe RRE deene B 23 B 1 44 LRL Location Relationship sss sese B 24 B 1 45 MFA Master File Acknowledgmen
271. andle any person associated with the patient e Anew UB2 segment was added in the finance chapter to handle UB92 fields that were never accommodated in the 2 1 version e In general the specification was cleaned up descriptions expanded and data made more consistent As a result of the changes it should be easier to understand and implement the standard Also functions and data not accommodated in the past are now provided eliminating the need to put these in Z segments 4 2 1 2 What does version 2 2 not address at this time Will they be covered in 2 3 or 3 0 Much of the emphasis and discussion regarding ADT concerns the fact that ADT requirements change significantly as health care moves out of the hospital and into an enterprise setting In addition much discussion centers around persons that may or may not be patients at some time but need to be accommodated These requirements are not currently addressed in the standard Version 2 3 will focus on these requirements while hoping to retain backward compatibility Version 3 0 will allow us the opportunity to redefine the transaction sets correctly according to a revised data mode Health Level Seven Implementation Support Guide Page 4 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 4 HL7 Version 2 2 Overview 4 2 1 3 4 2 1 4 4 2 2 4 2 2 1 4 2 2 2 4 2 2 3 4 2 2 4 Page 4 2 What key criteria should be used in deter
272. ange MEDIX 3 What is the relationship between the HL7 Standard and various proprietary health care protocols in use today 1 5 5 1 Lower Layer Protocols The HL7 Encoding Rules are substantially different from the ASN 1 Basic Encoding Rules BER documented in CCITT X 409 and X 209 and ISO 8825 or those employed in LU6 2 or RPC This is because 1 By definition the HL7 encoding rules will be applied where the environment does not include software to do encoding Without such software the burden on applications programmers to develop messaging software that conforms to those encoding rules is onerous 2 The encoding rules of these protocols depend on the assumption that lower level protocols provide transparency i e all character codes can be transmitted without being changed by and of the lower levels This assumption is often not met in the communications environments that must serve HL7 for the interim The techniques that might be used to implement transparency in the Lower Level Protocol are difficult to implement in some present day applications environments The notation chosen to document the message formats in the HL7 Standard is not the Abstract Syntax Notation ASN 1 Basic Encoding Rules BER defined by ISO Contrary to other high level communications environments there is no notion of association separate from the sending of the message from client to server and the response This seems appropriate to the clien
273. ange for any necessary outside expertise 2 2 1 3 Establish Advisory Committee Establish a Management Advisory Committee to oversee and guide the project Verify that the budgetary estimates have been incorporated into any necessary capital operating budget plans 2 2 2 Work Plan 2 2 2 1 Develop Project Plan Develop a detailed work program for the planning project which identifies all of the necessary work steps responsibilities deliverables time frames and budgets 2 2 2 2 Assign Resource Requirement Identify the internal personnel for the project and identify and arrange for any necessary outside expertise Page 2 2 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 2 Planning Methodology 2 2 2 3 Define Status Reporting Requirements Define the method schedule and distribution list for project status reports and updates Establish variance limits for immediate escalation 2 2 2 4 Prototype Demonstration Conduct demonstrations e g development of a prototype or visits to HL7 sites as necessary in order to demonstrate the value and functionality of an HL7 environment 2 3 BUSINESS STRATEGY PERFORMANCE MEASURES The purpose of this section is to ensure that overall business goals and objectives of the health care institution have been considered in conjunction with technical planning for an HL7 environment These activities are also int
274. ansient and permanent In the case of a transient virtual circuit an initiating module calls an accepting module the modules then perform one or more message transactions and the modules disconnect In the case of a permanent virtual circuit the initiating module has the responsibility of always maintaining a virtual circuit with another location whether or not it currently has messages to send This record oriented results links between the initiating and accepting modules will be permanent virtual circuits C 6 1 Initiating Module The initiating module needs at least the following information to manage a series of message transactions network address number of connection retries pause time between connect attempts receive timeout send timeout send retries if NAK is received For best performance these parameters may vary according to message type and receiving application The information can be kept in text form in a Network Parameter Table NPT which is read by an application at run time The NPT is keyed by the message type and receiving application By reading this information at run time the system can be tuned or reconfigured without coding changes The following pseudo code shows the procedure that the initiating task uses to perform message transactions over a transient virtual circuit The task calls a destination until successful or until a maximum number of attempts is reached If the call is successful it performs the
275. anties associated with the implementation of Category II and III interfaces 2 Maintenance and Support a St Anybody s Medical Center requires support and maintenance 24 hours a day seven days a week Provide the annual cost of 24x7 maintenance and support for both software and hardware If support is not included in the maintenance plan indicate the additional cost for support Note any increases in maintenance and support cost due to the addition of software modules and hardware components for the Category II and III interfaces Describe any assumptions and or additional information that will help to clarify the proposed pricing MAINTENANCE SUPPORT COMPONENT CATEGORY I CATEGORY II CATEGORY Ill CATEGORY CATEGORY II CATEGORY III b Whatis the maximum that cost of the support and maintenance contract s can increase each year Health Level Seven Implementation Support Guide Page F 55 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 3 F 1 9 9 Upgrades and System Enhancements Are system patches included in maintenance If not are they considered an upgrade or system enhancement What is your definition of a system upgrade How often are they available Is there a guideline for estimating the cost for system upgrades What is it What is your definition of a system enhancement How often are they available Is there a guideline for estimating the cost for syst
276. appa Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Requisition Detail Requisition Detail 1 Notes and Comments A 4 3 10 001 Pharmacy Treatment Order ORM Originator A or B Message Header Notes and Comments Patient Identification Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Insurance Information Insurance Information Add l Info Insurance Information Cert Guarantor Information Allergy Information Common Order Pharmacy Treatment Order Notes and Comments Pharmacy Treatment Route Pharmacy Treatment Component Notes and Comments Results Notes and Comments Billing Page A 38 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 3 11 O02 Message for Pharmacy Treatment ORR Originator A or B Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Pharmacy Treatment Order Notes and Comments Pharmacy Treatment Route Pharmacy Treatment Component Notes and Comments Health Level Seven Implementation Support Guide Page A 39 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 3 12 001 Pharmacy Treatment Encoded Order R
277. application data element A table is not necessarily created for each data element PROPOSED Indicates both the spelled out name and abbreviation for the name of the segment SEGMENT NAME which you are requesting NOTES Indicates any comments that may be helpful in the understanding of a specific field or the segment Health Level Seven Implementation Support Guide Page A 100 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 SEGMENT CHECKLIST The segment checklist provides detailed information about the fields contained in each segment This checklist can be used to identify optional fields that will be used in each message the characteristics of each field used and the name of the variable assigned to the corresponding data in each application A copy of each segment checklist should be completed for each segment identified in the message checklist section The segment checklist includes the following definitions Segment Name Item Number Name Required Optional Indicator For your convenience HL7 required fields are marked with an R A blank line is provided to indicate optional fields which will be included in the segment Use the following to indicate optionality R Required C Conditional O Optional Z Supported with Custom Code N Not Supported e Data Type e Field Length Maximum Length Used Maximum Length Specified by Stand
278. arantor financial class X GTI 55 l Guarantorrace X O Element name changed from Set ID insurance to Set ID INI IN1 1 Set ID INI WEE IN1 2 Insurance plan ID X Length changed from 8 to 60 data type changed from ID to CE IN1 3 Insurance company ID X Length changed from 6 to 59 data type changed from ST to CX repetition Health Level Seven Implementation Support Guide Page 5 23 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Segment Seq Lo changed to Y Insurance company name X Length changed from 45 to 130 data type changed from ST to XON repetition changed to Y BN ANN IT repetition changed to Y Insurance co contact X Data type changed from PN to XPN person repetition changed to Y element name changed from Insurance Co Contact Pers to Insurance Co Contact Person Insurance co phone X Data Type changed from TN to XTN Number repetition changed from Y 3 to Y Insured s group emp ID X Length changed from 35 to 130 data type changed from ST to XON repetition changed to Y Insured s group emp name X Data type changed from ST to CX repetition changed to Y Insured s group emp name X Length changed from 45 to 130 data type changed from ST to XON repetition changed to Y IN1 15 Plan type X Length changed from 2 to 3 data type changed from ID to IS IN1 16 Name of insured X Data type changed from PN to XPN repetition changed
279. ard e Repetitions If repetitions are allowed a line is provided to indicate the number of repetitions used in the interface e Sender System s Variable Name e Receiver System s Variable Name e Notes If the field uses a table the table number is provided in parentheses Health Level Seven Implementation Support Guide Page B 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists A blank field line is included at the bottom of each segment to define any site specific Z fields being used B 1 1 Accident Information 1 00527 Accident Date Time TS Ge TP 2 00528 AccidentCode 0050 EN ae 3 00529 AccidentLocation CT ST 5 TI 4 00812 Auto AccidentState CE 60 ss 5 00813 Accident Job Related Indicator ID o USR 6 00814 Accident Death Indicator wD 0136 B 1 2 ADD Addendum 1 0066 Addendum Cont Pomer C Sr ew l1 Ll B 1 3 AIG Appointment Information 1 00896 SetID AG JE SI 0 94 e 2 00763 Segment ActionCode JL ID 02006 3 00897 Reouc D LE CE Q0 9 S 4 0088 ReouceTpe ARA CE ew III J 5 0089 ResuceGoup CE ew 4 J J 6 00900_ R
280. ard edu Clem MacDonald Clem Gregen rg iupui edu John May jmm majortom sunquest com Mark Shafarman mshafarm O oacis com Tim Tracy tmedtracy O aol com Frequently a FAQ article is an amalgam of many individual postings to a thread Not all contributors may be cited In every case the author of the FAQ has edited the original list server thread and may have added or changed ideas G 3 HOW CANI CONTRIBUTE TO THE FAQ Send a question and answer directly to wes Grishel com Include links to relevant information that is available on the Web We would prefer to get the contribution as a nonencoded Microsoft Word document Health Level Seven Implementation Support Guide Page G 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions but we will also accept the text directly in the mail message or in a WordPerfect document Keep the format simple You are answering a question not writing a book or creating a brochure Submit diagrams in any format available to Windows users When you send a diagram in WMF format you will give us good flexibility to adjust its size for most effective display The author uses Visio to prepare his diagrams Try to keep the width of the diagram down to less than 5 5 inches If you are sending the diagram as a bitmap remember that for many users the usable portion of the screen is about 600 pixels wide by 400 pixels high Any larger will no
281. are modules packages that are required in addition to those proposed for Category I interfaces in order to implement Category II interfaces Software that has been listed as required for Category I interfaces but will require additional licenses for Category II interfaces should be included with the number and purchase price of additional licenses required VENDOR REL ADD L PACKAGE MODULE THIRD VER DESCRIPTION LICENSING LICENSES LICENSE NOTE PARTY REQUIRED NO TOTAL PROPOSED COST OF ADDITIONAL SOFTWARE FOR CATEGORY II INTERFACES Notes Page F 42 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates Interface Category III Include all software modules packages that are required in addition to those proposed for Category I an II interfaces in order to implement Category III interfaces Software that has been listed as required for Categories I and II but will require additional licenses for Category III should be included with the number and purchase price of additional licenses required VENDOR REL ADDL PACKAGE MODULE THIRD VER DESCRIPTION LICENSING LICENSES LICENSE NOTE PARTY REQUIRED NO TOTAL PROPOSED COST OF ADDITIONAL SOFTWARE FOR CATEGORY II INTERFACES Notes Health Level Seven Implementation Support Guide Page F 43 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 A
282. arge ADT ACK Swap patients ADT ACK Merge patient information QRY ADR Patient query ADT ACK Bed status update ADT ACK Patient goes on a leave of absence ADT ACK Patient returns from a leave of absence ADT ACK Delete a patient record ADT ACK Link patient information ADT ACK Cancel pending discharge ADT ACK Cancel pending transfer ADT ACK Cancel pending admit ADT ACK Add person information ADT ACK Delete person information ADT ACK Merge person information ADT ACK Update person information ADT ACK Cancel patient arriving tracking ADT ACK Cancel patient departing tracking ADT ACK Merge patient information patient ID only ADT ACK Merge patient information account number only ADT ACK Merge patient information patient ID and account number ADT ACK Unlink patient information ADT ACK Cancel pre admit Health Level Seven Implementation Support Guide Page B 61 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists ADT ACK Merge person external ID ADT ACK Merge patient internal ID ADT ACK Merge account patient account number ADT ACK Merge visit visit number oo Move patient information internal ADT ACK Move account information patient account number ADT ACK Move visit information visit number ADT ACK Change external ID ADT ACK Change internal ID ADT ACK
283. ase should be set to null in the latter case it should retain its prior value The encoding rules specify that if a receiving application cannot deal with a data field not being present it should treat the data field as present but null The encoding rules specify that a receiving application should ignore fields that are present in the message but were not expected rather than treat such a circumstance as an error Local Variations The HL7 Standard is intended to standardize data interchanges not the underlying applications systems This means that there will be a wide variety in the manner in which the Standard is applied in different institutions The requirement to support diversity within the Standard is addressed in these ways 4 The only data fields that are required in the abstract messages are those necessary to support the logic of the relationships among the messages or their basic purpose Many other fields are specified but made optional 5 There are provisions within the specifications to add messages or portions of messages that are local to an institution The conventions used for this are intended to prevent conflict with future versions of the specification Evolutionary Changes to the Standards All standards must evolve as the applications they support change and as a result of experience using them In recognition of this the Standard includes a protocol version ID in all messages New transactions or data element
284. ass Scheduling Chapter Only value pair parameter class IS parameter value IS Timing quantity For timing quantity specifications for orders see Chapter 4 Section 4 4 quantity CQ interval duration start date time TS end date time TS gt priority ID condition ST gt text TX conjunction ID gt order sequencing gt Note The HL7 Standard allows for different data formats for each of these data types This section provides a place to document general attributes of each data type format A 3 3 Presentation ASCH EBCDIC A 4 MESSAGE CHECKLIST The message checklist lists each HL7 message together with its required and optional message segments Select the HL7 messages for the interface from this checklist Decide which of the optional segments will be used Make a copy of the segment checklist for each of the required and chosen segments and decide which fields to use in the interface Each message listed is presented by HL7 specification chapter In most cases the message name is provided with the trigger event name in parentheses A blank line is provided after each message name to be checked off if that message will be included in the interface Under each message is a message selection section This section lists all the required and optional segments in the message Under the OPT heading the following are valid values R Requir
285. ass through the LLP For the sake of efficiency the protocol does not add a large amount of overhead which duplicates functions of the lower levels of the network It is assumed that 1 The RS 232 interface distance between the computer and communication server is short 10 And so will not experience a significant number of errors 2 The computer may place line length restrictions on data coming in over the serial port Health Level Seven Implementation Support Guide Page C 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols The computer may not deliver serial data to the application until it has received a carriage return The computer and the communication server have adopted some common flow control protocol over the RS 232 line such as XON XOFF or modem control signals The application may require transient use of the LAN virtual circuit capability In this mode a circuit will be created for each pair of messages that is exchanged and then released This mode of operation is an option that will not always be used C 2 1 2 Notation Conventions 1 2 Single ASCII characters are enclosed in single quotes Special characters or non printing ASCII characters are enclosed in angle brackets lt gt Special characters are the LLP Start Block and End Block characters Non printing ASCII characters may be written as their abbreviation e g ESC for the Escape chara
286. ata type changed from ID to IS optionality changed from O to B PV1 41 Data type changed from ID to IS E PV1 42 Pending location Length changed from 12 to 80 data type changed from CM to PL Length changed from 12 to 80 data type changed from CM to PL PV1 43 Prior temporary location PV1 50 Alternate visit ID PV1 51 Visit indicator Data type changed from CM to CX Health Level Seven Implementation Support Guide Page 5 13 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Segment Seq PV1 52 Other health care provider X Prior pending location X Length changed from 12 to 80 data type changed from CM to PL optionality changed from O to C PV2 7 Visit user code Dain type changed from ID to IS Expected admit date time X Length changed from 8 to 26 data type changed from DT to TS element name changed from Expected Admit Date to Expected Admit Date Tim Expected discharge X Length changed from 8 to 26 data type date time changed from DT to TS element name changed from Expected Discharge Date to Expected Discharge Date Time PV2 10 Estimated length of X inpatient stay PV2 11 Actual length of inpatient X stay po PV2 12 Visit description 13 PV2 13 Referral source code H PV2 14 PV2 15 Employment illness related indicator Purge status code Purge status date Special program code Retention indicato
287. ation Define a mechanism for ongoing review and evaluation of the project This may include periodic meetings with staff and end users to discuss changes in operations Health Level Seven Implementation Support Guide Page 3 13 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 4 HL7 Version 2 2 Overview 4 1 INTRODUCTION The purpose of this chapter is to provide information regarding new features and capabilities present in Version 2 2 of the HL7 specification migration considerations and future focus areas The first section contains a question and answer section authored by HL7 technical committee co chairs The second section contains a chapter by chapter description of the differences between the HL7 Version 2 2 Standard and the HL7 Version 2 1 Standard 4 2 VERSION 2 2 QUESTIONS AND ANSWERS 4 2 4 ADT Finance responses by Robert Evola 4 2 1 1 What was the driving force behind the creation of version 2 2 In comparison with version 2 1 what advantages does it offer The ADT and Finance portions of the specification were incomplete regarding functionality and data Among the more significant changes e The Merge Segment was added to the Transfer events A06 E A07 e Next of Kin Segment was added to the Patient Query A19 event e Additional fields were added to the PID segment to handle newborn baby information for UB92 that were formerly in the PV2 segment e Next of Kin was made more generic to h
288. ations also define the presentation of the information that is to say the strings of text that represent it HL7 refers to these as the encoding rules This represents Level 6 of the OSI conceptual framework Most HL7 implementations use the HL7 encoding rules However there is an out in the current HL7 specifications An implementation the follows the abstract message specifications but uses different encoding rules can claim to be HL7 conformant There have been implementations using ASN 1 and LU6 2 to encode the data fields HL 7 does not specify standards for communicating the character strings from one system to another Several recommended lower layer protocols were published as appendices to HL7 version 2 1 These can be used for implementing HL7 over serial lines and using TCP IP These will be republished essentially unchanged in the Implementation Guide for version 2 2 However implementations using other lower layer protocols may claim HL7 compliance G 9 1 5 What are the Goals of the HL7 Effort HL7 s purpose is to facilitate communication in health care settings The primary goal is to provide standards for the exchange of data among health care computer applications that eliminate or substantially reduce the custom interface programming and program maintenance that may otherwise be required This primary goal can be delineated as a set of objectives Page G 14 Health Level Seven Implementation Support Guide Final Version 6
289. ause a temporary text delay after receipt of the previous acknowledgment if the sending station is not capable of transmitting the text of the next transmission block before the predetermined time out period The reasons for such a delay might be the unavailability of buffer space or that the speed of the input device is considerably slower than the transmission speed and a full block has not yet been read from the media Block abort is accomplished by the sending station s ending the block at any time with the ENQ The sending station then halts transmission and waits for a reply The receiving station detects that the block was ended with ENQ rather than with a normal ending character ETB or ETX discards that portion of the block that had been received and sends a NAK response to the sending station and remains in the receive condition Following receipt of the NAK response the sending station will normally reinitiate the transmission with the same or a new block In the case of a NAK response that is not received the sending station will time out expiration of Timer A see section on Timers The sending station reinitiates transmission with the same block or it may choose to initiate an appropriate termination or recovery procedure The specific choice of operation will generally be a function of the system discipline being employed C 3 4 2 Sending Station Abort Description Application Procedures Page C 18 Final Version 6
290. ay update message OSQ OSR Query for order status ORU ACK Unsolicited transmission of an observation message QRY Query for results of observation QRY DSR Display oriented results query unsol update for backward compatibility only ORF Response to query transmission of requested observation QRY DSR query for display results UDM unsolicited update display results RAR Pharmacy administration information query response RDR Pharmacy dispense information query response RER Pharmacy encoded order information query response RGR Pharmacy dose information query response ROR Pharmacy prescription order query response SRM SRR Request new appointment booking SRM SRR Request appointment rescheduling SRM SRR Request appointment modification SRM SRR Request appointment cancellation Page B 66 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists SRM SRR Request appointment discontinuation SRM SRR Request appointment deletion SRM SRR Request addition of service resource on appointment SRM SRR Request modification of service resource on appointment SRM SRR Request cancellation of service resource on appointment SRM SRR Request discontinuation of service resource on appointment SRM SRR Request deletion of Service resource on appointment SIU ACK Notification of new appoint
291. bugging and testing In addition computer based training and help facilities are desirable in the proposed solution The underlying programming language should correspond to a common development language in general use today e g C or C The intent of the development tools is to give interface developers easy to use methods and tools for designing programming editing and testing interface programs Health Level Seven Implementation Support Guide Page F 25 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates Maintenance of the AIE including starting and stopping interfaces monitoring sessions and connection status etc should be uncomplicated yet secure In St Anybodys Medical Center s environment remote maintenance capability is desirable Describe in detail how and in what module your system provides the following capabilities facilities and tools 1 Programming Aids a Tables and menus to configure messages that the AIE will receive and forward to other systems b Sections for help and programmer training c Templates for pre existing standards e g HL7 ANSI X 12 etc d A GUI for system interface developers to access AIE resources as well as execute real time tests 2 Testing and Debugging Aids Debugging aids that incorporate facilities for a Sending dummy transactions with and without requiring applications b Conducting stress tests c M
292. c isothermal Ligase Chain Reaction Also probe amplification category method Abbott Laboratories thermal cycler Q Beta Replicase or probe amplification category Applies to DNA RNA method Gene Track Systems isothermal Table 14B Examples of specific methods that would be defined in LOINC as signal amplification methods PROBE AMP SIG HPA Hybridization Protection Assay Applies to Branched Chain DNA Applies to DNA RNA Chiron Corp isothermal Hybrid Capture Applies to 2 7 Immune fluorescent IF We do not distinguish among many variants of immune fluorescent tests DFA ACIF are all classed as immune fluorescent IF 2 7 3 Immune Tissue Stain Cyto IE We classify Peoxidase and all other immune stains of tissue under the method category immune stains 2 7 4 Enzyme Immune Assay We classify many variants of enzymes under EIA including ELISA CEIA etc 2 7 5 Coagulation We distinguish among three kinds of coagulation method Coagulation which measures the coagulation activity immune which measures the coagulation constituant and enzymatic which measures the coagulaiton factor via enzyme rate methods 2 7 6 Stains We provided very detailed distinctions among various tissue stains 2 7 7 Clinical measures We distinguish reported from estimated and measured values so reported body weight would be the stated weight from a patient or surrogate Estimated would be the body weight estimated by an observer and
293. ce Once the health care organization s data flow needs are established the appropriate HL7 transactions can be selected from the checklist Each transaction can be reviewed to determine which of the optional fields will be included in the message the required fields which must be included in the message are already marked with an R Descriptive information about the field e g maximum character length repeating non repeating field type of time date notation etc can be determined and documented on the checklist The checklist also provides space to document the variable names assigned to corresponding fields on each system A checklist and cover sheet should be completed for each interface being designed including interfaces that broadcast to more than one system In the case of broadcast interfaces every effort should be made to agree on a single format for the message from the sender Certain messages may include different segments and fields depending on the trigger event e g Pharmacy Orders and Lab Orders both use the same message Complete copies of the message selection definition documentation for each trigger event In the interest of conserving paper only one copy of each segment definition is included in the checklist Copy the appropriate segment definitions for each message to be implemented Health Level Seven Implementation Support Guide Page A 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Vers
294. ced by an updated term In those cases Map To contains the LOINC code of the new term that should be used 21 SCOPE Char 254 Not currently used 22 SNOMED CD Char 10 SNOMED Code future versions Not currently used 23 VA CD Char 8 VA Code future versions Not currently used 24 METPATH CD Char 10 Metpath Code Not currently used 25 HCFA CODE Char 12 HCFA code future versions Not currently used 26 CDC CODE Char 6 Code from CDC Complexity file which maps laboratory tests to the instruments used to perform them These codes are at the analyte level not the test instrument level 27 NORM_RANGE Char 30 Normal Range Example answers from real tests 28 EX_US_UNITS Char 30 Example units used in the US 29 IPCC_UNITS Char 30 Example units used by IUPAC IFCC future Page H 42 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Field Name GPI_CD GPI_CD_TOT REFERENCE EXACT_CMP_SY MOLAR_MASS IUPC ANLT CD ANSWERLIST2 LOINC Users Guide April 16 1998 Description GPI Code For drugs this field contains a map to the Medispan GPI codes a hierarchical system of classifying pharmaceutical products GPI Code Total For a few products a simple one to one mapping with a GPI code was not possible In these cases all applicable GPI codes are contained in this field separated by semicolons Contains references to medical literature
295. cellation and or failure to perform Set of acceptance criteria to be used in determining that the system is installed satisfactorily A guarantee for the availability for example minimum downtime Throughput transactions per second 1 A guarantee of throughput 2 Are your throughput objectives with or without mapping Your throughput definition should include the length of the message and some amount of mapping described 3 Provide examples of expected throughput specific to St Anybodys Medical Center 4 Provide benchmarks and substantiate performance 5 Indicate recourse if throughput does not meet the guaranteed performance Identification of modifications necessary to customize your system to meet the requirements of St Anybodys Medical Center Timeframes in which modifications will become available Names and resumes of personnel to be assigned to the installation Training schedule Right for St Anybodys Medical Center to demand component replacement lemon clause Absolute fixed price or not to exceed contracts for hardware software and services Guarantee that software prices and installation fees quoted in this REP will be honored during the duration of the selection process Hardware prices will be valid for a minimum of twelve 12 months Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates o Definition
296. ch each is required With a positive accept acknowledgment the receiving system commits the message to safe storage in a manner that releases the sending system from the need to resend the message After the message has been processed by the receiving system an application acknowledgment may be used to return the resultant status to the sending system This new enhanced mode allows the original 2 1 acknowledgment modes both regular and deferred as options It also allows communicating systems to specify the use of any combination of accept and application acknowledgments on the basis of the following new fields in the MSH segment e Accept acknowledgment type e Application acknowledgment type which are defined by the following table Table 0155 Accept application acknowledgment conditions Always Never Error reject conditions only Successful completion only Note If Accept acknowledgment type and Application acknowledgment type are omitted or are both null the original Acknowledgment Mode rules are used The MSA segment s Acknowledgment code has been adjusted as follows to support the enhanced acknowledgment mode Health Level Seven Implementation Support Guide Page 4 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 4 HL7 Version 2 2 Overview Original mode Application Accept Enhanced mode Application Acknowledgment Accept Original mode Application Error Enhanced mode
297. ch is used the scale will be nominal and the type of property will be presence or identification PRID 3 2 Blood bank Red cell antigens will be named in accordance with the American Association of Blood Banking A AB B naming standards In addition to the antigen or antibody a modifier would be included in the fourth subfield of the first field to indicate whether testing was performed on the patient donor or blood pack Unless explicitly stated testing is assumed to have been on a material collected from a patient Additional information about the person identified in the fourth subpart such as the donor s name or relationship to patient should be placed in other OBX segments or comment segments of the message and would not be part of the test name Examples of blood bank related names ANTIBODIES IDENTIFIED PRID PT SER PATIENT ORD B AB ACNC PT SER DONOR NOM AGGL RBC Each reportable antigen must have its own test so that each element in a full set of binary tests could be reported as negative positive or 0 1 The fully specified names of A AB and O blood types as observations would be as follows Measure of serum antibody against type A blood of donor A AB ACNC PT SER DONOR NOM AGGL RBC Presence of A antigen on donor s red blood cells A AG ACNC PT RBC DONOR NOM AGGL RBC Presence of A antigen on the blood cells in a pack of blood given to the patient A AG ACNC PT RBC BPU NOM AGGL RBC Blood bank reporting illustrates
298. cies e g for specific species of the maple genus Acer the LOINC analyte names would be MAPLE RED Acer rubrum MAPLE SILVER Acer saccharinum MAPLE SUGAR Acer saccharum Whenever available the Latin name will be stored in the RELATED NAMES field 2 1 2 17 Avoid use of the word total in laboratory test names except when denoting the denominator of a fraction Thus itis ALKALINE PHOSPHATASE NOT ALKALINE PHOSPHATASE TOTAL but ALKALINE PHOSPHATASE BONE ALKALINE PHOSPHATASE TOTAL 2 4 3 Punctuation in analyte names A number of analyte names include punctuation characters such as commas for example to identify the position of multiple alkyl groups in a carbon chain We will avoid special characters e g commas dashes and parentheses except where they are included in the name specified by IUPAC the Chemical Abstract Service CAS convention or another international convention So commas will appear in multiple substitutions of alkyl chains per the CAS standard dashes will appear in HLA antigen names and parentheses i e round brackets will appear in the names of red blood cell antigens 2 1 4 Case insensitivity All names are case insensitive We use upper case in our example but senders and receivers could use upper lower or mixed case However the meanings should not be sensitive to case conversions to avoid any possibility of confusion when Health Level Seven Implementation Support Guide Page H 15 for HL7 Standard
299. cle Although the accession number is primarily a creature of the lab there are times when it needs to be communicated It is often sent along with a charge transaction to be printed on the bill as a reference number It is useful when a physician calls to discuss a result These uses are discussed below Before the development of HL7 most lab people thought of the accession number as being the order number In reality they still do For the very occasional test that requires more than one specimen they decide on some arbitrary and not necessarily consistent basis which accession number to store the results under and leave it at that Many or most lab systems recycled their accession numbers so on the rare case where they had to look up an old test they would say give me the report on test 123 that occurred in November of last year Typically these were not stored on line anyway except possibly on an archive tape In some places the accession numbers recycled as frequently as once per week I have seen one lab system implemented where the accession number was X9999 where X was a one letter code to represent the day of the week At one time disk was expensive and this was one justification for recycling accession numbers However there are also human factors justifications Fewer digits can be typed faster with fewer errors Accession numbers are used as a reference in external communications so being able to send them out somehow is valuable
300. common components of narrative reports see HL7 Standard Version 2 3 Figure 7 1 The observation identifier for each such component is obtained by concatenating the observation battery ID the ID in OBR 4 universal service ID of the preceding OBR from any coding system with the appropriate suffix The author presumes that when a report message contains a mixture of text and numeric observations that the numeric observations would be repeated in the text With this usage it is possible to display or print a report by simply copying the contents of the values of the text type values The standard is silent on this point In addition to breaking the report into sections the standard further requires in HL7 Standard Version 2 3 Section 7 3 2 5 KAREN VERIFY SECTION that logically independent observations be broken into separate OBXs So for example an impression section with multiple findings would itself be subdivided into multiple OBXs This approach has a number of benefits By breaking out numeric observations in separately identified OB Xs the information is accessible in a record oriented form Breaking the text into smaller separately identified clumps makes it easier to retrieve only the impressions etc Similarly separating the logical observation permits easier retrieval and also allows the use of related data fields such as abnormal flags With this approach the contents of the observation value field may be very long It may contain
301. communicate in a LAN environment they must establish a virtual circuit The virtual circuit provides reliable sequenced error free two directional full duplex data transmission over the network The circuit is established by one of the entities performing a call operation and the other performing a listen operation The two entities use Network Names to identify one another The call operation is often called an active connection or simply a connection operation Occasionally the listen operation may be called a passive connection Once the calling entity has connected to the listening entity the circuit is established and they may exchange data The preferred method of establishing a circuit is for the initiating system to perform the call operation and for the responding system to perform the listen operation When the data exchange is through either side may perform a disconnect operation to break the circuit Data may or may not be lost between the two systems depending on the type of disconnect performed Some network protocols require both sides to perform a disconnect operation for the circuit to disappear completely It is highly recommended that the system which performs the call operation be the first to perform the disconnect operation Health Level Seven Implementation Support Guide Page C 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 2 3 2 Page C 4
302. components in one system or sample If the ratio refers to components in a single system the ratio of the mass concentrations is also a mass ratio because the denominators cancel out So a mass of serum creatinine to mass of serum urea nitrogen within the same specimen system would be a mass ratio Amount of substance molar amount would give a different ratio SRTO If the measures come from different specimens e g PT patient PT control it is a relative ratio IUPAC describes an entitic quantity This refers to measure per entity by number of entities e g cells receptors molecules Entetic quantities usually have units that include the name of some entity e g red blood cells per 10 RBCs One must be careful about measures of constituants of red blood cells because they can be expressed as an amount per mass of hemoglobin or per red blodd cell The former is a mass content the latter is a mass per entity All clearances have the property of volume rate but Clearance will be included in analyte name to clarify meaning SODIUM RENAL CLEARANCE VRAT2AH UR QN CREATININE RENAL CLEARANCE VRAT 12H UR QN Use PRID presence or identity as the type of property field when a specimen is sent for culture and the result can be the presence of any organism especially as an initial result and later the organism is identified The same rule applies to toxicology screens or other observations that report the identity of one or more c
303. composed of volunteers who give their time on a personal basis or under sponsorship of their employers Membership in the HL7 Working Group has been and continues to be open to anyone wishing to contribute to the development and refinement of Level 7 Interface Standard for network technology in health care Health Level Seven Implementation Support Guide Page G 15 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions G 9 2 2 What is a Technical Committee of the Working Group A Technical Committee often called a chapter committee is the basic specification writing entity in HL7 Its members are charged with developing and balloting proposed chapters in the HL7 specification For example the ADT Finance committee writes chapters 3 ADT and 6 Finance One special Technical Committee which does not write a chapter is the QA Data Modeling Committee This Committee has been primarily involved with developing a data model to represent the data used in HL7 transactions The current technical committees are e ADT Finance Inter Enterprise e Control Query e Implementation e Information Management Medical Records e Order Entry Clinical Results e Patient Care e Quality Assurance and Data Modeling G 9 2 3 What is a Special Interest Group of the Working Group A Special Interest Group is a sanctioned group that meets under the auspices of HL7 but is not authorize
304. concept described in the Silver Book We include most of the relevant IUPAC types of property in Table 7 See Appendix E for detailed examples Analytes reported with masses mgs gms etc in the numerator of the units of measure are associated with one of the properties that begin with the word mass e g mass content mass concentration etc Analytes reported as moles or millequivalents in the numerator of units of measure are associated with properties that begin with the word substance e g substance amount substance concentration Counts are associated with properties that begin with number e g a white blood cell count reported as number of WBCs divided by volume of blood would have a property of Number Concentration Measures of enzymatic activity are all associated with properties beginning with catalytic Each of these four major property categories has five derivatives content concentration concentration ratio fraction and rate Measures of an amount of mass substance amount catalytic activity or number divided by volume are concentrations Measures of the total amount measured per mass of sample are reported as contents mass content substance content etc These have units such as kg gm sample Mass fraction is used when grams of a component measured as a subcomponent of another component e g CKMB TOTAL CK These are almost always reported as percents 46 A mass ratio is the ratio of the mass of two chemical
305. control to customized external routine s based on field values transaction types etc b Resuming processing when control returns 9 Security Facilities that provide for a Isolating development from production areas b Protecting data dictionaries and tables c Migrating developed interfaces into production Health Level Seven Implementation Support Guide Page F 27 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates d Starting up shutting down individual interfaces e Authenticity What method do you recommend for verifying the sender of the message Do you support a digital signature f Do you encrypt decrypt messages g All other intrinsic security functionality 10 Maintenance Facilities that provide for a GUI based monitoring system maintenance b Snapshot screens for quick system status checking reporting c Starting up shutting down individual interfaces d Querying status of individual links e Remote access f All other intrinsic maintenance functionality 11 Communication Client Level Development a What already developed assets are available How much do they cost b How do you inform clients of their availability F 1 7 5 Product Architecture The architecture of the AIE can have significant impact on performance fault tolerance and robustness of the individual interfaces as well as on overall system performance and development cycl
306. cted Sequence Number The two possible conditions are listed as follows C 5 4 1 The Message Sequence Number Sent Equals the Expected Sequence Number The receiving system sends to the sending system an ACK with an AA or AE acknowledgment code and the current Expected Sequence Number MSA 4 It then increments its internal Expected Sequence Number by one and continues to process the message C 5 4 2 The Message Sequence Number Sent does not Equal the Expected Sequence Number The receiving system returns an ACK with AR Application Reject acknowledgment code an error message the Expected Sequence Number MS A 4 and message sequence number MSH 13 The sending system receives the reply message and checks the acknowledgment code In the event of an Application Reject AR the sending system checks the Expected Sequence Number field C 5 4 2 1 The Message Sequence Number Sent Plus One is Equal to the Expected Sequence Number It is assumed the previous acknowledgment was lost and the initial message was a duplicate The sending system sends the next message C 5 4 2 2 The Message Sequence Number Sent is Greater than the Expected Sequence Number The sending system can try to recover by starting again at the lower sequence number or it can freeze the link for operator intervention C 5 4 2 3 Other Errors The sending system freezes the link for operator intervention Health Level Seven Implementation Support Guide Page C 25 for HL7 Sta
307. cter They also may be written as their hex value in the form OxXX where X is a hexadecimal digit For example in Standard ASCII lt ESC gt is lt 0x1B gt C 2 2 Blocks There are two types of blocks data blocks and NAK blocks HL7 messages are transmitted in single data blocks NAK blocks are used to signal transmission errors Both block types have the same format SB tvv CR ddddccccexxx EB CR Blocks consist of the following fields Note that these are LLP fields and are not the same as HL7 message fields SB vv lt CR gt dddd Page C 2 Final Version 6 98 Start Block character 1 byte Configurable on a site specific basis Unless there is a conflict the value should be ASCII VT i e 0x0B This should not be confused with the ASCII characters SOH or STX Block Type 1 byte D data block N NAK block Protocol ID 2 bytes The characters 2 3 for this version Carriage Return 1 byte The ASCII carriage return character i e 0x0D Data variable number of bytes In a data block this is the data content of the block The data can contain any displayable ASCII characters and the carriage return character CR Carriage returns that are not part of the HL7 message may be inserted as described in Carriage Return Stuffing Ina NAK block this field contains a 1 byte reason code as follows Health Level Seven Implementation Support Guide for HL7 Standard
308. ctional issues would driv this Mmieration GE 4 2 4 2 1 4 When is version 2 2 likely to be available from vendors sese 4 2 4 2 2 Order Entry Clinical Observation responses by Hans Buitendijk 4 2 4 2 2 1 What was the driving force behind the creation of version 2 2 In comparison with version 2 1 what advantages does offer 4 2 4 2 2 What does version 2 2 NOT address at this time What known needs will NOT be covered and will they be in future releases such as 2 3 or en Ha 4 2 4 2 2 3 What key criteria should be used in determining if members should upgrade to 2 2 or stay with 2 1 What key functional issues would drive this migrations iaces diste xe e tea eee gena cte io a dn heet costes 4 2 4 2 2 4 If known when is version 2 2 likely to be available from vendors When should members look for these features in vendor interfaces Will version 2 2 be ahead of vendor application software functionality Wr SONIC E ALS Ls 4 2 4 2 3 Control Query responses by Mark ShafarMan sese 4 3 22 341 NOW DASS Ue DN Desa ac ae AAN 4 3 4 2 3 2 Control Query Future Issues and Directions eere 4 5 4 2 3 3 What are the advantages of HL7 Control Query v 2 2 over v 2 1 4 6 4 2 4 Master Files responses by Mark Shatarman sees 4 7 4241 Why Master Files transactions iini o rti eder reis qe lb ctr Masa ced Rand 4 7 4 3 SUMMAR
309. ctional measure and a particular site of measurement E g the many different intravascular sites for blood pressure measurements But in some cases the molecular variables represent combinations of specific measures and particular methods e g the cardiac output measures Please note that most molecular variables could also be accompanied by one or more atomic measures to provide special information about the measure e g special circumstances of the measure or the vendor model number or institutional inventory number of the measuring instrument We have introduced one more convention in this release When we have a variable that really reports what would have been contained in the name in a fully pre coordinated term will have an asterisk placed in the part that will be reported as a value For example a variable that is used to report the anatomic site as an atomic variable would have an asterisk in the system part of the name The variable used to report the method of a particular measure would have a asterisk in the method part of the name Health Level Seven Implementation Support Guide Page H 39 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC References Forrey AW McDonald CJ DeMoor G Huff SM Leavelle D Leland D Fiers T Charles L Griffin B Stalling F Tullis A Hutchins K Baenziger J The logical observation identifier names and codes LOINC database A p
310. d Event Checklists ES 00198 Ead Dates AE MOE AAA A HT E 10 00199 NextofKin AP JobTitle ST 600 Y 11 00200 NextofKinJob APCode Class CC QO 1 12 00201 Nextof Kin AP Employee Numer CX QO ss 13 00202 OrganizationName LI xo 600 Off 9 S 7 14 00119 Manal Status LC 2 5 Co 15 ool Sex 8 LL I D j LI000D 16 00110 Date Time of Birth PTS Q9 J 39 0 0 17 00755 LivingDependency dlrs Ofl 5 oa 18 00145 Ambulatory Status PS O 2 VW 19 00129 Citizenship 0 I 0 CT Cou 20 00118 PrimaryLanguage J l 600 2 ow 21 00742 Living Arrangement I USU 22 00743 Publicity Indicator LI CE D rs 23 00744 Protection Indicator ID D 0136 24 00745 StudentIndicator PS sy 25 0020 Religion IS ow 26 00746 Mothers Maiden Name XPN 489 J 0 0 S 27 00739 Nationality LI CET op 3A 0 wm 28 00125 BhicGrup IS 5 5 0 Soo 29 00747 ContactReason LCE
311. d from Driver s Lic Num Patient to Driver s License Number Patient data type changed from CM to DLN X Data type changed from CK to CX repetition changed to Y changed from ID to IS PID 15 Primary language PID 16 PID 17 PID 18 Patient Account Number PID 20 Driver s license number patient PID 21 Mother s identifier PID 22 Ethnic group PID 23 Birth place X Length changed from 25 to 60 PID 26 Citizenship X Length changed from 3 to 4 data type changed from ID to IS Page 5 12 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Segment Seq PID 28 Nationality X TI PID 29 Patient death date and time X o X Patient death indicator Set ID PV1 X Element name changed from SET ID Patient Visit to SET ID PV1 PV1 2 Patient class X Data type changed from ID to IS Assigned patient location X Length changed from 12 to 80 data type changed from CM to PL PV1 4 Admission type X Data type changed from ID to IS PVI 5_ Preadmtnumbr IX DatatypechangedfromSTto CX PV1 6 Prior patient location X Length changed from 12 to 80 data emm mm o L tome ae o PV1 7 Attending doctor X Data type changed from CN to XCN eee LU Perinde PV1 8 Referring doctor X Data type changed from CN to XCN oem t Pepe PVI 9 Consulting doctor X Data type changed from CN
312. d to write and ballot draft chapters The home health care SIG for example is a group that meets to discuss the application of HL7 to home health care and to provide coordinated input into the work of the various chapters Occasionally a special interest group meets and makes the case for a new chapter and is reconstituted as a Technical Committee G 9 2 4 What is the HL7 Executive Committee The Executive Committee consists of the elected officers of the group and certain members that are appointed by the Executive Committee including the Technical Chair and the Membership Chair The Executive Committee provides policy level guidance including setting budgets and approving the expenditure of funds The Executive Committee approves the formation of new Technical Committees or Special Interest Groups upon recommendation of the Technical Steering Committee G 9 2 5 What is the HL7 Technical Steering Committee The Technical Steering Committee consists of the chairs of all the HL7 Technical Committees and Special Interest Groups Its primary function is to coordinate the work of the Technical Committees G 9 2 6 What is the Role of the HL7 Executive Director and Administrative Staff HL7 contracts with The Association Management Group of Ann Arbor Michigan for various membership services These include publishing the standard and Implementation Guide arranging and providing administrative management of meetings publishing minutes and provid
313. dBase Excel or Lotus spreadsheet or tab delimited ASCII file All submissions should include at a minimum the 7 or 8 required parts of the term as detailed in Table 19 Please sort the input file by the your proposed LOINC name We will maintain the order of the submitted file when we return with our proposed new or existing LOINC codes mapped to your submission It makes it a lot easier to work with an alphabetically sorted file from the outset If you transmit an ASCII tab delimited file see Section 4 Submission in ASCII File Format please maintain the field order as outlined in Table 19 below using whatever delimiter is appropriate to your file format to indicate blank fields An example submission which because of space limitations includes columns for only the first eight fields appears below Real submissions should have columns for all 14 attributes listed in Table 19 Additional details are provided in the section titled Access Database and Excel Submissions presented later in this appendix Table 19 Example submission Row Your test Analyte Component Property Time System Prec Method Class Related Etc ID 1 G23 GLUCOSE 90M POST 50G MCNC T UR ORD TEST CHAL LACTOSE PO STRIP 2 C47 COPROPORPHYRIN 1 MRAT 24H UR QN CHEM ISOMER 3 198 INDICAN MRAT 24H UR QN CHEM 4 T51 THYROXINE FREE MCNC PT UR When we first get a file we run it through a filter program that looks for identical or close matches Our first response to yo
314. dard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 5 1 Since there are no NAK blocks there is no way to signal transmission errors except with higher level messages 2 Carriage Return stuffing is not used Flow through processing is an allowable option HL7 SEQUENCE NUMBER PROTOCOL IMPLEMENTATION In this discussion of HL7 Sequence Number protocol there is an initiating application sending system and an accepting application receiving system It should be noted that not all messages require sequence numbers i e queries network messages etc When a message does require sequence numbers the following implementation notes will apply C 5 1 C 5 2 C 5 3 C 5 3 1 Sequence Number Usage Both parties will follow the HL7 Specification with the following clarifications These clarifications will apply to each of the links over which the HL7 sequence number will be used Note If the Sequence Number protocol is not used on the above links the proper receipt of the messages transmitted over these links cannot be guaranteed Sequence numbering will not be used on display queries or network management messages Sequence Number Description A sequence number is one of the following a positive integer from 1 to two billion 0 or 1 No other numbers are valid e listhe smallest sequence number which can be used for normal message transactions e The value 0 zero
315. dder Tissue large intestine Tissue lung Tissue placenta Tissue small intestine Tissue ulcer Trachea Tube unspecified Icer mbilical blood nknown medicine rethra rine rine clean catch rine catheter rine sediment nknown substance Vitreous Fluid Vomitus Whole blood Whole body Water Wick Wound Wound abscess Wound exudate Wound drainage To be specified in another part of the message Che Cee c ecu These abbreviations are used in the laboratory LOINC codes Systems in clinical LOINC terms are spelled out in full and should be easily understood 2 5 1 Super system 2nd subpart The second subpart of the system distinguishes observations on the patient or samples taken from the patient or donor from observations on non patient materials that relate to the patient e g a blood product unit BPU We refer to this as the super system When the super system is not included in a name it can be assumed to be the patient This subpart can take on the values in Table 11 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page H 27 Final Version 6 98 Appendix H LOINC Table 11 Super System Control Patient Donor Blood Product Unit Pack Fetus POPULATION DISTRIBUTION Population Distribution NEWBORN Newborn For instance an example of representing a coagulation study which uses measures on both patient and a control might be COA
316. dent Information Universal Bill Information Universal Bill 92 Information A 4 2 29 A29 Delete Person Information ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Page A 26 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 2 30 A30 Merge Person Information ADT Originator A or B Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information A 4 2 31 A31 Update Person Information ADT App A App A Message Header Event Type Patient Identification Additional Demographics Next of Kin Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information Health Level Seven Implementation Support Guide Page A 27 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 2 32 A32 Cancel Patient Arriving ADT Originator
317. dumccss mc duke edu ftp standards html gt This Web Server contains pointers to many other Web resources applicable to HL7 and health care information systems standards G 10 RELATIONSHIP TO OTHER STANDARDS G 10 1 DICOM G 10 1 1 HL7 Does not Support DICOM yet How Can We Handle Images with HL7 Standard I think it is fair to say that today there is no HL7 specification for image management that is ready for implementation There has been discussion of this within HL7 and there is a DICOM HL7 special interest group on image management Some of the discussion is archived in lt ftp dumccss mc duke edu standards HL7 archive current CONTROL TXT gt Dean Bidgood bidgood acpub duke edu is a contact for the Image Management SIG In addition the draft of the Control chapter of the next version of HL7 provides for image and audio data types see files H7C2FINB DOC and H7C2FINB TXT in lt ftp dumccss mc duke edu standards HL7 pubs version2 3 gt Al Stone Page G 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 O 1998 All rights reserved Appendix H LOINC Logical Observation Identifier Names and Codes LOINC Users Guide Updated 5 01 1998 Please send questions and comments to LOINC c o Regenstrief Institute 1001 West 10th Street RHC 5 Indianapolis IN 46202 or via Internet loinc regenstrief iupui edu This and other relevant documents are availabl
318. dy weight and measures used to estimate ideal body weight Body height Body temperature Circumference of chest thigh legs Intake and output Major headings of history and physical Major headings of discharge summary Major headings in operative note Electrocardiographic measures Obstetric ultrasound imaging Urology ultrasound imaging In general the component is used to distinguish the various points or ranges or inflections of a physiologic tracing and to define precisely which of a number of possible dimensions of length or area are being measured in imaging For most clinical measurements the component is an attribute of a patient or an organ system within a patient However attributes of non patient systems are also often of interest For example we might want to know the class of instrument used to obtain the measurement i e the vendor model number or institutional inventory number of an endoscopy Such identification numbers have a property of ID Infection control might want the latter reported in order to track nosocomial infections When attributes of an instrument or device are being reported the system is the name of instrument The same is true when we report characteristics of tubes used to move fluid in and out of body cavities For example we might want to report the size and type of a nasogastric tube To accommodate the special dimensions of clinical observations we have introduced new options for the kind of
319. e error detection The BCC is generated as follows 1 Take the Exclusive Or of all of the characters in the block starting with the character following the first SOH or STX in the message and ending with the character just prior to the BCC characters If SOH is present start with the character following SOH and include the STX 2 Convert the resulting binary value to a two character hexadecimal ASCII representation For example to send the message text HL7 is great as the first block after establishment of master slave the general message format of STX BLK TL Text of Message ETX BCC TERM would be encoded as the hexadecimal byte values STX 01 BLK 1 31 1 BCC starts with this byte 30 NP MD d e G LA Lu AB el 73 20 67 72 65 61 74 21 ETX 03 BCC ends including this byte er D OF ga Health Level Seven Implementation Support Guide Page C 13 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 3 2 6 36 D 44 CR UD The result of the exclusive or of the checksummed bytes 31 30 30 30 31 33 48 4C 37 20 69 73 20 67 72 65 61 74 21 03 6D The ASCII characters 6D are used as the BCC above Establishment of Master Slave Relationship In this section the numbers in parentheses refer to Figure C 2 Prior to the establishment of transmission 1 neither station has master status is the sender Either station may request
320. e 20 you may enter your submission data A blank database template named SUBMIT MDB is included in the RELMA software package The data could then be entered into a row of the Access database with values similar to those above Note that fields 15 through 39 in Table 20 are empty when first submitted to RI You should however make every attempt to supply information for first 14 fields presented in Table 20 Other fields in the database e g R COMPO R PROP L_COMPO L PROP etc become populated by us during the evaluation process Using a previously shown example a submission may appear as follows Corresponding Field Name Submitted Data Row In Table 1a 1 S ROW 1 2 S_LOCAL_CD G23 3 S_COMPO GLUCOSE 90m POST 50g LACTOSE PO 4 S_PROP MCNC 5 S_TIME PT 6 S_SYS UR 7 S_SCALE ORD 8 S_METH TEST STRIP 9 S_REL_NAME null 10 S_LOINC 6762 9 11 S_RESULTS null 12 S_UNITS MG DL 13 S_ID null 14 S_COMMENT null Page H 50 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Submission in ASCII File Format Although we prefer that submission be in an Access database format you may also send your submission data as an ASCII file it must have the following format S_ROWIS_LOCAL_CDIS_COMPOIS_PROPIS_TIMEIS_SYSIS_SCALEIS_METHI S_REL_NAMIS_LOINCIS_RESUL
321. e Information A 4 2 50 A50 Change Visit Number ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Patient Visit A 4 2 51 A51 Change Alternate Visit ID ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Patient Visit Health Level Seven Implementation Support Guide Page A 33 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 3 Order Messages A 4 3 1 O01 General Order Message ORM Originator A or B Message Header Notes and Comments Patient Identification Additional Demographics Notes and Comments Allergy Patient Visit Patient Visit Additional Info Insurance Information Insurance Information Add l Info Insurance Information Cert Guarantor Information Allergy Information Common Order Observation Request Notes and Comments Results Notes and Comments Clinical Trial Identification Billing A 4 3 2 O02 General Order Response to any ORM ORR Originator A or B Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Observation Request Notes and Comments Page A 34 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appe
322. e Observation Identifier field that describes that data How Do Send Narrative Reports such as History and Physical or Discharge Summary In HL7 Standard Version 2 3 Sections 7 1 2 and 7 1 3 you will find a very precise description of how to send messages containing narrative reports Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix G Frequently Asked Questions Narrative reports from services such as Radiology usually consist of a number of subcomponents e g a chest x ray report may consist of a description an impression and a recommendation Other studies such as echocardiograms contain analogous components as well as numeric observations e g left ventricular and diastolic diameter The current standard treats each component of a narrative report as a separate test or observation A CHEM12 panel may be transmitted as an order segment OBR plus 12 OBX segments A chest x ray may be transmitted as an order OBR segment plus three OBX segments one for the description one for the impression and one for the recommendations Similarly an EKG report would be transmitted as an order segment OBR two OBX segments for the impression and recommendation and additional OBX segments for each EKG measurement e g the PR interval QR interval QRS axis and so on We have defined code suffixes for constructing observation IDs for the
323. e Templates Recommended Staff Background What training experience should the implementation and support personnel described above have prior to implementing your product POSITION TRAINING EXPERIENCE COMMENTS Interface Analysts Operators AIE Administrator Estimated Man hours Provide an estimate of the man hours required of St Anybody s Medical Center staff to support and implement the proposed solution Justify the estimate by including any assumptions or experience on which the estimate is based Implementation Category I Interfaces POSITION MAN HOURS JUSTIFICATION Health Level Seven Implementation Support Guide Page F 51 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates Category II Interfaces POSITION MAN HOURS JUSTIFICATION Category III Interfaces POSITION MAN HOURS JUSTIFICATION Ongoing Support and Maintenance Category I Interfaces POSITION MAN HOURS JUSTIFICATION Page F 52 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates Category II Interfaces POSITION MAN HOURS JUSTIFICATION Category I Interfaces iC 4 MAN HOURS JUSTIFICATION Health Level Seven Implementation Support Guide Page F 53 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates
324. e able to interrupt the sender to reverse the direction of data flow when needed 12 Error recovery should be simple few states 13 The checksum algorithm must not produce arbitrary byte values Displayable ASCII characters must be sent 14 Support of data transparency should be an optional but fairly trivial addition to the protocol 15 Either side can detect when the communication link becomes inoperative within 5 10 minutes 16 Block size and perhaps other parameters can be negotiated or predetermined Health Level Seven Implementation Support Guide Page C 9 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 3 1 3 Environment Model The following model and guidelines are used with this protocol to support the stated requirements and assumptions The job of the communication modules that implement this protocol is to take a message from a single source and deliver it intact to a single destination See Figure C 1 The message source and destination may vary with implementation but will frequently be a queue or spooler Message Source Message Message Message Destination Source Destination Application Messages Communications Communications Link Link Figure C 1 Single Message 1 Way Transfer The communications protocol is a delivery mechanism only To the communications module an HL7 reply is just another message text It d
325. e e PV2 36 Newbombabyindicaor X PV2 37 Baby detained indicator X ME CENE NKL2 Name TX Page 5 14 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Segment Seq A So ee NKI 4 Address NK1 5 Phone number NK1 6 Business phone number e hange repetition changed to Y repetition changed from Y 3 to Y Data type changed from TN to XTN repetition changed to Y X Field name changed from Next of Kin Job Title to Next of Kin Associated parties Job Title Data type changed from CM to JCC element name changed from Next of Kin Job Code Class to next of Kin Associated Parties Job Code Class X Data type changed from ST to CX element name changed from Next of Kin Employee Number to next of Kin Associated Parties Employee Number X Data type changed from ST to XON repetition changed to Y e 3 NK1 10 Next of kin associated parties job title NKI 11 Next of kin associated parties job code class NK1 12 Next of kin associated parties employee number NKI 14 NKI 15 NK1 31 Contact person s phone ee see NI NK1 33 Next of kin associated ee Ps NK1 35 NK1 36 NK1 37 Contact person social security number AL1 1 Set ID AL1 AL1 2 Allergy type AL1 4 Allergy severity NK 1 23 NK1 24 NK 1 25 X Element name changed from Set ID Allergy to Set ID AL1 Data type changed
326. e in Healthcare Environments Version 2 1 1990 e Application Protocol for Electronic Exchange in Healthcare Environments Version 2 2 1994 e Application Protocol for Electronic Exchange in Healthcare Environments Version 2 3 1997 e HL7 s Implementation Support Guide for Version 2 1 1992 e HL7 s Implementation Support Guide for Version 2 2 1995 e HL7 s Implementation Support Guide for Version 2 3 1998 1 8 EXPECTED PUBLICATIONS Application Protocol for Electronic Exchange in Healthcare Environments Version 3 0 2000 1 9 HL7 SPONSORED MEETINGS HL7 has been meeting regularly since March 1987 HL7 meetings have generally been held three times each year in January April and September The traditional meeting schedule is as follows an introductory Tutorial on HL7 is provided on Monday Working Group meetings convene on Tuesday through Friday morning HL7 s Fall meeting also includes a Plenary meeting on Monday with Working Group Meetings convening Tuesday through Friday morning A schedule of recent and future HL7 Working Group meetings is provided below HL7 MEETING DATES LOCATION January 1998 New Orleans LA April 1998 Baltimore MD September 1998 San Diego CA January 1999 Orlando FL April 1999 Toronto Ontario Page 1 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 1 Introduction 1 10 KEY CONTACTS 1998 HL7 BOARD
327. e in application systems 3 6 6 2 5 Security Define procedures to control update and monitor security at each entry point e g application systems operating system network interface engine 3 6 6 3 User Procedures Review the new data flow and interface with users in light of current user procedures Modify these procedures as needed Typically this will require changing manual procedures that are no longer necessary for double entry into different system 3 6 7 Conduct Training 3 6 7 1 User Training An HL7 interface can be implemented with little impact on application system users or may require significant changes in workflow and operation This is dependent on the scope of the effort from the migration of an existing interface to HL7 through complete application system replacement The impact can vary from transparent to major Selection and use of the following sections depends on the nature and scope of the interface being implemented 3 6 7 1 1 Review Changes In User Operation Review operational changes in the user department related to new or redefined user procedures This review should be from a training perspective in order to develop classes or materials to assist in the transition to the interfaced system 3 6 7 1 2 Develop Training Material Develop necessary training material from information gathered through development of user procedures and review of operational changes Material will be employed during trai
328. e main stumbling block was the need for the data to be EBCDIC on the AS 400 and ASCII on the Tandem The second RPG program referred to above in the ADT interface has the ability to do EBECDIC to ASCII translations as well as ASCII to EBCDIC on the return using an IBM program where you pass in one record at a time in a parameter and receive it back translated Therefore this issue of translating one record at a time was minimal Unfortunately the problem was not as easily handled with the charge batch Something inherent with the Tandem hardware required us to perform a BINARY translation when executing the GET Because the translation options of BINARY EBCDIC and ASCIT are mutually exclusive we were forced to either receive the file in ASCII or ask our vendor on the Tandem to send it in EBCDIC When working with IBM on how to perform a ASCII to EBCDIC translation on an entire file we found that the only way was to use IBM PC Support functions which we determined to be too cumbersome Our decision was to request the batch to be sent in EBCDIC The Future Initially we only needed the two interfaces as the first module we are bringing up on the Tandem is the Pharmacy module When we bring up our Order Communications module we will need to implement real time orders and results interfaces as our Lab system resides on our AS 400 It is our current plan to have those interfaces function similarly to the ADT interface and hopefully utilizing some
329. e measurement by another that are not covered by the above rules should be classed as having Complex CMPLX properties and the exact formula for deriving the quantity should be explicitly stated 6 ARBITRARY Arbitrary concentration of items If we are not measuring the activity of an enzyme then the units of measure and properties are Possible Values Property Precision Units International Units IU ARB QN Units ml IU ml etc ACNC QN Units gm IU gm etc ACNT QN Unit min IU 24hr etc ARAT QN Unitless Patient Control AFR QN When measuring presence absence or ordering measures of a component ACNC is also the correct property If we are measuring the activity of an enzyme then the units of measure and properties are Possible Values Property Precision Units International Units IU CRB QN IU ml Units ml etc CCNC QN IU gm Units gm etc CCNT QN IU 2Ahr Unit min etc CRAT QN Unitless Patient Control CFR QN Health Level Seven Implementation Support Guide Page H 55 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC 7 If the property is TITR then the precision is always QN For Any X AB Any X AG Possible Values Property Precision 1 2 1 4 1 8 TITR QN 8 For Any X AB Any X AG Possible Values Property Precision Neg Indeterminate Pos ACNC ORD 1 2 3 ACNC ORD lt 1 2 1 4 1 8 TITR QN Neg 1 4 1 8 ACNC TITR ORDON 9 For any intensi
330. e of data involved may be patient centric or aggregate across populations Example DS applications are patient centered alerting reminding the automated tracking of complex electronic guidelines cost benefit analysis outcome analysis etc Decision support applications often draw inferences or conclusions from diverse data elements and multiple data sources and thus have a requirement for data that is represented in a controlled and semantically meaningful fashion The role of the Decision Support SIG is to a identify the scope and range of data elements required for the functionality of DS applications b work with other SIGs or outside organizations to identify appropriate controlled vocabularies for encoding those data elements c identify or define messages and objects required to support the specific information exchange needs of DS applications both as feeders to DS applications and as output from DS applications Projects e Patient centered near real time alerts e Population and interpretation of data warehouse used for Decision Support HOME HEALTH Louis Gordon Delta Health Systems Ph 814 944 1651 Fax 814 944 6543 Email louisfordon deltahealth com Mission The goal of the Home Health Long Term Care SIG is to support message development efforts of the TCs to meet the needs of our interest groups Home Health Agencies Long Term Care facilities Hospices Assisted Living facilities Managed Care Organizations Adult Day
331. e via FTP Gopher www mcis duke edu standards termcode loinclab World Wide Web http www mcis duke edu standards termcode loinc htm List of Files Description Format File Name LOINC database ASCII LOINDBTI TXT LOINC database ASCII ZIP LOINDBTI ZIP LOINC database MDB ZIP LOINCMDB ZIP LOINC database printout RTF LOINDBW1 RTF LOINC database printout RTF ZIP LOINDBW1 ZIP LOINC Users Guide WP 6 7 8 LOINMANI WPD LOINC Users Guide Word 6 95 LOINMANI DOC LOINC Introduction ASCII LOININTR TXT LOINC Read Me ASCII LOINRDME TXT LOINC Release Notes ASCII RELNOTES TXT RELMA Regenstrief LOINC EXE ZIP RELMA EXE Mapping Assistant RELMA Documentation Word ZIP MANUAL ZIP Health Level Seven Implementation Support Guide Page H 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC TABLE OF CONTENTS COPYRIGHT AND TERMS OF Bor EE PREFACE AND INTRODUCTION DEE ii ACKNOWLEDGEMENTS Page H 2 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 TABLE OF CONTENTS CONTINUED APPENDIX A LONC DATABASE STRUCTURE ssccccssssscssssscccssssccccssssccscssccccssscccessnccsecssccccssacccesssaccecssceccessacccessssccscssseccees 32 APPENDIX B CALCULATING MOD 10 CHECK DIGITS eee ee ee ee eee sss seson etos ee aos seen nee seen e ee a sne 37 APPENDIX C PROCEDUR
332. ecutive and Steering committees submit registered HL7 message profiles for recognition by other international organizations involved in the progression of standards profiles including but not limited to EWOS and ISO JTC1 DECISION SUPPORT Carol Broverman Ph D First Databank Ph 650 588 5454 Fax 650 588 4003 Email carol broverman Gfirstdatabank com Karen Herzog HBO amp Company Ph 413 549 7100 Fax 413 253 5198 Email karen herzog hboc com Robert Jenders MD Columbia University Ph 212 305 5438 Fax 212 305 3302 Email endersGcolumbia edu Page 1 18 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapier 1 Introduction Harm Scherpbier MD Aetna US Healthcare USQA Ph 215 775 6587 Email scherpbier ushc com Mission Decision support DS refers to those functions which utilize data available in a health care enterprise that facilitate and support decision making Decision makers may be individuals or computer programs including all stakeholders such as health care practitioners nurses pharmacists quality assurance personnel and other administrative personnel The domains for DS include the support of clinical decisions financial decisions or administrative decisions The mode of interaction for decision support system functionality may be real time just in time or retrospective asynchronous The scop
333. ed 1 Name of Individual 2 Tide of Individual 3 Address 4 Phone number To assist in the response process St Anybodys Medical Center has provided a diskette containing the body of this RFP This RFP has been created in Microsoft Word 6 0 or 7 0 The award of the contract if any will be based upon evaluation criteria developed by St Anybodys Medical Center and the manner in which each proposal meets the evaluation criteria will be determined by St Anybodys Medical Center at its discretion All inquiries regarding the RFP and selection process should be directed to name at the Health Level Seven Implementation Support Guide Page F 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates address provided above F 1 3 4 Project Timetable All RFP responses will be evaluated by a team whose members represent the Information Systems Department of St Anybodys Medical Center and name if applicable Consultant to St Anybodys Medical Center for this selection process Each vendor will be notified of the outcome of the review of its response The anticipated timetable for the evaluation process and subsequent project activity is summarized below 1 Begin Date End Date Conduct reference checks 2 Date Distribute request for proposal 3 Begin Date End Date Vendor response period 4 Begin Date End Date Schedule on site walk throughs and demos 5 Date Receive vendor
334. ed Document potential conditions as they arise throughout the entire development process Additional conditions may be added during the testing process to identify unanticipated conditions Fault insertion testing procedures should be documented Expected Results Document the expected results for each test including output to another process and performance of the interface This provides the method for verifying the result Testing Worksheet Develop a document that will be used as a checklist during testing It should provide step by step tasks including the setup and execution of the tests as well as expected results 3 4 10 Finalize Migration Approach Review and finalize the high level migration approach defined during functional design Detail the process and timetable for parallel testing identify pilot users separate or shared communications and production cutover Use the output from section 3 3 5 Develop Migration Approach 3 4 11 Finalize User Access Security Approach Review and finalize user access and security approach This includes technical requirements to provide single or multiple points of entry and resolution of log ins and passwords Use the output from section 3 3 6 Develop User Access Security Approach 3 4 12 Conduct Review And Obtain Acceptance For Technical Design Document and present for approval entire technical design including lower level protocol communications hardware programs test
335. ed Final Version 6 98 Appendix H LOINC Table 1 Hierarchical Structure of Fully Specified Analyte Names Subpart Name Section Component analyte 2 2 Name and modifier 2 2 1 Component analyte name 2 2 1 1 Component analyte subname 2 2 1 2 Component analyte sub sub name 2 2 1 3 Information about the challenge e g 1H post 100 gm PO challenge 2 2 2 Adjustments corrections 2 2 3 Kind of Property mass concentration mass 2 3 Time Aspect point or moment in time vs time interval 2 4 System Sample type urine serum 2 5 Super System patient donor blood product unit Type of Scale nominal ordinal quantitative 2 6 Method Type 2 7 2 1 2 3 Use full taxonomic name of an organism or virus name not the disease when describing a test that diagnoses that disease Say rickettsia rickettsii AB not Rocky mountain spotted fever AB Say herpes simplex virus AB not HSV AB The disease name should be included as a synonym in the Related Term field 2 1 2 4 Species and groups of species SP identifies a single species whose identity is not known SPP identifies the set of species beneath a genus We have a third case however In some tests antibodies apply to different strains of species In rickettsial diseases the antibodies are then against groups of species e g the spotted fever group or the typhus group The convention remains the same we name the immunochemical serologic test by the organism so it becomes Ricke
336. ed to Process the Message C Conditionally Required O Optional Z Can support it with custom code N Not Supported For you convenience we have indicated the segments that are required by HL7 If the segment is optional a blank line is provided A check mark can be used to indicate that an optional segment will be used in the interface The messages described in the checklist are based on the final balloted Version 2 3 of the HL7 Interface Standard published April 3 1997 A 4 1 Control Section A 4 1 1 ACK General Acknowledgment Originator A or B Health Level Seven Implementation Support Guide Page A 9 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist Name OPT App A Repeat App B Repeat Message Header R Message Acknowledgment R Error A 4 1 2 MCF Delayed Acknowledgment Originator A or B Message Header Message Acknowledgment A 4 1 3 QRY Query Originator A or B Message Header Query Definition Query Filter Continuation Pointer Page A 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 1 4 DSR Display Response Originator A or B Message Header Message Acknowledgment Error Query Definition Query Filter Display Data Continuation Pointer A 4 1 5 Q05 Unsolicited Displa
337. egment and Event Checklists B 1 83 RQ1 Requisition Detail 1 1 00285 Anticipated Price Is ss 2 00286 ManufacuredID C CE 60 3 00287 Manufacturer s Catalog C ST ue PP 4 0088 VendorIb_____________ C CE 60 0 0 a 5 00289 VendorCatalog C ST 69 J o 6 0090 Taxable 1I D a amp mer 7 00291 Substitute Allowed T0136 B 1 84 RQD Requisition Detail 1 00275 Requisition Line Numer SI D S 2 00276 ItemCode Internal C CE 600 J ZJ 39 05 3 00277 ItemCode Extemal l 600 S 4 002778 HospitalltemCode CE o J J 0 9 5 00279 Requisition Quantity CW III S 6 00280 RequisiionUnitof Measure CE 6 Jj o S 7 00281 Dept CostCenter PAS GO o 8 00282 ItemNatural Account Number I GO Com 9 00283 DelivertoID LI CE 60 k HERE MENU C U ee ep EE Page B 48 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists
338. el Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 3 20 ROR Pharmacy Treatment Order Response ROR Originator A or B Message Header Message Acknowledgment Error Query Definition Query Filter Patient Identification Notes and Comments Common Order Pharmacy Treatment Order Pharmacy Treatment Route Pharmacy Treatment Component Continuation Pointer A 4 3 21 RAR Pharmacy Treatment Administration Information RAR Originator A or B Message Header Message Acknowledgment Error Notes and Comments Query Definition Query Filter Patient Identification Notes and Comments Common Order Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component Pharmacy Treatment Administration Pharmacy Treatment Route Continuation Pointer Health Level Seven Implementation Support Guide Page A 45 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 3 22 RDR Pharmacy Treatment Dispense Information RDR Originator A or B Message Header Message Acknowledgment Error Notes and Comments Query Definition Query Filter Patient Identification Notes and Comments Common Order Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component Pharmacy Treatment Dispense Pharmac
339. ell whether it s up whether errors have occurred recently what the errors were and what the volumes were can you restart the interface without restarting the system Health Level Seven Implementation Support Guide Page G 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions G 8 2 2 G 8 2 3 Develop and follow a test plan that includes validation of each data field for each trigger event and deals with error conditions The important thing to recognize is that interfaces are not plug and play nor will they be trouble free Considerable analyst time will be involved in selecting which options to use negotiating them with the vendors and developing and following a test plan As you change your information processing needs in house you will need to maintain your interfaces The most straightforward example of this is adding additional fields to messages as they become necessary The HL7 Implementation Guide is a source of more detailed information on implementation methodology As an Information Systems Developer How Do Develop HL7 Interfaces The two very important things to remember Interfaces run without the involvement of a human being Interfaces will change Because they run without a human being they are very sensitive to errors It is an unacceptable situation when the lab calls at 9 00 Monday morning because it isn t getting admissions and you find
340. em enhancement What is it Shipping and Taxes Provide an itemized list of shipping and handling costs associated with the purchase of the proposed solution including support maintenance upgrades and system enhancements Provide an itemized list of taxes associated with the purchase of the proposed solution including support maintenance upgrades and system enhancements Page F 56 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates F 1 9 10 Total Life Cycle Cost Use the information provided in the preceding sections to complete the following table IMPLEMENTATION COST SUPPORT AND MAINTENANCE UPGRADES AND ENHANCEMENTS CATEGORY CATEGORY CATEGORY CATEGORY CATEGORY CATEGORY CATEGORY CATEGORY CATEGORY I Il Ill 1 Il Ill I Il Ill SOFTWARE HARDWARE AND CABLING DOCUMENTATION MODIFICATIONS TRAINING IMPLEMENTATION ASSISTANCE FIRST YEAR SECOND YEAR THIRD YEAR FOURTH YEAR FIFTH YEAR SHIPPING AND TAXES TOTAL Notes Health Level Seven Implementation Support Guide Page F 57 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 9 11 Vendor Recommended Categories Approach Completion of this section is optional However if you have any suggestions for improving the implementation of the AIE and described interfaces St
341. em indicates it has recovered from a failure A predefined application function occurs A St Anybodys Medical Center defined application processing event occurs Describe in detail what transpires when each event occurs What other trigger events will send a transaction Describe transaction history archival capabilities Describe transaction re transmission capabilities Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 5 Transaction Size and Volume a Identity size limitations b Identity volume limitations c Describe image audio and video transaction capability 6 Batch File Transfer Which of the following do you support How are they configured e g table driven programmed etc Describe the programming effort and or tables required a TCP IP b DECnet c OSI d Kermit e X Y or Z Modem f Novell g Pathworks h LAN Manager i Appletalk j SMTP k Magnetic Media L Any others your product supports F 1 7 4 Application Interface Engine Development and Maintenance Tools The Application Interface Engine AIE development environment must fit within the framework of St Anybodys Medical Center s existing design program and testing philosophy Review and QA will be used throughout the development phase and in the overall implementation of the AIE Development tools specified by the vendor must include aids for de
342. ements Document Draft Prepare LAB Interface Requirements Document Final Obtain LAB Interface Requirements Signoff Requirements Analysis Benchmarks Current Environment Benchmark Determine Target Environment Benchmarks Requirements Analysis Procedure Directory Synchronization Clinical Data Repository and Lab Environment s Review Current Procedure Directories in all Lab System Environments Review Current Procedure Directories in the Clinical Data Repository Review Current Procedure Directories in Commercial Reference Lab Environments Prepare Procedure Directory Synchronization Requirements Document Draft Prepare Procedure Directory Synchronization Requirements Document Final Obtain Proc Dir Synchronization Requirements Signoff Requirements Analysis Operations Review Current Operations Policies and Procedures Prepare Operations Requirements Document Draft Identify user accts Dev amp Operations Identify backup requirements and schedule Prepare Operations Requirements Document Final Setup Licensing Maint Agreements for Software Setup Licensing Maint Agreements for Hardware Obtain Operations Requirements Signoff Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 8 DESIGN 8 1 Interface Engine Architecture High Level Design 8 2 Lab System Interface High Level Design 8 3 Purge Security Specification 8
343. emistry Coagulation study Cytology Drug levels Drug dose for transmitting doses for pharmacokinetics Fertility Hematology excluding coagulation amp differential count HLA tissue typing antigens Microbiology Pathology Serology antibodies and most antigens except blood bank and infectious agents Sugical pathology Toxicology Urinalysis Veterinary Medicine Abbr BDYCRC BDYHGT BDYSURF BDYTMP BP VENOUS CLIN ED EKG EKG IMP EKG MEAS EYE FUNCTION H amp P HEMODYN HRTRATE IO NEONAT OB US OBGYN RESP SKNFLD US URO VOLUME Clinical Term Classes Body circumference Body height Body surface area Body temperature Body weight Blood pressure Blood pressure central Blood pressure positional Blood pressure timed Blood pressure venous Clinical NEC Emergency department Electrocardiogram Electrocardiogram impression Electrocardiogram measures Eye Functional status e g Glasgow History and physical Hemodynamics Heart rate Input Output Neonatal measures Obstetric ultrasound Obstetrics gynecology Respiration Skinfold measurements Urological ultrasound Volume specimens Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page H 45 Final Version 6 98 Appendix H LOINC Appendix B Calculating Mod 10 Check Digits The algorithm for calculating a Mod 10 check digit is as follows In
344. ended to establish a framework for identifying establishing and measuring costs benefits and organizational impacts associated with the implementation of an HL7 environment 2 3 1 Business Strategy 2 3 1 1 Prototype Demonstration Review the key strategic objectives and mission of the institution the organizations business needs and the size of the organization e g anticipated growth available budget Ensure these items are understood and taken into consideration in establishing the overall systems strategies 2 3 1 2 Streamline Current Operations Identify any opportunities to streamline existing operations prior to initiating specific systems development activities This will help maximize the benefits of new system implementations and the integration of these systems 2 3 1 3 Develop I S Strategy Establish an overall information systems strategy e g open architecture single vendor shared contract services multiple vendor interfaced etc This strategy will be critical in guiding subsequent vendor selection design and implementation activities Document the pros cons and implications of the various overall systems strategy options as part of this process and communicate these to executive management 2 3 1 4 Develop Security Strategy Establish a high level security strategy regarding system access and controls This is a necessary activity within any systems development project but is even more critical when moving
345. endix A HL7 Transaction Checklist A 4 6 11 CMA Clinical Study with Phases and Schedules M06 Originator A or B Message Header Master File Identification Master File Entry Clinical Study Master Clinical Study Phase Clinical Study Schedule A 4 6 12 CMB Clinical Study without Phases but with Schedules M06 Originator A or B Message Header Master File Identification Master File Entry Clinical Study Master Clinical Study Schedule A 4 7 Medical Records Information Management A 4 7 1 T01 Original Document Notification MDM Originator A or B Message Header Event Type Patient Identification Patient Visit R R R R R Document Notification Page A 62 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 7 2 T02 Original Document Notification and Content MDM Originator A or B Message Header Event Type Patient Identification Patient Visit Document Notification Observation Result one or more required DDD DD m A 4 7 3 T03 Document Status Change Notification MDM Originator A or B Message Header R Event Type R Patient Identification R Patient Visit R Document Notification R A 4 7 4 T04 Document Status Change Notification and Content MDM Originator A or B Message Header Event Type Patient Identification Patient Visit Document N
346. ent eee F 6 F 1 4 2 Strategic Technological Dire CO ib F 6 F 1 4 3 Application Systems ENVIO Md ee eege F 7 E44 Application Interface Environinent uoce n et pci F 8 F 1 4 5 Network Environment itte rere etd e toti etate ME Pese eei etude F 9 F 1 5 Proposed Environment and Development Plan F 9 F151 Proposed Environment F 9 F 1 5 2 Development Plan order eive IRA PUR INL E SERE Ta asas F 10 ELE Vendor Information ii as F 12 F 1 6 1 General Vendor Informa ipee iii i F 12 F 1 6 2 Contractual Warranty Specifications sese ee see eee eee eee eee eee F 16 F 1 6 3 System Support and Maintenance ee eee eee F 17 E 1 6 4 Installation Support wiii eret ete EX a Rasa eae dae F 19 F 1 6 5 Documentation and Training acorns ose ic e pt ee hate ela eee F 20 F 1 7 Application Interface Engine Features and Functionality esses F 21 IS E O System OVerview aue eese RR QU IESU AAT ARIA T QUIS EY Ua QU d ve Eed F 21 F 1 7 2 Transaction Data Translation Splitting and Combining F 22 SEN Kee Ee Ree F 23 F 1 7 4 Application Interface Engine Development and Maintenance Tools F 25 Po n STs Ee EE F 28 F 1 7 6 Customer User Interface Front End Integration seen F 29 ELTA Standard Interlace Sirr aes Saat buta usati dus Cip ate EM dcus F 29 F 1 7 8 Data Repository Clinical Database esee ee F 31 E 1 79 JAdrmnistratlon E F 31
347. ent management ADT and financial that is patient accounting billing processing requirements of health care providers The Patient Administration projects will define the messages needed to support the identification maintenance and movement of patients throughout the health care provider environments This explicitly excludes the X12 subject domain and third party entities e g payers and government The Financial Management projects will define the messages needed to support the identification and maintenance of patient accounting data including contract management throughout the health care provider environments Projects Patient administration projects Communicate the collection and maintenance of person demographic data Communicate the collection and maintenance of persons or entitied related to the patient Communicate the collection and maintenance of patient encounter visit data Communicate the collection and maintenance of location tracking data Communicate specific identifier maintenance information Communicate associated patient administration master file data Communicate the collection and maintenance of data for a master patient index Financial Management projects Create and maintain patient account information include guarantor insurance diagnoses and procedure data Communicate detail financial transactions e g charges credits adjustments Communicate regulatory information include UB DRG and acc
348. entation and Training F 1 6 1 General Vendor Information 1 Corporate Overview A Names of Representatives Respondent to REP Name Title Office Location Phone Number B Authorized Contract Signer Name Title Office Location Phone Number 2 Locality A Where are your company headquarters located B Where is your sales office nearest to St Anybodys Medical Center located Page F 12 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 3 Corporate Management Please indicate the date of the last change in the following items Last Change in Date of Change Comments Ownership Composition President Chief Financial Officer Technical Support Director Customer Support Director Auditors Bankers 4 Financial Background A For each of the last three fiscal years please indicate FY 19 FY19 FY 19 Annual Sales Net Profit Total Assets Total Debt B How many consecutive quarters of profit has your firm posted in the past two years C List any outstanding financial or legal liens on the company D Please provide a copy of your most recent financial statement 5 Product Development Profile A How long has your company been in the business of data processing B How long has your company been in the business of Application Interface Engines C What percent of revenue and how many dollars did your company
349. ents Pathway Variance Pathway Role Pathway Variance Role Detail Problem Notes and Comments Variance Problem Role Variance Role Observation Result Notes and Comments Detail Goal Notes and Comments Goal Variance Goal Role Goal Variance Role Observation Notes and Comments Common Order Order Detail Notes and Order Detail Comments Variance Order Observation Result Notes and Comments Observation Variance Observation Result A 4 10 8 PCC PC Pathway Problem Oriented Update PPP See A 4 10 7 A 4 10 9 PCD PC Pathway Problem Oriented Delete PPP See A 4 10 7 Page A 86 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 10 10 PCG PC Patient Pathway Goal Oriented Add PPG Originator A or B See A 4 10 10 Message Header Patient Identification Patient Visit Patient Visit Additional Info Pathway Detail Notes and Comments Pathway Variance Pathway Role Pathway Variance Role Detail Goal Notes and Comments Goal Variance Goal Role Goal Variance Role Observation Notes and Comments Detail Problem Notes and Comments Variance Problem Role Variance Role Observation Result Notes and Comments Common Order Order Detail Notes and Order Detail Comments Variance Order Observation Result Notes and Comments
350. epetition changed to Y IN3 8 Operator X Data type changed from CN to XCN repetition changed to Y Page 5 26 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Segment Seq IN3 12 Non concur Added table 0233 code description IN3 14 Physician reviewer Data type changed from CN to XCN repetition changed to Y IN3 16 Certification contact phone Data type changed from TN to XTN number16 repetition changed from Y 3 to Y IN3 19 Certification agency phone Data type changed from TN to XTN number repetition changed from Y 3 to Y IN3 23 Data type changed from ID to IS N3 24 Second opinion Data type changed from ID to IS repetition changed to Y IN3 25 Second opinion physician Data type changed from CN to XCN repetition changed to Y ACC 2 Accident code Length changed from 2 to 60 data type changed from CE to ID ACC 4 ACC 5 Accident job related indicator ACC 6 Accident death indicator UB1 1 Set ID UB1 Element name changed from Set ID UB82 to Set ID UB1 UB1 2 Optionality changed from O to B UB1 7 Condition code 35 39 Length changed from 2 to 14 Data PE Type changed from ID to IS UB1 10 Value amount and code Data Type changed from ID to CM 46 49 UB1 12 Spec program indicator Length changed from 2 to 60 data type 44 changed from ID to CE UB1 13 PSRO UR approval Length changed from 1 to 60
351. er the AIE must be recovered because of its relationship to the other systems l Describe the features plans facilities available for disaster recovery 2 Describe disaster recovery plans you have incorporated at other institutions and identify the institution and contact person 3 What types of disaster recovery functions are available with the recommended platform 4 What if any disaster recovery function are you recommending 5 How are you the vendor involved in disaster recovery 6 Describe any real time disaster tolerant features of the product e g an Open VMS or FDDI cluster F 1 8 9 Environment St Anybodys Medical Center provides a data center that is engineered to provide facilities to meet the requirements of the equipment This includes but is not limited to proper power air conditioning space and security 1 Describe the environmental requirements consumption e g electrical power A C etc of Health Level Seven Implementation Support Guide Page F 37 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates the AIE processor and its components 2 Whatare the proposed platform s space requirements 3 Please provide copies of templates for planning the computer room layout F 1 8 10 Cable Plant St Anybodys Medical Center has typically installed cabling on an as needed basis to support network and system applications It is an
352. erface Engine Table of Contents F 1 SAMPLE RFP FOR AN APPLICATION INTERFACE ENGINE 1 F 1 2 Background and Strategic Direction 4 F 1 3 Instructions Scope and Methodology 4 1 4 Current Operational and Technical Environment Ln ol Proposed Environment and Development Plan F 1 6 Vendor Information 12 F 1 9 Implementation Cost Schedules 39 F 2 SAMPLE INTEGRATION PROJECT PLAN FOR A CLINICAL LAB PROJECT 59 Page F 2 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates F 1 1 Introduction This is a Request for Proposal RFP for an Application Interface Engine AIE for St Anybodys Medical Center SAMC The remainder of this RFP is divided into the following sections te Ce Background and Strategic Direction This section includes information regarding St Anybodys Medical Center the current systems environment and the project approach Instructions Scope and Methodology This section includes instructions for responding to the RFP an overview of the selection timetable the scope of the RFP and a description of the evaluation methodology Current Operational and Technical Environment This section describes the current operational environment and the strategic IS direction that St Anybodys Medical Center intends to pursue Proposed Environment and Development Plan This sect
353. ernal 1D R x on cp H Pr 4 00107 Alternate PatientID x 09 H H H 5 0008 PaimsNam 1 R XN on Or T 6 0010 Mothers Maiden Name 1 x a i T 1 7 o Date of Bien as 09 O T spoon sex H ST 9 oon Patient Alas XN 49 49 T 1 10 o Race H OS Cu mm Patient Address H XAb 09 CS 1 1 12 oons CountyCode 1 8 is amp 0o O To o To 13 0016 PhoeNemer Hom 1 XmN w O To 1 14 0017 Phone Number Business XIN on O T 15 008 Lagmge Paiem CE o 16 oono Marital Status 5 4D 17 0020 Religion 5 9 18 0013 Patient Account Number X Q9 T 1 19 00122 SsNNumer Paiem T ag T 20 00133 Drivers License Paiem DIN Ill 21 001 Mothers identifier 2 0025 Ethnic Group 1 2 00126 Birth Place 24 00127 Multiple Birth Indicator 25 00128 Birth Order 27 00130 Veteran s Military Status 28 0039 Nationality P 29 00740 PaientbeahDaeTim 30 00741 Patient Death Indicator JL B 1 71 PR1 Procedures Len Max Sender Variable Receiver Variable
354. ernal Medicine 1989 110 5 333 335 International Union of Pure and Applied Chemistry International Federation of Clinical Chemistry The Silver Book Compendium of terminology and nomenclature of properties in clinical laboratory sciences Oxford Blackwell Scientific Publishers 1995 LOINC Committee Logical Observation Identifier Names and Codes Indianapolis Regenstrief Institute and LOINC Committee 1995 c o Kathy Hutchins 1001 West 10th Street RG 5 Indianapolis IN 46202 317 630 7433 Available via FTP Gopher 8 Available from American Society for Microbiology 1913 Eye St NW Washington D C 20006 7 Available from the National Drug Code Directory FDA Rockville MD and other sources 8 Available from National Library of Medicine 8600 Rockville Pike Bethesda MD 20894 9 Available from James D Read MB ChB DRCOG MRCGP General Medical Practitioner Park View Surgery 26 28 Leicester Rd Loughborough Leicestershire LE11 2AG 10 Available from American College of Pathology Skokie IL 11 Available from INTDIS P O Box 26 S 751 03 Uppsele Sweden 12 Available from ECRI 5200 Butler Pike Plymouth Meeting PA 19462 13 Available from Dept of Health amp Human Services FDA Rockville MD 20857 14 Available from LOINC Committee Logical Observation Identifier Names and Codes Indianapolis Regenstrief Institute and LOINC Committee 1995 c o Kathy Hutchins 1001 West 10th Street RG 5 Indianapolis IN 46202 317 630 7433
355. ernal contradiction e g we have listed it as being done on serum when it is only valid when performed on plasma or it is a duplicate of some other concept in the data base Note that our policy is to allow both method vague no method as well as method specific measures in serology measures of AB and AG but not in antibiotic susceptibility testing Please pay special attention to requests for submissions that include the system of serum or plasma alone For most chemical analyses there is no important clinical difference between the values obtained from serum and those obtained from plasma and we would like to represent them in the database as SER PLAS to indicate our indifference to the distinction Unfortunately many requestors of new terms define their request in terms of the one that they happen to use e g serum or plasma without telling us that the measure can really be done on either serum or plasma equally Most such requests should be for SER PLAS as the system sample If the measurement MUST be done either serum or plasma please scientifically justify your request otherwise you will greatly delay our response to your submission When you wish to submit tests or measures which are radically different from those we currently carry please provide a full description of the test its purpose and procedure A Xerox copy of test kit vendors descriptive material or from a textbook describing the procedure and its purpose would be ve
356. ersal identifiers for test results Y Tab Delimited ASCII Each record of the database is on a separate line Each record is terminated by CR LF and each field is delimited by a tab character Non null text fields are enclosed in double quotes Spreadsheet and database programs can import such files easily This is the format you will use if you want to inport into your own data base It contains all of the content of the data base The tab delimited ASCII file is the database of record unlike the word processing versions it will always contain all implemented fields This file is available in a zipped and unzipped version d RTF file This file is formatted to print landscape in a Courier 6 point font and is intended to provide an easy to read print version The LOINC records are sorted in alphabetic order by class and then by full LOINC name within class The print version does not include all of the LOINC fields Some of the longer fields float vertically The size of the printed page make it Page H 6 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 impossible to display all database fields in this file The following files are available either zipped and unzipped PKUNZIP v 2 04 or compatible required d ACCESS data base The LOINC database is also available as a ACCESS MDB file This database which is indexed
357. ership fees and meeting fees Meeting fees are used to cover the costs of running meetings including conference rooms lunches on site administrative staff and a substantial copying bill Historically meeting fees and costs have just about balanced out Membership fees are used to cover the cost of editing and distributing the documents conducting mail ballots producing the annual member directory and various informative activities including the HL7 Newsletter and information booths at trade shows HL7 also pays for software used by the Technical Committees to develop a data model HL7 sometimes provides meeting space to other standards groups at no charge so that their meetings can be co located with those of HL7 This has demonstrably improved the harmonization among the various standards efforts G 9 3 The HL7 Working Group G 9 3 1 How Do I Join the HL7 Working Group Contact the HL7 Administrative Headquarters G 9 3 2 Why Should Join the HL7 Working Group The main reason you should join the Working Group is to support the effort Membership fees are the primary source of funds that support the work of writing publishing and providing information about the Standard Joining as an individual members is the cheapest way to get a copy of the spec and the only way to get the implementation guide It is possible to buy the spec at the same price without becoming a member Some companies choose to join HL7 as a company in order
358. ersion 2 2 be ahead of vendor application software functionality in some cases There are vendors out there that already support new version 2 2 features They opted to make assumptions about the likelihood of the standard and went ahead and developed their 2 2 interfaces prior to the publication of the final specification With minor adjustments these vendors support version 2 2 although not necessarily for all messages and segments This will Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 4 HL7 Version 2 2 Overview make it very difficult to determine who supports or does not support version 2 2 it depends on the area Members should start to look for version 2 2 interfaces today However they should also determine whether they need version 2 2 today across the board At times version 2 2 will be ahead of vendors and at times vendors are ahead of version 2 2 Z segments will still be required with version 2 2 4 2 3 Control Query responses by Mark Shafarman 4 2 3 1 New Features 4 2 3 1 1 Organization of the chapter The former chapter 5 queries has been merged into chapter 2 The resulting text has been extensively reorganized and edited for clarity 4 2 3 1 2 Acknowledgments enhanced mode The HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments as well the conditions under whi
359. ersion 2 2 contains a ZIN segment effective 3 31 94 On 12 31 94 a version 2 2 interface requires additional insurance data This data is not related to the current insurance entity Create a ZIl segment and place the ZI1 segment after the ZIN segment for messages that require the additional data 3 Z segments may repeat on a particular message following the encoding rules El 4 Zsegments may be used on multiple messages A 4 13 Creating Z Messages Z messages are needed to convey information that does not have a trigger event or convey meaning as defined in the standard For example an interface may require transacting a message to indicate end of day closing the census It is possible for a Z message to be comprised entirely of standard segments If a defined segment exists that contains the data needed then this segment should be used Use standard HL7 procedures for indicating optional and repeating segments e g use delimiters for optional segment place holding Health Level Seven Implementation Support Guide Page A 97 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 14 Management of Z Data Management is needed to ensure that application areas don t define different segments with the same identifier and or don t define different segments with the same data A 4 15 Z Segment Form Section 1 Administrative Section To be completed by requester
360. ervation Date Time C TS QO Y 8 00242 Observation End Date Time TS Ge J 0 S 9 0043 Collection Voume Cool QO 9 O J 79 10 00244 Collector Identifier PEN 60 TC A4 4 S 11 00245 Specimen ActionCode ID D 0065 12 00246 DangerCode CBE 60 0 jp 13 00247 Relevant Clinical Info LL ST e III S 14 00248 Specimen Rev d Date Time C TS eo S 15 00249 SpeimnSouce LLN Q0 J Com 16 0026 Ordering Provider LL XCN 80 ol 0 5 S 17 00250 Order Callback Phone Numer XTN w Cc J 0 0 S 18 00251 PlacersField1 ST 60 5 S 19 00252 PlacersField2 TE ST TO Page B 28 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists 20 00253 FillerField ST TO L2 S 00254 Piller Meld 2 O ESE O E 22 00255 Results Rpt StatusChange C TS o 0 5 0 23 00256 ChargetoPractice JL CM on j S 24 00257 DiagnosticSemiceSect DD ID a P 7 25 00258 ReultSaus
361. erved Final Version 6 98 Length changed from 5 to 2 X Length changed from 2 to 1 Chapter 5 HL7 Version 2 3 Overview OBX 16 Responsible observer X Length changed from 60 to 80 data type changed from CN to XCN OBX 17 Observation method pope 5 3 8 Chapter 8 Master Files 5 3 8 1 Messages Segments MFR file MFN Patient location master MFK file MEN Charge description master MFK file MEN Clinical trials master file X MFK General M2 Numeric observation Description 3 Categorical Observations that require specimens Observation batteries Observations that are calculated from other observations Patient location master Location characteristic LRL Location relationship LDP Location charge code CDM CMO CM2 e 3 Q E HI E de e Page 5 30 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview 5 3 8 2 Data Elements Segment Seq MFI 2 Master file application identifier MRE 4 Primary key value MFE Primary key value STF Element name changed from Primary Key Value to Primary Key Value STF STF 2 STF 3 Data type changed from PN to XPN STF 4 Data type changed from ID to IS STF 5 Data type changed from ID to IS STF 6 Date time of birth Element name changed from Date of d M Birth to Date Time of Birth STF 10 Data type changed from TN to XTN STF 11 Dat
362. es Available from Dr Georges DeMoor Euclides Foundation International nv Excelsioriaan 4A B 1930 Zaventern Belgium Phone 32 2 720 90 60 P Mahon CR Manuselis G eds Textbook of Diagnostic Microbiology Philadelphia W B Saunders 1995 Stevens SS Measurement statistics and the chemapiric view Like the faces of Janus science looks two ways toward schematics and empirics Science 1968 161 849 56 walker RH American Association of Blood Banks Technical Manual 11th ed Bethesda MD American Association of Blood Banks 1993 Get JG Krieg NR Sneath JT Williams ST Bergey s Manual of Determinative Bacteriology Williams amp Wilkins Baltimore MD 1994 Page H 40 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Appendix A LOINC Database Structure Field Name Type Width 1 LOINC_NUM Char 7 2 COMPONENT Char 150 3 PROPERTY Char 10 4 TIME_ASPCT Char 10 5 SYSTEM Char 50 6 SCALE_TYP Char 30 7 METHOD_TYP Char 50 8 RELAT_NMS Char 254 9 CLASS Char 20 10 SOURCE Char 8 11 EUCLIDE_CD Char 10 12 ASTM_CD Char 9 Description The unique LOINC Code This is a numeric code with a mod 10 check digit The algorithm for calculating a mod 10 check digit is given in Appendix B Fields 2 7 contain the six parts of the name The fully specified name for a given LOINC code would be construc
363. es St Anybodys Medical Center requires that the architecture of the proposed system promote these objectives and facilitate the AIE s growth over time Describe in detail the AIE s architecture and why how it fits the St Anybodys Medical Center environment The description should include details on the scalability mirroring use of multiple processors and or multiple processes and how a distributed AIE may be implemented 1 ATE Architecture 2 Scalability 3 Mirroring 4 Processors 5 Distributed AIE Page F 28 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates F 1 7 6 Customer User Interface Front End Integration St Anybodys Medical Center desires a Common User Interface CUI for presentation to end users preferably in a graphical object oriented format If your product supports this concept by either providing the capability or by facilitating its development please complete this section Describe in detail how and in what module your system provides the following capabilities and facilities 1 Supporting specific types of end user devices e g workstations terminals PCs printers etc 2 Supporting common log in services e g the ability to use a single log in ID to access multiple application systems 3 Supporting menu services e g the ability to execute an application without requiring
364. es Department to select an application integrator that will allow the hospital to effectively and quickly interface multiple disparate information systems The primary scope of this proposal is to define evaluate and select an Application Interface Engine that performs the following objectives e Supports long term IS strategies laid out in the information technology plan e Provides system to system interfaces back end integration e Allows for adding and removing of applications and or platforms e Builds in redundancy of both hardware and software e Provides interface monitoring and management capabilities e Provides easy to use development tools e Provides a common user interface front end integration if possible F 1 3 2 Vendor Requirements Instructions 1 RFP Response 2 Please respond completely to Sections VI VII VIII and IX The majority of the questions in these sections require a narrative response Section IX contains the cost schedules Each section introduction specifies the required response format These instructions must be followed exactly Failure to respond in the format requested may be cause for elimination 3 Use of Vendor Proposal and Accompanying Material 4 All material submitted by the vendor becomes the property of St Anybodys Medical Page F 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved F 1 3 3 Appendix F Sa
365. es the next 1 Sends messages from Waits for operator message message log beginning with ESN in intervention MSA Or 2 Waits for operator intervention C 5 6 To Query for the ESN The reserved sequence number 0 is used to query the receiving system for its Expected Sequence Number ESN The sending system starts a query transaction by sending a message with a 0 zero in the Sequence Number field of the MSH segment MSH 13 The receiving system replies with a message which has its Expected Sequence Number an integer greater than zero in the Expected Sequence Number field of the MSA segment MSA 4 If the receiving system does not have an Expected Sequence Number it should return a 1 in the Expected Sequence Number field of the MSA segment MSA 4 In the event the receiving system returns a 1 in the Expected Sequence Number field of the MSA segment MSA 4 the sending system determines the Expected Sequence Number for the link Health Level Seven Implementation Support Guide Page C 27 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 5 7 To Synchronize the ESN The reserved sequence number 1 is used to synchronize the Expected Sequence Number of the receiving system The sending system starts a synchronization transaction by sending a message with a 1 in the sequence number field of the MSH segment MSH 13 The receiving system replies wi
366. escribing the interface between Application A Application B A to IE 3 Application A IE to A 6 HL7 Compliant HL7 Compliant A to B 1 IE to B 4 Interface Engine Application B B to IE 5 Product Name B to A 2 Product Name Hardware Hardware Protocol Protocol Product Name Hardware Checklist completed on Agreed to by Changes completed on Agreed to by Note the document Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved System A and B are used to designate the sender receiver in the message checklist section of Page A 3 Final Version 6 98 Appendix A HL7 Transaction Checklist A3 GENERAL INTERFACE DESCRIPTION A 3 1 Delimiters SYSTEM B ESA IAN PS EE CO EE A ERRECHEN Repetiton Separator gt Note The interface must still parse the incoming message for the delimiters These delimiters may differ in each individual message This section provides a mechanism for deciding on and documenting the various delimiters that will be used and identifying any related issues early e g conflicts with ASCII characters being used that have special meaning in EBCDIC A 3 2 Data Type Descriptions e Data Data Type Name Notes Format Application A Application B ype Post m H CO em OOS n H H Numerical CQ Composite quantity NM units
367. escription B s w Poo ss 9 00363 TransactionDesc Alt B ST 40 0 o 10 00364 Transaction Quantity pp NM D 11 00365 Transaction Amount Ext CP 2 III 12 00366 Transaction Amount Unit 2 P 0 0 13 00367 DepartmentCode CE 600 y 14 00368 InuranePlanIDD J l 600 on 15 00369 Insurance Amount CP D D 9 16 00133 Assigned Patient Location PL 80 ss 17 00370 FeeSchedule IS D 5 y 18 00148 PatientType dlrs o 205 0189 19 00371 DiagnosisCode CE 600 Jol A 4 LIED 20 00372 PerformdbyCoe LJ XON a UUE 21 00373 OrderedbyCode XeN a ss 22 00374 UnitCost n lel a j gt S 7 23 00217 FillerOrderNumber EL QD 7 24 00765 EnteredByCode LI LOCH a ss 25 00393 ProcedureCode CE o Leg NM AED GC ME CCLMS MEA AAA AAA AAA Page B 14 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 35 FTS File Trailer
368. esia code X DataTypechangedfromIDioIS PR1 11 Surgeon X Length changed from 60 to 120 data type changed from CN to SCN optionality changed from O to B repetition changed to Y Procedure practitioner X Length changed from 60 to 230 data type changed from CM to XCN optionality changed from O to B PR1 13 Consent code X Length changed from 2 to 60 data type changed from ID to CE pa ee PRI I5 l Associated diagnosis code X GTI 1 Set ID GTI X Element name changed from Set ID guarantor to Set ID GTI GT1 2 Guarantor number Length changed from 20 to 59 data type changed from CK to CX repetition changed to Y GT1 3 Guarantor name Data type changed from PN to XPN repetition changed to Y GT1 4 Guarantor spouse name Data type changed from PN to XPN repetition changed to Y GT1 5 Guarantor address Data type changed from AD to XAD repetition changed to Y ee repetition changed from Y 3 to Y repetition changed from Y 3 to Y GT1 8 Guarantor date time of X Length changed from 8 to 26 data type birth changed from DT to TS element name changed from Guarantor Date of Birth to Guarantor Date Time of Birth Guarantor sex E GTI O Guarantortype GT1 11 Guarantor relationship GT1 16 Guarantor employer name Length changed from 45 to 130 data type changed from ST to XPN repetition changed to Y GT1 17 Guarantor employer Data type changed from AD to XAD address GT1 18 Guarantor employer phone Data type changed from
369. esign specifications and responsibilities should be formally approved by all involved parties Develop Implementation And Testing Approach Define high level implementation and testing strategies This should be reviewed with all parties users resources etc This document should include all procedures processes criteria data and documentation to be used This approach will be finalized as part of the implementation phase of the project Define The Testing Methodology Approach Documentation required Procedures End user system performance response time parameters Test model Define Test Data Test data bases Test files Methods of test data creation Storage and recovery of test data Testing Software Aides Identify and apply as appropriate Emulators if required Editors Test data generators Test results comparer Dump facility Testing Environment Establish the following as appropriate e solate hardware e Use of live system e Location Health Level Seven Implementation Support Guide Page 3 5 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Chapter 3 Implementation Methodology 3 4 9 3 4 9 1 3 4 9 2 3 4 9 3 3 4 9 4 Testing Testing Support Identify resources and skills necessary for test team Assign as appropriate Use output from section 3 2 1 2 Identify Resources Test Conditions Outline the requirements for each possible condition to be test
370. esource Quantity JL NM OTS 7 00901 Resource Quantity Units CE ew Jo TI 8 01202 StartDate Time JC TS Q9 0 9 y 9 00891 Start Date Time Offset TC NM QO III TI 10 00892 Start Date Time Offset Units c CE ew 0 S 11 0083 Duration NM QO e 12 00894 Duration Units CE ew S 13 00895 Allow SubstitutionCode JC s a 4 Lu 14 00889 FilerStausCode Je ce ew URT Page B 2 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 4 AIL Appointment Information Location NEUE EE A A H EE n sn 2 00763 Segment ActionCode C ID D 206 3 00903 LocationResoureeID C PL 8 TI 3 9 4 00904 LocationType R CEJ om j 5 00905 LocationGroup CE om J o e 6 01202 Start Date Time C TS e III 7 00891 Start Date Time Offset C NM QO 4 8 00892 Start Date Time Offset Units C CE ew III 9 0083 Duration _ _ SS
371. essages may be encoded according to the Encoding Rules grouped in a file and transferred using external media FTAM FTP Kermit or any other file transfer protocol Responses may be grouped in a file and similarly transmitted Chapter 2 of the Standard provides the general mechanisms for the batch transmittal of HL7 messages 1 5 5 Relationship to Other Protocols A great deal of consideration has been given to the relationship between the HL7 Standard protocol and other protocols There are three questions 1 What is the relationship between the HL7 protocol and lower layer service protocols In strict accordance with the ISO OSI model HL7 should not replicate features of these protocols This can even be construed to require HL7 to avoid replicating certain ISO layer 7 functionality contained in the Service Elements However it is the goal of the HL7 group to support health care communications in a wide variety of communications environments including many that are not as complete as ISO will be one day 2 What is the relationship between the HL7 Standard protocol and other applications protocols Protocols of interest include the ASC X12 Standards for Electronic Document Interchange the ASTM 1238 88 Standards for laboratory data reporting the ACR NEMA DICOM Standards for imaging and other aspects of Radiology Information Systems the NCPDP standards for prescription drug programs and the IEEE P1157 Standards for medical data interch
372. est 3 2 2 4 Receive Software Development Test 3 2 3 Order Support Equipment 3 2 4 Receive Support Equipment 4 HARDWARE SOFTWARE INSTALLATION 4 1 Create Test Environments 4 1 1 Configure Interface Engine Test Environment 4 1 2 Install amp Configure Lab Test Environment 4 1 3 Setup test beds data 4 2 Site Preparation Pilot repeat this set for all test and production environments 4 2 1 Location of Server 4 2 2 UPS 4 2 3 Phone line for modem 4 2 4 Network Connectivity 4 2 5 Order Unix hardware Software 4 2 6 Receive Unix Hardware Software 4 2 7 Install UNIX System 4 2 7 1 Unpack and Setup system 4 2 7 2 Install any all SBUS expansion cards Page F 62 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 4 2 7 3 Install peripherals Tape drives CDROM 4 2 7 4 Load Solaris OS 4 2 7 5 Partition all Disk Sub systems 4 2 7 6 Add User Login Accounts 4 2 7 7 Install Paging Software for Operations Personnel 4 2 7 8 Connect Unix to Network 4 2 8 UNIX Software Configuration 4 2 8 1 NIS 4 2 8 2 Automounter 4 2 8 3 Dial up out maintenance modem 4 2 8 4 FTP 4 2 8 5 PCNFS daemon 4 2 8 6 C C Compiler 4 2 8 7 Version Control Software 4 2 8 8 Application software 4 2 8 9 Utilities 4 2 9 Licensing of Relational Database Product 4 2 10 UNIX Environment Setup 4 2 10 1 Add User Logon IDs 4 2 10 2 Setup
373. ete block Timer D Inter block Timer Timer D serves to prevent a station from hanging in slave mode Timer D is started when entering slave mode and restarted after replying to each block Timer D is stopped upon receipt or transmission of EOT When timeout occurs 1 Return to control mode Timer E Line Check Timer Timer E triggers a check of the communications link when neither station has requested to be master for some time Timer E is reset whenever a transmission is sent or received When timeout occurs 1 The station triggers a bid for the line The line may be released as soon as master slave is established If no response is received when bidding for the line the normal mechanism using Timer A will report problems with the communications link C 3 6 2 Recovery Procedures Recovery procedures are system guidelines that should be used by all stations as applicable However it is recognized that the detailed method of station mechanization absolute value of timers etc may vary with applications and communication facilities Recovery procedures should be implemented that eliminate operator intervention wherever possible When a timeout invalid or NAK response to a transmitted block is received the master transmits the block again This may occur up to L times The recovery procedure after L unsuccessful retransmissions 1 Notify the operator or the processor program or both 2 Transmit EOT to end the ma
374. f narrative NAR Many clinical LOINC codes will come in two versions one for the nominal coded version and one for a narrative free text version We strongly encourage all reporting to be at the most granular level of detail That is if three numbers are reported they would each be reported under a unique LOINC code and transmitted in a separate HL7 in separate OBX segment Occasionally reporting systems are not able to comply with this dictum For example some chromatography instruments Page H 28 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 can identify chemicals from the entire spectrum of known chemicals CAS identifies more than 10 million distinct chemicals and we may not have specific LOINC codes for reporting out these details We have designated the scale of MULTI to identify results that include many separately structured results as one text glob with or without imbedded display formatting Some laboratories report all of the details of many multiple measure tests under such globs with test names that correspond to their order name We strongly discourage such reporting It defeats the very purpose of individual codes to tag content Table 12 Type of Scale Type of Scale Abbr Description Quantitative QN The result of the test is a numeric value that relates to a continuous numeric scale Reported eit
375. f terms used in veterinary medicine have been included and more are planned for the near future In addition the scope includes those non test measurements that are commonly required to interpret test results and are usually included as part of the report with the laboratory observations Examples include for cervical pap smears the phase of menstrual cycle use of estrogens for arterial blood gases inspired dioxygen for drug concentrations used in pharmacokinetics the dose for a blood bank the number of units dispensed ow v v The clinical portion of the LOINC database covers the areas of blood pressure heart and respiratory rates critical care measures cardiac output body dimensions body temperature intake and output electrocardiography obstetric ultrasound urologic ultrasound and the major headings of history and physical discharge summary and operative note reports Work on gastroenterology mechanical ventilator management and obstetrics is underway To each name we have assigned a unique permanent code that we call the LOINC code This is the code that systems should use to identify test results in electronic reports The LOINC code has no intrinsic structure except that the last character in the code is a mod 10 check digit The algorithm to calculate this check digit is given in Appendix B All of the structure associated with a single LOINC entity is stored in other fields in the LOINC database 2 Major Parts of a Test
376. frame number of the block being acknowledged Upon detecting the appropriate ACKN the master station may either transmit the next block 7 or initiate termination 9 if the last block ended in ETX BCC 6 b Ifthe received BLK character is lower than expected a duplicate block has been received The receiver discards the block and sends the optional prefix followed by ACKN when ready to receive another block 2 NAK a Ifthe transmission block was not accepted and the slave station is ready to receive another block it sends a NAK 10 Upon detecting a NAK the master station initiates retransmission of the last transmission block 11 7 L retransmissions may be made after which the master station exits 12 to a recovery procedure b Ifthe received BLK character is higher than expected the receiving station discards the received transmission block and sends an optional prefix followed by NAK when ready to receive another block The use of NAK does not alter the sequence of acknowledgments The same affirmative reply ACKO through ACK7 is used for a successful retransmission as would have been used if the previous transmission of the unaccepted block had been successful If the numbered reply indicates that the slave station missed the outstanding block receipt of ACKn 1 instead of ACKn the master station initiates retransmission of that block as if the slave station had returned a NAK A message frame is acknowledged as soon
377. gene ees B 52 B 1 90 RXO Pharmacy Prescription Order B 53 B191 RXR Pharmacy ROU cose eique IY ROM euo des qui evite rud EE B 53 B 1 92 SCH Schedule Activity Informations sese sees a B 54 B 1 93 SPR Stored Procedure Request Definition esee B 55 B 194 STF Staff Identification eenen n e aedo na E B 55 B 1 95 TXA Transcription Document Header B 56 Bal OG UBL UB82 Data a B 57 I AD 7 BZ ER B 58 B 1 98 URD Results Update Defnpons eese eene B 58 B 1 99 URS UnsGhcited le e de o o edo B 59 B 1 100 VIO Virtual Table Query Request Ains B 59 B 1 101 Z Z segment Hospital PEC A B 59 Page TOC 14 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Table of Contents HL7 Implementation Support Guide B 2 APPLICATION INTEGRATION MATRIX essere nennen nennen B 60 APPENDIX C LOWER LAYER PROTOCOLS Cl INTRODUCHON Ee C 1 C2 HYBRID LOWER LAYER PROTOCOL s eeeeeeeeeeenee tnnt neen teen enne tenerent C 1 2 1 Introducir tos C 1 L IE ear and Ee C 1 e e ONVENTONS EE C 2 ES MN BVO CMS Tcr C 2 2 3 Processing Rules cari ARE ORE EA QU E RU AE RUINA SES Deae o tH CHR ER EEN C 3 C 2 3 1 Optional Connection and DiISconnection sss sese sese eee eee eee C 3 2 3 2 Imitating and Responding o oce e qoos tides ae rne ble Eye EAE AR REI Mea C 4 C24 Carriage Return Stuffing isis eoo ee o GR IU ANDERES EE edd eet C 5 22 5 How Through
378. gnin ea e n a E E a EE ao A tea 2 1 1 Project Timing And Sequence eic eee ieai iie aa 2 12 HET Transiion Strategy acie aati ee Sette al eS E Eai 2 7 2 1 Establish An Overall Transition Flam eee ae 2 7 2 2 Determine Interface Environment sss sees e eee iii Z8 COS BENE ANALYSIS diets tutti pt poi idees DENM OI qc 2 8 1 1 Operatmmg Maintenance Costs sss i dete vei A neci E Ced auda Page TOC 2 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Table of Contents HL7 Implementation Support Guide 2 8 1 2 One Time And Ongoing CORS 2 8 2 9 2 Benefits E 2 9 E ge EE 2 9 2 9 VENDOR EVALUATION AND SELBOTION eese enne nnne 2 9 2 9 17 Evaluation eT e TTT 2 9 2 9 1 1 Assess Need For Assistance s csssicc cscedistasdacrisuscacivenisdaaaiussaesstanscaeaesdnartessaceesbace 2 10 2 9 1 2 General Vendor Evaluation Selection di 2 10 29 De DR eh 2 10 2 9 21 Vendor s EX perience miranda e A N ae Hen det 2 10 21072 EE 2 11 2 9 2 3 Software Modification Review sese ee 2 11 CHAPTER 3 IMPLEMENTATION METHODOLOGY Salk INTRODUCTION ee Ee Ee EE 3 1 32 INTERFACE IDE VEL OPMEIN DT E 3 1 32l Project EE 3 1 32A AN Identity TASKS EE 3 1 3 2 1 2 Identify TE 3 1 Sou Develop EE 3 2 3 2 1 4 Review Revise Internal Standards ir 3 2 3 21 5 Attend Interface Engine Tratetng sss sese eere eee eee 3 2 3 3 FUNCTIONAL DESIGN sei ir 3 2 o3 Develop Interface Deser
379. gories to make it easier to find general areas of interest It is divided into two main categories lab and clinical This split is recorded in Field 38 CLASSTYPE The laboratory portion of the LOINC database contains the usual categories of chemistry hematology serology microbiology which includes parasitology and virology and toxicology we also have categories for drugs and the cell counts you would find reported on a complete blood count or a cerebrospinal fluid cell count We have separated antibiotic susceptibilities into their own category The clinical portion of the LOINC database contains entries for vital signs hemodynamics intake output EKG obstetric ultrasound and other clinical observations Table 18 in Appendix A lists all of these classes in detail There is nothing sacred about these categories You will be able to sort the database by whatever class is convenient for your application when you get the electronic version We have defined fields in the database for a number of data elements e g typical units sample normal ranges but most of those fields are not yet filled in In a few cases we have suggested standard answer lists for tests whose results are usually reported as codes The database is an ongoing project We have established guidelines for users who wish to request additions and changes to LOINC which are detailed in Appendix C For some kind of tests and observations the database provides several ways
380. h Units CE 60 7 9 S 19 01129 Substance LotNumber ST OY 20 01130 Substance ExpirationDate TS Ge OY 21 01131 Substance Manufacturer Name CE w 2 5 S 22 01123 Indicaion CE ew CTT B 1 90 RXO Pharmacy Prescription Order Len Max Sender Variable Receiver Variable 1 00292 Requested Give Code R CE aw Page B 52 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists g 10 11 12 14 00305 Ordering Providers DEA C XCN 60 15 00306 Pharmacist Verifier ID LC XCN 60 16 00307 Needs Human Beien IL ID D 17 00308 Requested Give PerTime C ST o 18 01121 RequestedGive Strength NM QO 19 01122 Requested Give Strength Units CE 60 f 20 01123 Indication CET Q0 CT pp 21 01218 RequestedGive Rate Amount ST III S 22 01219 Requested Give Rate Units CE en ITT E AAA EA EA AAA IO CTN pM EA EA AAA AAA B 1 91 RXR Pharmacy Route 1 00309 Route R CE 00 0162 32 1 00810 Se E D QUE 60 1 Roo AOS 3 00311 AdministrationDevice CE 60
381. hase A 4 5 8 C06 Cancel Patient Entering a Phase CRM Originator A or B Message Header Patient Identification Patient Visit Clinical Study Registration Clinical Study Phase A 4 5 9 C07 Correct Update Phase Information CRM Originator A or B Message Header Patient Identification Patient Visit Clinical Study Registration Clinical Study Phase A 4 5 10 C08 Patient Has Gone Off Phase of Clinical Trial CRM Originator A or B Message Header Patient Identification Patient Visit Clinical Study Registration Clinical Study Phase Page A 54 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 5 11 C09 Automated Time Intervals for Reporting CSU Originator A or B Message Header R Patient Identification R Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Clinical Study Registration R Clinical Study Phase Clinical Study Data Schedule Common Order Observation Battery R Observation Results Common Order Pharmacy Administration Pharmacy Route A 4 5 12 C10 Patient Completes Clinical Trail CSU Originator A or B Message Header R Patient Identification R Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Clinical Study Registration R Clinical Study Phase Clinical Study Data Sched
382. hat consist of HL7 and non HL7 formats What other standardized interface templates are provided within the AIE For each interface standard include a list of versions supported a ANSIX 12 b DICOM c Other Interface Standards What database capabilities are resident in the engine e g loader acknowledgment database etc What tools are available Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates F 1 7 8 Data Repository Clinical Database The AIE might be a vehicle for populating a clinical data repository This repository will collect information from existing St Anybodys Medical Center systems and disseminate the information in a format defined by an end user The database will reside on another processor or system on the enterprise network with Systems feeding information to it in a common data formal If your product supports this concept by either providing the capability or by facilitating its development please complete this section The database will consist of communications hardware system and database software to gather patient demographic information and clinical data or St Anybodys Medical Center users Describe in detail any features and or functionality that could be used to populate a data repository e g a clinical data repository and identify in what modules they reside F 1 7 9 Admi
383. he Working Group has devised a format for the HL7 Standard that is relatively independent of the encoding rules chosen and easily translated into the ASN 1 notation The transactions defined in this manner should be directly transferable to the MEDIX effort and transaction messages encoded using the HL7 scheme should be translatable to transactions encoded using the BER This should facilitate the creation of gateways between HL7 and other protocols In addition HL7 and MEDIX have agreed on a course for convergence This will occur within the HL7 Abstract Message definitions MEDIX has further agreed to use the HL7 abstract message definitions as defined in V2 1 as a starting point for the MEDIX message definitions HL7 X12 NCPDP and IEEE are ANSI approved standards developers and Versions 2 2 and 2 3 of the HL7 Standard have been balloted as ANSI standards 1 5 5 3 Proprietary Protocols With relation to proprietary protocols the HL7 Standard is regarded as a migration path The Working Group recognizes that migration requires effort and that migration of all interfaces to HL 7 at a particular facility may reasonably be accomplished in steps rather than implementing an all or nothing approach at a particular point in time Health Level Seven Implementation Support Guide Page 1 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapier 1 Introduction 1 6 REFERENCE DOCUMENTS This section is an e
384. he approach to accommodating intra site variations and evolutionary changes and the way it has been structured in order to accommodate varying current and future communications environments 1 5 1 HL7 Encoding Rules Message formats prescribed in the HL7 encoding rules consist of data fields that are of variable length and separated by a field separator character Rules describe how the various data types are encoded within a field and when an individual field may be repeated The data fields are combined into logical groupings called segments Segments are separated by segment separator characters Each segment begins with a three character literal value that identifies it within a message Segments may be defined as required or optional and may be permitted to repeat Individual data fields are found in the message by their position within their associated segments All data is represented as displayable characters from a selected character set The ASCII displayable character set hexadecimal values between 20 and 7E inclusive is the default character set unless modified in the MSH header segment All the other special separators and other special characters are also displayable characters except that the segment separator is the ASCII Carriage Return character 1 There is nothing intrinsic to HL7 Version 2 3 or ASTM 1238 that restricts the legal data set to the printable ASCII characters The former restriction was imposed to accommodate the
385. he combination of component analyte and type of system sample that are commonly reported In practice laboratories include a relatively small range of sample types in the their test names Chemical tests commonly distinguish between serum urine blood and cerebrospinal fluid Microbiology cultures tend to distinguish between a greater number of sources The list in Table 10 was defined for reporting sample type in a field of the HL7 ASTM message that is quite independent of the test measure name and we do not imply that all such types will find their way into distinct LOINC names However when a distinction by type of system is required in the name it should be represented by one of the codes given in Table 10 Health Level Seven Implementation Support Guide Page H 25 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC When should we lump a variety of specimen types under the unspecific code FLU and when we should give a body material its own unique name for a given component The decision depends upon the degree to which laboratories have reported the system component pair as a separate result and the degree to which the normal ranges for a given component system have been standardized By this rule we will always define different tests for serum and for urine when a component can be measured in both We define sweat sodium as a distinct test because it is a standardized test used to diagno
386. he naming structure is an exact analogous structure to that of chemical challenges A test for glucose after 12 hours of an energy fast would be represented as GLUCOSE BS POST 12H CFST MCNC PT SER QN In all physiologic challenges fasting fluid deprivation the duration of the physiologic challenge must be stated A test for osmolality after fluid restriction would be OSMOLALITY POST 12H FFST OSMOL PT UR QN A test for triglyceride after an 18 h for energy fast would be TRIGLYCERIDES TOTAL POST 12H CFST MCNC PT SER QN Two durations can appear in one specification e g CORTISOL 1 5H POST 0 05 0 15 U INSULIN KG IV POST 12H CFST MCNC PT SER QN Our rules for naming challenge tests work well only when there is a single intervention followed by a test for one or more components over time Complex challenge tests involving more than one intervention or complicated sampling techniques need a unique name but the name may not be a complete description of all of the test parameters 2 2 2 3 Reporting characteristics of challenge as separate observations Because we cannot anticipate every type of challenge and route of administration and because some challenge tests have no usual dose some challenge tests will not contain a dose Challenge observations that do not include a specific dose in the name have the word DOSE where a numeric dose would otherwise appear The general form is lt analyte gt lt time gt post dose route Examples GLUCOSE 1H
387. he time delay substance of challenge amount administered and route of administration and 3 any standardization or adjustment The three subparts of the first part follow this syntax lt analyte subclass sub subclass gt lt time delay post amount substance route gt adjustment In the above syntax the carat is a required delimiter and the dot separates the analyte name from its subspecies This convention also implies that dots and carats cannot be a formal part of any of the words that are connected by these delimiters These subparts are described in greater detail below Sections 2 2 1 through 2 2 3 2 2 1 Analyte Name 1st subpart The first subpart names the analyte including any relevant sub classifications separated from the main analyte name by dots 2 2 1 1 Class Subclass Sub subclass The principal name the first subpart can be divided further by subclass e g calcium II is one component calcium ionized is another test that measures a subclass of calcium Subclasses are separated by dots Bound and free and bioavailable components ionized and unionized components and antibody subtypes are all subclasses Note that bio available is distinguished from free by including both free and partially bound moieties Use total as a modifier sparingly in in denominators of mass and substance fractions e g the fraction of Prealbumin over Protein total If the antibody is from a
388. hecklists 13 01047 Stratum for Study Randomization CE Q0 CT 4 Jp 14 01048 Patient Evaluability Status C CE 60 15 01049 Date Time Ended Study C TS o III S 16 01050 ReasonEndedStudy C CE oO B 1 19 CSS Clinical Study Data Schedule 1 01055 StudySchedued Time Pan R CE 60 J Jj Jj 2 01056 Study Scheduled Patient Time Point TS eo III 3 01057 Study Quality Control Codes_____ R CE 60 CTT B 1 20 CSP Clinical Study Phase 1 01051 Study Phase Identifier LK CE 60 2 J 9 0 4 2 01052 Date Time Study Phase Began R TS o 4 3 01053 Date Time Study Phase Ended TS o ss 4 01054 StudyPhaseEvaluability C CE 609 III B 1 21 CTI Clinical Trial Identification 1 01058 Sponsor Study Identifier R EI 60 II 0 2 01051 Study Phase Identifier C CE 60 4 Z2 S 3 01055 Study Scheduled Time Report CE en ITT B 1 22 CTD Contact Data Reps 1 0155 Role R CE Q0 l po ec 2 01165 ContactName XPN a Cl S 3 01166 ConatAddes XAD 600 Jj Q34 J 9 4 01167 ContactLocation
389. her as an integer a ratio a real number or a range The test result value may optionally contain a relational operator from the set lt lt gt gt Valid values for a quantitative test are of the form 7 7 7 4 7 4 7 8912 0 125 lt 10 lt 10 15 gt 12000 1 10 1 256 Ordinal ORD Ordered categorical responses e g 1 2 3 positive negative reactive indeterminant nonreactive Previously named SQ Quantitative or ORDQN Test can be reported as either ORD or QN e g an antimicrobial Ordinal susceptibility which can be reported as either resistant intermediate susceptible or as the mm diameter of the inhibition zone Previously named SQN Nominal NOM Nominal or categorical responses that do not have a natural ordering e g names of bacteria reported as answers categories of appearance that do not have a natural ordering e g yellow clear bloody Previously named QL Narrative NAR Text narrative such as the description of a microscopic part of a surgical papule test Multi MULTI Many separate results structured as one text glob with or without imbedded display formatting 2 7 Type of Method 6th part The method by which the test was performed is the sixth part of the test name Methods need only be expressed as part of the name when they provide a distinction between tests that measure the same component analyte but which have different clinical significance
390. hics Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Patient Diagnosis Diagnosis Related Group Procedures Role Guarantor Next of Kin Insurance Insurance Additional Info Insurance Cert Info Accident Information Universal Bill Information Universal Bill Information Message Header Event Type Patient Identification Additional Demographics Patient Visit Disability Information Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Originator A or B Originator A or B Page A 49 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 4 3 P03 Detail Financial Transaction DFT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Financial Transaction Procedures Role Diagnosis Diagnosis Related Group Guarantor Information Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information A 4 4 4 P04 Generate Bills and A R Statements QRY Originator A or B Message Header Query Definition Query Filter Continuation Pointer Page A 50 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL
391. his was not feasible because many of the apparent differences in method obtained with the standard samples were artifacts of the sample matrix and did not apply to serum specimens In addition the variation among laboratories was often of the same magnitude as the variation among methods within laboratories for the same method We do not mean to underrate the importance of method differences The result message will still include information about the normal range for that particular test the source laboratory and if the laboratory wishes specific information about the method e g OBX 17 can carry very specific method information However such information is reported in separate fields in the HL7 message It is not embedded in the names of the test We have a cooperative agreement with CAP and SNOMED to provide copies of the LOINC codes and names for distribution with the SNOMED codes in the P3 AXIS The LOINC committee will continue to have editorial control and to distribute the LOINC database via the WG SNOMED and add hierarchies to the LOINC data base 13 Scope of this document The current scope of the existing laboratory portion of the LOINC database includes all observations reported by clinical laboratories including the specialty areas chemistry including therapeutic drug monitoring and toxicology hematology serology blood bank microbiology cytology surgical pathology and fertility In the most current release a modest number o
392. hould be outlined 2 5 2 3 Assess Need For Integration Tools Perform a preliminary assessment of the need for integration tools based on user technology requirements technical strategy communications strategy and communications protocols Factors to consider at this point are obvious obstacles to integration e g legacy vendor does not support HL7 2 5 2 4 Evaluate Cabling Options Consider and evaluate various physical cabling options e g fiber coaxial twisted pair Select one or more based upon user needs technology requirements and transaction volumes 2 5 2 5 Define Network Management Requirements Define responsibility for network management and control Also identify the approach for data storage e g centralized decentralized along with controls for ensuring data integrity 2 5 2 6 Identify Communications Hardware Software Identify and document all of the necessary additional communications components This may include network adapter cards wiring hubs bridges routers repeaters additional cabling or specialized communications servers 2 5 2 7 Identify Character Translation Requirements Identify character translation requirements e g ASCII to EBCDIC 2 6 ORGANIZATION STRATEGY The purpose of this section is to ensure the organization has been adequately prepared for any changes implied by the new systems Additionally this section provides for considerations related to the design and implementation project
393. hurston Qing Zeng World Health Organization ARUP Laboratories Columbia Presbyterian Medical Center Geneva Switzerland Salt Lake City UT New York NY Jeff Suico Wayne Tracy Angelo Rossi Mori Regenstrief Institute Health Patterns LLC Istituto Tecnologie Biomediche Indianapolis IN Overland Park KS Rome Italy Blaine Takesue Margaret Vaughn Frank Stalling Regenstrief Institute Partners HealthCare System Inc Dallas ISC Dept of Veterans Affairs Indianapolis IN Boston MA Grand Prairie TX Anders Thurin University Hospital Linkoping Sweden Health Level Seven Implementation Support Guide Page H 9 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC 1 Goals The goal of this project is to create universal identifiers names and codes to be used in the context of existing ASTM E1238 HL7 CEN TC251 and DICOM observation report messages employed in the various subdomains of healthcare informatics such as Clinical Laboratory Information Management Systems and Computer Based Patient Record Systems Specifically we want to create identifiers that can be used as the coded value of the Observation Identifier field 3 of the OBX segment of an ORU HL7 HL7 Vs 2 2 and 2 38 or ASTM 1238 94 message or in a similar context in future versions of these HL7 ASTM standards The LOINC codes will be identified in HL7 as code system LN The ultimate goal is that these universal identifiers
394. ial transaction QRY DSP Generate bill and A R statements BAR ACK Update account BAR ACK End account Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists PEX Unsolicited initial individual product experience report PEX Unsolicited update individual product experience report SUR Summary product experience report PPR PC Problem Add PPR PC Problem Update PPR PC Problem Delete PRQ PC Problem Query PRR PC Problem Response PGL PC Goal Add PGL PC Goal Update PGL PC Goal Delete PGQ PC Goal Query PGR PC Goal Response PPP PC Pathway Problem Oriented Add PPP PC Pathway Problem Oriented Update PPP PC Pathway Problem Oriented Delete PTQ PC Pathway Problem Oriented Query PTR PC Pathway Problem Oriented Query Response PPG PC Pathway Goal Oriented Add PPG PC Pathway Goal Oriented Update PPG PC Pathway Goal Oriented Delete PTU PC Pathway Goal Oriented Query PTV PC Pathway Goal Oriented Query Response Health Level Seven Implementation Support Guide Page B 65 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists QRY DSR Query sent for immediate response QRY QCK Query sent for deferred response DSR ACK Deferred response to a query UDM ACK Unsolicited displ
395. ic Related Group CE 9 SSS men 9 00383 DRG Approval Indicator o 0 o T o T 10 00384 DRG GrouperReviewCode I5 o SS 1 098 Outlier Type E 9 L1 998 12 0086 Owirbas NM o A O O Too o To 13 0087 Owiercot per D 0 LI 14 00388 GrouperVeminandTpe ST nm Ill 15 00389 DigmosyDRGPioty NM o Ill 16 00390 Diagnosing Clinician x en T HS 17 00766 Diagnosis Classification I o H HS 18 00767 Confidential Indicator 1 Tb o SSS Page B 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists 19 00768 Attestation Date Time TE TS Q6 III 0139 B 1 25 DRG Diagnosis Related Group 1 00382 Diagnosis Related Group CE 60 0055 2 00769 DRG Assigned Date Time TS e J 5 3 00383 DRG Approval Indicator ID 0136 4 00884 DRG Grouper Review Coe IS 2 2 5 0085 Outlier Type l 600 S 3 6 0086 OutlierDays m J9 Lh 7 7 0087 OutlierCost LEI D j 8
396. ident data Communicate associated financial management master file data PATIENT CARE Karen Keeter IBM Global Healthcare Solutions Ph 770 835 7945 Fax 770 835 7972 Email kkeeter us ibm com Tom Marlin Spacelabs Medical Inc Ph 425 867 2129 Fax 425 771 5768 Email tomm slmd com Tim Snyder Productivity Innovations Inc Ph 406 586 2347 Fax 406 586 4869 Email t_snyder avicom net Mission The goal of Patient Care is to define messages to support the needs for communicating information regarding the creation management execution and the quality of diagnostic and therapeutic care Page 1 16 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 1 Introduction Projects The scope for Patient Care is a subset of the healthcare delivery and management processes The scope includes activities related to assessing and evaluating the patient member establishing the diagnosis problem developing and managing a plan of care service action administering care or treatment based on the plan documenting the administration of the plan of care managing compliance and exception reporting and reporting of clinical results outcomes The scope also includes the development and maintenance of standardized pathways protocols as well as support for concurrent retrospective quality and or outcomes analysis and management The scope includes the abi
397. ient Visit Patient Visit Additional Info Disability Information Health Information Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Originator A or B Originator A or B Page A 21 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 2 18 A18 Merge Patient Information ADT Originator A or B Retained for backward compatibility Message Header Event Type Patient Identification Additional Demographics Merge Information Patient Visit A 4 2 19 A19 Patient Query QRY ADR A 4 2 19 1 QRY R R R R Originator A or B Message Header Query Definition Query Filter A 4 2 19 2 ADR MSA ERR QRD QRF EVN PID PD1 NK1 PV1 PV2 DB1 OBX AL1 DG1 DRG PR1 ROL GT1 Page A 22 Final Version 6 98 Message Header Message Acknowledgment Error Query Definition Query Filter Event Type Patient Identification Additional Demographics Next of Kin Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information
398. ife of the AIE Phases of installation after Categories I through III will be determined by the business needs of St Anybodys Medical Center Sizing should focus on the first three categories but information regarding future growth implications should be included Guidelines for cost information are included in Section VIII F 1 5 2 1 Interface Categories Future interfaces have been categorized by the impact their implementation will have on St Anybodys Medical Center processes Categories I through III represent a phased implementation of the AIE Category IV lists interfaces that St Anybodys Medical Center recognizes a need for but has not yet addressed a Category I Interfaces b Interfaces included in the first category should be completed in the first 90 120 days of implementation They include the following c Category II Interfaces d Interfaces included in this category are expected to be completed in phase 2 within 120 150 days of implementation They include the following e Category III Interfaces f Interfaces included in this category are expected to be completed in phase 3 within 150 180 days of implementation They include the following e Downloads to Magnetic Media g Category IV Interfaces h These are interfaces that are known to be necessary in the near term but have not been analyzed and designed The time frames for implementation are also yet to be determined They include the following F 1 5 2 2 Data Interaction Mat
399. ifications of a basic method are named using a lt basic gt lt modification gt syntax e g METHENAMINE SILVER STAIN JONES 2 7 1 DNA RNA probes measures We will distinguish three kinds of DNA probe methods Probe without amplification Probe with signal amplification PROBE AMP SIG See Table 14A for a list of methods that would be identified as PROBE AMP SIG in a LOINC method Probe with target amplification PROBE AMP TAR See Table 14B for a list of methods that would be identified as PROBE AMP TAR in the method part of the LOINC term Page H 30 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Table 14A Examples of specific methods that would be classed as target amplified DNA RNA not an exhaustive list PROBE TAR AMP includes nucleic acid signal amplification and probe PCR Polymerase Chain Reaction Applies to DNA RNA Roche Molecular Systems thermal cycler Requires repeated cycles of heating and cooling each cycle doubles the target Transcription Mediated Amplification Applies to DNA RNA Genprobe Inc isothermal Nucleic Acid Sequence Based Analysis Applies to RNA DNA Organon Tenika Corp isothermal Strand Displacement Amplification Applies to DNA Beckon Dickenson isothermal Ligation Activated Transcription 3 Self Sustaining Sequence Replication Applies to RNA DNA Bartel s Diagnosti
400. ilty ST QO III 7 00087 BatchCreaionDat Tim TS Ge 0 8 00088 Batch Security LEI w LI 7 9 00089 BachNam ID Tye ST QO 9 39 9 10 00000 BatchComment ST 80 ss 11 0001 BatchControlID Cer on j 0 S 7 12 00092 Reference Batch Conr ID ST ou B 1 12 BLG Billing 1 0034 WhentoCharge CM Com 2 00235 ChargeType CT SO 0122 3 00236 AccountID EK oy Page B 6 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 13 BTS Batch Trailer 1 00093 BatchMessageCount ST L 2 00094 BatchComment ST 80 Ys 3 00095 BatchTotals Cal aw CTT y B 1 14 CDM Charge Description Master 1 001306 PrimryKeyValue CDM R CE ew UIT 2 00983 ChageCodeAis CE e 20 G 9 0 0 S 9 3 00984 Charge Description Short R ST QO 9 S 4 00985 ChageDesritinLog ST ew II S 5 00986 Description Override Indicator IS D f 0269 6 00987 ExplodingCharges LCE 600 CTT 9 7 00988 Proedue
401. implemented HL7 interfaces to share their lessons learned in the form of helpful hints D 2 VENDOR NEGOTIATIONS FOR HL7 INTERFACES Contributed By Patricia Burtchaell Programmer Analyst Deaconess Billings Clinic Health Center Billings Montana Phone 406 657 3824 Fax 406 657 3872 As our involvement with interfacing multiple computer platforms within DBCHS grows we have recognized the need to document suggestions to be considered when negotiating with vendors for future interfaces The following suggestions are based on past experience and may or may not apply when implementing future HL7 interface s or any other proprietary interface s If the interface or interfaces are to be HL7 during contract negotiations HL7 message definitions should be reviewed and agreed upon The version of HL7 should be agreed upon as well as provisions to migrate to any new versions in the future with the intent to stay as current as possible In addition to stating compliance to HL7 an agreement should be made that the final interface will be in accordance to customer specifications as HL7 is prone to variation It is also important to discuss the content of the data elements with the vendor so they cannot come back at a later date and refuse to accept a certain field due to database incompatibility Lower layer data transmission protocols such as TCP IP need to be decided on at time of contract negotiation An agreement needs to be reached as to who
402. in Version 2 3 is a key criterion Also whether the additional information in the extended segments is essential for the functionality of downstream systems Finally in an enterprise scenario where guarantors and insured persons are populated in the enterprise the extended segments in HL7 2 3 facilitate better person information to the enterprise The GT1 and IN1 segments now contain identifiers for the person similar to PID 3 Master Files responses by Mark Shafarman What was the driving force behind the creation of version 2 3 In comparison with version 2 2 what advantages does it offer Chapter 8 provides updates to 2 2 master files and includes some new master files Are there any functional issues that should be addressed prior to implementing this chapter You should implement Version 2 3 if your users need the new functionality The primary implementation issues are not in backwards compatibility because most new information is just that new and the 2 3 backwards compatibility clarified definition covers how to interpret those areas where it is an issue Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview 5 3 SUMMARY BY CHAPTER OF CHANGES FROM VERSION 2 2 TO 2 3 5 3 1 New Tables The chart below lists all tables new with Version 2 3 Alternate character sets 0240 Event consequence 0243 Ident
403. ing migration and access approaches 3 4 13 Conduct Review And Obtain Acceptance For Functional Performance Page 3 6 Document and present for approval the entire functional performance specification including End user response time Data integrity data flow Availability User access acceptance Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved 3 5 Chapter 3 Implementation Methodology PROGRAM DEVELOPMENT The following section applies to those persons involved with program development Program development should begin only after the technical design has been completed and approved The development serves to provide the actual program code used for the interface and also to provide documentation that accurately reflects this code If any interface engine is being installed it includes the development of site specific configuration and supporting documentation Documentation though often overlooked is an important tool for both supporting and upgrading your system Alter documentation to reflect any program changes 3 5 1 3 6 3 6 1 3 6 1 1 3 6 1 2 3 6 2 Program Architecture Develop an overall program architecture to identify all the functions of the program This will be used for the detailed design of the program The design may indicate multiple modules subroutines to handle specific functions Use the design documents generated i
404. ing information about HL7 Mark McDougall of this firm is the Executive Director of HL7 In this role he reports to the Executive Committee Page G 16 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix G Frequently Asked Questions The Executive Director and his staff have no role whatsoever in determining the content of the HL7 standard G 9 2 7 How are HL7 Standards Written Balloted and Published Technical committees write draft chapters During this process the chapter chair will normally use votes of those present in a meeting to decide upon draft contents and provide good order These are approved by a mail ballot by the HL7 Balloting process defined below The ballot group is not limited to members of the committee Any HL7 member can register an interest in the work of any committee and will be offered the opportunity to vote by mail without any need to attend any meetings In a response to a ballot a member may vote affirmatively affirmatively with minor suggestions negatively with minor suggestions or negatively The Technical Committee is required to respond to all negative votes Frequently they contact the person who provided the negative ballot in order to discuss the issue The committee s response to the negative ballot may be any of these e n response to the negative vote we have decided to amend the chapter and resubmit it to ballot
405. ing proposals and or recommendations to facilitate transactions flowing across multiple health care enterprises Projects Page 1 14 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapier 1 Introduction The Scheduling project defines abstract messages for the purpose of communicating various events related to the scheduling of appointments for services and associated resources The Patient Referral project defines the message set used in patient referral communications between mutually exclusive health care entities MODELING AND METHODOLOGY Ted Klein HBO amp Company Ph 770 393 6000 ext 4401 Fax 770 393 6092 Email tedOftklein com Abdul Malik Shakir The Huntington Group Ph 510 865 3900 Fax 510 271 6859 Email abdul malik_shakir idx com Mission The Modeling and Methodology Committee is responsible for creating and maintaining the HL7 message development methodology and facilitating its use and maintaining a Reference Model that reflects the shared models that are developed and used by the HL7 Functional Committees Projects e Modeling Tools Selection e Harmonization Process Definition e Modeling and Methodology Facilitation ORDERS OBSERVATIONS COMMITTEE Hans Buitendijk SMS Ph 610 219 2087 Fax 610 647 1328 Email hans buitendijk 9 smed com Clem McDonald MD Regenstrief Health Center Indiana University Ph 317 630
406. ion 6 98 Appendix A HL7 Transaction Checklist A LZ segment line is included at the bottom of each message to document site specific segments The location and name of the segment should be indicated for the message if Z segments are used The checklist does not replace the HL7 Interface Standards document Refer to the HL7 standard throughout the design and development process Keep in mind that the HL7 checklist and the HL7 standard itself may be interpreted differently by individual vendors as they apply the standard to the events and data that their systems process It is essential that all parties involved in an interface reach agreement on its details The HL7 checklist can facilitate that discussion As the health care community gains experience implementing HL7 interfaces the HL7 standard will evolve to both clarify its usage and expand its scope The HL7 Implementation Committee is very interested in learning about your experience implementing the HL7 standard Please direct your comments to the people listed at the end of this document This checklist is available to HL7 members in electronic format from the HL7 office at 3300 Washtenaw Ave Suite 227 Ann Arbor MI 48104 4250 Phone number 734 677 7777 Page A 2 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 2 HL7 INTERFACE CHECKLIST COVER SHEET D
407. ion A 4 2 11 A11 Cancel Admit ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Diagnosis Information A 4 2 12 A12 Cancel Transfer ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Diagnosis Information A 4 2 13 A13 Cancel Discharge ADT Originator A or B Page A 18 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist Health Level Seven Implementation Support Guide Page A 19 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Message Header R Event Type R Patient Identification R Additional Demographics Next of Kin Patient Visit R Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Add l Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information Appendix A HL7 Transaction Checklist A 4 2 14 A14 Pending Admit AD
408. ion describes the proposed interface environment and the plan for implementing interfaces on the selected AIE Vendor Information This section includes questions regarding the vendor s organization contractual and warranty specifications system support and maintenance installation support and system documentation and training Application Interface Engine Features and Functionality This section defines specific functional requirements for the AIE Hardware Operating System Technical Specifications This section addresses the system architecture performance and security requirements for the AIE Hardware and Software Cost Schedules This section includes schedules which are designed to provide St Anybodys Medical Center with complete and detailed cost information including the cost of hardware software ongoing maintenance modifications documentation installation assistance cabling shipping and taxes Health Level Seven Implementation Support Guide Page F 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 2 Background and Strategic Direction F 1 2 1 Current Environment e Inpatient Care e Ambulatory Care e SAMC In the Community e Emergency Care e Volunteers F 1 2 2 Strategic Direction F 1 3 Instructions Scope and Methodology F 1 3 1 Project Objectives and Scope of the Request for Proposal The primary objective of this project is for the Information Servic
409. ion with each version of the HL7 standard INFORMATION MANAGEMENT MEDICAL RECORDS Anne Shanney PHAMIS Inc Ph 206 689 1102 Fax 206 623 2688 Email shanney anne Ephamis com Wayne Tracy Health Patterns Ph 913 685 0600 Fax 913 897 6889 Email wrtracy wrt win net Mission The goal of the Medical Records Information Management Technical Committee is to define messages to support the messaging needs of the health information management medical records functions The Committee is comprised of individuals representing vendors of information systems computer based systems health information management professionals and other stakeholders including other allied health professionals and physicians Projects This committee constructs Domain Information Models DIMs and messages which can be communicated to and from systems which serve the needs of the health information management medical record functions of health care organizations INTER ENTERPRISE John Lynch Connecticut Healthcare Research amp Education Foundation Ph 203 294 7270 Fax 203 284 9318 Email David Means Oacis Healthcare Systems Inc Ph 770 390 9029 Fax 770 698 5090 Email dmeans oacis com Mission The Inter Enterprise Technical Committee defines messages and transactions to support cross functional processing requirements of health care enterprises This group will also act as a liaison between other functioning technical committees mak
410. is Information Resource Group Appointment Information Service Appointment Preferences Notes and Comments Appointment Information General Resource Appointment Preferences Notes and Comments Appointment Information Location Resource Appointment Preferences Notes and Comments Appointment Information Personnel Resource Appointment Preferences Notes and Comments Health Level Seven Implementation Support Guide Page A 67 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 8 1 2 Scheduled Request Response Originator A or B Message Header Message Acknowledgment Error Schedule Activity Information Notes and Comments Patient Identification Patient Visit Patient Visit Additional Info Diagnosis Information Resource Group Appointment Information Service Notes and Comments Appointment Information General Resource Notes and Comments Appointment Information Location Resource Notes and Comments Appointment Information Personnel Resource Notes and Comments A 4 8 2 S02 Request Appointment Rescheduling See A 4 8 1 A 4 8 3 S03 Request Appointment Modification See A 4 8 1 A 4 8 4 S04 Request Appointment Cancellation See A 4 8 1 A 4 8 5 S05 Request Appointment Discontinuation See A 4 8 1 A 4 8 6 S06 Request Appointment Deletion See A 4 8 1 Page A 68 Health Level Seven Implementation Support Guide Final Version
411. is reserved for querying for an Expected Sequence Number e The value 1 is reserved for synchronizing the sequence numbers on a link State of the Receiving System The receiving system will be in one of two states depending on its Expected Sequence Number Either the receiving system has an Expected Sequence Number or it does not In the middle of a synchronization sequence the receiving system does not have an Expected Sequence Number At startup the receiving system may or may not have an Expected Sequence Number Sequence Number Processing by the Receiving System The receiving system is expected to keep track of both its Expected Sequence Number and Expected Sequence Number state in a secure manner This is so that in the event of either side of a link going down a link may be restarted without loss or duplication of transactions By saving a 1 when the Expected Sequence Number state is NONE the receiving system can track both pieces of information with a single operation Saved ESN Expected Sequence Number State gt 1 gt 1 valid sequence number 1 NONE Page C 24 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols C 5 4 Normal Operations In normal operation of a link the sending system sends a message with a sequence number The receiving system checks the sequence number of the message against its Expe
412. istrators If so can these administrators be assigned different levels of authorization based on their function What are the levels Will the security system allow for dynamic reconfiguration If so can the new configuration be activated based on administrator requirements e g immediately or deferred Describe security administration GUI if available How is security maintained in conjunction with single terminal access or CUI Implementation Cost Schedules This section of the RFP includes schedules for cost information for the proposed system Please fill out each section completely and accurately We have provided transaction information for the proposed interfaces Failure to provide cost information in the required format or for a different implementation approach may be cause for elimination The schedules for the following are included A Software B Hardware C Documentation D Modifications E Support and Implementation Staff F Training G Installation Assistance H Ongoing Support Maintenance and Enhancements Health Level Seven Implementation Support Guide Page F 39 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates I Shipping and Taxes J Total Life Cycle Cost K Vendor Recommended Categories Approach Page F 40 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All right
413. ity may be divulged Health Level Seven Implementation Support Guide Page 5 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Table Number Table Name 0246 Product available for inspection Status of evaluation 0248 Product source 0249 Generic product 0250 Relatedness assessment 0251 Action taken in response to the event 0252 Casualty observations 0253 Indirect exposure mechanism 0254 Kind of quantity 0255 Duration categories 0256 Time delay post challenge 0257 Nature of challenge 0258 Relationship modifier 0259 Modality 0260 Patient location type 0261 Location equipment 0262 Privacy level 0263 Level of care 0264 Location department 0265 Specialty type 0267 Days of the week 0268 Override 0269 Charge on indicator 0270 Document type 0271 Document completion status 0272 Document confidentiality status 0273 Document availability status Document storage status 0276 Appointment reason codes 0277 Appointment type codes 0278 Filler status codes 0279 Allow substitution codes 0280 Referral priority 0281 Referral type 0282 Referral disposition 0283 Referral status 0284 Referral category 0285 Insurance company ID codes 0286 Provider role 0287 Action code 0288 Census tract 0289 County parish 0290 MIME base64 encoding characters 0291 Subtype of referenced data 0292 Vaccines Administered 0293 Billing category 0294 Time
414. ity start dates end dates calculated duration days and man days A project manual was also developed to assist user departments through the process of implementing the clinical system An extra step is also being taken to use this as an opportunity to avoid automating the processes currently in place but to first work on improving them and making them more efficient Health Level Seven Implementation Support Guide Page E 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix E Sample Case Studies E 2 3 E 2 4 E 2 5 Page E 2 The ADT and Charge Interface Projects As previously stated the hospital had not yet had the opportunity to send HL7 messages in a real time interface utilizing the TCP IP protocol It had been determined that this project required a real time ADT interface to the Tandem to support the clinical systems with the charges returning in a batch format to the AS 400 using the TCP IP FTP subcommands HL7 and TCP IP Implementation It was decided that we would implement using version 2 1 of HL7 with the intent to migrate to new versions as they became available Our vendor for the clinical system requested that we conform to the Berkeley Socket for the TCP IP portion of the interface however that feature of TCP IP is not expected to be available on the AS 400 until Version 3 release of the operating system Until then we are able to execute the real time TCP IP functions on the AS
415. ividual entities e g providers vendors and consultants that Health Level Seven Implementation Support Guide Page 1 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapier 1 Introduction contract for these interfaces The HL7 organization may develop a certification process or compliance testing procedures in the future Institutions that are considering major systems development activities e g comprehensive system upgrades replacements migration to an open systems architecture and or integration of various clinical financial or administrative systems with a central Hospital Information System HIS and are considering HL7 as a mechanism for integrating these systems should refer to the planning component of the methodology Institutions that have already made a decision to implement one or more HL 7 interfaces in any type of an environment will also find certain information in the planning section useful but should concentrate on the design and implementation sub section of the implementation methodology covered in Chapter 3 HIS vendors should focus on the design and implementation sections but may also consider reviewing the planning section as background 1 2 HL7 BACKGROUND HL7 was founded in 1987 to develop standards for the electronic interchange of clinical financial and administrative information among independent health care oriented computer systems e g hospital information systems c
416. l but it will always be used The PV1 segment is not listed as optional when in fact it was in version 2 1 Note that A18 should normally not be used it was retained for backwards compatibility purposes only You probably should be using A34 A36 where the MRG segment is required Norman Daoust CLINICAL DATA CONTENT Cannot Locate the HL7 Field Where Put Glucose or Height and Weight or Outcome or Whatever There are tens of thousands of kinds of clinical observations Rather than define a separate field for each such membership the HL7 committee chose to use a technique where the same segment OBX Observations Results serves for all of them Some of the important fields in this segment are e Value Type will the value be a string a number a code a block of text or what e Observation Identifier a code that identifies the observation e g serum glucose fasting e Observation Value the actual reported value e Units for numerical values the units e Reference Range the normal range for this test and patient e Abnormal Flags a flag if it was read as abnormal This same segment has been used to send chemistries microbiology reports radiology reports physical observations like height weight and coma scale and many other results and findings It is discussed at length in Chapter 7 of the specification Instead of looking for a field whose name describes the data you want to send you should look for a code to go in th
417. l Seven Implementation Support Guide Page B 57 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 97 UB2 UB92 Data L1 00559 SED UB2 NL dy cipe HH HE 2 0054 Co Insurance Days ST j 9 5 5 3 0055 Condition Code 24 30 Cp Ofl 3 Com 4 0056 CoveredDays 7 SE 5 00557 Non CoveredDays 8 _ dtl ss 6 00558 Value Amount Code 39 41 CM Os 7 00559 Occurrence Code Date 32 35 CM an Ot 8 00560 Occur Span Code Dates 36 CM Os 9 00561 UB92Loctor2 9ate ST OY 10 00562 UB92Locaorll Stte Ce a CP 11 00563 UB92Locator3l Ste ST 59 o 12 00564 Document Control Number GD ST Q9 ss 13 00565 UB92Locatr49 Naion ST o Ol 14 00566 UB92 Locator 56 State ST 0 Ol 9 0 5 S 15 00567 UB92 Locator 57 National ST o J S 16 00568 UB92Locaor78 Stt Cer o 9 9 S 17 00815 Special VisitCount TL Cal III S B 1 98 URD Results Update Definitions 1 0045 RUDae Tim TS 5 5 0 0 2 0046 ReportPriority l ID D 3 Com 3 00047 R U Who Subject Definition R XCN en hj S 9
418. l skills related to the systems environment selected should also be conducted 2 4 3 4 Identify Application For Replacement Modification Determine which if any of the current information systems applications will be replaced The institution should also identify existing systems applications that may require modifications in order to implement an HL7 environment 2 5 TECHNICAL ARCHITECTURE The purpose of this section is to identify the overall technical environment in which the interface s will be developed It is also intended to provide for development of a technology and communications infrastructure into which the various applications will be integrated 2 5 1 Technology Requirements 2 5 1 1 Identify User Technology Review the specific user technology requirements e g image processing and bedside automation identified during the previous tasks and identify the implications on the overall technical architecture e g image processing would require high speed high capacity transmission lines 2 5 1 2 Establish Technical Strategies Establish overall strategies for each of the following technical architecture components e Processing architecture distributed cooperative and centralized e Data Storage centralized decentralized e Hardware platforms e Workstation technology e Communications see below e Systems development strategy e g package custom and productivity aids 2 5 1 3 Identify Additional Hardware Software
419. lasses of entities as the result For example MICROORGANISM IDENTIFIED PRID PT ISLT NOM BACTERIAL SUBTYPING MICROORGANISM IDENTIFIED PRID PT ISLT NOM VIRAL SUBTYPING Page H 22 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Table 7 Kind of Property Enzymatic Activity Other Properties CACT Catalytic Activity ABS Absorbance CCNC Catalytic Concentration ACT Activity CCRTO Catalytic Concentration Ratio ANAT Anatomy CCNT Catalytic Content ANGLE Angle CFR Catalytic Fraction APER Appearance CRAT Catalytic Rate ARB Arbitrary CRTO Catalytic Ratio AREA Area ASPECT Aspect Entitic BIB Bibliographic Citation Entitic CIRC Circumference Arbitrary Entitic CLAS Class Entitic Substance of Amount CNST Constant Entitic Catalytic Activity COEF Coefficient Entitic Length COLOR Color Entitic Mass COMPLX Complex Entitic Number CONS Consistency Entitic Volume DEN Density Mass Volume DEV Device DIFF Difference Mass ELAS Elasticity Mass Concentration ELPOT Electrical Potential Voltage Mass Concentration Ratio ELPOTRAT Voltage Rate Amperage Mass Content ELRES Electrical Resistance Mass Fraction ENGRAT Power Energy Time Mass Increment ENGRTO Energy Ratio Mass Rate ENRG Energy Mass Ratio EQL Equilibrium Relative Mass Concentration EQU Equation Threshold Mass Concentration FCN Function FI
420. le Detail Problem Notes and Comments Variance Problem Role Variance Role Observation Notes and Comments Detail Goal Notes and Comments Goal Variance Goal Role Goal Variance Role Observation Notes and Comments Common Order Order Detail Notes and Order Detail Health Level Seven Implementation Support Guide Page A 91 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist P emm Variance Order Observation Result Notes and Comments Observation Variance Observation Result A 4 10 19 PCK Patient Pathway Goal Oriented Query QRY Originator A or B Message Header Query Definition Query Filter A 4 10 20 PCL Patient Pathway Goal Oriented Response PPT Originator A or B Message Header MSA Message Acknowledgment ERR Error QRD Query Definition PID Patient Identification PV1 Patient Visit PV2 Patient Visit Additional Info PTH Detail Pathway NTE Notes and Comments VAR Variance Pathway ROL Role VAR Variance Role GOL Detail Goal NTE Notes and Comments Goal VAR Variance Goal ROL Role Goal VAR Variance Role OBX Observation NTE Notes and Comments PRB Detail Problem NTE Notes and Comments VAR Variance Problem Page A 92 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Tran
421. lel Testing Once functional interface testing is complete the interface should be brought up in a mirror production environment and parallel tested if possible with the existing systems and environment Specific transactions should be identified to be entered into both systems Health Level Seven Implementation Support Guide Page 3 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 3 Implementation Methodology 3 6 9 6 3 6 9 7 3 6 9 8 3 7 Test Results Document the testing results in a summarized fashion This document may be used to review the results of the testing and determine whether additional testing is required User Review And Acceptance After successful testing schedule a review meeting with all users to discuss the results of testing and training and to outline the support structure and procedures Encourage discussion among users to promote common understanding of operations and responsibilities Reach consensus with all users that the interface is acceptable Sign Off Once the users are comfortable with the stability of the system and the support available obtain sign off as acceptance of a completed interface It may be necessary to schedule multiple meetings with different application areas and get sign off from each PRODUCTION CUTOVER The system is ready for cutover into production following the successful completion of all of the other tasks 3 7 1 3 7 2
422. lement APP CD APPLICATION CODE a code that identifies the application that owns the data element name in the APPLICATION FIELD NAME column APPLICATION The physical name of the application data element A physical name is defined as ELEMENT NAME the data element name used in programs COMP The OAS component or the application number used to identify the data element TYP TYPE indicates the data type of the application data element Allowable values ST string TX text FT formatted text data NM numeric DT date TM time TS time stamp PN person name TN telephone number AD address ID coded value SI sequence CM composite CK composite check digit CN composite number and name CQ composite quantity with units CE coded element CF coded element with formatted values RP reference pointer TQ timing quantity MO money LENGTH indicates the number of positions for the application data element OPTIONALITY indicates if the application data element is required optional or conditional in a segment Allowable values R required O optional C conditional REPETITION indicates if the application data type may repeat Allowable values N no repetition Y the field may repeat an indefinite number of times integer the field may repeat up to the number of times specified in the integer TABLE ID indicates the identification number for the table of allowable values for the
423. level but the acceptance criterion is more strict At least 60 of the registered voters must vote and 90 must vote to affirm In practice the Technical Committees work with the voters to achieve clarification and compromises in order to get almost all negative votes withdrawn After the draft standard has been successfully balloted it is subjected to a final editing process and then published Version 2 2 was published primarily as a series of WordPerfect files on floppy disk Members have the option to request printed copies Due to difficulties using this version it is likely that Version 2 3 will be published electronically using a different file format G 9 2 8 Who May Use the HL7 Standard Do Have to be a Member There are no licensing requirements for using the HL7 standard so technically anyone can use it There is a big Catch 22 here however The primary source of funds for HL7 is its membership Health Level Seven Implementation Support Guide Page G 17 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions fees The documents are free to members It is possible to purchase a copy of the document without being a member but the cost is the same as joining G 9 2 9 How Do Get a Copy of the Standard Contact the HL7 Administrative Headquarters G 9 2 10 What are the Sources of HL7 Funding and How is the Money Used HL 7 is wholly funded from two sources memb
424. liaison has now extended to the point where both groups now have the permission to freely use the contents of each others standards efforts in whole within their own published standards Some distinctions are more in the terminology chosen than the actual message content For example the ASTM sub field delimiter is generally used to separate repetitions of homogenous values It is called a repetition separator in HL7 HL7 and ASTM are both members of ANSI s HISB 4 NCPDP National Council for Prescription Drug Programs The NCPDP published standards for information processing for the pharmacy services section of the health care industry HL7 and the NCPDP signed a Memo of Understanding on November 5 1997 declaring common interests with respect to physician pharmacist interface modeling and joint mapping HL7 and the NCPDPD agreed to work to assure that community pharmacy content can be sent by either message standard There is also interest in developing a joint patient medication profile message 5 IEEE P1157 MEDIX The MEDIX committee is defining an application level protocol similar in scope to HL7 but built strictly on the ISO protocol stack up to and including the Remote Operation Service Element ROSE HL7 varies from this approach by the decision not to depend on ROSE nor use the ASN 1 BER syntax notation Despite the difference in approaches the HL7 Working Group has regular liaison with the MEDIX committee T
425. limitations of many existing communication systems Some existing systems would misinterpret some eight bit characters as flow control characters instead of data Others would strip off the eighth bit 2 The European community EC has a need for printable characters for example the German oe the French accent grave that are not within the above defined restricted data set The personal computer market accommodates these alphabetic characters by assigning them to codes between 128 and 256 but it does this in many different ways ISO 8859 is a 256 character set that does include all of the needed European letters and is a candidate for the European standards group Where the Europeans define an eight bit character set specification HL7 will accept this data set in environments that require it and can use it without complications 3 Multi character Codes a UNICODE When communicants use UNICODE and all characters are represented by the same number of bytes all delimiters will be single characters of the specified byte length and the Standard applies just as it does for single byte length except that the length of the characters may be greater than one byte b JIS X 0202 ISO 2022 provides an escape sequence for switching among different character sets and among single byte and multi byte character representations Japan has adopted ISO 2022 and its escape sequences as JIS X 0202 in order to mix Kanji and ASCII characters in the same
426. linical laboratory systems enterprise systems and pharmacy systems In the last three years HL7 s membership has grown to exceed 1 700 hospital professional society health care industry and individual members including almost all of the major health care systems consultants and vendors The HL7 Standard is supported by most system vendors and used in the majority of large U S hospitals today It is also used internationally in such countries as Australia Austria Belgium Finland Germany Holland Israel Japan New Zealand the Netherlands and the United Kingdom In June of 1994 HL7 was designated by the American National Standards Institute ANSI as an ANSI accredited standards developer HL7 released its fourth version of the standard Version 2 2 in December 1994 This consensus standard was balloted under ANSI rules and was approved as an ANSI Standard on February 8 1996 Version 2 3 which was released on CD ROM in April of 1997 was approved as an ANSI Standard on May 13 1997 1 3 HL7 TRANSACTIONS The Version 2 3 Standard defines transactions for transmitting data about patient registration admission discharge and transfers insurance charges and payors orders and results for laboratory tests image studies nursing and physician observations diet orders pharmacy orders supply orders master files appointment scheduling problem lists clinical trial enrollments patient permissions voice dictations advanced directives a
427. lity to support the information needs of activities such as scheduling patient tracking and orders and results The scope does not assume stewardship of messages generated by these external activities A goal of this committee is to continue to take advantage of and extend messages developed by other HL7 committees rather than develop redundant and independently maintained message components VOCABULARY Jim Cimino MD Columbia University College of Physicians and Surgeons Ph 212 305 8127 Fax 212 305 3302 Email ames cimino columbia edu Ed Hammond PhD Duke University Medical Center Ph 919 684 6421 Fax 919 684 8675 Email hammo001 Q mc duke edu Stanley Huff MD College of American Pathologists Intermountain Healthcare Ph 801 442 4885 Fax 801 263 3657 Email coshuff ihc com Mission To identify organize and maintain coded vocabulary terms used in HL7 messages Projects Provide an organization and repository for maintaining a coded vocabulary that when used in conjunction with HL7 and related standards will enable the exchange of clinical data and information so that sending and receiving systems have a shared well defined and unambiguous knowledge of the meaning of the data transferred SPECIAL INTEREST GROUPS AUTOMATED DATA Fritz Freidhoff Spacelabs Medical Inc Ph 206 882 4095 Fax 206 882 3897 Email fritzf 2slmd com Health Level Seven Implementation Support Guide Page 1 17 for HL7 Standard Version
428. ll rights reserved Appendix B HL7 Segment and Event Checklists B 1 67 PDC Product Detail Country 1 01247 Manufacturer Distributor Ir XON 80 0 2 01248 Country R CE A 3 01249 BrandName R ST 60 ss 4 01250 Device FamilyName ST 5 01251 GenericName l 60 J S 79 6 01252 Modelldenifer CT ST en OY 7 01253 Catalogue Identifier ST 60 J 0 S 8 01254 Otherldeniier ST ss 9 01255 ProduetCode l 60 10 01256 MaretngBasis DI III y 11 01257 MareingApprvallD ST 60 II S 12 01258 Labeled ShelfLife Cool 2 PP LJ 13 01259 Expected ShelfLife JL CQ 2 0239 14 01260 Date FirstMarked TS 0 0 0 0 0 0 0 15 01261 DateLastMarked d TS YH B 1 68 PEO Product Experience Observation 1 01073 EventIdentifiersUsed CE 00 OY 2 01074 EventSymptom Diagnosis Code CE 60 o 4A 0 0 S 3 01075 Event Onset Date Time R TS o J 5 5 4 01076 Event Exacerbation Date Time TS Bss 5 01077 Event Improved Date Time TS o J 0 0 6 01
429. ll rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 2 38 A38 Cancel Pre Admit ADT Originator A or B Message Header R Event Type R Patient Identification R Additional Demographics Next of Kin Patient Visit R Patient Visit Additional Info Disability Information Health Information Diagnosis Information Diagnosis Related Group A 4 2 39 A39 Merge Person External ID ADT Originator A or B Message Header R Event Type R Patient Identification R Additional Demographics Merge Information R Patient Visit A 4 2 40 A40 Merge Person Internal ID ADT Originator A or B Message Header R Event Type R Patient Identification R Additional Demographics Merge Information R Patient Visit Page A 30 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 2 41 A41 Merge Account Patient Account Number ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Patient Visit A 4 2 42 A42 Merge Visit Visit Number ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Patient Visit A 4 2 43 A43 Move Patient Information Internal ID ADT Originator A or B Message Header Event Type Patient Identificati
430. ll rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 3 5 C 3 5 1 Block Headings and Acknowledgment Prefixes Headings An optional heading may be sent as part of a transmission block It is a sequence of non communication control characters that constitutes a machine sensible address or routing information A STX terminates a heading C 3 5 2 Prefixes C 3 6 C 3 6 1 An optional prefix may precede acknowledgments It may consist of up to 15 characters other than communication control characters in order to convey additional information for example identity or status Note that EOT must never have a prefix Stations must accept prefix characters without confusion Interpretation of the prefix however must be by prior agreement between the implementers A prefix must not change the meaning of the associated control character Timers and Recovery Procedures Timers Timers are primarily used to indicate when recognition of specific control characters does not occur within specified periods It is to be noted that the timers specified in this section are functional only and do not necessarily imply a specific implementation The action taken following a timeout is specified but may vary for specific implementation requirements Logging and or operator notification of timeouts should be done to aid in the maintenance and troubleshooting of interfaces Timer A Response Timer Timer A is used by a
431. llection Description NOS NOMS and the Observation Results fields of the OBX segments would contain respectively Swab Right Arm and Wound The granularity of the actual terms used in the specimen description is at the discretion of the user Thus Right Arm Wound as the value of a single OBX segment could be used in place of the three codes described in the previous sentence Descriptions of measurement and culture growth will be noted as separate OBX segments that accompany the culture result message The name of the observation identifier will provide the context of the observation For instance the name for a quantitative test of bacteria in a specimen would be COLONY COUNT NUM PT XXX QN VC Descriptions of Gram stain findings will be noted as OBX segments that accompany the culture result message The name of the observation identifier will be MICROSCOPIC OBSERVATION PRID PT XXX NOM GRAM STAIN The result values that could be reported with this test which is a multiple choice multiple answer type or observation might include one or more of the following Epithelial cells Gram positive cocci in chains Many Gram negative diplococci The organisms identified in a culture will be sent as result values in OBX segments A separate table of allowable E M E E 15 Shes organism names will need to be identified Bergey s Manual of Determinative Bacteriology or some other authoritative Page H 34 Health Level Se
432. lly be reported in separate fields attributes of a test observation report message not as part of the observation name Attributes that we explicitly exclude from the fully specified name are the instrument used in testing fine details about the sample or the site of collection such as right antecubital fossa the priority of the testing e g whether stat or routine who verified the result the size of the sample collected the place of testing e g home bedside clinical lab ow v v v v In the case of laboratory tests the name does include information that identifies the type of sample or specimen However the sample part of the name is not meant to carry all possible information about the sample but only enough to indicate significant differences in the result and to reflect current usage in test names For example laboratories usually define urine sodium sweat sodium and serum sodium as different tests because each of these has a different normal range But laboratories do not define different tests to distinguish the concentration of arterial serum sodium from venous serum sodium though the lab may report that the sample was venous or arterial in another part of the report We are guided by the pragmatics of conventional usage If laboratories define separate tests for the same measurements done on different specimens this usually implies a well defined normal range difference we will define different resultable tests in o
433. lth Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols ESTABLISHMENT PROCEDURE MESSAGE TRANSFER TERMINATION PROCEDURE PROCEDURE Contention Terminate Message transfer 11 12 Oxo gt aom AZ nvalid or no reply To recovery procedures NOTE Crosshatched area is slave Figure C 2 Establishment of Master Slave In the case of an invalid or no reply to ENQ 7 the bidding station reinitiates its bid for master status 2 The station reinitiates its bid N times 8 After N unsuccessful bids the station exits to a recovery procedure 9 An exit to the recovery procedure 10 indicates that the remote station is not operational busy or down The recovery procedure may consist of a delay after which line bidding is resumed 2 Or recovery may involve passing an error indication to a higher level to abort a connection As in the case of a dial in link The master station transmits EOT 11 to indicate it has no more data to transmit EOT negates the master slave relationship and returns the station to contention mode 1 C 3 3 Message Transfer Messages may be subdivided into blocks A transmission block may be a complete message or a portion of a message The master station sends each transmission block to the slave station and waits for a reply If the reply indicates that the block was accepted the
434. lts of herpes virus 1 herpes virus 2 etc then PRID is the right property If the culture is for herpes virus and the answer is positive negative or yes no then the property should be ACNC and the scale ordinal ORD Health Level Seven Implementation Support Guide Page H 35 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC 3 5 Drug susceptibilities Drug susceptibility tests will be named according to the generic name of the drug tested and the methodology used in testing with the property SUSC with values that are either QN or ORD Thus appropriate names would be AMPICILLIN SUSC PT ISLT QN MIC AMPICILLIN SUSC PT ISLT ORD AGAR DIFFUSION TICARCILLIN CLA VULANATE SUSC PT ISLT QN MBC Table 16 lists methods in drug susceptibility tests Table 16 Drug Susceptibility Methods AGAR Bacterial sensitivity Kirby Bauer via agar diffusion MIC Minimum inhibitory concentration MLC Minimum lethal concentration SBT Serum bactericidal titre GRADIENT STRIP Susceptable by E Test or gradient strip method The drug susceptibility tests are all grouped together in the LOINC database under the class ABXBACT 3 6 Alternate representation of microscopic examinations Because of the alternative representation of microscopic observations see discussion in 1 1 of LOINC and item 21 the following convention will be used for the alternate representation of microscopic examinations WBC C
435. m the ANSI X3 28 Standard Decisions to use specific X3 28 options came from the items listed in section 1 2 Requirements and Assumptions The following X3 28 options are used Parenthesized paragraph numbers are citations to the ANSI document l Establishment and Termination Subcategory 2 3 Two Way Alternating Nonswitched Point to Point 2 Message Transfer Subcategory B2 Message Associated Blocking with Alternating Acknowledgments ACKN is used with link block numbers as a substitution for alternating ACKO ACKI e Link Block Numbers 3 7 e Prefixes 3 3 e Block abort 3 4 1 e Sending station abort 3 4 2 e Termination Interrupt 3 4 3 e Reverse interrupt 3 4 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols e Optional transparent heading and text Transparent block sequences are always used but escaping of DLEs in data is left to local implementation agreement Other features not covered in the X3 28 Standard but used in this protocol The BCC is converted to an ASCII hexadecimal representation A single termination character follows each block and control sequence A message length has been added to the block trailer to help verify block integrity A line check timer E provides early warning of communications link problems This protocol does not prescribe the means for est
436. mary Observer Aware E Q8 ff 01097 Primary Observer s Identity May Be 1 a Divulged B 1 69 PES Product Experience Sender 1 01059 Sender Organization Name TT XON 80 Po S 2 01060 Sender Individual Name XeON 60 OY 3 01062 Sender Address xo 60 Ys 4 01063 SenderTelephone XTN 40 Ol 0 7 5 01064 SenderEventldenifier IL EI Y 6 01065 Sender Sequence Huber NM j S 7 7 01066 Sender Event Description FT 00 Off 5 8 01067 SenderComment FT 00 III 9 01068 Sender Aware Date Time TS e 2 J 10 01069 EventReportDate R TS QO 0 11 01070 EventReportTiming Type ID Of 3 sy 12 01071 EventReportService ID D 2 0235 13 01072 EventRepotedto DEMO B 1 70 PID Patient Identification Len Max Sender Variable Receiver Variable 1 00104 SetID Patien ID TST Page B 38 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists 2 oos Patent ID ExemalID amp X L IL 3 00106 Patient 1D int
437. measured body weight Health Level Seven Implementation Support Guide Page H 31 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC 2 7 8 Imaging studies We distinguish among the major imaging modalities for most measures derived from such imaging studies e g cardiac output from a muga scan vs angiography 3 Special Cases 3 1 Findings viewed as variables or as values For some complex tests there are two ways to organize the results into a report 3 1 1 Value Assume a set X is made up of five results that can have a scale of absent present or 0 1 These results could be reported as Finding 1 Present or as 1 Finding 2 Absent 0 Finding 3 Present 1 Finding 4 Absent 0 Finding 5 Absent 0 Each finding is then considered a binary variable This is sometimes called a panel approach 3 1 2 Variable Multiple Choice Approach The alternative would be to report this information as a single variable or multiple choice question with many possible values Variable X Finding 1 Finding 3 In this case the findings are the values of a variable called Variable X only the positive findings are reported as values Many laboratory tests e g those that test for HLA antigens red blood cell antigens or screens for toxic substances could in theory be presented either way The microscopic part of the differential count and urinalysis could also be described either way
438. members look for v 2 2 availability In general the availability of new features should be demand driven 4 2 4 1 5 Will some new features be ahead of vendor s implementations Probably yes Health Level Seven Implementation Support Guide Page 4 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 4 HL7 Version 2 2 Overview 4 3 SUMMARY BY CHAPTER OF CHANGES FROM VERSION 2 1 TO 2 2 4 3 1 Chapter 2 Control Query Enhanced Mode Acknowledgement Queries moved from Chapter 5 Communication Environment 4 3 1 1 New Data Types CF code element with formatted values RP reference pointer TQ timing quantity MO money 4 3 1 2 Processing Immediate processing is now known as original processing Deferred Processing is now known as deferred two phase Enhanced Processing is new 4 3 1 3 Message Segments Tables 0104 b Table added value 2 2 0076 Message types Table added RAR RAS RDE RDR RDS RGV RGR RER ROR RRA RRD RRE RRG 0008 Acknowledgement Code x Table values added CA CE CR_______ What Subject Filter X Table new values added ARN APM APA NCK NSC MST RAR RER RDR RGR ROR 4 3 1 4 Data Elements MSH 5 Receiving Application x Length changed from 151030 MSH 7 Date Time of Message x Lengthchangedfrom 19to26 MSH 9 Message Type x jDatatypechangedfromIDtoCM MSH 12_ Yeman lD LL x Da
439. men Electrode Endocardium Endometrium Eosinophils Erythrocytes Eye Exhaled gas breath Fibroblasts Filter Fistula LIVER LYM MAC MAR MEC MBLD MLK MILK NAIL NOS ORH PAFL PAT PEN PCAR PRT PLC PLAS PLB PLR PMN PPP PRP PUS SAL SMN SMPLS SER Body fluid unsp Food sample Gas Gastric fluid contents Genital Genital cervix Genital fluid Genital lochia Genital Mucus Genital vaginal Hair Inhaled Gas Intubation tube Isolate Lamella Leukocytes Line Line arterial Line venous Liquid NOS Liver Lymphocytes Macrophages Marrow bone Meconium Menstrual blood Milk Breast milk Nail Nose nasal passage Other Pancreatic fluid Patient Penis Pericardial Fluid Peritoneal fluid ascites Placenta Plasma Plasma bag Pleural fluid thoracentesis fld Polymorphonuclear neutrophils Platelet poor plasma Platelet rich plasma Pus Saliva Seminal fluid Seminal plasma Serum LOINC Users Guide April 16 1998 Table 10 System Sample Type Codes SKN SKM SPRM SPT SPTC SPTT STON STL SWT SNV TEAR THRT THRB TISS TISG TLGI TLNG TISPL TSMI TISU TRAC TUB cic cod aic BLD BDY WAT WICK WND WNDA WNDE WNDD XXX Skin Skeletal muscle Spermatozoa Sputum Sputum coughed Sputum tracheal aspirate Stone use CALC Stool Fecal Sweat Synovial fluid Joint fluid Tears Throat Thrombocyte platelet Tissue unspecified Tissue gall bla
440. mends SNOMED Systematized Nomenclature of Human and Veterinary Medicine as the primary terminology resource for the coded entry Data Elements of both Standards Projects To this end the Image Management SIG is developing a framework for the development of an HL7 and DICOM interoperability model The framework leverages the work done in development of the HL7 v 3 0 Task Force s Message Development Framework MDF MPI MEDIATION Jim Gabler HUBLink Ph 614 841 9877 Fax 602 256 2568 Email jgabler hublink com Dave Kilman Los Alamos National Laboratory Ph 505 672 0178 Fax 505 665 4939 Email kilman ibm net Mission The goal of the MPI Mediation SIG is to recommend improvements or extensions to the HL7 specifications which support mediation among local MPI s master patient indices The specification will describe processes by which a unique individual can be identified and coordinated across multiple internal and external systems both existing and future Projects The MPI Mediation SIG will focus on the business functions which are to be addressed The general boundaries of this effort will include the description of an implied structure the necessary service requests with their attendant responsibilities and roles the need to quickly provide useful specifications the ability to support multiple identifiers both for cross referencing and for grouping the ability to support persons as well as other entities
441. ment booking SIU ACK Notification of appointment rescheduling SIU ACK Notification of appointment modification SIU ACK Notification of appointment cancellation SIU ACK Notification of appointment discontinuation SIU ACK Notification of appointment deletion SIU ACK Notification of addition of Service resource on appointment SIU ACK Notification of modification of service resource on appointment SIU ACK Notification of cancellation of service resource on appointment SIU ACK Notification of discontinuation of Service resource on appointment Health Level Seven Implementation Support Guide Page B 67 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists SIU ACK Notification of deletion of service resource on appointment SIU ACK Notification of blocked schedule time slot s SIU ACK Notification of opened unblocked schedule time slot s SQM SQR Schedule query message and response Notification that patient did not show up for schedule appointment MDM ACK Original document notification MDM ACK Original document notification and content MDM ACK Document status change notification MDM ACK Document status change notification and content MDM ACK Document addendum notification MDM ACK Document addendum notification and content MDM ACK Document edit notification MDM ACK Document edit notification and conte
442. ment start X date Health Level Seven Implementation Support Guide Page 5 25 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Segment Seq IN2 45 Insured s employment stop date IN2 46 Job title IN2 47 Job code class IN2 48 Job status IN2 49 Employer contact person name IN2 50 Employer contact person phone number IN2 51 Employer contact reason IN2 52 Insured s contact person s name IN2 53 Insured s contact person telephone number IN2 54 Insured s contact person reason IN2 55 Relationship to the patient start date IN2 56 Relationship to the patient stop date IN2 57 Insurance co contact reason IN2 58 Insurance co contact phone number IN2 59 Policy scope IN2 60 Policy source IN2 61 Patient member number IN2 62 Guarantor s relationship to insured IN2 63 Insured s telephone number home IN2 64 Insured s telephone number IN2 65 Military handicapped program IN2 66 Suspend flag IN2 67 Copay limit flag IN2 68 Stoploss limit flag IN2 69 Insured organization name and ID IN2 70 Insured employer organization name and ID IN2 71 Race IN2 72 HCFA patient relationship to insured IN3 1 Set ID IN3 Element Name changed from Set ID insurance certification to Set ID IN3 IN3 2 Certification number Length changed from 25 to 59 data type changed from ST to CX IN3 3 Certified by Data type changed from CN to SCN r
443. mining if members should upgrade to 2 2 or stay with 2 1 What key functional issues would drive this migration Since the majority of 2 2 centered around clarification and specification cleanup with few new capabilities it may make sense to continue to implement 2 1 and use Z segments where needed I primarily take this position because 2 3 looks as though it will entail a significant change If one needs to consider enterprise related issues it may make sense to defer modifications to existing interfaces until 2 3 When is version 2 2 likely to be available from vendors Good question I don t know As a vendor myself knowing there will be significant changes in 2 3 I m of the opinion to hold development of 2 2 and go right to 2 3 instead Right now 2 1 is working just fine for us Each vendor will need to consider that question based on the merits of what s already available and working Order Entry Clinical Observation responses by Hans Buitendijk What was the driving force behind the creation of version 2 2 In comparison with version 2 1 what advantages does it offer In version 2 2 we added Pharmacy Dietary and Supply messages segments The introduction of a Master File shell enabled us to define an Observation Master File segment set that will further support exchange of definition data These additions greatly expanded the applications that HL7 can support Additionally many data elements and clarifications were provided to m
444. mitSource IS 0023 15 00145 Ambulatory Status IS f f 00 16 00146 VIP Indicators PS 2 Cen 17 00147 AdmitingDocor SCHT 60 TI Com 18 00148 Patient Type IS o 35 oog 00149 Visit Number CX QO 5 S j 00150 FinancialClass rc on ofl UU 00151 Charge Price Indicator LC Lo 932 00152 Courtesy Code IS Roc O 00153 CreditRating LL IS PP y 00154 ContractCode LLJ Pc y 00155 Contract Effective Date DT LO IO 00156 Contract Amount LI NM 1D CC S 00157 ContractPeriod NM ss 00158 InterestCode I o LST 29 00159 TransfertoBadDebtCode IS D Com 30 00160 TransfertoBadDebtDate DT Ass 31 00161 BadDebtAgenyCode IS a 0021 kt o 20 21 22 23 24 25 26 27 28 Health Level Seven Implementation Support Guide Page B 43 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 32 00162 Bad Debt Transfer Amount NM 2 P 0 S 33 00163 Bad Debt Recovery Amount NM D 34 00164 Delete Account Indicator
445. more comprehensive than the other toolkits 3 Imex the first C language toolkit to be made publicly available was written at Columbia Presbyterian Medical Center It can be downloaded from ftp cucis cis columbia edu pub hI7 hl7imex Page G 12 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved G 8 3 G 8 3 1 G 9 G 9 1 G 9 1 1 Appendix G Frequently Asked Questions 4 Alan Rueter of the Mallinckrodt Institute of Radiology at Washington University has updated Imex and made it available as Imexa It can be downloaded from lt ftp wuerlim wustl edu pub hl7imexa gt Future Versions of HL7 What Will be in Version 2 3 Version 2 3 was published in April 1997 and included the following updated information Patient Administration Chapter 3 Order Entry Chapter 4 Query Chapter 5 Financial Management Chapter 6 Observation Reporting Chapter 7 Master Files Chapter 8 Medical Records Information Management Chapter 9 Scheduling Chapter 10 Patient Referral Chapter 11 Patient Care Chapter 12 GENERAL INFORMATION The Goals and Scope of HL7 What is HL7 HL7 is a standard for electronic data exchange in health care environments It endeavors to standardize the format and protocol for the exchange of certain key sets of data among health care computer application systems HL7 is accredited by the American National Standards
446. mple Templates Center and may be evaluated by any employee or agent of St Anybodys Medical Center St Anybodys Medical Center reserves the right to proceed or not to proceed with plans to acquire an AIE All proprietary information provided by vendors will be treated as confidential 5 On Site Walk Throughs and Demonstrations Vendors will be scheduled for a number hour on site walk through and system demonstration during month The purpose of this step is to e Allow vendors the opportunity to ask questions and clarify any issues related to the RFP e Provide an overview of the physical layout of the site e Allow St Anybodys Medical Center to more fully understand the products being proposed Each vendor will be required to have the appropriate staff on site to e Provide background on the company e Provide a conceptual overview of how the proposed product will meet St Anybodys Medical Center needs e Conduct a detailed demonstration of the product and the interface development tools being proposed for St Anybodys Medical Center The goal of this session is to provide as much product and site information to both the vendor and the hospital to ensure a more thorough and complete RFP response and evaluation Number of Proposals Please submit four copies each of all materials to the following address by date We request that one copy of the responses be delivered in electronic format Microsoft Word 6 0 or 7 0 is preferr
447. mponent Observation Results Notes and Comments A 4 3 17 002 Pharmacy Treatment Give re RRG Originator A or B Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Pharmacy Treatment Give Pharmacy Treatment Route Pharmacy Treatment Component Notes and Comments Health Level Seven Implementation Support Guide Page A 43 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 3 18 002 Pharmacy Treatment Administration Message RAS Originator A or B App A App B Repeat Message Header Notes and Comments Patient Identification Additional Demographics Notes and Comments Allergy Patient Visit Patient Visit Additional Info Common Order Pharmacy Treatment Order Notes and Comments Pharmacy Treatment Route Pharmacy Treatment Component Notes and Comments Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component Pharmacy Treatment Administration Pharmacy Treatment Route Observation Result Notes and Comments Clinical Trial Identification A 4 3 19 002 Pharmacy Administration Acknowledge RRA Originator A or B Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Pharmacy Treatment Administration Pharmacy Treatment Route Page A 44 Health Lev
448. n assigned LOINC number on a returned file 14 S COMMENT TEXT 250 Comments from the submitter may wish to pass to RI when needed 15 BLANKI TEXT 50 Place holder Do not use 16 BLANK2 TEXT 20 Place holder Do not Use LOINC RI ACTION RI COMMENT R COMPO R PROP R TIME R SYS R SCALE R METH L COMPO L PROP L TIME L SYS L SCALE L METH L CLASS Regenstrief Reference code A unique reference code assigned by RI to the submitted concept This code is produced by concatonating RIs abbreviation to the submitter the date the file was received by RI and the row position of the concept in the submitted spread sheet file Assigned LOINC code for submitted concept This may be a new code or a pre existing code Blank if questions still remain about the meaning of the concept Regenstrief Action Code ADD term accepted and new code assigned DUP submitted term already exists in LOINC databsae IDUP submitter inadvertently submitted same term twice internal Duplicate INFO more information needed from submitter HOLD submission is area not currently being considered RI s comments to submitter RTS revised version of submitter s analyted component RT s revised version of submitter s kind of property RTs revised version of submitter s time aspect RTS revised version of submitter s system sample type RT s revised version of submitter s type of scale RT s revised version of submitter s type of method Formal LOINC name for anal
449. n Appointment A 69 A 4 8 9 S09 Request Cancellation of Service Resource on Appointment oc A 69 A 4 8 10 S10 Request Discontinuation of Service Resource on Appointment A 69 A 4 8 11 S11 Request Deletion of Service Resource on Appointment A 69 A 4 8 12 S12 Notification of New Appointment SIU eee A 70 A 4 8 13 S13 Notification of Appointment Rescheduling sess A 70 A 4 8 14 S14 Notification of Appointment Modification eee A 70 A 4 8 15 S15 Notification of Appointment Cancellation eee A 70 A 4 8 16 S16 Notification of Appointment Discontinuation eere A 70 A 4 8 17 S17 Notification of Appointment Deletion eene A 70 A 4 8 18 S18 Notification of Addition of Service Resource on Appointment A 71 A 4 8 19 S19 Notification of Modification of Service Resource on Appointment A 71 A 4 8 20 S20 Notification of Cancellation of Service Resource on Appointment A 71 A 4 8 21 S21 Notification of Discontinuation of Service Resource on Appointment A 71 A 4 8 22 S22 Notification of Deletion of Service Resource on Appointment A 71 A 4 8 23 S23 Notification of Blocked Schedule Time Slots sessss A 71 A 4 8 24 S24 Notification of Opened Unblocked Schedule Time Slots
450. n order to ensure the vendors have adequately addressed responded to the established criteria During the selection process MIS users and management should be involved The selection process should also include reference calls checks on each of the vendors Consider the following during the evaluation process Functional and technical requirements of the system Overall hospital technical architecture Likely impact on the organization User and MIS Potential costs and benefits of each option vendor HL7 Criteria Vendor s Experience Investigate and document the vendor s experience with HL7 interfaces and consider this information during the selection process If selecting an interface engine understand the interface engine vendor s experience with your specific application systems and interfaces Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Chapter 2 Planning Methodology 2 9 2 2 Vendor Response Review Review vendor responses in order to ensure the following is included e HLI7 interface pricing including a description of activities and time included within the quoted price e References from HL7 activities and a list of delivered HL7 interfaces including version installed chapters and segments included and level at which the interface was developed e Scope of vendor responsibilities e Information support required from other vendors in order to complete
451. n other chapters of HL7 5 3 12 2 What functionality does it offer The Patient Care chapter offers support for the following trigger events PCI PPR PC Problem Add PC2 PPR PC Problem Update PC3 PPR PC Problem Delete PC4 QRY PC Problem Query PC5 PRR PC Problem Response PC6 PGL PC Goal Add PC7 PGL PC Goal Update PC8 PGL PC Goal Delete PC9 QRY PC Goal Query PCA PPV PC Goal Response PCB PPP PC Pathway Problem Oriented Add PCC PPP PC Pathway Problem Oriented Update PCD PPP PC Pathway Problem Oriented Delete PCE QRY PC Pathway Problem Oriented Query PCF PTR PC Pathway Problem Oriented Query Response PCG PPG PC Pathway Goal Oriented Add Page 5 32 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview PCH PPG PC Pathway Goal Oriented Update PCJ PPG PC Pathway Goal Oriented Delete PCK QRY PC Pathway Goal Oriented Query PCL PPT Pathway Goal Oriented Query Response 5 3 12 3 Are there any functional issues that should be addressed prior to implementing this chapter The implementator will need to determine whether or not the applications systems or institution which they will be communicating with supports a problem oriented or a goal oriented perspective Depending on the type of solution the messages
452. n section 3 4 5 Design Programs Lower Level Protocols Minimal functions should include Build HL7 messages Parse HL7 messages Interface to program handling the lower level protocol Interface to program handling the application Error handling trapping IMPLEMENTATION Site Preparation Physical This involves any physical changes necessary to implement the interface including modifications to physical workspace or computer room additional furniture or equipment racks and reservation of space for training or testing Use output from section 3 4 1 Define Required Hardware Platforms and section 3 4 2 2 Define Communications Hardware Technical This includes technical changes to the existing environment such as the addition of or modifications to cabling communications closets and lighting or power electrical requirements Select Install Lower Level Protocol Interfaces can be implemented in a number of environments including among applications on a single processor point to point between systems or over a network In most cases the interface will be built on top of some media and access method HL7 interfaces exist at the seventh or application layer of the OSI model As such they usually require the support of some lower level protocol LLP Things to consider include the current environment time frame for installation existing staff experience expertise long range communications strategy and cos
453. nal Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols retransmit the original block is application specific It depends on the type of message and the ability of the receiving system to detect duplicate messages 6 Optional Disconnect 7 Return to the encoding rule module with the response message Responding System Processing The responding system follows these steps 1 Optional Perform a listen function if required by the environment 2 Receive the block that contains the initial message To receive a block a Ignore all incoming characters until a Start Block character is received Any time another Start Block character is received before the end of a block ignore all previous characters Receive characters until EB CR is recognized This is the end of the block b Ifa block is received that does not have the proper 1 Block Format 2 Checksum xxx 3 Block Size ccccc or 4 Has too many characters to be received in a single block construct and send a NAK block type t N that includes the appropriate reason code in the data field c Ifthe receive block is valid go to the next step Give the initiation message to the application Application creates a response and makes a block Send the response message OY MU dC Disconnect if required C 2 4 Carriage Return Stuffing The HL7 encoding rules do not place any limits on
454. name ST suffix e g JR or Ill ST gt prefix e g DR ST degree e g MD ST source table IS assigning authority HD name type code ID identifier check digit ST code identifying the check digit scheme employed ID identifier type code IS assigning facility HD gt Generic CM Composite No new CM s are allowed after HL7 Version 2 2 Hence there are no new CM s in Version 2 3 Address street address ST lt other designation ST city ST gt state or province ST zip or postal code ST gt country ID address type ID gt other geographic designation ST gt Person name family name ST given name ST gt middle initial or name ST suffix e g JR or III ST gt prefix e g DR ST degree e g MD ST gt Telephone NN 999 999 number 9999 X99999 B99999 C any text XAD Extended In Version 2 3 replaces the AD address data type street address Demographics ST gt other designation ST gt city ST state or province ST gt zip or postal code ST country ID gt address type ID gt other geographic designation ST gt county parish code IS census tract IS Extended person In Version 2 3 replaces the PN name data type family name ST gt given name ST middle initial or name
455. nations based on each of the following variables and explain how routing is performed for each possibility Health Level Seven Implementation Support Guide Page F 23 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates Transaction type User location User sign on Application processor type Date time transaction has been generated Value of a data element contained in the transaction e g critical value indicator on lab result Value of related information not contained in the transaction but contained in a separate database e g routing of lab results based on Referring Physician Describe this database and how it is accessed as part of transaction routing Values of two or more data elements contained in the transaction e g patient age and patient diagnosis Explain which variable s take precedence 3 Route Transaction Tuning Transactions can be routed to destination systems at a scheduled time during the day or on scheduled dates Explain how this function is performed b Explain what happens if a receiving system is unavailable 4 Transaction Store and Forward Identify whether the AIE can receive transactions and store these transactions until one of the following events occur Page F 24 Final Version 6 98 A time threshold is reached A set number of transactions has been queued for the target system application An application syst
456. nce for example We would define different baseline measurements for challenges with different substances The baseline serum glucose before a challenge with 50 U insulin challenge would be defined as a different test from the baseline glucose for an oral glucose tolerance test These different baseline tests are defined to accommodate laboratories that conventionally do the same However a baseline glucose for any challenge is not affected by the challenge and could in principle be reported as a glucose without specifying the relation to a coming challenge We denote the route of the challenge by HL7 Version 2 2 abbreviations for medication routes Table 5 An oral route of administration would be denoted by PO an intravenous route by IV Page H 18 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Table 5 Route Abbreviations for Challenge Part Apply Externally Mucous Membrane Buccal Nasal Dental Nasogastric Epidural Nasal Prongs Endotrachial Tube Nasotrachial Tube Gastronomy Tube Ophthalmic GU Irrigant Otic Immerse Soak Body Part Other Miscellaneous Intra arterial Perfusion Intrabursal Oral Intracardiac Rectal Intracervical uterus Rebreather Mask Intradermal Soaked Dressing Inhalation Subcutaneous Intrahepatic Artery Sublingual Intramuscular Topical Intranasal Tracheostomy Intraocular Transdermal Intraperit
457. nd DB1 segments Changed name from Cancel patient arriving to Cancel patient arriving tracking Message added PD1 and DB1 segments Changed name from Cancel patient departing to Cancel patient departing tracking Message added PD1 segment ADT ACK cancel patient arriving tracking ADT ACK cancel patient departing tracking ADT ACK merge patient information patient ID only ADT ACK merge patient information account number only Message added PD1 segment ADT ACK merge patient information patient ID amp account Message added PD1 segment Segment name changed from Next of Kin to ADT ACK unlink patient information ADT ACK cancel pre X admit ADT ACK merge person X external ID A40 ADT ACK merge pe patient internal ID AAT ADT ACK merge account patient account A42 ADT ACK merge visit visit number A43 ADT ACK move patient information internal ID ADT ACK move account X information patient account number ADT ACK move visit X information visit number Gei Gei ADT ACK change X est n ADT ACK change X PO ERN ADT ACK change X a ADT ACK change X aten ccoo number ADT ACK change visit X P ADT ACK change aen IN Patient additional Hemgeme o oo Disability ES Next of kin associated NEM gt gt gt Health Level Seven Implementation Support Guide Page 5 11 for HL7 Standard Version 2 3 O 1998 All rights rese
458. nd parallel testing 3 6 6 Policies Procedures 3 6 6 1 Develop Policies Update policy manuals with managerial policies regarding the interfacing of various source systems via the HL7 protocol The company should provide clear guidelines and rationale for use of open systems or open architecture and develop or modify policies accordingly 3 6 6 2 Develop Operating Procedures 3 6 6 2 1 Change Control Define procedures for maintenance of interface code installation of new HL7 versions and modifications to applications software Control the environment and fully test new releases or updates 3 6 6 2 2 Restart Recovery Define procedures to handle downtime situations system and interface restart recovery and re synchronization and disaster or contingency planning 3 6 6 2 3 Backup Restore Backup and restore procedures are even more important and should be developed or modified as needed to ensure data integrity and recoverability 3 6 6 2 4 Table Maintenance The addition of new application systems may increase the number of duplicate tables or dictionaries stored in multiple systems In order to minimize transactions that are rejected by the Page 3 8 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 3 Implementation Methodology interfaces due to unsynchronized tables develop procedures to control the order and frequency of table maintenanc
459. nd physiologic signals Task forces in HL7 are also busy developing prototype transactions with new state of the art technologies such as CORBA and Microsoft s OLE objects 1 4 COOPERATION WITH OTHER STANDARDS DEVELOPING ORGANIZATIONS HL 7 has a pure focus on health care informatics standards and cooperates closely with other standards developers such as American Society for Testing and Materials ASTM Accredited Standards Committee X12N American College of Radiology ACR National Electrical Manufacturers Association NEMA National Council for Prescription Drug Programs NCPDP and Institute of Electronics and Electrical Engineers IEEE directly and via the ANSI Healthcare Informatics Standards Board HISB Examples of such cooperative efforts include cross copyrights with ASTM and hosting joint working group meetings with IEEE ACR NEMA X12N and NCPDP Page 1 2 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 1 Introduction HL7 has pioneered the provision of its minutes and standard drafts at no cost through Internet FTP servers on mcis duke edu Internet and supports a discussion group on the HL7 Virginia EDU list server We encourage other standards organizations to do the same 1 5 OVERVIEW This section is an excerpt from Chapter 1 of the HL7 Version 2 3 Standard and contains a description of the conceptual basis of the HL7 Standard t
460. ndard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 5 5 Sequence Numbering Chart SEQUENCE NUMEER PROCESSING BY RECEIVING SYSTEM SOT Sequence Number ESN Expected Sequence Number ESN State Expected Sequence Number State Is this a type of message that requires SQ s Process according to that type and ignore sequence numbers Do not change Incoming is an integer SQ gt 1 either the ESN State or the ESN Example If this message is a network management message from receiving system ignore sequence numbers altogether Send an MSA with an AR Example The Continue right message but the wrong sequence number format Y What is the ESN State Expected Sequence Number State ESN State 1 ESN State NONE An Expected Sequence Number exists or is defined An Expected Sequence Number does not exist or is not defined Set the following Incoming SQ 0 Incoming SQ 0 Set the following ESN 1 ESN 1 ESN State NONE ESN State NONE Set the following SQ must be gt 1 Incoming SQ gt 1 Set the following ESN Existing ESN Set the following ESN 1 ESN State ESN gt 1 ESN Existing ESN ESN State NONE ESN State ESN gt 1 Send MSA with AA Refer to the Message with NO YES Send MSA with AA Sequence Number Chart error Set the following ESN Incoming SQ ESN State gt 1 This must be a full message and the
461. nding system indicating that a legitimate transaction has arrived for processing Rejecting accepting transactions based on data that is part of the transaction Modifying field values in a transaction based on conditions that can be defined within the AIE application Modifying field values in a transaction based upon values within transaction fields Routing transactions based upon values within transaction fields Updating validating database code tables based upon values within transaction fields Lengthening shortening a transaction by adding removing data based on pre defined code tables or conditions that may require mathematical computation Translating a batch file into a series of real time transactions Translating a series of real time transactions into a batch file Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 11 Compressing the data packet and or individual data elements prior to sending to the receiving system 12 Translating transactions from ASCII to EBCDIC and vice versa prior to sending to the receiving system 13 Providing error recovery and validation 14 Combining data elements of multiple transactions into a single transaction 15 Splitting a single received transaction into multiple sending transactions 16 Processing binary data e g GIF to JPEG 17 Parsing by extracting and
462. nding transactions individually or in batches and several approaches to representing textual reports Not all systems have needed to implement all of these options e There are ambiguities in the specification This is a major concern in the areas of Query transactions e Optionality of fields is defined by segment rather than by how the segment is used for a specific trigger event Since the fields may be required for some trigger events and not for others almost every field ends up being shown as optional e As the health care business changes and as HL7 gets applied in widening frames of reference needs are discovered that have not been addressed When these are brought to the attention of the appropriate Technical Committee they are usually addressed However the implementation where the discovery proceeds will have to use the HL7 provisions for site specific variations to address the need before a revised standard is available e Because the lower level protocols are not HL7 standards the enterprise or its vendors may opt to use a different approach e HL7 has maintained a policy of backward compatibility in subsequent releases of the Standard When ambiguities or errors are found in the Standard this makes it difficult to fix the problems e Some prominent vendors have simply declined to implement some specific features of HL7 within an interface that is primarily based on HL7 Their customers have accepted these compromises These a
463. ndix A HL7 Transaction Checklist A 4 3 3 O01 Dietary Order Message ORM Originator A or B Message Header Notes and Comments Patient Identification Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Insurance Information Insurance Information Add l Info Insurance Information Cert Guarantor Information Allergy Information Common Order Dietary Orders Notes and Comments Results Notes and Comments Common Order Diet Tray Notes and Comments A 4 3 4 Q06 Query Response for Order Status DSR Originator A or B Message Header Message Acknowledgment Error Notes and Comments Query Definition Query Filter Patient Identification Notes and Comments common Order Observation Request Notes and Comments Clinical Trial Identification Continuation Pointer Health Level Seven Implementation Support Guide Page A 35 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 3 5 O02 Dietary Order Response ORR Originator A or B Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Dietary Orders Notes and Comments Common Order Diet Tray Notes and Comments A 4 3 6 O01 Stock Requisition Order ORM Originator A or B Message Header Notes and Comments Patient Identification Additional Demographics Notes and C
464. ndix F Sample Templates FROM Clinical Data Repository 8 9 3 Identify Code Values Translations Lab Orders FROM Clinical Data Repository 8 9 4 Identify Translation Requirements of Messages Segments Lab Orders FROM Clinical Data Repository 8 9 5 Complete Final Specification Lab Orders FROM Clinical Data Repository 8 9 6 Obtain Lab Orders FROM Clinical Data Repository Spec Signoff 8 10 Synchronization of Test Procedure Directories for Orders TO Lab Analysis 8 10 1 Pathology 8 10 2 Laboratory 8 10 3 Microbiology 8 10 4 Blood Bank 8 11 Detail Designs 8 11 1 Interface Engine Detail Design Communication Managers Queues etc 8 11 1 1 Detail Design Walk through 8 11 2 Lab System Interface Detail Design for SW development configuration 8 11 2 1 Detail Design Walk through 9 SOFTWARE DEVELOPMENT 9 1 Configure Purge Security 9 1 1 Test Purge 9 2 Configure LAB Interfaces 9 2 1 Configure LAB I F Lab System 9 2 2 Configure LAB I F Ordering System 9 2 3 Configure Communication Managers LAB 9 2 3 1 One for each LU6 2 connection e g ADT Patient Demographics Clinician Master File Update Page F 74 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 9 2 3 2 One for each TCP IP connection e g Clinical Data Repository 9 2 4 Configure Translation Rules 9 2 5 Configure Routing Rules 9 2 6 Config
465. ness transactions between institutions regarding the interchange of claims benefits or other financial information are the responsibility of ASC X12N the insurance subcommittee of X12 In February of 1994 HL7 and X12 signed an agreement to improve coordination efforts and have identified that technical issues must be harmonized Both groups agree to migrate to the appropriate level of resolution of potentially overlapping work by utilizing user and standards communities and anticipated health care reform requirements Since then HL7 and X12 have created two bodies to address the goals of harmonization 1 HL7 X12N Coordinating Ad Hoc Steering Committee to oversee efforts and 2 HL7 X12N Joint Coordinating Committee to develop and implement specific plans to achieve harmonization Both committees have convened a meeting in 1994 and will continue their work through 1997 3 ASTM 1238 88 Laboratory Data Reporting An active liaison effort between the ASTM committee and the Working group has resulted in minor changes in the ASTM specification to Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 1 Introduction enhance compatibility changes in the HL7 control specifications to enhance compatibility and the development of the entire Ancillary Data Reporting chapter developed jointly by the committees and built on the ASTM standards This
466. ning in use of interfaced systems 3 6 7 1 3 Schedule Training Once training materials are available schedule training Training should be scheduled conveniently for users It should also be scheduled over a period of weeks with time between sessions for users to get comfortable with the changes and develop a deep understanding Training can also be scheduled during parallel testing after all major bugs have been addressed This allows for the overall schedule to be compressed by overlapping these functions The schedule should also account for preparing the training facility This may include temporary cabling and workstations or off hours use of production areas Training should be conducted close to the actual implementation date so any new methods are still fresh when new systems are brought into production Health Level Seven Implementation Support Guide Page 3 9 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 3 Implementation Methodology 3 6 7 1 4 Develop User Manual As a final step in the training process each department should receive a user manual This manual should cover standard daily operations departmental specific procedures and a reference to available support The manual may also contain reference or look up tables for departmental data entry 3 6 7 1 5 Conduct Training Training should be held at the user site but away from user work area for initial sessions This allow
467. nistration Administration includes those functions that are necessary to ensure the day to day operation of the AIE Administrative functions differ from interface implementation functions in that they do not address the interface configuration or mapping Administrative functions concentrate on the performance of the system the successful completion of transactions access to the system and maintenance functions Describe in detail the administration capabilities of the AIE a Security b Error Logging c Transaction Logging d Activity Logging e Error Escalation f System Link Escalation g User Access h Distributed Administration i e ability to allow different administrators to perform different administrative functions without providing access to all administrative functions i System Wide Parameters 2 Describe any administrator training included with the system 3 How much time should the St Anybodys Medical Center AIE Administrator spend administering the system Describe daily weekly and monthly that should be performed Health Level Seven Implementation Support Guide Page F 31 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 8 Hardware Operating System Technical Specifications This section defines the technical specifications for the product platform both necessary and desirable for implementation of an AIE at St Anybodys Medic
468. nt MDM ACK Document replacement notification MDM ACK Document replacement notification and content MDM ACK Document cancel notification QRY DOC Document query VXQ Query for vaccination record VXX Response to vaccination query returning multiple PID matches Page B 68 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists VXR Vaccination record response VXU Unsolicited vaccination record update ORU Waveform result unsolicited transmission of requested information QRF Waveform result response to query Health Level Seven Implementation Support Guide Page B 69 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols C 1 INTRODUCTION The HL7 protocol will be used primarily in network environments Most of the details of error detection and correction are handled by the lower levels of any reasonable network protocol and are not appropriate for the HL7 Standard Many mini and mainframe computer systems however operate in communication environments that do not provide sufficient lower layer functionality In these cases HL7 offers several alternate lower layer protocols to suit different environments It is not a requirement of a vendor to implement any of these protocols to be considered HL7 compliant at the encoding rule level a b
469. ntation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Chapter 1 Introduction ICCS Commission on Professional and Hospital Activities ICD 9 International Classification of Diseases 9th Revision ICD9 CM International Classification of Diseases Clinical Modification Manual of Clinical Microbiolog NANDA North American Nursing Diagnosis Association Philadelphia PA NDC National drug coded NIC Nursing Interventions G ee Iowa Intervention Project U of Iowa NLM Unified Medical Languag Omaha System Read Omaha Visiting Nurse Association Omaha NE Clinical Classification of Medicine SNOMED III Systemized i E of Medicindil WHO Drug Code UMDNS Universal Medical Device Nomenclature zc FDA K10 Device Codes Device and analyte process code LOINC Laboratory Object Identifier and Numerical Codd 1 6 4 Other Applicable Documents ASTM E31 12 Draft Dec 19985 A Standard Specification for Representing Clinical Laboratory Test and Analyte Names Draft ASTM E1467 91 Standard Specificatio Between Independent Computer System r Transferring Digital Neurophysiological Data ASTM E1394 A Standard Specification for Transferring Information Between Clinical Instruments and Computer System ASTM E1381 Standard Specification for t Clinical Instruments and Computer System ow level Protocol to Transfer Messages between McDonald CJ Hammond WE Standard formats for electronic transfer of clinical data Annals of Int
470. nter New York NY Diane Dwyer Maryland Dept of Health and Mental Hygiene Baltimore MD Arden Forrey University of Washington Seattle WA Bill Francis Hewlett Packard Andover MA Andy Gajda Laboratory Corporation of America Burlington NC Norbert Goldfield 3M Wallingford CT Alan Golichowski Indiana University Hospital Indianapolis IN Brian Griffin Quest Diagnostics Rutherford NJ Karl Hammermeister Denver VA Medical Center Denver CO Ed Hazell Lifechem Laboratories Rockleigh NJ Gil Hill Hospital for Sick Children Toronto ON Canada Stan Huff Intermountain Health Care Salt Lake City UT Kathy Hutchins Regenstrief Institute Indianapolis IN Kathy Kammerer Quest Diagnostics Teterboro NJ Dennis Leavelle Mayo Medical Laboratories Rochester MN Diane Leland Riley Hospital for Children Indianapolis IN Pat Maloney Quest Diagnostics Teterboro NJ Doug Martin Roudebush VA Medical Center Indianapolis IN Bruce Meltzer Ernst amp Young Boston MA Ken McCaslin SmithKline Beecham Collegeville PA Clem McDonald Regenstrief Institute and Indiana U School of Medicine Indianapolis IN Bill Meilhan Laboratory Corporation of America Burlington NC Dan Pollock Centers for Disease Control Atlanta GA Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 John Stelling Bill T
471. ntifies the duration of the Study without specifying an exact time ENCTR identifies the Encounter ER visit hospital stay etc Drug doses as required to report the mass or amount of substance of a drug given would be identified by recording DOSE as the system sample and MASS as the kind of quantity A point dose would be the dose given at a single point in time e g 250 mg of ampicillin To represent the total amount of a drug given in 24 h one would record 24H in the third subfield and MASS RAT as the property Example GENTAMICIN MASS PT DOSE QN GENTAMICIN MRAT2AH DOSE QN Sample volumes reported for timed measurements are carried in other fields or as separate test results in other OBX segments Page H 24 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Table 8 Duration Categories PT To identify measures at a point in time This is a synonym for spot or random as applied to urine measurements STDY Duration of the study ENCTR Duration of an encounter hospital stay visit PROCEDURE Duration of the procedure surgery etc XXX Not specified time will be reported in another part of the electronic message star Life of the unit Used for blood products 5 minutes 8 hours 2 weeks 10 minutes 9 hours 3 weeks 15 minutes 10 hours 4 weeks 20 minutes 12 hours 1 month 30 days
472. o 9959 23 00774 Guarantor Credit Rating Code CE SSCS SCS 24 00775 Guaramor Death Date fime 1 TS eo A ESA 00776 GuarantorDeathFlag TE TD D URT Health Level Seven Implementation Support Guide Page B 15 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 26 00777 Guarantor Charge Adjustment Code CE 80 0218 27 00778 Guarantor Household Annual Income CP ao 0 28 00779 Guarantor Household Size NM oi S 29 00780 Guarantor Employer ID Number CX QO CTT S 30 00781 Guarantor Marital statusCode IS D Com 31 00782 Guarantor Hire EffectiveDate DT ss 32 00783 EmplymenStpDae DT ss 33 00755 Living Dependency PS 23 sy 34 00145 Ambulatory Status IS 0009 35 00129 Citizenship o IS 0 A Cou 36 00118 PrimaryLanguage LI CE 600 J 2 23 Q299 37 00742 Living Arrangement I 2 0 0222 38 00743 Publicity Indicator CE 80 P 2 Copa 39 00744 ProtectionIndicator ID D Ce 40 00745
473. o identify the need for any systems integrator and vendors for design implementation Clearly define the expected role of the systems integrator and or vendors Training And Conversion Planning Establish an overall user training plan and methodology for user training if changes resulting from implementation of the HL7 interface s will be visible to the user community Establish an overall communications strategy to convey project progress to the user community and management Establish an overall MIS training program to provide support for an HL7 environment Establish conversion plans as necessary for existing systems data bases and files Decide what data needs to be converted Include conversion approaches for archived data Specify methods for acquisition of data elements not available in old systems if appropriate MIGRATION STRATEGY The purpose of the migration strategy is to establish a plan for migrating from the current systems environment to HL7 environment It is intended to serve as a high level planning guide and will need to be supported by a detailed conversion plan for each specific system installation and interface 2 7 1 Project Timing And Sequence Identify and prioritize all of the required projects systems interfaces and establish an overall installation conversion sequence Develop overall time frames and planning charts for each project including production dates and priorities for individual systems Health Level
474. o we have a ratio scale Kelvin temperature is a ratio scale A QN value may be reported as a value for a continuous scale as is the case for serum sodium or it may be reported from a series of discretevalues as is the case for titers e g 1 16 1 32 Some observations have values that are well ordered e g 1 2 3 or negative intermediate positive but the values have no linear relationship to one another We do not know that positive is two or three times as much as intermediate we just know that positive is more than intermediate These kinds of observations have an ordinal scale ORD Some observations take on values that have no relative order Think of the numbers on football jerseys These simply identify the players they do not provide quantitative information or rank ordering of the players We refer to these as nominal NOM in scale Blood culture results provide a good example The value can be E coli or a code for E coli or staph aureus Other examples are admission diagnoses discharge diagnoses Any tests or measure that looks broadly at patient or specimen and reports the name of what it finds is a NOM scale The values of nominal scaled observations are assumed to be taken from a predefined list of codes or from a restricted vocabulary Some observations are reported as free text narrative The content is not drawn from a formal vocabulary or code system A dictated present illness would be an example of a scale o
475. oducer systems and used by Consumer systems After the demo is complete we will fold the experience in producing a ballotable version of the OMS and production quality specifications for the HL7 OLE Objects Microsoft has indicated that it will again develop freely available code to accelerate implementations of the final objects The purpose of the abstract OMS is to ensure that similar developments in the other technologies are as common as possible while still developing a pragmatic approach that can be efficiently implemented in the technologies Groups of interested parties has begun reviewing the OMS from the points of view of CORBA and OpenDoc The CORBA group is committed to writing IDL and other code and is considering the formation of a prototyping project similar to that being implemented for OLE Because this approach is modeled so closely on existing HL7 we believe that we can complete the prototypes develop and ballot the OMS and develop recommendations for the specific technologies within a year This is an aggressive schedule but the SIGOBT has been meeting eight or more times a year to facilitate progress How Does the SIGOBT Work Relate to the HL7 Data Modeling and Version 3 The following chart summarizes various activities that are going on through SIGOBT and how they relate to the activities of the QA Data Modeling Group and the plans for Version 3 Image here in Web version The diagram also shows the effort of the HL7 Q
476. oes not know the data content of the messages it transfers The following functions are performed at a higher level and should not be confused with the communications protocol described here e Queuing and prioritization of messages to be sent e Distributing messages received to the correct server application e Asynchronous storage and processing of messages e Relating application replies to requests e Guaranteed completion of remote operations A single communications module and physical line may support multiple applications Although throughput message priorities or fault tolerance may dictate a multi line design Page C 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols C 3 1 4 Communication Control Characters The following table defines the communication control sequences A brief description of each sequence follows the table References to these control sequences is used in describing the protocol throughout this document Note that the Termination Character must be appended to the transmission sequences EOT ENQ NAK and ACKN A Termination Character is also appended to transmission blocks after the checksum Control Sequences Abbreviation Characters Actual Bytes hex TERM CR 0D SOH SOH 01 STX STX 02 ETB ETB 17 ETX ETX 03 EOT EOT 04 ENQ ENQ 05 RINT DLE 10 3C NAK NAK 15 ACKO DLE 0 10 30 ACKI
477. of delivery mechanism e g nasal cannula An analogous approach is used for reporting many kinds of associated variables when the variables are not conventionally embedded in the name in part because there are too many levels of the variables and it is not feasible 2 2 2 4 Generic challenge specifications We allow for very specific challenges and less specific challenge designs a 30M post challenge b 1st specimen post challenge Some challenges will be specified fully as described above e g 30M post 100 gm glucose pc We will also include challenges without the amount specified e g 30M xxx glucose and those that do not specify the exact time e g 1st specimen post xxx glucose pc or even more generic Ist specimen post challenge These latter varients are needed to accommodate the submissions to reference laboratories that do not fit any common protocol and do not report the details of the study protocol to the referenc laboratory 2 2 2 5 Acute and convalescent pre amp post immunization specimens To assess the efficacy of immunizations by measuring antibody titres before and after the immunization we obtain evidence for acute infection by assessing acute and convalescent screens Both of these cases are assessed by the Ist specimen 2nd specimen option e g STREPTOCOCCUS AB 1ST SPECIMEN ACNC PT SR QN 2 3 3 Adjustments corrections 3rd subpart The third subpart of the data element contains calculations that adjust or cor
478. omments Patient Visit Patient Visit Additional Info Insurance Information Insurance Information Add l Info Insurance Information Cert Guarantor Information Allergy Information Common Order Requisition Detail Notes and Comments Results Notes and Comments Billing Page A 36 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 3 7 O02 Stock Requisition Order Response ORR Originator A or B PT appa Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Requisition Detail Notes and Comments A 4 3 8 001 Non Stock Requisition Order ORM Originator A or B Message Header Notes and Comments Patient Identification Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Insurance Information Insurance Information Add l Info Insurance Information Cert Guarantor Information Allergy Information Common Order Requisition Detail Requisition Detail 1 Notes and Comments Results Notes and Comments Billing Health Level Seven Implementation Support Guide Page A 37 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 3 9 O02 Non Stock Requisition Response ORR Originator A or B PT
479. omparison with version 2 2 what advantages does it offer 5 1 5 2 1 2 Are there any functional issues that should be addressed prior to Implementing this Chapter a condito E A R RRE 5 1 5 2 2 Financial Management responses by Freida Hall 5 2 5 2 2 1 What was the driving force behind the creation of version 2 3 In comparison with version 2 2 what advantages does it offer 5 2 5 2 2 2 What does version 2 3 not address at this time Will these issues be covered in the next release uu dcus etie EA EE AEN EE 5 2 5 2 2 3 What key criteria should be used in determining if members should upgrade to version 2 3 or stay with version 2 2 What key functional issues would drive this TBBgratlOn s A A AA A AAA e A AA 5 2 5 2 3 Master Files responses by Mark Shafarman ee eee eee 5 2 5 2 3 1 What was the driving force behind the creation of version 2 3 In comparison with version 2 2 what advantages does it offer 5 2 5 2 3 2 Are there any functional issues that should be addressed prior to implementing this chapter sii ass 5 2 5 3 SUMMARY BY CHAPTER OF CHANGES FROM VERSION 2 2 to 2 3 5 3 AV Sell ING We KE 5 3 mod Changes Do Existino KEE 5 6 5 3 3 Chapter 2 Control QUE i eee eod arte e ia EE 5 7 25 2 9 1 New Data EE 5 7 5 3 3 2 ING WDECIOIS Has dotado nunica A nob smi cake 5 7 0 3 3 IMESSages SeBTITGUES A A ood e ais coq e tas ent iita e meas eM tea cede be te
480. on Cert Accident Information Universal Bill Information Universal Bill 92 Information Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 2 8 A08 Update Patient Information ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Next of Kin Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Adal Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information A 4 2 9 A09 Patient Departing ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Diagnosis Information A 4 2 10 A10 Patient Arriving ADT Originator A or B Health Level Seven Implementation Support Guide Page A 17 for HL7 Standard Version 2 3 O 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Diagnosis Informat
481. on Additional Demographics Merge Information A 4 2 44 A44 Move Account Information Patient Account Number ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Health Level Seven Implementation Support Guide Page A 31 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 2 45 A45 Move Visit Information Visit Number ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Patient Visit A 4 2 46 A46 Change External ID ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information A 4 2 47 A47 Change Internal ID ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information A 4 2 48 A48 Change Alternate Patient ID ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merge Information Page A 32 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 2 49 A49 Change Patient Account Number ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Merg
482. on Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 5 6 Program File Naming Standards 5 6 1 Files 5 6 2 Rules 5 6 3 Tables 5 7 Login Usernames 6 TOOLS ACTIVITIES 6 1 Evaluate Development Production Software 6 2 Development Tools 6 2 1 Version Control System 6 2 1 Evaluate Version Control Tools Unix IBM DEC or other 6 2 1 Order Version Control Tools 6 2 1 Receive Version Control Tools 6 2 1 Install Version Control Tools 6 2 1 Setup Version Control Environments 6 2 1 Implement Version Control Tools 6 3 Testing QA Tools 6 3 1 Test Data Source Content 6 3 1 Evaluate Testing Tools Unix IBM DEC or other 6 3 1 Order Testing Tools 6 3 1 Receive Testing Tools 6 3 1 Install Testing Tools 6 3 1 Setup Test Tool Environments 6 3 1 Integrate Testing Tools 6 4 Implementation Tools 6 4 1 Distribution 6 4 1 Evaluate Distribution Tools Unix IBM DEC or other 6 4 1 Order Distribution Tools Health Level Seven Implementation Support Guide Page F 65 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 6 4 1 3 Receive Distribution Tools 6 4 1 4 Install Distribution Tools 6 4 1 5 Configure Distribution Tools 6 4 1 6 Implement Distribution Tools 6 4 2 Synchronization 6 4 2 1 Evaluate Synchronization Tools Unix IBM DEC or other 6 4 2 2 Order Synchronization
483. on by IN1 35 Company Plan Code IN1 42 Insured s Employment Status X X X X X X X NN NENN MENS NEM x a E x RECH e ss x x i Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Message added PV2 ALI OBX IN2 IN3 UB2 X Message added PV2 OBX Length changed from 5 to 10 Changed from 16 ST to 60 CE Changed from 8 ID to 60 CE Length changed from 19 to 26 Changed from 4 ST to 60 CE Changed from 2 ID to 60 CE no longer repeating Length changed from 19 to 26 Datatype changed from ID to CK May repeat up to 3 times Changed from 8 DT to 26 TS Datatype changed from CM to CN X X Datatype changed from ST to ID Datatype changed from ID to 60 CE Length changed from 19 to 26 Datatype changed from ST to NM X X X X X X X X X X X X X Page 4 13 Final Version 6 98 Chapter 4 HL7 Version 2 2 Overview Segment Seq UB1 3 Blond furn pints of 40 x Datatype changed from STto NM UBI 4 Bloodreplaced pints 41 x Datatype changed from STto NM UB1 5 Blood not rplcd pints 42 X Datatype changed from ST to NM UBI 6 Co nsuancedays 25 x Datatype changed from STto NM UBI 8 Covereddays 23 x DatatypechangedfromSTtoNM_ UBI 9 Non covered days 4 x Datatype changed from STto NM ID NM UBI 10 Value am
484. oneal Translingual Intrasynovial Urethral Intrathecal Vaginal Intrauterine Ventimask Intravenous Wound Mouth Throat Examples GLUCOSE BS 100 G GLUCOSE PO MCNC PT SER QN GLUCOSE 30M POST 100 GM GLUCOSE PO MCNC PT SER QN GLUCOSE 2H POST 100 GM GLUCOSE PO MCNC PT UR QN GENTAMICIN TROUGH MCNC PT SER QN For drug peak obtained at a time presumed to reflect the highest concentration and trough obtained at a time presumed to reflect the lowest concentration measures the nature of the substance loaded is the same as the analyte name and need not be included 2 2 2 2 Physiologic challenges Some challenges are defined in terms of a physiologic stress not a dose of a chemical substance The LOINC names currently cover calorie fasts no calorie intake exercise and fluid restrictions These challenges are denoted by codes given in Table 6 In the case of such challenges the syntax also includes the duration of the challenge E g duration POST duration physiologic challenge E g CHOLESTEROL POST 12H CFST Health Level Seven Implementation Support Guide Page H 19 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC Table 6 Nature of Challenge Calorie fast No caloric intake food for the period specified in the time part of the term e g POST 12H CFST Exercise undertaken as challenge can be quantified Fluid fast No fluid intake for the period specified T
485. onitoring step by step processing flow d Real time reviewing of results e Monitoring statistics 3 Documentation Utilities that create as a by product of interface application coding documentation of a Record layouts b Processing flows c Special reports 4 Prototyping While interface coding is being developed utilities that provide for a Unittesting b Overall system integration stress parallel testing Page F 26 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 5 Object Oriented Programming Facilities that allow system developers to a Manipulate data objects and formats without writing the underlying programming language b Establish relationships between data elements and systems that result in a test or prototype interface environment being created c Save and reuse previously designed and tested relationships for function testing and debugging 6 Database Data Definition Facilities that provide for a Defining maintaining a data dictionary of commonly interfaced items and data conversion tables b Any database management functionality inherent in the AIE 7 Language Identify availability of a Intrinsic language s b Third party language s c Debugger s d Code Library tool s e Editor s 8 Programmer Exits hooks Facilities that provide for a Conditionally passing
486. operating system and other third party documentation provided 2 Training a Describe the training approach and schedule you would recommend for St Anybodys Medical Center Indicate incremental training costs specify training materials user materials and the number and skill levels of the employees required for training b Describe your methodology for incorporating a testing region and a training region c Describe any computer assisted instruction modules that you have available d Do you provide training in the use of routines to build system files dictionaries tables e Describe the operations training available to data processing personnel Does it include Page F 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates e Training on hardware maintenance and repair e Recovery from hardware and software failures e Running hardware diagnostics e Interpretation of hardware diagnostics f Do you provide the final end user training manuals g Is on site training available h Is training available for every release Is it included in the price of the release i What are the qualifications of your trainers F 1 7 Application Interface Engine Features and Functionality This section defines the functions and development tools both necessary and desired for implementation of an AIE at St Anybodys Medical Center E
487. or have a different clinical reference ranges For instance whole blood glucose tested with a chemstrip might be distinguished in the method field The list of methods given in Table 13 is not exhaustive we have included only those methods which are abbreviated in the database or which otherwise require explanation or clarification Most methods are fully spelled out in the database and should be self explanatory Laboratories do not include the method as part of the name for most common chemical and hematological tests They often need the freedom to choose the instrument according to time of day urgency of the request for service availability of the instruments and so on even though the instruments may employ different methods The laboratories then adjust each of the interchangeable instruments to produce equivalent results even though the instruments may use different methods So we do not want to distinguish too finely on the basis of methods Though method is rarely significant for many chemical and hematological tests it is often important to immunochemical serology testing because the sensitivity and specificity of some tests varies greatly with the method So you will commonly see methods included in microbiology tests and coagulaiton tests within the LOINC database This does not mean that information about the method is irrelevant but that it is not always a meaningful part of the test name It is an essential element of the internal
488. oratory class 2 Clinical class Regression equation details for many OB US calculated terms Maps to Multum Inc database of codes for drugs Page H 43 Final Version 6 98 Appendix H LOINC Field Name Description DEEDS_CD Data Elements for Emergency Department Systems Codes CDC This field contains the DEEDS code value which maps to the LOINC code in question CSCQ_FRNCH_NM French name for LOINC term Supplied by Centre Suisse de Contr le de Qualit9 This field contains extended characters and will not transfer correctly to 7 bit systems SPECIES Codes detailing which non human species the term applies to If blank human is assumed EXAMPL_ANSWERS For some tests and measurements we have supplied examples of valid answers such as 1 64 negative 1 16 or 55 This differs from the ANSWERLIST field which details possible choices for nominal scale terms Page H 44 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Table 18 Classes Abbr ABXBACT ALLERGY BC BLDBK CELLMARK CHAL CHALSKIN CHEM COAG CYTO DRUG DRUGDOSE FERT HEM HLA MICRO PATH SERO SURGPATH TOX Laboratory Term Classes Antibiotic susceptibility Response to antigens Cell counts blood CSF pleuritic fluid Blood bank Cell surface models Challenge tests Skin challenge tests Ch
489. otification Observation Result one or more required R R R R R R Health Level Seven Implementation Support Guide Page A 63 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 7 5 TO5 Document Addendum Notification MDM Originator A or B Message Header R Event Type R Patient Identification R Patient Visit R Document Notification R A 4 7 6 TO6 Document Addendum Notification and Content MDM Originator A or B Message Header Event Type Patient Identification Patient Visit Document Notification Observation Result one or more required D D D D om om A 4 7 7 TO7 Document Edit Notification MDM Originator A or B Message Header R Event Type R Patient Identification R Patient Visit R Document Notification R A 4 7 8 TO8 Document Edit Notification and Content MDM Originator A or B Message Header Event Type Patient Identification Patient Visit Document Notification Observation Result one or more required R R R R R R Page A 64 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 7 9 T09 Document Replacement Notification MDM Originator A or B Message Header Event Type Patient Identification Patient Visit Document Notification DDD DdD m A
490. ount and code x Datatype changed from CM to UBI 11 Number of grace days x Datatype changed from ST to UB1 16 Occurrence 28 32 x Datatype changed from ID to CM 4 3 6 Chapter 7 Observation Reporting 4 3 6 1 Messages Segments Tables Msg Segment Name New Change Description ORU S DEE Message removed the MSA ox OMI Test Observation Master X Segment General OM2 Test Observation Master X Segment Numeric Observation Categorical OMA Test Observation Master X Segment Observations that require specimens be AEN Observation batteries OM6 Test Observation Master X Segment Observations that are claculated from other Observations 0125 Value types X Table new values added DT RP NM TQ ID SI CM CQ CF MO A PARA codes 4 3 6 2 Data Elements OBX 2 Value type x Changed from optional to required OBX 4 L teeragon sub id x Changed from optional to conditional OBX 5 Observational values x Changed from required to conditional OBX 6 Units Changed from20STto60CE OBX 8 Abnormal Flags x Datatype changed fromSTtoID OBX 12 Date last Obs Normal X Length changed from 19 to 26 pee A ae OBX 13 User defined access checks x o O OBX 14 Date time of the D s osea TTT x E S o o o OBX 16 Responsible Observer___ _x_ ___ ______________ Page 4 14 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard
491. owledgment RRD A 42 A 4 3 16 O01 Pharmacy Treatment Give Message RGV eee A 43 A 4 3 17 O02 Pharmacy Treatment Give Acknowledgment RRG A 43 A 4 3 18 O02 Pharmacy Treatment Administration Message RAS A 44 A 4 3 19 002 Pharmacy Administration Acknowledge RRA A 44 A 4 3 20 ROR Pharmacy Treatment Order Response ROR sees A 45 A 4 3 21 RAR Pharmacy Treatment Administration Information RAR A 45 A 4 3 22 RDR Pharmacy Treatment Dispense Information RDR A 46 A 4 3 23 RGR Pharmacy Treatment Dose Information RGR A 46 A 4 3 24 RER Pharmacy Treatment Encoded Order Information RER A 47 A 4 3 25 VOI Query for Vaccination Record VXQ sss A 47 A 4 3 26 V02 Response to Vaccination Query Returning Multiple PID Matches CVX iter aite tier IR veis v NIENTE A 47 A 4 3 27 V03 Vaccination Record Response VXR sese A 48 A 4 3 28 V04 Unsolicited Vaccination Record Update NS A 48 AAA EHNEN A 49 A AAT POI Add Patient Accounts BAR sss A 49 A 4 4 2 P02 Purge Patient Accounts BAR A A 49 A 4 4 3 P03 Detail Financial Transaction ORT A 50 A 4 4 4 P04 Generate Bills and A R Statements QRY sese A 50 A 4 4 5 POS Update Account BAR seene A 51 A 4 4 6 P06 End Account
492. oyer name X Length changed from 60 to 130 data type changed from CN to XCN repetition changed to Y IN2 4 Employer information data X DatatypechangedfromIDtoIS MS H Y E repetition changed to Y number IN2 7 Medicaid case name X Data type changed from PN to XPN opem e IN2 8 Medicaid case number X Datatype changed from NM to ST IN2 9 Champus sponsor name X Data type changed from PN to XPN Repetition changed to Y IN2 10 Champus ID number X Datatype changed from NM to ST IN2 11 Dependent of Champus X Length changed from 1 to 80 data type epe LJ oes E n IN2 14 Champussevie X DatatypechangedfromIDtoIS IN2 15 Champusrank gade X DatatypechangedfromIDtoIS IN2 16 Champusstatus T Datatype changed from IDa LIN221 Blooddeducible X Datatype changed from NM to ST IN2 22 Special coverage approval X Data type changed from PN to XPN name repetition changed to Y IN2 24 Non covered insurance Data type changed from ID to IS code Length changed from 6 to 59 data type IN2 25 Payor ID changed from ST to CX repetition changed to Y IN2 26 Payor subscriber ID Length changed from 6 to 59 data type changed from ST to CX repetition changed to Y Data type changed from IS to ID IN2 27 IN2 31 IN2 32 N2 33 N2 34 Primary language IN2 35 N2 36 Publicity indicator IN2 37 N2 38 N2 39 IN2 40 N2 41 IN2 42 N2 43 IN2 44 Insured s employ
493. p PEERS B 35 B 1 66 PD1 Patient Additional Demographie B 36 B 1 67 PDC Product Detail Country ici ssc ridad era ridi va en S s enne S EE dei B 37 B 1 68 PEO Product Experience Observations dri ean iecit Suae et B 37 B 1 69 PES Product Experience Sender eene piace dii nete B 38 BT FO RED Patient Identification ege Eeer e B 39 B UE PRIA there EA B 40 B 1 72 PRA Practitioner Detail eere oe ege HR SYN NAR US S RV aires B 40 A a e a a r a a a a B 41 B 7 PRD Provider Data ech deed Ee B 42 B 1 75 PSH Product Summary Header sees B 42 See PVT S Patent VIE a B 43 B 1 76 1 PV2 Patient Visit Additional Information eene B 44 B TT OAK Query Acknowledbment T B 46 BLR CORD lt Query Deb mito oie add ote ia cbe eg HSHT aai Denge B 46 B 1 79 ORE Query Biter siet ree Dye EXEUNT OSEE RSEN REHAB SERA Ed ALE B 46 B IS0 RDEP Table Row ettelbreck B 47 BALS RDT eT able ROW R 1 oH S ene ende EI I e el tete unie e nee As B 47 B 1 82 RFT Referral Information oii illa ec etti era ase ea Ea nee dn Ra erudi AEN Pe vsus B 47 B 1 83 ROT Requisition Detail EE EE B 48 B 1 84 ROD Requisition odds B 48 B 1 85 RXA Pharmacy Administration ec oe doit pe oe eee Lied es dede ue e dpa B 49 B 1 86 RXC Pharmacy Components sees sees eee eor sve ee eegene B 50 B 1 87 RXD Pharmacy Dispense ees eee eee B 50 I T5 RXB Pharmacy eeh ch sa as aca ane va doers de Lob Sea B 51 B 1 59 E XGT Pharmacy IVO essc ee
494. particular subclass of antibodies specify the subclass IGM IGG IGA or IGD e g Hepatitis A Page H 16 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 AB IGG Hepatitis A AB IGM If more than one species is included in the measurement all are listed in the subclass e g Hepatitis A AB IGM IGG with a plus sign 4 to separate the subspecies There should be no spaces between the plus sign and the words it connects If two constituents are measured as one quantity both should be named and the component separated by a plus sign e g Alprozolam Metabolytes 2 2 2 Challenge test 2nd subpart The second subpart contains information necessary to interpret challenge or loading or tolerance tests Variables that report the result of a measurement taken a certain amount of time post challenge e g glucose after an oral glucose tolerance test must be distinguished according to the challenge and the time post challenge Thus the second subpart has a substructure that identifies the time interval or time difference and the challenge using the following syntax where the word post or base line is required lt time delay gt post lt challenge gt where the challenge can be further characterized as lt amount given gt lt substance treatment given gt lt route given gt The time difference follows the syntax
495. parts and equipment to be delivered to St Anybodys Medical Center f Describe in detail the support you provide based on the system you have proposed Include the following areas of support e Training e Education e Hot Lines e Software releases and Enhancements e Documentation g Describe any regularly held seminars or user group meetings available to users of your system Have any enhancements been developed based on input from these user group meetings F 1 6 4 Installation Support 1 Staffing Describe in detail the installation process including the number of vendor personnel you will commit to having on site during the installation Provide an installation work plan indicating the tasks required including hardware and communications equipment installation and interface development the party responsible or each task hospital vendor other the approximate time required to complete each task and the relative sequence of tasks Also specify client resources needed to successfully install your system e g data processing and department man hours required skill levels etc a Provide brief resumes of your personnel who would manage the project as well as those who would be assigned to the day to day work b Provide brief resumes of your support and development staff c Describe the anticipated St Anybodys Medical Center personnel required and the skill level required to support your system on an ongoing basis d
496. ppendix F Sample Templates F 1 9 2 Hardware Provide a complete list of hardware including cabling that will be needed to meet the requirements in the preceding sections as you responded to them Indicate whether you will provide the hardware in conjunction with the purchase or if the hardware may be purchased from another source Include a full configuration description for each computing platform Describe any assumptions and or additional information that will help to clarify the proposed pricing configuration The list of hardware must be complete All necessary gateways translators network components etc must be included Interface Category I Include all hardware required to implement Category I interfaces COMPONENT VENDOR AND MODEL QUANTITY CONFIGURATION COST NOTES TOTAL PROPOSED COST OF HARDWARE FOR CATEGORY I INTERFACES Page F 44 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates Interface Category II Include all hardware and cabling that is required to implement Category II interfaces and is in addition to what is proposed for Category I interfaces Hardware that has been listed as required for Category I interfaces but will require additional components for Category II interfaces should be included COMPONENT VENDOR AND MODEL QUANTITY CONFIGURATION COST NOTES TOTAL PROPOSED COST OF HARDWARE FOR C
497. pplications systems departments and vendors involved List the perceived or anticipated benefits of the interface It is very important that decisions made during interface design be thoroughly and clearly documented and kept up to date Interface programming testing support maintenance and upgrades will all be facilitated by detailed accurate design documentation Complete HL7 Transaction Checklists For Each Interface Appendix A contains a template of a design checklist that can be used to document key design decisions Define Trigger Events By Application Using the current or agreed upon HL7 Standard define all trigger events to be used through the interface This should come directly from functional descriptions and analysis of current work and data flow as well as vendor capabilities to support For example an ADT vendor that does not provide Leave of Absence functionality in their registration system will not support triggers A21 Patient Goes on a Leave of Absence and A22 Patient Returns from a Leave of Absence Also make sure to document what action in the originating system triggers specific transactions over the interface Identify Required HL7 Segments For each trigger event define the HL7 segments required for the interface Common segments can be defined once and referenced in each trigger event as needed Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3
498. protocol functionality 4 2 3 3 3 When should this be available from vendors In general the availability of new features should be demand driven 4 2 3 3 4 When should members look for v 2 2 availability In general the availability of new features should be demand driven 4 2 3 3 5 Will some new features be ahead of vendor s implementations Probably yes Page 4 6 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 4 HL7 Version 2 2 Overview 4 2 4 4 2 4 1 Master Files responses by Mark Shafarman Why Master Files transactions In an open architecture health care environment there often exists a set of common reference files used by one or more application systems Such files are called master files Some common examples of master files in the health care environment include a doctor master file b system user and password master file c location census and clinic master file d device type and location e g workstations terminals printers etc e lab test definition file f exam code radiology definition file g charge master file h patient status master i patient type master These common reference files need to be synchronized across the various applications at a given site The Master Files messages provide a way of maintaining this synchronization by specifying a standard for the transmission of thi
499. quality assurance of laboratories Remember that both reference range and method can be sent in other fields of ASTM HL7 and CEN TC251 result messages Health Level Seven Implementation Support Guide Page H 29 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC Table 13 Methods Method Abbr Comment AGAR DIFFUSION AGAR Bacterial sensitivity Kirby Bauer AGGLUTINATION AGGL LATEX AGGLUTINATION LA AGGLUTINATION RED BLOOD CELL AGGL RBC Blood bank typing COMPLEMENT FIXATION CF COAGULATION ASSAY COAG To distinguish coagulation assays based on coagulation DNA NUCLEIC ACID PROBE DNA PROBE Nucleic acid amplification PCR is one of several methods TARGET AMPLIFICATION amp PROBE PROBE AMP TAR SIGNAL AMPLIFICATION amp PROBE PROBE AMP SIG ENZYME IMMUNOASSAY EIA Subsumes variants such as ELISA ENZYMATIC ASSAY ENZY To distinguish coagulation assays based on enzymatic activity FLOCCULATION ASSAY FLOC HEMAGGLUTINATION INHIBITION HAI IMMUNE BLOT IB IMMUNE DIFFUSION ID IMMUNE FLUORESCENCE IF IMMUNE STAIN Cells stained with immune enzyme Also called Cyto immune enzyme LEUKOCYTE HISTAMINE RELEASE LHR MINIMUM LETHAL CONCENTRATION MLC Also called MB bactericidal C MINIMUM INHIBITORY CONCENTRATION MIC Antibiotic susceptabilities NEUTRALIZATION NEUT RADIOIMMUNOASSAY RIA SERUM BACTERICIDAL TITER SBT Antibacterial susceptabilities Stain methods which are mod
500. r Expected number of insurance plans Visit publicity code Visit protection indicator Clinic organization name Patient status code Visit priority code Previous treatment date Expected discharge disposition Signature on file date First similar illness date Patient charge adjustment code Recurring service code Billing media code Expected surgery date amp time Military partnership code Military non availability code Newborn baby indicator Baby detained indicator Set ID NK1 ol gt lt PV2 16 PV2 17 PV2 18 PV2 19 PV2 20 PV2 21 PV2 22 PV2 23 PV2 24 PV2 25 PV2 26 PV2 27 PV2 28 PV2 29 PV2 30 PV2 31 PV2 32 PV2 33 PV2 34 PV2 35 PV2 36 PV2 37 NKI 1 Element name changed from Set ID Next of Kin to Set ID NK1 Data type changed from PN to XPN NK1 2 Name EX qoi S JUN NAE PV2 16 Purge status code zx PV2 17 Purge status date X Pv2 18 Special program code X PV2 19 Retention indicator X N TH PV2 21 T Visit publicitycode IX PV2 22 T Visit protection indicator X PV2 23 Clinic organization name X PV2 24 1 Patient status code X PV2 25 Visit priority code IX Be o I PV2 28 Signature on file date X PV2 29 First similar illness date X LEE E PV2 31 Recurring service code X PV2 32_ Billing mediacode IX PV2 34 Military partnership code X pc
501. r HL7 Standard Version 2 3 1998 All rights reserved C 2 6 C 2 6 1 Appendix C Lower Layer Protocols Implementation System and Site Specific Issues This section deals with issues that do not affect the data flowing among HL7 systems As such they are considered local matters and not subject to standardization Nonetheless they are important considerations in the implementation of this Lower Layer Protocol Connect Retries for Optional Transient Virtual Circuits Although the entire problem of connecting and disconnecting to form a virtual circuit on the network is beyond the scope of this document it should be pointed out that it may require more than one call operation to complete a circuit If the destination system is already processing a request the called address may not be immediately available Waiting a short time and retrying to connect may then be successful The number of times to retry connecting will be dependent on a number of factors and should be configurable This is covered more fully in the section Communication Parameters and the NPT C 2 6 2 Receive Timeout Errors A timeout error is often a signal of a hardware problem for which retrying will not help It may take a few seconds to tens of seconds for these errors to be returned to the program so blindly retrying on timeout error may make an interactive system appear to lock up Some implementations may wish to no retry an operation after a timeout error
502. r HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapier 1 Introduction SGML in all domains of health care This standard will comply with ISO 8879 SGML Participation is open to all parties Projects e Create and coordinate the development of a comprehensive document architecture for health care e Educate the healthcare community in the capabilities and utility of SGML based informatio e Develop coordinate and maintain a framework for interoperable Document Type Definitions DTDs for use in health care and health care standards including HL7 Coordinate and cooperate with other SGML initiatives where appropriate e Enable and promote the use of these standards and to make the standard as widely available as possible Represent health care in SGML standards activities evolution e Promote longevity of all information encoded according to these guidelines Ensure that the document architecture standards comply with and not be out of conformance with HL7 1 11 INTERNET RESOURCES 1 11 1 General Information Homepage http www hl7 org Duke website http www mcis duke edu standards HL7 hl7 htm To join the list server Send e mail to majordomo virginia edu Subject line may contain anything you want First line must read subscribe HL7 1 11 2 Homepages for Technical Committees and Special Interest Groups Control Query http www mcis duke edu standards HL7 committees control query index htm
503. r auditing by appropriate personnel It is St Anybody s Medical Center s intent to maintain a secure environment while not constricting the flow of information to areas users requiring it The future of security from a central system central database is still unknown however St Anybody s Medical Center will continue to keep abreast of technologies available 1 Describe in detail how and in what module your system provides the following capabilities and facilities a Transaction authentication b Dataintegrity c Auditing logging security violations Page F 38 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates F 1 9 10 d Automatically revoking privileges upon exceeding security parameters e Security at all levels e g dataset volume task transaction etc f Security interfaces to all platforms interacting with the AIE For the recommended system what security package is being implemented Are other packages outside of the recommended package available If so what are they and who manufactures them For the recommended security package what features does it incorporate How is security maintained when integrating and communicating with foreign systems Is security pass through available Do you recommend using it If not why not Does the recommended security system allow for multiple security admin
504. rbu 0 AS AAA E 7 00675 j Aciv lacive ID D 5 8 00676 Department CE Q0 o Cen 9 00677 Service l 9 TIGER E ET E E cuo o o ose cm 11 00679 Office Home Address XAD a Os 12 00680 ActivationDate CM OL 13 00681 InactivationDate JL CM Q9 O 34 4 S 14 00682 BackupPersonID CE 00 CTT S 15 00683 E Mail Address 1 ST Os 16 00684 PreferedConactMehod ID D Ce 17 00119 Marital Status PAS D 5 5 0 0 Com L 18 00785 E Y OY 19 00786 JobCode Class e Om III S 20 01276 EmploymentStatus LI IS 2 0066 21 01275 Additional Insured on Auto ID D 0136 22 01302 Drivers License Number Stff DIN QS II 23 01229 Copy Aug Insurance Cl go Ce Health Level Seven Implementation Support Guide Page B 55 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 24 01232 Auto Insurance Expires DT 9 5 5 5 5 25 01208 DateLastDMVReview DT 9 J 9 amp 9 J 26 01234 Date Next DMV Review DT e III B 1 95 TXA Transcription Document Header ITE
505. rd Version 2 3 1998 All rights reserved Appendix F Sample Templates e Similarities to St Anybodys Medical Center Facility 2 e The hospital environment and system configuration e Similarities to St Anybodys Medical Center Facility 3 e The hospital environment and system configuration e Similarities to St Anybodys Medical Center B Describe the interfaces installed at the reference facilities Facility 1 CURRENTLY APPLICATIONS INSTALLED INTERFACED REAL TIME COMMUNICATION THROUGH THE AIE INTERFACE PROTOCOL Facility 2 CURRENTLY APPLICATIONS INSTALLED INTERFACED REAL TIME COMMUNICATION THROUGH THE AIE INTERFACE PROTOCOL Facility 3 CURRENTLY APPLICATIONS INSTALLED INTERFACED REAL TIME COMMUNICATION THROUGH THE AIE INTERFACE PROTOCOL Health Level Seven Implementation Support Guide Page F 15 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 6 2 Contractual Warranty Specifications 1 Purchase Contract St Anybodys Medical Center is interested in including the following items in the final contract Describe your company s position on including each item in the final contract Page F 16 Final Version 6 98 Scheduled installation dates for all hardware and software Positive incentives for meeting implementation dates Availability dates of software under development Provisions for cancellation by either party and penalties for can
506. rd Version 2 3 O 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Medical history and physicals H amp Ps Progress notes Consultation reports Operative notes records Procedure notes including medical imaging interpretation and surgical pathology reports Discharge summary 5 3 9 3 Are there any functional issues that should be addressed prior to implementing this chapter There have been numerous implementations to date We are unaware of any limitations which require resolution prior to implementing this chapter other than the normal issues associated with any other HL7 interface including creating a unique identifier for each feeder and recipient systems and populating these IDs within the message header MSH segment 5 3 10 Chapter 10 No information submitted by co chair 5 3 11 Chapter 11 No information submitted by co chair 5 3 12 Chapter 12 responses by Karen Keeter 5 3 12 1 What was the driving force behind the creation of chapter 12 This chapter was created to support the communication of primary care provider information typically required by and generated by physicians and nurses These include assessment problem and goal oriented records and data at this time supporting clinical problems goals and pathways The chapter was developed following an assessment supported by the Orders TC in which it was agreed that there was not adequate support for these capabilities i
507. re frequently vendors with legacy systems based on older technologies e There is no model for conformance claims in HL7 In HL7 Version 3 several things are planned that will greatly reduce the need for site specific negotiations Transactions are developed based on a reference data model and optionality will be defined by trigger event rather than by segment These approaches will reduce the potential for ambiguity and errors Many known problems can be corrected because version 3 will not be 100 compatible Version 3 will probably use profiles to specify exactly how to implement it in TCP IP and some other communications environments Version 3 will have a conformance model to describe conformance on a specific interface basis rather than a black or white is conformant or is not conformant Health Level Seven Implementation Support Guide Page G 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions G 6 G 6 1 G 7 G 7 1 G 7 2 Page G 6 The recognition and use of HL7 has grown since we began working on the 2 X series We expect that our members users and vendors will support more rigorous specifications with fewer options in version 3 Wes Rishel PATIENT ADMINISTRATION MESSAGES Error in Trigger Event A18 Merge Patient Information There is a typographical error in version 2 2 describing the A18 message format The MRG segment is listed as optiona
508. rect some measured value We use this subpart to distinguish corrected or adjusted values from the uncorrected measurement e g corrected cell counts from the raw cell counts Since these attributes are unique to each measurement they will be short phrases of text rather than a controlled vocabulary to define the content of the third subpart However when defined such a test will have a unique LOINC code and the meaning will be fixed by the text in the third part Examples CALCIUM FREE PH ADJUSTED TO 7 4 SCNC PT SER PLAS QN CREATININE RENAL CLEARANCE NORMALIZED TO 1 72 BODY SURFACE AREA VRAT2AH UR QN LEUKOCYTES CORRECTED FOR NUCLEATED ERYTHROCYTES NCNC PT BLD QN Note that the actual pH of the sample would be sent as a separate OBX segment in the test result message analogous to the approach described in Section 2 2 2 1 2 3 Kind of Property also called kind of quantity 2nd part Health Level Seven Implementation Support Guide Page H 21 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC The second part of the fully specified name distinguishes between different kinds of quantities relating to the same substance e g the mass versus the concentration of sodium in a urine sample a molar concentration versus a mass concentration or the absolute eosinophil count versus the percent of the total white count that are eosinophils The type of property kind of quantity is an IUPAC
509. res 11 1 1 1 Shutdown 11 1 1 2 Start Up 11 1 1 3 Error Reporting 11 1 1 4 Develop Log Sheets 11 1 1 5 Support 11 1 1 5 1 Daytime 11 1 1 5 2 After Hours 11 1 1 6 Message Rejection Re entry 11 1 1 7 Downtime 11 1 1 8 Virus Protection 11 1 2 Develop Migration Procedures 11 1 3 Develop Backup Recovery Procedures 11 1 3 1 Interface Engine 11 1 4 Assemble Operational Procedures Book 11 1 5 Lab Policies and Procedures 11 1 5 1 Gather Existing Policies and Procedures 11 1 5 1 1 Downtime Page F 76 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 11 1 5 1 2 Any others 11 1 5 2 Test All Procedures 11 1 6 Lab Policies and Procedures Signoff 12 TRAINING 12 1 Develop Training Plan Approach 12 2 Develop Training Materials 12 3 Execute Training Plan 12 3 1 Schedule Training 12 3 2 Conduct Operational Training 12 3 3 Conduct Support Maintenance Training 13 IMPLEMENTATION 13 1 Implementation Migration Strategy 13 2 Go Live Plan 13 3 Final Migrations 13 4 Activate Interfaces 13 4 1 Activate Interfaces 13 4 2 Readiness Review 13 5 Go Live 13 6 Post Implementation 13 6 1 Plan Support Coverage 13 6 2 Provide Support 13 6 3 Do Performance Tuning 13 6 4 Obtain Implementation Signoff 13 6 5 Turnover Help Desk Support 14 TECHNOLOGY TRANSFER 14 4 Development of Technology Transfer Model 14 2 Relea
510. rices The following Matrices summarize the types of information to be transferred across the interfaces in each category The following codes have been used Page F 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates A A D T M Clinical Abstract Data F Financial Management C z Charges H HR Payroll S Statistical Category I Interactions Category II Interactions Health Level Seven Implementation Support Guide Page F 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates F 1 6 Vendor Information This section of the RFP presents questions related to the basic vendor information required by St Anybodys Medical Center Please answer each question completely concisely and accurately Incomplete answers will be considered as blank answers and will be disregarded Failure to provide appropriate data may delay or eliminate the evaluation of this proposal The following pages may be photocopied or new ones prepared in order to help you respond to these questions or you may respond on the enclosed diskette In any event the questions must be printed along with the answer Questions are presented in the following sequence 1 General Vendor Information 2 Contractual Warranty Specifications 3 System Support and Maintenance 4 Installation Support 5 Docum
511. riented Query A 92 A 4 10 20 PCL PPT Patient Pathway Goal Oriented Response A 92 A 4 11 Introduction to Z Segments EE A 93 A 4 11 1 When to Create Z Segments oi A 93 A 4 11 2 How to Develop New Z Segments sss sees esse eee A 93 A 4 11 3 Creating Z Segments for New Releases of HL7 eee A 94 A 4 12 How to Use Z Segments in Messages A 95 A 4 12 1 Placing Z Segments in Existing HL7 Messages A 95 AA 13 Creatmg Z WIGS SABES a cet to Rer Hu Rue ENEE eege A 97 Aca sl Management OF T A 98 A4 135 2 Segment EE A 98 APPENDIX B HL7 SEGMENT AND EVENTS CHECKLIST BA SEGMENT Regen a A a atu B 1 IT T Accident Intormat on asses A Ee B 2 Bed gt R B Ee EE B 2 B 1 3 AIG Appointment Information sss esse ee sees eee ee ee eee ee eee B 2 B 1 4 AIL Appointment Information Location oe sees B 3 B 1 5 AIP Appointment Information Personne B 3 B 1 6 AIS Appointment Information Service B 4 B 1 7 ALI Patient Allergy Information sss sees sese ee eee B 4 B 1 8 Appointment Information Preferences nennen B 4 BLS ARO Appointment Request EE B 5 B 1 10 AUT Authorization Information sisi eite etate robe db e peer ee ae repos B 5 Belt BHS Batch Headet ede t dia B 6 BA 42 EE B 6 Bill eB TS Bac R T enc esed ot e code eds B 7 B 1 14 CDM Charge Description Master B 7 Page TOC 12 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 St
512. rman LOINC committee Co chairman LOINC committee Health Level Seven Implementation Support Guide Page H 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC Acknowledgments We wish to thank Henrik Olesen Chairman of IUPAC Commission on Quantities amp Units in Clinical Chemistry for his very helpful comments and insights about laboratory test coding This endeavor was supported in part by grants and contracts from the John A Hartford Foundation of New York the National Library of Medicine Contracts NO1 LM 4 3510 and NLM 96 105 and the Agency for Health Care Policy and Research AHCPR Grants HS 05626 and HS 07719 013 Much of the work was performed under the auspices of the Regenstrief Institute John Baenziger Indiana University Hospital Indianapolis IN Pam Banning ARUP Laboratories Salt Lake City UT Rita Barsoum Kaiser Permanente Pasadena CA James Barthel H Lee Moffitt Cancer Ctr Tampa FL Barbara Bassoline Ernst amp Young Philadelphia PA Dean Bidgood Duke Medical Center Durham NC Bruce Bray University of Utah Salt Lake City UT Jim Bristol SmithKline Beecham Collegeville PA Jim Case California Veterinary Diagnostic Labs Davis CA Florence Chang Kaiser Permanente Pasadena CA Linda Charles Quintiles Inc Morrisville NC Jim Cimino Page H 8 Final Version 6 98 LOINC COMMITTEE MEMBERS Columbia Presbyterian Medical Ce
513. rogeneous operating systems The tool sets that are available for accessing CORBA are all third generation languages like C or C The applications that are using CORBA today are primarily using it for inter application messaging in a manner quite similar to the messaging done through HL7 The Object Management Group which is the consortium that developed and is promoting CORBA has a Web page at lt http ruby omg org corbmed htm gt In the author s opinion their Web page is somewhat frustrating because all the cool information is restricted to members However there is a good bibliography of books on CORBA OpenDoc is a third proposal for object brokering services that is being developed The two approaches have a lot in common even though they are used today in somewhat different modes It is likely that in the future the domain of each will expand to where there is considerable overlap The SIGOBT group has been exploring how to share HL7 data in the environments of these two object brokering environments It did a demonstration project in which seven vendors interoperated using OLE and the HL7 model at last year s HIMSS Another effort is underway for this years HIMSS At the same time it is working to find the common abstractions so that object based communications using HL7 data will be the same in the two environments G 8 1 2 What Approach is SIGOBT Using Rob Seliger s initial concept paper the current versions of the OLE demo
514. rved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview Event Name parties TT Next of Kin Associated Parties 5 3 4 2 Data Elements Segment Seq hange EVN 1 Event type code Optionality changed from R to B EV Recorded date time Element Name changed from Date time of event to Recorded date time EVN 4 Event reason code Data type changed from ID to IS EVN 5 Operator ID Length changed from 5 to 60 Data po EVN 6 X Ee Length changed from 16 to 20 Data PID 2 Patient ID External ID PID 3 Patient ID Internal ID Data type changed from CM to CX Element Name changed from Alternate PID 4 Alternate patient ID PID patient ID to Alternate patient ID PID length changed from 12 to 20 data type changed from ST to CX Z N Length changed from 30 to 48 data Element name changed from Date of Data type changed from PN to XPN repetition changed to Y PID 7 Date time of birth i PID 8 Sex o S PID 9 Patient alias Jo PID 10 Rae po PID 11 Patient address Data type changed from AD to XAD pee PID 12 Country code PID 13 Phone number home Data type changed from TN to XTN EM PID 14 Phone number business Data type changed from TN to XTN T Element Name changed from E Language Patient to Primary Language a E Al L length changed from 25 to 60 data type changed from ST to CE Data type changed from ID to IS Data type changed from ID to IS Data type changed from CK to CX Element Name change
515. ry helpful We often will require a committee discussion to decide how to represent new subject matter so response times will be slower The requestors also need to supply some evidence that they are familiar with the database and that they are sure the term is not already represented in LOINC The major work these requests generate is the effort to be sure the observation is not already in the database We can perform this service if the requestors have done most of this work themselves For this reason we request that you identify the LOINC term that is closest to your request and to flag the difference between the requested test and the existing test That is when a new observation is only a variation on an old one use an existing LOINC observation as the template Health Level Seven Implementation Support Guide Page H 47 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC change the part that is different in the new term and indicate that difference Later in this appendix we discuss how to make a submission as either a Microsoft Access database or an ASCII text file If you use an Access file submission you may use the S_COMMENT field see Table 20a to indicate the difference of the new term If you are making the submission as an ASCII file you should append three asterisks to the different term Terms should be submitted in an acceptable LOINC database format Access or
516. ry statistic usually reported When we address measures taken over time we usually include 1 hour 8 hour 10 hour 12 hour and 24 hour intervals to cover the varying lengths of work shifts within and across institutions The LOINC names of these correspond to the form of a 24H urine specimen The times are recorded in the duration 3rd part of the name The parts of clinical measurement names are the same as for laboratory measures Parts 2 3 5 and 6 type of property to method correspond exactly in meaning between laboratory and clinical LOINC codes Part 4 body system has the same general meaning for clinical and laboratory measures but in the case of laboratory tests the system usually identifies a fluid and a body compartment by implication e g serum cerebral spinal fluid For clinical terms the system is usually a body part e g chest organ e g cardiac ventricle or part of an organ cardiac In the case of laboratory tests the component usually identifies some chemical moiety that is distributed in the system glucose or HIV antibodies In the case of clinical terms the component usually identifies a particular projection of a three or four dimension space to a measure of a particular feature e g QRS interval systolic of a time changing measure ventricle left outflow tract In some cases the system may be an instrument or device attached to the system The component includes such things as the special kinds of length
517. s 22 01225 System Entry Date Time TE TS TH Health Level Seven Implementation Support Guide Page B 49 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists B 1 86 RXC Pharmacy Component 1 00313 RXComponentType R ID 066 2 00314 ComponentCode R CE aw 3 0015 ComponentAmount R NM QO 0 S 9 4 0086 Component Units I R CE QO 5 01124 Component Strength m QO j 6 01125 Component Strength Units CE en III B 1 87 RXD Pharmacy Dispense 1 00334 Dispense Sub ID Counter R NM j Z Jp 59 2 00335 Dispene GieCoe R CE Gao J A Comp 3 00336 Date Time Dispensed S R TS O9 J 5 0 5 Y 4 00337 Actual Dispense Amount R NM on pp 5 00338 Actual Dispense Units C CE 60 250 0 20 9 6 00339 ActualDosageForm CE 600 0 S 7 00325 PrescriptionNumber ST QO J TI 6 8 00326 Number of Refills Remaining 0 Dispense Notes 10 00341 Dispensing Provider CN e 11 00322 Substitution Status Lol 12 00329 TotalDailyDose LL NM GO 13 01303 Dispense toLocation C
518. s Any status 4 2 3 1 6 3 Date time selection qualifier Definition Allows specification of certain types of values within the date time range First value within range All values within the range Last value within the range All values within the range returned in reverse chronological order This is the default if not otherwise specified The above three fields also appear in new versions in the URS segment with R U prepended to their names 4 2 3 1 7 New Section Miscellaneous HL tables Tables used across all chapters Currently contains only the yes no table 4 2 3 1 8 New message examples Master file update examples with original and enhanced acknowledgment protocol 4 2 3 2 Control Query Future Issues and Directions Inclusion of alternate character sets within HL7 messages HL7 intends to allow the use of alternate character sets in a manner that is consistent with other US standards groups such as ASTM E1238 94 and with various international standards groups such as CEN TC 251 Health Level Seven Implementation Support Guide Page 4 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 4 HL7 Version 2 2 Overview 4 2 3 2 1 Now part of scope for HL7 v 2 3 Investigate extending the HL7 query paradigm to include a subset of SQL defined on an implicit table structure consistent with a subset of current HL7 segment definitions Now part of scope for HL7 v 2 3
519. s HL7 Implementation Support Guide A 4 2 47 A47 Change Internal ID ADT sss esee rennen A 32 A 4 2 48 A48 Change Alternate Patient ID ADT eee A 32 A 4 2 49 A49 Change Patient Account Number ADT eee A 33 A 4 2 50 A50 Change Visit Number ADT ii A 33 A 4 2 51 A51 Change Alternate Visit ID ADT sss sese eee A 33 A4 3 Order Messages incitan tii restado A 34 A 4 3 1 OOl General Order Message ORM eee A 34 A 4 3 2 002 General Order Response to any ORM ORR eere A 34 A 4 3 3 001 Dietary Order Message ORM sene A 35 A 4 3 4 Q06 Query Response for Order Status DSR eese A 35 A 4 3 5 002 Dietary Order Response ORR sese eee seene A 36 A 4 3 6 O01 Stock Requisition Order ORM eee A 36 A 4 3 7 002 Stock Requisition Order Response ORR A A 37 A 4 3 8 O01 Non Stock Requisition Order ORM seen A 37 A 4 3 9 002 Non Stock Requisition Response ORR A A 38 A 4 3 10 O01 Pharmacy Treatment Order ORM sees eee A 38 A 4 3 11 O02 Message for Pharmacy Treatment ORR eee A 39 A 4 3 12 O01 Pharmacy Treatment Encoded Order RDE sss A 40 A 4 3 13 002 Pharmacy Prescription Response RRE eee A 41 A 4 3 14 O01 Pharmacy Treatment Dispense RDS eene A 42 A 4 3 15 O02 Pharmacy Treatment Dispense Ackn
520. s Patient Identification Additional Demographics Notes and Comments Allergy Patient Visit Patient Visit Additional Info Common Order Pharmacy Treatment Order Notes and Comments Pharmacy Treatment Route Pharmacy Treatment Component Notes and Comments Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component Pharmacy Dispense Pharmacy Route Pharmacy Component Results Notes and Comments A 4 3 15 O02 Pharmacy Treatment Dispense Acknowledgment RRD Originator A or B Page A 42 Final Version 6 98 Message Header Message Acknowledgment Error Notes and Comments Patient Identification Notes and Comments Common Order Pharmacy Treatment Dispense Pharmacy Treatment Route Pharmacy Treatment Component Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 3 16 001 Pharmacy Treatment Give Message RGV Originator A or B Message Header Notes and Comments Patient Identification Notes and Comments Allergy Patient Visit Patient Visit Additional Info Common Order Pharmacy Treatment Order Notes and Comments Pharmacy Treatment Route Pharmacy Treatment Component Notes and Comments Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component Pharmacy Treatment Give Pharmacy Treatment Route Pharmacy Treatment Co
521. s Clinic Health Center Billings Montana Phone 406 657 3824 Fax 406 657 3872 E 2 1 Beginning of Project In January of 1994 Deaconess Billings Clinic Health Center DBCHS contracted with a vendor to implement a clinical based system for the hospital which would provide an Order Communications system as well as several clinical modules including Pharmacy Radiology and Nursing One of the challenges for the hospital was that the clinical based system resides on a Tandem Himalaya K1002 and our financial based system resides on an IBM AS 400 9406 D80 In the past the hospital had made a commitment to standardize on HL7 for the application protocol and also to use TCP IP as the communication protocol on any future interfaces Prior to this HL7 messages had been communicated in batch interfaces between platforms using an emulation file transfer process E 2 2 The Project Management Process In order to more effectively understand the needs of the clinical departments a Project Coordinator for the entire project was recruited from the nursing staff of the hospital To assist her with the project management and technical issues a Clinical Systems Analyst was also recruited The Project Coordinator developed a project plan using an Excel spreadsheet as a tool to break up the main project into smaller projects and the smaller projects into individual activities and tasks The spreadsheets contained data such as responsible teams team members activ
522. s Meetings Prepare ADT Requirements Document Draft Prepare ADT Requirements Document Final Obtain ADT Requirements Signoff Requirements Analysis Patient Demographics Review Existing Patient Demographics Documentation Review Existing Patient Demographics UE Specs Prepare Access DB Table for Patient Demographics Requirements Documentation Development Patient Demographics Requirements Mtgs Conduct Patient Demographics Requirements Meetings Prepare Patient Demographic Requirements Document Draft Prepare Patient Demographic Requirements Document Final Obtain Patient Demographic Requirements Signoff Requirements Analysis Clinician Master File Update Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 7 12 1 Review Existing Clinician Master File Update Documentation 7 12 2 Review Existing Clinician Master File Update I F Specs 7 12 3 Prepare Access DB Table for Clinician Master File Update 7 12 4 Requirements Documentation Development Clinician Master File Update Requirements Mtgs 7 12 5 Conduct Clinician Master File Update Requirements Meetings 7 12 6 Prepare Clinician Master File Update Requirements Document Draft 7 12 7 Prepare Clinician Master File Update Requirements Document Final 7 12 8 Obtain Clinician Master File Update Requirements Signoff 7 13 Requirements Analysis Clinical Data Repository 7 13 1 Review Existing Clinical
523. s data between applications It is important to note that the HL7 Master Files specification provides a general framework for transferring master files data This framework is independent of the definition of a particular master file If a site needs to synchronize a master file that has not yet been defined by HL7 Z segments may be used specified by local agreement The master files chapter has responsibility for defining site wide HL7 master files such as the location file individual application specific chapters have responsibility for defining application level HL7 master files In HL7 2 2 the master files chapter has defined both staff STF and practitioner PRA segments which may be used to synchronize staff and health practitioner master files data The Order Entry Results reporting chapter has defined test observation master segments Omx segments where x varies from 1 to 6 see appendix B of chapter 7 It is expected that other HL7 master files segments will be defined for future HL7 versions 4 2 4 1 1 How to decide whether to upgrade from v 2 1 If you need to transmit master files data at your site you should upgrade to use the HL7 master files messages 4 2 4 1 2 Key functional issues in migration from v 2 1 None unless the enhanced acknowledgment paradigm is needed 4 2 4 1 3 When should this be available from vendors In general the availability of new features should be demand driven 4 2 4 1 4 When should
524. s ded 5 8 5 3 3 4 Data Elements cafe ied eee te ia 5 8 Page TOC 6 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Table of Contents HL7 Implementation Support Guide 5 3 4 Chapter 3 Patient Administration sese seer 5 9 9 9 4 1 Messages Segments Tables raros 5 9 53342 Data 2 EE 5 12 5 3 3 Chapter 4 Order ENY EE 5 16 e e AN Messages E 5 16 5 3 2 Data Elements seri da 5 17 5 3 6 Chapter 6 Financial Management sss as 5 20 A MESAS MS E 5 20 5 3 6 2 Data Elements eie deele a 5 20 5 3 7 Chapter 7 Observation Reporting mitad us iov e See EE ache 5 28 e GEN e TEE 5 28 S32 Data E 5 29 5 3 0 Chapter 8 Master PHes oi os pee pite Een Ee Ee 5 30 5 3 8 1 Messages Segmients ios ENNEN ENNEN EENEG REENEN 5 30 RN Elements yi ace ha ceases o etu date esie oT uad tu ada dee 5 31 5 3 9 Chapter 9 responses by Wayne Tracy iii 5 31 5 3 9 1 What was the driving force behind the creation of chapter 9 5 31 5 3 9 2 What functionality does it offer 5 31 5 3 9 3 Are there any functional issues that should be addressed prior to Implementing this chapter seinere A A A 5 32 ede LO Chapter EE 5 32 31 Chapter Tl TT 5 32 5 3 12 Chapter 12 responses by Karen Keeter o 5 32 5 3 12 1 What was the driving force behind the creation of chapter 12 5 32 5 3 12 2 What functionality does it offer
525. s reserved Appendix B HL7 Segment and Event Checklists B 1 9 ARQ Appointment Request 1 00860 Placer Appointment ID R H III 2 00861 Filler AppointmentID C H J III 3 0082 OccurrenceNumber C NM III 4 00218 PlacerGroupNumber IL H op 5 00864 ScheduleID J l Q0 6 00865 RequestEventReason CE e op 7 00866 AppointmentReason CE 0 f 8 00867 Appointment Type CE e f 9 00868 Appointment Duration NM 0 10 00869 Appointment Duration Units CE 00 f 11 00870 Requested Start Date Time Range DR 6 Off 12 0087 Pio ST 5 13 00872 Repeating Interval RI a 14 00873 Repeating Interval Duration ST TI 15 00874 PlacerContactPerson R XCN 48 III 16 00875 Placer Contact Phone Numer ml om CTT J 17 00876 PlaerConact Address JL XAD awo S 18 00877 PlacerContactLocation PL 890 5 S 19 00878 EnteredByPeson R xn a III 20 00879 Entered By Phone Number ml w CTT J 21 00880 EntredByLocaion PL 80 0 22 00881
526. s reserved Appendix F Sample Templates F 1 9 1 Software Provide the software packages and modules with version release number that are proposed to meet the requirements in the preceding sections as you responded to them Indicate whether modules packages are included with the basic offering and the cost of adding the module package if it is not included Pricing must include a description of how the product is licensed i e by site seat workstation interface application etc and the number of licenses proposed If a volume discount has been factored into the price provide the incremental cost for additional licenses Describe any assumptions and or additional information that will help to clarify the proposed pricing licensing The list of software must be complete It must include all modules that run on the AIE the user workstations and the application hosts including standard interface templates emulators translators etc Interface Category I Include all software modules packages required to implement Category I interfaces VENDOR REL ADD L PACKAGE MODULE THIRD VER DESCRIPTION LICENSING LICENSES LICENSE NOTE PARTY REQUIRED NO TOTAL PROPOSED COST OF SOFTWARE FOR CATEGORY I INTERFACES Notes Health Level Seven Implementation Support Guide Page F 41 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates Interface Category II Include all softw
527. s reserved Final Version 6 98 Appendix B HL7 Segment and Event Checklists 22 00523 Second OpinionDate S DT pp J 23 00524 Second Opinion Status DOT ST 24 00525 Second Opinion Doc Revd DT P0152 25 00526 Second Opinion Practitioner XCN ep l___ coy B 1 40 LCC Location Charge Code 1 00979 Primary Key Value LCC R PL ew ss 2 00964 Location Department R IS 0 y 3 00980 Accommodation Tye CE 60 Jol S S p 4 0098 ChageCode R_ CE 69 Jol j 0132 B 1 41 LCH Location Characteristic 1 01305 PrimryKeyVale LCH R PL e P 9 S 2 00763 SegmntAcionCode R ID D Come Lc 3 00764 SegmentUniqe ke LL CET 80 4 01205 Location Characteristic ID R CE 80 0 9 J 4024 5 01237 Locat onCharacterisic Value R CE e __ ____ _ Page B 22 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists B 1 42 DP Location Department 1 00963 PrimaryKeyValue LDP_ R PL e P A3 S 2 00964 Lloc onDepamen R IS a II S 3 00905 LocationService
528. s users to concentrate on training without disruption Training should be hands on with the interfaced systems in test or debug mode if available Class size should be kept small and consider using two trainers This allows for more interaction and assistance In the last phase of training have training staff rotate through the production areas to address on the spot impromptu questions 3 6 7 2 Support Staff Training 3 6 7 2 1 Environment In many cases the MIS support staff must be introduced to HL7 concepts and environment They must understand the change in philosophy and direction and how HL fits into the long term strategy of the organization 3 6 7 2 2 Application Once the support staff is acclimated to the HL7 approach they must become familiar with the application areas In larger shops this is a matter of coordination between the interface and support groups In most shops however this means the support team must work closely with the end users and the vendors A thorough knowledge of the application systems will be invaluable throughout the implementation period and for ongoing support 3 6 7 23 HL7 It is very important for the support staff to have a thorough understanding of HL7 its role in open systems and its use in interface development This group must be able to look into the messages and diagnose problems perform maintenance and foresee the impact of updates to application software or new HL7 releases 3 6 7 2
529. s will be added to operational HL7 environments as a result of changes in the Standard or due to changes in the local implementation as permitted within the Standard It is important that these changes be implementable at a site without requiring all communicating applications to upgrade simultaneously The special provisions in the Encoding Rules for dealing with fields that are not present or unexpected are very important here Because of them new fields can be added first to the sending or source system the receiving system will ignore the new fields until it has been updated to use them Often these rules also facilitate changing the receiving system first Until the sending system is changed the receiving system will find the new data field not present and deal with this according to its rules for data not present Similarly the HL7 Encoding Rules support changes in data field sizes Fields are found within the message by examining separators rather than by an offset Changing the size of a field does not change the procedure used to detect subsequent fields Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 1 Introduction 1 5 4 Applicability to File Transfers Batch Processing Although the HL7 Standard is defined in terms of the client server remote operation model its standards are equally applicable to file transfers One or more m
530. saction Checklist Role Variance Role Observation Notes and Comments Common Order Order Detail Notes and Order Detail Comments Variance Order Observation Result Notes and Comments Observation Variance Observation Result A 4 11 Introduction to Z Segments HL allows for the development of segments and messages to address data that the Standard doesn t support More detailed information appears in the HL7 Standard Version 2 3 Chapter 2 Control Query A 4 11 1 When to Create Z Segments Create Z segments when an interface requires the communication of data currently not defined in the standard Data currently defined by the standard may not be communicated on a Z segment For example patient name is currently defined on the PID segment and therefore cannot be a part of a Z segment A 4 11 2 How to Develop New Z Segments Follow these rules when defining Z segments 1 Include data elements related to a single object entity on a segment Group logically related data such as patient demographic information insurance information or census information Following are guidelines for identifying related data listed in preferred usage order e Group data into Z segments that correspond to entities or objects e g Visit Patient Patient Account e Group data into Z segments that correspond to tables e Group data into Z segments that correspond to files 2 Use existing Z segments before defining new ones
531. se Change Management Activities Health Level Seven Implementation Support Guide Page F 77 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 14 3 Security Audit Activities 14 4 Due Diligence Check List 15 DEPENDENT ACTIVITIES 15 1 Lab System Test Node Install 15 2 Hardware Upgrade s if any 15 3 New Lab System Release if any Page F 78 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix G HL7 FAQ This section contains a list of frequently asked questions about HL7 Please feel free to distribute it Commercial rights are reserved by HL7 This is an unofficial document and as such is included in this version of the HL7 Implementation Guide The opinions are those of the author and the author hopes of the cited contributors This FAQ is also available on the internet at lt http dumccss mc duke edu ftp standards html gt G 1 WHAT S NEW AUTHORS CONTRIBUTORS G 2 WHO ARE THE AUTHORS AND CONTRIBUTORS TO THIS FAQ Wes Rishel wes rishel com is the author of the FAQ Al Stone stone001 mc duke edu has provided substantial assistance in researching its contents and improving its presentation The following individuals have contributed to the FAQ by their postings on the HL7 List Server John Barthle 75522 3032 compuserve com Norman Daoust norman daoust dfci harv
532. se cystic fibrosis We did not define duodenal fluid sodium as a separate LOINC code because this measure has not been standardized This does not mean that the specifics about the system would be ignored It just means that this information would be recorded in another field of the message the specimen field of the HL7 OBR segment not in the name For many chemistry tests we have included in the LOINC database a test name for identifying miscellaneous types of body fluid FLU to provide a way to distinguish tests that are performed on fluid types that are not explicitly represented in the database We use the code XXX to identify a material that is not specified it could be solid or fluid for example For many types of tests the distinction between plasma and serum is irrelevant When testing on serum or plasma is clinically equivalent the system should be recorded as SER PLAS Sometimes the test can only be run on either plasma or serum the component will then be associated with either SER or PLAS in one observation If the test can be run on either but the results are different and standardized a very rare circumstance two separate tests will be defined in our file one with a system PLAS and one with a system SER The current LOINC database includes some SER tests and some PLAS tests that should really be SER PLAS As we determine that a SER or PLAS test really should have been designated SER PLAS we will change the designation If the
533. sending station to protect against an invalid response or no response Timer A is started after the transmission of the last character of a block or after sending ENQ Timer A is stopped upon receipt of a valid reply ACKN NAK or EOT The value for Timer A includes the response time of the receiver plus the time to transmit the acknowledgment sequence It should be slightly longer than Timer B When timeout occurs while sending a block the sending station either retransmits the block up to N times or 2 follows the Sending Station Abort procedures by transmitting EOT When timeout occurs while bidding for master status ENQ will again be sent to request the line Timer B Receive Timer Timer B is used by a slave station to protect against failure to recognize the end of a block ETB or ETX Timer B is started upon receipt of start of block or start of text SOH or STX Timer B is stopped upon receipt of a valid terminating character or sequence for example ETB or ETX Since Timer B is the time to transmit a complete block its value is a function of the baud rate maximum message size and any intrablock delays by the sender if a message block is sent in pieces Page C 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix C Lower Layer Protocols When timeout occurs 1 Prepare to receive another transmission 2 Discard incompl
534. shows micromol L in Line 1 which is the unit of measure for the submission This is the S UNITS field of the database The first line of Table 21 continues with the remainder of the submission data The Property of the submission is SCNC stored in field S PROP then the Time field with the value PT field 5 TIME System is UR field S SYS Scale is QN field Health Level Seven Implementation Support Guide Page H 51 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC S SCALE and Method is null field S METH Notice that Line 1 contains the original data as received from the submitter Line 2 is a blank line used to separate the original submitter s data from the remaining data for the submission Line 3 is the revised submitter s data i e R COMPO R PROP R TIME etc The data in this line represents the submitter s data but perhaps revised by RI to more clearly fit the LOINC naming conventions Often the revisions represent correction of typographical errors and inconsistencies NOTE These revisions may change the intention of your submission Therefore it is very important that you review such revisions very carefully when we return the mapped codes to you Notice the three asterisks following SCNC in the Property field The asterisks are used to mark the word where the revised item deviated from a similar test as stored in the
535. sitory 8 7 2 3 Negotiate Mod Unique Filler Placer Nbrs Lab Orders Results to Clinical Data Repository 8 7 2 4 Negot Mod Unique User ID Across Systems Lab Orders Results to Clinical Data Repository 8 7 2 5 Identify Code Values Translations Lab Orders Results to Clinical Data Repository 8 7 2 6 Identify Translation Requirements of Messages Segments Lab Orders Results to Clinical Data Repository 8 7 3 Complete Final Specification Lab Orders Results to Clinical Data Repository 8 7 4 Obtain Lab Orders Results to Clinical Data Repository Spec Signoff 8 8 Synchronization of Test Procedure Directories for Orders Results FROM Lab Analysis 8 8 1 Pathology 8 8 2 Laboratory 8 8 3 Microbiology 8 8 4 Blood Bank 8 8 5 Outsourcing 8 9 Lab Orders FROM Clinical Data Repository Specification 8 9 1 Identify Messages Trigger Events Lab Orders FROM Clinical Data Repository 8 9 2 Negotiate Modifications 8 9 2 1 Negotiate Mod Unique Patient ID Lab Orders FROM Clinical Data Repository 8 9 2 2 Negotiate Mod Unique Account ID Lab Orders FROM Clinical Data Repository 8 9 2 3 Negotiate Mod Unique Encounter ID Lab Orders FROM Clinical Data Repository 8 9 2 4 Negotiate Mod Unique Filler Placer Nbrs Lab Orders FROM Clinical Data Repository 8 9 2 5 Negot Mod Unique User ID Across Systems Lab Orders Health Level Seven Implementation Support Guide Page F 73 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appe
536. sment Technical Architecture eee 2 4 2 1 Identify Transaction Volume Capacity sss sss sees sees eee eee 2 4 3 Application And Technology Requirements esee 2 4 3 1 Identify Application Information Requirements eee 2 4 3 2 Identify Application Technology Use eee 24 33 Assess Susi sui i trea celo ee o c ota o t oA tte 2 4 3 4 Identify Application For Replacement Modification eee 2 5 TECHNICAL ARCHITECTURE ai 2 5 1 Technology Requirements ota iaa 2 5 1 Identify User Technology cscs iiec e aae e esten chartas idad OSO 231 2 Establish Technical State ci ciu eod idet od 2 5 1 3 Identify Additional Hardware Software esee 2 5 2 Communications Network Strategy sees eee eee ee eee 2 5 2 1 Establish Communications Strategy sess 2 5 2 2 Define Communications Protocols esee 2 5 2 3 Assess Need For Integration Tools cei teda diae eed Dada ee edad 2 5 2 4 Evaluate Cabling ODUOIS adi dnd ais 2 5 2 5 Define Network Management Requirement eese 2 5 2 6 Identify Communications Hardware Software eese 2 5 2 7 Identify Character Translation Requirement eee 2 6 ORGANIZATION STRATEGY nenen 2 6 1 Organizational Considerations sss esse eee ee eee 2 6 2 Project Staffing And Organization EE 2 6 3 Training And Conversion Plannmg cete dee ad ZF Migtation Strates yresnireene
537. spec and the sample code are all available on the Duke server ftp dumccss mc duke edu standards HL7 sigs SIGOBT The HL7 Version 2 X Object Mapping Specification OMS prescribes the process of translating a given version of the HL7 protocol to a set of objects and methods that can be used to implement HL in an object brokering technology Rob Seliger has developed an initial concept paper that will be the basis for the OMS In this abstract model the objects are things like Producer Consumer Message Segment Name Date and so forth The Message and Segment objects are exact analogues of the corresponding data structures in HL7 Version 2 X From this abstract specification we can prepare specific specifications for LE CORBA OpenDoc or other object brokering technologies HL7 does not endorse any of these object technologies but is serving as a focus for any group of five or more HL7 members that wants to include a technology in this process During a series of interim meetings specifications have been prepared for the OLE version on a prototyping basis and this experience has been fed back into the preparation of the OMS This second prototype will be shown in a demo at HIMSS ADT and Results data will be made Page G 10 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved G 8 1 3 G 8 2 G 8 2 1 Appendix G Frequently Asked Questions available by Pr
538. specified LOINC names The SNOMED Editorial Board can create hierarchical concepts in the SNOMED P3 Laboratory Procedures axis that combine any one or two LOINC relationships However if one of the relationships is the LOINC component relationship SNOMED can NOT combine it with the LOINC system relationship When the SNOMED Editorial Board has the need to use more than two LOINC relationships the Editorial Board will work with the LOINC Committee to create a mutually acceptable solution Any concept in the SNOMED P3 axis that currently does not meet these criteria will be retired and or given to the LOINC Committee for consideration LOINC will not define codes for entities that would be stored as values for its observations including those that are listed as text in the answer field of the LOINC database 4 The components of LOINC names will be mapped to their corresponding atomic SNOMED elements The entire mapping along with the LOINC copyright requirement will be published in a future release of SNOMED Contact the CAP if you are interested in examining a pre release version of this mapping SNOMED version 3 4 contains numerous additions to the SNOMED chemicals functions living organisms and other atomic axes that are referred to by the LOINC mapping 12 What is not part of the name Certain parameters and descriptions pertaining to test performance are specifically excluded from the fully specified test name These parameters will typica
539. ssage is ended with ETB 5 A block that ends at the end of a message is ended with ETX 6 The ETB or ETX character is immediately followed by the two block check characters BCC After the ETB or ETX and BCC are sent the master station waits for a reply C 3 3 2 Replies The slave station upon detecting the ETB or ETX followed by the BCC determines whether it will send ACKN or NAK The receiver verifies that a block was received correctly by checking that 1 The message terminated with TERM 2 Thecalculated BCC matches the BCC in the message 3 The number of bytes in the message text matches the Text Length in the message 4 The message text is followed by either an ETB or ETX Page C 16 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved C 3 4 C 3 4 1 Appendix C Lower Layer Protocols The receiver checks the block sequence number BLK to detect duplicate or missing blocks BLK of 1 is expected in the first block received after establishment of master slave BLK of 2 is expected in the second block received Subsequent BLK numbers sequence up to and include 7 after which they wrap to 0 and sequence upward as before This sequencing continues for the remainder of the master slave relationship 1 ACKN a Ifthe transmission block was accepted and the slave station is ready to receive another block it sends the appropriate ACKN 8 where N is the
540. st A 4 9 11 2 RRI Originator A or B See A 4 9 11 A 4 9 13 114 Cancel Patient Referral See A 4 0 11 A 4 9 14 115 Request Patient Referral Status See A 4 0 11 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Message Header Message Acknowledgment Referral Information Authorization Information Contact Data Provider Data Contact Data Patient Identification Accident Information Diagnosis Information Diagnosis Related Group Allergy Information Procedure Authorization Contact Data Observation Request Notes and Comments Observation Result Note and Comments Patient Visit Patient Visit Additional Info Notes and Comments A 4 9 12 113 Modify Patient Referral Page A 83 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 10 Patient Care A 4 10 1 PC6 PC Patient Goal PGL Originator A or B Message Header Patient Identification Patient Visit Patient Visit Additional Info Detail Goal Notes and Comments Goal Variance Goal Role Goal Variance Role Detail Pathway Variance Pathway Observation Result Notes and Comments Detail Problem Notes and Comments Problem Variance Problem Role Problem Variance Role Observation Notes and Comments Common Order Order Detail Notes and Order Detail Comments Variance Order Observation Result Notes and Comments Observation
541. ster slave relationship When a timeout invalid or NAK response to a line bid ENQ is received the sender transmits ENQ again This may occur up to L times The recovery procedure after M unsuccessful retransmissions 1 Notify the operator or the processor program or both 2 The sender may continue to request the line by sending ENQ with an appropriate delay between requests C 3 6 3 Parameters and Defaults The following parameters should be defined when implementing this protocol Many are subject to local agreement Some defaults are given in parenthesis but are not mandatory Health Level Seven Implementation Support Guide Page C 21 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix C Lower Layer Protocols Buffer Sizes e Maximum Message Size e Maximum Block Size Timer Values e Timer A 6 seconds e Timer B 3 seconds e Timer D 30 seconds e Timer E 3 minutes Contention e Station designated as Primary e Contention Retry Delay Primary Station 1 second e Contention Retry Delay Secondary Station 3 seconds Retry Counts e L block transmission 5 times e M line bid 10 times e Delay between requests after M retries 30 seconds Physical Layer Parameters for RS 232 e Baud rate Easily switched between 1200 2400 4800 9600 bps e Start Bits 1 e Stop Bits 1 e Data Bits 8 Standard Extended ASCII ANSI X3 41 1974 code extension techniques e Parity Odd C 4 MINIMAL LOW
542. structions Example 12345 1 Take the odd digit positions counting from the right 531 2 Multiply by 2 1062 3 Take the even digits starting from the right 42 4 Append these to the front of the results of 2 421062 5 Add the digits of 4 together 6 Find the next highest multiple of 10 4 2 1 0 6 2 15 7 Subtract 5 from 6 20 20 15 5 Thus 5 is the Mod 10 check digit for 12345 Page H 46 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Appendix C Procedure for Submitting Additions Changes to the Database Introduction We receive two kinds of requests for additions 1 The first kind of request deals with a an entirely new kind of measurement e g DNA sequencing or b the use of LOINC codes in manners that have not been agreed upon by the LOINC committee e g the definition of terms to accommodate the organism 1 organism 2 etc structures that are present in many laboratory databases 2 Other requests are variations on observations that are already in the database E g we have a term for a particular test result with serum as the specimen system and a user requests an identical term for a specimen of gastric contents Provided that the requestor followed the rules given below and the number of terms requested at a given time are modest we will try to respond to these kinds of reques
543. subject filter Added the following values GOL PRB SAL SBK SBL SOP SSA SSR VXI 0052 Diagnosis type Added the following suggested values A W F 0053 Diagnosis coding method Removed the following value I9 Specimen source codes Table name changed from Source of Specimen to Specimen Source Codes added the following values BIFL BLDC BPU BLDV DIAF DOSE DUFL EARW EYE EXHLD GAS IHG ISLT LIQ PAFL PAT PPP PRP RT TLGI TLNG TSMI TUB UMED URNS USUB WAT XXX deleted the following values PER TISL TISP TISU TISC 0074 Diagnostic service section ID Added the following values ICU LAB and RAD 0076 Message type Added the following values ADR CRM CSU EDR ERP EQQ PPG PPP PPT MDM MEN MFK MFD MFQ MFR OSR PEX PGL PIN PPR RCI RCL RGR REF RQC ROP RPA RPI RPL RPR RQA ROL RRI SIU SPQ SOM SQR SRM SRR TBR VQQ VXQ VXX VXR VXU PPV PRR PTR QCK SUR 0092 Re admission indicator Removed the following value null 0106 Query response format code Added the following value T table name changed from Query format code to Query response format code 0119 Order control codes and their Added the following values FR AF DF FU OF UA meaning OE 0123 Added the following value A Value type Added the following values CP CX ED SN XAD XCN XON XPN XTN deleted the following values TQ ID SI CM CQ 0133 Procedure practitioner type Added the following values SN PS AS 01
544. supports the interface s once they are implemented and live Functional requirements of the interface s and a testing plan should be drawn up and agreed upon prior to beginning implementation Again these should be in accordance with the specifications of the customer Test data must be provided from the sending side and it must be signed off on prior to live testing The intent of this is to minimize any surprises at the last minute as our experiences with vendors in the past have been that they do not review the test data provided to them Any master files that need to be built to facilitate interface s have to be agreed upon as well as provisions for their creation and maintenance Naming conventions for the interface objects may need to be developed and documented for the purpose of future maintenance Health Level Seven Implementation Support Guide Page D 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix E Sample Case Studies BEE E 1 INTRODUCTION The intent of this appendix is to provide health care organizations who are considering or are in the process of implementing HL7 interfaces with case studies from other healthcare organizations who utilize the HL7 Standard Case studies have been voluntarily submitted to HL7 for inclusion in this appendix E 2 CASE STUDY ADT and Charge Interfaces using HL7 and TCP IP Contributed By Patricia Burtchaell Programmer Analyst Deaconess Billing
545. sured using optical density as the detection method However the property we are really measuring is an arbitrary concentration ACNC not the optical density If it is a ratio of optical densities as with Gliadin AB Parvovirus B19 AB etc that are compared patient value divided by a standard control then the property should be ACRTO arbitrary concentration ratio 14 ml min 1 73sqM Milliliters per min per 1 73 square meters BSA Similar to the immediately preceeding item This result has the same property as if it had units of ml min sqM The property of this measurement should be called areic volume rate The hierarchy of units should be RateUnits gt Aereic VolumeRateUnits gt ml min sqM A sibling to ml min sqM should be ml min 1 73sqM Health Level Seven Implementation Support Guide Page H 57 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98
546. t eese eene enne nnne nnne B 24 B L46 MEE Master File EDS s se ie ue oho eege Mem tu ara B 24 B 1 47 MFI Master File Identification eese eee eee en nenne enne enne een nes B 25 B 1 48 MRG Merge Patient Information sss sese B 25 B 1 49 MSA Message Acknowledgment sss sees porem eel Gee eek B 25 B 1 50 MSH Message Header Required segment sss sese seene B 26 B 1 51 NK1 Next of Kin Associated Parties AA B 26 B 1 52 NPU Bed Status Update ics eee e dial dicas B 28 51 33 NEE 5 Notessand COMME DES sc ees orestis NEN pde ida B 28 B 1 54 OBR Observation Request a Ri B 28 B 1 55 OBX Observation ReEsult eO id RE aid B 30 B 1 50 ODS RE e B 30 B157 OD ter Tray THSUUCETOTIS eege ee B 31 B T 55 0NIT General SEO a dd B 31 Health Level Seven Implementation Support Guide Page TOC 13 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Table of Contents HL7 Implementation Support Guide B 1 59 OM2 Numeric Obs O id atadas B 33 B 1 60 OMG Categorical Test Observation sss sees esse eee eee B 33 B 1 61 OM4 Observations That Require Specimens eene B 34 B 1 62 OMS Observation Batteries seis B 34 B 1 63 OM6 Observations That Are Calculated From Others 8 48 B 34 B 1 64 ORC Common Order scere eO IEEE QUEE iaa a EES E B 35 B 1 65 PCR Possible Casual Relationship s ose teer tto o tesi ea este pd E
547. t Use the output from section 3 4 2 1 Select Lower Layer Protocol Health Level Seven Implementation Support Guide Page 3 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 3 Implementation Methodology 3 6 3 Select Install Hardware Hardware includes upgrades to and or purchases of new hardware components such as memory or disk CPU communications boards networking hardware e g bridges routers gateways modems multiplexers etc workstations and printers Make sure to take delivery and installation lead times into account when planning your order dates for any hardware components 3 6 4 Select Install Software Software includes not only HL7 interface code for each application but also additions or modifications to system or application software communications software and perhaps network management or diagnostic software 3 6 5 Network Communication Testing After selecting and installing the hardware you have software and lower level protocol necessary for the interface the basic communications environment This should include testing point to point connection virtual circuits concurrent access and volume stress Devices such as line monitors and network sniffers should be employed to generate and monitor basic lower level protocol traffic This unit type test of the communications equipment will facilitate interface testing and isolation of problems during integration a
548. t be easily visible for these users For reference the SIGOBT diagram at the web site listed above is 395 pixels wide by 430 high Please use a GIF file format when you are submitting a diagram as a bitmap For diagrams that contain solid colors GIF files are far more compact and more accurately rendered than JPEG files For esthetic reasons consider using the transparent background option for your GIF files For PC users two fantastic shareware programs for working with images are Lview Pro and Paint Shop Pro The help files alone are worth the bother of a download Use color in diagrams where it is important to clarify the thought But please do not use color just to pretty up a diagram The time a browser takes to download a black and white diagram will be 1 8th of the time for color For users who access the Web with a high speed modem the time can be 6 seconds for black and white vs 48 seconds for color Multiply this by the number of diagrams that we would like to include When you use color it is helpful if you confine its use to a few solid colors There is a bandwidth saving if there are fewer than 16 colors including black and white Remember Smoky the Internet Bear says Only you can prevent data avalanches Diagrams are omitted from this version of the Frequently Asked Questions GA DESIGN AND DISCLAIMERS G 4 1 What is the Purpose of this FAQ and What Disclaimers Does it Carry The primary goal is to give people a way to
549. t benefit analysis in order to document the economic impact of implementing the new systems architecture 2 8 1 Costs 2 8 1 1 Operating Maintenance Costs Identify and document the costs of operating maintaining the current systems as a basis for comparison 2 8 1 2 One Time And Ongoing Costs Identify and document all of the one time and ongoing costs associated with the effort of implementation including e Hardware Software Communications use the output from sections 2 5 1 3 and 2 5 2 6 e Installation e Internal Personnel use the output from section 2 6 2 e Interface Page 2 8 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 2 Planning Methodology e Consulting Vendors e Facility e Other e Hardware Software Maintenance e Opportunity costs and the time value of money 2 8 2 Benefits Establish target benefits for the project s Both tangible and intangible benefits should be included in these targets Develop a benefits realization plan in order to help the organization manage the project and associated activities in a manner that enables attainment of the target benefits Obtain agreement from user departments and executive management that the target benefits are reasonable and establish responsibilities accountabilities for achieving the benefits 2 8 3 Summary Prepare an overall summary economic analysis and re
550. t server model Health Level Seven Implementation Support Guide Page 1 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 1 Introduction 1 5 5 2 Page 1 6 Whenever HL7 is applied in a networking environment addressing will be an issue This is equally true when it is applied on ISO Standards networks or proprietary networks Although the Standard does not specify how this addressing will occur it does provide certain data fields that will be of value in determining addresses The fields MSH 5 receiving application MSH 6 receiving facility and MSH 11 processing ID are located in the header of all HL7 messages MSH 6 receiving facility is intended for environments where multiple occurrences of the same application are being run on the same computer system or on the same network on behalf of different institutions or other organizational entities MSH 11 processing ID is used where various versions of essentially the same application may reside on the same computer for different purposes See HL7 table 0103 Processing ID for recommended values The HL7 committee does not standardize the values for the MSH 5 receiving application and MSH 6 receiving facility at this time because there are so many variations in place in existing systems and because different kinds of environments e g different countries may have different required code sets However we strongly encourage the use of the HL7 suggested
551. t virtual circuit Network address may mean a combination of IP address and TCP port address or just a TCP port address as appropriate Error handling varies from application to application The only requirement from a network standpoint is that circuits not be left dangling Care should be taken that a single initiating module does not monopolize an accept module over a transient virtual circuit This may cause problems for other parts of the system trying to use the services of the accept module This problem may occur if the initiate module has a number of messages which take the accept module a long time to process or the initiate module takes a long time to process reply messages and the initiate module does not disconnect between messages It is assumed that an initiating module may connect and perform more than one message transaction before disconnecting but it may not have more than one outstanding message waiting for a response In other words the initiating task must wait for the response to a given message before sending another message The pseudo code here is given in a C like language Further clarification of the pseudo code can be given if requested Health Level Seven Implementation Support Guide Page C 31 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix D Helpful Hints D 1 INTRODUCTION The purpose of this appendix is to provide a forum for health care organizations who have
552. ta intact The second RPG program which is again executing segments of the Pascal program picks up the ACK or NACK and writes it out to a receiving data queue If the acknowledgment is not positive that RPG program notifies operations of the problem by sending an informational message The HL7 ADT program then receives the data queue and checks for an positive ACK If it does not receive back a positive acknowledgment it alerts the other programs that it is terminating and they in turn end It is up to operations to act upon the error message and resolve the problem Once that is done the interface programs can be restarted If the acknowledgments are positive the ADT interface program continues to read and process the trigger records as they arrive The charge batch is retrieved from the Tandem once a day The FTP subcommand GET is executed by an IBM CL program and the file is placed in a library on the AS 400 ready to be processed by the HL7 charge interface program That program interprets the messages and creates records that are processed by our daily financial posting run This interface did not need to be real time as we only post once a day in our financial system and the clinical system also generates charges in a similar manner Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved E 2 6 E 2 7 Appendix E Sample Case Studies Implementation Issues Th
553. tandard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 2 Planning Methodology 2 9 1 1 2 9 1 2 2 9 2 2 9 2 1 Page 2 10 Final Version 6 98 Skill level and availability of experienced resources The evaluation and selection of interface engine products should include the evaluation criteria listed above as well as the following criteria Performance guarantees that the vendor is willing to make for interface throughput Interface monitoring capabilities e g status screens and visual audible or print alerts when interface s go down Restart recovery and a commitment regarding system up time A clear understanding of configuration tools and flexibility Provide the vendor with anticipated scenarios during product demonstrations and view the effort required to accomplish the desired results Clear definition of what vendor provides in standard libraries to facilitate configuration e g interface scripts HL7 data dictionaries etc Product documentation and training Assess Need For Assistance Consider the need for a systems integrator to help coordinate implementation If one is required specific requirements including skills for the integrator should be identified and communicated General Vendor Evaluation Selection Establish criteria and weighting factors for evaluating and selecting the vendor s and obtain agreement from MIS users and management Review vendor responses i
554. tatype changed from NM toID_ e a Type MSH 16 Application X Acknowledgement Type MSH 17 Country Code xl TI MSA 6 Eror Condition xl TI ERR 1 L Code and Location x DatatypechangedfromIDtoCM QRD 1 Query Date Time T Length changed from19t026 QRD 6 Deferred Response X Length changed from 19 to 26 Date Time Quantity Limited Request a Length changed from 19 to 26 When Data Start FS x Length changed from 19 to 26 Page 4 8 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 4 HL7 Version 2 2 Overview Date Time S When Data End Date Time MOE xx Length changed from 19 to 26 Q INE E OA Qualifier Qualifier R U When Data Start R U When Data End QRF 8 URD 1 URS 2 URS 3 URS 6 URS 7 URS 8 DSC 1 ADD 1 FHS 7 FTS 1 BHS 7 BTS 3 NTE 3 R U Which Date Time R U Which Date Time R U Date Time Selection Addendum Continuation Batch Creation Date Time Batch Totals Comment X X X X X Length changed from 19 to 26 Length changed from 19 to 26 Length changed from 19 to 26 Length changed from 60 to 180 Length changed from 60 to 64K Length changed from 19 to 26 Datatype changed from ST to NM Length changed from 19 to 26 Now repeating No longer required length changed from 120 to 64K Datatype changed from TX to FT 4 3 2 Chapter 3 Admission
555. ted by printing out the contents of these fields 2 7 inserting a colon between the contents of each of these fields One or more synonyms separated by semicolons This field is intended to make it easier to find a given observation by providing other names by which the observation may be known For a drug level for example we include the trade names of that drug under the related names An arbitrary classification of the terms for grouping related observations together The current classifications are listed in Table 18 We present the database sorted by the class field within class type see field 10 Users of the database should feel free to re sort the database in any way they find useful and or to add their own classifying fields to the database Field 10 Source is for our internal use and should be ignored by database users EUCLIDES analyte code The Euclides code identifies the analyte the first subpart of the first part of the name The ASTM codes apply to only a few of the tests e g cell counts antibiotic sensitivities These are the codes included in the appendices of HL7 and ASTM E1238 94 13 IUPAC CD Char 8 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved The IUPAC code identifies the component kind of property and system Note Most of the IUPAC codes for chemistry assume the component is measured in substance concentration
556. tegrity maintained 5 What happens if data integrity is not maintained 6 What optional performance features are available 7 Describe real time performance monitoring utilities 8 Can performance tuning be performed dynamically e g can I O paths be altered can CPU resources be redirected etc 9 How is network performance monitored 10 Describe real time network performance monitoring utilities 11 How is disk performance monitored 12 What is the processor and performance overhead associated with the various data modalities e g text voice imaging video 13 How does a GUI interface impact performance and what considerations options must be implemented to support this 14 How does a CUI interface impact performance and what considerations options must be Health Level Seven Implementation Support Guide Page F 35 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates implemented to support this 15 Identify inbound outbound transaction volume limitations 16 Identify transaction turnaround rate that is provided by the recommended processor operating system I O subsystem and network configuration 17 Describe performance management GUI if available F 1 8 6 Fault Tolerance Because the AIE will be providing critical services to all areas within the hospital and due to the dependence other systems have on the AIE for Interface information
557. tes and Comments Health Level Seven Implementation Support Guide Page A 79 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 9 8 A 4 9 8 1 Page A 80 108 Request for Treatment Authorization Information RQA RPA RQA Originator A or B Final Version 6 98 Message Header Referral Information Authorization Information Contact Data Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert Accident Information Diagnosis Information Diagnosis Related Group Allergy Information Procedure Authorization Contact Data Observation Request Notes and Comments Observation Result Note and Comments Patient Visit Patient Visit Additional Info Notes and Comments Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 9 8 2 RPA Originator A or B See A 4 9 8 Message Header Message Acknowledgment Referral Information Authorization Information Contact Data Provider Data Contact Data Patient Identification Next of Kin Associated Parties Guarantor Information Insurance Information Insurance Information Additional Info Insurance Information Cert Accident Information
558. th Level Seven Implementation Support Guide Page 3 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 3 Implementation Methodology 3 2 1 3 3 2 1 4 3 2 1 5 3 3 3 3 1 3 3 2 3 3 2 1 3 3 2 2 Page 3 2 Develop Schedule Within the context of the overall project and relative to resource availability and task interdependencies determine the due dates and or duration times for all tasks From this develop the implementation schedule and publish Distribute this schedule to the clinical area management as well as information systems Also share the schedule with vendors involved in the implementation so that they are clear as to what is expected of them and when The schedule should be updated and redistributed on a regular basis Review Revise Internal Standards Review and revise as necessary internal standards regarding interface development including migration conversion change control restart recovery and backup Attend Interface Engine Training If installing an interface engine it is a good idea to complete product training prior to finalizing interface specifications This will enable you to take specific interface engine capabilities into account when designing the interfaces and should reduce specification modifications later on FUNCTIONAL DESIGN Develop Interface Descriptions Document general functional descriptions of the interfaces to be developed including the a
559. th a message which has 1 in the Expected Sequence Number field of the MSA segment MSA 4 At this point the receiving system does not have an Expected Sequence Number The next message received which has a positive non zero sequence number determines the Expected Sequence Number of the receiving system The receiving system sets its Expected Sequence Number to the sequence number of the incoming message Note Ifthe receiving system is queried message sequence number equals zero after the synchronization message but before receiving a positive non zero sequence number it should reply with a 1 in the Expected Sequence Number field of the MSA segment C 5 8 Overview of the Sequence Number Protocol The following two tables provide an overview of the sequence number protocol The first shows the state of the receiving system without an existing Expected Sequence Number such as can occur during startup or synchronization The second shows the state of the receiving system when an Expected Sequence Number exists Current State of Receiving System Expected Sequence Number NONE Incoming Message Seq Expected Seq Num Next State of Receiving EE Field of MSA System Same as incoming Same as Incoming 1 Current State of Receiving System Expected Sequence Number gt 1 Num Field of MSA System SE SSES 4 same asncoming same a coming C 5 9 Link Management Messages The messages used to query and synchronize the link do not
560. th check digit XCN Extended composite ID number and name XAD Extended address XPN Extended person name XON Extended composite name and ID number for organizations XTN Extended telecommunications number CD Channel definition MA Multiplexed array NA Numeric array ED Encapsulated data CP Composite price FC Financial class QSC Query selection criteria QIP Query input parameter list RCD Row column definition DLN Driver s license number JCC Job code class VH Visiting hours PPN Performing person time stamp DR Date time range RI Repeat interval SCV Scheduling class value pair 5 3 3 2 New Sections e Section 2 10 2 Version compatibility definition e Section 2 15 1 Display vs record oriented queries original model embedded query language virtual table and stored procedure queries and event replay requests has been expanded to include a sub section on Interactive continuation 2 15 4 e Section 2 19 ENHANCED MODE QUERY MESSAGES Health Level Seven Implementation Support Guide Page 5 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 5 HL7 Version 2 3 Overview e Section 2 21 QUERY MESSAGE IMPLEMENTATION CONSIDERATIONS e Section 2 22 QUERY ERROR RESONSE e Section 2 23 4 Modes for updating via repeating segments is new e Section 2 25 4 Query Examples has been updated to include the following new subsections 2 25 2 Enhanced mode query examples 2 25 4 2 1
561. the hooks for access control OBJECT BROKER TECHNOLOGIES Douglas Pratt SMS Ph 610 219 3050 Fax 610 219 3124 Email doug pratt smed com Wes Rishel Wes Rishel Consulting Ph 510 522 8135 Fax 510 521 2423 Email wes rishel com Daniel Trainor Hewlett Packard Ph 508 659 3241 Fax 508 686 1319 Email kbiebelGcpr tech com Page 1 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 1 Introduction Mission The charter of the group is to facilitate prototype implementations of HL7 in Object Brokering Technologies Examples of Object Brokering Technologies include OLE 2 0 Microsoft CORBA Object Management Group Distributed Objects NextSTEP Object Broker DEC and OpenDOC industry consortium Projects The general plan is to select some specific transactions that are relatively simple develop a specification based on HL7 V2 2 then develop vendor specific specifications and implementations The choice of vendors will be made by the individual HL7 members doing the development of the prototypes SECURE TRANSACTIONS Berndt Blobel MD The University of Magdeburg Ph 49 3916713542 Fax 49 3916713536 Email bernd blobel mrz uni magdeburg de Mary Kratz University of Michigan Medical Center Ph 313 763 6871 Fax 313 763 0629 Email mkratz umich edu Gunther Schadow Regenstrief Institute for Health Care Ph 317 6307
562. the American Association of Blood Banking and other sources as well as the expertise of the individuals or the committee to choose preferred names Examples of fully specified LOINC names SODIUM SCNC PT SER QN SODIUM SCNC PT UR QN SODIUM SRAT 24H UR QN CREATININE RENAL CLEARANCE VRAT 24H UR QN GLUCOSE 2H POST 100 G GLUCOSE PO MCNC PT PLAS QN GENTAMICIN TROUGH MCNC PT SER PLAS QN CALCIUM FREE SCNC PT SER PLAS QN ALBUMIN MCNC PT SNV QN 2 General naming conventions 2 4 4 Abbreviations in names of component analyte Except for enumerated exceptions Table 2 abbreviations should not be used in the component analyte of the name We require the use of total not tot Fraction not frac alpha not A Beta not B and so on for any Greek letter oxygen not O and so on 2 4 2 General naming rules for the component analyte part of the fully specified name 2 1 2 1 Place the identifier of the substance being measured first This means Hepatitis A antibodies AB not Antibodies Hepatitis A 2 1 2 2 Use the generic name of a drug not the brand name when referring to drug concentrations and minimum inhibitory concentrations MICs e g Propranolol not Inderal For concentrations of drugs and to antibiotic susceptibility we will usually include the brand or trade names in the field related name Health Level Seven Implementation Support Guide Page H 13 for HL7 Standard Version 2 3 1998 All rights reserv
563. the recommended processor 5 Does the system provide disk caching features If so what are they 6 Describe high performance features of recommended disk subsystem 7 Describe availability data integrity and error detection correction features of recommended disk subsystem 8 Describe system RAID capabilities 9 Describe system disk grouping clustering capabilities F 1 8 3 Network and Communication Protocols The AIE product at St Anybodys Medical Center will be providing critical services to the entire information systems arena What this means to St Anybodys Medical Center is the AIE must have the ability to successfully integrate and communicate with all of St Anybodys Medical Center s existing and planned information systems St Anybodys Medical Center operates on a number of disparate platforms that are integrated through network services This type of environment is expected to continue growing as we implement more systems to assist the institution achieve its mission 1 Describe the attributes you deem important as network features when implementing the AIE product 2 What types of communications adapters are available for the recommended platform Please list all available 3 Can the platform accommodate multiple communications adapters If so can they be of varying types Health Level Seven Implementation Support Guide Page F 33 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 9
564. ticipated that the hardware platform will be configured with the appropriate cables Describe any cabling that will be required to support the AIE 2 Provide a schematic representing the physical layer of the network to describe how St Anybodys Medical Center systems will be connected to the AIE F 1 8 11 Security Specifications This section subsection defines the specifications for security functions both necessary and desirable for implementation of an AIE at St Anybody s Medical Center If specific features or functionality are unavailable the AIE vendor must identify these as unavailable and propose alternative solutions that meet St Anybody s Medical Center s integration requirements If a function is available in a future release please note the anticipated release date Again the questions must be printed along with the answer and identify in what module your system provides each of the features The current information systems at St Anybody s Medical Center security environment consists of individual security systems based on processor OS platform The platform security package correlation is as follows DEC VAX VMS Standard VMS Security Application Level Security Ultrix BSD level Security Application Level Security St Anybody s Medical Center currently performs security checks at the dataset level user ID level transaction level volume level task level and system level All current systems generate security logs fo
565. tient Visit Disability Information Appendix A HL7 Transaction Checklist A 4 2 25 A25 Cancel Pending Discharge ADT Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information A 4 2 26 A26 Cancel Pending Transfer ADT Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information A 4 2 27 A27 Cancel Pending Admit ADT Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Originator A or B Originator A or B Originator A or B Page A 25 Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 2 28 A28 Add Person Information ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Next of Kin Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Diagnosis Related Group Procedures Role Guarantor Information Insurance Information Insurance Information Add l Info Insurance Information Cert Acci
566. tination CFU colony forming unit DNA deoxyribonucleic acid HIV human immunodeficiency virus HLA human histocompatibility complex derived antigens HTLV 1 human t cell lymphotropic virus 1 Igx immunoglobulins e g IGG for immune globulin G IGM for immune globulin M RNA ribonucleic acid RRNA ribosomal nucleic acid 2 1 2 9 VDRL will be named Reagin AB because that is what it is We will have to depend upon synonyms and aliases to equate our standardized names with the old names 2 1 2 10 Use the noun form of the target of the antibody e g Myocardium AB not Myocardial AB 2 1 2 11 Anion vs acid Always use the anionic name for chemicals not the acid name e g lactate citrate and urate not lactic acid citric acid and uric acid The acid form of the name will be included in the synonym field of the database 2 1 2 12 Alcohols Always use the single word names for alcohols methanol not methyl alcohol ethanol not ethyl alcohol and so on 2 1 2 13 Always spell out OH as Hydroxy or as ol with no space or hyphen between Hydroxy and the next word 2 1 2 14 Greek letters alpha beta gamma etc are always spelled out e g alpha tocopherol not A tocopherol with a space between the spelled out Greek letter and the rest of the chemical name 2 1 2 15 Use pH not log H 2 1 2 16 When naming allergenic materials of plant or animal origin order the common name to reflect the Linnaean taxonomy of genus spe
567. tion at a moment of time or an observation integrated over an extended duration of time e g 24 hour urine 4 The type of sample e g urine blood 5 The type of scale e g whether the measurement is quantitative a true measurement ordinal a ranked set of options or nominal E Coli Staph Aureus 6 Where relevant the method used to produce the result or other observation It also contains information about the amount route and timing of physiologic or pharmacologic challenges eg oral glucose tolerance test which would be expressed in LOINC as GLUCOSE 1H POST 100 DL GLUCOSE PO5 The LOINC identifiers do not usually include the method in the name for chemistry tests where tests are more often standardized to normalized methods but do include it for most serological tests and coagulation studies This same principle is usually reflected in the master files of existing laboratories Of course the method can always be reported as a separate item of information in a result message regardless of whether it is part of the test name We used many sources for constructing the database including the Silver Book from the International Union of Pure and Applied Chemistry IUPAC and the International Federation of Clinical Chemistry IFCC textbooks of clinical pathology e g Henry and Tietz the expertise and work of the LOINC members and EUCLIDES We have also reviewed the master test files of seven sources Indiana Universi
568. to 120 data type changed from CN to XCN Data type changed from CM to PL Data type changed from TN to XTN Length changed from 80 to 120 data type changed from CN to XCN Length changed from 15 to 40 Data type changed from CM to CK Field name changed from Set ID Observation Request to Set ID OBR OBR 2 Placer order number f OBR 3 Filler order number E OBR 4 Universal service ID OBR 5 Priority OBR 6 Requested date time 1 OBR 8 Observation end date time OBR 10_ Collector identifier OBR 13 Relevant clinical info __ OBR 14 Specimen received date time OBR 16 Ordering provider OBR 17 Order callback phone number OBR 21 Filler Field 2 E OBR 22 Results rpt status chng date time OBR 24 Diagnostic serv sect ID EAN OBR 25 Result status Rf OBR 26 Parent result ie gt II OBR 28 Result copies to he OBR 29 Parent mE OBR 32 Principal result interpreter Ween Length changed from 60 to 200 OBR 33 Assistant result interpreter Length changed from 60 to 200 OBR 34 Technician LX Length changed from 60 to 200 Data type changed from CM to EI Data type changed from CM to EI optionality changed from R to C Optionality changed from O to R Optionality change from O to B Optionality changed from C to B Optionality changed from C to O Data type changed from CN to XCN Optionality changed from C to O Optionality changed from O to C Data type changed from CN to XCN Data type changed
569. to Patient Stop Date DT 98 ci 57 00797 Insurance Co Contact Reason IS 3022 D 4 G 932 58 00798 Insurance CoContactPhone XIN w S 59 0079 PolicyScope S IS o III Tomm 60 00800 PolicySource 1 s A om 61 00801 Patient Member Number CX 600 I Jp 62 00802 Guarantor sRel toInsured I en 63 00803 Insured s Phone Number Home XIN 4D Jol TI 64 00804 Insured s Employer Phone XTN w CE Page B 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix B HL7 Segment and Event Checklists 65 00805 Military Handicapped Program CE 60 OP TI 66 00806 SuspendFlag LL Do TL oe 67 00807 CopayLimitFlag Do X 3 TL 00939 i 68 00808 StoplossLimitFlag ID 39e 3 TL oe 69 00810 Insured Employer Org Name amp ID XON 30 Ol TI 70 00810 Insured Employer Org Name amp ID XON aso Uc TI 71 500093 Raso E E qe spo gt capu EEN 72 00811 HCFA Patient Rel to Insured CE 60 III TI B 1 39 N3 Insurance Certification Info IX 1 BOSORSPSECT
570. to XCN PV1 10 Hospital service Daa pe changed from ID toIS_ PV1 11 Temporary location X Length changed from 12 to 80 data A LU PV1 12 Preadmittestindicator IX Data type changed from IDtoIS PV1 13 Readmissionindicatr IX Data type changed from ID to IS _ PV1 14 Admit source X Data type changed from ID to IS PV1 15_ Ambulatory status X Datatype changed fromIDtoIS PV1 16 VIP indicator IX _ DatatypechangedfromIDtoIS PV1 17 Admitting doctor X Data type changed from CN to XCN TT E LU RAN PV1 18_ Patienttype LI Daa pe changed fromIDtoIS PV1 19 Visit number X Length changed from 15 to 20 data emm Y Le PV1 20 Financial class X Data type changed from CM to FC mem o Le PV1 21 Charge price indicator X Data type changed from ID to IS PV1 22 Courtesy code X DatatypechangedfromIDtoIS PVI 23 Credit rating X DatatypechangedfromIDtoIS PVI24 Contract code X DatatypechangedfromIDtoIS PVI28 Interestcode X _ DatatypechangedfromIDtoIS PV1 29 Transfer to bad debt code X DatatypechangedfromIDtoIS PVI 31 Bad debt agency code X DatatypechangedfromIDtoIS PV1 36 Discharge disposition EAT Data type changed from ID to IS PV1 38 Data type Data type changed from ID to IS PV1 39 Servicing facility Data type changed from ID to IS PV1 40 Bed status X D
571. to Y IN1 17 Insured s relationship to X Data type changed from ID to IS patient DN In Y A a changed from DT to TS Data type changed from AD to XAD repetition changed to Y IN1 20 Assignment of benefits IN1 21 Coordinator of benefits Data type changed from ID to IS Element name changed from Report of Eligibility Code to Report of Eligibility Flag Data type changed from ID to IS Data type changed from NM to CP optionality changed from O to B optionality changed from O to B optionality changed from O to B IX Data type changed from ID to IS INI 25 Report of Eligibility Flag IN1 27 Release information code IN1 30 Verification by IN1 31 Type of agreement code IN1 32 Billing status IN1 35 Company plan code IN1 37 Policy deductible E WW EN ES IN1 43 IN1 44 Insured s employer address IN1 46 Prior insurance plan ID INI 47 Coverage type INI 48 Data type changed from ID to IS Data type changed from AD to XAD repetition changed to Y Data type changed from ID to IS Page 5 24 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Segment Seq INI 49 Insured s ID number ESA a IN2 1 Insured s employee ID X Length changed from 15 to 59 data type changed from ST to CX repetition changed to Y number changed from NM to ST IN2 3 Insured s empl
572. to be able to provide more substantial support or to make a statement to their customers and prospects about their support for HL7 Some institutions choose to join HL7 as a corporate member in order to provide more substantial support or to make a statement to vendors about their interest in seeing HL7 compliance Corporate membership also simplifies administration for companies that have multiple working group members G 9 3 3 How Big is the HL7 Working Group There are approximately 1700 people who are currently eligible to vote in HL7 ballots Page G 18 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix G Frequently Asked Questions The average working group meeting includes about 250 members G 9 3 4 Who are the Principle Contacts for Questions and Comments about HL7 Karen VanHentenryck HL7 Associate Executive Director Health Level Seven 3300 Washtenaw Ave Suite 227 Ann Arbor MI 48104 Phone 734 677 7777 Fax 734 677 6622 KarrenVan hl17 org George Woody Beeler Jr Ph D Chair HL7 Board of Directors Mayo Foundation Phone 507 284 9135 Fax 507 284 0796 beeler mayo edu John Quinn Technical Chair HL7 Working Group Ernst and Young 2000 National City Center Cleveland OH 44114 216 861 5000 john quinn ey com G 9 3 5 When and Where are the Next Working Group Meetings e January 12 16 1998 New Orleans
573. to use it Traffic on the net server and the author s own contacts with some sites has shown that the Health Level Seven Implementation Support Guide Page G 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix G Frequently Asked Questions G 5 5 G 5 6 G 5 7 G 5 8 Page G 4 Minimal LLP is used quite frequently in TCP environments Whether it is best or not there is considerable advantage to doing what most other people do For vendors it reduces the likelihood that you will be compelled to do something different than your normal product For institutions it is usually faster cheaper and more reliable to have the vendors install code that has been developed and field tested at others expense Wes Rishel How Can I Send Binary Data in HL7 Messages The 2 3 draft allows for a mime encoded base 64 data type encapsulated data which could be used for example in the OBX value field There would have to be a bilateral agreement on the interpretation of such fields See files H7C2FINB DOC and H7C2FINB TXT in lt ftp dumccss mc duke edu standards HL7 pubs version2 3 control query Mark Shafarman Al Stone Are there Provisions in HL7 for European and Asian Character Sets The HL7 2 3 control query ballot includes support for other character sets Some of the language came from Japanese HL7 users and Technical Committee 251 in the European Community The proposal is to use ISO standard
574. tpllolss oso dees aageades aeons aed 3 2 3 3 2 Complete HL7 Transaction Checklists For Each Interface 3 2 3 3 2 1 Define Trigger Events By Appltcanon eee 3 2 3 9 2 4 Identify Required HL7 Segment sese sees 3 2 3 3 2 3 Identify Data Elements C haracteristits cit a 3 3 3 3 24 Identify Extra Z Segment Requirements dida 3 3 3 3 3 Document And Resolve Functional Interface Issues esee 3 3 3 3 4 Develop Restart Recovery Approach 3 3 3 3 5 Develop Failure Mode Response Approach 3 3 3 3 6 Develop Migration Approach sese 3 3 3 3 7 Develop User Access Security Approach sse eee 3 3 3 3 8 Obtain User Review And ACGCepancG esse eee 3 3 Sc FECHNIGAL DESIGN erka i E E E E E E NE T a Er eer er nee 3 4 3 4 1 Define Required Hardware Platforms eese nennen 3 4 3 4 2 Document Communications Design 3 4 SAI Select Lower Ee DE 3 4 3 4 2 2 Define Communications Hardware 3 4 3 4 3 Define Workstation Requirements id dree 3 4 3 4 4 Define Application Facility Name 3 4 3 4 5 Design Programs Lower Level Protocol A 3 4 3406 Application Level HL penei on a A aE E EA R 3 4 3 4 6 1 Application Code Modifications As Needed see 3 5 3 4 7 Define Document Specifications setenta eee 3 5 Health Level Seven Implementation Support Guide Page TOC 3 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Table of Contents HL7 Implementation Support G
575. transmitting all or selected transaction fields as required by the receiving system 18 Reordering and enhancing data elements as necessary for processing by the receiving system 19 Communication Protocol Translation 20 List the protocols translations that are provided with your AIE 21 Describe your communication protocol facilities and your method for conversion Are any third party or additional hardware or software components required Does configuration involve any type of programming What implementation tools are provided F 1 7 3 Transaction Routing The primary function of the transaction routing feature is to send transactions from one application system to a receiving application system The router has the network transport protocol necessary to make the connection to the receiving system and can dynamically change paths to a receiving system Describe in detail how and in what module your system provides each of the following capabilities and facilities 1 Source and Destination Routing The router should be able to pass transactions on to a single destination and multiple destinations depending on transaction type Alternate routing functions should be available in the event of system or network failure a Explain the router function b Explain recovery methods when AIE failures occur c Describe features available to monitor such failures 2 Routing Variables Identity whether transactions can be routed to desti
576. ts Tables Message added AL1 and notation corrected Message added ERR message message message message response to query response to query response to query response to query response to query Dietary orders suplements Segment ODT Segment RQI segment segment RXO Pharmacy Prescription segment Pharmacy Route ox segment Health Level Seven Implementation Support Guide Page 4 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 4 HL7 Version 2 2 Overview RXC_ Pharmacy Component x segment y O RXE Pharmacy Encoded order x segment O X segment RXG_ k PharmacyGive_____ x segment A segment RX1 Segment DELETED Segment DELETED Deleted values C N New values New values Substitution Status x 4 3 3 2 Data Elements Segment Seq ORC 1 Datatype changed from ST to ID ORC 2 Changed from Optional to Conditional ORC 3 Changed from Optional to Conditional ORC 5 Datatype changed from ST to ID ORC 6 Datatype changed from ST to ID ORC 7 Datatype changed from CM to TQ ORC 9 Length changed from 19 to 26 ORC 15 ORC 16 ORC 17 ORC 18 ORC 19 OBR 2 Optional changed to conditional OBR 3 Filler order number x Optional changed to conditional OBR 5 Priority X Datatype changed from ST to ID OBR 6 Requested Date Time x Lengthchangedfrom19to26 OBR 7 Length changed from 19 to 26 OBR 8 Obser
577. ts quickly We will only be able to respond quickly to such requests if the requestor provides us with clear information about the new terms as detailed in the first part of Table 19 which defines the content that we need to determine whether a submitted code requires a new LOINC code assignment or not Before sending a request make sure that you have at a minimum provided information about items 1 through 7 and 8 if applicable It is also very important to us to know the units and when possible a sample value of the test observation that is being requested We cannot guarantee a response for requests that do not include items 11 and 12 This information enables us to verify the property precision and method Please note that we tend to avoid the use of methods for chemistry tests We will not routinely accept requests for method specific chemistry tests Only in very special circumstance will we distinguish among analytic methods in chemistry We do distinguish microbiology serology and coagulation tests by method type Even here however we do not distinguish every variation in methods Look in the body of this guide for information about the kinds of distinctions we make When you find a test in the data base that you believe is wrong please send us a letter or email calling attention to the concept and the reason it is wrong e g we are not using the standard nomenclature a typographical error has occurred the name carries some int
578. ts this mode of processing Initiating System Processing After sending the initial message the initiating system awaits the response step 5 page C 4 The program must receive characters and form them into lt CR gt terminated lines When a complete block header the portion from the Start Block character to the first lt CR gt has been received and it is determined that the reply is not a negative acknowledge the data lines that follow can be sent directly to the encoding rules as they are received Before the line is sent to the encoding rules however the character before the lt CR gt must be checked to see if it is an End Block character If it is this line is the block trailer and should not be passed to the higher level The block should be verified at this time If an error is detected notification should be passed through the encoding tules to the application C 2 5 2 Responding System Processing Page C 6 When the encoding rules have provided the first segment of the reply a block header the portion from the Start Block character to the first lt CR gt and the partial reply can be sent The remaining characters of the message are sent as the encoding rules module provides them Once the entire message has been created and sent a block trailer can be constructed and sent This may require the application to keep a running character count and checksum Health Level Seven Implementation Support Guide Final Version 6 98 fo
579. ttsia SPP Spotted fever group or Rickettsia SPP Typhus group When the test measures an antigen to a specific species of organism but cross reactivity is such that other organisms are identified the name should be the principal organism which is targeted by the test 2 1 2 5 Avoid direct and indirect except as parts of synonym names Avoid conjugated and unconjugated when a more precise term is available For instance use bilirubin glucuronide instead of bilirubin conjugated Bilirubin conjugated becomes the synonym 2 1 2 6 Use platelets not thrombocytes 2 1 2 7 Name vitamins by their chemical name E g use thiamin not Vitamin B1 The name containing Vitamin will be included as a synonym This is the only reasonable approach because all vitamins have a chemical name but not all vitamins have a numbered vitamin name 2 1 2 8 Always specify whether serology tests measure the antigen or antibody using the abbreviation AB for antibody and AG for antigen Remove the anti from ANTI X AB It is redundant and obscures the most significant word in the name Thus anti smooth muscle AB becomes Smooth muscle AB Page H 14 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Table 2 Allowable Abbreviations in Component analyte Names Abbreviation Full Name AB antibody AG Antigen AGGL Agglu
580. ty Regenstrief University of Utah Association of Regional and University Pathologists ARUP Mayo Medical Laboratories LDS Hospital in Salt Lake City the Department of Veterans Affairs Quest Diagnostics and University of Washington This has been an empirical effort Our goal is to provide codes to which laboratories and clinical departments could map to their master files In the United States PO an abbreviation for per ora is used to identify medications taken by mouth Health Level Seven Implementation Support Guide Page H 5 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC The database includes fields for each of the six parts of the name In addition it may also contain EUCLIDES codes for the component analytic part of the name IUPAC IFCC codes and ASTM codes as well as related words synonyms and comments Related words synonyms are included to facilitate searches for individual laboratory test and clinical Observation results Laboratories and managers of medical records systems should record the LOINC codes as attributes of their existing test observation master files and use the LOINC codes and names in the OBSERVATION ID field OBX 3 of the ASTM and HL7 OBX segment and the corresponding CEN TC251 and DICOM messages to identify laboratory results The print version of the LOINC database is presented to you as an electronic document grouped by sensible cate
581. u do not sell the hardware on which the proposed software will execute describe the process by which you will warrant the operation and performance of your software on the proposed hardware platform c Will your company warrant your software if the hardware is purchased directly from the hardware vendor F 1 6 3 System Support and Maintenance 1 Contract Health Level Seven Implementation Support Guide Page F 17 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates a Please provide a copy of your standard hardware and software maintenance support contract b Describe how you contract for ongoing software maintenance and support c How soon after the release of a new operating system will you guarantee delivery and installation d If you modify your operating system how long will it take you to incorporate these modifications into previous releases e IfSt Anybodys Medical Center delays or declines to install a new release how will this affect our support agreement f Dothe proposed costs of your system include future enhancements and developments If not describe the conditions and terms under which enhancements and new releases are available to current users of your system g Doyouactas a single point of contact for all hardware and software h Whatis the average response time to call for software support that your company is prepared to guarantee i
582. u will often be an email asking some clarifying questions We will refer to your submissions by the row number of the submitted file first concept is row 1 second is row 2 etc We would prefer to clear up the general intent of the file via an email dialogue before proposing LOINC codes for your submissions Please respond to the email by inserting your answers below the questions in a response email We will return the output in a file with all of the fields you submitted plus a number of fields that we will add it as part of our internal review process We will also add fields that identify the LOINC code and formal LOINC name when we are able to map your term to a LOINC concept These will include an action code explaining whether we mapped your term to a pre existing LOINC code or made up a new one to accommodate it We also indicate in both cases whether we had to change your term to make it fit our rules please check these closely to be sure that we did not misunderstand your proposal We also will point out internal contradictions in the naming and show close matches these help us decide whether your term is formatted correctly for the subject matter Page H 48 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 Table 20a Access Field Names for Submissions Row Field Name Data Type Size Description Bytes 1 S_R
583. ublic use set of codes and names for electronic reporting of clinical laboratory test results Clinical Chemistry 1996 42 81 90 McDonald CJ Park BH Blevins L Grocers physicians and electronic data processing AMA Continuing Medical Education Newsletter 1983 12 1 5 8 International Union of Pure and Applied Chemistry International Federation of Clinical Chemistry The Silver Book Compendium of terminology and nomenclature of properties in clinical laboratory sciences Oxford Blackwell Scientific Publishers 1995 x Henry JB Clinical Diagnosis and Management by Laboratory Methods Philadelphia W B Saunders 1991 Burtis CA Ashwood ER Tietz Textbook of Clinical Chemistry 2nd ed Philadelphia W B Saunders 1994 McDonald CJ Tierney WM Computer stored medical records JAMA 1988 259 3433 40 Dick AS Steen EB eds The computer based patient record Washington DC National Academy Press 1991 5Health Level Seven An application protocol for electronic data exchange in healthcare environments Version 2 3 Ann Arbor MI Health Level Seven Inc 1997 ASTM E1238 94 Standard Specification for Transferring Clinical Observations Between Independent Computer Systems Philadelphia American Society for Testing Materials 1994 10 American College of Pathology Systematized Nomenclature of Medicine SNOMED 2nd edition Skokie IL ACP 1984 Euclides Foundation International EUCLIDES Laboratory Investigation Cod
584. uide 3 4 8 Develop Implementation And Testing Approach 3 5 3 4 8 1 Define The Testing Methodologie 3 5 2415 2 Defme Test Ados E 3 5 JAS Testing Software Aides oniinn da te ad See tu unde alee enda coda uius 3 5 3484 Testing ENVIO ME iris 3 5 BAD Ke E 3 6 34 91 Testing Te 3 6 349 KE omni EG 3 6 DADS Expected Results nc rero diia 3 6 S494 Testing Worksheet EE 3 6 3 4 10 Finalize Migration Approach a tt 3 6 3 4 11 Finalize User Access Security CEA ee eege 3 6 3 4 12 Conduct Review And Obtain Acceptance For Technical Design 3 6 3 4 13 Conduct Review And Obtain Acceptance For Functional Performance 3 6 oo PROGRAM DEVBELOPMEN H EE 3 7 A eege eege 3 7 5 6 IMPLEMENTA TION ries ruere o Rea PER AR YES E P ERI NUES E ENRR NAT ART VUE r nU Para A 3 7 Sr Site Preparatoria 3 7 SOAS LSU EE 3 7 SOD O e E E A A 3 7 3 6 2 Select Install Lower Level Protocol 3 7 3 6 3 Select Install Hardware seele ica idad sir tad age ed ee oes 3 8 04 EE EE EE 3 8 3 6 5 Network Communication Testing aii 3 8 3 6 6 Policies Procedures usaste lada 3 8 SCDE 3 Deyelop PON TT 3 8 3 6 6 2 Develop Operating Pr odds 3 8 300 3 ds NS 3 9 36 7 Conduct TrM gue ee ENEE 3 9 CET EM Bd E 3 9 3 00 7 2 Support Stafi TET 3 10 3 0 0 GoLive Planini h eaan Reo Uc ee psc 3 11 3 6 8 1 Finalize Support Staffing Plan sss eee ee eee eee eee 3 11 3 0 8 2 Conversion Preparation ET 3 11 0 0 KEE 3
585. uired to implement Category II interfaces DESCRIPTION OF MODIFICATION ESTIMATED COMPLETION PERFORMED BY COST MAN HOURS TIMEFRAME NOTES EE EN RE EE BE E EE A TOTAL PROPOSED COST OF MODIFICATIONS FOR CATEGORY II INTERFACES Interface Category III Include all modifications required to implement Category III interfaces DESCRIPTION OF MODIFICATION ESTIMATED COMPLETION PERFORMED BY COST MAN HOURS TIMEFRAME NOTES TOTAL PROPOSED COST OF MODIFICATIONS FOR CATEGORY III INTERFACES Page F 49 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates F 1 9 5 Support and Implementation Staff Roles and Responsibilities Describe the roles and responsibilities of the individuals from St Anybodys Medical Center who will be required to participate in the implementation and support of the AIE A few positions have been provided as a strawman POSITION DESCRIPTION COMMENTS Interface Analysts Implement the interface using the AIE EE Operators Monitor the operation of the AIE Take first level corrective action Identify the cause of the problem and escalate to the proper analyst AIE Administrator Performs daily administrative functions on the AIE REUS Page F 50 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sampl
586. ule Common Order Observation Battery R Observation Results Common Order Pharmacy Administration Pharmacy Route Health Level Seven Implementation Support Guide Page A 55 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist A 4 5 13 C11 Patient Completes a Phase of Clinical Trail CSU Originator A or B Message Header R Patient Identification R Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Clinical Study Registration R Clinical Study Phase Clinical Study Data Schedule Common Order Observation Battery R Observation Results Common Order Pharmacy Administration Pharmacy Route A 4 5 14 C12 Update Correction of Patient Order Result Information CSU Originator A or B Message Header R Patient Identification R Additional Demographics Notes and Comments Patient Visit Patient Visit Additional Info Clinical Study Registration R Clinical Study Phase Clinical Study Data Schedule Common Order Observation Battery R Observation Results Common Order Pharmacy Administration Pharmacy Route Page A 56 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 5 15 Message Header Event Type Patient Identification Additional Demographics Notes and Comments Patient Visit
587. um data values Numeric array For waveform data only see Chapter 7 Section 7 15 1 value1 NM gt value2 NM value3 NM gt value4 NM gt Encapsulated Supports ASCII MIME data encoding of binary data source application HD gt main type of data ID gt data subtype ID gt encoding ID data ST gt MA Multiplexed array For waveform data only see Chapter 7 Section 7 15 2 sample 1 from channel 1 NM sample 1 from channel 2 NM gt sample 1 from channel 3 NM gt sample 2 from channel 1 NM sample 2 from channel 2 NM gt sample 2 from channel 3 NM gt Health Level Seven Implementation Support Guide Page A 7 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist Price data CP Composite price In Version 2 3 replaces the MO data type price MO price type ID gt from value NM to value NM range units CE gt range type ID gt Patient Administration Financial Information FC Financial class financial class ID effective date TS gt Extended Queries QSC Master Files Query selection criteria Query input parameter list Row column definition Driver s license number Visiting hours Job code class name of field ST gt relational operator ID gt value ST gt
588. universal codes and names The names we create correspond most closely to the long test descriptions seen in test master files We want to create fully specified names That is if a person wanted to map her local test dictionary to the LOINC codes all information needed to map a local test name to one of the fully specified names should be present in the LOINC name This means that the names created will usually be longer than those used in lab reports today The fully specified LOINC name is not meant to be used on clinical reports It is assumed that shorter more convenient abbreviated names and synonyms will be created and maintained by the local computer system We have had many requests to create standardized short names that could serve as reportable names and will consider defining such names as a future project We want to achieve a level of detail in the definition of a test that will map one to one to the separately reported observations on a clinical laboratory report If a test has its own column on a clinical report or has a reference range that is different from other tests or has clinical significance distinct from other closely related tests it will usually be assigned a separate name We deliver these fully specified names their codes and their related names as a database in which each line corresponds to a unique type of test 1 1 Successes The LOINC codes have been greeted enthusiastically since they were released to the
589. ur dictionary If they do not we will not The extent to which we include methods as part of the name is also guided by pragmatics We distinguish tests observations by the method used to produce the results only if the method has a significant effect on the interpretation Health Level Seven Implementation Support Guide Page H 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC of the result This is a complex subject and it is difficult to fully describe our rationale in this report Where laboratories do not tend to include the method in the name e g most of chemistry we do not include the method in the name Where they tend to e g in immunochemistry we do For some tests this can be justified by the standardization of methods to produce equivalent results and sometimes by the many variables method reagent that one could never hope to represent fully in a single name However even when we do distinguish these cases we distinguish by method class not the most detailed possible method distinction See section 2 7 for more details The College of American Pathologists produces statistical summaries of the results for measurements of standard samples broken down by laboratory and by instrument or procedure These are called CAP surveys We explored the feasibility of using this CAP survey data to decide empirically when test names should be distinguished by method T
590. urance plan ID X Length changed from 8 to 60 data type changed from ID to CE FT1 15 Insurance amount X _ Data type changed from CM to CP FT1 16 Assigned patient location X Length changed from 12 to 80 data type changed from NM to PL FT1 17 Fee schedule X Data type changed from ID to IS Page 5 20 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1997 All rights reserved Chapter 5 HL7 Version 2 3 Overview Segment Seq FT I 18 Data type changed from ID to IS FT1 19 Length changed from 8 to 60 FT1 20 Performed by code Length changed from 60 to 120 data rr FT1 21 Ordered by code X Length changed from 60 to 120 data LL T Ne Ken FT1 22 FT1 23 Filler order number X Length changed from 75 to 22 data FT1 24 AAA FT1 25 Se il diagnosis to Set ID DO pes Pawo E changed from ID to CE DG1 4 Diagnosis description O x O Optionality changed from O to B Diagnosis type X Data type changed from ID to IS element name changed from Diagnosis DRG Type to Diagnosis Type DG1 7 Major diagnostic category Za x O Optionality changed from O to B Diagnostic related group X Length changed from 4 to 60 data type changed from ID to CE optionality NUN changed from O to B DGI 9 DRGapprovalindicatr X Optionality changed fromOtoB DG1 10 DRG grouper review code X Data Type changed from ID to IS S meh E DGI l1 Outlier type X _
591. ure Queues and Associated Managers 9 2 7 Update Clinical Data Repository DB Tables 9 2 7 1 Update Procedure Directories with Lab Services 9 2 7 2 Update Locations 9 2 7 3 Update Clinicians 9 2 7 4 Update Other 9 2 8 Migrate Lab Interface from Development to Test Environment 9 2 9 Develop LAB Transaction Test Plan 9 2 10 Unit Test Interfaces 9 2 10 1 Test Communications 9 2 10 2 Test Transactions 10 TESTING 10 1 Develop Test Interface Scenarios 10 1 1 Develop ADT Scenarios 10 1 2 Develop LAB Status Result Scenarios 10 1 3 Develop LAB Orders Scenarios In and Out 10 1 4 Include Interface Scenarios in Integration Test Plan 10 2 Integration System Test 10 2 1 Develop Integration Test Plan 10 2 2 Obtain Integration Test Plan Signoff 10 2 3 Conduct Integration Test 10 2 4 Document Problems Resolution 10 2 5 Obtain Integration Test Results Signoff Health Level Seven Implementation Support Guide Page F 75 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates 10 3 Performance Stress Testing 10 3 1 Develop Performance Stress Test Plan 10 3 2 Obtain Performance Stress Test Plan Signoff 10 3 3 Conduct Performance Stress Test 10 3 4 Document Problems Resolution 10 3 5 Obtain Problem Resolution Signoff 10 3 6 Obtain Performance Stress Test Resolution Signoff 11 POLICIES AND PROCEDURES 11 1 Develop IS Operational Procedures 11 1 1 Develop File Maintenance Procedu
592. us in terms of existing applications hardware communications and growth potential 2 4 1 2 Identify Functional Information Requirements Identify and document the information needs of each functional area considering system replacement acquisition Also identify understand and evaluate the extent to which these needs are being satisfied by the current systems Consider future business and technology plans as well as any simplified work flows and policies procedures when identifying information needs 2 4 2 Current Status Assessment Technical Architecture 2 4 2 1 Identify Transaction Volume Capacity Research and document both current and projected transaction and data volumes Following this review and assess the current hardware and communications capacities in light of the information needs identified 2 4 3 Application And Technology Requirements 2 4 3 1 Identify Application Information Requirements Group information needs into various applications in order to identify the types of systems and potential options available 2 4 3 2 Identify Application Technology Use Identify and document the needs for any specific technologies and map each required technology to the various applications Page 2 4 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 2 Planning Methodology 2 4 3 3 Assess Staff A current assessment of the available personne
593. usiness Strategy and Performance Measures Health Level Seven Implementation Support Guide Page 2 1 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Chapter 2 Planning Methodology Information Needs and Application Requirements Technical Architecture Organization Strategy C D E F Migration Strategy G Cost Benefit Analysis H Vendor Evaluation and Selection Additional information regarding systems planning considerations as well as the pros and cons of both networked and traditional point to point environments is available in many of the health care technology publications as well as through health care information consulting firms These references should be considered in conjunction with the HL7 methodology when conducting a systems planning evaluation project 2 2 PLANNING AND ORGANIZATION The purpose of this section is to ensure that an overall work program has been developed which defines the activities to be completed the overall project time frame and resource requirements These activities are also intended to ensure that executive management understands and supports the project 2 2 1 Project Organization 2 2 1 1 Define Scope Of Project Communicate the intended project scope and approach to senior management and obtain their approval for the project 2 2 1 2 Determine Resource Requirements Identify the personnel skill and experience requirements for the project Identify and arr
594. vation End Length changed from 19 to 26 Date Time OBR 11 X Datatype changed fr4om ST to ID OBR 12 Danger Code X Datatype changed from CM to CE OBR 14 Specimen received D Length changed from 19 to 26 date time Changed from Required to Conditional gt OBR 16 x Length changed from 60 to 80 OBR 22 Results Rpt Status Chng X Length changed fr4om 19 to 26 Changed from Required to Conditional OBR 26 X Datatype changed from CE to CM OBR 27 Quantity Timing X Datatype changed from CM to TQ OBR 28 Result copies to LL x Length changed from 80 to 150 Page 4 12 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Chapter 4 HL7 Version 2 2 Overview Segment Seq OBR 32 Principal Result Interpreter OBR 33 Assistant Result Interpreter OBR 34 Technician OBR 35 OBR 36 Scheduled Date Time 4 3 4 Chapter 5 Query Datatype changed from CN to CM Datatype changed from CN to CM Datatype changed from CN to CM Datatype changed from CN to CM X X X X Length changed from 19 to 26 All contents of chapter 5 were moved to chapter 2 4 3 5 Chapter 6 Finance 4 3 5 1 Messages Segments Tables Msg Segment BAR Add amp Purge Patient JI Se DFT Post detail financial e NM IN Insurance additional info ee eee Mail claim party 4 3 5 2 umm X X Data Elements W PRI 5 Procedure date time IN1 7 IN1 30 Verificati
595. ve Joachim Dudeck M D Institute for Medical Information Phone 49 64 1702 4500 Fax 49 64 1787 88 Email jwd uni giessen de International Affiliate Contacts HL7 Australia Meno Schilling Standards Australia Phone 61 02 391 9764 Fax 61 02 391 9762 Email mschiCdoh health nsw gov au HL7 Canada Laura Sato Canadian Institute for Health Information Phone 416 429 0464 Fax 416 429 1953 Email jzelmer cihi ca HL 7 Finland Niilo Saranummi VTT Information Technology Phone 358 3 316 3300 Fax 358 3 317 4102 Email niilo saranummi O vit fi Page 1 12 Final Version 6 98 Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Chapier 1 Introduction HL7 Germany Joachim Dudeck M D Institute for Medical Information Phone 49 64 1702 4500 Fax 49 64 1787 88 Email jwd uni giessen de HL7 Japan Michio Kimura Hamamatsu University Medical School Phone 81 53 435 2770 Fax 81 53 435 2769 Email HL7 The Netherlands Bert Kabbes Kabbes amp Partners Healthcare Management Consultants Phone 31 318 553812 Fax 31 318 510655 HL7 New Zealand Brian A Say Chair HL7 New Zealand Phone 64 7 856 0366 Fax 64 7 856 0366 Email briansay wave co nz HL7 TECHNICAL COMMITTEES CONTROL QUERY COMMITTEE Mark Shafarman Oacis Healthcare Systems Inc Ph 415 925 4570 Fax 415 925 4455 Email mshafarmCoacis com Larry
596. ve evaluation whose value comes from a finite set of unranked independent coded items the property will be PRID TYPE and precision NOM For extensive measures whose value comes from a finite set of unranked coded items the property will be the extensive property and the precision will be NOM Intensive Properties Possible Values coded Property Precision Organism Identified E coli S aureus etc PRID NOM ABO Group A B AB O PRID NOM Surgery Dis Summary Cholecystectomy PRID NOM Appendectomy Extensive Properties Possible Values coded Property Precision Urine Color Amber straw etc COLOR NOM Urine Turbidity Hazy cloudy opaque TURBIDITY NOM 10 For any intensive evaluation whose value comes from a finite set of unranked free text items or a paragraph the property will be PRID FIND or ATTRIBUTE and precision NAR to indicate that the result is free text narrative For extensive measures whose value comes from a finite set of unranked text items or a paragraph the property will be the extensive property and the precision will be NAR Intensive Properties Possible Values text Property Precision Organism Identified E coli S aureus etc PRID NAR ABO Group A B AB o PRID NAR Surgery Dis Summary Cholecystectomy Appendectomy PRID NAR Extensive Properties Possible Values text Property Precision Urine Color Amber straw etc COLOR NAR Urine Turbidity Hazy cloudy opaque TURBIDITY NAR 11 IMP is used to represent
597. ven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved LOINC Users Guide April 16 1998 source SNOMED is an appropriate source for these organism names codes may be used as the standard The names for the result identifiers will be created using the same strategy as for other identifiers but with particular emphasis on the method While Throat Culture is the source of the culture inoculum it is also a label that indicates what kind of media was inoculated and the other techniques used in the laboratory So it is a short hand for a kind of method and such will be recorded as the method part of the name Thus Throat Culture and Blood Culture and Clostridium difficile Culture all represent labels for how a culture was performed Examples of names of culture results are MICROORGANISM IDENTIFIED PRID PT BLD NOM BLOOD CULTURE MICROORGANISM IDENTIFIED PRID PT BRN NOM DIRECT BURN CULTURE MICROORGANISM IDENTIFIED PRID PT STL NOM STOOL CULTURE Names of methods of staining directly on a sample material where many descriptive observations are possible MICROSCOPIC OBSERVATION PRID PT XXX NOM GRAM STAIN MICROSCOPIC OBSERVATION PRID PT XXX NOM ACID FAST STAIN KINYOUN MICROSCOPIC OBSERVATION PRID PT XXX NOM DRY MOUNT MICROSCOPIC OBSERV ATION PRID PT XXX NOM INDIA INK PREPARATION MICROSCOPIC OBSERVATION PRID PT XXX NOM TRICHROME STAIN MICROSCOPIC OBSERVATION PRID PT XXX NOM GIEMSA S
598. view this with senior management prior to finalizing vendor contracts and initiating design installation projects 2 9 VENDOR EVALUATION AND SELECTION The purpose of this section is to identify the considerations associated with developing evaluation criteria to issue to potential systems and technology vendors as well as considerations associated with evaluating and selecting various vendors While you may begin preliminary discussions with interface engine vendors prior to selection of your application vendor s the majority of your interface engine evaluation should take place following the selection of your application vendor s This will enable you to directly address solutions to your specific integration issues 2 9 1 Evaluation Criteria Develop evaluation criteria that describe the functional and technical requirements of the desired system s The evaluation criteria should include the following e A description of the current and planned technical environments of the hospital e A list of the specific interfaces required specifically requesting that the vendors utilize the HL7 standard for interfaces addressed by the standard e Requests for the vendors to indicate specific pricing for each of the HL7 interfaces and the scope of work included at that pricing e g programming testing training e Aclear definition of the responsibilities of the vendors Health Level Seven Implementation Support Guide Page 2 9 for HL7 S
599. well as the future interfaces described in Section IV C The future interfaces will certainly not be limited to those identified in this document Rather we estimate that the number of interfaces could increase by 100 200 percent over the useful life of the AIE with an attendant but unknown increase in interface traffic All interfaces will be routed through the AIE While the initial focus will be to migrate existing point to point interfaces to the AIE new interfaces will Health Level Seven Implementation Support Guide Page F 9 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix F Sample Templates probably be implemented concurrently The matrices included in this section divide existing interfaces into three development categories These categories are described and itemized in Section V B The last category includes specifics on anticipated near term interfaces Please note that inclusion in a particular category does not imply any temporal relationship with the possible exception of Category I While St Anybodys Medical Center is open to most hardware operating systems platforms it does have preferences For specifics regarding existing interfaces to be transferred to the AIE please refer to Section IV C F 1 5 2 Development Plan Applications will be phased into the AIE not necessarily in order by their categories However Category I interfaces have been targeted for installation early in the l
600. whether circumference or diameter or radius when length is the property and the specific level and axis on which a measure of a body part is taken e g circumference taken at the nipple line The component should remove all ambiguity as to what projection or axis or specific subtime frame is being measured So if one is measuring the diameter of the kidney the system would have to specify the kidney right or kidney left and the component would identify the axis and level at which the diameter was measured e g crossectional at level of pelvis For a measure of chest circumference the system chest the property circumference at nipple line and the property length Areas lengths and volumes of organs all have to be specified enough in the component to distinguish a particular area or length that is being measured When a measure changes over some cycle e g inspiration expiration diastole systole then that should also be specified in the component Duration is used to identify the duration of an over all study Health Level Seven Implementation Support Guide Page H 37 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix H LOINC Table 17 Subjects covered to date in clinical LOINC Blood pressure systolic diastolic and mean Heart rate and character of the pulse wave Respiratory rate Critical care measures Cardiac output resistance stroke work ejection fraction etc Bo
601. xcerpt from Chapter 1 of the HL7 Version 2 3 Standard 1 6 1 ANSI Standards ANSI X3 30 ANSI X3 4 ANSI X3 43 ANSI X3 50 ANSI X3 51 1 6 2 ISO Standards ISO 5218 ISO 1000 ISO 2955 ISO 8072 ISO 8601 ISO 8859 ISO 8859 1 ISO 8859 2 ISO 8859 3 ISO 8859 4 ISO 8859 5 ISO 8859 6 ISO 8859 7 ISO 8859 8 ISO 8859 9 JAS2020 JIS X 0202 1985 Representation for calendar date and ordinal date 1986 Coded character sets American National Standard code for information interchange 7 bit ASCII 1986 Information systems representation of local time of day for information interchange 1986 Representations for U S customary SI and other units to be used in systems with limited character sets 1986 Representations of universal time local time differentials and United States time zone references for information interchange 1977 Information Interchange Representation of Human Sexes 1981 SI Units and Recommendations for the use of their multiples and of certain other units 1983 Information processing Representation of SI and other units in systems with limited character sets 1986 Network Standards 1988 Data elements and interchange formats information interchange representation of dates and times 1988 Information Processing 8 bit single byte coded graphic character sets 1988 Information Processing Latin Alphabet No 1 1988 Information Processing Latin Alphabet No 2 1988 Information Processing Latin Alphabet No 3
602. y Treatment Route Pharmacy Treatment Component Continuation Pointer A 4 3 23 RGR Pharmacy Treatment Dose Information RGR Originator A or B Message Header Message Acknowledgment Error Query Definition Query Filter Patient Identification Notes and Comments Common Order Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component Pharmacy Treatment Give Pharmacy Treatment Route Pharmacy Treatment Component Continuation Pointer Page A 46 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix A HL7 Transaction Checklist A 4 8 24 RER Pharmacy Treatment Encoded Order Information RER Originator A or B Message Header Message Acknowledgment Error Query Definition Query Filter Patient Identification Notes and Comments Common Order Pharmacy Treatment Encoded Order Pharmacy Treatment Route Pharmacy Treatment Component Pharmacy Treatment Give Pharmacy Treatment Route Pharmacy Treatment Component Continuation Pointer A 4 8 25 V01 Query for Vaccination Record VXQ Originator A or B A 4 3 26 V02 Response to Vaccination Query Returning Multiple PID Matches VXX Originator A or B Message Header Message Acknowledgment Query Definition Query Filter Patient Identification Next of Kin Associated Parties Health Level Seven Implementation Support Guide Page A 4
603. y Update Message UDM Originator A or B Message Header Results Update Definition Results Update Selection Criteria Display Data Continuation Pointer A 4 2 Admission Discharge and Transfer Messages A 4 2 1 A01 Admit a Patient ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Next of Kin Patient Visit Patient Visit Additional Info Disability Information Health Information Allergy Information Diagnosis Information Procedures Role Guarantor Information Insurance Information Health Level Seven Implementation Support Guide Page A 11 for HL7 Standard Version 2 3 1998 All rights reserved Final Version 6 98 Appendix A HL7 Transaction Checklist Insurance Information Adal Info Insurance Information Cert Accident Information Universal Bill Information Universal Bill 92 Information A 4 2 2 A02 Transfer a Patient ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Health Information A 4 2 3 A03 Discharge a Patient ADT Originator A or B Message Header Event Type Patient Identification Additional Demographics Patient Visit Patient Visit Additional Info Disability Information Diagnosis Information Diagnosis Related Group Procedures Role Health Information Page A 12 Health
604. y were reported electronically using the LOINC codes The LOINC codes and names for test observations should be of interest to hospitals clinical laboratories doctors offices state health departments governmental health care providers third party payers and organizations responsible for quality assurance and utilization review The LOINC codes are not intended to transmit all possible information about a test or observation They are only intended to identify the test result or clinical observation Other fields in the message can transmit the identity of the source laboratory and very detailed information about the sample For instance the result code may identify a blood culture but the message source code can be more specific and identify the sample as pump blood The level of detail in the LOINC definitions was intended to distinguish tests that are usually distinguished as separate test results within the master file of existing laboratory systems Indeed we used the master files from seven U S laboratories to shape this effort Each LOINC record corresponds to a single test result A current project is to invent names and codes for batteries of tests such as electrolytes The record includes fields for specifying 1 Component analyte e g potassium hemoglobin hepatitis C antigen 2 Property measured e g a mass concentration enzyme activity catalytic rate 3 Timing i e whether the measurement is an observa
605. you recommending for the recommended platform 3 ls this a multi processing multi tasking operating system Page F 34 Health Level Seven Implementation Support Guide Final Version 6 98 for HL7 Standard Version 2 3 1998 All rights reserved Appendix F Sample Templates 4 What other operating systems does the AIE operate under 5 Describe data integrity and error detection correction features of the recommended operating system 6 Does the AIE application have any hooks into the operating system If so please list the hooks and the OS process they interact with 7 What are the performance benchmarks for the recommended OS 8 Describe the fault tolerant features of the recommended operating system 9 Describe the security maintenance features of the recommended operating system 10 Describe operating system management GUL if available F 1 8 5 Performance Integrity Performance and integrity are critical elements in providing service to the user Because the AIE will be providing services that are critical to the institution it must have high performance while maintaining the utmost integrity at the transaction data and security levels 1 Describe what attributes you deem important for performance and integrity when implementing the AIE product 2 What are the overall performance benchmarks for the recommended system 3 What type of growth factor was built into the recommended systems 4 How is data in
606. ystem To receive the block that contains the response a Ifacompletely delimited block is not received before the receive timeout as specified in the NPT resend the original block If the number of timeout retries specified in the NPT has been exceeded then return to the encoding rules module with a timeout error b Ignore all incoming characters until a Start Block character is received Any time another Start Block character is received before the end of a block ignore all previous characters Receive characters until EB CR is recognized This is the end of the block c Ifa block is received that does not have the proper 1 Block Format 2 Checksum xxx 3 Block Size ccccc or 4 Has too many characters to be received in a single block resend the original block or return an indication of the error to the encoding rule module depending on the number of send retries and the type of error d Ifthe block is acceptable and has block type N it is a negative acknowledgment Resend the original block as many times as is specified in the NPT or return to the application with an indication of the error e Ifthe block is acceptable and has block type D itis the response Go to the next step f Ifthe initiating system detects an error in the data block from the responding system it has the option of retransmitting the original data block The decision of whether to Health Level Seven Implementation Support Guide Fi
607. yte component if LOINC number assigned Formal LOINC name for kind of property if LOINC number assigned Formal LOINC name for time aspect if LOINC number assigned Formal LOINC name for system sample type if LOINC number assigned Formal LOINC name for type of scale if LOINC number assigned Formal LOINC name for type of method if LOINC number assigned Formal LOINC name for class if LOINC number assigned 34 STATUS TEXT 20 Regenstrief s Status for submitted term 3 ID TEXT 50 Regenstrief s internal assigned ID for the submitter s file Internal path and file name information 36 COMMENT TEXT 250 Regenstrief s automated comments about the submitted term These identify internalcontraditions automated equivalencing e g serum to SER plas 37 UNIQ TEXT 150 This lists any words in a concept that are new to the LOINC data base These may indicate typo s mis statements of words or new words in the concepts 38 DUPS TEXT 150 These are lists of subsets or near matches for submitted terms These are produced only to assist the submission review process and should not be given too much credence 38 EDIT_CTL TEXT 10 Regenstrief s Edit Control Making a Submission Health Level Seven Implementation Support Guide for HL7 Standard Version 2 3 1998 All rights reserved Page H 49 Final Version 6 98 Appendix H LOINC Tables 1a and 1b describe a submission that is in the form of a Microsoft Access database If you send an Access data

Download Pdf Manuals

Related Search

Related Contents

取扱説明書 - シーアンドシー  -- (公財)沖縄 - 沖縄県中小建設業協会  86885 ES Aldi ES Content final 5004 4635.indd  Pelco DX8000 Installation  AT-6130 取扱説明書(PDF/3.4MB)  Entretien du linge 2  Samsung RS21DASM Bruksanvisning  SET MODE  

Copyright © All rights reserved. Failed to retrieve file