Cool Technology of the Week

Thanks to Wes Rishel for this suggestion.

I'm a vegan, so I find this product questionable, but it does illustrate an interesting technology - using the genome to create customized products.

RayFish will genetically engineer a stingray to express colors and patterns of your own design and will then create a shoes from stingray leather.

Not just build to order but breed to order. The 10 month lead time may limit the market size.

Per Wes:

"I wonder if they can be genetically bred to include logos in the hide? You should be able to get a GREAT discount for volume!

If this is true and the genetic engineering can be automated what else could we breed to order? The ultimate dinner party, serving fish bred with a unique flavor just for one single meal? Takes a year to prepare dinner, but your friends will be impressed.

Tell your daughter she needs to plan her wedding a year in advance so the entrée can be bred to order. Perhaps the cycle time for breeding vegan entrée ingredients is shorter?"

It's a brave new world when our supply chain includes breeding products to order.

Morally objectionable, but fascinating nonetheless.

The Patient Safety Organization Common Format

In a recent call with the HIT Policy Committee, I was asked to comment on the suggestion that EHRs include the technology necessary to submit reports to patient safety organizations about defects in the EHR or safety issues caused by the use of the software.

I commented that the standards to do this are still emerging.

You may not be familiar with the AHRQ and NQF efforts to standardize reporting to Patient Safety Organizations.

AHRQ recently released version 1.2 of the "Common Format"  .

Its objective is well described in the implementation guide:

"The Common Formats published by the Agency for Healthcare Research and Quality (AHRQ) of the U.S. Department of Health & Human Services were created as part of the Patient Safety and Quality Improvement Act of 2005 (Patient Safety Act). AHRQ has coordinated the development of the Common Formats to facilitate the voluntary collection of patient safety event information. The Common Formats are available on the PPC Web Site (https://psoppc.org). For more information on the Common Formats, refer to the Common Formats Users Guide available on the PPC Web Site (https://psoppc.org).

The Common Formats are intended to be used to gather information on a patient safety event in order to create a Common Formats Patient Safety Report (hereinafter referenced to as “report”). Reports may be submitted to the PPC for data nonidentification and transmission to the Network of Patient Safety Databases (NPSD)."

The Common Format is a CDA document customized to include 3 report types

*Incident: A patient safety event that reached the patient, whether or not the patient was harmed.
*Near Miss: A patient safety event that did not reach the patient.
*Unsafe Condition: Any circumstance that increases the probability of a patient safety event.

Each of these types includes an issue category for Device or Medical/Surgical Supply, including Health Information Technology (HIT).

The challenge is that the data elements required do not map to the information commonly available in EHRs today.

Although software vendors supporting Patient Safety Organizations have implemented the Common Format, no EHR vendors have yet included it.

At Harvard, we're working to map our own local codes, supporting our patient safety organization, to the Common Format, so that we have interoperable incident reporting among all our hospitals.

Thus, the PSO Common Format is emerging - low maturity, low adoption, but deserves watching.   I think it unlikely that PSO reporting will be included in the 2014 Meaningful Use final rule, but it's clear that PSO report is on the list of desirable future goals.

The Canadian eHealth Conference

On May 28, I keynoted the Canadian eHealth 2012 Conference, focusing on the need to innovate in the areas of EHR usability, frictionless health information exchange, novel analytics, patient/family engagement, and privacy protection.

Here's the presentation I used.

I talked to dozens of people during my 24 hours in Vancouver and I believe there are 5 areas that Canadians should address to enhance their national healthcare IT program.

1.  Enable innovation via grant programs, competitive challenges, and high risk/high reward projects for emerging technologies, recognizing that traditional procurement approaches can inhibit innovation.  Procurement generally includes complex legal boilerplate plus certification that the technology is already running in referenceable customer sites.   No  innovative startup is going to agree to these terms and conditions.  Customer references for new technologies are likely to be scant because it is evolving so fast.   Traditional procurement approaches are likely to acquire technology at the end of its lifecycle.

2.  Prioritize Patient and Family engagement - to date, much of the Canadian healthcare IT program has focused on acute care hospitals.  Although some patient portals have been created, there is no national priority to engage patient and families.   Given the importance of shared decision making, keeping the patient informed, and transparency, encouraging interoperability with patients is key.

3.  Consider a Meaningful use type program even thought it may be politically unpopular among clinicians.  Canada has encouraged clinicians to acquire technology and has set interoperability standards nationally.  However, it has not specified the best practices for using the technology or held clinicians accountable for their  IT behaviors.  There is a fear that pushing the clinicians too far too fast will result in their leaving Canada to practice elsewhere.

4.  Clarify the strategy for healthcare IT at a national level.  Canada Health Infoway has done a remarkable job with standards and defining infrastructure for data exchange, but healthcare IT implementation is done on the provincial level.   It's not clear that the Canadian Prime Minister thinks about healthcare IT or has set priorities that must be followed by all provinces.

5.  Standardize outpatient/ambulatory EHRs with the same vigor that Canada has used for acute care settings.  Canada has many advantages over the US to accomplish the interconnection of ambulatory records - 30 million people (1/10 of the US), a publicly funded universal healthcare system, and a provincial level healthcare identifier.  It does have a challenge ensuring the connectivity of all providers across its diverse and sometimes remote geography.   Creating a certification program for ambulatory EHRs and ensuring they adhere to functional capabilities and interoperability standards will enable data sharing for care coordination and population health.

The Canadians are a warm, enthusiastic, and thoughtful people.   I look forward to continued collaboration and learning from each other as we implement new healthcare information technologies.

The May HIT Standards Committee Meeting

The May HIT Standards Committee focused on the ONC Governance RFI and how best to think about standards and policy for building trust among healthcare information exchange network participants

We also reviewed the Query Health project, Quality measurement project efforts, and the continuing work to create a national library of medicine curated vocabulary/code set repository in support for meaningful use.

The meeting began with a description by Farzad  that our work on the Governance RFI should result in "interoperability that just works".    Instead of plug and pray, it should be plug and play.   No one should have to negotiate trading partner agreements one by one.

Jon Perlin outlined the work recently done by the National Cancer Institute to envision a learning healthcare system based on information exchange and decision support.  It is no longer a dream, but is becoming a reality.

Steve Posnack from ONC presented the Governance RFI which is summarized on this blog post.

The discussion that followed was very robust with two major recommendations

a.  Policy should be "modular"  - the requirements to be a Network Validated Entity should vary based on the services offered.  It's quite different to be a repository of deidentified data verses a full Nationwide Health Information Network participant supporting a "pull" model for records based on a master patient index/record locator service.

b.  Policy should be separated from standards/certification, since policy may change at a slower rate than technology.  The current Meaningful Use Program separates attestation and certification, and such an approach seems prudent.

Dixie Baker presented an analysis on the RFI from the NwHIN Power Team and the Privacy & Security Workgroup .  Her comments provided many valuable refinements to the RFI and further bolster the case for separating policy and standards/certification details when defining criteria for trusted healthcare data exchange

Richard Elmore presented an overview of the Query Health program  including current pilots and next steps.  Massachusetts is proud to be a participant in this ground breaking effort to send questions to the data rather than data to a central repository.

Jim Walker presented the work of the Essential Components Tiger Team which included recommendations for federal action to make usable and useful value sets available for Meaningful Use Stage 2.

Betsy Humphreys presented an overview of the latest NLM work to provide curated code sets, vocabularies and cross-maps.   She offered us optimistic comments that ONC and NLM are working hard to operationalize the HIT Standards Committee request for hosting these code sets in one central location for any stakeholder to access at no charge.

A very rich agenda that represents the maturity of the standards harmonization process.  We're no longer debating basic vocabulary, content, and transport standards - we're thinking about advanced ways to enable an ecosystem of data exchange.

Our Cancer Journey Week 23

Radiation Oncology planning begins June 1 and radiation treatments begin June 6.   Kathy is regaining her sensation in her fingers and toes, but she does find that a day of walking results in pain/fatigue in her lower extremities.   All of this pales in comparison to the news we received last week that she is now in complete remission.

Last Thursday,  Kathy's pathology results concluded there is no residual cancer.   Here's the report

Breast, left, lower inner quadrant, needle localized partial mastectomy :
Changes consistent with tumor bed/biopsy site.
No residual carcinoma identified.
Margins inked and evaluated.

Breast, left, lower inner quadrant, radial re-excision :
Changes consistent with tumor bed/biopsy site.
No residual carcinoma identified.
Margins inked and evaluated.

We were overjoyed and used the weekend to get our lives back on track with the day to day chores on the farm. I shoveled hundreds of pounds of debris from the compost pile, repaired doors/windows, and built a tree swing.

Kathy is again doing heavy lifting since her surgical site is healing rapidly.   She's up at 5am and working until 9pm.

The stress and anticipation in our lives is palpably different.

Now we will learn about radiation treatments, which she'll receive to significantly decrease the risk of cancer returning after surgery.  We are believe the treatments will be daily (7 days a week) for 5 weeks.   What are the side effects to the local skin?    Will the irradiated area become painful over time?  Will she feel fatigued over the course of treatment?

What started as the nightmare of diagnosis in December will become fully treated complete remission by July.

I turned 50 this week and all my birthday wishes have been granted.

Crafting a Social Media Policy

Today's Computerworld has a great article about the issues of mixing social media and healthcare.

As hospitals and clinics formulate social networking policies, there are three broad considerations:

1.  Given HIPAA and HITECH privacy and breach rules, how can you best prevent the disclosure of protected healthcare information on insecure social media sites?

2.  Given the distraction factor and productivity loss that can occur with social media, how can you best align the benefits of groupware communication while minimizing the negatives?

3.  How can you reduce the security risks of malware embedded in games and other applications that are downloaded from social networking sites?

To date, Beth Israel Deaconess has focused on #1, ensuring that our employees do not post data to social networking sites in violation of state and federal laws.

We've not yet completed a  policy covering #2, although several hospital sites and departments are discussing the issue.

We're developing a pilot for #3, including blocks on selected websites, Facebook add-on applications, and personal email.

Ensuring we have a suite of social media policies is one of our Internal Audit focuses for 2012.  To formalize our polices, procedures, and guidelines, we're collecting best practices for healthcare institutions throughout the country and assembling a multi-disciplinary group including Corporate Communications, Legal and IT.

There are many benefits to social networking to foster collaboration and communication.   As we work on developing further policies, I'll share our lessons learned in future posts.

The Challenge of Encrypting BYOD Devices

As we continue the journey to protect corporate data that is accessed from personal mobile devices, we're developing increasingly rigorous policies that  rebalance individual preferences with corporate compliance requirements.

Requiring a non-trivial password and a timeout is supported by all Windows, Android, and iOS phones.   Using Microsoft Active Sync, we can push settings to phones, enforcing corporate policies.

Central management of personal phone encryption is much more problematic.

I've spoken to my peer CIOs in Massachusetts and we all have policies requiring encryption of mobile devices that access hospital information systems.

Massachusetts requires that any mobile device containing "personal information" be encrypted:

"Under the law, personal information to be protected includes a Massachusetts resident’s name (either first and last name or first initial and last name) combined with a complete social security number, driver’s license, or other state-issued number, a financial account number or a complete credit card or bank account number."

However, no local CIO has tried to push encryption settings to personal devices.

Why?

We've tested encryption on several smartphones and found that it lacks robustness - we've had performance issues and data corruption issues.

Many phones do not support pushed settings to encrypt the device.   Some devices, such as any iPhone older than the iPhone 3, do not support encryption at all.    Here's an overview of the heterogeneity.

Similarly, no local CIO has implemented automated remote wipe of personal devices for a certain number of failed password attempts.   At present, smartphones have no capability to selectively wipe corporate data, leaving personal data intact.  Although there are mobile device management (MDM) solutions that require loading software on personal devices, they are expensive and challenging to support.

Thus, the best practice in the hospitals of Massachusetts as of mid-2012 seems to be pushing password/timeout settings, avoiding remote wiping, and requiring encryption by policy rather than a forcing technology.

What about laptops?

Everyone in healthcare wants laptops encrypted because encryption provides a "safe harbor".  If you lose one that contains protected healthcare information , you don't have to go through the full breach disclosure.

There are three generations of laptop encryption strategies

a. Full Disk Encryption (FDE) requiring an application such as McAfee's SafeBoot

b. Native Operating support  for encryption such as Microsoft's BitLocker in Windows 7 and Apple's native encryption in Lion.

c.  Self-encrypting drives with enterprise management software such as Safend Endpoint Security.  The encryption is part of the hardware when the device is procured.

We currently use FDE for Windows XP and native operating system support for Windows 7 and iOS.  We're studying management tools that support self-encrypting drives.

The issue of encrypting smartphones and laptops is a very high priority for hospital compliance and risk committees.   The policies are clear, but the technology to support those policies is still in evolution.

The burden on IT departments to purchase and support mobile device security tools is significant.

Self encrypting drive approaches hold promise because they are operating system neutral and require little support.

We will continue to enhance  our abilities to centrally manage encryption of mobile devices.   Like many security issues, the management of personal device encryption is a journey.