Configure schema warnings in the Error Handling and Logging section of the DB Maintenance tab. In the Edit Schema window click on the DB Maintenance button on the toolbar.

 

 

IMPORTANT NOTE: If you are using Schema Training then ALL of your warning levels MUST be set to "Treat as Fatal" as shown above.

 

Schema warnings only apply to INBOUND processors (see importing HL7) and fall into 4 categories.

 

Data Truncation occurs when an inbound processor is attempting to add HL7 data and the SQL database column is too small to accept the data. For example, the Patient Name is field #5 of the HL7 PID segment and can contain multiple components (varies depending on the HL7 version). Component 1 is the Last Name (Surname), Component 2 is the First Name, Component 3 is the Middle Name etc, etc. The 'raw' HL7 for this field might look like this |Public^John^Q|. In the schema engine the PID segment data table (<prefix>_Segment_PID_A) defines the patient middle name column (PID_F5_C3) as a Varchar(20). Suppose that the raw value looked like this (|Public^John^Papadopolas-Hydewhiteson|) note the middle name is now greater than 20 characters and will not fit into the database because it is too long. You have 4 options as to what will happen should this occur:

 

1.Do Nothing. If checked the schema engine software will simply truncate the data from the HL7 message to the maximum size allowed by the field.

2.Place in the C0 column. If a truncation situation arises the schema engine will place the ENTIRE value of the HL7 field into the appropriate C0 column of the table. So in the example above, when the system detects that it will have to truncate the middle name it would do so placing the truncated value in PID_F5_C3 BUT it would also place the ENTIRE raw value (Public^John^Papadopolas-Hydewhiteson) into the special column PID_F5_C0 (which is defined as a 'Text' column and can take any size data). See Special Handling for more information.

3.Log in the Errors table. If checked the truncated values will be placed in the appropriate columns AND also logged into the SchemaWarnings table where both the truncated and full values are stored. When this occurs the Warnings column in the <prefix>_HL7Data table is incremented by 1 for each occurrence.

4.Treat as FATAL. If checked the schema engine will ABORT processing whenever a truncation error occurs, also logging the error into the <prefix>_SchemaWarnings table. This gives you the opportunity to manually alter the size of the effected column(s) and then restarting your processor(s). It's brute force but it works.

See also: Special Handling, HL7 Vendors, Altering Schema Tables

 

Unknown Segment occurs when an inbound processor detects that an HL7 message contains a HL7 segment which does not exist in the HL7 vendor definition used to create the schema tables and thus has no schema segment table to load the data into. You have 3 options as to what will happen should this occur:

 

1.Do Nothing. If checked the schema engine will ignore the unknown segment(s) and will load only known segments into the schema data tables.

2.Log in the Errors table. If checked an entry will be logged into the SchemaWarnings table indicating that the HL7 message contained an unknown segment. When this occurs the Warnings column in the <prefix>_HL7Data table is incremented by 1 for each occurrence.

3.Treat as FATAL. As with Truncation errors the schema engine will ABORT processing whenever an unknown segment is detected and all processing will stop. This gives you the opportunity to research and create the appropriate segment data table (see HL7 Vendor Definitions and Repairing Schema Tables).

 

See also: Special Handling, HL7 Vendors, Altering Schema Tables