ࡱ> *   k a c q LJGEC7 8bjbjUU 7|7|vxl((((h,j,,-f}f}f}(~rD&-^ |¨X:T(|(p)7 PF H H H A e A $  e ]D,$# */M i e )) Ty B)ZD,F # F N 'Z+D,ҟ  U-Of}By ҟ t5 H^ Ɔ  C ҟ --))))January 2002 Minutes Orders/Observations Worksession Table of Contents  TOC \o "1-2" \h \z  HYPERLINK \l "_Toc842947" Table of Contents  PAGEREF _Toc842947 \h 1  HYPERLINK \l "_Toc842948" Attendees  PAGEREF _Toc842948 \h 3  HYPERLINK \l "_Toc842949" Monday - Version 2.x Review  PAGEREF _Toc842949 \h 4  HYPERLINK \l "_Toc842950" Proposal 240 Clarify Reference Range Type  PAGEREF _Toc842950 \h 4  HYPERLINK \l "_Toc842951" Proposal 245 CM Data Type Replacement for OO Part A  PAGEREF _Toc842951 \h 6  HYPERLINK \l "_Toc842952" Proposal 214 CM Data Type Replacement for OO Part B  PAGEREF _Toc842952 \h 19  HYPERLINK \l "_Toc842953" Proposal 241 Move Message Constituent Definitions  PAGEREF _Toc842953 \h 30  HYPERLINK \l "_Toc842954" Proposal 180 Segment Grouping  PAGEREF _Toc842954 \h 32  HYPERLINK \l "_Toc842955" Proposal 198 Resolving the ambiguity of SAC segment occurrence in the OML and ORL messages  PAGEREF _Toc842955 \h 33  HYPERLINK \l "_Toc842956" Proposal 249 Specimen Segment  PAGEREF _Toc842956 \h 36  HYPERLINK \l "_Toc842957" Proposal 190  PAGEREF _Toc842957 \h 65  HYPERLINK \l "_Toc842958" Proposal Blood Bank  PAGEREF _Toc842958 \h 66  HYPERLINK \l "_Toc842959" Tuesday through Thursday - V3  PAGEREF _Toc842959 \h 86  HYPERLINK \l "_Toc842960" Thursday PM Joint with Clinical Trials SIG  PAGEREF _Toc842960 \h 87  HYPERLINK \l "_Toc842961" Friday  PAGEREF _Toc842961 \h 88  HYPERLINK \l "_Toc842962" Proposal 214/245  PAGEREF _Toc842962 \h 88  HYPERLINK \l "_Toc842963" Proposal 241  PAGEREF _Toc842963 \h 88  HYPERLINK \l "_Toc842964" Proposal 181  PAGEREF _Toc842964 \h 89  HYPERLINK \l "_Toc842965" Proposal 190 Inventory Master File for Chapter 8  PAGEREF _Toc842965 \h 92  HYPERLINK \l "_Toc842966" Proposal 189 Inventory Master File Amendment  PAGEREF _Toc842966 \h 98  HYPERLINK \l "_Toc842967" Proposal 246  PAGEREF _Toc842967 \h 99  HYPERLINK \l "_Toc842968" Proposal 248 Add film handling to OBR and IPC  PAGEREF _Toc842968 \h 107  HYPERLINK \l "_Toc842969" Proposal - Point-of-Care Observation messages for Version 2.x for Laboratory and Point-of-Care Domains  PAGEREF _Toc842969 \h 109  HYPERLINK \l "_Toc842970" Proposal Specimen  PAGEREF _Toc842970 \h 113  HYPERLINK \l "_Toc842971" Proposal 249 Specimen Segment Proposal  PAGEREF _Toc842971 \h 113  HYPERLINK \l "_Toc842972" Chapter 13 changes relative to SPM  PAGEREF _Toc842972 \h 113  HYPERLINK \l "_Toc842973" Attachment A: Introduction  PAGEREF _Toc842973 \h 115  HYPERLINK \l "_Toc842974" Attachment B: Pharmacy Domain Introduction  PAGEREF _Toc842974 \h 116  HYPERLINK \l "_Toc842975" Attachment C: Pharmacy DMIM Narratives  PAGEREF _Toc842975 \h 117  HYPERLINK \l "_Toc842976" Pharmacy Substance Administration Order Focal Class  PAGEREF _Toc842976 \h 117  HYPERLINK \l "_Toc842977" Pharmacy Substance Administration Intent Focal Class  PAGEREF _Toc842977 \h 120  HYPERLINK \l "_Toc842978" Pharmacy Substance Administration Focal Class  PAGEREF _Toc842978 \h 123  HYPERLINK \l "_Toc842979" Pharmacy Supply Order Focal Class  PAGEREF _Toc842979 \h 125  HYPERLINK \l "_Toc842980" Pharmacy Supply Event Focal Class  PAGEREF _Toc842980 \h 126  HYPERLINK \l "_Toc842981" Pharmacy Supply Intent Focal Class  PAGEREF _Toc842981 \h 128  HYPERLINK \l "_Toc842982" Attachment D: Pharmacy Storyboards  PAGEREF _Toc842982 \h 131  HYPERLINK \l "_Toc842983" Change Order 24  PAGEREF _Toc842983 \h 131  HYPERLINK \l "_Toc842984" Dispense Event Activate 6  PAGEREF _Toc842984 \h 131  HYPERLINK \l "_Toc842985" Dispense Event Complete  PAGEREF _Toc842985 \h 132  HYPERLINK \l "_Toc842986" Inpatient Pharmacy Story: Using the pharmacy system for clinical monitoring  PAGEREF _Toc842986 \h 133  HYPERLINK \l "_Toc842987" Inpatient Pharmacy Story: patient is discharged from the hospital and transferred to the OP IV Infusion Program  PAGEREF _Toc842987 \h 133  HYPERLINK \l "_Toc842988" A simple story: An outpatient prescription that is filled only one time and is then complete.  PAGEREF _Toc842988 \h 133  HYPERLINK \l "_Toc842989" A little more complicated story: An outpatient prescription that is filled multiple times.  PAGEREF _Toc842989 \h 134  HYPERLINK \l "_Toc842990" Newborn  PAGEREF _Toc842990 \h 135  HYPERLINK \l "_Toc842991" Community Prescription for UK order  PAGEREF _Toc842991 \h 135  HYPERLINK \l "_Toc842992" Inpatient Order Request  PAGEREF _Toc842992 \h 135  HYPERLINK \l "_Toc842993" Inpatient Order Status Change Request  PAGEREF _Toc842993 \h 135  HYPERLINK \l "_Toc842994" Inpatient Order Status Change Request  PAGEREF _Toc842994 \h 136  HYPERLINK \l "_Toc842995" Inpatient Order Status Change Request  PAGEREF _Toc842995 \h 136  HYPERLINK \l "_Toc842996" Inpatient Order Status Change Request  PAGEREF _Toc842996 \h 136  HYPERLINK \l "_Toc842997" Inpatient Order Status Change Request  PAGEREF _Toc842997 \h 137  HYPERLINK \l "_Toc842998" Inpatient Order Status Change Request  PAGEREF _Toc842998 \h 137  HYPERLINK \l "_Toc842999" Inpatient Order Activate order request through pharmacy verification  PAGEREF _Toc842999 \h 137  HYPERLINK \l "_Toc843000" Inpatient verified Order revision request  PAGEREF _Toc843000 \h 138  HYPERLINK \l "_Toc843001" Inpatient verified Order revision accept  PAGEREF _Toc843001 \h 138  HYPERLINK \l "_Toc843002" Community Pharmacy - Prescription nullified  PAGEREF _Toc843002 \h 138  HYPERLINK \l "_Toc843003" Community Pharmacy - Prescription aborted  PAGEREF _Toc843003 \h 138  HYPERLINK \l "_Toc843004" Inpatient Pharmacy - Dispensingsupply requested  PAGEREF _Toc843004 \h 138  HYPERLINK \l "_Toc843005" Inpatient Pharmacy - Dispensingsupply fulfilled  PAGEREF _Toc843005 \h 139  HYPERLINK \l "_Toc843006" Inpatient Pharmacy - Dispensingsupply refused  PAGEREF _Toc843006 \h 139  HYPERLINK \l "_Toc843007" Inpatient Pharmacy - Dispensingsupply Obsolete/New and Revised  PAGEREF _Toc843007 \h 139  HYPERLINK \l "_Toc843008" Inpatient Pharmacy - Dispensingsupply suspended  PAGEREF _Toc843008 \h 140  HYPERLINK \l "_Toc843009" Inpatient Pharmacy - Dispensingsupply resumed  PAGEREF _Toc843009 \h 140  HYPERLINK \l "_Toc843010" Inpatient Pharmacy - Dispensingsupply abort  PAGEREF _Toc843010 \h 140  HYPERLINK \l "_Toc843011" Community Pharmacy - Prescription nullified  PAGEREF _Toc843011 \h 140  HYPERLINK \l "_Toc843012" Community Pharmacy - Prescription aborted  PAGEREF _Toc843012 \h 141  HYPERLINK \l "_Toc843013" Inpatient Pharmacy - Dispensingsupply requested  PAGEREF _Toc843013 \h 141  HYPERLINK \l "_Toc843014" Inpatient Pharmacy - Dispensingsupply fulfilled  PAGEREF _Toc843014 \h 141  HYPERLINK \l "_Toc843015" Inpatient Pharmacy - Dispensingsupply refused  PAGEREF _Toc843015 \h 141  HYPERLINK \l "_Toc843016" Inpatient Pharmacy - Dispensingsupply Obsolete/New and Revised  PAGEREF _Toc843016 \h 141  HYPERLINK \l "_Toc843017" Inpatient Pharmacy - Dispensingsupply suspended  PAGEREF _Toc843017 \h 142  HYPERLINK \l "_Toc843018" Inpatient Pharmacy - Dispensingsupply resumed  PAGEREF _Toc843018 \h 142  HYPERLINK \l "_Toc843019" Inpatient Pharmacy - Dispensingsupply abort  PAGEREF _Toc843019 \h 143  HYPERLINK \l "_Toc843020" Community Pharmacy order with state changes to completion  PAGEREF _Toc843020 \h 143  HYPERLINK \l "_Toc843021" Scenario #1  PAGEREF _Toc843021 \h 144  HYPERLINK \l "_Toc843022" Scenario #2  PAGEREF _Toc843022 \h 146  HYPERLINK \l "_Toc843023" Scenario #3  PAGEREF _Toc843023 \h 147  HYPERLINK \l "_Toc843024" Various Other Storyboards  PAGEREF _Toc843024 \h 148  HYPERLINK \l "_Toc843025" Attachment E: Lab Storyboards  PAGEREF _Toc843025 \h 155  HYPERLINK \l "_Toc843026" Simple Lab Order with Results, Closely Coupled Systems  PAGEREF _Toc843026 \h 155  HYPERLINK \l "_Toc843027" Bone Marrow Biopsy  PAGEREF _Toc843027 \h 157  HYPERLINK \l "_Toc843028" Automated Microbiology Reflex tests, loosely/closely coupled  PAGEREF _Toc843028 \h 159  HYPERLINK \l "_Toc843029" Laboratory Automation with closely-coupled order/results  PAGEREF _Toc843029 \h 162  HYPERLINK \l "_Toc843030" Food Safety Outbreak Investigation  PAGEREF _Toc843030 \h 165  HYPERLINK \l "_Toc843031" General Laboratory with Reflex Order  PAGEREF _Toc843031 \h 167  HYPERLINK \l "_Toc843032" General Laboratory with Frequency, Interrupted and Resumed  PAGEREF _Toc843032 \h 169  Attendees AttendeeCompany/E-MailMon AMMon PMTue AMTue PMWed AMWed PMThu AMThu PMFri Chris Brown HYPERLINK "mailto:ccbrown@quadramed.com" ccbrown@quadramed.com((Hans Buitendijk HYPERLINK mailto:hans.buitendijk@smed.com Hans.buitendijk@smed.com(((((((((Jim Case HYPERLINK mailto:Jtcase@ucdavis.edu Jtcase@ucdavis.edu((((((Carmela Couderc HYPERLINK "mailto:Carmela.couderc@smed.com" Carmela.couderc@smed.com((((Dav A. Eide HYPERLINK mailto:Eide.d@ghc.org Eide.d@ghc.org((Lisa Glaspie HYPERLINK "mailto:lglaspie@epicsys.com" lglaspie@epicsys.com(((((Hugh Glover HYPERLINK "mailto:Hugh_glover@multilex.com" Hugh_glover@multilex.com((((Edgar Gluck HYPERLINK "mailto:Edgar.gluck@kith.no" Edgar.gluck@kith.no(Mary Hamilton HYPERLINK "mailto:mhamilton@cdc.gov" mhamilton@cdc.gov(((Charles Hawker HYPERLINK mailto:Hawkercd@aruplab.com Hawkercd@aruplab.com((Julie James HYPERLINK "mailto:Julie_james@multilex.com" Julie_james@multilex.com((((Rose Jenkins HYPERLINK "mailto:Rose.Jenkins@smed.com" Rose.Jenkins@smed.com(((((((((Dan Jernigan HYPERLINK "mailto:Dbj0@cdc.gov" Dbj0@cdc.gov(Gaby Jewell HYPERLINK mailto:Gjewell@cerner.com Gjewell@cerner.com(Tom Jones HYPERLINK "mailto:Tom.jones@oracle.com" Tom.jones@oracle.com((((((Julia Kim HYPERLINK "mailto:jkim@cap.org" jkim@cap.org((((Andrzej J. Knafel HYPERLINK mailto:Andrzej.knafel@roche.com Andrzej.knafel@roche.com(((((((Sara Korpak HYPERLINK "mailto:Sara.korpak@mckesson.com" Sara.korpak@mckesson.com((((((Austin Kreisler HYPERLINK "mailto:Austin.kreisler@mckesson.com" Austin.kreisler@mckesson.com(((((((((Ken McCaslin HYPERLINK mailto:Kenneth.h.mccaslin@questdiagnostics.com Kenneth.h.mccaslin@questdiagnostics.com(Lloyd McKenzie HYPERLINK mailto:Lmckenzie@la.ibm.com Lmckenzie@la.ibm.com((((Suzanne Nagami HYPERLINK "mailto:Suzanne.e.nagami@kp.org" Suzanne.e.nagami@kp.org((((Manish Narang HYPERLINK "mailto:mnarang@ocdus.jnj.com" mnarang@ocdus.jnj.com(((((((Robert Nleski HYPERLINK "mailto:bobnl@att.net" bobnl@att.net(Mike Ostler HYPERLINK "mailto:mikeo@mediserve.com" mikeo@mediserve.com(((Amy Page HYPERLINK "mailto:Amy.page@med.va.gov" Amy.page@med.va.gov((Jeff Perry HYPERLINK "mailto:Jeff_perry@walker-ix.com" Jeff_perry@walker-ix.com((Dan Pollock HYPERLINK "mailto:dpollock@cdc.gov" dpollock@cdc.gov(Theresa Presley HYPERLINK "mailto:Theresa_presley@washoehealth.com" Theresa_presley@washoehealth.com(((((Linda Quade HYPERLINK "mailto:Lindaq@lilly.com" Lindaq@lilly.com(Rebecca Randolph HYPERLINK "mailto:Randolph.r@ghc.org" Randolph.r@ghc.org((((((Harry Rhodes HYPERLINK "mailto:Harry.Rhodes@ahima.org" Harry.Rhodes@ahima.org(((Scott Robertson HYPERLINK mailto:Scott.m.robertson@kp.org Scott.m.robertson@kp.org(((((((Gunther Schadow HYPERLINK mailto:schadow@regenstrief.iupui.edu Schadow@regenstrief.iupui.edu(((((Benjamin C. Schoenbrun HYPERLINK "mailto:Schoenbrun_Benjamin@bah.com" Schoenbrun_Benjamin@bah.com(((Karen Sieber HYPERLINK mailto:Ksieber@cerner.com Ksieber@cerner.com((((((Alan Sim HYPERLINK "mailto:asim@cdc.gov" asim@cdc.gov((Harry Solomon HYPERLINK "mailto:Harry.Solomon@med.ge.com" Harry.Solomon@med.ge.com((((Kent Spackman HYPERLINK "mailto:spackman@ohsu.edu" spackman@ohsu.edu((Helen Stevens HYPERLINK "mailto:Helen.stevens@mckesson.com" Helen.stevens@mckesson.com((((Paula Visyak HYPERLINK "mailto:Paula.a.visyak@kp.org" Paula.a.visyak@kp.org(((((Mead Walker HYPERLINK "mailto:mead@voicenet.com" mead@voicenet.com((Martin Whittaker HYPERLINK "mailto:martin@touchstone.uk.com" martin@touchstone.uk.com(((((Daphne Young HYPERLINK "mailto:Daphne.young@mckesson.com" Daphne.young@mckesson.com(((((( Communication with declared O&O participants can be done through  HYPERLINK mailto:ord@lists.hl7.org ord@lists.hl7.org. You can sign up on this list through HL7s home page  HYPERLINK "http://www.hl7.org" www.hl7.org. Related list servers for specific order/observation domain discussions are  HYPERLINK "mailto:bloodbank@lists.hl7.org" bloodbank@lists.hl7.org,  HYPERLINK "mailto:pharmacy@lists.hl7.org" pharmacy@lists.hl7.org,  HYPERLINK "mailto:microbiology@lists.hl7.org" microbiology@lists.hl7.org, and  HYPERLINK "mailto:lapauto@lists.hl7.org" lapauto@lists.hl7.org, and  HYPERLINK "mailto:dicom@lists.hl7.org" dicom@lists.hl7.org. Monday - Version 2.x Review We started Monday with a review of the open V2.x proposals to get them ready for the V2.5 ballot. Thanks to the hard work of Scott Robertson in particular, who coordinated the many V2.x conference calls, we have substantial new material for V2.5 as well as many, many clarifications and corrections that will enhance the overall usability of the standard. Thank you Scott!! The following are the proposals we reviewed with their disposition: Proposal 240 Clarify Reference Range Type Short Description: Clarify recently approved Reference Range (RFR) data type. Justification: This is a clarification of proposal #16 approved for ballot in a previous meeting. The component model for the RFR is inconsistent with the component narrative. The name of the first component should be Numeric Range not reference (normal) range because it is applied to Normal Range, Critical Range and Absolute Range fields. The OM2-numeric observation segment defined in chapter 8, section 8.8.4, has a number of fields with an undefined data type. This was uncovered by Frank Oemig during the version 2.4 membership ballotting process. A temporary solution that retained the CM data type but assigned data types to the components was agreed upon with the understanding that this situation could be corrected with a new data type in the next release. A Reference Range (RFR) data type having the following components would meet requirements for 3 of these fields: Components ^ ^ ^ ^ ^ ^ This data type could be applied to the following: 8.8.4.6 - OM2-6 The reference (normal) range for ordinal and continuous observations 8.8.4.7 - OM2-7 Critical range for ordinal and continuous observations 8.8.4.8 - OM2-8 Absolute range for ordinal and continuous observations This proposal is dependent on the Numeric Range data type proposal submitted under separate cover. (Note: proposals to apply the same data type to the OM2-7 and OM2-8 as the OM2-6 have been prepared under separate cover for submission to OO.) This proposal with minor changes was heard and approved in OO subcommittee on 12/13/00 with 7 participants representing HBOC and Kaiser Permanente. An early version of the proposal was considered in the OO teleconference on October 4. Twelve persons participated in the discussion representing Regenstrief, PIXIS, HBOC, Siemens, Quest, and Kaiser Permanente. 2.9 Data Types 2.9.N Reference range (RFR) Components: < Numeric range (NR)> ^ ^ ^ ^ ^ ^ Definition: Specifies the range of data being referenced and any constraining conditions applying to the value. 2.9.N.1 Numeric range (NR) Definition: Specifies the interval between the lowest and the highest values in a series of data. 2.9.N.2 Administrative sex (IS) Definition: Specifies which gender for which the reference range is valid. 2.9.N.3 Age range (NR) Definition: Specifies the age range for which the reference range is valid. 2.9.N.4 Gestational age range (NR) Definition: Specifies the gestational age range for which the reference range is valid. 2.9.N.5 Species (TX) Definition: Specifies the species for which the reference range is valid. 2.9.N.6 Race/subspecies (ST) Definition: Specifies the race or subspecies for which the reference range is valid. 2.9.N.7 Conditions (TX) Definition: Specifies any arbitrary condition for which the reference range is valid. This may include such conditions as phase of menstrual cycle or dose of a particular drug. Resolution The proposal was accepted with 10 for, 0 against, and 4 abstain. Proposal 245 CM Data Type Replacement for OO Part A Note: This is an updated version of proposal 213. It contains responses from the OO subcommittee on 01/02/02. Short Description: Continue to define new data types to replace existing CM data types. Justification: This proposal replaces proposal # 213 and numerous earlier ones. Continuation of proposal # 155. Data TypeSegment FieldComponent ModelSection ReferenceCommentCCD Charge code & dateBLG-1 When to charge ^ 4.5.2.1EIP Entity identifier pairOBR-29 Parent Number ^ 4.5.3.29 / 7.4.1.29Defined in 4.5.1.8EIPORC-8 Parent ^ 4.5.1.8MOC Money & charge codeOBR-23 Charge to Practice ^ 4.5.3.23 / 7.4.1.23NDLOBR-32 Principle Result Interpreter ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 4.5.3.32 / 7.4.1.32Contains embedded complex data type CN that cannot be fully expressed. Historical CN restored as CNH.NDLOBR-33 Assistant Result Interpreter ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 4.5.3.33 / 7.4.1.33Erratum identified: erroneous subcomponent model given for CN. Contains embedded complex data type CN that cannot be fully expressed. Historical CN restored as CNH.NDLOBR-34 Technician ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 4.5.3.34 / 7.4.1.34Erratum identified: erroneous subcomponent model given for CN. Contains embedded complex data type CN that cannot be fully expressed. Historical CN restored as CNH.NDLOBR-35 Transcriptionist ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 4.5.3.35 / 7.4.1.35Erratum identified: erroneous subcomponent model given for CN. Contains embedded complex data type CN that cannot be fully expressed. Historical CN restored as CNH.PRLOBR-26 Parent Result ^ ^ 4.5.3.26 / 7.4.1.26OSDOBR-27.10 Order Sequencing Component & & < Placer Order Number: Namespace ID (IS)> & < Filler Order Number: Entity Identifier (ST)> & < Filler Order Number: Namespace ID (IS)> & < Sequence Condition Value (ST)>& < Maximum Number of Repeats (NM)> & < Placer Order Number: Universal ID (ST)> & < Placer Order Number: Universal ID Type (ID)> & < Filler Order Number: Universal ID (ST)> & < Filler Order Number: Universal ID Type (ID)>4.5.3.27.10 / 7.4.1.27.10Embedded in TQ data type, comp 10, defined 4.3.10. Errata identified: 3 subcomponents (1, 6 and 7) have missing data types. These have now been corrected.OSDORC-7.10 Order Sequencing Component & & < Placer Order Number: Namespace ID (IS)> & < Filler Order Number: Entity Identifier (ST)> & < Filler Order Number: Namespace ID (IS)> & < Sequence Condition Value (ST)>& < Maximum Number of Repeats (NM)> & < Placer Order Number: Universal ID (ST)> & < Placer Order Number: Universal ID Type (ID)> & < Filler Order Number: Universal ID (ST)> & < Filler Order Number: Universal ID Type (ID)>4.5.1.8.10Embedded in TQ data type, comp 10, defined 4.3.10. Erratum identified: 3 subcomponents (1, 6 and 7) have missing data types. These have now been corrected.OSDRXE-1.10 Order Sequencing Component & & < Placer Order Number: Namespace ID (IS)> & < Filler Order Number: Entity Identifier (ST)> & < Filler Order Number: Namespace ID (IS)> & < Sequence Condition Value (ST)>& < Maximum Number of Repeats (NM)> & < Placer Order Number: Universal ID (ST)> & < Placer Order Number: Universal ID Type (ID)> & < Filler Order Number: Universal ID (ST)> & < Filler Order Number: Universal ID Type (ID)>4.14.4.1.10Embedded in TQ data type, comp 10, defined 4.3.10. Erratum identified: 3 subcomponents (1, 6 and 7) have missing data types. These have now been corrected. CCD- charge code and date Components: ^ HL7 Component Table - CCD charge code and date  XE "HL7 Component Table - CCD"  SEQLENDTOPTTBL#COMPONENT NAMECOMMENTSSEC.REF.11IDR100When to Charge Code226TSODate/time Definition: This field specifies when to charge for the ordered service. Specifies whether a charge action is based on an invocation event or is time-based. Issue: Sentiment was expressed in an OO subcommittee meeting that charge information be moved to chapter 6. This would include the entire BLG segment. Maximum Length: 28 Note: Replaces the CM data type used in section 4.5.2.1 BLG-1, as of version 2.5. When to charge code (ID) Definition: Specifies the code for the event precipitating/triggering the charge activity. Refer to  HYPERLINK \l "HL70100" HL7 Table 0100 Invocation Event  for valid values. HL7 Table 0100 - When to charge Invocation Event XE HL7 Table 0100 When to charge  ValueDescriptionDOn dischargeOOn receipt of orderRAt time service is completedSAt time service is startedTAt a designated date/timeOO 10/1/01: expand narrative to support new name, examples or some indication of broader context. These concepts not included in current v3 development these are very similar to trigger events. These values will need to be added to v3 vocabulary. Issue: Do we want to remove the constraint that this is related to charge activity? We already have ways to communicate when a service is ordered, when it should be/was performed and when it was recorded. Are there other events this would be used for other than charge activity? Date/time (TS) Definition: The second component is used to express the exact time to charge for the ordered service; it is used only when the when to charge value is T. When used, it is expressed as a TS data type. Resolution We accepted the proposal with 14 for, 0 against, and 3 abstain. EIP- entity identifier pair Components: ^ Subcomponents of parents placer order number: & & & Subcomponents of parents filler order number: & & & HL7 Component Table - EIP entity identifier pair  XE "HL7 Component Table - EIP"  SEQLENDTOPTTBL#COMPONENT NAMECOMMENTSSEC.REF.1EIPlacer Assigned Identifier2EIFiller Assigned Identifier Definition: Specifies an identifier assigned to an entity by either the placer or the filler system. If both components are populated the identifiers must refer to the same entity. Maximum Length: 267 Note: Replaces the CM data type used in sections 4.5.1.8 - ORC-8, 4.5.3.29 OBR-29, 7.3.1.29 OBR-29, as of version 2.5. Placer Assigned Identifier (EI) Definition: Specifies an identifier assigned to an entity by the placer system. For example, the component might be used to convey the following: placer order number of the parent order the specimen identifier as assigned by the placer. A location identifier assigned (or used by) the placer. Filler Assigned Identifier (EI) Definition: Specifies an identifier assigned to an entity by the filler system. For example, the component might convey the following: filler order number of the parent order the specimen identifier as assigned by the filler. A location identifier assigned (or used by) the filler. Resolution After incorporating minor changes as documented above (clarified that the use of the data type within a particular field can lead to specific restrictions, e.g., uniqueness) we accepted the proposal with 13 for, 0 against, and 4 abstain. MOC- money and charge code Components: ^ Subcomponents of monetary amount: & Subcomponents of charge code: & & & & & HL7 Component Table - MOC Money and code  XE "HL7 Component Table - MOC"  SEQLENDTOPTTBL#COMPONENT NAMECOMMENTSSEC.REF.115MOODollar amount Monetary Amount2250CEOCharge code Definition: This field is data type contains/specifies the charge to the ordering entity for the studies performed when applicable. Transmits monetary information and the associated charge code for services performed. Maximum Length: 267 Note: Replaces the CM data type used in sections 4.5.3.23 OBR-23 and 7.4.1.23- OBR-23 as of version 2.5. Dollar Monetary Amount (MO) Definition: The first component is a dollar amount when known by the filler.b The amount and denomination of money associated with the charge code. Charge code (CE) Definition: The second is a charge code when known by the filler (results only). The code identifying the charge to the ordering entity for the services performed. when applicable. Issue: Need user-defined table. Does one exist? This is unclear. There is a Charge Code element in segment field LCC-4 that has user-defined table 0132 transaction code assigned. The narrative for LCC-4 says to use the same values as in FT1-7 transaction code. OO 10/1/01 pure charge codes that are parallel to the service items. Not clear of the intent, inadvisable to specific as this not relate to current use(s). Rather than specify, detail the possible intents of the component. Editors note: Does anyone know what the intention is? Seems safest to declare a new user-defined table. Might also allow use of table 0132 as noted above. OO subcommittee response 01/02/02: Refer issue to PAFM. OO does not know if this is context sensitive or if existing table 0132 could be used. Resolution After incorporating minor changes as documented above (change the name of the first component in MOC from dollar amount to monetary amount), we accepted the proposal 14 for, 0 against, and 3 abstain. NDL name with date and location Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ Subcomponents of name: & & & & & & & & Subcomponents of facility: & & HL7 Component Table - NDL name with date and location  XE "HL7 Component Table - NDL"  SEQLENDTOPTTBL#COMPONENT NAMECOMMENTSSEC.REF.1250?CN CNSOName226TSOStart date/time326TSOEnd date/time420ISO302Point of care 520ISO303Room 620ISO304Bed7HDO362Facility820ISO306Location status 920ISO305Patient location type1020ISO307Building 1120ISO308Floor Definition: Specifies the name of the person performing a service, when the person performed the service and where the person performed the service. Maximum Length: 267 Note: Replaces the CM data type used in sections 4.5.3.32 and 7.4.1.32-( OBR-32) , 4.5.3.33 and 7.4.1.33 - ( OBR-33) 4.5.3.34 and 7.4.1.34 - ( OBR-34) 4.5.3.35 and 7.4.1.35 - ( OBR-35) as of version 2.5. Suggested Solution: The components below are the current components in the current order. Name (CNS) Definition: Name of person performing a service. Start date/time (TS) Definition: The starting date and time for when the person is performing the service. End date/time (TS) Definition: The ending date and time for when the person is performing the service. Point of Care (IS) Definition: Conditional on location type (e.g., nursing unit or department or clinic). After floor, most general patient location designation. HYPERLINK \l "HL70302"User-defined Table 0302 - Point of care is used as the HL7 identifier for the user-defined table of values for this component. Room (IS) Definition: Patient room. After point of care, most general location designation. HYPERLINK \l "HL70303"User-defined Table 0303 - Room is used as the HL7 identifier for the user-defined table of values for this component. Bed (IS) Definition: Patient bed. After room, most general location designation. HYPERLINK \l "HL70304"User-defined Table 0304 - Bed is used as the HL7 identifier for the user-defined table of values for this component. Facility (HD) Subject to site interpretation but generally describes the highest level physical designation of an institution, medical center or enterprise. Most general location designation. Location Status (IS) Definition: Location (e.g., Bed) status. HYPERLINK \l "HL70306"User-defined Table 0306 - Location status is used as the HL7 identifier for the user-defined table of values for this component. Location Type (IS) Definition: Location type is the categorization of the location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. Usually includes values such as nursing unit, department, clinic, SNF, physicians office. HYPERLINK \l "HL70305"User-defined Table 0305 - Person location type is used as the HL7 identifier for the user-defined table of values for this component. Building (IS) After facility, most general location designation. HYPERLINK \l "HL70307"User-defined Table 0307 - Building is used as the HL7 identifier for the user-defined table of values for this component. Floor (IS) After building, most general location designation. HYPERLINK \l "HL70308"User-defined Table 0308 - Floor is used as the HL7 identifier for the user-defined table of values for this component. Location description (ST) Definition: An unstructured textual description of the location used to support or substitute for the structured location information. Resolution We agreed to remove a proposal to add a Comprehensive Identifier and a XCN flattened list. This may be revisited on Friday if argument can be made to reconsider. We accepted a modification to rename CNH (composite name historical) to CNS (composite name simple) to indicate that the name structure is a simplified version of name and does not support the complex name structure with 15 for, 0 against, and 2 abstain. Action: Scott to take to CQ and Joann We accepted a suggestion to add Location Description with 14 for, 0 against, and 2 abstain. An issue was raised that we require the definition and data types for the components of the CNS prior to making a decision on this data type. Concern that the CNS will not support international requirements introduced in the XCN. Note: description from 2.2 CN. All components are ST data type. A field identifying a person both as a coded value and with a text name. The first component is the coded ID according to a site-specific table. The second through the seventh components are the person's name as a PN field. The eighth component specifies the source table used for the first component. For specific fields, individual sites may elect to omit the ID or the name. We agreed to change R to O and make all components optional. Let the field that uses the data type drive optionality of specific components. We pushed the discussion on extending XCN to Friday if somebody has compelling case for one or more components 9 thru 18. Key issue is internationalization of the family name and maintaining backwards compatibility. We accepted a decision to defer resolution on the NDL data type until Friday when a full review of the CNS can be included. In the interim, we will ask CQ to address the internationalization requirements in the CNS with 14 for, 0 against, and 3 abstain. PRL- parent result link Components: ^ ^ Subcomponents of OBX-3-observation identifier of parent result: & & & & & HL7 Component Table - PRL Parent result link  XE "HL7 Component Table - PRL"  SEQLENDTOPTTBL#COMPONENT NAMECOMMENTSSEC.REF.1250CEOBX-3-observation identifier of parent result Parent Observation Identifierdefined in the OBX-3 of the parent result.2STOBX-4-sub-ID of parent result Parent Observation Sub-identifierdefined in the OBX-4 of the parent result.3TXPart of OBX-5 observation result from parent Parent Observation Value DescriptorTaken from the OBX-5 of the parent result. Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-parent, uniquely identifies the parent results OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization. We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs. This field is present only when the parent result is identified by OBR-29-parent and the parent spawns child orders for each of many results. (See Chapter 7 for more details about this linkage.) A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism. Definition: Uniquely identifies the parent results OBX segment related to the current order, together with the information in OBR-29-parent. Usage Note: This data type is applied only to OBR-26 Parent Result where it serves to make information available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-parent, uniquely identifies the parent results OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization. We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs. This field is present only when the parent result is identified by OBR-29-parent and the parent spawns child orders for each of many results. (See Chapter 7 for more details about this linkage.) A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism. Maximum Length: ?? Note: Replaces the CM data type used in sections 4.5.3.26 - OBR-26 and 7.4.1.26 - OBR-26 as of version 2.5. OBX-3-observation identifier of parent result Parent Observation Identifier (CE) Definition: Contains the unique identifier of the parent observation as defined in the OBX-3 of the parent result. The value is the same as the OBX-3 of the parent. OBX-4-sub-ID of parent result Parent Observation Sub-identifier (ST)> Definition: Contains the sub-ID of the parent result as defined in the OBX-4 of the parent result. The value is the same as the OBX-4 of the parent. Part of OBX-5 observation result from parent Parent Observation Value Descriptor (TX) Definition: Contains a descriptor of the parent observation value as specified in the OBX-5 of the parent result. As an example, the third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture. OO 10/01/01 agree with component name changes. Note change to component 3 narrative, some thought that this field was added to support micro, may also be used for reflex tests, generally a narrow, focused use. If rewritten for wider use, will this just provide another method of grouping. Should not be rewritten to expand beyond what has been defined by Orders. Some of the field note from chapter 7 has not been pulled forward into this definition. This may have lost some of the intent of the data type. The original field note does not generalize well. Suggest that the data type should not be generalized in this nature. Keep more of the original language and specify that the data type has a very limited application just to be used for OBR. Editors note: Field notes have been restored. Looks like it still needs some smoothing out. Response from OO subcommittee on 01/02/02: Time did not permit adequate discussion. This needs to be looked at by Lab Auto in San Diego next week. Resolution We accepted the proposal with 14 for, 0 against, and 1 abstain. XE "OSD"XE "Data types: OSD"OSD - order sequence definition components: ^ ^ ^ ^ ^ ^ < Maximum Number of Repeats (NM)> ^ ^ ^ ^ HL7 Component Table - OSD order sequence definition  XE "HL7 Component Table - OSD"  SEQLENDTOPTTBL#COMPONENT NAMECOMMENTSSEC.REF.11IDRnnSequence/Results flag215STRPlacer Order Number: Entity Identifier36ISO0363Placer Order Number: Namespace ID415STRFiller Order Number: Entity Identifier56ISO0363Filler Order Number: Namespace ID612STOSequence Condition Value73NMOMaximum Number of Repeats815STRPlacer Order Number: Universal ID96IDO0301Placer Order Number: Universal ID Type1015STRFiller Order Number: Universal ID116IDO0301Filler Order Number: Universal ID Type Decision: Editor to reconcile lengths of components 2-5 and 8-11 to match with EI in chapter 2. Definition: This data type specifies a fully coded version for forming a relationship between an order and one or more other orders. The relationship may be sequential or a cyclical pattern. Usage of the OSD is restricted to the TQ data type (especially as it is applied to the ORC-7?). Retained for backwards compatibility only as of v 2.5. The reader is advised to consider the TQ1 and TQ2 segments rather than this data type if sequencing levels or cyclical patterns need to be transmitted. Maximum Length: 864? Note: Replaces the CM data type used in the TQ data type, component 10, as of version 2.5. Issue: Can we strike most of the following introductory narrative since the TQ is being deprecated? No, required to support 2.4 considerations. OO 10/1/01 - Assuming that TQ is accepted, then this might be struck out. However, not everybody may implement the new TQ construct, we do not want to lose valid narrative. The level of sequencing allowed by this data type would seem to indicate that the implementors would move to the new TQ. Appears reasonable to strike language as appropriate. Editors note: If the following 3 paragraphs are to be retained it seems like they should be under the Usage Notes, perhaps new point a, point b would then address cyclical patterns. This approach would appear to be consistent with the definition above. The current point b Inheritance of order status does not appear to be a parallel concept with Sequencing and Cyclical Patterns. There are many situations, such as the creation of an order for a group of intravenous (IV) solutions, where the sequence of the individual intravenous solutions (each a service in itself) needs to be specified, e.g., hyperalimentation with multi-vitamins in every third bottle. There are other situations where part of the orders instructions contains a results condition of some type, such as PRN pain. There is currently a free text condition component of ORC-7-quantity/timing which allows any condition to be specified. The sequencing conditions supported by this 10th component are based on the completion of a predecessor service. Usage Notes: a) Cyclic placer order groups To implement a cyclic group of four IV orders using the parent/child paradigm, the parent specifies a custom group of IVs, and the following occurs: ORC-7 quantity/timing of the second child order specifies that it follows the first child order. ORC-7 quantity/timing 2 of the third child order specifies that it follows the second child order. ORC-7 quantity/timing of the fourth child order specifies that it follows the third order. To repeat the group of four child orders in a cyclic manner, the following occurs: ORC-7 quantity/timing of the first child order specifies that it is to be executed once without any dependence on the completion of other orders. Its second execution follows the completion of the fourth order. See example in Section 4.15.2, RXO segment field examples. Editors Note: The following paragraphs regarding order status should be deleted from the OSD data type definition. The data type does not include any order status component. Does this discussion belong in the field notes for ORC-5 Order Status? No retain with OSD definitions. This scheme allows the following to be tracked: The status of the whole group of orders to be reported back at the level of the parent order. The status for each individual IV order by following the status of the corresponding child order. Separate Orders example: The same group of orders can be sent as a group of four orders (without a common parent), linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7 method of transmitting the order status of the group as a whole without transmitting the status of each of the four separate orders. b) Inheritance of order status Cancellation/discontinuation/hold order control events: This logic implies the normal execution of the referenced predecessor order. Thus a cancel (or discontinuation or hold) of a predecessor order implies the cancellation (or discontinuation or hold) of all subsequent orders in the chain. If the referenced order has been canceled (or discontinued or held), the current order inherits that same status. In the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given order (which can then be executed according to the specification in the TQ2 segment). Sequence/Results flag (ID) Definition: Identifies whether sequence conditions or a repeating cycle of orders is defined. HL7 Table nnnn Sequence Condition Code ValueDescriptionSSequence conditionsCRepeating cycle of ordersRReserved for possible future usePlacer Order Number: Entity Identifier (ST) Definition: Required component that cContains the first component of the placer order number, entity identifier . Placer Order Number: Namespace ID (IS) Definition: Optional component that cContains the second component of the placer order number, namespace ID. Refer to user-defined table 0363 - Assigning Authority for suggested values. Filler Order Number: Entity Identifier (ST) Definition: Required component that cContains the first component of the filler order number, entity identifier . Filler Order Number: Namespace ID (IS)> Definition: Optional component that cContains the second component of the filler order number, namespace ID. Refer to user-defined table 0363 - Assigning Authority Sequence Condition Value (ST)> Definition: Defines the relationship between the start/end of the related predecessor or successor order and the current order from ORC-2, 3 or 4. The acceptable condition values have the form commonly used in project planning methodologies : +/-