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.

 

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.)

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.

Should Syslog use application acks?

This started as an ATNA-Syslog question, that I will consider in the context of some DICOM history. 

Should Syslog have an appliction ack to deal with some known vulnerabilities?  I call them vulnerabilities because they are extremely unlikely except when combined with intentional external actions.  These vulnerabilities become apparent with mobile equipment and with skilled attackers.

DICOM has used application ack since it's introduction.  But, this was for application reasons, not to deal with vulnerabilities in the underlying TCP and TLS services.

• In C-MOVE there is a C-MOVE-REQ that says "please accept object X".  The corresponding C-MOVE-RSP says either "yes, got it" or "no, this is why not."  Most often the no is because the responder is out of storage space, but it can also be due other problems.

• In C-FIND the pair is more complex.  C-FIND-REQ says "please provide information on objects that match these criteria".  The C-FIND-RSP normally conveys the information requested.  It can also deal with "and there is more to come later" or "this is everything".  The "no, this is why not" deals with invalid requests and other problems.

The use of application ack to deal with network problems as part of failure management was a side effect.  These are just another kind of failure to be reported.  The state machine for the application layer has to deal with network failures as part of completeness, not as a reason for application ack.

DICOM also tolerates a certain level of indeterminacy.  The designers basically said "close enough", much like the designers of CRC and FEC codes.  These cover most of the possible errors, and accept that a few will sneak through and be dealt with elsewhere.

The "elsewhere" in DICOM leads back towards the isues with Syslog and ATNA.  DICOM makes transactions idempotent to the maximum extent possible.

The C-MOV transaction is idempotent.  These is no end state difference between "C-MOV object X" once and "C-MOV object X" one hundred times.  The only difference is the time it takes.  So when in doubt or uncertain, DICOM applications just do it again.  The second time probably reaches a determined state.  Similarly the C-FIND is idempotent.  A look at operational DICOM logs shows well over 99.9% of the transactions performed are idempotent.

There are some necessary exceptions, like "print".  Sending "print" once is different from sending "print" a hundred times.  You get a lot more copies printed.  DICOM tries to take the non-idempotent applications and split them into an idempotent part and non-idempotent part.  DICOM puts as much of the application into the idempotent part as it can.  In the case of "print", everything except the N-ACTION-PRINT is idempotent.  This minimizes the window of vulnerability.  DICOM then took the attitude, "close enough, maybe there is the occasional duplicate print when something goes wrong.  We'll accept that.  It won't happen often enough to be a problem."
    
Syslog and ATNA have the issue that:

• There is no application level ack, and

• There is a delivery uncertainty in the face of some kinds of errors that occur with mobile devices and skilled attackers.

Can idempotency deal with this?  It can if syslog messages are designed properly.  This would allow a gradual transition to reliability without requiring changes to the underlying syslog protocols.  The application change would be to send extras when uncertain about delivery.  This is probably also a much smaller network impact also.  There is extra traffic only in those error situations, not during normal traffic.

This takes messages that are universally unique over all time and sources, and that are idempotent.  The idempotency allows sending duplicates.  Duplicates can be recognized and discarded by recipients.  (This also simplifies some of the multiple database and dispersed database issues for log processing.)

Unique IDs deal with uniqueness.  DICOM uses unique IDs for all sorts of things.  The hardest problem with unique IDs is persuading all the hot shot programmers that they really should read the recommendations on best practices for creating unique IDs. The home grown unique ID algorithms all seem to fall into one or another of the well known traps that result in non-unique ID generation.

If the lead-in to every syslog message body includes that unique ID for that message, you may be done.  The rest is ensuring that the generating application doesn't generate multiple messages for the same event.  That's bad design in any case.  You also want to avoid non-idempotent content.  This should be easy for ATNA and syslog.  The message is describing an event.  It shouldn't be that hard to make these messages idempotent.

The one idempotency trap that I've seen with log messages is the use of incremental messages.  These need sequence integrity.  The idempotence of meaning is lost if the messages are processed in the wrong order.  Time tags and other tools can be used to preserve sequence integrity despite repeats and out of order arrival.  But it helps a lot if the syslog messages are designed to be a self-contained complete description of the event of interest.

How well did RFC-3881 and DICOM do when defining audit messages?  So-so.  The event identification mandates identifying a source, date-time, etc.  It does not require that these be message unique. The messages are fully self-contained.  What they need is a unique ID.

I also checked the MITRE CEE effort.  They don't mandate idempotent messages either.

So, should I propose a change to add an optional unique ID?  Something to think about.

Standards and drug costs

In honor of Dr. Meier's recent death, a comment on how standards choices affect drug costs.  Dr. Mieir was the major advocate for the use of randomized trials.  Standards can reduce the costs of these trials when used properly.  Some of the results are counterintuitive, but that's common when using statistics.

The major cost of developing a new drug is the Stage III trials.  These involve many patients as trial subjects, plus all the associated costs.  These costs are huge.  The two major approaches used to reduce these costs are:

1. better early screening to reject candidates.  This reduces the number of Stage III failures.
2. reduce the cost of individual trials.  Standards can help directly with this.

The primary cost driver for the Stage III trial is the number of subjects needed.  This number results from using randomized trials to remove the effects of variance.  This variance is composed of:

1. Subject variance, the inherent variability of the disease and patients.  There is little that can or should be done to reduce this.
2. Observer variance, the variability of the observation methods, calibration, recording accuracy, etc.  In an ideal world this would be zero, and standards tackle this problem.

The techniques covered by standards include:

1. recording all the relevant details about observation methods.  DICOM enables capturing the important observational parameters.  It defines the terminology, measurement units, etc.  As observational equipment evolves and is better understood, DICOM extends these definitions.
2. recording calibration information and making it available for subsequent use.  This was a low hanging fruit for DICOM, requiring only a minor clarification and extension to the patient identification module to incorporate calibration phantom information.  See CP-613 and CP-764 (http://www.dclunie.com/dicom-status/status.html#CorrectionProposalsByNumber) This enables subsequent trial specific calibrations for the patient results.
3. recording and providing measurement methods.  There is significant variance that results from differences in setup, patient preparation, etc.  This often involves machine specific information for individual model types.  DICOM is working on methods to capture this and communicate it.  See Supplement 121 (http://www.dclunie.com/dicom-status/status.html) The hope is that this will enable all of the sites involved with a particular clinical trial to use the same measurement methods, and reduce variance this way.
4. definition and distribution of standard codes and terminology.  Clear definitions of measurement meaning reduce variation between observers when reporting.  IHE has contributed a Shared Value Set (SVS) facility so that it is easy to distribute these terms and their definitions to all the staff and other participants.  Other standards efforts like SNOMED and RADLEX try to define universally useful clinical terminologies.

I emphasize variance reduction because that is where there are potentially huge savings.  The number of patients needed in a trial is proportional to the square of the variance.  If we can cut variance in half, it would cut the cost of Stage III by as much as 75%.  More realistic goal is a 10% reduction in variance that generates a 20% reduction in Stage III costs.  That would be a multi-billion dollar per year savings.  There is much naive discussion about using the network to find more subjects.  This does help, but in almost all cases the real cost driver is the large number of subjects participating in the trial.

Now for the statistical subtlety.  One potentially large source of variance is changing methods or terminology in the middle of a study.  So healthcare faces an ethical dilema.  Changing methods and terminology is needed to make improvements in care, but interferes with ongoing clinical trials.  Making a change should involve the patient and the clinical trials organization as well as the healthcare provider.  The clinical trials organization needs to inform the decision makers about the impact that this change will have.  How much does it affect the trial?  The patient and provider need to assess what the effect of the change will be on the patient's prognosis and goals.

An example of a change is a new patient prep procedure that reduces CT prep time by 5 minutes.  For any patient not involved in a trial involving CT, the answer is obvious.  They should get the change.

But for a patient in a trial using CT data you need to consider whether this change will affect the trial.  If this will increase trial variance by 1%, it may increase the trial costs by 2%, reduce trial quality, or delay trial results.  The patient may well prefer to take the extra 5 minutes rather than interfere with the trial.

To make this work you need:

• a system in place to keep track of which patients are in trials, and what procedures are affected by these trials.
• a system to provide trial specific information for everyone conducting those procedures
• a system of people who are prepared for the operational variety that this creates.  It's like conservation of mass.  The variations have been removed from the clinical trial and put into the day to day operation of the healthcare provider.

The IHE SVS profile helps by enabling the use of date, version, and trial tags to identify value sets that support particular trials.  DICOM Supplement 121 helps by easing distribution and implementation of consistent imaging protocols.  These are a small part of the overall effort, but the bulk of the systems described above are internal to each healthcare provider.

Internet trust lecture

Summary: A lecture by Miriam Meckel reminded me of the importance of reciprocity in healthcare relationships.

The lecture by Miriam Meckel presented results of a study on building trust on internet.  They picked ten realistic things that are part of establishing trust.  Then they examined surveys over 1 year for a variety of B2B and consumer organizations.  These were studied for primacy component analysis to see what drives trust the most.

Biggest factor is "reciprocity".  This is the agreement by both sides that their expected actions make sense and are appropriate for the nature of the relationship.  A very simple example is that customers expect to pay for goods delivered.  This reciprocity is a factor independent of contract or other terms.  It applies to later discoveries, undisclosed activity, etc. 

Reciprocity was 1/3 of the determination of trust.

Also noted was the penalty for violating reciprocity expectations.  A slimey crook who presents as a crook is not trusted to begin with.  A trusted relationship that then has a reciprocity failure is treated as a major betrayal.  The betrayer becomes much worse than an untrusted crook.  They are an enemy to society.

Three factors are responsible for the next 1/3 of establishing trust:

• Technical reliability.  This means all aspects of the relationship work smoothly and without problems.  It's much more than just web site stabiltiy.
• Customer control.  The more that the customer determines the relationship and activities, the greater the trust.
• 3rd party recommendations.

So, with four reasonably well defined areas you get 2/3 of the trust establishment, and reciprocity is the dominating factor. 

This has some relevance to healthcare and its security.  The trust relationship is important to most aspects of healthcare. 

One result is that the risk assessment priorities for security analysis need reconsideration.  It's true that inappropriate disclosure is a risk. I would consider that a technical reliability problem. But, reciprocity, patient control, and 3rd party recommendations are also assets to be protected. 

This also points to a flaw in an argument that I hear often regarding data losses.  The many disclosures due to stolen laptops are discounted because the data is rarely actually disclosed.  In practice the laptop is wiped, because the thief stole it for resale.  Wiped laptops are easier to sell.  That's an argument dealing with the 10% factor of technical reliability failure.  This argument ignores the reciprocity failure, and leaves the vendor open to enemy of society treatment.  That's a big loss of an important asset.

The solution to the reciprocity failure is some mix of

• have the customer accept that the loss is reasonable.  This is the rather unpopular "there is no privacy any more" argument.
• make sure the customer knows that you cannot be trusted with their data.  This downgrades you from enemy of society to merely not trustworthy.
• don't lose data on laptops

We need to add the assets of reciprocity, reliability, customer control, and 3rd party assessment to the risk analysis mix.  It's more than loss of data and data disclosure.

I've seen two other related problems in healthcare.

1.  "Consent"s, which are important but generally bungled.  Reciprocity does not mean that you told me something would happen.  Reciprocity means that when I later learn about it I agree that it was appropriate.  Consent is only part of reciprocity to the extent that it ensures that the customer understands the other side and knows who not to trust. 
2. The "patient control" implementations that I've seen have generally asked the patient to do the impossible.  The patient is expected to make an agreement while under extreme stress, inadequately informed, and with no time to get proper advice or more information.  Then the agreement is used to rationalize all kinds of reciprocity failures.  They would do better to deal with the reciprocity failures in most cases, and concentrate patient control on situations where the patient is not under stress, has adequate information, and the time to make an informed decision (including getting 3rd party advice).

Medicine and Aviation

     Summary: Both healthcare and aviation are system engineering problems.  Healthcare does have things to learn from aviation, some simple and some very hard.  One of the simple things is crew resource management techniques.  The extremely hard is transitioning from a vengeance based quality system to a modern quality system.

 There are three very different kinds of engineering problems:

• Complex part engineering problems, like mechanical design engineering:  In this kind of problem there are a small number of different interacting parts, and each part is extraordinarily complex.  A single camera housing part may reflect hundreds of man years of engineering, with stress analysis, temperature flow profiles, manufacturing plastic fluid flow simulations, etc.
• Huge number engineering problems, like financial software:  In this kind of problem there is an extraordinarly huge number of interacting parts, but each part is fairly simple.  Financial software and web commerce applications routinely deal with millions of transactions every hour.  The rules for any one individual transaction are fairly simple.
• System engineering problems, like aerospace and medicine:  In this kind of problem there are a large number of interacting parts and each part is complex.

It's unfortunate that many people see the recent successes solving huge number engineering problems and think that these huge number approaches will solve a system engineering problem. 

Aerospace engineering and aviation problems are 99% hidden from the traveling public.  Being a major traveler does not mean you understand aviation engineering.  I was on the system engineering teams for several satellites and radars.  This gives a different perspective.  There are things that medicine can learn from avaiation.

One simple but difficult step that will have very large benefit is introducing the medical equivalent of crew resource management.  There are some providers making progress here, but right now it's tiny little islands of effective management in a huge sea of mismanagement.

In the 1950's and 60's aviation was similar to medicine.  In aviation the pilot was god, just as in medicine the doctor is god.  Investigations of accidents showed that this was leading to major accidents and significant loss of life.  Pilots were ignoring important information and making mistakes of judgement.  There was serious human factors and psychological research into changing this.  Simulations and practices  from other industries were studied.  Airlines forced a change in pilot and crew behaviors through training, explanation, practice, and supervision. 

The first really big public success for crew resource management was the Sioux City DC-10 crash.  After a mechanical failure that should have been unsurvivable and caused 296 deaths, an amazing ad-hoc crew managed a crash landing with only 111 deaths.

I've once seen a doctor listen respectfully to the advice from a transport orderly, take the advice, change patient treatment, and thank the orderly.  Once, at one hospital.  Most of medicine is still struggling with maintaining civil relationships between nurses and doctors.  Only a few hospitals have reached the point where doctors will tolerate and participate on a working committee that is chaired by a grounds keeper.

Medicine and aviation are at a similar maturity level for equipment.  My experience with making products for the aviation industry prepared me for medical equipment.  The two are similar.  Medicine can learn from aviation in this area, but it is a learning between equals.  Both aviation and medicine have mature modern quality systems for their equipment.  Each can learn some things from the other.

The really hard problem is switching the industry from a vengeance based quality system to a modern quality system.  The vengeance based systems go back into pre-history.  They also work.  Rome grew to a major civilization that lasted for centuries with the simple vengeance quality system:

If the slave does low quality work, torture them.

It's sad that this works.

Modern quality systems date to Demming and Juran.  They are presently entering medical practice under names like the Toyota Production System.  The details evolve, but one principle is abandoning the vengeance based quality system.

One example of the difference between aviation and medicine is that there is an NTSB that examines all aviation accidents involving fatalities or major losses.  The accidents are impartially investigated, causes analyzed, and mitigations evaluated.  These reports provide input to other organizations.  These provided a sound basis for things like the investment in crew resource management.  There are islands of vengeance, but the sea is a modern quality system.

In contrast, public evaluation of medical errors is deeply feared and avoided because of fears of malpractice, retaliation, loss of status, and other harms.  This fear is well justified.  Any doctor who has been through a malpractice suit will agree that it is a form of torture.  Similarly, when the government decided that something needed to be done about "never" events, there was no investigation of causes or evaluation of mitigations.  There were threats by medicare and payment retaliation for failures.  A medicare audit is another form of torture.  There is a sea of vengeance based quality systems.  You only find occasional small islands of modern quality systems.

The change from vengeance based to modern quality system is needed before large improvements can be made in patient safety.  Other industries have made this transition.  It has happened in aviation, electronics, and manufacturing. 

Ownership and copyright

This weekend's work finds yet another oddball use for "own".  In the world of BPEL and BPMN the "owner" of a task is the person who is currently working on it.  Another way to spread confusion.

John asked about an "XML schema" for privacy.   There are two answers to this.

1. I think a consent structure similar to the Creative Commons copyright licenses is feasible.
2. A general XML encoding for privacy, consent, or copyright remains a matter for research and exploration.  The translation of law and decisions into a structured form has been a matter of legal research since the mid 1970's or earlier.  It's still research.  There is also ongoing research into forms of license and contract.  None of these are ready for routine use.

A bit of history

While I think that common consents are feasible, it will take a lot of time.  The history of work that led up to the the Creative Commons licenses shows how much time it can take:

• 1974 - The CONTN commission recommends that copyright law be extended to software.
• 1980 - Copyright is extended to include software
• 1988 - The Emacs General Public License is written.  This is the first effort to formalize a publicly usable license.  It is a reaction to the serious problems resulting from inadequacy of the Gosling license for early emacs work.
• 1991 - GPLv2 issued.  This became a major influence on copyright and public domain thinking.
• 2002 - The Creative Commons is established.  The needs for open culture, open publications, etc. are not met by the GPL and similar variants.
• 2009 - The Creative Commons licenses reach version 3.0 (the current version).

Creative Commons is now to the point where there are about a dozen standard copyright licenses.  For a very large number of people it meets their needs.  You answer a few questions and get a recommended license.  You also get an HTML code snippet that identifies the license, and provides links for further information, attribution, etc.

This has reached the same level of ease of use as the typical publisher's copyright assignment forms, with substantially better commonality.  Every publisher, etc. has their own standard assignment forms,  with their own terms, etc.  They all have lawyers who customize things to maximum advantage of the publisher.  Common Criteria took the perspective of the authors, and after a few years experience with actual author preferences, has a set of common licenses for the open culture authors.

A Creative Commons for Consents

There have been occasional discussions of whether privacy rules could be managed like copyright.  Zittrain has written on this, and there was a recent seminar on the topic at the Berkman Center.  These make clear that the larger issue of privacy remains extremely complex.  But in a much narrower domain like patient privacy consents, there is a better chance for success.

I can see a situation where a group defines a set of patient oriented consents.  These consents would differ from much of what I've seen in current work by being patient perspective rather than provider perspective.  Rules like the HIPAA rule are impenetrable to the typical patient.  They deal with the many issues that are visible to the provider, rather than the issues that are visible to the typical patient.

I expect that getting this right will probably take a decade, given that it took two decades for the copyright licenses to evolve a public oriented set.  We can learn much from that effort, but one of the things that you learn is that real experience was crucial to the evolution of these licenses.  Real experience takes time.