Detection of acute myocardial infarction To the editor: Ko, Kostuk and Deatrich (Can Med Assoc J 116: 260, 1977) reported that in myocardial infarction a linear relation exists between the serum creatine phosphokinase (CPK) concentration and the scintigraphic area of myocardial uptake of technetium99m-stannous pyrophosphate (99mT.PYP) with good correlation (r = 0.74). For some years it has been appreciated that a general relation exists between height of enzyme increase and prognosis (and therefore infarct size) in acute myocardial infarction.1" However, this is not a close relation for at least two reasons. The authors correctly noted that once-daily blood sampling may miss the peak serum CPK value in view of its rapid appearance and short half-life. However, with frequent sampling and documentation of a true peak serum CPK value, actual infarct size may differ in two patients in whom this peak is the same, because not all infarcts release CPK at the same rate; therefore a large infarct that releases CPK slowly may produce a peak serum CPK value no higher than that from a smaller infarct that releases CPK rapidly. I have discussed these points in more detail in a recent issue of the Journal (Can Med Assoc J 117: 255, 1977). Quantitative enzymatic estimation of infarct size requires approaches such as that developed by Roberts, Henry and Sobel.3 It could be that the three "malfits" described by Kostuk and his colleagues might better fit the linear regression if they had used the approach of Roberts and associates. The 6000 U/L infarct had an excessively high peak serum CPK value for the scintigraphic area, which could mean that enzyme release was very rapid and short-lived, giving the impression of a larger infarct than was actually present. The 347 and 536 U/L infarcts had low peak serum CPK values for the scintigraphic areas; this could have been due to gradual CPK release over many hours, resulting in peak values that suggested the infarcts were smaller than they actually were. The authors are correct in their contention that "comparison of estimates of infarct size in animals and man by both scintigraphic and serum CPK measurement needs to be made" using the serial CPK technique. JOHN A. CAmNs, MD, FRCP[C] Division of cardiology McMaster University Medical Centre London, Ont.
References 1. KIBE 0, NILssoN NJ: Observations on the diagnostic and prognostic value of some enzyme tests in myocardial infarction. Acta Med Scand 182: 597, 1967
2. SOBEL BE, BRESNAHAN GF, SHELL NE, et al: Estimation of infarct size in man and its relation to prognosis. Circulation 46: 640, 1972 3. ROBERTS R, HENRY PD, SOBEL BE: An improved basis for enzymatic estimation of infarct size. Circulation 52: 743, 1975
The Trojan computer To the editor: Articles on computers by Dominic Covvey and coauthors are always worth reading. Now and again, however, they hit out at the wrong "computeresque curlique". For example, in their article in the Journal (Can Med Assoc J 117: 273, 1977) Covvey and McAlister give, out of context, an extract of a urinalysis report (003. WBC/HPF) to illustrate a computer output that requires "a new attitude or set of skills" to enable one to interpret it. But does it? They offer no proof. I leave it to the readers of the Journal to decide for themselves if the routine SMA report I provide (Fig. 1) requires new attitudes or skills. This report was produced by the University Hospital's commercially available laboratory management system. I think Covvey and McAlister really meant that the layout of the report is of critical importance. Comments on leading zeros are not really relevant in that context. AR. HENDERSON, B SC, MB, PH 1), MRC PATH Department of clinical biochemistry University Hospital London, Ont.
To the editor: We are pleased that Dr. Henderson took the time to read our article and to comment on it, and that he has provided us with the opportunity to comment critically and constructively on the real output of a real system. Obviously the example we gave does not require a "new attitude or set of skills" to be interpreted. It should not, however, in our opinion, be "satisfactory to the user" (to put our comment in the context in which it actually appeared). This is what we said and meant. Why not satisfactory? Because WBC/ HPF is an integer, not a floating point number. The currently accepted way of printing the integer "three" is "3" not SERUM CHEM S-SODIUM S-POTASSIUM S-CHLORIDE S-BICARB S-BUN 5-CREATININE S-PROT,TOTAL S-ALBUMIN S-CALCIUM S-PHOSPH S-GLUCOSE 5-URATE S-BILI,TOTAL
"003.". Certainly the latter is more acceptable than ±3.0 E+00 - the "scientific" or logarithmic variation - but why shouldn't a user get what he wants: "3" or at the worst "3."? I have made the following observations on Dr. Henderson's output. The typewritten version he has provided is excellent in terms of print quality. Actual computer-generated output is, however, usually much less readable (e.g., line printer or dot matrix printer output). Also he has supplied a cumulative report and that's not easy to get. The data all appear to be forced to conform to an arbitrary 4-character length (3 numerics and a decimal point); hence the leading zeros and the everpresent decimal points even where they are not necessary. This is lazy programming or perhaps a reflection of programming restrictions caused by the computer system used. Also, most people prefer output with the decimal points aligned vertically making numbers easier to read and the number size more obvious. The column with which the ± or sign is associated is not obvious at first glance especially if the signs appearing between the first and second columns and after the last column were absent. The dates and times at the top of the report can be confusing. The numeric dates cause problems near the beginning of the month. Why not have a three-letter month code; for example, Jan., Feb.? The times aren't clear to outsiders, but perhaps local users know whether they refer to the time a specimen was taken, the time it was processed or the time the report was produced. Again, in our opinion, laziness on the part of the developer forces work on the part of the user. A few labels here and there can improve matters greatly. Admittedly these are small points but this output is the buck that stops with the user, which he must use and will subsequently complain about. Since the reports have been considered worth paying for and worth acquiring a system to produce, why not make them
27/8 7:08
28/8 6:59
29/8 6:40
30/8 7:16
31/8 7:39
2/9 13:34
UNITS
137. 03.6 091. 36.0 004. 00.4
137. 03.5 091. 37.0 004. 00.4 05.1 02.6 08.2 04.4 137. 03.8 00.5
138. 03.5 093. 40.0 003. 00.5 05.3 02.8 08.5 04.4 115. 04.0 00.4
139. 03.9 095. 36.2 002. 00.2 05.4 03.4 08.8 04.0 113. 03.0 00.6
137. 03.9 094. 34.0 003. 00.3 05.3 03.3 08.9 03.4 128. 03.0 00.4
140. 04.4 095. 37.0 + 008. 00.6 -
MMOL/L MMOL/L MMOL/L MMOL/L MG/DL MG/DL G/DL G/DL MG/DL MG/DL MG/DL MG/DL MG/DL
140.
+ -
+ +
+ HIGH
+ +
+ -
+ -
NORMALS LOW-HIGH 135. 03.5 095. 24.0 007. 00.7 06.0 03.5 08.5 02.5 070. 02.5 00.2
145. 05.0 105. 32.0 020. 01.3 08.0 04.5 10.5 04.0 140. 06.9 01.0
- LOW
FIG. 1-Computer output of routine SMA report. CMA JOURNAL/NOVEMBER 5, 1977/VOL. 117 1005
References 1. KIBE 0, NILssoN NJ: Observations on the diagnostic and prognostic value of some enzyme tests in myocardial infarction. Acta Med Scand 182: 597, 1967
2. SOBEL BE, BRESNAHAN GF, SHELL NE, et al: Estimation of infarct size in man and its relation to prognosis. Circulation 46: 640, 1972 3. ROBERTS R, HENRY PD, SOBEL BE: An improved basis for enzymatic estimation of infarct size. Circulation 52: 743, 1975
The Trojan computer To the editor: Articles on computers by Dominic Covvey and coauthors are always worth reading. Now and again, however, they hit out at the wrong "computeresque curlique". For example, in their article in the Journal (Can Med Assoc J 117: 273, 1977) Covvey and McAlister give, out of context, an extract of a urinalysis report (003. WBC/HPF) to illustrate a computer output that requires "a new attitude or set of skills" to enable one to interpret it. But does it? They offer no proof. I leave it to the readers of the Journal to decide for themselves if the routine SMA report I provide (Fig. 1) requires new attitudes or skills. This report was produced by the University Hospital's commercially available laboratory management system. I think Covvey and McAlister really meant that the layout of the report is of critical importance. Comments on leading zeros are not really relevant in that context. AR. HENDERSON, B SC, MB, PH 1), MRC PATH Department of clinical biochemistry University Hospital London, Ont.
To the editor: We are pleased that Dr. Henderson took the time to read our article and to comment on it, and that he has provided us with the opportunity to comment critically and constructively on the real output of a real system. Obviously the example we gave does not require a "new attitude or set of skills" to be interpreted. It should not, however, in our opinion, be "satisfactory to the user" (to put our comment in the context in which it actually appeared). This is what we said and meant. Why not satisfactory? Because WBC/ HPF is an integer, not a floating point number. The currently accepted way of printing the integer "three" is "3" not SERUM CHEM S-SODIUM S-POTASSIUM S-CHLORIDE S-BICARB S-BUN 5-CREATININE S-PROT,TOTAL S-ALBUMIN S-CALCIUM S-PHOSPH S-GLUCOSE 5-URATE S-BILI,TOTAL
"003.". Certainly the latter is more acceptable than ±3.0 E+00 - the "scientific" or logarithmic variation - but why shouldn't a user get what he wants: "3" or at the worst "3."? I have made the following observations on Dr. Henderson's output. The typewritten version he has provided is excellent in terms of print quality. Actual computer-generated output is, however, usually much less readable (e.g., line printer or dot matrix printer output). Also he has supplied a cumulative report and that's not easy to get. The data all appear to be forced to conform to an arbitrary 4-character length (3 numerics and a decimal point); hence the leading zeros and the everpresent decimal points even where they are not necessary. This is lazy programming or perhaps a reflection of programming restrictions caused by the computer system used. Also, most people prefer output with the decimal points aligned vertically making numbers easier to read and the number size more obvious. The column with which the ± or sign is associated is not obvious at first glance especially if the signs appearing between the first and second columns and after the last column were absent. The dates and times at the top of the report can be confusing. The numeric dates cause problems near the beginning of the month. Why not have a three-letter month code; for example, Jan., Feb.? The times aren't clear to outsiders, but perhaps local users know whether they refer to the time a specimen was taken, the time it was processed or the time the report was produced. Again, in our opinion, laziness on the part of the developer forces work on the part of the user. A few labels here and there can improve matters greatly. Admittedly these are small points but this output is the buck that stops with the user, which he must use and will subsequently complain about. Since the reports have been considered worth paying for and worth acquiring a system to produce, why not make them
27/8 7:08
28/8 6:59
29/8 6:40
30/8 7:16
31/8 7:39
2/9 13:34
UNITS
137. 03.6 091. 36.0 004. 00.4
137. 03.5 091. 37.0 004. 00.4 05.1 02.6 08.2 04.4 137. 03.8 00.5
138. 03.5 093. 40.0 003. 00.5 05.3 02.8 08.5 04.4 115. 04.0 00.4
139. 03.9 095. 36.2 002. 00.2 05.4 03.4 08.8 04.0 113. 03.0 00.6
137. 03.9 094. 34.0 003. 00.3 05.3 03.3 08.9 03.4 128. 03.0 00.4
140. 04.4 095. 37.0 + 008. 00.6 -
MMOL/L MMOL/L MMOL/L MMOL/L MG/DL MG/DL G/DL G/DL MG/DL MG/DL MG/DL MG/DL MG/DL
140.
+ -
+ +
+ HIGH
+ +
+ -
+ -
NORMALS LOW-HIGH 135. 03.5 095. 24.0 007. 00.7 06.0 03.5 08.5 02.5 070. 02.5 00.2
145. 05.0 105. 32.0 020. 01.3 08.0 04.5 10.5 04.0 140. 06.9 01.0
- LOW
FIG. 1-Computer output of routine SMA report. CMA JOURNAL/NOVEMBER 5, 1977/VOL. 117 1005
