Cycling to Meetings - a Progress Report

The month of July is drawing to a close. Here's a report on my experiment to replace car travel with bike travel for a month.

What did I find?

*There is no place in the city of Boston that is faster to reach by car than bike. I average 15 miles per hour on bike and 10 miles per hour by car. A car on Fenway Red Sox days can be a painful 5 mph experience.

*My Harvard and CareGroup offices are 1.2 miles apart. I can go from desk to desk in 6 minutes, since my Strida folding bike travels in and out of the building with me. Car travel is between 15 and 30 minutes, depending on traffic.

*Parking in downtown Boston runs about $30 for the first hour. I saved more than the cost of the bike in one month of cycling.

* The streets of Boston are narrow, the potholes are deep, and the drivers are psychotic. I wore a helmet at all times, even for 1 mile rides between offices. The key to my success was to cycle in a predictable straight line, never darting in and out of traffic.

*Pedestrians and other bikes are even more hazardous than cars. I had numerous pedestrians (often walking into traffic while talking on their cell phones) nearly run into me.

*Rain can make cycling problematic. My Strida has fenders which protect me from tire spray, but wearing a suit while cycling in the rain can be tricky.

The bottomline - using a bike to commute in Boston saves me 30 minutes per day, saves gas, saves parking, and burns calories. If the rain stops, the pedestrians get off the phone, and the potholes are filled, life will be grand.

The experiment has been a success and I will continue to bike to all my meetings in Boston, April to November, weather permitting.

Next Steps for the HIT Standards Committee

At the July 21 meeting of the HIT Standards, we approved an initial set of standards for quality, clinical operations and security/privacy. We were told to refine these initial efforts by the next meeting of the Committee, August 20, so that ONC and CMS can incorporate the work into the interim final rule. Here's an update on the deliberations of the workgroups.

Privacy and Security
We received several public comments about our selected privacy and security standards - those used for authentication, authorization, auditing, encryption, and secure transmission. It's important to note that the sending and receiving of transactions for healthcare information exchange is part of the scope of the Privacy and Security Workgroup. Clinical Operations specifies the vocabulary/codesets/value sets and the actual message or document to send. Privacy and Security ensures it is sent in a secure fashion, consistent with HIPAA and ARRA. Our recent decisions in response to comments are

*Although the IHE ATNA profile for securing transmission via TLS allows use of Null Cipher (i.e. no encryption) as an option for private networks, we will require all health information exchange transactions between organizations, even those running on private networks to be encrypted via the AES_SHA cipher by 2011.

*SOAP is an approach to data exchange that enables programmers to use the web to call remote servers using the HTTP POST syntax. POST means the URL does not contain any specific information i.e.

I use POST to talk to a server at http://mymedicalrecords.com and request information about my medical record number and the kind of information I want to retrieve using hidden exchanges between the servers, not by embedding the details of my request in the URL.

SOAP has a learning curve and generally requires a toolkit to make the implementation easier. It has been a favored approach in healthcare because it has many standardized security tools.

*REST is an approach to data exchange the enables programmers to use the web to call remote servers using the HTTP GET syntax. It's easy to use without a toolkit. For example, you could use a browser to call a URL like the following to retrieve your allergies

http://mymedicalrecords.com?myMRN=1234567&show=allergies

Although it's simple, there are fewer standardized security tools. REST is increasingly popular and Amazon, Google, and most e-commerce companies have embraced REST, creating their own unique security tools.

*The Security and Privacy Workgroup recognizes that both approaches, SOAP and REST, should be allowable for data exchange. Here's a list of the HITSP Capabilities and Services supporting these transactions

TP13 - Manage Sharing of Documents (XDS.a), SOAP and REST
TP13 - Manage Sharing of Documents (XDS.b), SOAP
TP13 - Cross-Community Access (XCA), SOAP
TP21 - Query for Existing Data, SOAP
T31 - Document Reliable Interchange, SOAP
T42 - Medication Dispensing Status, SOAP
TP49 Sharing Radiology Results, SOAP and REST
TP50 - Retrieve Form for Data Capture, REST
T63 - Emergency Message Distribution Element, SOAP
T66 - Terminology Service, SOAP and REST
T81 - Retrieval of Medical Knowledge, REST
T85 - Administrative Transport to Health Plan, SOAP
TP89 - Sharing Imaging Results, SOAP and REST

For a more detailed discussion of the pros/cons of SOAP and REST, see my blog entry on the topic.

Clinical Quality
Leveraging the completed HITEP report, the Clinical Quality Workgroup has proposed 27 initial quality measures and the data types required to capture each electronically. The challenge is that several quality measures contain exclusionary criteria i.e. when considering HbA1c levels, remove patients on comfort care measures from the denominator. When considering tobacco cessation counseling, remove patients who really like smoking and lack readiness to quit from the denominator. Such exclusionary criteria are really challenging to support with existing EHRs. It is likely that either these exclusions will have to be removed from the measures until EHRs and standards support them, or that self attestation of quality measures rather than electronic measurement be done in the short term until EHRs can capture these more esoteric data elements. The Clinical Quality workgroup is examining every data type for its readiness/adoption and will then make final recommendations on the quality measures and data types to use in 2011.

Clinical Operations
We're refining the matrix of vocabulary, messaging and document standards to respond to comments from HIT Standards Committee members and the public. We've heard such things as

*Allow HL7 2.51 messaging as well as XML-based document formats for transmission of data in HIEs, at least for the next several years

*Although care coordination and patient experience data exchanges may benefit from unstructured documents such as a PDF exchanged electronically along with metadata, quality measurement really requires codified data, even if it is just ICD9. SNOMED-CT is the preferred vocabulary for clinical observations and eventually should be used for all quality measures, but it will take several years for SNOMED-CT to be fully implemented in healthcare information exchanges, so ICD9 and ICD10 will be allowed along the way

*The HIT Standards Committee focuses on healthcare information exchange - from the edge of one organization to another organization. All the vocabularies we are discussing - LOINC, RxNorm, SNOMED-CT and UNII (for allergies) are for exchange, not necessarily required within internal systems of organizations. This is the realistic approach that is needed to give organizations the time they need to implement controlled vocabularies for data exchange.

We'll continue our work for the next two weeks and then present it publicly on August 20. Thanks to all the Committee, Workgroup, and HITSP volunteers who have spent many hours on this effort.

The Making of the Third Generation Prius Ad

It's Summer, so time for some lighter fare (don't worry, more news from Washington is coming later this week.)

I'm a Prius driver and will likely be replacing our older Toyota Highlander with another Prius, which will be my wife's and my daughter's car.

The Third Generation Prius advertisement features a unique combination of people, amazing graphics, and digital assembly - over 1,000,000 people were created from 200 extras.

Here's a You Tube Video that explains how the entire commerical was created. Incredible.

A Glossary of the Data Center

I'm serving as a subject matter expert for a panel studying the IT capabilities of the Food and Drug Administration. In preparing our report, the team recognized that many FDA stakeholders are not well versed in the terms used to describe data centers. Here's the glossary that the team developmented, which I thought you might find useful for your own reports and presentations.

Classification of Data Centers (Tier 1 – 4). The Telecommunication Industry Association (TIA) has published the TIA-942 standard for classification of data center capabilities.

Tier 1 – Basic: 99.671% Availability
Susceptible to disruptions from both planned and unplanned activity
Single path for power and cooling distribution, no redundant components (N)
May or may not have a raised floor, UPS, or generator
Takes 3 months to implement
Annual downtime of 28.8 hours
Must be shut down completely for perform preventive maintenance

Tier 2 – Redundant Components: 99.741% Availability
Less susceptible to disruption from both planned and unplanned activity
Single path for power and cooling direction, includes redundant components (N+1)
Includes raised floor, UPS, generator
Takes 3 to 6 months to implement
Annual downtime of 22.0 hours
Maintenance of power path and other parts of the infrastructure require a processing shutdown

Tier 3 – Concurrently Maintainable: 99.982% Availability
Enables planned activity without disrupting computer hardware operation, but unplanned events will still cause disruption
Multiple power and cooling distribution paths but with only one path active, includes redundant components (N+1)
Takes 15 to 20 months to implement
Annual downtime of 1.6 hours
Includes raised floor sufficient capacity and distribution to carry load on one path while performing maintenance on the other.

Tier 4 – Fault Tolerant: 99.995% Availability
Planned activity does not disrupt critical load and data center can sustain at least one worst-case unplanned event with no critical load impact
Multiple active power and cooling distribution paths, includes redundant components (2 (N+1), i.e. 2 UPS each with N+1 redundancy)
Takes 15 to 20 months to implement
Annual downtime of 0.4 hours


Cloud Computing (and Storage). Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.

NAS (Network Attached Storage). The Network Attached Storage is file-level computer data storage connected to a computer network providing data access to heterogeneous network clients.

Reference Architecture. The reference architecture provides a proven template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality.

Reference Architecture can be defined as different levels of abstraction. A highly abstract one might show different pieces of equipment on a communications network, each providing different functions. A lower level one might demonstrate the interactions of procedures (or methods) within a computer program defined to perform a very specific task.

SAN (Storage Area Network). The Storage Area Network (SAN) is an architecture to attach remote computer storage devices (such as disk arrays, tape libraries, and optical jukeboxes) to servers in such a way that the devices appear as locally attached to the operating system. Although the cost and complexity of SANs are dropping, they are uncommon outside larger enterprises. Network attached storage (NAS), in contrast to SAN, uses file-based protocols where it is clear that the storage is remote, and computers request a portion of an abstract file rather than a disk block.

Virtualization (Server Virtualization). Virtualization is a method of partitioning a physical server computer into multiple servers such that each has the appearance and capabilities of running on its own dedicated machine. Each virtual server can run its own full-fledged operating system, and each server can be independently rebooted. (Best practice for reducing cost and increasing performance in large enterprises).

Documents and Messages, a Guest Blog

Yesterday on a call of the HIT Standards Committee Privacy and Security Workgroup, we had a great discussion about Common Data Transport and Health Information Exchange. This is a guest blog describing that conversation by David McCallie at Cerner, a member of the Committee.

"These are some principles that we try to follow in our work.

*Be aware of the difference between a document and a message

*A document should ideally contain data that is assembled to represent a specific clinical context – the data in the document should cohere in some meaningful way. For example, a document (e.g., a CCD) could represent a summary of an encounter, or a response to a query for a current_medication_profile, or you could have a CDA representing a radiology report with structured findings, etc.

*A message communicates some kind of discrete change in state, and is capable of standing in isolation from other messages. For example, a reference lab sends a test result back to the ordering physician via messages. Messages should have sufficient metadata to allow for idempotency (timestamps to avoid duplicate data errors on replay) and to allow for transactional updates to the discrete content of the message (externally-valid identifiers that can be used to send corrections or amendments, etc.) Documents do not need to contain idempotency or transactional information about the discrete structures contained within. The arrival of a document does not imply that all of the contained structures have been updated, whereas the arrival of a discrete message usually does indicate a change in state of the discrete.

*Of course, a message could be used to send a document, in which case the message will have metadata about the overall document (though that does not imply that the metadata is relevant to each discrete element within the document.)

*However, in general, a document should not be used to send a message. For example, a document (like a CCD) should not be used to update discrete information such as specific problems in an external problem list. If a provider chooses to (manually) extract discrete data from the document into his EMR, he should be aware of the context of the overall document to determine the validity of making the extraction. (He may reject the extraction because he is already aware of the discrete information, or his EMR already contains more accurate or more refined knowledge than what is contained in the document.)

*Discrete information should not be automatically extracted from a structured document (except under carefully controlled circumstances.)

*It is tempting to consider a structured document to be the same thing as a structured message, but the semantics are different and trouble will follow

*An HIE that allows only for document submission will be unable to accommodate capture of messages (unless some of the above principles are violated.)

*Yet messages are far more common in HIT transactions today than are documents (labs, claims, eRx, etc.)

Ideally, an HIE should be able to utilize both documents and messages to capture and share patient clinical state."

I thought that these ideas were important to share with the Health Information Exchange and Standards stakeholders who read my blog.

The SNOMED-CT Problem List has arrived

As promised in my earlier blog, the National Library of Medicine has created a "best practices" subset of SNOMED-CT which is highly usable by clinicians for documenting the symptoms and conditions used on a typical Problem List.

I've discussed previously the hazards of using ICD-9 as problem list vocabulary. It's an administrative billing vocabulary, not a clinical observation vocabulary.

You need a free SNOMED license (if you're in one of the countries that has licensed SNOMED, such as the US) to retrieve the SNOMED Problem List document.

The present subset is based on datasets submitted by 7 institutions - Beth Israel Deaconess Medical Center, Intermountain Healthcare, Kaiser Permanente, Mayo Clinic, Nebraska University Medical Center, Regenstrief Institute and Hong Kong Hospital Authority.

We're implementing this problem list vocabulary in our home grown systems first, then we'll work with eClinicalWorks to incorporate it into their EHR. We'll test it extensively with a few clinicians and then roll it out broadly if we achieve a good balance of functionality and clinician satisfaction.

The HIT Standards Committee will likely recommend SNOMED-CT as the preferred problem list vocabulary, so this release by the NLM is very important to all EHR stakeholders.

BIDMC's Red Flags Policy

I recently wrote about the FTC's Red Flags Rule that must be implemented by August 1, 2009.

Here are the completed BIDMC Policies needed to support this rule. Feel free to use them as inspiration for your own policies.

Red Flags Policy

PV-01 Designation of Organized Health care arrangement

PV-11 Designation of Privacy Officer

PV-14 Mitigating the Effect of an Unauthorized Use or Disclosure of Protected Health Information

PV-17 Business Associate Agreements

PV-19 Opt Out

PV-20 Authentication Policy

Appendix