Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Autotransfusion wikipedia , lookup
Hemorheology wikipedia , lookup
Blood transfusion wikipedia , lookup
Blood donation wikipedia , lookup
Plateletpheresis wikipedia , lookup
Jehovah's Witnesses and blood transfusions wikipedia , lookup
Men who have sex with men blood donor controversy wikipedia , lookup
ABO blood group system wikipedia , lookup
October 2001 Minutes Orders/Observations Worksession Table of Contents Table of Contents .........................................................................................................................................................1 Attendees ......................................................................................................................................................................2 Version 2.x Review ......................................................................................................................................................3 Proposal 168 - CM Data Type Replacement – Part 4 ........................................................................................3 Proposal 154 - Timing/Quantity Proposal Proposal 115 – Repeat Pattern Data Type Proposal ........................3 Proposal 172 – Data Type Continuation ............................................................................................................3 Proposal 176 - Specimen Segment Proposal ......................................................................................................3 Proposal xxx – POC Triggers and Messages .....................................................................................................4 Blood Bank V2.x Proposal ................................................................................................................................4 Version 3 Ballot Review ..............................................................................................................................................8 January Agenda .........................................................................................................................................................13 Attachment A – V2.x Proposals ................................................................................................................................ 14 CM Data Type Replacement Part 4 (OO) ................................................................................................................14 Timing Quantity (TQ1/TQ2) Segment Proposal ......................................................................................................24 Part 6 CM Data Type Replacement Proposal ..........................................................................................................56 Blood Bank Special Interest Group (BB SIG) .........................................................................................................64 Attachment B – Version 3 Ballot Response Summary ............................................................................................93 October 2001 O&O Minutes Page 1 Attendees Mon PM Tue AM [email protected] [email protected] Attendee Company/E-Mail Nina August Hans Buitendijk Jim Case Laurecia DailyEvans Carol Donahue Tammy Dugan Karen Eckert Dav A. Eide David Fallas Charles Hawker Frank Howard Roark Hulet Frank Innes Julie James Gaby Jewell Neill Jones Andrzej J. Knafel Helmut König Austin Kreisler John Leslie Peter Macisaac David Markwell Tom Marley Ken McCaslin Lloyd McKenzie Dan Noack Jeff Perry Arkadi Popov LaRae Prue Alan Rector Scott Robertson Gunther Schadow Benjamin C. Schoenbrun Karen Sieber Anthony Smith Wayne Tracy Kendra Yen [email protected] [email protected] [email protected] Mon AM Tue PM Wed AM Wed PM Thu AM Thu PM Fri [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Communication with declared O&O participants can be done through [email protected]. You can sign up on this list through HL7’s home page www.hl7.org. October 2001 O&O Minutes Page 2 Version 2.x Review Proposal 168 - CM Data Type Replacement – Part 4 2.9.70 - Suggestion to add clarifying language if the title of Table 0100 is changed to Invocation Event. Since this concept ties to trigger events in V3, maybe want to consider Invocation Trigger Event as the table name. The vocabulary should be added to V3. No intent to make additions. 2.9.71 – Do not see a need to change the names to more generic, but if other parties discover the need, the description should use the current names as examples. 2.9.72 – Suggest to provide description where charge code references multiple possibilities, e.g., points to separate charge master, or to the “actual” service being charged, etc. 2.9.73 – Don’t want a separate segment (Issue 3). Agreement with suggestions 1, 2, and 3 on Issue 1. Suggest that references to other definitions are either hyperlinks, or repeat the other definition. This is a publication issue to keep it easy to read without jumping around. Leave the length increase to CQ. 2.974 – Agreement with name changes. Suggest to add “for example” to the third component’s definition to clarify that it is not only restricted to micro. Concern that it may open up another grouping mechanism. There is belief that it may already by used for reflex tests and the text already reference toxicology. We agreed that it should references beyond what OO already uses. Concern that the generalization is not appropriate as it really cannot be used elsewhere, other then OBR.26. 2.9.75 – Introductory text can go once the new TQ structure is accepted. If anybody outside OO uses it, they need to provide input accordingly. See Attachment A for proposed text with embedded comments. Proposal 154 - Timing/Quantity Proposal Proposal 115 – Repeat Pattern Data Type Proposal Editorial in OMG that the TQ1/TQ2 structure was mistyped. 4.4.4 OMG message structure table has [{ TQ1 }] when it should just be TQ1. Editorial in 4.13.6 to include RRE and 4/13/7 to change to 4.13.7 Agreed to keep Priority a default. Vote was 3-3-2 where current behavior superceded. A motion was moved to approve the Repeat Pattern Data Type Proposal. There was not further discussion. The motion was accepted with 9 in favor and 1 abstain. A motion was moved to approve the Timing/Quantity Proposal. There were some clarifications on the placement of the TQ1/TQ2 segments in the message structures. The motion was accepted with 8 in favor and 2 abstain. Both Austin Kreisler (McKesson) and Scott Robertson (Kaiser) were thanked for their efforts in creating a much cleaner and syntactically correct structure around timing/quantity. See Attachment A for proposed text with embedded comments. Proposal 172 – Data Type Continuation See Attachment A for proposal text with embedded comments. Proposal 176 - Specimen Segment Proposal General agreement from LAPOCT that a specimen segment makes sense. Various questions need to be addressed though. How is dependency between parent and dependent specimen, such as aliquot, derived, or components? Do we need to keep parent ID, child ID (repeat), or both? Agreement to only have the parent ID. Suggest to add Specimen Role with vocabulary from V3. Vote: Unanimous. Suggestion to include SPM into SSU and SSR messages where the sequence would be SAC, SPM with SPM optional. No objection. Need to change the diagram. Agreed that the diagram in the proposal only applies to the order environment. For the lab automation environment in chapter 13 the diagram will be a variant without the OBR. LAPOCT agrees with the proposed OML/ORL sequence. We are not sure yet about query messages. We agreed that LAPOCT may make adjustments related to this specifically for chapter 13. October 2001 O&O Minutes Page 3 Keep available volume and initial specimen volume in SAC as container specific info. Need better explanation. Suggestion SAC-22 to be renamed to Container Available Volume and adjust definition. Andrezj will address SAC clarifications and Jim the SPM clarifications. Proposal xxx – POC Triggers and Messages Will submit to V2 proposal database and contact Scott. Need to look at SPM and TQ1/TQ2. Blood Bank V2.x Proposal We reviewed the proposal and action items that were open up to the meeting. The following notes incorporate the open issues and the resolutions at the meeting (flagged as O/O input). See Attachment A for the corresponding updated in the actual proposal. Create BBSig observation status flags and table for BP Observation Status (BPX-03 Gaby>> This is a group effort. Assumably, O&O does not want us to use the OBX observation statuses Patti>> To my knowledge, we would only need three – Final, Preliminary and Corrected. Since those exst in the original table, I don’t understand why we can’t use that table. O/O input – is there any reason that we can not support the existing table 85. Ok to use table 85 in this field with changes made to document to reflect that this table is an HL7 table. Possible to indicate that some values may not be supported in the BB environment/should indicate that the values not used have no meaning in BB. Need to show the relationship of conditional using something other than (+). Gaby>> the + and * were actually used to indicate blood component only fields and commercial product only field. I renamed the fields. Those that begin BC are blood component only fields and indicate such in the field definition. Those that begin CP are commercial product only fields and indicate such in the field definition. Patti>> This seem fine to me. O/O Need to indicate in how BP, CP, and BC are used in the description of the elements of a segment It is recommended that this explanation be placed in section 4.4 of the document. In OMB, for NTE segment, need to enter a business statement for the type of note. Gaby>> matches Chapter 4’s annotation for ORM message definition. Patti>> No further comments O/O Added description of how notes will be used. It is accepted as written BP Donation ID (BPX-05) recommended that this be an EI data type. Gaby >> done O/O Change made to segment is accepted as written. Version 3 note: will need to support unique identifier. Need to determine the total number of characters will be specified for the identifier. Does this field need to be repeating to support all the different places the number maybe generated? Need to validate that ABC Codabar and ISBT 128 are defined ID issuing organizations. Define the specification for which message has what requirements based on the product Gaby>> not real sure what this means Patti>> No further comments O/O We believe this is addressed through field definitions. Need indicator to identify Commercial/blood product. This can be conveyed through the Manufacturer and Lot number. (Felt that the universal Service Identifier defines the product). Gaby>> I think this is just a comment and no action is needed. We define the message as being for a commercial product when the relevant fields are populated. Patti>> No further comments O/O This will be identified by the universal Service identifier. October 2001 O&O Minutes Page 4 BPX-11 (Blood Group). Adjust the conditional definition to state that field is required for blood components as well as specified commercial products (such as detergent solvent plasma) Gaby>> I did. The statement reads, “This is a conditional field and is required for blood components and certain commercial products (such as detergent solvent plasma).” Since it is for both components and commercial products, left the name as BP Blood Group (rather than BC Blood Group for blood component). Also, should the Blood Group in the BTX segment have the same statement? It currently states that it is required for blood components only. Patti>> No further comments O/O Need to determine if the field is conditional field, because it is required in some case. Need more definitions around the requirements. Need the rules for when the field is required. BPX-12 (BP Special Testing) should be optional when there is no requirements so it needs to be changed to optional from conditional. Gaby>> done. Patti>> No further comments O/O is the table owned by another organization and do we need the agreement to use the table? Need to also talk to publication regarding placing other organization’s tables in the HL7 documents. BPX-13 BP Expiration Date/Time Need to define conditions when this field in conditionally required. Need to build use case for the requirements. Gaby>> Why? This field is defined as optional. Patti>> I don’t want to build too many specific rules for this. It will get too complicated when we get to derivatives and accessories (filters, recipient sets),etc. Some of these have expiration dates, some do not. O/O this field is acceptable as an optional field. Recommend that if there are any AABB requirements that could constraint this as a conditional field based on some conditions that make this field required. Recommend a usage note to indicate that it is desired to have this field populated. BPX-18 BP Actual Dispense to Location Need to support home health and other situations proposed to be CE and an additional field for address. Not PL because it does not have enough fields per Scott Robertson from Kaiser. (we later discussed that the actual home-health facility itself would be a dispense-to location built into the database just like a ward/hospital location, and that including a patient’s address is not necessary for our purposes. We do not need to have this address. CM) Gaby>> No changes made. It is actually a PL (Person Location) data type. Patti>> No further comments O/O May need to consider CE (Code Entity) then go to another field for the physical address of the dispenser. Add a separate XAD field for the address (for the non coded address). This could create up to 3 fields to support a CE, PL, and XAD fields. BPX-19 BP Dispensed to Receiver should be XCN. Need to support free text names. Gaby>> done. Patti>> No further comments O/O Accepted. BPX-20 BP Responsible Observer – Need better name and description. Gaby>> Need someone else’s help here. Patti>> Are there are employee ID type fields in use anywhere? I don’t have the standard with me, so I can’t look it up. O/O WIP BPX-21 BP Equipment Instance Identifier – Make this a repeating field and need to make sure that there is information about repeating. Also need to make sure there is information. Gaby>> done. Patti>> No further comments O/O accepted. Need to review Producer’s ID field. Where we have CE consider changing to CWE’s October 2001 O&O Minutes Page 5 Gaby>> The CWE data type indicates that you can send only free text if no code is provided for the concept in the text. I searched the document for instances where it was indicated that free text was allowed in CE fields. I found it only for BPX-8 Commercial Product, so I changed it to CWE. I question why we don’t have the same statement for BTX-5 Commercial Product. We should probably go through each of the CE data elements and determine whether the code is required or not. If it is required to be coded, the data type should be CNE. CNE does not mean the field is required, it just means if there is a value in the field, it has to be a valid code. BPO-2 BP Universal service identifier (CE) BPO-5 BP Units (CE) BPO-10 BP Indication for Use (CE) BPX-2 BP Status (CE) BPX-6 BC Component (CE) BPX-7 BC Donation type / intended use (CE) BPX-11 BP Blood group (CE) BPX-12 BC Special testing (CE) BTX-3 BC Component (CE) BTX-4 BC Blood Group (CE) BTX-5 CP Commercial Product (CE) BTX-10 BT Units (CE) BTX-11 BT Transfusion Status (CE) BTX-19 BT Adverse Reaction Type (CE) Patti>> BP Units and BT Units should not be coded fields. Since there is always a text description even for coded elements, I think the others should be coded. BTX Blood Product Transfusion BTX-02 BT Donation ID+ This should be changed to EI data type rather than ST and be more consistent with the use case notes in the document. Gaby>> done. Patti>> No further comments O/O Done. Define BT at the beginning of 4.4 BTX-08 – Quantity BTX-09 Amount Will it ever be required for amount when Quantity is Required. Need to put more information about the relationships of these two fields Gaby>> need help with this one. Patti>> Yes. Amount will be used to indicate the volume of blood components required when less than a full unit is request. For example, they may order I unit containing 35 ml. Another example would be when ordering factor concentrate. They will order 5 vials of Factor VIII dosage 2150 IU. Quantity should be required. Amount is optional. O/O No additional rules that can be stated. BTX 9 and 10 can be combined. Need to clarify whether BTX9/10 used when either overriding the implicit amount through BTX 3 or 5, or to describe the amount if there is no implicit amount through BTX 3 or 5. Recommend that fields BTX-18 and BTX-20 be eliminated as Y/N fields by the absences and presences of information in BTX-19 and BTX-21. Gaby>> I didn’t do this because I don’t remember discussing it as a group. Patti>> I don’t remember discussing this as a group. I don’t have a problem with doing this, though. We should probably bring it up again. O/O Consider to include AL1 as an optional repeats after BTX. Consider OBX repeat after the BTX to support observations of allergies or adverse reactions to the transfusion. Consider using the IAM to replace AL1 segment to replace the BTX-19&21. Gaby>> Again, I’m not opposed to talk about it. I am not familiar enough with the IAM segment to make a knowledgable decision. October 2001 O&O Minutes Page 6 Adverse events can be entered in the AL1. Gaby>> Okay, which one do they want? The IAM or the AL1? The AL1 seems more appropriate as the IAM used to keep allergies in sync between 2 systems. What we’re really trying to convey is an adverse reaction to a specific transfusion, right? The AL1 segment is really designed to send information about a patient allergy. I’m not sure we have the information to complete the AL1 segment. It requires the allergy code, and all we know is that the patient displayed an adverse reaction to a specific transfused product. I suppose the allergy code would have to relate to a blood product (BP universal service id). The AL1 also allows us to define the severity (Severe, Moderate, Mild) and the free text reaction. The problem is it doesn’t allow us to tie it back to a specific blood component or commercial product. We can require that association by it’s placement within the message (the AL1 segment must also follow the BTX segment to which it is associated). Thoughts? Patti>> I don’t like the idea of using the AL1 segment. You are right – we need to be able to tie it back to a transfusion event. I would orefe r to keep it right in our own BTX segment. BTX-14,15, 20 have cut and past problems need to resolve. Gaby>> May have been done by Lloyd as I didn’t see any problems. Patti>> No further comments. I can’t see qnything. O/O Has already been resolved BTX 18, 19 will be repeating fields. Gaby>> done. If we don’t use the AL1 segment, only field 19 needs to repeat. Patti>> Agreed. O/O Agreed . Need to support TQ1 and TQ2 segments. Does BBSIG need to support SAC segments? Need to BTX BPX-15 Change data type to a CQ BPX-16 should be eliminated Define BT to BP – Consider if possible. October 2001 O&O Minutes Page 7 Version 3 Ballot Review We spend most of Tuesday through Thurday to review the V3 ballot feedback. The numbers correspond to the entries in the table in Attachment B. Common Review Issue 11, 19 - Need interactions for nullified and obsolete states. This issue relates to the There were two triggers with two interactions. “Supercede” became “obsolete” and “nullified” was added. Need to combine the triggers/interactions for supercede and add one for nullified. We need other interactions as well since we can go from anywhere to obsolete. We agreed to define interactions as follows: 1. (Obsolete) Normal to Obsolete – Common 2. (Obsolete) Normal to Obsolete and Null to Normal – Lab 3. (Obsolete) Normal to Obsolete and Null to Normal – Rx 4. (Obsolete) Normal to Nullified – Common 5. (ReActivate) Complete to Active – Rx – Medication SIG will determine whether it will be put in scope. 6. (Revise) Complete to Complete – Lab Need a Revise on New in the state machine. Will not create interactions for them. Needs to go to harmonization. Need interaction that is tied to two state transitions. MnM Issue 24 - Missing receiver request and sender notify role interactions for abort, resume, cancel, hold. They are located in section 5. Hold is outside the scope of the first cut. Request to withdraw negative. Issue 25 - Missing sender and receiver interactions for cancel, abort, resume, hold, and notify activate, notify supercede. The first three are dealt with in general order messages, hold is out of scope, notify activate is there, and notify supercede is being revamped. Request to withdraw negative. Issue 32, 12, 13 – Storyboards and diagrams We agreed to create a number of Lab and Rx storyboards. Cross Lab/Rx storyboards will be “nice to have” and therefore be low on the priority list. On Wednesday and Thursday respectively we will establish the storyboard and example outlines. We will need one point person to orchestrate each effort to be overall synchronized by Hans. Ladder diagrams are part of the storyboard (one ladder diagram per storyboard). Therefore the current ladder diagrams will collapse and be combined. Issue 33 – See Issue 32 resolution Issue 43 Agreed to change the wording to “shared or synchronized repository”. Hans withdrew the minor negative. Issue 46 We did not distinguish at the trigger event level. New storyboard approach will avoid having to create different storyboard based on loosely vs. closely coupled variants. We had agreed to only address closely and loosely coupled variants as part of the first V3 iteration. Other variants can be addressed later based on specific use cases. Interactions require separation. Request MB to withdraw. Issue 18 – Act.priority_cd vocabulary is missing. We had already agreed that USAM values would be used, but did not make it. Needs to be submitted to harmonization. Austin will withdraw the negative when harmonized. Issue 73 Committee accepts suggestion to change cardinality to 0. Will forward to the CMET Group with OO endorsement. Issue 8 Acceptance to add minimum required attributes and will be passed to CMET Group as proposed changes. Austin will withdraw once addressed. Issue 14 - Application Acknowledgement can’t require application acknowledgement Control/Query already agreed with the use case and is willing to allow for this. Methodology allows for it. OO endorses the need. Austin is willing to withdraw when Control accepts. Issue 86 – Vocabulary Need improved vocabulary. Issue 80 – Description Enhancements There is agreement that this must be done. Issue 60 - Print suppression in Micro Biology. October 2001 O&O Minutes Page 8 Topics for further discussion: Normal to Obsolete, Normal to Nullify. Lloyd did some RMIM's for common messages for normal to Obsolete. Allergy CMET, Allergy management. We will deal with this in detail during the 3 rd Quarter. Vocabulary - Determine what the holes are. Lloyd suggested doing a query against the data base to find this out. Description Enhancements. Discussed how to deal with enhancing descriptions. Charlie Hawker was volunteered by the LAPOCT people. I latter verified that he was okay with this. Need a mid November conference call to go over Descriptions. Lab Storyboard Volunteers - Laurecia Dailey-Evans. Kaiser (Scott Robertson is the contact) and Quest (Ken McCaslin is the contact) will be participating also. Lab Descriptions Volunteers - Charlie Hawker. Kaiser (Scott Robertson is the contact) and Quest (Ken McCaslin is the contact) will be participating also. Allergy Discussion We are limiting the scope to an Allergy CMET. We won't include Allergy management messages in the next ballot. Remove Device from Authoring Choice. The CMET won't have a capability to report allergy history. Rename the base class from Allergy to Intolerance. Remove AR_Component from the R-MIM. Restrict Intolerance.value data type to UVP(CE) and UVN(CE), using coding strength CWE. Add in attribution information (author, verifier, etc. from message control. 21 – missing interaction diagrams. Discussion: Noted that there are very few storyboards in the pharmacy ballot. There were more storyboards submitted, but there was insufficient time to code into the ballot format. Response: Yes, will be addressing the need for additional storyboards 22 - discussion: essentially the same as 21. Response: will be resolved with further storyboard work. 23 – missing sending role interactions for. Discussion: took a different approach than lab. Integrated tracker and placer. Response: pharmacy roles will be revised to follow the same construct as lab. 26 – placer/filler breaking complex orders into individual event orders (i.e., dispense now). Discussion: some applications deal with the complex order while others only deal with individual administration instances. Daphne's comment appears to ask for an application to support both. The two scenarios are not mutually exclusive, an application may be able to support both. It did not seem to be necessary to create a combined role, but with recent changes in methodology, this is now possible. Resolution: will create a container application role to combine both roles. Nn – medication vs packaged medication. Discussion: medication cmet represents something that can be administred. Packaged medication is something that is meant to be dispensed, which may include package info, administratation devices. Packaged medication cmet references the medicinal product CMET. Response: cmet descriptions will be revised to clarify intent and relationships or families of related CMETs. Nn – vaccination management? Discussion: current vaccination is not separated as distinction orders in v3. Vaccinations do have additional "tracking" and query requirements, however this may not be very different from the requirements for cytotoxic regimens. We could add a means to identify a product as a vaccine, cytotoxic, etc. at the least, we need to have vaccine related stories. An additional role(s) and interactions for vaccination management/reporting may be necessary. Some question as to whether this is within current scope. Some of these requirements may be business rule requirements, but the message content must support these requirements. Also, vocab will need to incorporate terminology needed for vaccine messages/report. Response: will confirm/support identification of a order as a vaccination order within the current pharmacy messages for special reporting October 2001 Page 9 O&O Minutes requirement at the order and administration event and dispense. (to support multiple reporting concepts e.g., vaccine, controlled substances, antibiotic survey). 79 – what is P_subject 1 to many rather than 1 to 1. Discussion: was originally to support orders for families or herds, but the CMET has been enhanced to support the concept of a group. Response: will revise cardinality to 1..1. 82 – already discussed 84 – identification of contraindications. Discussion: need to discuss the modeling of contraindications in more detail. 85 – means to request an event. Discussion: the concept of instance orders was to support this requirement. Response: withdrawn by submitter 27 – cd is act_code, implies that any act code is acceptable. Discussion: a vocab issue. Clinical drug is still being settle. There may be realm-specific requirements. But there still may be need for a universal vocabulary to support messages between realms. Further vocab work is needed. Response: Need to have domain defined and constrain cd to that domain in the message model (keyword: harmonization) general discussion: Do the messages support a primary recipient and "cc's"? This is supported in infrastructure. The message content does not change but the message wrapper is different. Further discussion on the concept of multiple trackers. New security issues may Plan for remainder of the day: Vocab issues: where are the holes, what is needed now, what can happen later Contraindications: identification, messaging issues, overrides, Queries: start discussion, what is absolutely needed for immediate ballot Storyboards … Call for volunteers to the CMET group Tom Marley action items: Lloyd: need to confirm that pharmacy msgs support shelf expiration and reconstitution expiration. The second quarter focused on. Plan for remainder of the day: Quick run-through the ballot Vocab issues: where are the holes, what is needed now, what can happen later Contraindications: identification, messaging issues, overrides, Queries: start discussion, what is absolutely needed for immediate ballot Storyboards … action items (drawn forward through minutes): (Wed Q1/Lloyd) Need to confirm that pharmacy msgs support shelf expiration and reconstitution expiration. (Wed Q2/Lloyd) request definitive statement on attribute renaming from MnM (Wed Q2/Lloyd) we need to look at e-claim material relative to UK container orders October 2001 O&O Minutes Page 10 >>Negative ballot item from MedRec. MedRec has renamed their act.id's to act.id_filler and act.is_placer. Neg ballot by Austin to have them change back to act.id. push back that maybe orders (lab, pharmacy, ord) should use id_filler and id_placer. Discussion acknowledges that a person may have difficulty differentiating between the ids, but a computer would not. Additionally, new tooling will allow annotations to be conveyed down through the RMIM and HMD. Generally, attribute renaming is not considered a good idea. Outcome: Lloyd will bring issue of attribute renaming to MnM to request a definitive statement. Ord/Pharm does not find the argument to rename the attributes compelling, but does agree that better annotations are needed. Wayne may be willing to change back if appropriate annotation can be introduced and maintained through all necessary levels of the messaging documents. >>Overview/Review of Pharmacy V3 ballot by Lloyd. Pharmacy Domain: Health & Clinical Management (HM) Practice & Operations (PO) Pharmacy (RX). All artifacts are of the form HMPO_RX_xxnnnn. Storyboards will be added to the domain level Interaction categories are a means to group related trigger events, interactions and storyboards. Lab and Pharmacy used a common set of categories of Order, Intent and Event. Trigger events are an occurrence of some sort that results in one or more messages being sent. May be sent from one application to another, or from an application to itself. Message type is a structure that is used to send information. A type may be used in different contexts and result in different activities on the receiving side. Interaction is a specific message sent between two applications (or one application to itself). An interaction is a specific message type being sent between a specific sender application (role) to a specific receiver application (role) resulting from a specific trigger event. (Additional definitions and descriptions can be found in the v3 guide and the backbone) Questions led to the discussion of the state diagram. Theoretically, all states can be applied to all domains, however, in practice some states are not relevant. For pharmacy, the new (and related states) may not be significant. Most trigger events relate directly to state transitions. But there are trigger events that are not tied to a state transition, e.g., a query is not a state transition. MnM is developing more specific language on when a trigger event must be tied to state transitions. The super-state of normal permits the transition from any of the sub-states to nullified or obsolete. An object must exist in a sub-state of normal, but exists in normal only in relation to the sub-state. Discussion of relationship of actions within an application as it relates to the state diagram. Some systems, particularly MedRec, each revision of an order may be modeled as a separate object. This may be different model concept: each revision would be a new instance rather than revisions to an given instance. In these cases, the only need is to transition from null to normal and normal to obsolete. In these cases, it is suggested that this modeling would use null to complete and complete to obsolete. This is in terms of messages between MedRec systems … messages between MedRec and Lab would depend on messaging concepts of the Lab application. The filler would send the results back to the placing system … while the filler may be changing the state to complete, the placing system transitions to complete only when all intents associated with the order are complete. (The state of the order on the placing system does not have to match the state of the filler system intent.) Moods: Intent is a superset of Order. OO uses Intent in a specific way: the placer sends the Order and the filler responds with an Intent message. The Intent contains the filler's agreement to do the requested service and any interpretation or refinement of the Order (what would be the "encoded order" in v2x). Differentiation between Order and Intent is done in terms of the trigger event and the application role. All are identified as separate artifacts in v3. October 2001 O&O Minutes Page 11 Concept of a container order. Where an order exists that consists of multiple orders. Example, a single prescription that contains orders for three medications has an identifier for the order and separate identifiers for each of the separate medications. (In the UK this can effect patient charges, one order of three things is charged differently than three separate orders.) OO 4th Quarter Quick Meeting with Medical Records. Discussion about changing Act.id attribute name (i.e., rename the attribute in the R-MIM/HMD's). An alternate solution to Wayne's issue is to add a small comment to the HMD for an alternate description for the attribute name. This appears to be the solution to the issue. Medical Records will be reverting to the original attribute (id). MR wants OO to approve adding ORC/OBR addition to med record messages. OO doesn't have an issue with this proposal. MR is going to evaluate if TQ1/TQ2 need to be added. Other OO Stuff The OO representatives to the new CMET group are Tom Marley (Pharmacy) and Manish Narang (LAPOCT). Manish was volunteered by a LAPOCT co-chair (Andrzej Knafel), so this hasn't been confirmed with Manish. OO doesn't have direct representation on the CMET group. As Austin pointed out at the meeting, direct OO membership seems to have been dramatically reduced due to all the SIG's we now have. We have gone from one of the largest committees to one of the smallest (no counting the SIG members). Austin feels don't know if this is a good thing or a bad thing, but it does mean we are getting stretched pretty thin when it comes to things like this. October 2001 O&O Minutes Page 12 January Agenda The agenda for January is tentatively defined as follows: Monday Tuesday Wednesday Thursday Friday October 2001 O&O Minutes 09:00 – 10:30 AM1 OO – Finalize V2.5 proposals 11:00 – 12:30 AM2 OO - Finalize V2.5 proposals OO + Med + BB + LAPOCT – V3 OO + Med – V3 OO + LAPOCT – V3 OO – Finalize V2.5 proposals OO + Med + BB + LAPOCT – V3 OO + Med – V3 OO + LAPOCT – V3 OO – Finalize V2.5 proposals 01:45 – 03:00 PM1 OO+LAPOCT – Finalize V2.5 proposals OO + Med + BB + LAPOCT – V3 OO + Med – V3 OO + LAPOCT – V3 Adjourn 03:30 – 05:00 PM2 OO + BB – Finalize V2.5 proposals OO + Med + BB + LAPOCT – V3 OO + Med – V3 OO + LAPOCT – V3 05:00 >> Evening Page 13 Attachment A – V2.x Proposals CM Data Type Replacement Part 4 (OO) Short Description: Continue to define new data types to replace existing CM data types. Justification: This proposal replaces proposal # 141 and a portion of proposal # 135. Continuation of proposal # 155,165, 166 and 167. Data Types 2.9.70 Components: CCD- charge code and date <when to charge code (ID)> ^ <date/time (TS)> HL7 Component Table - CCD – charge code and date SEQ LEN DT OPT TBL# COMPONENT NAME 1 1 ID R 100 When to charge code 2 26 TS O Note: COMMENTS SEC.REF. Date/time Replaces the CM data type used in section 4.5.2.1 BLG-1, as of version 2.5. Definition: This field specifies when to charge for the ordered service. Issue: CQ teleconference 9/19: Consider generalizing. Specifies whether an action is based on an invocation event or is time-based. 2.9.70.1 When to charge code (ID) Definition: The first component contains a value defined in HL7 Table 0100 - When to charge. HL7 Table 0100 - When to chargeInvocation Event Value Description D On discharge O On receipt of order R At time service is completed S At time service is started T At a designated date/time OO 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. 2.9.70.2 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. October 2001 O&O Minutes Page 14 2.9. 71 EIP- entity identifier pair Components: <parent's placer order number (EI)> ^ <parent's filler order number (EI)> Subcomponents of parent’s placer order number: <entity identifier (ST)> & <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (IS)> Subcomponents of parent’s filler order number: <entity identifier (ST)> & <universal ID (ST)> & <universal ID type (IS)> <namespace ID (IS)> & HL7 Component Table - EIP – entity identifier pair SEQ LEN DT OPT TBL# COMPONENT NAME 1 EI Parent's placer order number 2 EI Parent's filler order number COMMENTS SEC.REF. 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. Definition: TBD Issue: This data type should be more general. The current component names should stand as field names. Suggested Solution: Component 1 – Identifier 1; Component 2 – Identifier 2 Sept 19 CQ teleconference Response: We need a use case before generalizing. 2.9.71.1 Parent's placer order number (EI) Definition: The placer order number of the parent order. 2.9.71.2 Parent's filler order number (EI)> Definition: The filler order number of the parent order. OO 10/1/01 – agree not to generalized unless a use case exists. If generalized, the orignial meaninig of placer/filler should not be lost … include as example. 2.9.72 MOC- money and code Components: <dollar amount (MO)> ^ <charge code (CE)> Subcomponents of dollar amount: <quantity (NM)> & <denomination (ID)> Subcomponents of charge code: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (ST)> HL7 Component Table - MOC – Money and code SEQ LEN DT OPT 1 15 MO O Dollar amount 2 250 CE O Charge code Note: October 2001 O&O Minutes TBL# COMPONENT NAME COMMENTS SEC.REF. 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. Page 15 Definition: This field is the charge to the ordering entity for the studies performed when applicable. Issue: Need to increase field length from 40 to at least 250, the length of the largest component. Issue: The intent of the MO data type as of version ?? is that it be used only in the CP data type. Solution: 1) Change the MO narrative to include usage within the MOC as well as the CP OR, 2) Deprecate component 1 and replace with a new component 3 composite price. 2.9.72.1 Dollar amount (MO) Definition: The first component is a dollar amount when known by the filler. 2.9.72.2 Charge code (CE) Definition: The second is a charge code when known by the filler (results only). Issue: What does this mean? 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. 2.9. 73 NDL – name with date and location Components: <name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <patient location type (IS)> ^ <building (IS)> ^ <floor (IS)> Subcomponents of name: <ID number (ST)> & <family name (ST)> & <given name (ST)> & <middle initial or name (ST)> & <suffix (e.g., JR or III) (ST)> & <prefix (e.g., DR) (ST)> & <degree (e.g., MD (ST)> & <source table (IS)> & <assigning authority (HD)> Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)> HL7 Component Table - NDL – name with date and location SEQ LEN DT OPT 1 250 ? CN B? 2 26 TS 3 26 TS TBL# COMPONENT NAME SEC.REF. Name Start date/time End date/time 4 IS 302? Point of care 5 IS 303? Room 6 IS 304? Bed 7 HD 362?? Facility 8 IS 306? Location status 9 IS 305? Patient location type October 2001 O&O Minutes COMMENTS Page 16 SEQ LEN DT OPT TBL# COMPONENT NAME 10 IS 307? Building 11 IS 308? Floor COMMENTS SEC.REF. 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 - ( OBR33) 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. Definition: Specifies the name of the person performing a service, when the person performed the service and where the person performed the service. Is this correct? Issue 1: This construction is a concatenation of the CN data type (that was deprecated and replaced by XCN in v 2.3), 2 elements of type TS, and an outdated version of the PL data type. The CN as a component of NDL has 2 subcomponents FN and HD that cannot be legally expressed in that they in turn have subcomponents. Suggested Solution: 1) Update the PL portion to 2.5 2) Deprecate the name component and replace with a new Person Name component at the end with an XCN that has been flattened. 3) Assign table numbers as they currently exist for the PL and XCN data types. 4) Three of the 4 fields in question repeat so it is difficult to turn this into 2 fields like we have done in some of the pharmacy segments. Issue 2: Length should be increased from 200 to nnn. The CN component itself could probably run 250 as could the PL portion if fully populated. Issue: Should this be a segment? 10/01/01 OO – do not favor a new segment The components below are the current components in the current order. Name (CN) Definition: Name of person performing a service. Retained for backwards compatibility only. Cannot be fully expressed legally. Refer to components nn –nn instead. 2.9.73.1 Start date/time (TS) Definition: The starting date and time for what? When the person is performing the service? 2.9.73.2 End date/time (TS) Definition: The ending date and time for what? When the person is performing the service? 2.9.73.3 Point of care (IS) Definition: See PL.1, section 2.9.21.1 October 2001 O&O Minutes Page 17 10/01/01 OO – using only reference is difficult to work with. Copy definition and retain reference? A publications issue. 2.9.73.4 Room (IS) Definition: See PL.2, section 2.9.21.2 2.9.73.5 Bed (IS) Definition: See PL.3, section 2.9.21.3 2.9.73.6 Facility (HD) Definition: See PL.4, section 2.9.21.4 2.9.73.7 Location status (IS) Definition: See PL.5, section 2.9.21.5 2.9.73.8 Patient location type (IS) Definition: See PL.6, section 2.9.21.6 2.9.73.9 Building (IS) Definition: See PL.7, section 2.9.21.7 2.9.73.10 Floor (IS) Definition: See PL.8, section 2.9.21.8 2.9.73.11 Location description (should this be added?) Definition: TBD 2.9.73.12 Comprehensive identifier (should this be added?) Definition: TBD 2.9.73.13 Begin XCN flattened list?? Definition: TBD OO 10/01/01 – agree with suggestions 1, 2, and 3. Issue 2, length, agree that length needs to be increased 2.9.74 PRL- parent result link Components: <OBX-3-observation identifier of parent result (CE)> ^ <OBX-4-sub-ID of parent result (ST)> ^ <part of OBX-5 observation result from parent (TX)see discussion> Subcomponents of OBX-3-observation identifier of parent result: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (ST)> HL7 Component Table - PRL – Parent result link SEQ LEN DT 1 250 COMPONENT NAME COMMENTS CE OBX-3-observation identifier of parent result Parent Observation Identifier defined in the OBX-3 of the parent result. 2 ST OBX-4-sub-ID of parent result Parent Observation Sub-identifier defined in the OBX-4 of the parent result. 3 TX Part of OBX-5 observation result from parent Parent Observation Value Descriptor Taken from the OBX-5 of the parent result. October 2001 O&O Minutes OPT TBL# SEC.REF. Page 18 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. 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 result’s 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. Issue: Component names beginning with a segment field identifier would seem to be ill-advised. Consider names like Parent Result Identifier for component 1 and Parent Result Sub-identifier for component 2. The narrative could describe the source of the identifier and sub-identifier. This needs to be evaluated by OO. Definition: TBD 2.9.74.1 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. 2.9.74.2 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. 2.9.74.3 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. Issue: Need to establish a good name for this component. Issue: Definition needs to be fixed to include other uses than micro-organisms. 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. 2.8.75 OSD - order sequence definition components: October 2001 O&O Minutes <Sequence/Results flag (ID)> ^ <Placer Order Number: Entity Identifier (ST)> ^ <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)> Page 19 HL7 Component Table - OSD – order sequence definition SEQ LEN DT OPT TBL# COMPONENT NAME nn Sequence/Results flag 1 ID 2 ST 3 IS 4 ST 5 IS 6 ST Sequence Condition Value 7 NM Maximum Number of Repeats 8 ST 9 ID 10 ST 11 ID Note: COMMENTS SEC.REF. Placer Order Number: Entity Identifier 0363 Placer Order Number: Namespace ID Filler Order Number: Entity Identifier 0363 Filler Order Number: Namespace ID Placer Order Number: Universal ID 0301 Placer Order Number: Universal ID Type Filler Order Number: Universal ID 0301 Filler Order Number: Universal ID Type Replaces the CM data type used in the TQ data type, component 10, as of version 2.5. 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. Issue: Can we strike most of the following introductory narrative since the TQ is being deprecated? 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. 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 order’s 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: October 2001 O&O Minutes 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. Page 20 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. 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: b) 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. 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). 2.9.75.1 Sequence/Results flag (ID) Definition: Identifies whether sequence conditions or a repeating cycle of orders is defined. HL7 Table nnnn – Sequence Condition Code Value Description S Sequence conditions C Repeating cycle of orders R Reserved for possible future use 2.9.75.2 Placer Order Number: Entity Identifier (ST) Definition: Required component that contains the first component of the placer order number, entity identifier . 2.9.75.3 Placer Order Number: Namespace ID (IS) Definition: Optional component that contains the second component of the placer order number, namespace ID. Refer to user-defined table 0363 - Assigning Authority for suggested values. October 2001 O&O Minutes Page 21 2.9.75.4 Filler Order Number: Entity Identifier (ST) Definition: Required component that contains the first component of the filler order number, entity identifier . 2.9.75.5 Filler Order Number: Namespace ID (IS)> Definition: Optional component that contains the second component of the filler order number, namespace ID. Refer to user-defined table 0363 - Assigning Authority 2.9.75.6 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: <one of “SS”, “EE”, “SE”, or “ES”> +/- <time> Issue: Should we declare an HL7 defined table ???? This is under consideration for the TQ2 segment. HL7 defined table ???? Value Description EE End related order(s), end current order. ES End related order(s), start current order. SS Start related order(s), start current order. SE Start related order(s), end current order. * The first order in a cyclic group # The last order in a cyclic group. For the special case where there is a cycle of orders that must be repeated, the first order to be executed will have a “sequence condition value” whose first repeat must be an asterisk (*). The last order to be executed may have a “sequence condition value” whose first repeat must be a pound sign (#). Example: ...|*~ES|+10^min|... translates to: execute this order the first time without evaluating the condition specified in the TQ2 segment; but repeat only its execution when the specified external order’s start or finish date/time has met this condition. This specification generates a repetition of the order for each iteration of the cycle. Note: This requires that the ordering application be able to specify the placer/filler/placer group order number of the last order in the cycle in the first order’s quantity/timing specification. 2.9.75.7 Maximum Number of Repeats (NM)> Definition: The maximum number of repeats to be used only on cyclic groups. The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first. 2.9.75.8 Placer Order Number: Universal ID (ST)> Definition: Required component that contains the next to the last component of the placer order number, universal ID October 2001 O&O Minutes Page 22 2.9.75.9 Placer Order Number: Universal ID Type(ID)> Definition: Optional component that contains the last component of the placer order number. Refer to HL7 table 0301 - Universal ID Type for valid values. 2.9.75.10 Filler Order Number: Universal ID (ST)> Definition: Required component that contains the next to the last component of the filler order number, universal ID . 2.9.75.11 Filler Order Number: Universal ID Type(ID)> Definition: Optional component that contains the last component of the placer order number. Refer to HL7 table 0301 - Universal ID Type for valid values. October 2001 O&O Minutes Page 23 Timing Quantity (TQ1/TQ2) Segment Proposal Short Description: Replace the TQ data type with two new segments, the TQ1 and TQ2. Justification: The TQ data type has a number of “features” that break the HL7 message encoding rules as given in chapter 2. To correct these problems, and retain the TQ as a data type would require several changes to the message encoding rules, and adding sub-sub-component delimiters, component and sub-component repeat delimiters. A much simpler approach is to migrate this data type to a pair of new segments. Subcommittee Findings: This proposal is nearly complete. Once the full Orders Working Group reviews and approves the proposal, it will be complete. Issues: Need to incorporate examples of usage. Usage of the TQ1/TQ2: TQ1 and TQ2 would form a repeating segment group within a message. The group would be in the form: [{ TQ1 [{ TQ2 }] }] October 2001 O&O Minutes Page 24 Tying TQ1/TQ2 to Version 3.0: The TQ1/TQ2 grouping has similarities to the Service/Service Relationship classes in version 3.0. The TQ1 segment is used to define timing/quantity information about the order (service) it is associated. The TQ2 segment is used to define the relationship between the order (service), and a separate order (service). Adopting this type of segment group in orders gives us a bridge between 2.x orders and the version 3.0 Act paradigms. Suggested Solution: 4.3 Quantity/Timing (TQ) Data Type Definition The TQ data type has a number of “features” that break the HL7 message encoding rules as given in chapter 2. To correct these problems, and retain the TQ as a data type would require several changes to the message encoding rules, and adding sub-sub-component delimiters, component and sub-component repeat delimiters. A much simpler approach is to migrate this data type to a pair of new segments (TQ1, and TQ2). See sections 4.4 and 4.5 for more details on the TQ1 and TQ2 segments. The TQ data type is maintained strictly for backward compatibility and may not be used for the definition of new fields. 4.4.3 OSQ/OSR- query response for order status (event Q06) OSR^Q06 Order Status Response MSH MSA [ERR] [{NTE}] QRD [QRF] [ [PID [{NTE}] ] { ORC [{ TQ1 [{TQ2}] }] <OBR|RQD|RQ1| RXO|ODS|ODT> [{NTE}] [{CTI}] } ] [DSC] Message Header Message Acknowledgment Error Notes and Comments (for Header) Query Definition Query Filter Chapter 2 2 2 2 2 2 Patient Identification Notes and Comments (for Patient ID) 3 2 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group [Order Detail Segment] OBR, etc. 4 Notes and Comments (for Detail) Clinical Trial Identification 2 7 Continuation Pointer 2 4 4 4 4.4.4 OMG - general clinical order message (event O19) OMG^O19^OMG_O19 General Clinical Order Message MSH [{NTE}] [ PID [PD1] [{NTE}] [ PV1 [PV2] ] Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) 3 3 2 Patient Visit Patient Visit- Additional Info 3 3 October 2001 O&O Minutes Chapter Page 25 OMG^O19^OMG_O19 General Clinical Order Message Chapter [{IN1 [IN2] [IN3] }] [GT1] [{AL1}] Insurance Insurance Additional Info Insurance Add’l Info - Cert. 6 6 6 Guarantor Allergy Information 6 3 ORC [{ TQ1 [{TQ2}] }] OBR [{NTE}] [CTD] [{DG1}] [{ OBX [{NTE}] }] {[ [PID [PD1]] [PV1 [PV2]] [AL1] { [ORC] OBR {[NTE]} [{ TQ1 [{TQ2}] }] [CTD] { OBX [{NTE}] } } }] [{FT1}] [{CTI}] [BLG] } Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Observation Notes and Comments (for Detail) Contact Data Diagnosis 4 ] { 4 4 4 2 11 6 Observation/Result Notes and Comments (for Results) Patient Identification Additional Demographics Patient Visit Patient Visit Add. Info Allergy Information previous previous previous previous previous result result result result result 3 3 3 3 3 Common Order - previous Order Detail - previous Notes and Comments - previous Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Contact Data - previous result result result 4 4 2 Observation/Result Notes and Comments – – – – - 7 2 4 4 result 10 - previous result - previous result 7 2 Financial Transaction Clinical Trial Identification Billing Segment 6 7 4 4.4.5 ORG - general clinical order acknowledgement message (event O20) ORG^O20^ORG_O20 General Clinical Order Acknowledgment Message MSH MSA [ERR] [{NTE}] [ [PID [{NTE}] ] { ORC [{ TQ1 [{TQ2}] }] [OBR] [{NTE}] Message Header Message Acknowledgment Error Notes and Comments (for Header) 2 2 2 2 Patient Identification Notes and Comments (for Patient ID) 3 2 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Observation Notes and Comments (for Detail) 4 October 2001 O&O Minutes Chapter 4 4 4 2 Page 26 ORG^O20^ORG_O20 [{CTI}] General Clinical Order Acknowledgment Message Chapter Clinical Trial Identification 7 } ] 4.4.6 OML - laboratory order message (event O21) OML^O21^OML_O21 Laboratory Order Message MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] [{IN1 [IN2] [IN3] }] [GT1] [{AL1}] ] { [ SAC [{OBX}] ] { ORC [{ TQ1 [{TQ2}] }] [ OBR [{ SAC [{OBX}] }] [TCD] [{NTE}] [{DG1}] [{ OBX [TCD] [{NTE}] }] [{ [PID [PD1]] [PV1 [PV2]] [{AL1}] { [ORC] OBR {[NTE]} [{ TQ1 [{TQ2}] }] { OBX [{NTE}] } } }] ] Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit- Additional Info Insurance Insurance Additional Info Insurance Add’l Info - Cert. 3 3 2 3 3 6 6 6 Guarantor Allergy Information 6 3 October 2001 O&O Minutes Chapter Specimen Container Details Additional Specimen Characteristics 13 7 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Observation Request 4 4 4 Specimen Container Details Additional Specimen Characteristics 13 7 Test Code Details Notes and Comments (for Detail) Diagnosis 13 2 6 Observation/Result Test Code Detail Notes and Comments (for Results) 7 13 2 Patient Identification Additional Demographics Patient Visit Patient Visit Add. Info Allergy Information – – – – - previous previous previous previous previous result result result result result 3 3 3 3 3 Common Order - previous result Order Detail - previous result Notes and Comments - previous result Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 4 2 Observation/Result Notes and Comments 7 2 - previous result - previous result 4 4 Page 27 OML^O21^OML_O21 Laboratory Order Message [{FT1}] [{CTI}] [BLG] Chapter Financial Transaction Clinical Trial Identification Billing Segment 6 7 4 } ] 4.4.7 ORL - general laboratory order response message to any OML (event O22) ORL^O22^ORL_O22 General Laboratory Order Acknowledgment Message MSH MSA [ERR] [{NTE}] [ [PID { [SAC [{OBX}] ] [{ ORC [{ TQ1 [{TQ2}] }] [OBR [{SAC}] ] }] } ] ] Message Header Message Acknowledgment Error Notes and Comments (for Header) 2 2 2 2 Patient Identification 3 4.5 Specimen Container Details Additional Specimen Characteristics Chapter 13 7 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Observation Request Specimen Container Details 4 4 4 4 13 General segments 4.5.1 ORC - common order segment HL7 Attribute Table – ORC – Common Order SEQ LEN DT OPT RP/# 7 200 TQ B Y 4.5.1.7 TBL# ITEM# ELEMENT NAME 00221 Quantity/Timing ORC-7 Quantity/timing (TQ) 00221 Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration (ST) > ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ST) (ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction ((ST) (ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total occurrences (NM)> Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively. This field determines the priority, quantity, frequency, and timing of an atomic service. Order segments should be thought of as describing an atomic service. It is a composite field that is defined in detail in Section 4.3, “Quantity/Timing (TQ) Definition.” October 2001 O&O Minutes Page 28 For example, if an OBR segment describes a unit of blood, this field might request that three (3) such units be given on successive mornings. In this case ORC-7-quantity/timing would be “1^QAM^X3”. ORC-7quantity/timing is the same as OBR-27-quantity/timing. To send information about “collection time”, use the ‘text’ component of the TQ data type in either the ORC-7 or OBR-27. ORC-7-quantity/timing is the same as OBR-27-quantity/timing. If the ORC-7 and OBR-27 are both valued, then both should be valued exactly the same. If the quantity/timing is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments. 4.5.3 OBR - observation request segment HL7 Attribute Table – OBR – Observation Request SEQ LEN DT OPT RP/# 27 200 TQ B Y 4.5.3.27 TBL# ITEM # ELEMENT NAME 00221 Quantity/Timing OBR-27 Quantity/timing (TQ) 00221 Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total occurrences(NM)> Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively. This field contains information about how many services to perform at one service time and how often the service times are repeated, and to fix duration of the request. See Section 4.3, “Quantity/Timing (TQ) Data Type D.” 4.5.4 TQ1 – Timing/Quantity Segment The TQ1 segment is used to specify the complex timing of events and actions such as those that occur in order management and scheduling systems. This segment determines the quantity, frequency, priority, and timing of a service. By allowing the segment to repeat, it is possible to have service requests that vary the quantity, frequency and priority of a service request over time. Use cases showing when TQ1 may need to repeat: Cardiac enzymes STAT and then q 4 hours Streptokinase studies, draw 1st Stat and run Stat, then draw q 4 hours and run Stat Gentamicin 100mg Now and 80mg q12h second dose ( First 80mg dose) given exactly 12 hours after the 100mg dose. (Might be 2 service requests) Activase 15mg bolus Stat then 50mg over 30 minutes, then 35mg over the next 60 minutes. (Might be 2 service requests) October 2001 O&O Minutes Page 29 Imodium 4mg (2 caps) po initially, then 2mg (1cap) after each unformed stool to a maximum of 16 mg per day. (Might be 2 service requests) Zithromax 500mg (2tabs) PO on the first day then 250mg (1tab) po qd for 5 days. (Might be 2 service requests) Zyban (Bupropion) Start 150mg po qam x 3 days, then increase to 150mg po bid for 7 to 12 weeks. Colchicine 1mg (2 tabs) po now then 1 tablet q1 to 2 hours until pain relief or undesirable side effects (Diarrhea, GI upset) (Might be 2 service requests) doxycylcine 100mg po bid on the first day then 100mg po qd. scopolamine, xxx mg, 1 hour before surgery. Relative time = -1^hour, priority = P (preop). or alternately repeat pattern = P1H^Preop, 1 Hour before Surgery^99LocalCode, Relative time would be empty and priority would be P (preop). HL7 Attribute Table - TQ1 SEQ LEN DT OPT RP/# 1 2 3 4 5 6 7 8 9 10 11 12 13 14 4 20 540 20 20 20 26 26 250 250 250 10 20 10 SI CQ RPT TM CQ CQ TS TS CWE TX TX ID CQ NM O O O O O O O O O O O C O O N N Y Y Y N N N Y N N N N N TBL# ITEM# ELEMENT NAME Set ID - TQ1 Quantity Repeat Pattern Explicit Time Relative Time and units Service Duration Start date/time End date/time Priority Condition text Text instruction Conjunction Occurrence duration Total occurrence's 4.5.4.0 TQ1 field definitions 4.5.4.1 Set ID - TQ1 Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on. 4.5.4.2 Quantity (CQ) Definition: This field specifies the numeric quantity of the service that should be provided at each service interval. For example, if two blood cultures are to be obtained every 4 hours, the quantity would be 2 or if three units of blood are to be typed and cross-matched, the quantity would be 3. The default value for this field is 1. If multiple identical services are to be requested, it is strongly recommended that multiple service requests be placed; giving each service request it’s own unique placer/filler number. 4.5.4.3 Repeat pattern (RPT) (See RPT data type proposal) Definition: The repeating frequency with which the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems. This field may be repeated to build up more complex repeat patterns. When the quantity timing specification must change to a different repeat pattern after some period of time, a new TQ1 segment must October 2001 Page 30 O&O Minutes be used to show the new repeat pattern. Note that the end date of the current TQ1 will show when the current timing specification ends, and the start date of the next TQ1 shows when the new timing specification begins. The Conjunction field, TQ1-12 determines if the next TQ1 segment is to be performed sequentially or in parallel. Note: The following table defines possible ranges of coded values for this field. The table is not intended to imply that these codes are to be parsed to derive the meaning of the code. User-defined Table 0335 - Repeat pattern Value Description Q<integer>S every <integer> seconds Q<integer>M every <integer> minutes Q<integer>H every <integer> hours Q<integer>D every <integer> days Q<integer>W every <integer> weeks Q<integer>L every <integer> months (Lunar cycle) Q<integer>J<day#> repeats on a particular day of the week, from the French jour (day). If <integer> is missing, the repeat rate is assumed to be 1. Day numbers are counted from 1=Monday to 7=Sunday. So Q2J2 means every second Tuesday; Q1J6 means every Saturday. BID twice a day at institution-specified times (e.g., 9AM-4PM) TID three times a day at institution-specified times (e.g., 9AM-4PM-9PM) QID four times a day at institution-specified times (e.g., 9AM-11AM-4PM-9PM) XID “X” times per day at institution-specified times, where X is a numeral 5 or greater. E.g., 5ID=five times per day; 8ID=8 times per day QAM in the morning at institution-specified time QSHIFT during each of three eight-hour shifts at institutionspecified times QOD every other day (same as Q2D) QHS every day before the hour of sleep QPM in the evening at institution-specified time C service is provided continuously between start time and stop time U <spec> for future use, where <spec> is an interval specification as defined by the UNIX cron specification. PRN given as needed PRNxxx where xxx is some frequency code (e.g., PRNQ6H); given as needed over the frequency period. October 2001 O&O Minutes Comment Note: None of the above three specifications are equivalent to their Q<integer>H counterpart. QID is not Q6H. The former is unequally spaced; the latter is equally spaced. Page 31 Once one time only. This is also the default when this field is null. Meal Related Timings <timing>C (“cum”)<meal> A Ante (before) P Post (after) I Inter (e.g., between this meal and the next, between dinner and sleep M Cibus Matutinus (breakfast) D Cibus Diurnus (lunch) V Cibus Vespertinus (dinner) AC before meal (from lat. ante cibus) PC after meal (from lat. post cibus) IC between meals (from lat. inter cibus) ACM before breakfast (from lat. ante cibus matutinus) ACD before lunch (from lat. ante cibus diurnus) ACV before dinner (from lat. ante cibus vespertinus) PCM after breakfast (from lat. post cibus matutinus) PCD after lunch (from lat. post cibus diurnus) PCV after dinner (from lat. post cibus vespertinus) ICM between breakfast and lunch ICD between lunch and dinner ICV between dinner and the hour of sleep 4.5.4.4 Deprecated in v 2.5; retained for backward compatibility only. Deprecated in v 2.5; retained for backward compatibility only. Deprecated in v 2.5; retained for backward compatibility only. Deprecated in v 2.5; retained for backward compatibility only. Deprecated in v 2.5; retained for backward compatibility only. Deprecated in v 2.5; retained for backward compatibility only. Deprecated in v 2.5; retained for backward compatibility only. Explicit time (TM) Definition: This field explicitly lists the actual times referenced by the code in TQ1-3. This field will be used to clarify the TQ1-3 in cases where the actual administration times vary within an institution. If the time of the service request spans more than a single day, this field is only practical if the same times of administration occur for each day of the service request. If the actual start time of the service request (as given by TQ1-7 ) is after the first explicit time, the first administration is taken to be the first explicit time after the start time. In the case where the patient moves to a location having a different set of explicit times, the existing service request may be updated with a new quantity/timing segment showing the changed explicit times. Usage Note: This field is not valued if a Repeat Pattern is not present. 4.5.4.5 Relative time and units (CQ) Components: <quantity (NM)> ^ <units (CE)> Note: In future versions, CQ fields should be avoided because the same data can usually be sent as two separate fields, one with the value and one with the units as a CE data type. Definition: This field is used to define the interval between schedules for service request or bottle records. If this field contains a value, it overrides any value in the explicit time interval field. The units component of the CQ data type is constrained to units of time. Examples: Q6H||60^M Q6H||6^H QD||1^D October 2001 O&O Minutes Page 32 4.5.4.6 Service Duration (CQ) Definition: This field contains the duration for which the service is requested. The quantity component of this field must be a positive, non-zero number. The unit's portion of this field is constrained to units of time. 4.5.4.7 Start date/time (TS) Definition: This field may be specified by the requester, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start date/time will be implied or will be defined by other fields in the service request record (e.g., urgency - STAT). In such a case, this field will be empty. The filling service will often record a value in this field after receipt of the service request, however, and compute an end time on the basis of the start date/time for the filling service’s internal use. 4.5.4.8 End date/time (TS) Definition: When filled in by the requester of the service, this field should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time. Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time. 4.5.4.9 Priority (CWE) Definition: This field describes the urgency of the request. If this field is blank, the default is R. The following values are suggested. The following User defined table may be used for this field. User Defined Table xxx - Priority Value Short Text Description S Stat With highest priority A ASAP Fill after S orders R Routine Default P Preop C Callback T Timing critical A request implying that it is critical to come as close as possible to the requested time, e.g., for a trough anti-microbial level. TS<integer> Timing critical within <integer> seconds. TM<integer> Timing critical within <integer> minutes. TH<integer> Timing critical within <integer> hours. TD<integer> Timing critical within <integer> days. TW<integer> Timing critical within <integer> weeks. TL<integer> PRN 4.5.4.10 Timing critical within <integer> months. As needed Condition text (ST) Definition: This is a free text field that describes the conditions under which the drug is to be given. For example, PRN pain, or to keep blood pressure below 110. October 2001 O&O Minutes Page 33 The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given. For complex codified conditions see the TQ2 segment below. 4.5.4.11 Text Instruction (ST) Definition: This field is a full text version of the instruction (optional). 4.5.4.12 Conjunction (ID): Definition: This field indicates that a second TQ1 segment is to follow. This field can take values from HL7 table 0472. HL7 table 0472 - TQ Conjunction ID Value Description S Synchronous - Do the next specification after this one (unless otherwise constrained by the following fields: TQ1-7-start date/time and TQ1-8-end date/time). An “S” specification implies that the second timing sequence follows the first, e.g., when an service request is written to measure blood pressure Q15 minutes for the 1st hour, then every 2 hours for the next day. A Asynchronous - Do the next specification in parallel with this one (unless otherwise constrained by the following fields: TQ1-7-start date/time and TQ1-8-end date/time). The conjunction of “A” specifies two parallel instructions, as are sometimes used in medication, e.g., prednisone given at 1 tab on Monday, Wednesday, Friday, and at 1/2 tab on Tuesday, Thursday, Saturday, Sunday. C Actuation Time - It will be followed by a completion time for the service. This code allows one to distinguish between the time and priority at which a service should be actuated (e.g., blood should be drawn) and the time and priority at which a service should be completed (e.g., results should be reported). For continuous or periodic services, the point at which the service is actually stopped is determined by the field TQ1-8 end date/time and TQ1-6 duration, whichever indicates an earlier stopping time. Ordinarily, only one of these fields would be present. Condition Rule: If the TQ1 segment is repeated in the message, this field must be populated with the appropriate Conjunction code indicating the sequencing of the following TQ1 segment. 4.5.4.13 Occurrence duration (CQ) Definition: This field contains the duration for which a single performance of a service is requested. The quantity component of this field must be a non-negative integer when populated. The units component is constrained to be units of time. Example: Whirlpool twenty minutes three times per day for three days. Twenty minutes is the occurrence duration. October 2001 O&O Minutes Page 34 4.5.4.14 Total occurrences (NM) Definition: This field contains the total number of occurrences of a service that should result from this service request. If both the end date/time (TQ1-8) and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence. 4.5.5 TQ2 – Timing/Quantity Relationship The TQ2 segment is used to form a relationship between the service request the TQ1/TQ2 segments are associated with, and other service requests. The TQ2 segment will link the current service request with one or more other service requests. There are many situations, such as the creation of an service request 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 service request’s instructions contains a results condition of some type, such as “PRN pain.” There is currently a free text “condition” field of TQ1-10 (Condition text) which allows any condition to be specified. However, to support a fully encoded version of service request sequencing, or results condition, the TQ2, Timing/Quantity Relationship segment has been defined. HL7 Attribute Table - TQ2 SEQ LEN DT OPT RP/# 1 2 3 4 5 6 7 8 9 10 4 1 22 22 22 2 1 20 10 1 SI ID EI EI EI ID ID CQ NM ID O O C C C C C O O C N N Y Y Y N N N N N TBL# ??? ??? ??? ITEM# ELEMENT NAME Set ID - TQ2 Sequence/Results Flag Related Placer number Related Filler number Related Placer group number Sequence condition code Cyclic Entry/Exit Indicator Sequence condition time interval Cyclic group maximum number of repeats Special service request relationship TQ2 Usage notes a) Cyclic placer service request groups To implement a cyclic group of four IV service requests using the parent/child paradigm, the parent specifies a custom group of IVs, and the following occurs: TQ2 of the second child service request specifies that it follow the first child service request. TQ2 of the third child service request specifies that it follow the second child service request. TQ2 of the fourth child service request specifies that it follow the third service request. To repeat the group of four child service requests in a cyclic manner, the following occurs: October 2001 O&O Minutes TQ2 of the first child service request specifies that it is to be executed once without any dependence on the completion of other service requests. Its second execution follows the completion of the fourth service request. See example in Section 4.15.2, “RXO segment field examples. Page 35 This scheme allows the following to be tracked: The status of the whole group of service requests to be reported back at the level of the parent service request. The status for each individual IV service request by following the status of the corresponding child service request. Separate Service requests example: b) The same group of service requests can be sent as a group of four service requests (without a common parent), linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7 method of transmitting the service request status of the group as a whole without transmitting the status of each of the four separate service requests. Inheritance of service request status Cancellation/discontinuation/hold service request control events: This logic implies the normal execution of the referenced predecessor service request. Thus a cancel (or discontinuation or hold) of a predecessor service request implies the cancellation (or discontinuation or hold) of all subsequent service requests in the chain. If the referenced service request has been canceled (or discontinued or held), the current service request inherits that same status. In the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given service request (which can then be executed according to the specification in the TQ2 segment). 4.5.5.0 TQ2 field definitions 4.5.5.1 Set ID – TQ2 (SI) Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on. 4.5.5.2 Sequence/Results Flag (ID) Definition: This flag defines the sequencing relationship between the current service request, and the related service request(s) specified in this TQ2 segment. See HL7 table ??? for values. If not value is present, the S - Sequential is the default value. HL7 defined table ??? Value October 2001 O&O Minutes Description S Sequential C Cyclical - The C will be used for indicating a repeating cycle of service requests; for example, individual intravenous solutions used in a cyclical sequence (a.k.a. “Alternating IVs”). This value would be compatible with linking separate service requests or with having all cyclical service request components in a single service request. Likewise, the value would be compatible with either Parent-Child messages or a single service request message to communicate the service requests’ sequencing. R Reserved for future use Page 36 4.5.5.3 Related Placer number (EI) Definition: The placer numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Placer number " from the current service request. For orders, the Placer Order Number from ORC-2 is the appropriate "Placer number". Repeats of this field indicates the current service request is related to multiple service requests. Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value. 4.5.5.4 Related Filler number (EI) Definition: The filler numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Filler number " from the current service request. For orders, the Filler Order Number from ORC-3 is the appropriate "Filler number". Repeats of this field indicates the current service request is related to multiple service requests. Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value. 4.5.5.5 Related Placer group number (EI) Definition: The placer group numbers of the service request(s) to which this TQ2 segment links the current service request. . This field should be populated with the appropriate "Placer group number " from the current service request. For orders, the Placer Group Number from ORC-4 is the appropriate "Placer group number". Repeats of this field indicates that the current service request is related to multiple groups of service requests. Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value. 4.5.5.6 Sequence Condition Code (ID) Definition: Defines the relationship between the start/end of the related service request(s) (from TQ2-3, TQ2-4, or TQ2-5) and the current service request from ORC-2,3 or 4. See HL7 defined table ??? for allowed values. Conditional Rule: Either this field or TQ2-??? must be present. HL7 defined table ???? Value Description EE End related service request(s), end current service request. ES End related service request(s), start current service request. SS Start related service request(s), start current service request. SE Start related service request(s), end current service request. 4.5.5.7 Cyclic Entry/Exit Indicator (ID) Definition: Indicates if this service request is the first, last, service request in a cyclic series of service requests. If null or not present, this field indicates that the current service request is neither the first or last service request in a cyclic series of service requests. Usage note: Should not be populated when TQ2-2 (Sequence/Results Flag) is not equal to a 'C' (cyclic service request). HL7 defined table ???? Value Description * The first service request in a cyclic group # The last service request in a cyclic group. October 2001 O&O Minutes Page 37 Example of TQ2 - 6, 7, & 8 Usage: ...|ES|*|+10^min|... translates to: execute this service request the first time without evaluating the condition specified in the TQ2 segment; but repeat only its execution when the specified external service request’s start or finish date/time has met this condition. This specification generates a repetition of the service request for each iteration of the cycle. Note: This requires that the requesting application be able to specify the placer/filler/placer group number of the last service request in the cycle in the first service request’s quantity/timing specification. 4.5.5.8 Sequence condition time interval (CQ) Definition: Defines the interval of time between the start/end of the related service request(s) and the start/end of the current service request. The unit's component is constrained to units of time. If this field is not populated, then there should be no interruption between start/ending the current service request, and the related service request(s). 4.5.5.9 Cyclic group maximum number of repeats (NM) Definition: The maximum number of repeats to be used only on cyclic groups. The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first. 4.5.5.10 Special service request relationship (ID) Definition: This defines an additional or alternate relationship between this service request and other service requests. It's primary intended use for Pharmacy administration service requests, but it may be useful for other domains. See HL7 Table ?? for allowed values. Conditional Rule: Either this field or TQ2-6 must be present. HL7 defined table ??? Value October 2001 O&O Minutes Description N Nurse prerogative - RN Prerogative order. I've seen it ordered so that the nurse can chose between 3 or 4 different items, depending on which the patient can tolerate at the moment. Another example would be:Milk of Magnesia PO 30 ml qhs (at bedtime)/Dulcolax Supp R @ hs prn /Colace 100 mg capsule PO bid The nurse may be giving the Colace twice daily as a stool softener, but may also give the Dulcolax Supp along with it if Colace is not producing any "results". For example give order 1 and order 2 or order 3. This can be extended to more than three orders. The old TQ did not handle this many to many scenario. C Compound - A compound is an extempo order which may be made up of multiple drugs. For example, many hospitals have a standard item called "Magic Mouthwash". The item is ordered that way by the physician. The extempo items will contain multiple products, such as Maalox, Benadryl, Xylocaine, etc. They will all be mixed together and will be dispensed in a single container. T Tapering - A tapering order is one in which the same drug is used, but it has a declining dosage over a number of days. For example, Decadron 0.5 mg is often ordered this way. The order would look like this: Decadron 0.5 mg qid (four times a day) for 2 days, then Decadron 0.5 mg tid (three times a day) for 2 days, then Decadron 0.5 mg bid (twice a day) for 2 days, then Decadron 0.5 mg qd (daily) for 2 days, then stop. E Exclusive - An exclusive order is an order where only one of the multiple items Page 38 should be administered at any one dosage time. The nurse may chose between the alternatives, but should only give ONE of them. An example would be: Phenergan 25 mg PO, IM or R q6h prn (orally, intramuscularly, or rectally every 6 hours as needed). S Simultaneous - A simultaneous order is 2 or more drugs which are ordered to be given at the same time. A common example of this would be Demerol and Phenergan (Phenergan is given with the Demerol to control the nausea that Demerol can cause). The order could be:Demerol 50 mg IM with Phenergan 25 mg IM q4h prn (every 4 hours as needed). 4.7.1 OMD - dietary order (event O03) OMD^O03^OMD_O03 Dietary Order MSH [{NTE}] [ PID [PD1] [{NTE}] [ PV1 [PV2] ] [{ IN1 [IN2] [IN3] }] [GT1] [{AL1}] ] { ORC [{ TQ1 [{TQ2}] }] [ {ODS} [{NTE}] [{ OBX [{NTE}] }] ] } { [ ORC [{ TQ1 [{TQ2}] }] {ODT} [{NTE}] ] } Message Header Notes and Comments (for Header) Chapter 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) 3 3 2 Patient Visit Patient Visit - Additional Info 3 3 Insurance Insurance Additional Info Insurance Add’l Info - Cert. 6 6 6 Guarantor Allergy Information 6 3 Common Order Segment Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Dietary Orders, Suppl., Prefer. Notes and Comments (for ODS) 4 2 Results Notes and Comments (for OBX) 7 2 Common Order Segment Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Diet Tray Instructions Notes and Comments (for ODT) 4 4 4 4 4 4 2 4.7.2 ORD - dietary order acknowledgment (event O04) ORD^O04^ORD_O04 Dietary Order Acknowledgment Message MSH MSA [ERR] [{NTE}] [ Message Header Message Acknowledgment Error Notes and Comments (for MSA) October 2001 O&O Minutes Chapter 2 2 2 2 Page 39 [ PID [{NTE}] Patient Identification Notes and Comments (for Patient ID) 3 2 ORC [{ TQ1 [{TQ2}] }] [{ODS}] [{NTE}] Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Dietary Orders, Supplements, and Preferences Notes and Comments (for ODS) 4 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Diet Tray Instructions Notes and Comments (for ODT) 4 ] { 4 4 4 2 } [{ ORC [{ TQ1 [{TQ2}] }] [{ODT}] [{NTE}] 4 4 4 2 ]} ] 4.10.1 OMS - stock requisition order message (event O05) OMS^O05^OMS_O05 Stock Requisition Order Message MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] [{IN1 [IN2] [IN3] }] [GT1] [{AL1}] ] { ORC [{ TQ1 [{TQ2}] }] RQD [RQ1] [{NTE}] [ { OBX [{NTE}] } ] [BLG] } Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit - Additional Info Insurance Insurance Additional Info Insurance Add’l Info - Cert. 3 3 2 3 3 6 6 6 Guarantor Allergy Information 6 3 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Requisition Detail Requisition Detail-1 Notes and Comments (for RQD) 4 Observation/Result Notes and Comments (for OBX) 7 2 Billing Segment 4 4.10.2 4 4 4 4 2 ORS - stock requisition order acknowledgment message (event O06) ORS^O06^ORS_O06 Stock Order Acknowledgment Message MSH MSA [ERR] [{NTE}] [ Message Header Message Acknowledgment Error Notes and Comments (for Header) October 2001 O&O Minutes Chapter Chapter 2 2 2 2 Page 40 [PID [{NTE}] ] Patient Identification Notes and Comments (for Patient ID) 3 2 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Requisition Detail Requisition Detail-1 Notes and Comments (for RQD) 4 { ORC [{ TQ1 [{TQ2}] }] RQD [RQ1] [{NTE}] 4 4 4 4 2 } ] 4.10.3 OMN - non-stock requisition order message (event O07) OMN^O07^OMN_O07 Nonstock Requisition Order Message MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] [{IN1 [IN2] [IN3] }] [GT1] [{AL1}] ] { ORC [{ TQ1 [{TQ2}] }] RQD [RQ1] [{NTE}] [ { OBX [{NTE}] } ] [BLG] } Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit - Additional Info Insurance Insurance Additional Info Insurance Add’l Info - Cert. 3 3 2 3 3 6 6 6 Guarantor Allergy Information 6 3 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Requisition Detail Requisition Detail-1 Notes and Comments (for RQD) 4 Observation/Result Notes and Comments (for OBX) 7 2 Billing Segment 4 4.10.4 Chapter 4 4 4 4 2 ORN - non-stock requisition order acknowledgment message (event O08) ORN^O08^ORN_O08 General Order Acknowledgment Message MSH MSA [ERR] [{NTE}] [ [PID [{NTE}] ] { ORC [{ TQ1 [{TQ2}] }] Message Header Message Acknowledgment Error Notes and Comments (for Header) 2 2 2 2 Patient Identification Notes and Comments (for Patient ID) 3 2 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 October 2001 O&O Minutes Chapter 4 4 Page 41 RQD [RQ1] [{NTE}] Requisition Detail Requisition Detail-1 Notes and Comments (for RQD) 4 4 2 } ] 4.13.3 OMP - pharmacy/treatment order message (event O09) OMP^O09^OMP_O09 Pharmacy/treatment Order Message MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] [{IN1 [IN2] [IN3] }] [GT1] [{AL1}] ] { ORC [{ TQ1 [{TQ2}] }] RXO [{NTE}] {RXR} [ {RXC} [{NTE}] ] [ { OBX [{NTE}] } ] [{FT1}] [BLG] } Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit - Additional Info Insurance Insurance Additional Info Insurance Add’l Info - Cert. 3 3 2 3 3 6 6 6 Guarantor Allergy Information 6 3 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Pharmacy/Treatment Order Notes and Comments (for RXO) Pharmacy/Treatment Route 4 Pharmacy/Treatment Component Notes and Comments (for RXC) 4 2 Observation/Result Notes and Comments (for OBX) 7 2 Financial Transaction Billing Segment 6 6 4.13.4 Chapter 4 4 4 2 4 ORP - pharmacy/treatment order acknowledgment (event O10) ORP^O10^ORP_O10 Description MSH MSA [ERR] [{NTE}] [ [PID [{NTE}] ] { ORC [{ TQ1 [{TQ2}] }] [ RXO [{NTE}] {RXR} Message Header Message Acknowledgment Error Notes and Comments (for Response Header) 2 2 2 2 Patient Identification Notes and Comments (for Patient ID) 3 2 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy/Treatment Order Notes and Comments (for RXO) Pharmacy/Treatment Route 4 2 4 October 2001 O&O Minutes Chapter 4 4 Page 42 [{RXC}] [{NTE}] Pharmacy/Treatment Component Notes and Comments (for RXC) 4 2 ] } ] 4.13.5 RDE - pharmacy/treatment encoded order message (event O11) RDE^O11^RDE_O11 Pharmacy/Treatment Encoded Order Message MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] [{IN1 [IN2] [IN3] }] [GT1] [{AL1}] ] { ORC [{ TQ1 [{TQ2}] }] [ RXO [{NTE}] {RXR} [ {RXC} [{NTE}] ] ] RXE { TQ1 [{TQ2}] } {RXR} [{RXC}] [{ OBX [{NTE}] }] {[CTI]} } Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit - Additional Info Insurance Insurance Additional Info Insurance Add’l Info - Cert. 3 3 2 3 3 Guarantor Allergy Information 6 3 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy/Treatment Prescription Order Notes and Comments (for RXO) Pharmacy/Treatment Route 4 2 4 Pharmacy/Treatment Component (for RXO) Notes and Comments (for RXC) 4 2 Pharmacy/Treatment Encoded Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Pharmacy/Treatment Route Pharmacy/Treatment Component (for RXE) 4 Results Notes and Comments (for OBX) 7 2 4.13.6 Clinical Trial Identification Chapter 6 6 4 4 4 4 4 4 7 RRE - pharmacy/treatment encoded order acknowledgment (event O12) RRE^O12^RRE_O12 Pharmacy/Treatment Encoded Order Acknowledgment Message MSH MSA [ERR] [{NTE}] [ [PID [{NTE}] ] { Message Header Message Acknowledgment Error Notes and Comments (for Header) 2 2 2 2 Patient Identification Notes and Comments (for PID) 3 2 October 2001 O&O Minutes Chapter Page 43 ORC [{ TQ1 [{TQ2}] }] [ RXE { TQ1 [{TQ2}] } {RXR} [{RXC}] ] Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy/Treatment Encoded Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Pharmacy/Treatment Route Pharmacy/Treatment Component 4 4 4 4 4 4 4 } ] 4.13.7 RDS - pharmacy/treatment dispense message (event O13) RDS^O13^RDS_O13 Pharmacy/Treatment Dispense Message MSH [{NTE}] [ PID [PD1] [{NTE}] [{AL1}] [ PV1 [PV2] ] ] { ORC [{ TQ1 [{TQ2}] }] [ RXO [ {NTE} {RXR} [ {RXC} [{NTE}] ] ] ] [ RXE { TQ1 [{TQ2}] } {RXR} [{RXC}] ] RXD {RXR} [{RXC}] [{ OBX [{NTE}] }] [{FT1}] } Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for PID) Allergy Information 3 3 2 2 Patient Visit Patient Visit - Additional Info 3 3 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy /Treatment Order 4 Notes and Comments (for RXO) Pharmacy/Treatment Route 2 4 Pharmacy/Treatment Component Notes and Comments (for RXC) 4 2 Pharmacy/Treatment Encoded Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Pharmacy/Treatment Route Pharmacy/Treatment Component 4 Pharmacy/Treatment Dispense Pharmacy/Treatment Route Pharmacy/Treatment Component 4 4 4 Results Notes and Comments (for OBX) 7 2 Financial Transaction segment 6 October 2001 O&O Minutes Chapter 4 4 4 4 4 4 Page 44 4.13.8 RRD - pharmacy/treatment dispense acknowledgement message (event O14) RRD^O14^RRD_O14 Pharmacy/Treatment Dispense Acknowledgment Message MSH MSA [ERR] [{NTE}] [ [PID [{NTE}] ] { ORC [{ TQ1 [{TQ2}] }] [ RXD {RXR} [{RXC}] ] } ] Message Header Message Acknowledgment Error Notes and Comments (for Header) 2 2 2 2 Patient Identification Notes and Comments (for Patient ID) 3 2 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy/Treatment Dispense Pharmacy/Treatment Route Pharmacy/Treatment Component 4 4 4 4.13.9 Chapter 4 4 RGV - pharmacy/treatment give message (event O15) RGV^O15^RGV_O15 Pharmacy/Treatment Give MSH [{NTE}] [ PID [{NTE}] [{AL1}] [PV1 [PV2]] ] { ORC [{ TQ1 [{TQ2}] }] [ RXO [ {NTE} {RXR} [ {RXC} [{NTE}] ] ] ] [ RXE { TQ1 [{TQ2}] } {RXR} [{RXC}] ] { RXG { TQ1 [{TQ2}] } {RXR} Message Header Notes and Comments (for Header) 2 2 Patient Identification Notes and Comments (for PID) Allergy Information Patient Visit Patient Visit - Additional Info 3 2 2 3 3 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy /Treatment Order 4 Notes and Comments (for RXO) Pharmacy/Treatment Route 2 4 Pharmacy/Treatment Component Notes and Comments (for RXC) 4 2 Pharmacy/Treatment Encoded Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Pharmacy/Treatment Route Pharmacy/Treatment Component 4 Pharmacy/Treatment Give Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Pharmacy/Treatment Route 4 October 2001 O&O Minutes Chapter 4 4 4 4 4 4 4 4 4 Page 45 [{RXC}] { [OBX] [{NTE}] } Pharmacy/Treatment Component 4 Observation/Results Notes and Comments (for OBX) 7 2 } } 4.13.10 RRG - pharmacy/treatment give acknowledgment message (event O16) RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgment Message MSH MSA [ERR] [{NTE}] [ [PID [{NTE}]] { ORC [{ TQ1 [{TQ2}] }] [ RXG { TQ1 [{TQ2}] } {RXR} [{RXC}] ] } ] Message Header Message Acknowledgment Error Notes and Comments (for Header) 2 2 2 2 Patient Identification Notes and Comments (for PID) 3 2 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy/Treatment Give Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Pharmacy/Treatment Route Pharmacy/Treatment Component 4 4.13.11 Chapter 4 4 4 4 4 4 RAS - pharmacy/treatment administration message (event O17) RAS^O17^RAS_O17 Pharmacy/Treatment Administration MSH [{NTE}] [ PID [PD1] [{NTE}] [{AL1}] [PV1 [PV2]] ] { ORC [{ TQ1 [{TQ2}] }] [ RXO [ {NTE} {RXR} [ {RXC} [{NTE}] ] ] Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for PID) Allergy Information Patient Visit Patient Visit - Additional Info 3 3 2 2 3 3 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy /Treatment Order 4 Notes and Comments (for RXO) Pharmacy/Treatment Route 2 4 Pharmacy/Treatment Component Notes and Comments (for RXC) 4 2 October 2001 O&O Minutes Chapter 4 4 Page 46 ] [ RXE { TQ1 [{TQ2}] } {RXR} [{RXC}] ] {{RXA} RXR {[OBX {[NTE]} ]}} {[CTI]} Pharmacy/Treatment Encoded Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Pharmacy/Treatment Route Pharmacy/Treatment Component 4 Pharmacy/Treatment Administration Pharmacy/Treatment Route Observation/Result Notes and Comments (for OBX) 4 4 7 2 Clinical Trial Identification 7 4 4 4 4 } 4.13.12 RRA - pharmacy/treatment administration acknowledgment message (event O18) RRA^O18^RRA_O18 Pharmacy/Treatment Administration Acknowledgment Message MSH MSA [ERR] [{NTE}] [ [PID [{NTE}]] { ORC [{ TQ1 [{TQ2}] }] [ {RXA} RXR ] } ] Message Header Message Acknowledgment Error Notes and Comments (for Header) 2 2 2 2 Patient Identification Notes and Comments (for PID) 3 2 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy/Treatment Administration Pharmacy/Treatment Route 4 4 4.14.4 Chapter 4 4 RXE - pharmacy/treatment encoded order segment HL7 Attribute Table – RXE – Pharmacy/Treatment Encoded Order SEQ LEN DT OPT 1 200 TQ B 4.14.4.1 RP/# TBL# ITEM # 00221 ELEMENT NAME Quantity/Timing RXE-1 Quantity/timing (TQ) 00221 Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total occurrences(NM)> Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively. See Section 4.14.4, “RXE - pharmacy/treatment encoded order segment,” for necessary modification for this field’s definition to cover interorder dependencies needed by pharmacy/treatment orders. This field is used by the pharmacy or non-pharmacy treatment supplier to express the fully-coded version of the drug or October 2001 O&O Minutes Page 47 treatment timing. It may differ from ORC-7-quantity/timing, which contains the requested quantity/timing of the original order. 4.14.6 RXG - pharmacy/treatment give segment HL7 Attribute Table – RXG – Pharmacy/Treatment Give SEQ LEN DT OPT 3 200 TQ B 4.14.6.3 RP/# TBL# ITEM # ELEMENT NAME 00221 Quantity/Timing RXG-3 Quantity/timing (TQ) 00221 Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total occurrences(NM)> Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively. This field contains the quantity/timing specification that refers to either a single scheduled give instruction only or to multiple give instructions. In the former case, RXG-1-give sub-ID counter is a positive integer greater than or equal to one (1). In the latter case, RXG-1-give sub-ID counter is zero (0). The quantity will always be 1. This quantity/timing field may differ from the ORC quantity/timing field, which contains the requested quantity/timing of the original order. Note: The contents of fields 3-8 should be identical to the comparable fields in the RXE (RXE-2 thru 5). 4.17.5 VXR - vaccination record response (event V03) VXR^V03 Vaccination Response MSH MSA QRD [QRF] PID [PD1] [{NK1}] [PV1 [PV2]] [{GT1}] [{IN1 [IN2] [IN3] }] [{ [ ORC [{ TQ1 [{TQ2}] }] ] RXA [RXR] [{OBX [{NTE}] }] }] Message Header Message Acknowledgment Query Definition Query Filter Patient Identification Additional Demographics Next of Kin/Associated Parties Patient Visit Patient Visit - Additional Info Guarantor Insurance Insurance Additional Info Insurance Add’l Info - Cert. 2 2 2 2 3 3 3 3 3 6 6 6 6 Common Order Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy Administration Pharmacy Route Observation/Result Notes (Regarding Immunization) 4 4 7 2 October 2001 O&O Minutes Chapter 4 4 Page 48 4.17.6 VXU - unsolicited vaccination record update (event V04) VXU^V04 Unsolicited Vaccination Update MSH PID [PD1] [{NK1}] [PV1 [PV2]] [{GT1}] [{IN1 [IN2] [IN3] }] [{ [ ORC [{ TQ1 [{TQ2}] }] ] RXA [RXR] {[ OBX [{NTE}] ]} }] Message Header Segment Patient Identification Segment Additional Demographics Next of Kin/Associated Parties Patient Visit Patient Visit - Additional Info Guarantor Insurance Insurance Additional Info Insurance Add’l Info - Cert. Chapter 2 3 3 3 3 3 6 6 6 6 Common Order Segment Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 Pharmacy Administration Segment Pharmacy Route Observation/Result Notes (Regarding Immunization) 4 4 7 2 4 4 7 7.3.1 ORU - unsolicited observation message (event R01) ORU^R01 Unsolicited Observation Message MSH { [ Message Header Chapter 2 PID [PD1] [{NK1}] [{NTE}] [ PV1 [PV2] ] Patient Identification Additional Demographics Next of Kin/Associated Parties Notes and Comments 3 3 3 2 Patient Visit Patient Visit - Additional Info 3 3 [ORC] OBR {[NTE]} [{ TQ1 [{TQ2}] }] [CTD] { [OBX] {[NTE]} } [{FT1}] {[CTI]} Order common Observations Report ID Notes and comments Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Contact Data 4 7 2 11 Observation/Result Notes and comments 7 2 Financial Transaction Clinical Trial Identification 6 7 Continuation Pointer 2 ] { } } [DSC] October 2001 O&O Minutes 4 4 Page 49 7.3.2 OUL - unsolicited laboratory observation message (R21) OUL^R21^OUL_R21 Unsolicited Laboratory Observation Message MSH [NTE] [ PID [PD1] [{NTE}] ] [ PV1 [PV2]] ] { [ SAC [SID] [{OBX}] ] [ORC] OBR [{NTE}] [{ TQ1 [{TQ2}] }] { [OBX] [TCD] {[SID]} [{NTE}] } [{CTI}] } [DSC] Message Header Notes and Comments 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) 3 3 2 Patient Visit Patient Visit – Additional Information 3 3 Specimen Container Details Substance Identifier Additional Specimen Characteristics 13 13 7 Common Order Observation Notes and Comments (for Detail) Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 7 2 Observation Result Test Code Detail Substance Identifier Notes and Comments 7 13 13 2 Clinical Trial Identification 7 Continuation Pointer 2 7.4 Chapter 4 4 Segments 7.4.1 OBR - observation request segment HL7 Attribute Table – OBR – Observation Request SEQ LEN DT OPT RP/# 27 200 TQ B Y 7.4.1.27 TBL# ITEM # ELEMENT NAME 00221 Quantity/Timing OBR-27 Quantity/timing (TQ) 00221 Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total occurrences(NM)> Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively. This field contains information about how many services to perform at one service time and how often the service times are repeated, and to fix duration of the request. See Section 4.3, “Quantity/Timing (TQ) Data Type D.” October 2001 O&O Minutes Page 50 7.7.2 CSU - unsolicited study data message (events C09-C12) CSU^C09-C12^CSU_C09 Unsolicited Study Data Message MSH MSA QRD [QRF] { [ PID [{NTE}] ] { [ORC] OBR {[NTE]} [{ TQ1 [{TQ2}] }] [CTD] { [OBX] {[NTE]} } {[CTI]} } } [ERR] [QAK] [DSC] Message Header Message Acknowledgment Query Definition Query Filter 2 2 2 2 Patient ID Notes and Comments 3 3 Order common Observation request Notes and comments Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group Contact Data 2 7 2 11 Observation/Result Notes and comments 7 2 Clinical Trial Identification 7 Error Query Acknowledgement Continuation Pointer 2 5 2 11.3.5 Chapter 4 4 RQC/RCI - request for patient clinical information (event I05) RCI^I05^RCI_I05 MSH MSA QRD [QRF] { PRD [{CTD}] } PID [{DG1}] [{DRG}] [{AL1}] [ { OBR [{NTE}] Return Clinical Information Message Header Message Acknowledgment Query Definition Query Filter [{ TQ1 [{TQ2}] }] [ { OBX [{NTE}] } ] October 2001 O&O Minutes Chapter 2 3 5 5 Provider Data Contact Data 11 11 Patient Identification Diagnosis Diagnosis Related Group Allergy Information 3 6 6 3 Observation Request Notes and Comments 4 2 Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 4 Observation/Result Notes and Comments 7 2 Page 51 } ] [{NTE}] 11.4.1 RQA^I08I11^RQA_I08 MSH [RF1] [ AUT [CTD] ] { PRD [{CTD}] } PID [{NK1}] [[{GT1}] { IN1 [IN2] [IN3] } ] [ ACC ] [{DG1}] [{DRG}] [{AL1}] [ { PR1 [ AUT [CTD] } ] [ { OBR [{NTE}] [{ TQ1 [{TQ2}] }] [ { OBX [{NTE}] } ] } ] [ PV1 [PV2] ] [{NTE}] Notes and Comments RQA/RPA - request patient authorization message Request Patient Authorization Chapter Message Header Referral Information 2 11 Authorization Information Contact Data 11 11 Provider Data Contact Data 11 11 Patient Identification Next of Kin/Associated Parties Guarantor 3 6 6 Insurance Insurance Additional Info Insurance Add'l Info - Cert 6 6 6 Accident Information Diagnosis Diagnosis Related Group Allergy Information 6 6 6 3 Procedure 6 Authorization Information Contact Data ] 11 11 Observation Request Notes and Comments 4 2 Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 4 Observation/Result Notes and Comments 7 2 Patient Visit Patient Visit Additional Info 3 3 Notes and Comments 2 RPA^I08- Return Patient Authorization I11^RPA_I08 MSH Message Header October 2001 O&O Minutes 2 Chapter 2 Page 52 MSA [RF1] [ AUT [CTD] ] { PRD [{CTD}] } PID [{NK1}] [{GT1}] [ { IN1 [IN2] [IN3] } ] [ ACC ] [{DG1}] [{DRG}] [{AL1}] { PR1 [ AUT [CTD] ] } [ { OBR [{NTE}] Message Acknowledgment Referral Information 3 11 Authorization Information Contact Data 11 11 Provider Data Contact Data 11 11 Patient Identification Next of Kin/Associated Parties Guarantor 3 6 6 Insurance Insurance Additional Info Insurance Add'l Info - Cert 6 6 6 Accident Information Diagnosis Diagnosis Related Group Allergy Information 6 6 6 3 Procedure 6 Authorization Information Contact Data 11 11 Observation Request Notes and Comments 4 2 [{ Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 4 Observation/Result Notes and Comments 7 2 Patient Visit Patient Visit Additional Info 3 3 Notes and Comments 2 TQ1 [{TQ2}] }] [ { OBX [{NTE}] } ] } ] [ PV1 [PV2] ] [{NTE}] 11.5.1 REF^I12I15^REF_I12 MSH [RF1] [ AUT [CTD] ] { PRD [{CTD}] } PID October 2001 O&O Minutes REF/RRI - patient referral message Patient Referral Chapter Message Header Referral Information 2 11 Authorization Information Contact Data 11 11 Provider Data Contact Data 11 11 Patient Identification 3 Page 53 [{NK1}] [{GT1}] [ { IN1 [IN2] [IN3] } ] [ACC] [{DG1}] [{DRG}] [{AL1}] [ { PR1 [ AUT [CTD] } ] [ { OBR [{NTE}] [{ TQ1 [{TQ2}] }] [ { OBX [{NTE}] } ] } ] [ PV1 [PV2] ] [ PV1 [PV2] ] [{NTE}] RRI^I12I15^RRI_I12 MSH [MSA] [RF1] [ AUT [CTD] ] { PRD [{CTD}] } PID [ACC] [{DG1}] [{DRG}] [{AL1}] [ { PR1 [ AUT October 2001 O&O Minutes Next of Kin/Associated Parties Guarantor 6 6 Insurance Insurance Additional Info Insurance Add'l Info -Cert 6 6 6 Accident Information Diagnosis Diagnosis Related Group Allergy Information 6 6 6 3 Procedure 6 Authorization Information Contact Data ] 11 11 Observation Request Notes and Comments 4 2 Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 4 Observation/Result Notes and Comments 7 2 Patient Visit 3 Patient Visit Additional Info 3 Patient Visit Patient Visit Additional Info 3 3 Notes and Comments 2 Return Referral Information Chapter Message Header Message Acknowledgment Referral Information 2 3 11 Authorization Information Contact Data 11 11 Provider Data Contact Data 11 11 Patient Identification Accident Information 3 6 Diagnosis Diagnosis Related Group Allergy Information 6 6 3 Procedure 6 Authorization Information 11 Page 54 [CTD] } ] [ { OBR [{NTE}] [{ TQ1 [{TQ2}] }] [ { OBX [{NTE}] } ] } ] [ PV1 [PV2] ] [{NTE}] October 2001 O&O Minutes Contact Data ] 11 Observation Request Notes and Comments 4 2 Start Timing/Quantity Group Timing/Quantity Timing/Quantity Order Sequence End Timing/Quantity Group 4 4 Observation/Result Notes and Comments 7 2 Patient Visit Patient Visit Additional Info 3 3 Notes and Comments 2 Page 55 Part 6 CM Data Type Replacement Proposal Short Description: Continue to define new data types to replace existing CM data types. Justification: Continuation of proposal # 155,165, 166, 167 and 168. Pharm 10/01/01 – will the use of CM_xxx names for 2.3.1 and 2.4 and new names (e.g., LA1) in 2.5 create problems with interversion messages when using XML. Strongly suggest that the new names be used for 2.3.1 and 2.4, or keep the CM names in 2.5. Control Data Types 2.9.80 LA1 - location with address variation 1 HL7 Component Table – LA1 – Location with Address Variation 1 SEQ LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. 1 IS 302 Point of Care 2.9.29.1 2 IS 303 Room 2.9.29.2 3 IS 304 Bed 2.9.29.3 4 HD Facility 2.9.29.4 5 IS 306 Location Status 2.9.29.5 6 IS 305 Patient Location Type 2.9.29.6 7 IS 307 Building 2.9.29.7 8 IS 308 Floor 2.9.29.8 9 AD Address 2.9.29.9 Note: Replaces the CM data type used in 4.14.1.8 RXO-8 and 4.14.4.8 RXE-8 as of version 2.5. Definition: Specifies a location and its address. Issue 1: Although the CM applied to RXO-8, RXE-8, RXD-13, RXG-11 and RXA-11 began life as the same structure, they separated into 2 structures in versions 2.3 and 2.3.1. This was confirmed by CQ on 2/9/01 and a distinct CM_LA1 structure and a CM_LA2 structure were defined and applied as an interim measure. Can we now move toward bringing them together again or will we apply a bandaid and ask OO to deprecate the fields and replace them with a new structure –perhaps a new XPL data type or perhaps 2 fields? The difference is that the LA1 has a component with an AD data type while LA2 has flattened the AD into components of the parent data type LA2. Pharm 10/01/01 – agree that we do not want to consolidate the two at this time. But, one of these two should be deprecated to prevent reuse … which would be better to keep? Since AD is deprecated, suggest that LA1 be deprecated (not the fields, deprecate use of the data type for future work) and LA2 be favored. October 2001 O&O Minutes Page 56 2.9.80.1 Point of Care (IS) Definition: Issue 2: This has already been defined as part of the PL data type. Should the definition for this component and the following 7 components be repeated here? Should I simply say: See 2.9.29.1 – PL-1 for definition? Pharm 10/01/01 – prefer to have definition copied from PL into these components and include a statement that the definition should be the same as the referenced PL component defintion. 2.9.80.2 Room (IS) Definition: 2.9.80.3 Bed (IS) Definition: 2.9.80.4 Facility (HD) Definition: 2.9.80.5 Location Status (IS) Definition: 2.9.80.6 Patient Location Type (IS) Definition: 2.9.80.7 Building (IS) Definition: 2.9.80.8 Floor (IS) Definition: 2.9.80.9 Address (AD) Definition: Issue 3: The AD data type has been deprecated and should not be applied to new uses. Should this be replaced by the XAD data type? The XAD has an embedded complex data type SAD. Maybe use of the AD can be considered definition of a current use not a new use. If that is the case, should we say: See section 2.9.1? Pharm 10/01/01 – since the CM already exists, the use of AD should not be an issue. Additionally, our suggestion (see above) is to deprecate this data type, which would limit the impact of using AD. 2.9.80 LA2 - Location with Address Variation 2 HL7 Component Table – LA2 – Location with Address Variation 2 SEQ LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. 1 IS 302 Point of Care 2.9.29.1 2 IS 303 Room 2.9.29.2 3 IS 304 Bed 2.9.29.3 4 HD Facility 2.9.29.4 October 2001 O&O Minutes Page 57 SEQ LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. 5 IS 306 Location Status 2.9.29.5 6 IS 305 Patient Location Type 2.9.29.6 7 IS 307 Building 2.9.29.7 8 IS 308 Floor 2.9.29.8 9 ST Street Address 2.9.1.1 10 ST Other Designation 2.9.1.2 11 ST City 2.9.1.3 12 ST State or Province 2.9.1.4 13 ST Zip or Postal Code 2.9.1.5 14 ID 399 Country 2.9.1.6 15 ID 190 Address Type 2.9.1.7 16 ST Note: 2.5. Other Geographic Designation Replaces the CM data type used in 4.14.5.13 RXD-13, 4.14.6.11 RXG-11 and 4.14.7.11 RXA-11 as of version Definition: Specifies a location and its address. Issue 1: 2/9: CQ confirms the LA1 structure and the LA2 structure are different; therefore they are 2 distinct data types. Can we now move toward bringing them together again or will we apply a bandaid and ask OO to deprecate the fields and replace them with a new structure –perhaps a new XPL data type or perhaps 2 fields? Pharm 10/01/01 – see above 2.9.80.1 Point of Care (IS) Definition: Issue 2: This has already been defined as part of the PL data type. Should the definition for this component and the following 7 components be repeated here? Pharm 10/01/01 – see above 2.9.80.2 Room (IS) Definition: 2.9.80.3 Bed (IS) Definition: 2.9.80.4 Facility (HD) Definition: 2.9.80.5 Location Status (IS) Definition: 2.9.80.6 Patient Location Type (IS) Definition: 2.9.80.7 Building (IS) Definition: October 2001 O&O Minutes Page 58 2.9.80.8 Floor (IS) Definition: 2.9.80.9 Street Address (ST) Definition: Issue: This has already been defined as part of the AD data type. Should the definition for this component and the following 7 components be repeated here? Or do we say: See section 2.9.1.1? Pharm 10/01/01 – see above PL discussion, same applies to ADOther Designation (ST) Definition: 2.9.80.10 City (ST) Definition: 2.9.80.11 State or Province (ST) Definition: 2.9.80.12 Zip or Postal Code (ST) Definition: 2.9.80.13 Country (ID) Definition: 2.9.80.14 Street Address (ID) Definition: 2.9.80.15 Other Geographic Designation (ST) Definition: 2.9.81 WVI - channel identifier HL7 Component Table – Channel Identifier SEQ LEN DT OPT TBL# COMPONENT NAME 1 NM Channel Number 2 ST Channel Name COMMENTS SEC.REF. Note: Replaces the CM data type used in 7.14.1.3.1 OBX-5.1 where OBX-5 Observation value (*) is data type CD as of version 2.5. Definition: This data type specifies the number and name of the recording channel where waveform data is trnsmitted. 2.9.81.1 Channel number (NM) Definition: This component specifies the number of the recording channel. 2.9.81.2 Channel name (ST) Definition: This component specifies the name of the recording channel. 2.9.82 WVS - waveform source HL7 Component Table – Waveform Source SEQ LEN DT OPT TBL# COMPONENT NAME 1 ST Source Name 1 2 ST Source Name 2 October 2001 O&O Minutes COMMENTS SEC.REF. Page 59 Note: Replaces the CM data type used in 7.14.1.4 OBX-5.2 where OBX-5 Observation value (*) is data type CD as of version 2.5. Definition: This data type identifies the source of the waveform connected to a channel. 2.9.82.1 Source name 1 (ST) Definition: This component identifies the first input for the waveform source. 2.9.82.1 Source name 2 (ST) Definition: This component identifies the second input for the waveform source. 2.9.83 CSU - channel sensitivity HL7 Component Table – Channel Sensitivity SEQ LEN DT OPT TBL# COMPONENT NAME 1 NM Channel Sensitivity 2 ST Unit of Measure Identifier 3 ST 4 ID 5 ST Alternate Unit of Measure Identifier 6 ST Alternate Unit of Measure Description 7 ID COMMENTS SEC.REF. Unit of Measure Description 396 396 Unit of Measure Coding System Alternate Unit of Measure Coding System Note: Replaces the CM data type used in 7.14.1.5 OBX-5.3 where OBX-5Observation value (*) is data type CD as of version 2.5. Definition: This data type defines the channel sensitivity (gain) and the units in which it is measured in a waveform result. 2.9.83.1 Channel sensitivity (NM) Definition: This component transmits the nominal value that corresponds to one unit in the waveform data, that is, the effective resolution of the least significant bit of the ADC, and the polarity of the channel. 2.9.83.2 Unit of measure identifier (ST) Definition: The units designation for the channel sensitivity. 2.9.83.3 Unit of measure description (ST) Definition: The full text name of the unit of measure identifier. 2.9.83.4 Unit of measure coding system (ID) Definition: Specifies the coding system for the unit of measure. 2.9.83.5 Alternate unit of measure identifier (ST) Definition: An alternate units designation for the channel sensitivity. 2.9.83.6 Alternate unit of measure description (ST) Definition: The full text name of the alternate unit of measure identifier. 2.9.83.7 Alternate unit of measure coding system (ID) Definition: Specifies the coding system for the alternate unit of measure. October 2001 O&O Minutes Page 60 2.9.84 CCP - channel calibration parameters HL7 Component Table – Channel Calibration Parameters SEQ LEN DT OPT TBL# COMPONENT NAME 1 NM Channel Calibration Sensitivity Correction Factor 2 NM Channel Calibration Baseline 3 NM Channel Calibration Time Skew COMMENTS SEC.REF. Note: Replaces the CM data type used in 7.14.1.6 OBX-5.4 where OBX-5 Observation value (*) is data type CD as of version 2.5. Definition: This data type identifies the corrections to channel sensitivity, the baseline, and the channel time skew when transmitting waveform results. 2.9.84.1 Channel calibration sensitivity correction factor (NM) Definition: This component defines a correction factor for channel sensitivity which may be derived from the last calibration procedure performed. The actual channel sensitivity is the nominal channel sensitivity given in the previous component multiplied by the unitless correction factor. 2.9.84.2 Channel calibration baseline (NM) Definition: This component defines the actual channel baseline (the data value which corresponds to a nominal input signal of zero). The actual baseline may differ from the ideal because of a dc offset in the amplifier connected to the ADC. The actual baseline values for all channels (which need not be integers) may be determined at the time of calibration as the average digitized values obtained when a zero input signal is connected to each channel. 2.9.84.3 Channel calibration time skew (NM) Definition: This component defines the time difference between the nominal sampling (digitization) time (which would be the same for all channels) and the actual sampling time of the channel, in seconds (or fractions thereof). This value will differ from zero when all channels in the montage are not sampled simultaneously, as occurs in systems which sample successive channels at regular time intervals. This value may be determined from a calibration procedure in which an identical time-varying signal is applied to all channels and interchannel time differences are estimated, or more commonly it may be taken from the manufacturer’s specifications for the digitizing system used. For example, for a system which samples successive channels at regular time intervals t, the time skew of channel number n would be (n-1)t. The actual time of sampling (digitization) of sample number m of channel number n in such a system would be R + (m-1)/f + (n-1)t, where R is the reference time at the start of the epoch and f is the channel sampling frequency (t < 1/f). 2.9.85 PLN – practitioner license or other ID number Components: <ID number (ST)> ^ <type of ID number (IS)> ^ <state/other qualifying info (ST)> ^ <expiration date (DT)> Note: this a duplicate of the data type presented in proposal #167. It is repeated here for the convenience of OO who will need to address some of the issues.. HL7 Component Table - PLN – practitioner license or other ID number SEQ LEN DT OPT 1 20 ST R 2 8 IS R October 2001 O&O Minutes TBL# COMPONENT NAME COMMENTS SEC.REF. ID number 0338 Type of ID number Page 61 SEQ LEN DT OPT TBL# COMPONENT NAME 3 62 ST O State/other qualifying info 4 8 DT O Expiration date COMMENTS SEC.REF. Definition: This data type specifies a practitioner’s license number, or other ID number such as UPIN, Medicare and Medicaid number, and associated detail. Note: Replaces the CM data type used in 15.4.5.6 PRA-6 as of version 2.5. Issue: This data type should replace the CM data type applied to PRA-6 Practitioner ID numbers as defined in chapter 15, section 15.4.5.6 , PRD-7 Provider identifiers as defined chapter 11, section 11.6.3.7, and CTD-7 Contact identifiers as defined in chapter 11, section 11.6.4.7. It should be noted that the PRA-6 may be deprecated in v 2.5. Issue: PRD-7 and CTD-7 currently do not have the 4th component “expiration date”. Also, the 3rd component is described as “other qualify information”. However, the narrative refers the reader to the PRA-6 for further specification. Response: suggest OO TC deprecate these 2 segment fields and replace with new fields of data type revised CX. Issue: Should there be a proposal to deprecate PRD-7 and CTD-7 in favor of new fields assigned data type CX? Pharm 10/01/01 – agrees with the idea to deprecate these fields in favor of new fields of type CX 2.9.85.1 ID number (ST) Definition: Specifies the license number or other ID number such as UPIN, Medicare and Medicaid number. 2.9.85.2 Type of ID number (IS) Definition: Specifies the type of number.. The practitioner ID number type (component 2) is a user-defined table (Table 0338). User-defined Table 0338 - Practitioner ID number type Value CY DEA County number Drug Enforcement Agency no. GL General ledger number L&I Labor and industries number MCD Medicaid number MCR Medicare number QA October 2001 O&O Minutes Description QA number Page 62 Value SL Description State license number TAX Tax ID number TRL Training license number UPIN Unique physician ID no. 2.9.85.3 State/other qualifying info (ST) Definition: Optional component whichthat specifies the state or province in which the license or ID is valid, if relevant, or other qualifying information. It is recommended that state qualifications use the abbreviations from the postal service of the country. 2.9.85.4 Expiration date (DT) Definition: Specifies the date when the license or ID is no longer valid.. October 2001 O&O Minutes Page 63 Blood Bank Special Interest Group (BB SIG) Proposal for Changes: Blood Product Order Message Blood Product Dispense Status Message Blood Product Transfusion Message October 2001 O&O Minutes Page 64 Table of Contents 4.1 Document Objective 66 4.2 Message Identification 68 4.3 bLOOD bANK trigger events and messages 70 4.3.1 Usage notes for blood bank messages ................................................................................... 70 4.3.2 OMB – blood product order message (event O26) ............................................................... 70 4.3.3 ORB – blood product order acknowledgment (event O27) .................................................. 70 4.3.4 BPD – blood product dispense status message (event O28) ................................................. 71 4.3.5 BRP – blood product dispense status acknowledgment (event O29) .................................... 71 4.3.6 BTS – blood product transfusion message (event O30) ........................................................ 72 4.3.7 BRT – blood product transfusion acknowledgment (event O31) .......................................... 72 4.4 Blood Bank Segments 72 4.4.1 ORC - common order segment.............................................................................................. 72 4.4.2 BPO – blood product order segment ..................................................................................... 73 4.4.3 BPX – blood product dispense status segment...................................................................... 77 4.4.4 BTX – blood product transfusion segment ........................................................................... 87 October 2001 O&O Minutes Page 65 Document Objective This working document is intended to serve as an organized means of communicating all the information gathered through the Blood Bank Special Interest Group (BB SIG). Information presented in this document has originated from BB SIG meeting discussions, conference calls, individual contributions, and previously existing HL7 documents. Note: The proper name for the laboratory area, which performs pre-transfusion testing for a patient to determine product compatibility, is a transfusion service. The more commonly used name is blood bank. However, in the blood bank industry, blood bank usually refers to the blood center where blood donations are made. Throughout this document an attempt has been made to utilize the more appropriate name of transfusion service for the patientrelated messaging. Problem: The current HL7 standard does not adequately address the following transfusion service related interface issues: 1. The specimen used for testing in a blood bank / transfusion service differs from a routine lab- oratory specimen, as it has an extended expiration date and may be used for multiple orders for the duration of the life of that specimen. This information needs to be communicated between the clinical staff and the transfusion service. Also, labeling of blood specimens must follow very stringent labeling requirements. Mis-labeled, mis-identified and expired specimens cannot be used for testing and this information must also be communicated between the hospital staff and the transfusion service. 2. There is no standard means of ordering blood products intended for transfusion to a patient, particularly for a patient with special transfusion requirements. 3. There is currently no standard means of communicating the status of blood products that are made ready for transfusion to a patient by the transfusion service, or have been dispensed or transfused to a patient. 4. In order for the transfusion service medical staff to perform a prospective review of appropriateness of a blood product order or subsequent transfusion, it is necessary to view the patient's current hematology results of specific tests. This is readily performed when the transfusion service computer system is a module within an LIS. However, stand-alone transfusion service computer systems do not have immediate access to such information and are dependent upon receiving this information from the clinician when the order is placed. There is currently no standard means of transmitting this information. 5. Transfusion service testing frequently involves performing tests that are relevant to more than one individual, such as a mother and infant or a potential organ donor and intended recipient. There is currently no way to link the results of testing to the related individual. This current proposal addresses these issues in the following manner: 1) The transmission of specimen information is of great importance to the BB SIG. However, a proposed solution is not included in this current proposal as the BB SIG is investigating the use of the Specimen Source (SPM) segment, providing the required attributes can be added to that segment. This specimen information should be included in any new messages in this proposal since the availability and status of a blood bank specimen can change at any time. The BB SIG will seek the approval of the Specimen Source committee for the additional specimen attributes. 2) Proposed new Blood Product Order message: a) Proposed new trigger event for the message (to be officially assigned by O/O): 26 b) New detail segment containing specific blood-product related attributes: BPO c) ORB New Acknowledgment message for the blood product order: d) New trigger event for the acknowledgement (to be officially assigned by O/O): e) October 2001 O&O Minutes OMB 27 Relevant clinical information is included in the OBX segment as needed. Page 66 3) Proposed new Blood Product Dispense status message: a) Proposed new trigger event for the message (to be officially assigned by O/O): BPS 28 b) New detail segment containing specific blood-product related attributes: BPX c) BRP New Acknowledgment message for the blood product order: d) New trigger event for the acknowledgement (to be officially assigned by O/O): 4) Proposed new blood product transfusion message: a) Proposed new trigger event for the message (to be officially assigned by O/O): 29 BTS 30 b) New detail segment containing specific blood-product related attributes: BTX c) BRT New Acknowledgment message for the blood product order: d) New trigger event for the acknowledgement (to be officially assigned by O/O): 31 The remaining sections of the proposal include the detail descriptions of the messages, segments and message usage. October 2001 O&O Minutes Page 67 Patient Related Messages Message Identification The following diagram depicts the message flow of the proposed new blood product messages. Clinical Order Entry System (HIS) Lab System (LIS) Transfusion Service System Blood Product Order Message from Placer (Trigger Event O26) OMB Acknowledgement from Filler (Trigger Event O27) ORB Modification to order from placer or filler (Trigger Event O26) OMB OMB Acknowledgement from filler or placer (Trigger Event O27) ORB ORB Blood Product Dispense Status Message - Blood Product Ready to Dispense (RD) from filler (Trigger Event O28) BPD Acknowledgement by placer (Trigger Event O29) BRP Clinical Order Entry System (HIS) October 2001 O&O Minutes Clinical Order Entry System (HIS) Transfusion Service System Page 68 Blood Product Dispense Message - Blood Product Dispensed (DI) (Trigger Event 28) BPD Acknowledgement by placer (Trigger Event O29) BRP Stop/Cancel Transfusion (Trigger Event O32) BTS Acknowledgement by filler (Trigger Event O33) BRT Complete Transfusion by placer (Trigger Event O30) BTS Acknowledgement by filler (Trigger Event O31) BRT October 2001 O&O Minutes Page 69 bLOOD bANK trigger events and messages Usage notes for blood bank messages OMB – blood product order message (event O26) Blood product order messages present the need for additional information that is not included in standard HL7 order messages. Order messages need to contain accompanying details regarding the blood product component, such as special processing requirements (e.g. irradiation and leukoreduction), and the amount of the blood product to be administered. Additionally, specific relevant clinical information can be included to allow the prospective review of the appropriateness of the blood product order Blood product orders can use the OMB message with the BPO segment for the detail segment and the acknowledgment message, ORB as described below. OMB^O26^OMB_O26 Blood Product Order Message Chapter MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] [{IN1 [IN2] [IN3] }] [GT1] [{AL1}] ] { ORC BPO [{NTE}] [{DG1}] [{ OBX [{NTE}] }] [{FT1}] [BLG] } Message Header Notes and Comments (for Header) 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit - Additional Info Insurance Insurance Additional Info Insurance Add’l Info - Cert. 3 3 2 3 3 6 6 6 Guarantor Allergy Information 6 3 Common Order Blood Product Order Notes and Comments (for Order) Diagnosis 4 4 2 6 Observation/Result Notes and Comments (for Results) 7 2 Financial Transaction Billing Segment 6 6 OMB use notes a) The NTE segment(s) can be included in the OMB message in four places; in each place the NTE refers to the segment that it follows. In particular, the NTEs following the MSH refer only to the message header; the NTEs following the blood product order segment apply to the service defined by that ORC and blood product order segment. b) The PID segment is required if and only if new orders are being entered and they are related to a particular patient. For non-patient-related orders the PID segment is never included. c) The optional PV1 segment is present mainly to permit transmission of patient visit information such as current location with an order. ORB – blood product order acknowledgment (event O27) ORB^O27^ORB_O27 Description MSH MSA [ERR] [{NTE}] [ Message Header Message Acknowledgment Error Notes and Comments (for Response Header) October 2001 O&O Minutes Chapter 2 2 2 2 Page 70 [PID [{ ORC [BPO] }] ] Patient Identification 3 Common Order Blood Product Order 4 4 ] BPD – blood product dispense status message (event O28) In the pre-transfusion processing of blood products, it is necessary for the transfusion service to communicate information that is not included in the current HL7 order/observation model. Examples of pretransfusion processing include performing a crossmatch test to ensure compatibility with the patient, or irradiation of the blood product due to a special transfusion requirement for the patient. The blood product dispense status messages need to contain additional information regarding the blood products requested such as the Donation ID number, product code, blood type, expiration date/time and current status of the blood product. In the processing of commercial blood products, such as Rh Immune Globulin, Factor Concentrate, or Albumin Products, it is necessary for the transfusion service to communicate information that is not included in the current HL7 order/observation model. The status messages need to contain additional information regarding the blood products requested, such as the lot number and manufacturer, expiration date and status of the commercial product. A new message type and trigger event are proposed to initiate the transmission of a blood product dispense status message each time the status of a blood product changes. Blood product dispense status messages will use the BPS and BRP messages as described below. BPS^O28^BPS_O28 Blood Product dispense status Message MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] ] { ORC BPO [{NTE}] [{ BPX [{NTE}] }] } Message Header Notes and Comments (for Header) Chapter 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit - Additional Info 3 3 2 3 3 Common Order Blood Product Order Notes and Comments (for BPO) 4 4 2 Blood Product dispense status/Observation Notes and Comments (for BPX) 4 2 BRP – blood product dispense status acknowledgment (event O29) BRP^O29^BRP_O29 Description MSH MSA [ERR] [{NTE}] [ [PID [{ ORC [BPO] [{BPX}] }] ] Message Header Message Acknowledgment Error Notes and Comments (for Response Header) 2 2 2 2 Patient Identification 3 Common Order Blood Product Order Blood Product dispense status/Observation 4 4 October 2001 O&O Minutes Chapter Page 71 BTS – blood product transfusion message (event O30) A new message type and trigger event is proposed to notify the filler system of the final disposition (transfusion) of a blood product. Blood product transfusion messages will use the BTS and BRT messages as described below. BTS^O30^BTS_O30 Blood Product Transfusion Message MSH [{NTE}] [ PID [PD1] [{NTE}] [PV1 [PV2]] ] { ORC BPO [{NTE}] [{ BTX [{NTE}] }] } Message Header Notes and Comments (for Header) Chapter 2 2 Patient Identification Additional Demographics Notes and Comments (for Patient ID) Patient Visit Patient Visit - Additional Info 3 3 2 3 3 Common Order Blood Product Order Notes and Comments (for BPO) 4 4 2 Blood Product Transfusion Status/Observation Notes and Comments (for BTX) 4 2 BRT – blood product transfusion acknowledgment (event O31) BRT^O31^BRT_O31 Description MSH MSA [ERR] [{NTE}] [ [PID] [{ ORC [BPO] [{BTX}] }] ] Message Header Message Acknowledgment Error Notes and Comments (for Response Header) Chapter 2 2 2 2 Patient Identification 3 Common Order Blood Product Order Blood Product Transfusion Status/Observation 4 4 4 Blood Bank Segments ORC - common order segment The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM) message. ORC is mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise. If details are needed for a particular type of order segment (e.g., Pharmacy, Dietary), the ORC must precede any order detail segment (e.g., RXO, ODS). In some cases, the ORC may be as simple as the string ORC|OK|<placer order number>|<filler order number>|<cr>. If details are not needed for the order, the order detail segment may be omitted. For example, to place an order on hold, one would transmit an ORC with the following fields completed: ORC-1-order control with a value of HD, ORC-2-placer order number, and ORC-3-filler order number. There is some overlap between fields of the ORC and those in the order detail segments. These are described in the succeeding sections. October 2001 O&O Minutes Page 72 HL7 Attribute Table – ORC – Common Order SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 2 22 22 22 2 1 200 200 26 250 250 250 80 250 26 250 250 250 250 250 250 250 250 250 250 ID EI EI EI ID ID TQ CM TS XCN XCN XCN PL XTN TS CE CE CE XCN CE XON XAD XTN XAD CWE R C C O O O O O O O O O O O O O O O O O O O O O O N 0119 N 0038 0121 00215 00216 00217 00218 00219 00220 00221 00222 00223 00224 00225 00226 00227 00228 00229 00230 00231 00232 00233 01310 01311 01312 01313 01314 01473 Order Control Placer Order Number Filler Order Number Placer Group Number Order Status Response Flag Quantity/Timing Parent Date/Time of Transaction Entered By Verified By Ordering Provider Enterer’s Location Call Back Phone Number Order Effective Date/Time Order Control Code Reason Entering Organization Entering Device Action By Advanced Beneficiary Notice Code Ordering Facility Name Ordering Facility Address Ordering Facility Phone Number Ordering Provider Address Order Status Modifier Y Y Y Y Y/2 Y 0339 Y Y Y Y N BPO – blood product order segment Blood product order messages present the need for additional information that is not included in standard HL7 order messages. Order messages need to contain accompanying details regarding the blood product component, such as special processing requirements (e.g. irradiation and leukoreduction) and the amount of the blood product to be administered. The following table was used to present various use cases surrounding blood product orders. Discussions of these examples led to the identification of new fields needed that are required for blood product order messages. Universal Service ID [ISBT-128 Universal Service ID] Blood Product Attribute Quantity Blood Product Amount Units 002^Red Blood Cells Leukoreduced 2 300 ml 002^Red Blood Cells Leukoreduced 1 60 ml 002^Red Blood Cells Irradiated 2 15 ml 002^Red Blood Cells Leukoreduced 1 020^Platelets Leukoreduced Irradiated 6 024^ Apheresis Platelets Irradiated 1 910 IU 002^Red Blood Cells 1 Factor VIII 2 October 2001 O&O Minutes Page 73 As can be seen from this table, in addition to the Universal Service ID, it may be necessary to order special blood product attributes, such as leukoreduced or irradiated, or it may be necessary a particular volume of red blood cells required for transfusion. The attributes for the BPO Segment are defined below. HL7 Attribute Table – BPO – Blood Product Order SEQ LEN DT OPT 1 2 3 4 5 6 7 8 9 10 11 4 250 250 5 250 26 80 26 80 250 1 SI CE CE NM CE TS PL TS PL CWE ID R R O O O O O O O O O RP/# TBL # Y ITEM # ??? Y? 0136 ELEMENT NAME Set ID – BPO BP Universal Service ID BP Attributes BP Amount BP Units BP Intended Use Date/Time BP Intended Dispense From Location BP Requested Dispense Date/Time BP Requested Dispense To Location BP Indication for Use BP Informed Consent Indicator BPO field definitions BPO-1 Set ID – BPO (SI) Definition: This field contains the sequence number for the BPO segment within the message. For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on. BPO-2 BP Universal service identifier (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field contains the identifier code for the requested observation/test/battery. This can be based on local and/or “universal” codes. We recommend the “universal” procedure identifier. The structure of this CE data type is described in the control section. The preferred coding system is the ISBT 128 Product Cod e. Blood Product Orders for commercial products such as Rh Immune Globulin or Factor VII concentrate are not defined in an international or national coding system as are blood product. Therefore, locally defined codes can be used of the Universal Service Identifier for commercial products. Figure x-x. Appendix 1 - ISBT 128 Product Code Database Documentation Version 1.2.0 Code ISBT 128 Component Class 001 WHOLE BLOOD 002 RED BLOOD CELLS 003 WASHED RED BLOOD CELLS 004 FROZEN RED BLOOD CELLS 005 FROZEN REJUVENATED RED BLOOD CELLS 006 DEGLYCEROLIZED RED BLOOD CELLS 007 DEGLYCEROLIZED REJUVENATED RED BLOOD CELLS 008 REJUVENATED RED BLOOD CELLS 009 APHERESIS RED BLOOD CELLS 010 FRESH FROZEN PLASMA 011 THAWED FRESH FROZEN PLASMA 012 APHERESIS FRESH FROZEN PLASMA 013 THAWED APHERESIS FRESH FROZEN PLASMA 014 APHERESIS PLASMA October 2001 O&O Minutes Page 74 015 THAWED APHERESIS PLASMA 016 LIQUID PLASMA 017 PLASMA 018 THAWED PLASMA 019 PLATELET RICH PLASMA 020 PLATELETS 021 WASHED PLATELETS 022 POOLED PLATELETS 023 WASHED POOLED PLATELETS 024 APHERESIS PLATELETS 025 FROZEN APHERESIS PLATELETS 026 THAWED APHERESIS PLATELETS 027 WASHED APHERESIS PLATELETS 028 CRYOPRECIPITATE 029 THAWED CRYOPRECIPITATE 030 POOLED CRYOPRECIPITATE 031 THAWED POOLED CRYOPRECIPITATE 032 APHERESIS CRYOPRECIPITATE 033 THAWED APHERESIS CRYOPRECIPITATE 034 GRANULOCYTES 035 APHERESIS GRANULOCYTES 036 POOLED GRANULOCYTES 037 APHERESIS GRANULOCYTES /PLATELETS 038 LEUKOCYTES 039 APHERESIS LEUKOCYTES 040 POOLED PLASMA BPO-3 BP Attributes (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field contains additional information about the blood component class associated with the Universal Service ID. The placer of the order can specify any required product attributes or special processing requirements for the blood product, which must be completed prior to transfusion to the intended recipient. Examples of processing requirements or product attributes include CMV Negative, HLA Matched, Irradiated or Leukoreduced. Refer to HL7 Table #### (to be assigned) - Blood Component Transfusion Requirements for suggested values. This is an optional, repeating field. HL7 Table #### (to be assigned) - Blood Component Transfusion Requirements Value October 2001 O&O Minutes Description LR Leukoreduced IR Irradiated CS CMV Safe FR Fresh unit AU Autologous Unit DI Directed Unit HL HLA Matched CM CMV Negative HB Hemoglobin S Negative WA Washed IG IgA Deficient Page 75 BPO-4 BP Amount (NM) Definition: This field contains the ordered amount (volume) associated with each quantity of blood product. This field is optional so that a unit of blood can be ordered without an amount or unit specified. BPO-5 BP Units (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)> Definition: This field contains the units for the blood product amount. This field contains the designation for unit of measure for blood products. See 7.15.3.3.2. This field is optional so that a unit of blood can be ordered without an amount or unit of measure specified. BPO-6 BP Intended Use Date/Time (TS) Definition: This field specifies the date/time associated with the scheduled availability of the blood product. This is the time when the product is expected to be available within the transfusion service. For example, the product should be available for use but not dispensed on this date/time. This field is optional. BPO-7 BP Intended Dispense From Location (PL) Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ < location status (IS )> ^ <person location type (IS)> ^ <building (IS )> ^ <floor (IS)> ^ <location description (ST)> Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID) Definition: The first component contains location from which the blood component is to be issued (if applicable). Locally defined codes can be used for this field. This field is an optional field and is used when the transfusion service has more than one site from which blood products can be dispensed. This location would indicate the specific facility from which the blood product should be dispensed. BPO-8 BP Requested Dispense Date/Time (TS) Definition: This field specifies the date/time that the requested blood products must be ready to dispense. This date/time may be different from the Intended Use Date/time. For example, the patient may be scheduled to come in for a transfusion at a specified time. However, the placer would request that the blood product be ready to dispense prior to that in order to have the blood component ready for transfusion at the scheduled time. BPO-9 BP Requested Dispense To Location (PL) Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)> Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID) Definition: The first component contains the inpatient or outpatient location to which the blood component is to be dispensed. The default (null) value is the current census location for the patient. Site-specific table. The first eight components have the same form as the first eight components of PV1-3-assigned patient location. The final eight components replace the ninth component of PV1-3-assigned patient location and represent the full address specification. BPO-10 BP Indication for Use (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)> This is a coded optional field. The value indicates the reason that the blood product was ordered. Locally defined codes can be used for this value. This information is helpful for prospective review or retrospective October 2001 O&O Minutes Page 76 studies of blood product ordering practices of the ordering provider by the Quality Assurance Department and/ or Transfusion Committee. User-defined table #### – Indication for use is used as the HL7 identifier for the user-defined table of values for this field. User-defined Table #### – Indication for use Value Description No suggested values BPO-11 BP Informed Consent Indicator (ID) This field indicates whether consent for the transfusion has been obtained. This is an optional yes/no field. BPX – blood product dispense status segment In the processing of blood products, it is necessary for the transfusion service to communicate information that is not included in the current HL7 order/observation model. The status messages need to contain additional information regarding the blood products requested such as the unique donation ID, product code, blood type, expiration date/time of the blood product, and current status of the product. This segment is similar to an OBX segment, but contains additional attributes. A new message type and trigger event is proposed to initiate the transmission of a blood product dispense status message each time the blood product dispense status changes. BP indicates that the component is Blood Products CP indicates that the component is Commerical Product BC indicates that the blood component. HL7 Attribute Table – BPX – Blood Product dispense status SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME Set ID – BPX 1 4 SI R 2 3 4 5 6 7 8 9 10 11 12 13 14 15 250 1 26 22 250 250 250 250 22 250 250 26 5 5 CE ID TS EI CE CE CWE XON EI CE CE TS NM NM R R R C C C C C C O O O R O 16 250 CE O BP Units 17 22 EI O BP Unique ID 18 80 PL O BP Actual Dispense To Location 19 250 XCN O BP Dispensed to Receiver 20 250 XCN O 21 22 EI O October 2001 O&O Minutes ??? 0085 ? ? ? Y ? ? BP Status BP Observation Status BP Date/Time of Status BC Donation ID BC Component BC Donation Type / Intended Use CP Commercial Product CP Manufacturer CP Lot Number BP Blood Group BC Special Testing BP Expiration Date/Time BP Quantity BP Amount BP Responsible Observer Y BP Equipment Instance Identifier Page 77 BPX field definitions BPX-1 Set ID – BPX (SI) Definition: This field contains the sequence number for the BPX segment under the related BPO segment. For the first blood product dispense status transmitted, the sequence number shall be 1; for the second product dispense status, it shall be 2; and so on. BPX-2 BP Status (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field is used to indicate the current status of the specified blood product as indicated by the filler. For example, the first status change of a product that may trigger a Blood Product dispense status Message is when it first becomes linked to a patient and is ready to dispense to a patient. When the blood product is delivered or issued to a patient, the status of the blood product would be changed to indicate that it has now been “dispensed.” A final status would indicate that the product has actually been “transfused.” Refer to HL7 Table #### (to be assigned) - Blood product dispense status for suggested values. HL7 Table #### - Blood product dispense status Value Placer(P)/Filler (F) Description RI Received into inventory (for specified patient) F RD Reserved and ready to dispense F RS Reserved (ordered and product allocated for the patient) F RE Released (no longer allocated for the patient) F DS Dispensed to patient location F RA Returned unused/no longer needed F RL Returned unused/keep linked to patient for possible use later F WA Wasted (product no longer viable) F PT Presumed transfused (dispensed and not returned) F CR Released into inventory for general availability F RQ Request to dispense blood product P BPX-3 BP Observation status (ID) Definition: The most commonly used values in a BPX will be preliminary and final. A status is considered preliminary until a blood product has reached a final disposition for the patient. For example, when the product is first cross-matched and a status message is sent, it would be considered preliminary. When the product is dispensed to the patient, that status would also be considered preliminary. However, once the product is transfused, the status would be considered final. The status of a blood product can continue to change and the previous result should be overwritten until it reaches a final status. Refer to HL7 table 0085. Table 0085 - Observation result status codes interpretation Value October 2001 O&O Minutes Description C Record coming over is a correction and thus replaces a final result D Deletes the OBX record F Final results; Can only be changed with a corrected result. I Specimen in lab; results pending N Not asked; used to affirmatively document that the observation identified in the OBX was not sought when the universal service ID in OBR-4 implies that it would be sought. O Order detail description only (no result) P Preliminary results R Results entered -- not verified S Partial results X Results cannot be obtained for this observation Page 78 Value Description U Results status change to final without re-transmitting results already sent as ‘preliminary.’ E.g., radiology changes status from preliminary to final W Post original as wrong, e.g., transmitted for wrong patient BPX-4 BP Date/time of status (TS) Definition: This field indicates the date and time that the status of the blood component was changed. For example, if the blood component had a status, of "RD" (Ready to Dispense) , the date and time in this field would indicate the date and time that component was made ready to dispense by the filler system. This is a required field. BPX-5 BC Donation ID (EI) Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Definition: The donation ID is the unique identification number assigned to a blood donation. The donation number will depend upon the bar code labeling system used for the component. There are currently two blood component labeling standards: ABC CODABAR and ISBT 128. If using ISBT 128, the donation ID Number is an internationally unique identifier consisting of the following 13 characters: Country Code Collection Facility Donation Year Serial Number This is a conditional field and is required for blood components. It is not applicable for commercial product messages. BPX-6 BC Component (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: The Blood Component field includes a description of the specific blood component. 1st component: The numeric or alphanumeric product code, which represents the type of blood component. The coding system will be determined by the bar code labeling system on the particular component of blood. The preferred coding system is ISBT 128. If using ISBT 128 labeling standard, the product code will consist of an 8-character alphanumeric code, starting with an alpha character and will include the component class, donation type/intended use and division indicator. If using CODABAR product labeling standard, the product code will consist of a 5-character numeric. 2nd Component: Product Description: The Product Description is a textual description of the numeric or alphanumeric product code. This is a conditional field and is required for blood components. It is not applicable for commercial product messages. User-defined table #### – Blood product component is used as the HL7 identifier for the user-defined table of values for this field. User-defined Table #### – Blood product component Value Description No suggested values October 2001 O&O Minutes Page 79 BPX-7 BC Donation type / intended use (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: Donation Type is used to indicate the type of donation or collection/intended use. This value is populated from the list of Reference values below. The default value is “0” or “Unspecified.” Other values will indicate if the blood product is an allogeneic unit from a volunteer donor, or is intended for a specific recipient but may be crossed over and used for another recipient, or is an autologous donation intended only for that particular recipient. Refer to Table 5 -Type of Donation in the ISBT 128 Bar Code Symbology and Application Specification for Labeling of Whole Blood and Blood Components. Figure X.X. ISBT 128 Table 5 – Type of Donation Value Description 0 Not specified 1 For autologous use only X For autologous use only – biohazardous V Voluntary allogeneic D Directed voluntary donation – eligible for crossover Small d Directed paid donation – eligible for crossover P Paid allogeneic donation 2 Directed voluntary allogeneic donation – for directed donor use only L Directed voluntary allogeneic donation – for directed donor use only – limited exposure 3 Directed voluntary allogeneic donation – for directed donor use only – biohazardous 4 Designated voluntary allogeneic donation 5 Dedicated voluntary allogeneic donation R Voluntary research donation Small r Paid research donation S Voluntary source donation T Voluntary therapeutic collection This is a conditional field and is optional for blood component messages. It is not applicable for noncommercial product messages. BPX-8 CP Commercial Product (CWE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field contains the code and description to identify a commercial product. Examples of commercial products are blood derivatives such as Rh Immune Globulin and Factor VIII concentrate, Leukoreduction filters, and blood administration sets. A site-specific table determines the value of the Commercial Product field. Free text can be utilized if no update is to occur. User-defined table #### – Commercial product is used as the HL7 identifier for the user-defined table of values for this field. User-defined Table #### – Commercial product Value Description No suggested values This is a conditional field and is required for commercial blood products. It is optional for blood component messages. October 2001 O&O Minutes Page 80 BPX-9 CP Manufacturer (XON) Definition: This field identifies the manufacturer of the commercial product. The manufacturer may not be the same as the supplier of the commercial product. This is a conditional field and is required for commercial blood products. It is not applicable for blood component messages. BPX-10 CP Lot Number (EI) Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as accessories to transfusion. This is a conditional field and is required for commercial blood products. It is not applicable for blood component messages. BPX-11 BP Blood group (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field indicates the blood group of the blood component. The preferred values for the blood group are the ISBT 128 specified values in Table 3A - Encodation of Blood Group in the ISBT 128 Bar Code Symbology and Application Specification. This is a conditional field and is required for blood components and certain commercial products (such as detergent solvent plasma). Figure 4-n. ISBT 128 Table 3A - Encodation of Blood Group Value Description 95 O Rh negative 51 O Rh positive 06 A Rh negative 62 A Rh positive 17 B Rh negative 73 B Rh Positive 28 AB Rh negative 84 AB Rh positive 55 O 66 A 77 B 88 AB D6 para-Bombay Rh negative E6 para-Bombay Rh positive G6 Bombay Rh negative H6 Bombay Rh positive BPX-12 BC Special testing (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This is a repeating optional field – to allow multiple entries for special testing that was performed. The Special Testing code is used to indicate any types of Special Testing performed on the blood component. The preferred coding system for Special Testing is defined in the ISBT 128 Bar Code October 2001 O&O Minutes Page 81 Symbology and Application Specification. Proposals have been developed and will soon be published by ICCBBA, Inc. for the encodation of other antigen and antibody specificities including, HLA, platelet, red cell and other types of markers. This field is optional for blood component messages. It is not applicable for non-commercial product messages. Refer to Table Table I3 - Special Testing Codes of the ISBT 128 Bar Code Symbology and Application Specification, Figure 4-n. ISBT 128 Table I3 - Special Testing Codes Code October 2001 O&O Minutes Description N0000 default N0001 HLA phenotyped N0002 HPA phenotyped N0003 IgA deficient N0004 RBC phenotyped N0005 RBC antibody(ies) present N0006 RBC antibody absent N0007 Specific antibody present N0008 CMV seronegative N0009 CMV seropositive N0010 HLA antibody(ies) present N0011 HLA antibody absent N0012 HPA antibody(ies) present N0013 HPA antibody absent N0014 HLA phenotyped HPA phenotyped N0015 HLA phenotyped IgA deficient N0016 HLA phenotyped RBC phenotyped N0017 HLA phenotyped RBC antibody(ies) present N0018 HLA phenotyped RBC antibody absent N0019 HLA phenotyped CMV seropositive N0020 HLA phenotyped CMV seronegative N0021 HLA phenotyped HLA antibody(ies) present N0022 HLA phenotyped HLA antibody absent N0023 HLA phenotyped HPA antibody(ies) present N0024 HLA phenotyped HPA antibody absent N0025 HLA phenotyped HPA phenotyped RBC phenotyped N0026 HLA phenotyped HPA phenotyped Page 82 RBC phenotyped CMV seronegative October 2001 O&O Minutes N0027 HLA phenotyped HPA phenotyped RBC phenotyped CMV seropositive N0028 HLA phenotyped RBC phenotyped RBC antibody(ies) present N0029 HLA phenotyped RBC phenotyped RBC antibody absent N0030 HLA phenotyped HLA antibody absent RBC phenotyped N0031 HLA phenotyped HLA antibody absent RBC phenotyped CMV seronegative N0032 HPA phenotyped IgA deficient N0033 HPA phenotyped RBC phenotyped N0034 HPA phenotyped RBC antibody(ies) present N0035 HPA phenotyped RBC antibody absent N0036 HPA phenotyped CMV seronegative N0037 HPA phenotyped CMV seropositive N0038 HLA antibody(ies) present HPA phenotyped N0039 HLA antibody absent HPA phenotyped N0040 HPA phenotyped HPA antibody(ies) present N0041 HPA phenotyped HPA antibody absent N0042 RBC phenotyped IgA deficient N0043 IgA deficient CMV seronegative N0044 IgA deficient CMV seropositive N0045 RBC phenotyped RBC antibody(ies) present N0046 RBC phenotyped RBC antibody absent N0047 RBC phenotyped Specific antibody present N0048 RBC phenotyped CMV seronegative N0049 RBC phenotyped Page 83 CMV seropositive October 2001 O&O Minutes N0050 HLA antibody(ies) present RBC phenotyped N0051 HLA antibody absent RBC phenotyped N0052 HPA antibody(ies) present RBC phenotyped N0053 HPA antibody absent RBC phenotyped N0054 RBC phenotyped RBC antibody absent CMV seronegative N0055 RBC phenotyped RBC antibody absent CMV seropositive N0056 HLA antibody absent RBC phenotyped RBC antibody absent CMV seronegative N0057 HLA antibody absent RBC phenotyped RBC antibody absent CMV seropositive N0058 HLA antibody absent HPA antibody absent RBC phenotyped RBC antibody absent CMV seronegative N0059 HLA antibody absent HPA antibody absent RBC phenotyped RBC antibody absent CMV seropositive N0060 RBC antibody(ies) present Specific antibody(ies) present N0061 RBC antibody(ies) present CMV seronegative N0062 RBC antibodiy(ies) present CMV seropositive N0063 HLA antibody(ies) present RBC antibody(ies) present N0064 HLA antibody absent RBC antibody(ies) present N0065 HPA antibody(ies) present RBC antibody(ies) present N0066 HPA antibody absent RBC antibody(ies) present N0067 RBC antibody absent Specific antibody present N0068 RBC antibody absent CMV seronegative N0069 RBC antibody absent CMV seropositive N0070 HLA antibody(ies) present Page 84 RBC antibody absent October 2001 O&O Minutes N0071 HLA antibody absent RBC antibody absent N0072 HPA antibody(ies) present RBC antibody absent N0073 HPA antibody absent RBC antibody absent N0074 CMV seronegative Specific antibody present N0075 CMV seropositive Specific antibody present N0076 HLA antibody(ies) present Specific antibody present N0077 HLA antibody absent Specific antibody present N0078 HPA antibody(ies) present Specific antibody present N0079 HPA antibody absent Specific antibody present N0080 HLA antibody(ies) present CMV seronegative N0081 HLA antibody absent CMV seronegative N0082 HPA antibody(ies) present CMV seronegative N0083 HPA antibody absent CMV seronegative N0084 HLA antibody(ies) present CMV seropositive N0085 HLA antibody absent CMV seropositive N0086 HPA antibody(ies) present CMV seropositive N0087 HPA antibody absent CMV seropositive N0088 HLA antibody(ies) present HPA antibody(ies) present N0089 HLA antibody(ies) present HPA antibody absent N0090 HLA antibody absent HPA antibody(ies) present N0091 HLA antibody absent HPA antibody absent N0092 For future use N0093 For future use N0094 For future use N0095 For future use N0096 For future use N0097 For future use N0098 For future use N0099 For future use N0100 CMV antibody present N0101 Anti-D present Page 85 N0102 HAV antibody present N0103 HBV antibody present N0104 Tetanus antibody present N0105 Varicella Zoster antibody present BPX-13 BP Expiration date/time (TS) Definition: The expiration date/time specifies the date and time that the blood product expires. The blood product is no longer considered acceptable once the expiration date has been reached unless cleared by the blood bank medical staff. BPX-14 BP Quantity (NM) Definition: This field indicates the number of blood bank products or components. This is a required field. BPX-15 BP Amount (NM) Definition: This field contains the ordered amount (volume) associated with each quantity of a blood bank component. This is an optional field. BPX-16 BP Units (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field contains the units for the blood product quantity. (See Chapter 7 for more details about identifying reporting units.) This field may be used to specify the units of measure for volume of a blood component (i.e. 50 ml). It may also be used to indicate the unit of measure or dosage of a commercial product (i.e. 910 I.U. - International Units - of Factor VIII Concentrate). BPX-17 BP Unique ID (EI) Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Definition: This field is a unique system-generated number assigned to the blood product to which the message is referring. Each time the status is updated, the new message should replace the previous message if the Blood Product dispense status ID Number is the same. If the Blood Product dispense status ID Number is different, it indicates that the status applies to a different blood product. This is an optional field and its use must be agreed upon by the sending and receiving systems. BPX-18 BP Dispensed to Location (PL) Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)> Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID) Definition: The first component contains the inpatient or outpatient location to which the blood component was actually dispensed. The default (null) value is the current census location for the patient. Site-specific table. The first eight components have the same form as the first eight components of PV1-3-assigned patient location. The final eight components replace the ninth component of PV1-3-assigned patient location and represent the full address specification This field is optional. BPX-19 BP Dispensed to receiver (XCN) Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., October 2001 O&O Minutes Page 86 MD) (IS)> ^ <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)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)> Subcomponents of assigning authority: type (ID) Subcomponents of assigning facility: type (ID) <namespace ID (IS)> & <universal ID (ST)> & <universal ID <namespace ID (IS)> & <universal ID (ST)> & <universal ID Definition: This is the person who picked up the blood unit(s) and transported them. The code for the receiver is recorded as a XCN data type. If the identity is sent as a local code, it should be unique and unambiguous when combined with BPX-25-producer ID (need to determine what this means BTX 14, 15). This field can be free text to permit capture without table update. In this case, the receiver’s name must be recorded as the second through fourth components of the field. This field is optional. BPX-20 BP Responsible Observer (XCN) Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <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)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)> Subcomponents of assigning authority: type (ID) Subcomponents of assigning facility: type (ID) <namespace ID (IS)> & <universal ID (ST)> & <universal ID <namespace ID (IS)> & <universal ID (ST)> & <universal ID Definition: This field is used to indicate the identification of the individual who prepared the blood component. This is an optional field. BPX-21 BP Equipment Instance Identifier (EI) Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Definition: This field identifies the Equipment Instance (e.g., Analyzer, Analyzer module, group of Analyzers) responsible for the production of the observation. This is the identifier from an institution's master list of equipment, where the institution is specified by the namespace ID or if it is blank, then by the “BP Producer’s ID” (BPX-7). It should be possible to retrieve from this master list the equipment type, serial number, etc., however it is not planned to transfer this information with every BPX. The repeating of this field allows for the hierarchical representation of the equipment (lowest level first), e.g., module of an instrument, instrument consisting of modules, cluster of multiple instruments, etc. BTX – blood product transfusion segment HL7 Attribute Table – BTX – Blood Product Transfusion SEQ LEN DT OPT 1 4 SI R 2 3 4 5 6 7 8 22 250 250 250 250 22 5 EI CE CE CE XON EI NM C C C C C C R October 2001 O&O Minutes RP/# TBL# ITEM # ELEMENT NAME Set ID – BTX ? ? ? BC Donation ID BC Component BC Blood Group CP Commercial Product CP Manufacturer CP Lot Number BT Quantity Page 87 SEQ LEN DT OPT 9 10 11 12 5 250 250 1 NM CE CE ID O O R R RP/# TBL# ? ? ITEM # ELEMENT NAME BP Amount BT Units BT Transfusion Status BT Observation Status 13 26 TS R BT Date/Time of Status 14 250 XCN O BT Administrator 15 250 XCN O BT Verifier 16 26 TS O BT Start Date/Time 17 26 TS O 18 1 ID O 19 250 CE O 20 1 ID 21 250 CWE BT End Date/Time 0136 Y BT Adverse Reaction Indicator ? BT Adverse Reaction Type O 0136 BT Transfusion Interrupted O ? BT Transfusion Interrupted Reason BTX field definitions BTX-1 Set ID – BTX (SI) Definition: This field contains the sequence number for the BTX segment under the related BPO segment. For the first product transfusion transmitted, the sequence number shall be 1; for the second product transfusion, it shall be 2; and so on. BTX-2 BC Donation ID (EI) Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Definition: The donation ID is the unique identification number assigned to a blood donation. The donation number will depend upon the bar code labeling system used for the component. There are currently two blood component labeling standards: ABC CODABAR and ISBT 128. If using ISBT 128, the donation ID Number is an internationally unique identifier consisting of the following 13 characters: Country Code Collection Facility Donation Year Serial Number This is a conditional field and is required for blood components. It is not applicable for commercial product messages. BTX-3 BC Component (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: The Blood Component field includes a description of the specific blood component. 1st component: The numeric or alphanumeric product code, which represents the type of blood component. The coding system will be determined by the bar code labeling system on the particular component of blood. The preferred coding system is ISBT 128. If using ISBT 128 labeling standard, the product code will consist of an 8-character alphanumeric code, starting with an alpha character and will include the component class, donation type/intended use and division indicator. If using CODABAR product labeling standard, the product code will consist of a 5-character numeric. 2nd Component: Product Description: The Product Description is a textual description of the numeric or alphanumeric product code. This is a conditional field and is required for blood components. It is not applicable for commercial product messages. October 2001 O&O Minutes Page 88 BTX-4 BC Blood Group (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field indicates the blood group of the blood component. The preferred values for the blood group are the ISBT 128 specified values in Table 3A - Encodation of Blood Group in the ISBT 128 Bar Code Symbology and Application n Specification. This is a conditional field and is required for blood components. It is not applicable for commercial product messages. Refer to section 4.4.3.11 for the contents of figure x-x. ISBT 128 Table 3A - Encodation of Blood Group. BTX-5 CP Commercial Product (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field contains the code and description to identify a commercial product. Examples of commercial products are blood derivatives, such as Rh Immune Globulin and Factor VIII Concentrate and transfusion accessories, such as Leukoreduction filters, and blood administration sets. User-defined table #### – Commercial product is used as the HL7 identifier for the user-defined table of values for this field. User-defined Table #### – Commercial product Value Description No suggested values This is a conditional field and is required for commercial blood products. It is optional for blood component messages. BTX-6 CP Manufacturer (XON) Definition: This field identifies the manufacturer of the commercial product. The manufacturer may not be the same as the supplier of the commercial product. This is a conditional field and is required for commercial blood products. It is not applicable for blood component messages. BTX-7 CP Lot Number (EI) Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as accessories to transfusion. This is a conditional field and is required for commercial blood products. It is not applicable for blood component messages. BTX-8 BT Quantity (NM) Definition: This field indicates the number of blood bank products or components. BTX-9 BT Amount (NM) Definition: This field contains the ordered amount (volume) associated with each quantity of a blood bank component. This is an optional field. October 2001 O&O Minutes Page 89 BTX-10 BT Units (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field contains the units for the blood product quantity. (See Chapter 7 for more details about identifying reporting units.) This field may be used to specify the units of measure for volume of a blood component (i.e. 50 ml). It may also be used to indicate the unit of measure or dosage of a commercial product (i.e. 910 I.U. - International Units - of Factor VIII Concentrate. BTX-11 BT Transfusion Status (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field is used to indicate the current status of the specified blood product as indicated by the placer. For example, the placer may return the blood product to the transfusion service unused or wasted because an IV could not be started. A final status would indicate that the product has actually been “transfused.” Refer to HL7 Table #### (to be assigned) - Blood Product Transfusion Status for suggested values. HL7 Table #### - Blood Product Transfusion Status Value Description DS Dispensed to patient location RA Returned unused/no longer needed RL Returned unused/keep linked to patient for possible use later WA Wasted (product no longer viable) TX Transfused TR Transfused with adverse reaction BTX-12 BT Observation status (ID) Definition: The most commonly used values in a BTX will be preliminary and final. A status is considered preliminary until a blood product has reached a final disposition for the patient. For example, when the product is first cross-matched and a status message is sent, it would be considered preliminary. When the product is dispensed to the patient, that status would also be considered preliminary. However, once the product is transfused, the status would be considered final. The status of a blood product can continue to change and the previous result should be overwritten until it reaches a final status. Table 0085 - Observation result status codes interpretation Value October 2001 O&O Minutes Description C Record coming over is a correction and thus replaces a final result D Deletes the OBX record F Final results; Can only be changed with a corrected result. I Specimen in lab; results pending N Not asked; used to affirmatively document that the observation identified in the OBX was not sought when the universal service ID in OBR-4 implies that it would be sought. O Order detail description only (no result) P Preliminary results R Results entered -- not verified S Partial results X Results cannot be obtained for this observation U Results status change to final without retransmitting results already sent as ‘preliminary.’ E.g., radiology changes status from preliminary to final W Post original as wrong, e.g., transmitted for wrong patient Page 90 BTX-13 BT Date/time of status (TS) Definition: This field indicates the date and time that the status of the blood component was changed. For example, if the blood component had a status, of "TX" (Transfused), the date and time in this field would indicate the date and time that component was transfused the placer system. BTX-14 BT Administrator (XCN) Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <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)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)> Subcomponents of assigning authority: type (ID) Subcomponents of assigning facility: type (ID) <namespace ID (IS)> & <universal ID (ST)> & <universal ID <namespace ID (IS)> & <universal ID (ST)> & <universal ID Definition: This field contains the identity of the individual who administers the transfusion of the blood product. The identity for the individual is recorded as a XCN data type. If the code is sent as a local code, it should be unique and unambiguous when combined with BPX-250-producer ID. This field can be free text to permit capture without table update. In this case, the administrator’s name must be recorded as the second through fourth components of the field. This field is optional. BTX-15 BT Verifier (XCN) Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <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)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)> Subcomponents of assigning authority: type (ID) Subcomponents of assigning facility: type (ID) <namespace ID (IS)> & <universal ID (ST)> & <universal ID <namespace ID (IS)> & <universal ID (ST)> & <universal ID Definition: This field contains the identity of the individual who assists in the identification of the patient and verification of the product information prior to transfusion of the blood product. The identity for the verifier is recorded as a XCN data type. If the ID Number is sent as a local code, it should be unique and unambiguous when combined with BPX-250-producer ID. This field can be free text to permit capture without table update. In this case, the verifier’s name must be recorded as the second through fourth components of the field. This field is optional. BTX-16 BT Start Date/time of status (TS) Definition: This field indicates the date and time that the verifier started the transfusion of the blood component or commercial product. This is an optional field. BTX-17 BT End Date/time of status (TS) Definition: This field indicates the date and time that the transfusion of the blood component or commercial product was completed or stopped. October 2001 O&O Minutes Page 91 This is an optional field. BTX-18 BT Adverse Reaction Indicator (ID) This field indicates whether the recipient of the blood product experienced an adverse reaction. This is an optional yes/no field. BTX-19 BT Adverse Reaction Type (CE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field contains the type of adverse reaction that the recipient of the blood product experienced. Locally defined codes for this value can be used. This is an optional field. User-defined table #### –Transfusion adverse reaction type is used as the HL7 identifier for the user-defined table of values for this field. User-defined Table #### – Transfusion adverse reaction Value Description No suggested values BTX-20 BT Transfusion Interrupted (ID) This field indicates whether the transfusion of the blood product was interrupted or stopped prior to the completion of the transfusion. This is an optional yes/no field. BTX-21 BT Transfusion Interrupted Reason (CWE) Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> Definition: This field contains the reason that the transfusion of the blood product was interrupted. Locally defined codes for this value can be used. This is an optional field. User-defined table #### – Transfusion interrupted reason is used as the HL7 identifier for the user-defined table of values for this field. User-defined Table #### – Transfusion interrupted reason Value Description No suggested values October 2001 O&O Minutes Page 92 Attachment B – Version 3 Ballot Response Summary Highlighted items are ones we recommend be discussed in Salt Lake City by the relevant committee(s). Items in Green are those we need to make sure we have a response for, since they didn’t come up directly in discussion (that I'm aware of). Practice & Operations ID # Section Vote Type Existing Wording Proposed Wording Comments DM General N Mj See comment See comment The current documentary form contains insufficient usage notes about individual attributes in particular RMIM refined classes (or in the common HMD) to allow any certainty of interoperability. Numerous specific examples can be offered for each of the individual messages where the RIM description of the attribute is too general to be sure of the intended usage in a specific message. A revised documentary form is needed with usage notes available for each attribute of each class in the RMIM. This could most elegantly be provided in an extended version of the common HMD. Until this is available a really informed affirmative vote on this document is not possible. Even though it is possible that the usage intended by the authors is entirely appropriate to the proposed interactions. This usage needs to be made explicit. An example of the problem … Substance_admin_order.max_dose_qty in HMPO_RX_RM01000. What does this maximum dose mean in the order? Is it an instruction that the recipient of the order limits the supply OR indicates on the supplied medication the maximum? The answer may seem self-evident to the authors of the RMIM but it needs to be stated explicitly in relation to these October 2001 O&O Minutes Disposition Page 93 Identif ier ID # Section Vote Type Existing Wording Proposed Wording Comments Disposition Identif ier MnM Issue 1 Description issue. LAPOCT 2 LAPOCT. misundertstood process. 3 LAPOCT Not lab Description issue. LAPOCT 4 Description issue. LAPOCT LAPOCT&OO Combine with discussion of #16. OO 6 MnM issue. Description issue. 9 Description issue. OO, LAPOCT 10 messages to ensure safety and interoperability. Note that this is only example, the primary problem is the restriction of the documentary form. AK 2 N Mi AK 2.1 N Mi AK 2.2 A S AK 2.2 N Mi AK 2.2 N Mi AK 2.3 N Mi AK 2.4 N Mi AK 2.5 N Ma AK 3 N Mi AK 3 N Mi October 2001 O&O Minutes All the CMET names in this section need to be reviewed in light of the CMET naming standard that emerged from the Indianapolis Publishing meeting in July 2001. I think the description of this CMET needs to be beefed up. To just say that it describes the specimen and the container simplifies it to much. It's obvious from the RMIM diagram that a lot of things about specimens, containers, observations about specimens, etc. are included in the CMET. OrderOptions RMIM. There are constraints on the value data type give in the RMIM. The appropriate way to indicate the data type for a given attribute is to place the data type restriction directly in the class, for example: O_ReflexPermission.value: BL Since the value attribute is associated with each Act clone in this CMET, shouldn't the mood be EVN? The description of the Order Options CMET needs to be enhanced to describe what options it provides. Also needs to describe how it should be used. The description of the Reagent CMET needs to be more descriptive. It's currently a circular definition. Since there may be a charge for a transport service, the Financial_txn CMET should be associated with the Transport_clin CMET. The Supporting Clinical Information CMET does not contain any allergy information. Although an allergy is a form of observation, it is not a simple observation, so it's not really supported by the Clinical_observation cloned class in the R-MIM. Scattered throughout the Lab Domain are comments, descriptions, etc. that contain information relating a Version 3 component with something from version 2.x. In general these comments need to re-written to explain the 2.x jargon, so that people not familiar with 2.x can still understand what's been written. In general, the descriptions provided in the Lab Domain are sketchy. They need to be elaborated more, so they better describe the artifact in question. Page 94 5 7 8 ID # Section Vote Type AK 3.1 5.1 N Ma AK 3.1 N Ma AK 3.1.1.1.2 3.1.2.1.2 3.1.3.1.2 N Mi AK 3.1.1.1.2.3 3.1.1.2.2.3 N Mi AK 3.2 N Ma AK 3.3.1 3.3.2 3.3.3 N Mi October 2001 O&O Minutes Existing Wording Proposed Wording Comments Disposition As part of Indianapolis Harmonization meeting, the Act state machine was revised. This has considerable impact on the types and names of interactions used in Lab Orders, Intents, Events and Shared Interactions. In addition, there has been considerable debate on how to name the various individual interactions, such that they uniquely identify the interaction, yet are readable. A naming convention for interactions needs to be worked out amongst the various groups building interaction models. The same issue's occur with Trigger events, since we have derived them from the Act state machine. Most of the Ladder diagrams used for the Storyboards within the Lab Orders Interaction category show a notification message from the filler to a tracker, where the filler is notifying the tracker of the relevant event. This notification should be using the placer application role as the originating application role, not the filler application role. Although the Lab Domain is intended to support LAPOCT, none of the storyboards reflect any LAPOCT messaging. I believe it is critical that LAPOCT supply storyboard examples for the Lab Domain. The Infrastructure part of the ballot current states that an application acknowledgement can't itself require an application acknowledgement, and yet this complex set of interactions appears to require just that. OO, Rx Identif ier 11 OO, LAPOCT 12 OO, LAPOCT 13 OO, Control. Multiple negatives on Infrastructure ballot on this issue. Need to resolve with Control. MnM issue Austin: MnM has resolved this issue to allow App roles to contain other app roles. 14 OO. Combine with discussion of transport CMET (#7) 16 The application Roles for Lab as they are now set up are hierarchical in nature. This means that a child application role can have a single parent application role. In reality they need to be more flexible than that. Instead of a parent/child (or tree) model for application roles, we need to use a more open model, where an application role can fall into several groups of different application roles. The 2.x order message included a BLG segment so the placer could communicate to the filler when to bill for the service being ordered. We need to include the Financial_txn CMET into the Lab RMIM's so we can continue to communicate this information. We will need to submit a vocabulary for the TimingEvent table (which is used with the EIVL data type) to support this addition. Page 95 15 ID # Section Vote Type AK 3.3.1 3.3.2 3.3.3 N Mi AK 3.3.1 3.3.2 3.3.3 N Mi DY Throughout RX P&O N Mi DY 4.1.1.1, 4.1.1.2, 4.1.2.2, 4.1.2.4, 4.1.3.1 N Ma Existing Wording Administration Instance Order Pharmacy Administration Intent DY 4.1.1.1.3 & Throughout entire RX P&O 4.1.3.1.2 N Ma N Ma DY 4.2.25 4.2.24 N Ma DY 4.2.24 4.2.25 N Mj DY October 2001 O&O Minutes Proposed Wording Pharmacy Give (order) The appropriate mood could be added to the end. Pharmacy Administration Order Acknowledgement (Intent). Pharmacy Administration Instance Intent Pharmacy Give Acknowledgement (intent) Pharmacy Administration Event Pharmacy Administration (event) Comments Disposition We need to include the Detailed_diagnosis CMET to the Lab Order, Intent and Event RMIM's. This will allow us to associate the order/intent/event to the diagnosis that required the order in the first place. Act.priority_cd vocabulary is missing. USAM included a vocabulary for priority_cd, but it's never made it into the Vocabulary model. We will need to submit the vocabulary for the next Harmonization. Need interactions for nullified and obsolete states. OO, LAPOCT Identif ier 17 OO, Vocab 18 OO, LAPOCT, Rx. Same as State Machine, #11 MnM issue. Austin: MnM is working on a standard for naming app roles, trigger events, and interactions. There will also be the ability to add 2.x comments for most of the artifacts. 19 Rx 21 Rx 22 Rx 23 OO, Rx, LAPOCT 24 The pharmacy interaction naming standards and Descriptions need to be more informative. The term Administration is used too broadly to represent different concepts. The term ‘Administration’ is used for orders, gives/schedules as well as administrations. I understand the need to correlate the names to the mood but the noun part should describe what the object is. The descriptions use the term administration in a general way. It would help if there was a legend relating the current 3.0 concepts to existing 2.x concepts(or a translation next to the categories and descriptions) This is like learning a new language. For people who already have a primary language they have to translate what they know to the new language. For those who have no language they need the definitions without translation but the definitions need to make sense. We are missing interaction diagrams for all but one interaction, the simple outpatient prescription. All of the administration event storyboard scenarios I submitted are missing. The only storyboard present is for a simple outpatient prescription. Missing sending role interactions for communicating the administration event to order fillers. The pharmacy or filler may need to further act based on the admin event ( charge for a dose, reschedule future schedules, cancel future schedules) based on what is in the admin record. By only communicating to Trackers who only store the data and do not interact or react based on it is unacceptable. There seem to be similar missing interactions throughout the document. Missing receiver request and sender notify role interactions for abort, resume, cancel, hold. Page 96 20 ID # Section Vote Type DY 4.2.33 4.2.34 4.2.33 4.2.34 N Mj N Mi DY 4.3.1.1.1 & Throughout RX HMD N Ma DY 4.3.8 N Mi DY 5 N Ma AK 5 N Mi AK 5 N Mi AK 5.1 N Ma DY October 2001 O&O Minutes Existing Wording Proposed Wording A loosely coupled version of a Pharmacy Order Filler that is only capable of filling orders consisting of single occurrence substance administrations. This type of application relies on the placer application to break complex orders into a series of instance orders. (A looselycoupled application is one where the assumption is there is no shared repository containing information on providers, patients, etc.) Contains the classes, attributes and associations necessary for communicating dispense events Contains the classes, attributes and associations necessary for communicating therapy administration events Comments Disposition Identif ier Missing sender and receiver interactions for cancel, abort, resume, hold and notify activate, notify supercede The Placer may not be able to break the request into single instance orders and the filler may not ONLY handle single instance orders. Is it a different Category (s) responsible when it is a combination of these or do we just need to improve the language here? OO, Rx, LAPOCT Rx 25 In pharmacy order HMDs, the cd attribute domain is listed as ACT_CODE. There is no reference within ACT_CODE to the more granular and required Clinical Drug. This implies that any act code is acceptable for pharmacy orders. The RMIM Admin Event Descriptions all define the event as being for pharmacy dispense events. It should describe it as being for therapy administration events. Rx, Vocab 27 Rx. Description issue. 28 The descriptions provided in the Shared Interactions Domain are insufficient. Scattered throughout the Shared Interactions Domain are comments, descriptions, etc. that contain information relating a Version 3 component with something from version 2.x. In general these comments need to be re-written to explain the 2.x jargon, so that people not familiar with 2.x can still understand what's been written. In general, the descriptions provided in the Shared Interactions Domain are sketchy. They need to be elaborated more, so they better describe the artifact in question. Many of the Ladder diagrams used for the Storyboards within the Shared Interaction domain show a notification message from the filler to a tracker, where the filler is notifying the tracker of the relevant event. This notification should be using the placer application role as the originating application role, not the filler application role. MnM issue. Same as #30. MnM issue. Same as #29. 29 MnM issue. 31 OO, Rx, LAPOCT Same as #12. 32 Page 97 26 30 ID # Section Vote Type AK 5.1.1.1.2 5.1.2.1.2 5.1.3.1.2 N Ma AK 5.3.2 N Mi HB All N Mj HB All N Mj HB N Mj HB 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.3.1, 3.3.2, 3.3.3, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.3.7, 4.3.8, 4.3.9 All N Mi HB 2.6 N Mj HB 2.8.,2.9 N Mi October 2001 O&O Minutes Existing Wording Proposed Wording Comments Disposition None of the Storyboards for Shared Interactions have Storyboard examples. Although the narrative for the examples aren't normative, it is critical to understanding the interactions. We need to iron out with Control what and application Accept/Reject message payload should look like. OO, Rx, LAPOCT Control, OO, Rx. This was negatively balloted on infrastructure. Need to harmonize the approach to using accept/rejects. Description issue. 34 OO & LAPOCT 36 MnM issue. 37 References to vocabulary are largely missing, compounding the difficulty to read the diagrams and subsequent text. The application focused implementation suggestion is inappropriate for HL7 to document as part of normative material. Publications 38 OO, LAPOCT 39 The distinction between Packaged Medication and Rx 40 Significant work has taken place to move V3 forward. As the document shows, much has been put in place, but more is necessary to make the scope implementable. Descriptions should contain examples as use cases don't really provide concrete examples on how things work. They provide reasonable context on why messages must exist in a particular area, but not how messages are ultimately derived on. Changes have occurred since the initial ballot issue without substantial committee review, forcing reviewers to work with a moving target. Extension of the review does not adequately address this issue. The respective RMIMs are difficult to read and understand without comprehensive narrative to enable the reader to map their data sets into the HL7 V3 data set, and do that unambigously. Even if one participated in all discussions, this is not clear. Implementation Suggestion: If note_txt is present, an application should display an indicator, and allow the user to view the full text on request. Implementation Suggestion: If note_txt is present, an application should display an indicator, and allow the user to view the full text on request. Identif ier 33 Page 98 35 ID # Section Vote Type Existing Wording HB 3 N Mi Medicinal Product is not clear. The reference to Common Clinical Domain is unclear as it is not clear where that is documented. HB 3.1.1 S The description is not clear on who is doing what. HB 3.1.1.1 N Mi HB 3.1.1.1.1 A S We need to figure out a way to tie these closer to the story boards. HB All A S The document structure (sequencing) does not feel comfortable yet. It is difficult to easily jump between trigger events, interactions, application roles, etc., and tie it easily together to understand whether it all fits. We recognize that there are issues with different sequences as well. We need to be open to adjust sequencing as we go until we settle on the most comfortable one. The number of trigger events and messages has been greatly expanded by the specification of both closely and loosely coupled versions. This differentiation should not be specified at the trigger event/storyboard/interaction level. Universal use of closely vs loosely coupled CMETs will improve this situation. Also are there more than two states ‘closely’ and ‘loosely’ ??? The storyboard examples used by HL7 were considered to be too simple – we found some transitions were missing (e.g. a set of messages in prescriptions). We suggest that consistent use of state transition diagrams linked to storyboards and interaction cascades would be a useful documentation and educative tool. We will provide an example for this (e.g. a pathology example) Systems that are closelycoupled assume that a shared repository of provider, patient, protocol, and other “masterfile” type information exists between sender and receiver. MB Mj Closely vs loosely coupled system interactions MB Mj State transition diagrams & storyboards October 2001 O&O Minutes Proposed Wording Systems that are closely-coupled assume that a shared repository vocabulary of provider, patient, protocol, and other “master-file” type information exists between sender and receiver. Comments We need a definition of what a "shared repository" means. It does not have to be a physically shared repository, but rather a virtually shared set of vocabulary. Page 99 Disposition Identif ier OO Common Clinical is now known as Shared Interactions. OO, LAPOCT. Documentation Issue. OO, Rx, LAPOCT 41 Publications, Desrciption issue. Publication 44 OO, Rx, LAPOCT 46 Description issue. Publications 47 42 43 45 ID # Section Type Existing Wording MB Mj State transition diagrams & storyboards MB Mi Shared care and community health support MB Mi Clinical content MB Mj Context sensitive description of classes in an R-MIM MB Mj More context-sensitive explanatory/descriptive information needs to be included for every attribute in an HMD (as is currently the case for every field of an HL7 2.x message). MB Mj Navigation of documentation is time-consuming and laborious. October 2001 O&O Minutes Vote Proposed Wording Comments Disposition The storyboard examples used by HL7 were considered to be too simple – we found some transitions were missing (e.g. a set of messages in prescriptions). We suggest that consistent use of state transition diagrams linked to storyboards and interaction cascades would be a useful documentation and educative tool. We will provide an example for this (e.g. a pathology example) Would like to see use cases developed through to CMETs and messages by the Community Health and Patient Care TC We would like to see the timetable for the inclusion of more clinical domains. Description issue. Publications Clinical referral is not represented – we would like to see continuation of this as a joint work item for Patient Care and Orders/ Observations TCs as begun in January 2001. While we could come to a "theoretical" resolve on where some data could fit using the classes available for Pathology, we were also not completely certain that our findings were correct. In the Lab Filler Event Super R-MIM there are 5 classes derived from the observation act. The usage of some of these classes is hard to determine. Eg ObservationEvent, Obs_order_intent, Observation_event_master. A commentary explanation of the usage of each of the classes in each R-MIM would be helpful. Identifiers used in the HMDs are abstract. E.g. In the HMD for the Lab Filler Event some attributes require further description such as, ‘cd’, ‘id’ and ‘txt’. E.g. Multiple usage (interval or discrete time) of the attribute ‘activity_time’. Automatic Linking from an HMD to a specification for a referenced CMET would be helpful. Indexing of individual CMETs would help in navigation of the document. Page 100 Identif ier 48 MnM issue. Patient Care, Community Health need to answer question about their timetables for content. OO, Referrals.. Expansion in scope. 49 MnM issue. OO 51 Publication, MnM issue. 52 Publications 53 50 ID # Section Comments Disposition Pathology order/results grouping (and numbering of groups) – not well defined Could be represented using the AR_component or AR_fulfills Will provide detailed storyboards How do I relate that a single specimen and colony count can have multiple organisms which in turn can have multiple test results (sensitivities) OO, LAPOCT. Is Pathology in our current scope? Mj Multiple addresses for receipt of pathology results Does not handle multiple addresses. Will provide detailed storyboards 55 MB Q Result copies to multiple recipients How do you do OBR-28 ?? MB Q MB MB Q Q Radiology (handling link reports) Allergies Vaccination What is the status of consultation with North American College of Radiologists and DICOM? It is not clear how reaction nor severity are represented. It is not clear how this is managed. OO, LAPOCT. Associated with #56. Is Pathology in our current scope. OO, LAPOCT. Associated with #55. Imaging Integration Duplicate of #8. Rx MB Q Print supression in microbiology report messages` Where is this information included in a message, how is it transmitted? OO, LAPOCT. Application issue to determine, not an interface standard issue. 60 Mi Inconsistencies Mi *HMPO_LB_TE20011: Supersede Complete Lab Event, Loosely-coupled HMPO_LB_TE20012: Complete Lab Event, Looselycoupled *HMPO_LB_ST20011: Complete Lab Event, looselycoupled HMPO_LB_ST20012: Supersede Complete Lab Event, loosely-coupled Numbering of trigger events and Storyboards inconsistent for Supercede and Complete lab events Similar for Closely coupled equivalents OO. Needs research, and will be addressed during general clean up. MB MB infrastructu re MB MB 3.1.3.2.1 3.1.3.2.2 October 2001 O&O Minutes Vote Type Existing Wording Mj Proposed Wording Identif ier 54 56 57 58 59 61 Page 101 62 ID # Section MB 3.1.3.2.1.1 3.1.3.2.2.1 Vote Type Existing Wording Mi Trigger Event: Activate Lab Event, Loosely-coupled (HMPO_LB_TE20007) “The closest 2.x equivalent is a result status of I … or S ...” MB 3.1.3.2.1.2 3.1.3.2.2.2 Mi MB 3.1.3.2.1.3 3.1.3.2.2.3 Mi Story Board: Activate Lab Event, loosely-coupled (HMPO_LB_ST20007) “This would be the equivalent of … a result status of "I" ...” *Trigger Event: Preliminary Lab Event, Loosely-coupled (HMPO_LB_TE20008) “This would be the equivalent of … a result status of P” Storyboard: Preliminary Lab Event, loosely-coupled (HMPO_LB_ST20008) “This would be the equivalent of … a result status of "A" … or "P" Trigger Event: Revise Active Lab Event, Loosely-coupled (HMPO_LB_TE20009) “This would be the equivalent of … a result status of P” Proposed Wording Comments Disposition OO. Needs research, and will be addressed during general clean up. Identif ier 63 Trigger event and Story board descriptions inconsistent Only the P case is considered in the first instance, both A and P are discussed in the second. OO. Needs research, and will be addressed during general clean up. 64 Trigger event and Story board descriptions inconsistent Note that while only the P case is considered in the first instance, both A and P are discussed in the second. OO. Needs research, and will be addressed during general clean up. 65 MnM issue 66 Storyboard: Revise Active Lab Event, loosely-coupled (HMPO_LB_ST20009) “This would be the equivalent of … a result status of "A" … or "P" ...” BD General October 2001 O&O Minutes N Mj We need some type of narrative description of the clones. Often times I can’t fully understand their intent just by looking at the name of the clone. (It may be that if I studied the interactions and scenarios, these clones would make sense, but I didn’t have a chance to study the ballot in Page 102 ID # Section Vote Type BD 2.1 Specimen CMET N Mj BD 2.1 Specimen CMET 2.2 Order Options CMET 2.3 Reagents CMET N Mj N Mj A Q BD 2.5 Supporting Clinical Information CMET N Mj BD 2.6 Detailed diagnosis CMET A Q BD BD October 2001 O&O Minutes Existing Wording Proposed Wording Comments that much detail. Still, I think a narrative blurb about each clone would be useful.) Don’t understand the purpose of the SA_DurgInterference clone. I imagine this means some drug interferes somehow with the specimen? Don’t understand the A_Registration clone or why you’d register a container. Don’t understand O_DiluentEndoConc clone How come there’s no little cd attribute in MM_Reagent? How do you know what the reagent is? method_cd should be CE rather than CV. In general, all attributes with a CWE domain need to be CE rather than CV. CWE domains allow local implementations to create their own vocabulary terms. Even after some of these terms become standardized, institutions will need to transmit their local values (in addition to the standard values). All CWE domains that are of type CV should be carefully reviewed. (The same holds true for all R-MIMs where this attribute is used). neither this CMET nor the Supporting Clinical Information CMET use the Act_relationship class. Does that mean that ALL complex diagnoses are supposed to use the Act.value? For example, we were recently asked guidance on how to represent things like “persistent neutropenic fever despite amphotericin”, “chronic, recurrent sinusitis Page 103 Disposition Identif ier Description issue. LAPOCT 67 Description issue. LAPOCT. Description issue. LAPOCT 68 LAPOCT 70 OO. Bob Dolin has a general issue with CE's vs. CV's. We need to come up with a general answer for this. 71 OO. 72 69 ID # Section Vote Type BD 2.6 Detailed diagnosis CMET N Mj BD 2.9 Medicinal Product CMET N Mj BD 3.1.1 Scenario N Mi BD 3.3.1 Lab Order Super RMIM N Mj October 2001 O&O Minutes Existing Wording Proposed Wording Comments with frontal sinus mucous retention cyst”. The lower cardinality of P_responsible_parties should be 0 instead of 1. We don’t usually record this information when simply filling in the “indications” box when submitting an order. form_cd should be CE rather than CV. In general, all attributes with a CWE domain need to be CE rather than CV. CWE domains allow local implementations to create their own vocabulary terms. Even after some of these terms become standardized, institutions will need to transmit their local values (in addition to the standard values). All CWE domains that are of type CV should be carefully reviewed. (The same holds true for all R-MIMs where this attribute is used). The scenario is not medically accurate. Would not typically order a PSA (especially STAT) in the setting of suspected prostatitis, as it might be elevated due to inflammation. A renal ultrasound looking for the cause of a urinary tract infection in a male wouldn’t show the prostrate – you’d need a rectal ultrasound, which wouldn’t be indicated. You need a biopsy to diagnosis prostate cancer – not just a PSA, sono, and DRE. The ObservationOrder does not have a “cd” attribute, nor does the Observation_order_master clone. How will the lab know what is ordered? I’m not sure I agree with making the lower Page 104 Disposition Identif ier O/O 73 OO. Bob Dolin has a general issue with CE's vs. CV's. We need to come up with a general answer for this. 74 OO. Storyboard narrative not medically accurate. In general, the Lab Order storyboards did not receive clinical review. 75 OO & LAPOCT 76 ID # Section Vote Type BD 3.3.1 Lab Order Super RMIM N Mj BD 3.3.3 Lab Event A Q October 2001 O&O Minutes Existing Wording Proposed Wording Comments cardinality to AR_instantiates be a 1. Are you sure people ONLY order off a service master? Can’t a simply order a LOINC observation? I would have thought that you need a “cd” attribute in both the ObservationOrder and the Observation_order_master clones, and the link to AR_instantiates should not be mandatory. Note that while we typically DO order off a service master, when necessary we can order stuff that is not on the service master – such as special send-out tests that have to go to the CDC or state public health department. So I don’t think it’s correct to require that every orderable be required to be drawn from the service master. (The same holds true for the Lab Filler Intent Super R-MIM in 3.3.2). priorty_cd should be CE rather than CV. In general, all attributes with a CWE domain need to be CE rather than CV. CWE domains allow local implementations to create their own vocabulary terms. Even after some of these terms become standardized, institutions will need to transmit their local values (in addition to the standard values). All CWE domains that are of type CV should be carefully reviewed. (The same holds true for the Lab Filler Intent Super R-MIM in 3.3.2 and Lab Event Super R-MIM in 3.3.3 and for all other RMIMs). Why does ObservationEvent.cd show “(LOINC code)” in the Page 105 Disposition Identif ier OO. Bob Dolin has a general issue with CE's vs. CV's. We need to come up with a general answer for this. 77 Descritption issue. Need to 78 ID # Section Vote Type Super RMIM Existing Wording Proposed Wording Comments Disposition VISIO diagram? If this is just meant as an example, than ok. BD 4.3.1 Pharmacy Order RMIM A Q SR Practice & Observatio ns N S SR Practice & Observatio ns 3 N Mj LM General N Ma LM General N LM General LM LM add e.g. to front of LOINC to make t clear it's an example. Rx Why is the cardinality to P_subject 1 to many rather than just 1 to 1? Wouldn’t you need to specify a distinct order for each subject? Identif ier 79 For those portions of the document that were reviewed, the general consensus within Kaiser was that additional editing would be useful to improve the understandability of the document. At this time, we have only one specific example to offer, but we are willing to work with the editors and submit suggestions and additional storyboards as they can be defined. While Observation.interpretation_cd is of data type SET<CS>, the domain is ObservationInterpretation(CWE). But the description of CS states " the designation of the domain qualifier will always be CNE." This appears to be a conflict within the standard. We need to incorporate the pharmacy storyboards that were submitted into the ballot framework. OO, LAPOCT, Rx. 80 OO, LAPOCT 81 Rx 82 Ma We need substantially stronger descriptions 83 N Ma General N Ma Rx 85 General N Ma We need a way to handle the identification of contraindications associated with a particular order, as well as an optional indication of the management actions taken. We need a means to request an event. For example: Physician sends request to community pharmacy to dispense against an existing order. We need to do substantial work on vocabulary, particularly the various Act.cd domains. We need to align our use of Accept vs. Notify messages with the approach of Lab. (I believe both have the same trigger event, and message type, but will have different message wrappers and different receiving roles.) Description issue. Rx OO, LAPOCT, Rx, Vocab. Duplicate of #34. 86 LM October 2001 O&O Minutes 3.1.3 Parent category: Lab Event (HMPO_LB_IC20001) Page 106 84 87 DM – David Markwell AK - Austin Kreisler DY - Daphne Young HB - Hans Buitendijk MB - Maree Bellamy BD - Bob Dolin SR - Scott Robertson LM - Lloyd McKenzie October 2001 O&O Minutes Page 107