Being mounted with the insight of the last section, we can now start to check our database. We will have to check for
During the rest of this section, we will merely see the output that was generated by the Prolog check clauses:
Removing Facts with undefined key value: retracting segment(G198, "")
There was a completely void segment definition caused while chapter 1 was processed. Something has screwed up, we can safely ignore this.
Now we're checking for tables which had not been defined in appendix A, but were used in the chapters. `chptbl.pl' was loaded and compared against table/3, result is `none', meaning that no undefined tables have been found. Next, we check for one to one relationship between table/2 and table/3, particularly if table/3 contains all of table/2, which is true. The descriptions of corresponding tables are consistent, which means, that we can savely exclude table/2 from the further process without loss of information.
Performing checks on: *** Tables chptbl compiled, 0.05 sec, 2,120 bytes. tables which are not yet defined: none tables from table/2 that are not in table/3: none tables with conflicting descriptions: none
The next part checks whether there are tables referred to for which there are no values defined. This is tue for a lot of tables but is not necessarily wrong. A table denoted as `user_defined' may well be undefined in the HL7 standard. But how about tables marked as `hl7_standard'? These may be references to tables defined by other standards, however we'll remember this problem in case we get into trouble but leave this alone for now. We also check if these missing tables are defined somewhere in the chapters, but they are in neither case. Finally we check for values which do not belong to a table, which would point us towards an error in our AWK scripts, but this is not the case.
tables without any value definition:
for class `hl7_and_user': 111,112,101,30,90,63.
in the chapters: none
for class `hl7_standard': 50,31,13,25,59,51,52,55,56,37,14,26,18,
75,17,29,35,41,15.
in the chapters: none
for class `user_defined': 117,23,19,120,21,22,32,43,44,45,46,47,
49,114,113,57,66,60,24,64,96,68,69,42,
72,86,73,79,118,81,83,84,10,87,88,89,92,
93,94,115,110,98,99.
in the chapters: none
values without any defining table: none
We do a similar processing of segment as we did with table above, i.e. checking for containment and conflicting descriptions, and do not find any surprise.
*** Segments segments from segment/2 that are not in segment/3: none segments with conflicting descriptions: none
Here follows the proof of our assumptions we made about the one-to-one relationship of field and data element. The extra check on conflicts in length is of historical reasons and will disapear, since it is done again by the general check for conflicts
*** Data elements
conflicts in length:
for data_element/9: none
for field/10: none
data_element/9 not in field/10: none
data_element/9 referenced by more than on field/10: none
field/10 and data_element/9 conflicts: [obx,4,769],[obx,6,562].
We see that our proof for one-to-one relationship succeeds, although there are inconsistencies concerning the data types of two pairs of field and data element, which are marked below:
field(obx,4,20,st,_,_,_,00769,"observation subid"). data_element(00769,"observation subid",obx,anr,20,nm,_,_,_). field(obx,6,20,st,_,_,_,00562,"units"). data_element(00562,"units",obx,anr,20,id,_,_,_).
Next, check is as self explaining as it succeeds well.
*** Fields field/10 without segment/3: none segment/3 without field/10: none
Finally there are the checks on messages. Message definition syntax is error free because Prolog has filtered out the mismatched parentheses. Nevertheless the problem was not corrected by Prolog, it was just removed. No syntax error does merely mean that the conversion scripts have their job well done. But then there are undefined message types. We don't care about the stuff from the `Widget' unfunctional area. That the messages of appendix C do not appear in the list of message types in appendix A is a fact that makes us worry once more about the `computerized data dictionary' which is said to be used to generate all the tables. Why are there inconsistencies? Why missing objects? In fact some people think that the computerized data dictionary is just a phantom. The ADR message type is unknown as well, but these problems could be fixed easily once we know about them.
However, undefined messages are not at all easy to fix, because how should we know about them if we are told nothing but its name and functional area? Note, that ORF and ORM are missing because of the syntax error above. While OCF has disappeared since v2.2, ARD and OSQ are still hanging around in the tables. We assume them to be fired next time as well.
Finally -- again forget about the widgets -- there are messages which refer to segments which are not defined. This is the worst error, that we have detected here, because it makes whole messages unimplementable. However, if we subtract the `ms'-typo in an ACK of which there are many other definitions as well, and once we know, that we have to treat `ANY' segments specially, there remains PD1, patient demographics, which is undefined. After all v2.2 has silently fired this segment as much as v2.1 silently contained this segment.
*** Messages
message definition syntax errors: none
undefined message types used: adr,nmd,nmq,nmr,wro,wrp.
undefined message: ard,ocf,orf,orm,osq.
undefined segments used: [wro,wid],[wrp,wdn],[wrp,wpn],[wrp,wpd],
[wrp,wdn],[wrp,wpn],[wrp,wpd],[wrp,wdn],[wrp,wpn],[wrp,wpd],
[ack,ms],[adt,pd1],[orr,any].