It doesn't take an evil overlord to destroy something. Things will fall apart on their own if you simply wait long enough.
Beyond a certain size, a software project, a publication, a technical specification, or a standard becomes unmanageable. This can be mitigated with processes, but processes executed by humans aren't nearly as a repeatable as processes managed using automation.
Let's take a look at an example of how something like this happens in standards...
In HL7 Version 2, the PV1 segment reports information about a patient visit. An important thing happens during an inpatient or emergency department visit, which is that the patient is discharged. You will want to know about this, in terms of both where to, and when. In HL7 Version 2.1, where is captured in PV1-37 Discharged To Location, and when in PV1-45 Discharge Date/Time.
Let's look at the evolution of PV1-37 over time.
Version | Datatype | Description |
---|---|---|
2.2 | CM | Components: <code> ^ <description> Definition: indicates a facility to which the patient was discharged. Refer to user-defined table 0113 - discharged to location. |
2.3.1 | CM | Components: <discharge location (IS)> ^ <effective date (TS)> Definition: This field indicates a facility to which the patient was discharged. User-defined table 0113 - Discharged to location is used as the Hl7 identifier for the user-defined table of values for this field. |
2.5.1 | DLD | Components: <Discharge Location (IS)> ^ <Effective Date (TS)> Definition: This field indicates the healthcare facility to which the patient was discharged and the date. Refer to User-defined Table 0113 - Discharged to Location for suggested values. |
2.8.2 | DLD | Components: <Discharge to Location (CWE)> ^ <Effective Date (DTM)> Definition: This field indicates the healthcare facility to which the patient was discharged and the date. Refer to User-defined Table 0113 - Discharged to Location in Chapter 2C, Code Tables, for suggested values. |
Originally, PV1-37 was just a composite made up of a code and a description. Between 2.2 and 2.3, the data types and description of the second part of the composite changed from <description> to <effective date (TS)>. Why? I don't know. It could quite simply have been someone asking "What do they put in the description field?", and someone else responding "Usually the discharge date" and from there maybe they decided to set the data type to TS, not realizing this data was already in PV1-45. NOTE: It's really hard to say what happened because this was back in 1994. The HL7 List Serve only tracks back to 2012 for pafm and V2 lists, and the historical tracker database only goes back to Version 2.5, which came out in 2006/7 time frame, and the ballot desktop only goes back to 2004.
In the 2.4-2.5 time frame the CM data type was replaced with a real data type (DLD), which was defined as being an IS followed by a TS. That we can determine from change request 135 in the HL7 change tracking database for Version 2.
Over time, IS data types were switched to CWE data types, and TS to DTM as you can see in Version 2.8.2 above.
So, somewhere along the way, we lost track of why <description> became <effective date>, and duplicated what was already in PV1-45 Discharge Date/Time.
People move on, knowledge gets lost, cruft and minor issues accumulate, technical debt accrues. Eventually, technology needs to be rebuilt, just like anything else, in order to be relevant, useful and most of all, well understood by all currently using it, or it collapses under its own weight.
No comments:
Post a Comment