Fairhaven, The River

Defining Metadata

Summary:The Dublin Core work leaves out the importance of establishing an intended use as context for metadata.  Having this context then makes their level of interoperability and some of the issues around metadata storage much clearer.

Dublin Core leaves out the importance of intended use when discussing metadata.  It may be too obvious to those close to the problem. Their definition
      "Metadata is data about data>"
while correct, is insufficient.  All data is metadata from some context.  A clearer definition is:
      "Metadata is data about data, that is useful in a specific context of intended use."

Johm Moehrke's post gives good examples of the kinds of intended use that are important for medical records.

It makes sense to say that PatientID is metadata about a document in different contexts:

• It could mean that "This document is about PatientID"
• It could mean that "This document references PatientID", e.g., a document about a child references the mother.

You need the context of a use to understand metadata.

The context of use also explains the levels of interoperability that are otherwise left dangling by the Dublin Core.  The degree of interoperability is in the context of the intended use.  An example of the lowest level of interoperability might be a piece of metadata called "license".

At the lowest level, that word "license" is all you know about the metadata.  You can only guess about possible meanings.  You don't know the format of "license".  Maybe it is a text blob that contains legal language.  Maybe it's a URL to a document in an unknown format.  Maybe it's a UUID.  This is the lowest level of interoperability and it makes automated processing nearly impossible. But, it's an important improvement over having nothing.  There are many situations where this vague hint is sufficient information for a person to figure out what to do.

At the highest level, you find something like "diagnosticCode", with a specification that it is to be encoded as an HL7 CWE, with a value selected from the 2011 XYZ profile value set.  Now I have the semantic meaning, the format, the vocabulary, complete version information, and can perform extensive automatic processing.

It's important to separate the discussion of metadata, intended use, and degree of interoperabilty needed in early discussions defining metadata.  They are different concepts.

Another issue that is not mentioned in Dublin Core is the decision of how metadata is stored and conveyed.  This is an interface and exchange problem only.  Within any processing system you don't need agreement with others about how any data is stored or conveyed.  But metadata discussions do need to understand that when exchanging metadata there are three possible situations:

• The metadata may be embedded in the document, and not otherwise exposed.  This means that it is only accessible to systems and people that understand the document format.  An example of this could be "patient's mother" or "KVP setting".  These are metadata for some rather specialized uses in genomics and procedure analysis.  An indexing registry for medical records is unlikely to maintain these as a separately stored metadata index.
• The metadata might only be available as a separate item.  The hash value for a document is almost never stored as part of the document.  It's use is as a separate piece of metadata used by the privacy, security, and integrity systems.
• The metadata might be stored both as part of the document and as a separate item.  PatientID is often stored both ways.  When using patientID as part of finding and selecting documents, it is appropriate to have separate indices for many reasons.  But when processing those documents, it is necessary to have that patientID information in context within the document.  This does lead to some considerations about consistency rules when defining how the metadata is to be used, and that is normal.

 

Definitions matter (median income statistics)

Summary: definitions matter much more than I expected.

There have been lots of public opinions about the change in median income in the US, and what it means for policies.  It turns out that the definition of median income matters much more than I expected.

This table shows the increase in percentage from 1979 to 2007, for those who want the answer up front:

Income Included	Tax Unit	Household	Size Adjusted Tax Unit	Adjusted Household
pre tax, pre-transfer	3.2	12.5	14.5	20.6
pre tax, post-transfer	6.0	15.2	17.0	23.6
post tax, post-transfer	9.5	20.2	25.0	29.3
post both, plus health insurance	18.2	27.3	22.0	36.7

The widely reported figure is the 3.2.  This is used to argue that there has been no improvement.  All the gains have gone to the top 1%.  The middle class is being hollowed out.

The different definitions make for a more nuanced answer, and reflect difficulties in getting data.

The different terms are:

• Tax Unit is the tax filing unit.  This is what the IRS tax statistics report.
•  Household is what you would expect.  It's all the people in the house.  So everyone in the household is combined.  This captures the effects of grandparents, parents, and children all being potential earners and sharing income and expenses.  It also captures unmarried couples, shared custody, etc.  The IRS statistics don't capture this, but the monthly Census survey does.
• Size adjustment modifies the income using the same adjustment as is used for cost of living.   A family of four needs more income than a single person, but not four times more.
• The kinds of income reflect regular wages/dividends, transfer payments like social security or food stamps, and finally health insurance benefits.  These variations also reflect data gathering.  The IRS can measure some transfer income, like the EITC, but not other transfer income, like food stamps.  EITC and food stamps are two very large social welfare programs in the US.

A recent paper is interesting in that it works from the census bureau data rather than the tax data.  This lets it measure households, transfer payments, and health insurance.  The tax information can only measure tax units.  They compared their results with the tax data and confirmed that they matched when measuring the categories that the IRS can measure.

My Conclusions:

• There is no "right" number.  The proper issue is what is the question that you are trying to answer.  The shifts in households, with grandparents and adult children moving back together with parents may be a compensation for economic hard times.  These numbers show that it works and has more than compensated for income loss.  Health insurance costs have gone up dramatically, as these numbers show.  Transfer payments and a progressive tax rate do appear to have a significant effect.
• The "middle class is vanishing" is at best misleading. 

Paper is at http://www.nber.org/papers/w17164

There is some more data on trends in household sizes, etc.  There is also a breakdown of quintiles.  For the all included houehold category, the bottom quintile saw 26.4% growth and the top quintile saw 52.6% growth.  The top 5% saw 63% growth.  There is no data for the top 1% because privacy related data blinding was applied by the census bureau, and only larger aggregates are reported.

So you can argue that all parts of the population saw significant improvement, or that the rich saw a larger improvement, or that the middle class is suffering.  The data shows that the progressive tax rate (EITC included) does have an effect, transfer payments and the social programs do make a difference, and that healthcare benefits do make a difference.

 

Dell U2711 and getting full resolution

The documentation from Dell and others is utterly atrocious, so people like me write posts like this to help others with their setup.  First, although Dell never documents this, these are the limits for various kinds of input:

• DisplayPort can do the full 2560x2048
• DVI-I Dual Link can do the full 2560x2048
• VGA can only do up to 2048x1152.  (Interpolation makes text a bit fuzzy.)
• DVI Single Link can do up to 2048x1152
• HDMI I can't test properly.

Then there are the variations of support by various systems.  Vendors do not document their hardware well enough to know what will work without trying it.  I have found:

• MacBook Pro with MacOS, DVI-I Dual Link is supported at full resolution
• Intel D94GZIS with Windows 7, DVI-single link at 1600x1200, DVI-VGA Adapter at 2048x1152
• Intel DH67CL with Linux and Intel Driver 2011Q3, VGA adapter to DVI works at 2048x1152, DVI only up to 1600x1200
• Dell Latitude 630 in Docking Station: DisplayPort at full resolution

The documentation and connector for the DH67CL claim dual link capability but after various experiments I've found no way to configure the driver to use it properly.  Documentation of the Intel driver provides no information about dual link setup.  The default configuration did not set it up automatically. 

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.

Medical Market "failure"

I had to change my regular medications last week.  I delayed the conversation with the nurse while I did some checking of prices.  From both Costco and Walmart I could get a 3-month supply for $10, cash, no insurance.  The nurse commented "we don't price compare".  My response was "I do."  (It's actually quite unreasonable to expect them to help price compare.  Insurance plan complexities are different for every patient and finding a cost is hard.)  Since my co-pay is $25, the $10 is a good price.

I've been through this before, but just for my amusement I checked again:

• At both local chain pharmacies they will not quote a price.  Prices are secret.  All they will disclose is co-pay and only 1 month supply salable if insured.  They are not willing to sell on other terms, even for cash, because they know I have insurance.
• I didn't waste time with the PBM that used to nag me.  Last time they were not willing to quote a price.  All they would disclose was the copay, for a 3 month supply, delivered by mail sometime in a two week window.

The only way to find a price is to buy the drug and look at the receipt details.

I find the nonsense about healthcare demonstrating "market failure" to be highly annoying.  You can't call it a market when prices are kept secret from potential customers.  Price and quality comparison are fundamental to anything called a market.

The increasing penetration of Costco and Walmart may partially reflect customer intolerance for the mandated inconvenient delivery and secret pricing.  The cost conscious public clearly want a real marketplace with public prices.

Actual failure experience (re ATNA-Syslog)

This has to be somewhat vague for trade secret reasons, but during the mid-90's Polaroid gathered extensive data on network problems as part of a total system reliability tracking effort.  The systems were medical printing systems, and data was gathered for video capture units, print servers, and printers.  The networks were hospital networks, all with wired ethernet connections.  There were several hundred devices involved and measurements taken at a couple hundred hospitals over an extended period at these hospitals.  Some of the units were stationary, and some of the units were mobile.

The network traffic is noticably different from ATNA-Syslog, so these results would need some adjustment for that purpose.  The network traffic for printing was DICOM, "lpr", and "ftp" traffic.  The observations were made over a period of several years.  In excess of 10 million transactions were recorded.  Transactions were almost entirely print transactions, with a very few print status queries.  The observations were:

• Network problems were entirely insignificant.
  
  • Stationary systems reported no network problems.  TCP/IP handled whatever happened just fine.  (I should note that a down server or printer was not considered a network problem if this was detected before the print data was sent.  The sending systems would queue their prints and wait for the server  or printer to be restored to service. Down servers or printers were considered a different kind of reliability problem.)
  • Mobile systems detected network problems at about one per 250,000 transactions.  These were all the kind of failure that I described earlier.  The application acks did help identify problems.  At a problem rate of 4 ppm we decided it was reasonable to deal with these problems by just re-printing whenever a possible problem was observed.  Four extra prints per million is an insignificant problem and not worth extensive engineering work.

ATNA Syslog is a different network use pattern, and the motivation for directed attacks is different.   Hospital network characteristics may have changed since the 1990's, and this data is not a measurement of cross enterprise data traffic.  This data is relevant in characterizing the internal characteristics of the hospital environment, and can be taken into consideration when doing reliabiliity design, FMEA, and similar analysis for ATNA product design and installation design.