BALLOT TITLE: HL7 Version 2
BALLOT TITLE: HL7 Version 2.4 (Membership Ballot)
|ID # |Submitter |Section |Vote |Type |Existing Wording |Proposed Wording |Comments |Disp. |ID |
| |Susan Abernathy |3.3.9.16 |A |S,Q,T |User-defined Table 0441-Immunization |Change "I" code to "N." |This is a user-defined table. This|8 |Membership |
| | | | | |registry status has values suggested for | |change would help to avoid | |Ballot #1 |
| | | | | |use by registries. We had originally | |confusion among the various | | |
| | | | | |requested that the value for the second | |"Inactive" categories and would be | | |
| | | | | |item, Inactive, be "N" rather than "I". I| |consistent with usage documents we | | |
| | | | | |believe the discussion indicated that "I" | |distributed under Version 2.3.1 | | |
| | | | | |is usually used for Inactive in HL7 | |before this TC had a chance to | | |
| | | | | |tables, and "I" is the code in the table | |consider it. | | |
| | | | | |now. However, we now have 4 inactive | | | | |
| | | | | |codes, so I request that the committee | | | | |
| | | | | |consider changing the "I" to "N" to avoid | | | | |
| | | | | |confusion and to make it consistent with | | | | |
| | | | | |usage documents we have distributed. | | | | |
| |Susan Abernathy |4.17 |N |Mj |Cut/paste did not work well because |We have used revision marks in the |Previously submitted revisions were| | |
| | | | | |formatting was lot or changed. I am |attached zipped file. Our additions are |not incorporated correctly. | | |
| | | | | |attaching a zipped version of the entire |colored red to make them easier to see. | | | |
| | | | | |Chapter 4, but our revisions only affect | | | | |
| | | | | |Section 4.17. We have changes throughout | | | | |
| | | | | |Section 4.17 that were previously | | | | |
| | | | | |submitted but were not made or were made | | | | |
| | | | | |incorrectly. We submitted the CVX table | | | | |
| | | | | |exactly as it should be published, but it | | | | |
| | | | | |appears to have been re-typed with errors | | | | |
| | | | | |and omissions. If published this way, it | | | | |
| | | | | |would reflect negatively on us. Please | | | | |
| | | | | |ensure that everything in the table and | | | | |
| | | | | |the usage notes is exactly as submitted. | | | | |
| | | | | |If possible, please paste this version | | | | |
| | | | | |into the file rather than retype or try to| | | | |
| | | | | |correct the old one. | | | | |
| |Jos Baptist |2.8.12.5 |N |Mi |Missing codes in table 0203 Identifier |Add those codes in table 0203 Identifier |In the San Diego-ballot version of | | |
| | | | | |Type |Type. |chapter 3 table 0203 was listed in | | |
| | | | | | | |chapter 3 with those new identifier| | |
| | | | | | |USSSN |type codes. Those additions were | | |
| | | | | | |US Social Security Number |lost in the membership ballot. | | |
| | | | | | | | | | |
| | | | | | |CAJHN | | | |
| | | | | | |Canadian Jurisdictional Health Number | | | |
| | | | | | | | | | |
| | | | | | |AUSMC | | | |
| | | | | | |Australian Medicare Number | | | |
| | | | | | | | | | |
| | | | | | |AUSPN | | | |
| | | | | | |Australian Pension Number | | | |
| | | | | | | | | | |
| | | | | | |AUSHC | | | |
| | | | | | |Australian Health Card Number | | | |
| | | | | | | | | | |
| | | | | | |AUSWC | | | |
| | | | | | |Australian Workers’ Comp Number | | | |
| | | | | | | | | | |
| | | | | | |BA | | | |
| | | | | | |Bank Account Number | | | |
| | | | | | | | | | |
| | | | | | |DR | | | |
| | | | | | |Donor Registration Number | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| |Jos Baptist |2.15.9.9 |N |Mi |Missing ADT events in table 0003 Event |Add: |Inconsistent with Chapter 3 | | |
| | | | | |type |A60 update allergy information | | | |
| | | | | | |A61 change consulting doctor | | | |
| | | | | | |A62 cancel change consulting doctor | | | |
| |Jos Baptist |3.2.x |N |Mi |The ROL – Role Segment is used in this |Addition: |Since the ROL segment is now also | | |
| | | | | |message to communicate providers not |Also use ROL-5 - Role Begin Date/Time and |to be used for the patient’s | | |
| | | | | |specified elsewhere. Person level |the ROL-6 - Role End Date/Time in the ROL |Primary Care Providers, it’s only | | |
| | | | | |providers with an ongoing relationship are|segment for the start and end of the |consistent to handle the begin- and| | |
| | | | | |reported in the ROL segment following the |PCP-roles |end-date/time in the same way as | | |
| | | | | |PID segment. Visit level providers | |the attending, referring, and | | |
| | | | | |(corresponding to the PV1 data) are | |admitting doctor | | |
| | | | | |reported in the ROL segment following the | | | | |
| | | | | |PV1 segment. Providers related to a | | | | |
| | | | | |specific procedure are reported in the ROL| | | | |
| | | | | |segment following the PR1 segment. To | | | | |
| | | | | |communicate the begin and end date of the | | | | |
| | | | | |attending, referring, or admitting doctor,| | | | |
| | | | | |use the ROL-5 - Role Begin Date/Time and | | | | |
| | | | | |the ROL-6 - Role End Date/Time in the ROL | | | | |
| | | | | |segment following the PV1 segment, with | | | | |
| | | | | |the applicable ROL-3 - Role code. Refer | | | | |
| | | | | |to section 12.3.3 for additional | | | | |
| | | | | |information | | | | |
| |Jos Baptist |3.2.x |A |Mi |The ROL – Role Segment is used in this …….| |Maybe this section about the role | | |
| | | | | |Refer to section 12.3.3 for additional | |segment should only be added in | | |
| | | | | |information | |descriptions of those trigger | | |
| | | | | | | |events that may communicate a | | |
| | | | | | | |change in a role of a provider. | | |
| |Jos Baptist |12.3.3.3 |N |Mi |Missing code for ‘Consulting Doctor’ in |Add ‘CO – Consulting Doctor’ to the table |In San Diego was agreed upon adding| | |
| | | | | |table 0443 Role Code | |CO for Consulting Doctor (see the | | |
| | | | | | | |minutes of the Patient Care San | | |
| | | | | | | |Diego meeting) | | |
| |Tim Escher |3.2.56 |Y |Typo |Event is A56 |Should be events Q21 and K21 | | | |
| |Tim Escher |3.5.4 |Y |Typo |References to section 6.4.X throughout |References need to be changed to 3.5.4.X | | | |
| |Tim Escher |3.5.4.7 |Y |Typo |Figure 3-5 has event K23 |Should be event K24 | | | |
| |Tim Escher |3.5.4.8 |Y |Typo |Figure 3-6 is the wrong picture |Should use the deleted one with the | | | |
| | | | | | |Q22/K22, and Q21/K21 events | | | |
| |Tim Escher |3.5.4.9 |Y |Typo |Figure 3-7 has AXX and KXX events |Should be A56 and K24 | | | |
| |Freida Hall |2.8.5.4 |A |Ti |User defined Table 0363 has no suggested |Insert the table values from Chapter 3 | | | |
| | |2.8.7.9 | | |values. |(3.3.2.3), at least in the first | | | |
| | |2.8.12.4 | | | |occurrence (2.8.5.4) | | | |
| | |2.8.17.2 | | | | | | | |
| | |2.8.32.9 | | | | | | | |
| | |2.8.53.9 | | | | | | | |
| | |2.8.54.6 | | | | | | | |
| |Freida Hall |2.8.32.14 |A |T |2.8.12.5 |A code corresponding to the type of |Table 0203 was changed to an HL7 | | |
| | |2.8.53.14 | | |A code corresponding to the type of |identifier. In some cases, this code may |Table in 2.8.12.5. | | |
| | |2.8.54.7 | | |identifier. In some cases, this code may |be used as a qualifier to the “Assigning |The other three occurrences of the | | |
| | | | | |be used as a qualifier to the “Assigning |authority” component. Refer to |table need to be changed from | | |
| | | | | |authority” component. Refer to HL7 Table |User-defined Table 0203 - Identifier type |User-defined to HL7. | | |
| | | | | |0203 - Identifier type for suggested |for suggested values. | | | |
| | | | | |values. | | | | |
| |Freida Hall |3.2.1 |A |T |The ROL – Role Segment is used in this |The ROL – Role Segment is used in this |The ROL segment follows the PD1, | | |
| | |3.2.2 | | |message to communicate providers not |message to communicate providers not |not the PID. | | |
| | |3.2.3 | | |specified elsewhere. Person level |specified elsewhere. Person level | | | |
| | |3.2.4 | | |providers with an ongoing relationship are|providers with an ongoing relationship are| | | |
| | |3.2.5 | | |reported in the ROL segment following the |reported in the ROL segment following the | | | |
| | |3.2.6 | | |PID segment. Visit level providers |PD1 segment. Visit level providers | | | |
| | |3.2.7 | | |(corresponding to the PV1 data) are |(corresponding to the PV1 data) are | | | |
| | |3.2.8 | | |reported in the ROL segment following the |reported in the ROL segment following the | | | |
| | |3.2.13 | | |PV1 segment. Providers related to a |PV1 segment. Providers related to a | | | |
| | |3.2.14 | | |specific procedure are reported in the ROL|specific procedure are reported in the ROL| | | |
| | |3.2.15 | | |segment following the PR1 segment. To |segment following the PR1 segment. To | | | |
| | |3.2.16 | | |communicate the begin and end date of the |communicate the begin and end date of the | | | |
| | |3.2.19 | | |attending, referring, or admitting doctor,|attending, referring, or admitting doctor,| | | |
| | |3.2.28 | | |use the ROL-5 - Role Begin Date/Time and |use the ROL-5 - Role Begin Date/Time and | | | |
| | | | | |the ROL-6 - Role End Date/Time in the ROL |the ROL-6 - Role End Date/Time in the ROL | | | |
| | | | | |segment following the PV1 segment, with |segment following the PV1 segment, with | | | |
| | | | | |the applicable ROL-3 - Role code. Refer |the applicable ROL-3 - Role code. Refer | | | |
| | | | | |to section 12.3.3 for additional |to section 12.3.3 for additional | | | |
| | | | | |information. |information. | | | |
| |Freida Hall |3.2.2 |A |T |The ROL – Role Segment is used in this |The ROL – Role Segment is used in this |Remove reference to the PR1 | | |
| | |3.2.15 | | |message to communicate providers not |message to communicate providers not |segment; there is no PR1 segment in| | |
| | |3.2.16 | | |specified elsewhere. Person level |specified elsewhere. Person level |this message. | | |
| | | | | |providers with an ongoing relationship are|providers with an ongoing relationship are| | | |
| | | | | |reported in the ROL segment following the |reported in the ROL segment following the | | | |
| | | | | |PID segment. Visit level providers |PID segment. Visit level providers | | | |
| | | | | |(corresponding to the PV1 data) are |(corresponding to the PV1 data) are | | | |
| | | | | |reported in the ROL segment following the |reported in the ROL segment following the | | | |
| | | | | |PV1 segment. Providers related to a |PV1 segment.To communicate the begin and | | | |
| | | | | |specific procedure are reported in the ROL|end date of the attending, referring, or | | | |
| | | | | |segment following the PR1 segment. To |admitting doctor, use the ROL-5 - Role | | | |
| | | | | |communicate the begin and end date of the |Begin Date/Time and the ROL-6 - Role End | | | |
| | | | | |attending, referring, or admitting doctor,|Date/Time in the ROL segment following the| | | |
| | | | | |use the ROL-5 - Role Begin Date/Time and |PV1 segment, with the applicable ROL-3 - | | | |
| | | | | |the ROL-6 - Role End Date/Time in the ROL |Role code. Refer to section 12.3.3 for | | | |
| | | | | |segment following the PV1 segment, with |additional information. | | | |
| | | | | |the applicable ROL-3 - Role code. Refer | | | | |
| | | | | |to section 12.3.3 for additional | | | | |
| | | | | |information. | | | | |
| |Freida Hall |3.2.52 |A |T |It is recommended that field EVN-6 contain|It is recommended that field EVN-6 – Event|Add field name for EVN-6 and | | |
| | | | | |the date/time this event actually occurred|Occurredcontain the date/time this event |PV2-47and change to italics for | | |
| | | | | |to the patient. On an A52 it should have |actually occurred to the patient. On an |consistency with the rest of the | | |
| | | | | |LOA cancellation date/time. A new field |A52 it should have LOA cancellation |chapter. | | |
| | | | | |PV2-47 will be used in this message to |date/time. A new field PV2-47- Expected | | | |
| | | | | |communicate the LOA expected return |LOA Return Date/Time will be used in this | | | |
| | | | | |date/time. |message to communicate the LOA expected | | | |
| | | | | | |return date/time. | | | |
| |Freida Hall |3.2.53 |A |T |It is recommended that field EVN-6 contain|It is recommended that field EVN-6 - Event|Add field name for EVN-6 and | | |
| | | | | |the date/time this event actually occurred|Occurred contain the date/time this event |PV2-47and change to italics for | | |
| | | | | |to the patient. On an A53 it should have |actually occurred to the patient. On an |consistency with the rest of the | | |
| | | | | |the date the LOA return was cancelled. |A53 it should have the date the LOA return|chapter.. | | |
| | | | | |A new field PV2-47 will be used in this |was cancelled. | | | |
| | | | | |message to communicate the LOA expected |A new field PV2-47 -Expected LOA/Return | | | |
| | | | | |return date/time. |Date/Time will be used in this message to | | | |
| | | | | | |communicate the LOA expected return | | | |
| | | | | | |date/time. | | | |
| |Freida Hall |3.2.61 |A |T |The new consulting doctor(s) of the |The new consulting doctor(s) of the |Add edit/field names and change to | | |
| | | | | |patient should appear in the |patient should appear in the PV1-9 - |italics. | | |
| | | | | |PV1-9-consulting doctor and may appear in |Consulting Doctor and may appear in a role| | | |
| | | | | |a role segment per new consulting doctor. |segment per new consulting doctor. | | | |
| | | | | |If a consulting doctor stops being |If a consulting doctor stops being | | | |
| | | | | |consulting doctor for this patient-visit, |consulting doctor for this patient-visit, | | | |
| | | | | |the end date/time can be sent in the ROL-6|the end date/time can be sent in the ROL-6| | | |
| | | | | |Role End Date/Time |- Role End Date/Time | | | |
| | | | | | | | | | |
| | | | | |It is recommended that field EVN-6 |It is recommended that field EVN-6 – Event| | | |
| | | | | |contains the date/time the event actually |Occurred contains the date/time the event | | | |
| | | | | |occurred to the patient. |actually occurred to the patient. | | | |
| |Freida Hall |3.2.62 |A |T |The A62 event is sent when an A61 (change |The A62 event is sent when an A61 (change |Edit field name and change to | | |
| | | | | |consulting doctor) event is cancelled, |consulting doctor) event is cancelled, |italics. | | |
| | | | | |either because of erroneous entry of the |either because of erroneous entry of the | | | |
| | | | | |A61 event or because of a decision not to |A61 event or because of a decision not to | | | |
| | | | | |change the consulting doctor after all. |change the consulting doctor after all. | | | |
| | | | | |PV1-9-consulting doctor must show the |PV1-9 - Consulting Doctor must show the | | | |
| | | | | |patient's doctor prior to the original |patient's doctor prior to the original | | | |
| | | | | |hand-over. |hand-over. | | | |
| |Freida Hall |3.3.3.7 |A |T |Definition: This field identifies the |Definition: This field identifies the |Add field name and change to | | |
| | | | | |actual facility where the event occured as|actual facility where the event occured as|italics. | | |
| | | | | |differentiated from the sending facility |differentiated from the sending facility | | | |
| | | | | |(MSH-4). It would be the facility at |(MSH-4 – Sending Facility). It would be | | | |
| | | | | |which the Operator (EVN-5) has entered the|the facility at which the Operator (EVN-5 | | | |
| | | | | |event. |– Operator ID) has entered the event. | | | |
| |Freida Hall |3.3.3 |A |T |HL7 Attribute Table for PID-28 Nationality|Change “O” in OPT column to “B”. |The field note indicates the field | | |
| | | | | |indicates O (optional).. | |is retained for backward | | |
| | | | | | | |compatibility. | | |
| |Freida Hall |No number-end of PID|A |T |The two paragraphs regarding assigning | |Move the Usage Note paragraphs to | | |
| | |segment | | |authority have had the sectiono number | |the beginning of the PID segment. | | |
| | | | | |removed, so they now appear related to | | | | |
| | | | | |3.3.2.38. | | | | |
| |Freida Hall |3.3.4.53 |A |T |3.3.3.53 PV1 usage notes | |Move the usage notes preceding the | | |
| | | | | |The facility ID, the optional fourth | |segment. | | |
| | | | | |component of each patient location field, | | | | |
| | | | | |is a HD data type that is uniquely | | | | |
| | | | | |associated with the healthcare facility | | | | |
| | | | | |containing the location. A given | | | | |
| | | | | |institution, or group of | | | | |
| | | | | |intercommunicating institutions, should | | | | |
| | | | | |establish a list of facilities that may be| | | | |
| | | | | |potential assignors of patient locations. | | | | |
| | | | | |The list will be one of the institution’s | | | | |
| | | | | |master dictionary lists. Since third | | | | |
| | | | | |parties other than the assignors of | | | | |
| | | | | |patient locations may send or receive HL7 | | | | |
| | | | | |messages containing patient locations, the| | | | |
| | | | | |facility ID in the patient location may | | | | |
| | | | | |not be the same as that implied by the | | | | |
| | | | | |sending and receiving systems identified | | | | |
| | | | | |in the MSH. The facility ID must be | | | | |
| | | | | |unique across facilities at a given site. | | | | |
| | | | | |This field is required for HL7 | | | | |
| | | | | |implementations that have more than a | | | | |
| | | | | |single healthcare facility with bed | | | | |
| | | | | |locations, since the same | | | | |
| | | | | |^ ^ combination may exist at | | | | |
| | | | | |more than one facility. | | | | |
| |Freida Hall |3.3.3.12 |A |T |Refer to User-defined Table 0289 - |N/a see comment. |Add empty table. | | |
| | | | | |County/parish for suggested values | | | | |
| |Freida Hall |3.3.3.24 |A |Q |Definition: This field indicates whether |N/a see comment. |Add Y/N table. Y-patient is part | | |
| | | | | |the patient was part of a multiple birth. | |of multiple birth. N-patient is | | |
| | | | | |Refer to HL7 Table 0136 - Yes/No Indicator| |not part of multiple birth. | | |
| | | | | |in Chapter 2. | | | | |
| |Freida Hall |3.3.3.28 |A |T |Definition: This field contains a code |N/a see comment. |Add empty table for user defined | | |
| | | | | |that identifies the nation or national | |table 0212 for consistency (field | | |
| | | | | |grouping to which the person belongs. | |is flagged for backward | | |
| | | | | |This information may be different from a | |compatibility, but has a table | | |
| | | | | |person’s citizenship in countries in which| |number assigned.). | | |
| | | | | |multiple nationalities are recognized (for| | | | |
| | | | | |example, Spain: Basque, Catalan, etc.). | | | | |
| |Freida Hall |3.3.4 |A |T |HL7 Attribute Table – PV1, Field 50 (table|N/a see comment. |Table 0203 is a data type table, | | |
| | | | | |# 0203) | |not a field level table, and | | |
| | | | | | | |therefore should not be referenced | | |
| | | | | | | |in the PV1 attribute table. | | |
| |Freida Hall |3.3.5.2 |A |T |Refer to User-defined Table 0129 - |N/a see comment. |Add empty table. | | |
| | | | | |Accommodation code for suggested values. | | | | |
| |Freida Hall |3.3.5.15 |A |Q |Definition: This field specifies whether |N/a see comment. |Add Y/N table. Y-illness is job | | |
| | | | | |a patient’s illness was job-related. | |related. N-illness is not job | | |
| | | | | |Refer to Chapter 2, HL7 Table 0136 - | |related. | | |
| | | | | |Yes/no indicator for valid values. | | | | |
| |Freida Hall |3.3.5.18 |A |T |Refer to User-defined Table 0214 - Special|N/a see comment. |Add empty table. | | |
| | | | | |program codes for suggested values. | | | | |
| |Freida Hall |3.3.5.19 |A |Q |Definition: This field allows the user to|N/a see comment. |Add Y/N table. Y-retain. N-do not| | |
| | | | | |control the financial and demographic | |retain. | | |
| | | | | |purge processes at the visit. It is used | | | | |
| | | | | |to preserve demographic and financial data| | | | |
| | | | | |on specific, high priority visits. Refer | | | | |
| | | | | |to Chapter 2, HL7 Table 0136 - Yes/no | | | | |
| | | | | |indicator for valid values. | | | | |
| |Freida Hall |3.3.5.21 |A |T |Definition: This field contains a |N/a see comment. |Add empty table (0215). | | |
| | | | | |user-defined code indicating what level of| | | | |
| | | | | |publicity is allowed (e.g., No Publicity, | | | | |
| | | | | |Family Only) for a specific visit. Refer | | | | |
| | | | | |to User-defined Table 0215 - Publicity | | | | |
| | | | | |code for suggested values. Refer to | | | | |
| | | | | |PD1-11 - publicity code for the patient | | | | |
| | | | | |level publicity code. | | | | |
| |Freida Hall |3.3.5.22 |A |Q |Definition: This field identifies the |Add Y/N table. |What are the values for Y/N? | | |
| | | | | |person’s protection that determines, in | | | | |
| | | | | |turn, whether access to information about | | | | |
| | | | | |this person should be kept from users who | | | | |
| | | | | |do not have adequate authority for a | | | | |
| | | | | |specific visit. Refer to Chapter 2, HL7 | | | | |
| | | | | |Table 0136 - Yes/no indicator for valid | | | | |
| | | | | |values. Refer to PD1-12 - protection | | | | |
| | | | | |indicator for the patient level protection| | | | |
| | | | | |indicator. | | | | |
| |Freida Hall |3.3.5.24 |A |T |Definition: This field indicates the |N/a see comment. |Add empty table (0216). | | |
| | | | | |status of the episode of care: for | | | | |
| | | | | |instance, Active Inpatient, Discharged | | | | |
| | | | | |Inpatient. Refer to User-defined Table | | | | |
| | | | | |0216 - Patient status for suggested | | | | |
| | | | | |values. | | | | |
| |Freida Hall |3.3.5.31 |A |Q |Definition: This field contains the |N/a see comment. |This field is hyperlinked to the | | |
| | | | | |priority of the visit. Refer to | |table in another field, however, | | |
| | | | | |User-defined Table 0217 - Visit priority | |you cannot discern this from the | | |
| | | | | |code for suggested values. | |printed chapter. Suggest the table| | |
| | | | | | | |be repeated in each field where it | | |
| | | | | | | |occurs. | | |
| |Freida Hall |3.3.5.32 |A |Q |Definition: This field indicates if the |N/a see comment. |Add Y/N table. Y-reject from tape | | |
| | | | | |account is to be rejected from tape | |billing. N-do not reject from tape| | |
| | | | | |billing. Refer to Chapter 2, HL7 Table | |billing. | | |
| | | | | |0136 - Yes/no indicator for valid values. | | | | |
| |Freida Hall |3.3.5.34 |A |Q |Definition: This field indicates that a |N/a see comment. |Add Y/N table. What are the | | |
| | | | | |military healthcare facility has | |values? | | |
| | | | | |contracted with a non-military healthcare | | | | |
| | | | | |facility for the use of its services. | | | | |
| | | | | |Refer to Chapter 2, HL7 Table 0136 - | | | | |
| | | | | |Yes/no indicator for valid values. | | | | |
| |Freida Hall |3.3.5.30 |A |T |Definition: This field contains a |N/a see comment. |Add empty table. | | |
| | | | | |user-defined code that indicates which | | | | |
| | | | | |adjustments should be made to this | | | | |
| | | | | |patient’s charges. Refer to User-defined | | | | |
| | | | | |Table 0218 - Charge adjustment for | | | | |
| | | | | |suggested values. This field is the same | | | | |
| | | | | |as GT1-26-guarantor charge adjustment | | | | |
| | | | | |code. | | | | |
| |Freida Hall |3.3.5.35 |A |Q |Definition: This field indicates whether |N/a see comment. |Add Y/N table. Y-patient has | | |
| | | | | |a patient has permission to use a | |permission to use non-military | | |
| | | | | |non-military healthcare facility for | |facility. N-patient does not have | | |
| | | | | |treatment. Refer to Chapter 2, HL7 Table | |permission to use non-military | | |
| | | | | |0136 - Yes/no indicator for valid values. | |facility. | | |
| |Freida Hall |3.3.5.36 |A |Q |Definition: This field indicates whether |N/a see comment. |Add Y/N table. Y-patient is | | |
| | | | | |the patient is a baby. Refer to Chapter | |newborn. N-patient is not newborn.| | |
| | | | | |2, HL7 Table 0136 - Yes/no indicator for | | | | |
| | | | | |valid values. | | | | |
| |Freida Hall |3.3.5.37 |A |Q |Definition: This field indicates if the |N/a see comment. |Add Y/N table. Y-baby was | | |
| | | | | |baby is detained after the mother’s | |detained. N-baby was not detained.| | |
| | | | | |discharge. Refer to Chapter 2, HL7 Table | | | | |
| | | | | |0136 - Yes/no indicator for valid values. | | | | |
| |Freida Hall |3.3.6.7 |A |T |Definition: This field indicates the |N/a see comment. |Add empty table. | | |
| | | | | |specific relationship role (next of kin, | | | | |
| | | | | |employer, emergency contact, etc.). Refer| | | | |
| | | | | |to User-defined Table 0131 - Contact role | | | | |
| | | | | |for suggested values. This field | | | | |
| | | | | |specifies the role that the next of | | | | |
| | | | | |kin/associated parties plays with regard | | | | |
| | | | | |to the patient. Examples might include an| | | | |
| | | | | |employer, emergency contact, next of kin, | | | | |
| | | | | |insurance company, state agency, federal | | | | |
| | | | | |agency, etc. | | | | |
| |Freida Hall |3.3.6 |A |T |HL7 attribute table for NK1 segment., |Remove 0327/0328. |These are data type tables, not | | |
| | |(NK1-11), GT1-50, | | |field 11 references tables 0327/0328 | |field tables, and therefore should | | |
| | |IN2-47, STF-19. | | | | |not be referenced in the | | |
| | | | | | | |segment/field attribute table. | | |
| |Freida Hall |3.3.1.6 |N |Mi |Identification date 00208 |Identification date 00208 |The backward compatibility concept | | |
| | |IAM attribute table | | |Definition: This field has been retained |Definition: It has been replaced with two |was required when we were using the| | |
| | | | | |for backward compatibility only. It has |more specific fields, Onset Date and |AL1 for both snapshot and unique | | |
| | | | | |been replaced with two more specific |Reported Date. However, it is being left |key update. Since we have a | | |
| | | | | |fields, Onset Date and Reported Date. |for backward compatibility and should also|created a new IAM segment, the | | |
| | | | | |However, it is being left for backward |be populated. When used for backward |Identification date can be changed | | |
| | | | | |compatibility and should also be |compatibility, this field contains the |to optional, not backward | | |
| | | | | |populated. When used for backward |date that the allergy was identified |compatible. This | | |
| | | | | |compatibility, this field contains the | | | | |
| | | | | |date that the allergy was identified. | | | | |
| |Freida Hall |Ch. 15 |N |Mj |Chapter 15 has introduced new elements | |Quoting Chapter 2: “No new CM’s | | |
| | |Ch. 2 | | |that are a CM data type in the PRA | |are allowed after HL7 Version 2.2. | | |
| | | | | |segment. | |Hence there are no new CM’s in | | |
| | | | | | | |Version 2.3.” I believe the intent| | |
| | | | | | | |was to ban CM’s on all future | | |
| | | | | | | |versions, not just 2.3. This | | |
| | | | | | | |statement in Chapter 2 needs to be | | |
| | | | | | | |changed if we are now allowing CM | | |
| | | | | | | |data types. | | |
| |Richard |12.3 |A |S | | |Most of the CE datatypes should | | |
| |Harding |(all of the | | | | |refer to a table and preferably a | | |
| | |segments) | | | | |HL7 table. | | |
| | | | | | | |Many of the data items have | | |
| | | | | | | |suggested values in text – these | | |
| | | | | | | |should appear in tables. | | |
| |Richard |12.2 |A |S | | |Add a new section at start of 12.2 | | |
| |Harding | | | | | |that explains how goal lists and | | |
| | | | | | | |problem lists can be maintained for| | |
| | | | | | | |each discipline. Explain that these| | |
| | | | | | | |messages simply identify Pathways, | | |
| | | | | | | |they are described elsewhere. | | |
| | | | | | | |Alternatively, describe in 12.1.1.1| | |
| |Richard |12.2 |A |S |Applications can have differing |There are two different ways in which an |The first sentence of 12.2 is | | |
| |Harding | | | |orientations for representing problem and |application can view problems and goals: |incredibly important, yet on | | |
| | | | | |goal hierarchies. For example, |in the goal-oriented view, a problem is |several readings, I missed its | | |
| | | | | |parent/child relationships may map |dependent on the goal or goals which are |message. | | |
| | | | | |problem(s) to goal(s), or goal(s) to |intended to address it. The Patient Goal |Perhaps we need to show a diagram. | | |
| | | | | |problem(s). To accommodate these different|message PGL reflects this orientation |I am not sure that the words | | |
| | | | | |orientations, the Problem message allows |in the problem-oriented view, a goal is |“parent/child” are useful here as | | |
| | | | | |representation of goals that are |dependent on the problem or problems which|they are used in Chapter 7 to | | |
| | | | | |functionally dependent upon a problem, and|created the need for the goal. The Patient|describe a more rigorously defined | | |
| | | | | |the Goal message allows representation of |Problem message PPR reflects this |situation in Microbiology. | | |
| | | | | |problems that are functionally dependent |orientation | | | |
| | | | | |on a goal. |Similarly, when describing a patient’s | | | |
| | | | | | |progress against a pathway, there can be a| | | |
| | | | | | |goal orientation or a problem orientation | | | |
| | | | | | |to the pathway. | | | |
| |Richard |12.3.1.6 |A |S | |(12.3.2.18) |Goal List priority and Problem | | |
| |Harding |also | | | |This field ranks the problem against all |ranking should be consistently | | |
| | |12.3.2.18 | | | |of the other problems that are maintained |defined and have the same data | | |
| | | | | | |for this Problem Management Discipline. |type. (I would additionally suggest| | |
| | | | | | |More than one problem can be assigned the |a HL7 table of values is defined | | |
| | | | | | |same rank. |for these fields). | | |
| |Richard |12.3.1.9 |A |S | | |Use the same table for Problem | | |
| |Harding |also | | | | |Classification and goal | | |
| | |12.3.2.10 | | | | |classification. | | |
| |Richard |12.3.1.10 |Neg |Mi | | |Use the same table for Problem | | |
| |Harding |also | | | | |Management Discipline and goal | | |
| | |12.3.2.11 | | | | |management discipline. | | |
| | | | | | | |The alternate “parent/child” | | |
| | | | | | | |relationships do not work if these | | |
| | | | | | | |tables are different. | | |
| |Richard |12.3.1.18 |A |S | | |I would like Goal Lifecycle status | | |
| |Harding | | | | | |to be a HL7 table with some | | |
| | | | | | | |explanation of the values. | | |
| | | | | | | |I have trouble with the example | | |
| | | | | | | |values because “cancelled” and | | |
| | | | | | | |“suspended” seem to be subclasses | | |
| | | | | | | |of “Inactive” and I would like to | | |
| | | | | | | |see a value of “achieved”. | | |
| | | | | | | |Consider similar lifecycles for | | |
| | | | | | | |pathway lifecycle status 12.3.4.5 | | |
| | | | | | | |and problem lifecycle status | | |
| | | | | | | |12.3.2.14. | | |
| |Richard |12.3.2.14 |A |S | | |Try to use the same nomenclature | | |
| |Harding | | | | | |here as for Goal lifecycle status, | | |
| | | | | | | |but the valid values will differ eg| | |
| | | | | | | |problem lifecycle is stable, | | |
| | | | | | | |improving, worsening, inactive or | | |
| | | | | | | |resolved. Note the removal of the | | |
| | | | | | | |redundant “active” statuses. | | |
| |Richard |12.3.5 |A |S | | |Need to provide some additional | | |
| |Harding | | | | | |text describing specific examples | | |
| | | | | | | |of variations. | | |
| |Richard |12.3.5 |A |Q | | |Should there be an additional field| | |
| |Harding | | | | | |“reason for variance” to be used | | |
| | | | | | | |when a Dr changes a pathway? Any | | |
| | | | | | | |peer review would wish to | | |
| | | | | | | |understand the Dr’s reasons for | | |
| | | | | | | |changing what should be best | | |
| | | | | | | |practice. | | |
| |Richard |12.3.5 |A |Q | | |Original problem is “diarrhoea”. | |9 |
| |Harding | | | | | |Subsequently changed to “salmonella| | |
| | | | | | | |poisoning”. Is this | | |
| | | | | | | |a new problem | | |
| | | | | | | |a variation to the original problem| | |
| | | | | | | |a replacement for the original | | |
| | | | | | | |problem with the original problem | | |
| | | | | | | |held as a historic variation? | | |
| |Clem McDonald |4.4.3.46 | | | | |The idea of having supplemental | | |
| | | | | | | |ordering information is | | |
| | | | | | | |understandable. Different systems | | |
| | | | | | | |have different styles for | | |
| | | | | | | |structuring their order codes. For | | |
| | | | | | | |example, a system may have a code | | |
| | | | | | | |for femur xray and allow the | | |
| | | | | | | |specification of the right and left| | |
| | | | | | | |side by an additional code. | | |
| | | | | | | |However, the particulars in this | | |
| | | | | | | |table are such a mis-mash that this| | |
| | | | | | | |proposal will reduce the | | |
| | | | | | | |inter-operability of different | | |
| | | | | | | |systems and the suggestions for | | |
| | | | | | | |alternative code systems are worse.| | |
| | | | | | | |(E.g., there is no micro-glossary | | |
| | | | | | | |in SNOMED for radiology, and I | | |
| | | | | | | |understand no work has been done. | | |
| | | | | | | |Further, when it is produced it may| | |
| | | | | | | |really define order codes not | | |
| | | | | | | |modifier codes.) | | |
| | | | | | | | | | |
| | | | | | | |Specific criticisms of table 0411. | | |
| | | | | | | |I have many problems with this | | |
| | | | | | | |table as it is proposed. First, it | | |
| | | | | | | |is focused solely on the needs of | | |
| | | | | | | |radiology reporting, but is being | | |
| | | | | | | |proposed as a table for all of | | |
| | | | | | | |ordering. Secondly, its genesis is | | |
| | | | | | | |partly from the HCFA coding | | |
| | | | | | | |modifiers. HCFA has added required | | |
| | | | | | | |modifies for Right and Left, but it| | |
| | | | | | | |also has modifiers to identify the | | |
| | | | | | | |individual fingers and toes. HCFA | | |
| | | | | | | |uses 20 distinct modifiers (one for| | |
| | | | | | | |each finger and toe) not the five | | |
| | | | | | | |modifiers listed here. The table | | |
| | | | | | | |includes some of the variants for | | |
| | | | | | | |specifying position with respect to| | |
| | | | | | | |gravity (E.g., upright) but not the| | |
| | | | | | | |others - prone, supine, etc. It | | |
| | | | | | | |includes a modifier for Pediatric | | |
| | | | | | | |(a common part of the name of | | |
| | | | | | | |radiology tests for billing | | |
| | | | | | | |purposes because often more of the | | |
| | | | | | | |body can be obtained with less | | |
| | | | | | | |film), but the birth date defines | | |
| | | | | | | |“pediatric”. Furthermore, we have | | |
| | | | | | | |just completed a review of more | | |
| | | | | | | |than 13 hospitals reporting and | | |
| | | | | | | |billing codes for radiology and | | |
| | | | | | | |most of them have pre-coordinated | | |
| | | | | | | |the distinctions being described in| | |
| | | | | | | |the above. | | |
| | | | | | | | | | |
| | | | | | | |Thirdly, these would be an | | |
| | | | | | | |invitation for contradictory orders| | |
| | | | | | | |without additional structure to | | |
| | | | | | | |define what modifiers are allowed | | |
| | | | | | | |with what tests. | | |
| | | | | | | | | | |
| | | | | | | |Fourthly, this does have some | | |
| | | | | | | |relationship to the procedure code | | |
| | | | | | | |modifier listed in section | | |
| | | | | | | |4.4.3.45. The procedure modifier | | |
| | | | | | | |came from HCFA but don’t know if | | |
| | | | | | | |they are the CPT 2000 modifier | | |
| | | | | | | |codes because can’t see the table. | | |
| | | | | | | |This has an obvious overlap with | | |
| | | | | | | |the listed purpose of this field, | | |
| | | | | | | |indeed it includes some of the same| | |
| | | | | | | |values, but I believe is intended | | |
| | | | | | | |only for billing purposes as is the| | |
| | | | | | | |procedure code | | |
| | | | | | | | | | |
| | | | | | | |So, I would accept leaving the | | |
| | | | | | | |fields in – to serve as escape | | |
| | | | | | | |valves for needs that arise. But | | |
| | | | | | | |think we should remove the specific| | |
| | | | | | | |suggested table because it is too | | |
| | | | | | | |irregular and too specialized and | | |
| | | | | | | |it invites criticism and mis-use. | | |
| | | | | | | |In the body of the text we could | | |
| | | | | | | |mention some of the possible uses | | |
| | | | | | | |that are listed in the table, | | |
| | | | | | | |should mention the HCFA modifier | | |
| | | | | | | |codes in the body of the text, and | | |
| | | | | | | |should remove reference to anything| | |
| | | | | | | |that does not yet exist. | | |
| | | | | | | | | | |
| | | | | | | |I would suggest the following | | |
| | | | | | | |revisions. | | |
| | | | | | | | | | |
| | | | | | | |Making this a user defined CE | | |
| | | | | | | |coding sytem. | | |
| | | | | | | | | | |
| | | | | | | |Replace the last sentence in | | |
| | | | | | | |4.4.3.46 with the following: | | |
| | | | | | | | | | |
| | | | | | | |“On the ordering side, this field | | |
| | | | | | | |can be used to describe details | | |
| | | | | | | |such as whether study is to be done| | |
| | | | | | | |on the right or left, for example | | |
| | | | | | | |where the study is of the arm and | | |
| | | | | | | |the order master file does not | | |
| | | | | | | |distinguish right from left or | | |
| | | | | | | |whether the study is to be done | | |
| | | | | | | |with or without contrast (when the | | |
| | | | | | | |order master file does not make | | |
| | | | | | | |such distinctions). The HCFA CPT | | |
| | | | | | | |modifiers could also be used as | | |
| | | | | | | |codes in this field.” | | |
| | | | | | | | | | |
| | | | | | | |3) Add a code for CPT modifier in | | |
| | | | | | | |Table 0396 of Chapter 7 just below | | |
| | | | | | | |CPT4 as follows: | | |
| | | | | | | | | | |
| | | | | | | |CPT Modifier code CPTM | | |
| | | | | | | |Available for the AMA at the | | |
| | | | | | | |address listed for CPT above. | | |
| | | | | | | |These codes are found in Appendix A| | |
| | | | | | | |of CPT 2000 Standard Edition. (CPT | | |
| | | | | | | |2000 Standard Edition, American | | |
| | | | | | | |Medical Association, Chicago, IL). | | |
| |Clem McDonald |4.4.3.47 | | | | |See comments from Clem McDonald on | | |
| | | | | | | |Section 4.4.3.46 | | |
| |Clem McDonald |4.4.1.5 |N | | | |Order Status Modifier - We | | |
| | | | | | | |currently have real problems with | | |
| | | | | | | |the receipt of ORU messages that | | |
| | | | | | | |fail to use the order status as it | | |
| | | | | | | |is currently defined (e.g., they do| | |
| | | | | | | |not report corrections which | | |
| | | | | | | |require special processing at the | | |
| | | | | | | |medical record receiving end). | | |
| | | | | | | |Including an order status modifier | | |
| | | | | | | |that is user defined would only | | |
| | | | | | | |exaggerate this problem and create | | |
| | | | | | | |new inter-operability problems. | | |
| | | | | | | |Either this field has to be much | | |
| | | | | | | |more tightly defined to avoid any | | |
| | | | | | | |collision with the current | | |
| | | | | | | |requirements of interoperability or| | |
| | | | | | | |it should be removed. I would be | | |
| | | | | | | |much more accepting of a fully | | |
| | | | | | | |specific order status modifier with| | |
| | | | | | | |prespecfied codes to accommodate | | |
| | | | | | | |the additional needs described in | | |
| | | | | | | |this field. | | |
| |CCM | |A |T | | |There are numerous errors on the | | |
| |HBOC | | | | | |message table headers. For | | |
| | | | | | | |example, instead of showing ADT^A01| | |
| | | | | | | |it shows ADT^A01^ADT A01. These | | |
| | | | | | | |errors are not restricted to any | | |
| | | | | | | |given chapter. Our reviewers | | |
| | | | | | | |reported numerous occurrences. | | |
| |JF |2.6.2 |A |S |The following field lengths are specified |The following maximum field lengths are |For consistency with section | | |
| |HBOC | | | |for only chapters 2, 3, 5, 6, 8, 14 and |specified for only chapters 2, 3, 5, 6, 8,|heading. | | |
| | | | | |15: |14 and 15: | | | |
| |JDK |2.6.5 |N |Mj |N – no repetition |N or blank - no repetition |Virtually all segment tables use a | | |
| |HBOC | | | | | |blank to indicate no repetition | | |
| | | | | | | |versus N. Some people are | | |
| | | | | | | |interpreting a blank in this column| | |
| | | | | | | |to mean the field may optionally | | |
| | | | | | | |repeat – it is important to clear | | |
| | | | | | | |this issue up. | | |
| |JF |2.8 CN, 2.8.7 |A |T | ^ ^ | ^ ^ |For consistency with name | | |
| |HBOC | | | | ^ ^ ^ ^ ^ | | | |
| |JDK |2.8 PN |A |T |& ^ ^ |definition). | | |
| | | | | | ^ | | | |
| |JDK |2.8 XAD |A |T |In Version 2.3 and later, replaces the AD |In Version 2.3 and later, replaces the AD |Street address data type not shown | | |
| |HBOC | | | |data type. ^ ^ ^ ^ ^ ^ < address | | | |
| | | | | |(ID)> ^ ^ ^ ^ |(ST)> ^ ^ | | | |
| | | | | | ^ | | | |
| |JF |2.8.3.3 |N |Mj |User defined table 0396 – Coding systems |Add: |This list is not complete enough to| | |
| |HBOC | | | | |ICD-9-CM: The International |meet the spirit of HIPAA. The | | |
| | | | | | |Classification of Diseases, Ninth |HIPAA required coding systems | | |
| | | | | | |Revision, Clinical Modification |should be added. This suggestion | | |
| | | | | | |CPT-4: Physician Current Procedural |has arisen from various HIPAA focus| | |
| | | | | | |Terminology, fourth revision |group discussions. | | |
| | | | | | |HCPCS: Health Care Financing | | | |
| | | | | | |Administration Procedure Coding System | | | |
| | | | | | |contains codes for medical equipment, | | | |
| | | | | | |injectable drugs, transportation services,| | | |
| | | | | | |and other services not found in CPT4. | | | |
| | | | | | |CDT-2: Current dental terminology. | | | |
| |JF |2.8.7.2.22.8.7.2.42.|A |T |i.e |i.e. |Abbreviation punctuated incorrectly| | |
| |HBOC |8.19.22.8.19.42.8.31| | | | |throughout the chapter | | |
| | |.1.2 | | | | | | | |
| | |2.8.31.1.4 | | | | | | | |
| | |2.8.32.2.2 | | | | | | | |
| |JF |2.8.7.4 |A |T |Middle initial or name (ST) |Middle initial or name (ST) Second or |For consistency with name | | |
| |HBOC | | | | |further given names or initials thereof |components | | |
| | | | | | |(ST) | | | |
| |JDK |2.8.8 |A |T | | |Hidden text fields have the wrong | | |
| |HBOC | | | | | |data type indicated. | | |
| |JF |2.8.8.10 |A |T |For example, if the Observation Identifer |For example, if the Observation |Misspelled | | |
| |HBOC | | | |field |IdentiferIdentifier field | | | |
| |JDK |2.8.11 |A |T | | |Hidden text fields have the wrong | | |
| |HBOC | | | | | |data type indicated. | | |
| |JDK |2.8.24 |A |T | | |Hidden text fields have the wrong | | |
| |HBOC | | | | | |data type indicated. | | |
| |JDK |2.8.31 |A |T |& | | | |
| |JDK |2.8.52 |A |T |Components: In Version 2.3 and later, |Components: In Version 2.3 and later, |Street address data type not shown | | |
| |HBOC | | | |replaces the AD data type. ^ ^ ^ ^ ^ | | | |
| | | | | |^ < address type (ID)> ^ ^ | | | |
| | | | | |designation (ST)> ^ ^ ^ |^ | | | |
| |JDK |2.8.53 |A |T | |Subcomponents of name context: |Data type definition is missing CE | | |
| |HBOC | | | | | & & & & &| | | |
| | | | | | | | | | |
| |JF |2.8.53. |A |T |This component is used to designate the |This component is used to designate the |Sentence didn’t make sense. | | |
| |HBOC |16 | | |context in which a name is used had been |context in which a name is used had been | | | |
| | | | | |identified. |identified. | | | |
| |JDK |2.8.55 |A |T | |Subcomponents of name context: |Data type definition is missing CE | | |
| |HBOC | | | | | & & & & &| | | |
| | | | | | | | | | |
| |JDK |2.14.4.2 |A |S | | |Chapter 12 uses table 0287 to | | |
| |HBOC | | | | | |perform the same function as table | | |
| | | | | | | |0206. Shouldn’t table 0287 be | | |
| | | | | | | |indicated here as well as 0206? | | |
| |JF |2.15 |A |T |QRI 2.15.11 |Delete row |Row specific to QRI should be | | |
| |HBOC | | | | | |removed from table as all Query | | |
| | | | | | | |segments have been moved to Chapter| | |
| | | | | | | |5 | | |
| |JDK |2.15.9.17 |A |T |Components: ^ ^ ^ |but has a CE data type component | | |
| | | | | | ^ | | | |
| |JDK |2.15.9.21 |N |Mj | | |HL7 defined table 0449 has no | | |
| |HBOC | | | | | |values indicated. Should this be | | |
| | | | | | | |an IS instead of an ID, especially | | |
| | | | | | | |since it indicates sites may define| | |
| | | | | | | |values for this field? If ID, | | |
| | | | | | | |there can be no site-specific | | |
| | | | | | | |conformance ID’s created. | | |
| |JDK |2.15.10, 2.15.10.2 |N |Mj | | |NTE field 2, Source of comment, was| | |
| |HBOC | | | | | |changed from ID to IS via CQ, and I| | |
| | | | | | | |can’t recall reviewing any ballots | | |
| | | | | | | |that were negative to this change… | | |
| | | | | | | |the document now is back to ID - | | |
| | | | | | | |why was this change rescinded? | | |
| |AB |3.2.5 |A |Q | | |Should the A05 pre-admit event | | |
| |HBOC | | | | | |include the ROL segment for PID and| | |
| | | | | | | |PV1? It seems that the PID ROL | | |
| | | | | | | |information would be available at | | |
| | | | | | | |pre-admission time and perhaps the | | |
| | | | | | | |PV1 ROL information. | | |
| |AB |3.2.28 |A |Q | | |Should the A28 add person event | | |
| |HBOC | | | | | |include the ROL segment for PID and| | |
| | | | | | | |PV1? It seems that the PID ROL | | |
| | | | | | | |information would be available and | | |
| | | | | | | |if PV1 information is available, | | |
| | | | | | | |perhaps the PV1 ROL information | | |
| |AB |3.2.31 |A |Q | | |Should the A31 update person event | | |
| |HBOC | | | | | |include the ROL segment for PID and| | |
| | | | | | | |PV1? It seems that the PID ROL | | |
| | | | | | | |information would be available and | | |
| | | | | | | |if PV1 information is available, | | |
| | | | | | | |perhaps the PV1 ROL information | | |
| |Jean |3.2.56.1 |A |T |Input Parameter Specification - Person |Person Identifier length should be 250 |The field length is missing all | | |
| |HBOC | | | |Identifier length is listed as 20. |based on length changes for CX data type |together in 3.2.57, 3.2.58, 3.2.59 | | |
| |Jean |3.2.60 |A |Q |[PV1] | |Want to discuss whether or not PV1 | | |
| |HBOC | | | |[PV2] | |segments are really appropriate in | | |
| | | | | | | |an allergy segment since it is | | |
| | | | | | | |typically a ‘person’ level message.| | |
| | | | | | | |What value will the fields in the | | |
| | | | | | | |PV1 add? | | |
| |Jean |3.2.61 |A |T |When other important fields change, it is |When other important fields change, it is | | | |
| |HBOC | | | |recommended that the A08 (update patient |recommended that the A08 (update patient | | | |
| | | | | |information) event be used in addition. |information) event be used in addition. | | | |
| | | | | |If the Patient Administration system |If the Patient Administration system | | | |
| | | | | |allows demographics to change at the same |allows demographics to change at the same | | | |
| | | | | |time (for example an address change), two |time (for example an address change), two | | | |
| | | | | |messages (an A54 followed by an A08) |messages (an A54A61 followed by an A08) | | | |
| | | | | |should be sent. |should be sent. | | | |
| |Jean |3.3.1 |N |Mi |IAM-10 Category Code |Remove field from segment |Introduction of contraindications | | |
| |HBOC |3.3.1.10 | | | | |and intolerances into this segment | | |
| | | | | | | |adds a layer of complexity and the | | |
| | | | | | | |segment does not adequately support| | |
| | | | | | | |the concepts. Additionally the | | |
| | | | | | | |other values in the table are not | | |
| | | | | | | |mutually exclusive or clearly | | |
| | | | | | | |defined. | | |
| |Jean |3.3.1.4 |N |Mi |Allergy Severity Code (CE) |Allergy Severity Code (CEIS) |Because this element is shared by | | |
| |HBOC | | | | | |the AL1 segment where it is a data | | |
| | | | | | | |type ‘IS’. Also because the value | | |
| | | | | | | |is derived from a table, CE is not | | |
| | | | | | | |appropriate | | |
| |Jean |3.3.1.4 |A |S | |Add value “Unknown” to table of |“Unknown” is clinically relevant | | |
| |HBOC | | | | |recommended values |value. For example, if a relative | | |
| | | | | | | |is responding to questioning. | | |
| | | | | | | |Blank should be used to imply there| | |
| | | | | | | |was no response at all | | |
| |Jean |3.3.1.7 |N |Mi |The HL7 attribute table defines the field |Change the table to conditional and change| | | |
| |HBOC | | | |as required; however, the definition |the wording in the definition to be | | | |
| | | | | |states that it is both conditional and |conditional throughout. | | | |
| | | | | |optional | | | | |
| |Jean |3.3.1.7 |N |Mi |If the allergy messages are being sent in |If the allergy messages are being sent in |The IAM is a new segment and to | | |
| |HBOC | | | |snapshot mode, then this does not need to |snapshot mode, then this does not need to |suggest backward compatibility is | | |
| | | | | |be valued. By allowing this field to be |be valued. By allowing this field to be |being maintained does not make | | |
| | | | | |optional, the backward compatibility of |optional, the backward compatibility of |sense | | |
| | | | | |the IAM is maintained. Refer to HL7 Table |the IAM is maintained. Refer to HL7 Table | | | |
| | | | | |0323 - Action code for suggested values. |0323 - Action code for suggested values. | | | |
| |Jean |3.3.1.8 |N |Mi |The HL7 attribute table defines the field |Change HL7 Attribute table to indicate |Field is conditional if IAM-3.1 is | | |
| |HBOC | | | |as required, however the definition states|field is conditional. |not used as unique identifier | | |
| | | | | |that it is both conditional and optional | | | | |
| |Jean |3.3.1.8 |N |Mi |Definition: This field uniquely |This field provides a value that uniquely |The original definition is | | |
| |HBOC | | | |identifies one of multiple repetitions of |identifies one of multiple repetitions of |difficult to understand and does | | |
| | | | | |the primary entity defined by the |the primary entity defined by the |not clearly define the intent of | | |
| | | | | |repeating segment in a way that does not |repeating segment in a way that does not |this field. | | |
| | | | | |change over time. |change over time a single allergy for a | | | |
| | | | | | |person. It is unique across all segments | | | |
| | | | | | |and messages for a person. If a system | | | |
| | | | | | |maintains allergen codes as a unique | | | |
| | | | | | |identifier for a particular allergy, then | | | |
| | | | | | |the allergen code reported in IAM-3.1 can | | | |
| | | | | | |be replicated in this field and used as a | | | |
| | | | | | |unique identifier. | | | |
| |Jean |3.3.1.17 |A |S |Definition: This field describes any type |Definition: This field describes any type |Added for clarity. | | |
| |HBOC | | | |of alert device the patient may be |of allergy alert device the patient may be| | | |
| | | | | |carrying or wearing. |carrying or wearing. | | | |
| |Jean |3.3.1.18 |N |Mi |Table 0438 Allergy clinical status |Remove or clarify values: |The intent of this field is to | | |
| |HBOC | | | | |Pending |communicate verification status of | | |
| | | | | | |Suspect |an allergy. These values do not | | |
| | | | | | |Doubt Raised |clearly do this. To serve the | | |
| | | | | | |Erroneous |purpose of an application, an | | |
| | | | | | | |allergy is either verified or | | |
| | | | | | | |unverified. To assign ‘degrees’ of| | |
| | | | | | | |verification adds confusion. Are | | |
| | | | | | | |these values intended to | | |
| | | | | | | |communicate a verified or | | |
| | | | | | | |unverified status? | | |
| |Jean |3.3.3 |A |T |23 25060 Birth Place |23 25060 Birth Place | | | |
| |HBOC | | | | | | | | |
| |Jean |3.3.3.9 |A |Q |Definition: This field has been retained | |If name type is present – shouldn’t| | |
| |HBOC | | | |for backward compatibility only. It is | |it be stated that the name type can| | |
| | | | | |recommended to use PID-5 - patient name | |only have the value of ‘A’ for | | |
| | | | | |for all patient names. This field | |Alias since this is the Alias name | | |
| | | | | |contained the name(s) by which the patient| |field? Instead by referencing a | | |
| | | | | |has been known at some time. Refer to HL7| |table – it indicates to me that any| | |
| | | | | |Table 0200 - Name type for valid values. | |of the name types are valid. | | |
| |Jean |3.3.4.52 |A |Q |This field contains the other healthcare | |If this field is for other | | |
| |HBOC | | | |providers (e.g., Nurse care practitioner, | |healthcare practitioners – why is | | |
| | | | | |midwife, physician assistant). Multiple | |table 0010 – Physician ID | | |
| | | | | |healthcare providers can be sent. | |referenced? | | |
| | | | | |Depending on local agreements, either the | | | | |
| | | | | |ID or the name may be absent from this | | | | |
| | | | | |field. Use values in User-defined Table | | | | |
| | | | | |0010 - Physician ID for first component. | | | | |
| |Jean |3.3.5.43 |A |S |PD1-7 Definition: This field indicates | |There should be some wording in the| | |
| |HBOC | | | |whether or not the patient has a living | |definition to the PV2 field such | | |
| | | | | |will and, if so, whether a copy of the | |as: The value of PV1-51 affects | | |
| | | | | |living will is on file at the healthcare | |whether data is sent in this field.| | |
| | | | | |facility. If the patient does not have a | | | | |
| | | | | |living will, the value of this field | | | | |
| | | | | |indicated whether the patient was provided| | | | |
| | | | | |information on living wills. Refer to | | | | |
| | | | | |User-defined Table 0315 - Living will for | | | | |
| | | | | |suggested values. See also PV2-43 - | | | | |
| | | | | |Living will. | | | | |
| | | | | | | | | | |
| | | | | |PV2-43 Definition: This field indicate | | | | |
| | | | | |whether or not the patient has a living | | | | |
| | | | | |will and, if so, whether a copy of the | | | | |
| | | | | |living will is on file at the healthcare | | | | |
| | | | | |facility. If the patient does not have a | | | | |
| | | | | |living will, the value of this field | | | | |
| | | | | |indicated whether the patient was provided| | | | |
| | | | | |information on living wills. Refer to | | | | |
| | | | | |User-defined Table 0315 - Living will code| | | | |
| | | | | |for suggested values. See also PD1-7 - | | | | |
| | | | | |Living will. | | | | |
| |Jean |3.3.5.44 |A |S | | |See comments 3.3.5.43 | | |
| |HBOC | | | | | | | | |
| |Jean |3.3.5.45 |A |S | | |See comments 3.3.5.43 | | |
| |HBOC | | | | | | | | |
| |Jean |3.3.7.3 |A |T |If a system maintains allergen codes as |If a system maintains allergen codes as |AL1-8 is not a valid element. | | |
| |HBOC | | | |it's unique identifier for a particular |it's unique identifier for a particular | | | |
| | | | | |allergy, and two systems have agreed to |allergy, and two systems have agreed to | | | |
| | | | | |process the AL1 using update mode, then |process the AL1 using update mode, then | | | |
| | | | | |this field can be used as the unique |this field can be used as the unique | | | |
| | | | | |identifier instead of AL1-8 - Allergy |identifier instead of AL1-8 - Allergy | | | |
| | | | | |Unique Identifier. This does not preclude |Unique Identifier. This does not preclude | | | |
| | | | | |using allergen codes for unique |using allergen codes for unique | | | |
| | | | | |identifiers for snapshot processing. |identifiers for snapshot processing. | | | |
| |CCM |3.3.7.7 |A |T |AL1-19 Statused by person |Delete this section. |3.3.7 identifies 6 elements for | | |
| |HBOC | | | | | |AL1; inclusion of seventh element | | |
| | | | | | | |named AL1-19 is obvious error. | | |
| |Jean |3.4.9 |N |Mi | | |Is this really applicable for AL1 –| | |
| |HBOC |3.4.10 | | | | |should this example be removed or | | |
| | | | | | | |used instead for IAM with the | | |
| | | | | | | |associated triggers for IAM? | | |
| |JF |3.5.4.3 |A |S |MPI QBP/RSP Queries: |MPI QBP/RSP Queries: |Server is the correct term. | | |
| |HBOC | | | |The following sections show several |The following sections show several | | | |
| | | | | |scenarios involving looking up a person on|scenarios involving looking up a person on| | | |
| | | | | |a “client” system |a “clientserver” system | | | |
| |CCM |3.5.4.3 |A |T |Figure 3-1 |Figure 3-1 | | | |
| |HBOC | | | |A24 Link Patient Inforamtion |A24 Link Patient Information | | | |
| |JF |3.5.4.4, 3.4.5.6 |A |S | | |In addition to A01 and A04 other | | |
| |HBOC | | | | | |ADT messages such as A05 or A14 | | |
| | | | | | | |should be included in these | | |
| | | | | | | |discussions. | | |
| |JF |3.5.4.5 |A |S |Prior to querying the MPI, the client |Prior to querying the MPI, the client |Clarity. | | |
| |HBOC | | | |system may query its own database prior to|system may query its own database prior to| | | |
| | | | | |querying the MPI to reduce network |querying the MPI to reduce network | | | |
| | | | | |transactions. |transactions.. | | | |
| |JF |3.6 |A |T |MPI QUERIES |Delete |Section moved/removed, title left | | |
| |HBOC | | | | | |in chapter 3. | | |
| |AK |4.3.2 |A |Q | | |ORR^O02^ORR_O02 | | |
| |HBOC | | | | | |Format - is this correct? Why is | | |
| | | | | | | |the double listed there? Other | | |
| | | | | | | |times it is OSQ Q06 | | |
| |AK |4.3.2.1 |A |T |Note: ORRs for supply, pharmacy, and |Note: ORRs for supply, pharmacy, and |Misspelled | | |
| |HBOC | | | |dieteray orders all have slightly |dieteray dietary orders all have slightly | | | |
| | | | | |different message syntax; |different message syntax; | | | |
| |AK |4.3.5 |A |T |OMG - general clinical order response |OMG ORG - general clinical order response |Correct header. | | |
| |HBOC | | | |message (event O20) |message (event O20) | | | |
| |AK |4.4.1 |A |Q | | |ORC table Fields 1 & 5 – | | |
| |HBOC | | | | | |They are now RP/# = N | | |
| | | | | | | |Does that mean non-repeating? I | | |
| | | | | | | |thought blank was non-repeating? | | |
| | | | | | | |Why specify N? | | |
| |AK |4.4.1.1 |A |Q | | |Table 0119 | | |
| |HBOC | | | | | |Missing Event/message types | | |
| | | | | | | |NW is missing OMG | | |
| | | | | | | |OK is missing ORL and there’s more | | |
| | | | | | | |UC, UD, UA, HR, UR, XO, UM, DE, LI | | |
| | | | | | | |are listed in there twice | | |
| |AK |4.9.4 |A |T |ORS Nonstock Requisition Order |ORS ORN Nonstock Requisition Order |Correct heading | | |
| |HBOC | | | |Acknowledgment Message (O08) |Acknowledgment Message (O08) | | | |
| |AK |4.x.x |A |T | | |All dietary / supply trigger | | |
| |HBOC | | | | | |headers should consistently say | | |
| | | | | | | |(EVENT XYZ), the document should be| | |
| | | | | | | |reviewed generally for consistency.| | |
| | | | | | | |Example: | | |
| | | | | | | |OML - laboratory order message | | |
| | | | | | | |(event O21) | | |
| | | | | | | |ORN Nonstock Requisition Order | | |
| | | | | | | |Acknowledgment Message (O08) | | |
| |JF |4.13.1.3 |A |T |In a nonvarying dose |In a non-varying dose |Misspelled | | |
| |HBOC | | | | | | | | |
| |JDK |5.1.3 |A |T |The next section elaborates on the three |The next section elaborates on the three |Missing ‘of’. | | |
| |HBOC | | | |styles response data (segment pattern, |styles of response data (segment pattern, | | | |
| | | | | |tabular, and display) that a data owner |tabular, and display) that a data owner | | | |
| | | | | |may use to represent its data. |may use to represent its data. | | | |
| |JDK |5.1.4.2 |A |T |The rows and columns of Virtual Table for |The rows and columns of the Virtual Table |Missing ‘the’. | | |
| |HBOC | | | |a query are fully described in the |for a query are fully described in the | | | |
| | | | | |Conformance Statement for that query. |Conformance Statement for that query. | | | |
| |JDK |5.2.2 |A |T |Input Specification and Commentary: Cites|Input Specification and Commentary: Cites|Missing ‘be’. | | |
| |HBOC | | | |the allowable parameters that can passed |the allowable parameters that can be | | | |
| | | | | |to the recipient. The structure of this |passed to the recipient. The structure of | | | |
| | | | | |part of the Conformance Statement is very |this part of the Conformance Statement is | | | |
| | | | | |similar in appearance to an HL7 Segment |very similar in appearance to an HL7 | | | |
| | | | | |Attribute Table with several additional |Segment Attribute Table with several | | | |
| | | | | |columns: ColName, Key/Search, Sort, |additional columns: ColName, Key/Search, | | | |
| | | | | |MatchOp, SegmentFieldName, and LOINC or |Sort, MatchOp, SegmentFieldName, and LOINC| | | |
| | | | | |HL7 Code. |or HL7 Code. | | | |
| |JDK |5.2.3.3 |A |T | | |There is text in the header section| | |
| |HBOC | | | | | |of the conformance statement that | | |
| | | | | | | |should be outside of the | | |
| | | | | | | |conformance statement, and the word| | |
| | | | | | | |‘Conformance’ is missing from the | | |
| | | | | | | |header. | | |
| |JDK |5.3 |A |T |The query recommended for use in v 2.4 is |The query recommended for use in v 2.4 is |Missing ‘in’. | | |
| |HBOC | | | |the Query By Parameter (QBP). The |the Query By Parameter (QBP). The | | | |
| | | | | |query/response message pairs that follow |query/response message pairs that follow | | | |
| | | | | |in this section supercede the previous |in this section supercede the previous | | | |
| | | | | |generation of original mode and enhanced |generation of original mode and enhanced | | | |
| | | | | |queries that are described sections Error!|queries that are described in sections | | | |
| | | | | |Reference source not found., Error! |Error! Reference source not found., Error!| | | |
| | | | | |Reference source not found., 5.9.4. |Reference source not found., 5.9.4. | | | |
| |JDK |5.3.4 |A |T |Several for this query are as follows: 1) |Several use cases for this query are as |Missing ‘use cases’. | | |
| |HBOC | | | |to populate a database initially, 2) to |follows: 1) to populate a database | | | |
| | | | | |recover from an extended down time on the |initially, 2) to recover from an extended | | | |
| | | | | |part of the recipient, 3) to enable |down time on the part of the recipient, 3)| | | |
| | | | | |systems which normally receive unsolicited|to enable systems which normally receive | | | |
| | | | | |data to be extended to act as a query |unsolicited data to be extended to act as | | | |
| | | | | |client with minimal modification. |a query client with minimal modification. | | | |
| |JDK |5.4.4, 5.4.4.1 |A |T |Definition: This field contains the name |Definition: This field contains the name |To be consistent with other uses of| | |
| |HBOC | | | |of the query. These names are assigned by|of the query. These names are assigned by|this field, it should not refer to | | |
| | | | | |the function-specific chapters of this |the function-specific chapters of this |a table. | | |
| | | | | |specification. Site-specific query names |specification. Site-specific query names | | | |
| | | | | |begin with the letter “Z.” Refer to Table|begin with the letter “Z.” Refer to Table| | | |
| | | | | |nnn, Query Name, for valid values. |nnn, Query Name, for valid values. | | | |
| |JDK |5.4.5.3 |A |T |Example: |MATCHWARE_1.2^^HL7nnnn| or |Example: |MATCHWARE_1.2^^HL70393nnnn| or |Example should have HL7 table | | |
| |HBOC | | | ||LINKSOFT_2.01^HL7nnnn| ||LINKSOFT_2.01^HL70303nnnn| |number not ‘nnnn’. | | |
| |JDK |5.4.6 |A |T | | |Field 4, Execution and delivery | | |
| |HBOC | | | | | |time is noted as Conditionally | | |
| | | | | | | |required; however there is no | | |
| | | | | | | |conditionality rule defined. | | |
| | | | | | | |Should this field be Optional? | | |
| |JDK |5.6.4, 5.6.5 |A |T |QPD|Q99^ORU_Subscription^HL7nnnn|Q0044|123| |Examples alternately use HL7nnnn | | |
| |HBOC | | | |4^^^MPI^MR~4567^^^MPI^MR| | |and HL70003. Is there an HL7 table| | |
| | | | | | | |assigned for this? Examples in | | |
| | | | | |QID|Q0044|Q99^ORU_Subscription^HL70003| | |entire chapter should be | | |
| | | | | | | |consistent, and should not use | | |
| | | | | | | |‘HL7nnnn’ (there are many examples | | |
| | | | | | | |of this throughout the chapter). | | |
| |JDK |5.8.2.3.1 |A |T |The combination of values for PatientID, |The combination of values for PatientID, |Conformance statement for Lab | | |
| |HBOC | | | |and PatientIDAssigningAuthority, are |and PatientIDAssigningAuthority, are |Result History refers to checking | | |
| | | | | |intended to identify a unique entry on the|intended to identify a unique entry on the|the PHARMACY_DISPENSE_TRANSACTION, | | |
| | | | | |PATIENT_MASTER table. The |PATIENT_MASTER table. The |which doesn’t make much sense. | | |
| | | | | |PatientIDTypeCode is useful for further |PatientIDTypeCode is useful for further | | | |
| | | | | |filtering or to supply uniqueness in the |filtering or to supply uniqueness in the | | | |
| | | | | |event that the assigning authority may |event that the assigning authority may | | | |
| | | | | |have more than one coding system. (The |have more than one coding system. (The | | | |
| | | | | |PATIENT_MASTER table contains a constraint|PATIENT_MASTER table contains a constraint| | | |
| | | | | |that prevents multiple patients from being|that prevents multiple patients from being| | | |
| | | | | |identified by the same combination of |identified by the same combination of | | | |
| | | | | |field values.) This PATIENT_MASTER entry |field values.) This PATIENT_MASTER entry | | | |
| | | | | |will be searched against on the |will be searched against on the | | | |
| | | | | |PHARMACY_DISPENSE_TRANSACTION table to |PHARMACY_DISPENSE_TRANSACTION table to | | | |
| | | | | |retrieve the rows fulfilling the query |retrieve the rows fulfilling the query | | | |
| | | | | |conditions> |conditions | | | |
| |JDK |5.8.3.1.1 |A |T |The combination of values for PatientID, |The combination of values for PatientID, |Conformance statement for MPI | | |
| |HBOC | | | |and PatientIDAssigningAuthority, are |and PatientIDAssigningAuthority, are |refers to checking the | | |
| | | | | |intended to identify a unique entry on the|intended to identify a unique entry on the|PHARMACY_DISPENSE_TRANSACTION, | | |
| | | | | |PATIENT_MASTER table. The |PATIENT_MASTER table. The |which doesn’t make much sense. | | |
| | | | | |PatientIDTypeCode is useful for further |PatientIDTypeCode is useful for further | | | |
| | | | | |filtering or to supply uniqueness in the |filtering or to supply uniqueness in the | | | |
| | | | | |event that the assigning authority may |event that the assigning authority may | | | |
| | | | | |have more than one coding system. (The |have more than one coding system. (The | | | |
| | | | | |PATIENT_MASTER table contains a constraint|PATIENT_MASTER table contains a constraint| | | |
| | | | | |that prevents multiple patients from being|that prevents multiple patients from being| | | |
| | | | | |identified by the same combination of |identified by the same combination of | | | |
| | | | | |field values.) This PATIENT_MASTER entry |field values.) This PATIENT_MASTER entry | | | |
| | | | | |will be searched against on the |will be searched against on the | | | |
| | | | | |PHARMACY_DISPENSE_TRANSACTION table to |PHARMACY_DISPENSE_TRANSACTION table to | | | |
| | | | | |retrieve the rows fulfilling the query |retrieve the rows fulfilling the query | | | |
| | | | | |conditions> |conditions | | | |
| |JF |6.4.7.57 6.4.7.58 |A |S |Insurance co |Insurance company |Spell out | | |
| |HBOC | | | | | | | | |
| |JF |6.4.8.20 |A |S |req/window |required/window |Spell out | | |
| |HBOC | | | | | | | | |
| |JF |6.4.9.9 |A |S |This field identifies the person or |This field identifies the person or |Grammar | | |
| |HBOC | | | |organization who brought in the patient. |organization who that brought in the | | | |
| | | | | | |patient. | | | |
| |JF |6.4.12. | | |User-defined table 0424 |User-defined table 0424 |Misspelled | | |
| |HBOC |11 | | |Preterm |Pre-term | | | |
| |Jean |6.4.16.3 |N |Mj |Definition: This repeating field contains| |The use of “” in the repeat | | |
| |HBOC | | | |the APC modifier status code correlating | |violates an HL7 construct rule. | | |
| | | | | |to the procedure code modifiers reported | | | | |
| | | | | |in PR1-16 - Procedure Code Modifier. A | |Chapter 2, section 2.10 Message | | |
| | | | | |placeholder must be used if there is no | |Construction Rules, Step 1, b): | | |
| | | | | |modifier status code value for a | |"7) if the field definition permits| | |
| | | | | |particular procedure code modifier. For | |repetition of a field, the | | |
| | | | | |example, if PR1-16 - Procedure Code | |following rules are used, the | | |
| | | | | |Modifier reports 01~02~03~04 as modifier | |repetition separator | | |
| | | | | |codes, and modifier code 03 modifier | |is used only if more than one | | |
| | | | | |status code is unknown, APC-3 APC - | |occurrence is transmitted and is | | |
| | | | | |modifier status would report. | |placed between occurrences. (If | | |
| | | | | | | |three occurrences are transmitted, | | |
| | | | | | | |two repetition separators are | | |
| | | | | | | |used.) In the example below, two | | |
| | | | | | | |occurrences of telephone number are| | |
| | | | | | | |being sent:" | | |
| | | | | | | ||234-7120~599-1288B1234| | | |
| | | | | | | | | | |
| | | | | | | |I don't think "" denotes an | | |
| | | | | | | |"occurrence". There is no implied | | |
| | | | | | | |meaning in the order of the | | |
| | | | | | | |repetitions | | |
| | | | | | | | | | |
| | | | | | | |Suggestion to either add a data | | |
| | | | | | | |type that would incorporate the | | |
| | | | | | | |PR1-16 - Procedure Code Modifier | | |
| | | | | | | |and GP2-3 APC modifier status | | |
| | | | | | | |code | | |
| | | | | | | | | | |
| | | | | | | |OR | | |
| | | | | | | | | | |
| | | | | | | |add a table value for “Modifier | | |
| | | | | | | |status unknown” to user-defined | | |
| | | | | | | |Table 0459 – APC modifier status | | |
| | | | | | | |code? | | |
| |Jean |6.5 |A |Q | | |Should this Example Transactions | | |
| |HBOC | | | | | |section be expanded to include an | | |
| | | | | | | |example of the new P10 transaction?| | |
| |AK |7.3.1.46 |A |T |Refer to User-defined table 4011 - |Refer to User-defined table 4011 0411 - |Table reference should be 0411. | | |
| |HBOC | | | |Supplemental service information values |Supplemental service information values | | | |
| | | | | |for suggested values. |for suggested values. | | | |
| |AK |7.4.1 |A |S |This examples use LOINC® clinical codes |This These examples use LOINC® clinical |Grammar | | |
| |HBOC | | | | |codes | | | |
| |AK |7.3.1.47 |A |Q | | |Text is different than 4.4.3.47 | | |
| |HBOC | | | | | |text regarding SNOMED, etc | | |
| | | | | | | |Chapter 7: Individual | | |
| | | | | | | |implementations may extend this | | |
| | | | | | | |table using other appropriate | | |
| | | | | | | |vocabularies. | | |
| | | | | | | |Chapter 4: Individual | | |
| | | | | | | |implementations may extend this | | |
| | | | | | | |table using other appropriate | | |
| | | | | | | |vocabularies such as the SNOMED | | |
| | | | | | | |DICOM Microglossary (SDM) or | | |
| | | | | | | |private (local) entries. | | |
| |AK |7.7.2 |A |Q | | |Second paragraph begins with “Phase| | |
| |HBOC | | | | | |of a clinical trial.” What does | | |
| | | | | | | |this mean? | | |
| |Jean |8.7.3.43 |A |Q |(star) Life of the "unit." Used for blood|(asterisk) Life of the "unit." Used for | | | |
| |HBOC | | | |products |blood products | | | |
| |JF |8.7.1 |A |T |OM7 segment contains additional basic |OM7 segment contains additional basic |Retype to be consistent with the | | |
| |HBOC | | | |attributes that apply to the definition of|attributes that apply to the definition of|other segment wording. | | |
| | | | | |most observations/services. |most observations/services | | | |
| |JF |8.7.3.12 |A |Q |orderability | |In OM1.12 is orderability a word? | | |
| |HBOC | | | | | | | | |
| |Jean |8.8.3 |A |T | | |LCH table Field 4 length is 025 and| | |
| |HBOC | | | | | |should be 250. | | |
| |Jean |8.9.2 |A |T | | |CDM table Field 7 length is 025 and| | |
| |HBOC | | | | | |should be 250. | | |
| |JDK |14.2.1 |A |T |NCK - Network System Clock |NCK - Network System Clock |In NMQ, to be consistent with the | | |
| |HBOC | | | | | |other definitions of this segment. | | |
| |JDK |14.2.2 |A |T |NST - Statistics |NST - Application control-level Statistics|In NMD, to be consistent with the | | |
| |HBOC | | | | | |other changes made. | | |
| |JDK |14.3.2 |A |T |NSC - status change segment |NSC - Application status change segment |To be consistent with segment table| | |
| |HBOC | | | | | |usage. | | |
| |JDK |14.3.2.1 |A |T | | |Hidden fields have not been changed| | |
| |HBOC | | | | | |to match new table name. | | |
| |JDK |14.3.3 |A |T |NST - statistics segment |NST - Application control-level statistics|To be consistent with segment table| | |
| |HBOC | | | | |segment |usage. | | |
| |Frank Oemig |2 |N |Mj | | |The contents of the document was | | |
| |HL7 Germany | | | | | |changed on 04/21/2000 and | | |
| | | | | | | |04/25/2000. | | |
| | | | | | | |Please check for the correct | | |
| | | | | | | |section numbers! | | |
| |Frank Oemig |2.8.8 |A |T |index information: “CE” |“CNE” | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.11 |A |T |index information: “CE” |“CWE” | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.13 |A |T | | |“DLN”: index information is missing| | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.14 |A |T | | |“DR”: index information is missing | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.16 |A |T | | |contains empty index information: | | |
| |HL7 Germany | | | | | |delete it! | | |
| |Frank Oemig |2.8.18 |A |T | | |“FC”: index information is missing | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.22 |A |T |index information: “ID” |“IS” | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.23 |A |T | | |“JCC”: index information is missing| | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.30 |A |T | | |“PPN”: index information is missing| | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.30.16 |A |S |uses table 4000 | |Use a table number below 500. | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.31 |A |T | | |“PT”: index information is missing | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.32 |A |T | | |“QIP”: index information is missing| | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.33 |A |T | | |“QSC”: index information is missing| | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.34 |A |T | | |“RCD”: index information is missing| | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.35 |A |T | | |correct index information to make | | |
| |HL7 Germany | | | | | |it consistent with the other | | |
| |Frank Oemig |2.8.37 |A |T | | |correct index information to make | | |
| |HL7 Germany | | | | | |it consistent with the other | | |
| |Frank Oemig |2.8.40 |A |T | | |“SRT”: index information is missing| | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.47 |A |T | | |“VH”: index information is missing | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.8.48 |A |T | | |“VID”: index information is missing| | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |2.11 |N |Mj | | |Introduce “” to allow| | |
| |HL7 Germany | | | | | |choices of segments within a | | |
| | | | | | | |message specification. We agreed on| | |
| | | | | | | |it in San Diego in order to specify| | |
| |Frank Oemig |3 |N |Mj | | |The contents of the document was | | |
| |HL7 Germany | | | | | |changed on 05/11/2000. | | |
| |Frank Oemig |3.2.56 |A |Mj | | |Check events and their message | | |
| |HL7 Germany | | | | | |structures! | | |
| |Frank Oemig |3.2.57 |A |Mj | | |Check events and their message | | |
| |HL7 Germany | | | | | |structures! | | |
| |Frank Oemig |3.2.58 |A |Mj | | |Check events and their message | | |
| |HL7 Germany | | | | | |structures! | | |
| |Frank Oemig |3.2.59 |A |Mj | | |Check events and their message | | |
| |HL7 Germany | | | | | |structures! | | |
| |Frank Oemig |4.3.1 |N |Mj | | |Thus please replace “???” by the | | |
| |HL7 Germany | | | | | |following sequence: “”. | | |
| |Frank Oemig |4.3.1 |A |Q |only for backward compatibility! | |chapter 4.5.2 makes use of this | | |
| |HL7 Germany | | | | | |message to order non-medical | | |
| | | | | | | |services. Which message should be | | |
| | | | | | | |taken instead? | | |
| |Frank Oemig |4.3.2 |N |Mj | | |Replace “???” by the following | | |
| |HL7 Germany | | | | | |sequence: “”. | | |
| |Frank Oemig |4.3.3 |N |Mj | | |Replace “???” by the following | | |
| |HL7 Germany | | | | | |sequence: “”. | | |
| |Frank Oemig |4.5.2 |A |Mj | | |The specified query can be replaced| | |
| |HL7 Germany | | | | | |by a new one using a conformance | | |
| | | | | | | |statement. | | |
| | | | | | | |The according proposal is submitted| | |
| | | | | | | |directly in form of a complete | | |
| | | | | | | |document. | | |
| |Frank Oemig |5.1.3 |A |S |structure of conformance statement | |Add a table which explains the | | |
| |HL7 Germany | | | | | |combination of the different parts | | |
| | | | | | | |of a conformance statement. | | |
| | | | | | | |Please see the analysis from the | | |
| | | | | | | |publishing group. | | |
| |Frank Oemig |5.2.1.2 |A |S | | |The example makes use of a | | |
| |HL7 Germany |5.2.2 | | | | |“Conformance Statement ID”. That | | |
| | | | | | | |allows for easy referencing the | | |
| | | | | | | |conformance statement esp. for | | |
| | | | | | | |storing in the database. | | |
| | | | | | | |It should be discussed, whether a | | |
| | | | | | | |conformance statement ID is | | |
| | | | | | | |required, but its use in MSH-21 | | |
| | | | | | | |should be optional. | | |
| |Frank Oemig |5.??? |A |S | | |All conformance statements are | | |
| |HL7 Germany | | | | | |formatted too wide! | | |
| | | | | | | |For international requirements | | |
| | | | | | | |(Europe/Australia) all formatting | | |
| | | | | | | |must also fit on DIN/A4 letters. | | |
| |Frank Oemig |5.2.2.2 |A |Q | | |Some example uses “contains=”. Is | | |
| |HL7 Germany | | | | | |this a relational operator? | | |
| |Frank Oemig |5.2.? |A |S | | |Include explanation for “Query | | |
| |HL7 Germany | | | | | |Grammar Specification” into the | | |
| | | | | | | |chapter! | | |
| |Frank Oemig |5.2.? |A |S | | |Include explanation for “Input | | |
| |HL7 Germany | | | | | |Parameter Field Description and | | |
| | | | | | | |Commentary” into the chapter. | | |
| |Frank Oemig |5.2.? |A |S | | |Include explanation for “Output | | |
| |HL7 Germany |5.8.1.1.1 | | | | |Specification and Commentary” into | | |
| | | | | | | |the chapter. It would be good to | | |
| | | | | | | |place directly at the beginning, | | |
| | | | | | | |i.e. at the end of the header! | | |
| |Frank Oemig |5.2.2.4 |A |S | | |Introduce the comment and support | | |
| |HL7 Germany | | | | | |indicator column into the standard | | |
| | | | | | | |message definition. | | |
| |Frank Oemig |5.2.3.x |A |S | | |Apply the correct formatting | | |
| |HL7 Germany | | | | | |templates (according to the style | | |
| | | | | | | |guide) to the examples. | | |
| |Frank Oemig |5.2.2.5 |N |Mi | | |The example display lines must not | | |
| |HL7 Germany | | | | | |appear within the output | | |
| | | | | | | |specification. | | |
| |Frank Oemig |5.4.2 |N |Mj |QAK-4, data element 01434: data type HCT | |Data element 01434 (QAK-4) uses | | |
| |HL7 Germany | | | | | |unknown data type HCT! Due to the | | |
| | | | | | | |short segment definition wouldn’t | | |
| | | | | | | |it be better to define three | | |
| | | | | | | |separate fields instead of a new | | |
| | | | | | | |data type? Proposal: “Hit count | | |
| | | | | | | |total”, “Hit count this payload” | | |
| | | | | | | |and “Hit count remaining”; all of | | |
| | | | | | | |data type NM! | | |
| |Frank Oemig |5.4.4.3.1 |N |Mj |data element 01593: sort control, data | |This data element is defined as a | | |
| |HL7 Germany | | | |type SRT | |data element, but is used as a | | |
| | |5.4.4.3.2 | | | | |component. Therefor it does not | | |
| | | | | |data element 01594: segment group | |follow the guidelines of the style | | |
| | | | | |inclusion, data type ID | |guide. | | |
| | | | | | | |But more important is the | | |
| | | | | | | |complexity and usage of this data | | |
| | | | | | | |element: Wouldn’t it be better to | | |
| | | | | | | |introduce both data elements as new| | |
| | | | | | | |and repetitional fields, say QPD-3 | | |
| | | | | | | |and QPD-4. As a result the current | | |
| | | | | | | |QPD-3 would become QPD-5. | | |
| | | | | | | |Additionally I would refer to the | | |
| | | | | | | |fields by the help of the column | | |
| | | | | | | |number. This would allow for using | | |
| | | | | | | |a numeric field. | | |
| | | | | | | |The explanation of how to use this | | |
| | | | | | | |field and its components is not | | |
| | | | | | | |sufficient. | | |
| | | | | | | |On the other hand you can not | | |
| | | | | | | |append this information to the end | | |
| | | | | | | |of each possible data element | | |
| | | | | | | |because of its data type! Therefor | | |
| | | | | | | |this solution will not work | | |
| | | | | | | |properly! | | |
| |Frank Oemig |5.4.7.2 |A |T |Table 0440: | |Is listed as a valid value: delete | | |
| |HL7 Germany | | | |“Value – Description” | |this item! | | |
| | |8.3.1 |A |Mj |message type MFN^M01-M06 |MFN^M01-M06^MFN_M01 | | | |
| |Frank Oemig |8.3.1 |A |Mj |message type MFK^M01-M06 |MFK^M01-M06^MFK_M01 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |8.3.2 |A |Mj |message type MFD^MFA |MFD^MFA^MFD_MFA | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |8.3.2 |A |Mj |message type ACK^MFA6 |ACK^MFA^ACK | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |8.3.3 |A |Mj |message type MFQ^M01-M06 |MFQ^M01-M06^MFQ_M01 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |8.3.3 |A |Mj |message type MFR^M01-M06 |MFR^M01-M06^MFR_M01 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |8.7.4.6.1 |A |Mj |reference (normal) range: | |the components don’t have a data | | |
| |HL7 Germany | | | | | |type: please define one | | |
| |Frank Oemig |8.7.4.6.3 |A |Mj |age range: | |the components don’t have a data | | |
| |HL7 Germany | | | | | |type: please define one | | |
| |Frank Oemig |8.7.4.6.4 |A |Mj |gestational age range: | |the components don’t have a data | | |
| |HL7 Germany | | | | | |type: please define one | | |
| |Frank Oemig |8.7.4.7 |A |Mj |critical range for ordinal and continuous | |the components don’t have a data | | |
| |HL7 Germany | | | |observations: | |type: please define one | | |
| | | | | | | | | | |
| |Frank Oemig |8.7.4.8 |A |Mj |absolute range for ordinal and continuous | |the components don’t have a data | | |
| |HL7 Germany | | | |observations: | |type: please define one | | |
| | | | | | ^ ^ ^| | | | |
| | | | | | | | | | |
| |Frank Oemig |8.7.4.9 |A |Mj |delta check criteria: | |the first component is not defined | | |
| |HL7 Germany | | | | ^ ... | |further | | |
| |Frank Oemig |8.7.9 |A |T |index information in heading: “OM1” |“OM7” | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |8.11.2 |A |T | | |add index information into heading | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |10.2 |A |Mj |message type SRM^S01-S11 |SRM^S01-S11^SRM_S01 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |10.2 |A |Mj |message type SRR^S01-S11 |SRR^S01-S11^SRR_S01 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |10.3 |A |Mj |message type SIU^S12-S24, S26 |SIU^S12-S24, S26^SIU_S12 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |10.3 |A |Mj |message type ACK^S12-S24, S26 |ACK^S12-S24, S26^ACK | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |12.2.1 |A |Mi |Message Definition Header: |PGL^PC6, PC7, PC8^PGL_PC6 | | | |
| |HL7 Germany | | | |PGL^PC6, PC7, PC8 | | | | |
| |Frank Oemig |12.2.1 |A |Mj |Message Definition: | |replace “OBR, etc.” by the | | |
| |HL7 Germany | | | |OBR, etc. | |following sequence(I guess these | | |
| | | | | | | |alternatives are allowed): “”.| | |
| | | | | | | |Please compare with 2.11 and 4.3.2 | | |
| |Frank Oemig |12.2.2 |A |Mi |Message Definition Header: |PPR^PC1, PC2, PC3^PPR_PC1 | | | |
| |HL7 Germany | | | |PPR^PC1, PC2, PC3 | | | | |
| |Frank Oemig |12.2.2 |A |Mj |Message Definition: | |compare with 12.2.1 | | |
| |HL7 Germany | | | |OBR, etc. | | | | |
| |Frank Oemig |12.2.3 |A |Mi |Message Definition Header: |PPP^PCB, PCC, PCD^PPP_PCB | | | |
| |HL7 Germany | | | |PPP^PCB, PCC, PCD | | | | |
| |Frank Oemig |12.2.3 |A |Mj |Message Definition: | |compare with 12.2.1 | | |
| |HL7 Germany | | | |OBR, etc. | | | | |
| |Frank Oemig |12.2.4 |A |Mi |Message Definition Header: |PPG^PCG, PCH, PCJ^PPG_PCG | | | |
| |HL7 Germany | | | |PPG^PCG, PCH, PCJ | | | | |
| |Frank Oemig |12.2.4 |A |Mj |Message Definition: | |compare with 12.2.1 | | |
| |HL7 Germany | | | |OBR, etc. | | | | |
| |Frank Oemig |12.2.6 |A |Mj |Message Definition: | |compare with 12.2.1 | | |
| |HL7 Germany | | | |OBR, etc. | | | | |
| |Frank Oemig |12.2.8 |A |Mj |Message Definition: | |compare with 12.2.1 | | |
| |HL7 Germany | | | |OBR, etc. | | | | |
| |Frank Oemig |12.2.10 |A |Mj |Message Definition: | |compare with 12.2.1 | | |
| |HL7 Germany | | | |OBR, etc. | | | | |
| |Frank Oemig |12.2.10 |A |T |Message definition contains “0” | |delete “0” | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |12.2.10 |A |T |Message definition: | |insert “[“ in front of “{“ | | |
| |HL7 Germany | | | |{ NTE } ] | | | | |
| |Frank Oemig |12.2.12 |A |Mj |Message Definition: | |compare with 12.2.1 | | |
| |HL7 Germany | | | |OBR, etc. | | | | |
| |Frank Oemig |12.2.12 |A |T |Message definition (2nd column): | |move “}]” to first column | | |
| |HL7 Germany | | | |“}]” | | | | |
| |Frank Oemig |13.2.1 |A |Mi |message type ESU^U01 |ESU^U01^ESU_U01 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.2 |A |Mi |message type ESR^U02 |ESR^U02^ESR_U02 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.3 |A |Mi |message type SSU^U03 |SSU^U03^SSU_U03 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.4 |A |Mi |message type SSR^U04 |SSR^U04^SSR_U04 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.5 |A |Mi |message type INU^U05 |INU^U05^INU_U05 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.6 |A |Mi |message type INR^U06 |INR^U06^INU_U05 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.7 |A |Mi |message type EAC^U07 |EAC^U07^EAC_U07 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.8 |A |Mi |message type EAR^U08 |EAR^U08^EAR_U08 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.9 |A |Mi |message type EAN^U09 |EAN^U09^EAN_U09 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.10 |A |Mi |message type TCM^U10 |TCM^U10^TCM_U10 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.11 |A |Mi |message type TCR^U11 |TCR^U11^TCM_U10 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.12 |A |Mi |message type LSU^U12 |LSU^U12^LSU_U12 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.13 |A |Mi |message type LSR^U13 |LSR^U13^LSU_12 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |13.2.13 |A |Mj | | |devide table for message definition| | |
| |HL7 Germany | | | | | |for answer into a separate table | | |
| |Frank Oemig |14.2.x |A |Mi | | |define event code | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |7.1.2.4 |A |T | | |illegal reference (“Word macro”) | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |7.3.1.9 |A |T |heading: “OBOR-9” |“OBR-9” | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |7.3.1.12 – 7.3.1.15 |A |T |heading |“OBR-10” missing | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |7.6.1 |A |Mj |message type: CRM^C01-C08 |CRM^C01-C08^CRM_C01 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |7.6.2 |A |Mj |message type: CSU^C09-C12 |CSU^C09-C12^CSU_C09 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |7.10.1 |A |Mj |message type: PEX^P07, P08 |PEX^P07, P08^PEX_P07 | | | |
| |HL7 Germany | | | | | | | | |
| |Frank Oemig |7.10.2 |A |Mj |message type | | | | |
| |HL7 Germany | | | | | | | | |
| |Peter Rontey VA |4.16.2 |N |Mj | ~ | ~ |QRF segment, QRF-5-other query | | |
| | | | | | ~ ~ ~ |number> ~ ~< mother's |deviates from that definition with | | |
| | | | | | ~ |each of which represents a | | |
| | | | | | ~ |composite element of undetermined | | |
| | | | | |~ ~< father's name |data type. | | |
| | | | | | |first>~< father's name middle> ~ |Such a construct will not parse | | |
| | | | | | | is)? | | |
| |Peter Rontey VA |4.18.1,para#1,sent# |A |T |Identifiers other than patient name are |Identifiers other than patient name are | | | |
| | |3 | | |defined in the query by giving positional |defined in the query by giving positional | | | |
| | | | | |meaning to the repeat delimiters in the |meaning to the repeat delimiters in the | | | |
| | | | | |QRF-5-other query subject filter segment, |QRF-5-other query subject filter field, as| | | |
| | | | | |as specified in 4.16.2, "Queries for |specified in 4.16.2, "Queries for | | | |
| | | | | |immunization records (QRF Segments)." |immunization records (QRF Segments). | | | |
| |Peter Rontey VA |4.18.1 |N |Mj |MSH|^~\&||GAVACREC||AZVACREC|199505221605||MSH|^~\&||GAVACREC||AZVACREC|199505221605||Related to issue #1 above | | |
| | | | | ||VXQ^V01|950522GA40|T|2.4||| ||VXQ^V01|950522GA40|T|2.4||| | | | |
| | | | | |AL |AL | | | |
| | | | | |QRD|199505221605|R|I|950522GA40|||1000^RD||QRD|199505221605|R|I|950522GA40|||1000^RD|| | | |
| | | | | |JONES^JOHN^RICHARD|VXI|SIIS |JONES^JOHN^RICHARD|VXI|SIIS | | | |
| | | | | |QRF|AZVACREC||||256946789~19900607~CA~CA99|QRF|AZVACREC||||256946789~19900607~CA~CA99| | | |
| | | | | |999999~88888888~JONES^MARY^S |999999~88888888~~ Y>~~ | | | |
| | | | | |UE~ |898666725~~ | | | |
| | | | | |898666725~JONES^MATHEW^LEE~822546618 |~~822546618 | | | |
| |Laura Sato |2.8.31 |A |T |& ^ ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- minecraft version 1.12.2 free download
- aprwin version 6 2 0
- minecraft version 1 12 2 free download
- minecraft version 1 10 2 download
- minecraft version 1 10 2 free
- minecraft version 1 5 2 download
- pip version for python 2 7
- proxy ballot sample
- minecraft version 1 13 2 download
- georgia ballot proposed constitutional amendments
- constitutional amendments on ballot 2020
- minecraft version 1 12 2 download pc