At this week's WG-06 meeting we have one item that reflects the need to think about installed base and compatibility. We've got a problem with an old basic component of almost every DICOM SOP class. There is a fundamental element for encoding coded terminology. Twenty years ago, when this element was defined, nobody expected these opaque code values to be longer than 16 characters. These are code values like ICD-9, SNOMED, and LOINC. Now, we've got coding systems using OIDs, UUIDs, and URIs for codes. The latest version of SNOMED uses codes that are 18 characters long, and longer for local extensions. So DICOM needs to find a fix.
There are several alternatives. Each is an easy software change. Each has problems with failure modes. We can't find a fix without failure modes. Software that is unprepared for longer code values will have some form of failure when given an object with longer code values.
We spent about 45 minutes discussing this yesterday. We spent the whole time looking at failure modes. What will happen to existing implementations that receive new objects. What will be all the failure modes. What will be the recovery modes? How will the errors propagate? How will this affect archived objects?
We've picked an approach and will be writing up the recommended change so that toolkit implementors and others can evaluate the ramifications and comment on what we missed. Reviewing the final form will take another 15 minutes.
This little change consumed an hour this week and will consume much more. We dealt with the complete review of a new RESTful service for obtaining capabilities of archive services in less time.
Nobody thinks this is unreasonable. DICOM is not a greenfield. You need to spend the time that it takes to avoid introducing failures.
Comments