Fairhaven, The River

Good podcast video from MIT Libraries

This video (1.5hr) stood out from the crowd that I usuallyscan.  It's got good insights into the learning processes of high-end digital native kids (MIT undergrads), the needs of a modern library, what MIT's educational life is like, and where MIT libraries are heading.  Some of it's obvious and some was surprising.  For example, the changing role of books on paper was not what I expected.

Good standards take time

     "I want what I want, I want it now" - by Lauren Christy

Those with no insight into the process want standards now.  They don't understand what it takes to make a successful high quality standard, and their demands for "NOW" result in the proliferation of bad, duplicative, and failed standards.

Good standards take time.  Three standards that have withstood the test of time show this:

• ASCII.  This simple characterset standard took three years of work, from 1963 to 1966 to develop.  It has been tweaked a few times since, but it is fundamentally unchanged.
• TCP/IP.  This networking standard was first outlined on paper and funding began in 1973.  The initial operational roll-out was 1982.  So it took nine years of work.  It has been tweaked a few times since then, but it is fundamentally unchanged.
• Fortran 77.  The Fortran effort was a split effort that began in 1966.  One split simply took the language manual for the leading IBM 7094 Fortran compiler and issued it as Fortran 66.  That took 9 months of publications and editorial scrubbing of the manual.  (This would be impossible in today's intellectual property environment.  Back then, it was easy to get IBM's permission.)  The development of the language standard took 11 years.  Fortran 77 was published early in 1978.

The DICOM addition of MPEG-4 HD video encoding is one of the simplest and fastest standard additions that I've ever experienced.  It took only 9 months.  Examining the steps and work involved may help understand why it takes time to do a good job on a standard.  More complex or controversial standards take much longer.

The stages involved were:

• Workitem definition and approval
• Prepare first draft for WG-06 review
• Prepare Public Comment version for WG-06 review and publication
• Prepare Ballot version for WG-06 review and publication
• WG-06 review and Final Text publication

DICOM has a substantial work item gate that must be cleared before work can start.  This eliminates most of the frivolous, hobby horse, and "boil the ocean" proposals.  To get started the sponsors must:

• Provide at least one realistic use case.  This use case will be reviewed by the medical professional societies and they must agree that it is realistic to expect it in regular medical practice.  It's important to understand that this is a professional society opinion, not an individual doctor's opinion.  This keeps out the research and personal hobby proposals.
• Identify two vendors (not just one) that have a commitment to work on the standard and probably implement it.
• Have a verifiable completion goal.  This is important for project management, scope management, etc.  "Issue a standard" is not a completion goal.  It must be clear how the completion goal is related to the use case and reflects the standardization need.
• Have a realistic work plan for accomplishing the goal.  This will be reviewed by the full committee and revised based on experience with other standards work.
• Have an identified person to act as editor.  This can't be a company or group commitment.  It has to be a person who has this job as an assignment from their boss.  (This is also a measure of the reality of the vendor commitments.)

The workitem in this case was extremely simple:  Add the MPEG-4 HD (high definition) encoding as an option for any DICOM IOD that encodes video.

DICOM already had MPEG-2 and MPEG-4 SD (standard definition).  It was obvious that HD cameras were becoming practical for endoscopy and other uses.  It was clear that the video industry was ready for widespread deployment of high definition equipment.  Multiple vendors wanted a DICOM standard so that they would have a stationary feature target.  Completion was clear and the estimated time was "under a year".  It had clearly identified staff. The expected project plan was:

• prepare initial draft (about a month)
• initial DICOM WG-06 review
• one or two tcons to deal with review comments (about two months)
• WG-06 approval for public comment issuance
• 7 week comment period
• one tcon to deal with public review comments (if any) (about two months)
• WG-06 approval for ballot issuance
• 45 day ballot period
• one tcon to deal with ballot comments (if any) (about a month)
• WG-06 review, final text preparation, issue standard

I'm part of WG-06, so my perspective is based on the four WG-06 interactions. 

The initial draft was fairly simple and easy.  They took the final text for the addition of MPEG-4 SD and made various textual changes to change it into an HD proposal.  Issues that were raised in the initial review:

• There were some additional video uses in DICOM that had been added since the MPEG-4 SD was initially issued.  These needed to be added to the HD.
• There was an open question on mandatory formats.  This needed to be resolved with a firm proposal before public comment.  Public comment can respond with corrections, but you cannot leave that kind of detail out.  In theory, the public comment version should be a complete ready to go standard.  In practice there are always problems, but you only find these through the effort of writing a complete standard and then examining how well it will work.
• There were some editorial problems, like missing references to the MPEG standards documents.

Resolving the formats issue illustrates why standards take time.  There are two core questions that need answering:  what formats were going to be built into the cameras?  what formats were going to be reasonable to implement on all of the possible players?  This means getting the attention and feedback from the chip design teams in the consumer and professional camera divisions of non-medical companies.  This takes time.  They are busy dealing with their own product issues.

The public comment version had a firm proposal for mandatory formats based on partial feedback from the sensor makers and player vendors.  It went through WG-06 review which fixed more editorial problems and made clarity revisions.  This review identified two more issues for public comment:

• The license and patent section was missing.  This was not viewed as a stopper issue, but clearly needed to be fixed before ballot.  These issues are not open to standards modification, and would not have a likely impact on the rest of the standard.
• The proposed mandatory formats approach would permit a system to offer HD formats without offering SD formats.  The acceptability of this was an identified public comment issue.

The public comment feedback gives time for a repeat of the process of getting feedback from chip vendors, camera makers, player makers, and starts to get real feedback from the workstation and device vendors.  The workstation and device vendors mostly ignored the earlier stages because they plan to buy sub-components from the camera and player makers.  At this stage they start confirming with their current and candidate vendors that this standard will be acceptable.  This gets a much more complete review from all of those vendors.
       The result was:

• Some minor revisions to the mandatory formats.  The bigger issue of allowing an HD only device was considered acceptable.  The marketplace and functional requirements would take care of that.
• The presentation and layout of the mandatory format description needed clarification to remove some confusion.

The ballot version was prepared easily, with the inclusion of the format fixes and a section identifying the license and patent issues around MPEG-4 HD.

The ballot review cycle went very fast in WG-06.  There were a few more typos found and the ballot issued in about 15 minutes.

The ballot comments brought in some of the editorial consistency nit-pickers.  They don't waste their time on the earlier versions.  For the ballot versions you get a few of the QA nitpickers checking all the details, cross references, consistency, wording ambiguities, etc.  You also get the last comments from the chip, camera, and player vendors.  The medical device vendors send the ballot version to their vendors saying "Last chance.  This will be part of our next contract requirements.  Speak now if you will have a problem." 

The result was some feed back corrections from the editorial nit-pickers.  Even after all these reviews there were some sections that could be read more than one way.  Those familiar with the subject didn't notice the alternative incorrect readings, but the QA reviewers caught those problems.  The medical vendors got the OK from their vendors.

The approval and issuance of final text took about 15 minutes.  The editorial problems and ambiguities had been fixed based on the comments.

       This whole process took nine months.  But look at how many people had to be involved.  There were:

• clinical staff,
• medical professional societies,
• medical device vendors (including product planning, product management, legal, engineering, QA, manufacturing, and purchasing departments),
• camera and player vendors (again, all those same divisions),
• sensor chip vendors (primarily their product planning and product management teams, although legal and engineering might have been needed to advise them). 

Working on standards is not a drop everything type of issue.  All these groups give this work the same priority as their other routine work.  This is why there are the 7 week and 45 day response periods.  These give enough time for all the handoffs and internal processes needed to get good quality feedback.

 This is for an incredibly simple seeming standard.  For novel technology and significantly complex issues, there is much more engineering involved and the internal review and feedback cycles take more work.

       (Bad movie reference: reread this imagining Denise Richards washing a Jeep.)

How to read DICOM

I've published my first draft of a "The structure of DICOM".  It's clear from comments and descriptions that very few people understand what DICOM covers or how the pieces fit together.  This will be revised from time to time based on comments, and extended with other pages.

This is aimed at the information architect who wants to know what are the major subjects covered by DICOM, where is the information found, and how is the DICOM documentation organized.  That seems to be a major gap.

News has a problem with economic reporting

News, whether web or paper, needs a story.  It's extremely hard to transform very slow processes into an interesting story, and even harder to explain complex slow processes.  Unemployment is an example.

All of the economic reporting that I see on unemployment tries to bring some excitement to the story.  Big news.  Sudden change. Get people scared or excited.  They present as complicated a diagram as possible, or find some chart that looks really bad or suddenly good.  But there is rarely any effort to take apart the complex system and show the separate parts in a way that can be understood.

This diagram illustrates the problem with using a clearer presentation.

Click on graph for larger image.
It separates out one important component in employment from the others. This shows how many people are working, and in a way that lets you compare it with other recessions.

There's no exciting story here.  It shows that this is a really severe recession, much worse than anything since World War Two.  It also shows that all the fuss and excitement over this plan or that change has made no difference.  You don't see changes due to elections either.  The one and only government driven change is the employment bubble from the 2010 census.

You also see an interesting evolution in the nature of recessions.  The last three have been very smooth and without the sudden jumps of previous ones.  They are also lasting much longer.

There are probably some very important lessons to be learned from this that would help in making decisions.  But there is no story.  There is no cause for sudden joy or sorrow.  There is no reason for panic and fear.  It's a long slow process that needs understanding.

As a result, it does not make the general news.  They need big excitement like "Unemployment reaches X".  A difficult to explain slowly changing increase in the number of actual jobs is not "news".

Graph from Calculated Risk.

Standards are not enough, you also need good administrative decisions

John Halamka's blog post shows the importance of having good administrative procedures to accompany the available standards and technology. Without these, the new technology and standards do not improve patient care as they should.

I noticed several administrative decisions that made his experience much worse and likely caused some confusion. They are not driven by standards or technology.

First, they apparently failed to explain the nature of the CD that he was given. He discusses the need for a vendor neutral format that can be used by any vendor. The CD that he was given was almost certainly exactly that. The DICOM media formats and IHE PDI profile are supported by over 100 different vendors. It is widely used and vendor neutral. But they apparently failed to explain this. I can understand the staff not explaining this, but it would have cost nothing to include an explanatory document on the CD itself.

Second, they only included a Windows viewing application. I can understand the need to make a selection. There are over 100 different DICOM viewers available for Windows, Mac OS, Linux, IOS (iPhone/iPad), and Android. It can be too burdensome to provide support for all the possibilities. But why didn't they include a document explaining that there are free, open source, and commercial viewers available for all these systems? I would point MacOS users to Osirix as a starting point, and give some google hints for the others.

Leaving patients with no documentation or hints about where to get a viewer is another administrative mistake. It would cost very little to explain the alternatives in the document describing the CD.

Third, why didn't he get the CD immediately? When I went to the vet I got a DICOM CD with my cat's X-rays immediately. It was just part of the end of visit process. There is no technical reason for a substantial delay or a 9-5 policy. All that's involved is transmitting the images to a system with a CD burner and burning the CDs. This should take tens of minutes at most. It will be less if the network and CD burner are fast. If this were part of the routine process, I would expect the burner to be finished before the patient is ready to leave. The IHE profiles specify the routine process for creating CDs and DVDs. There are more than 10 vendors offering IHE compliant CD creating products, and they all exchange data without problems.

It's an administrative policy decision that I don't understand to force patients to return later with some 9-5 limit on services.

Finally, there is some confusion about whether DICOM requires a PACS system.

Back when imaging was done on film, radiologists, dentist, veterinarians, and other imaging users had filing cabinets with specialized folders and labels to keep track of all the films. The organizing and managing of the film library was a necessary part of daily operations. It could consume a huge floor space and require a large staff.

With the move to digital images, this organizing and managing of images has shifted from film cabinets in huge rooms to image management software and disk drives. It's much smaller and faster than the film libraries, but it remains a necessary part of daily operations.

What DICOM has done is standardize the interface to this image management system. Radiologists call this system "PACS", but other groups like dentists and veterinarians often just call it their image management system. It is normal in a hospital to have a PACS from one vendor, with workstations and modalities from many other vendors. This works because DICOM has standardized the PACS interfaces. The IHE actor called the "Image Manager" is found in many IHE profiles is a PACS. The profiles specify both the DICOM interactions and the HL7 interactions for the common hospital activities.

It is possible to use DICOM without having a PACS system. There are small niche uses that do not need to organize and manage their images. These are not common, but they exist and do use DICOM. In most applications you need an image management system. PACS systems are used because the applications need an image management system, not because DICOM requires it. DICOM allows you to choose the image manager vendor independently from the other vendors and still expect everything to fit together and work.

The range of needs for image management is huge. Open source image managers like dcm4che co-exist with very large expensive commercial image managers. The users can decide how much they want to do by themselves and how much they purchase. The systems can be sized appropriately to the volume of imaging that they perform. As a proof of concept, we installed and ran dcm4che on an Android phone. I do not recommend using an Android phone as the PACS for any serious imaging operations, but it worked quite well for a small number of small images. Small research applications do not need to pay the cost of the large systems needed by large hospitals.

Disclosure, I work for a PACS vendor and am involved with dcm4che.