Wednesday, November 4, 2009
Big J&J Layoff
Johnson and Johnson has announced that they will lay off 7000 employees. That is about 7% of the employees at the company. How can the economy really be improving with such large job eliminations occurring?J&J is one of the most admired and diversified health conglomerates with a consumer division, diagnostic/devise equipment, pharmaceutical drugs and R&D arm. Johnson and Johnson is present in
Unreal Health Care Costs
I took my son to the ER for a broken thumb. It was a minor injury but the thumb is the most important digit on the hand. The ER care was just fine...a quick look, an Xray and a small splint. We didn't have to wait long and everyone was courteous.Imagine my surprise to receive the bill from the hospital. Yes, I have insurance. My out of pocket expense was minimal but here is what the insurance
Standards Lessons from the Web
Following last week's HIT Standards Committee Implementation Workgroup Hearing , Microsoft's Sean Nolan and Gartner's Wes Rishel wrote thoughtful blogs.
They point out that the web has two basic standards - content (HTML) and transport (HTTP). Of course there are several other supporting standards such as DNS, TLS/SSL, URL syntax, CSS, etc. but to get started all you need is basic content and transport. You can learn everything you need to know to create a web page in under an hour.
At the hearings, I got that sense that much of the content we've (HITSP, HIT Standards Committee, the industry in general) proposed for healthcare such as NCPDP Script for eRx, HL7 2.x for lab, and X12 for administrative transactions is fine. There is some debate about the right level of simplification for a clinical summary standard, but I'm convinced that the SDOs will continue to refine clinical summaries in a way that ensures suitable content packages will be available for simple and complex use cases. There is additional vocabulary work to do, but that is already is in progress.
On the transport side, let's explore the options:
1. Do nothing and let the market develop a transport mechanism - after all that is what happened with HIPAA (it specified the content as X12 4010 and left implementation of transport up to the market)
I do not favor this option. In Massachusetts, NEHEN implemented secure appliances to solve the problem of data transport. We spent millions and took years to do this. HIPAA transactions are not as widely implemented as the industry would like, largely because transport standards were missing and implementation guidance for the content was not detailed enough. Of course, you could force everyone to sign up for the clearinghouse/intermediary of their choice but this creates heterogeneity, click fees, and unnecessary middlemen.
2. Specify all the standards and policies necessary for end to end secure transport.
Thus far, we've stayed architecturally neutral and provided a suite of standards for transport that ensure authentication, authorization, role-based access control, and auditing to support all policy variations. This approach has been a fine starting point, but it needs to be refined via policy so the number of standards can be constrained. For example, a policy which states that audit trails must be available showing who looked at what when is probably sufficient instead of requiring every organization to implement a standards-based audit trail. It's unclear what the business case is for a completely standardized, interoperable audit trail. Another example - If policy requires segmentation of the record into standard care, HIV care, mental health care, and substance abuse care, as well as requires that the application enables patients to record their preferences for release of these 4 segments, do we need access control standards or accept that the application adequately protects privacy?
If policies and certification ensure appropriate application behavior then point to point transport might be as simple as TLS with bilateral certificate exchange at the infrastructure level, substantially reducing the burden of implementation.
Of course, some may argue that an approach that uses simple web standards for securing transmission and leaves other privacy controls to the application cannot ensure "chain of trust" end to end security. It is true that each organization and stakeholder would have to decide if they trust the applications used by their trading partners. Our experience with NEHEN is that policy, data use and reciprocal support agreements (DURSA), and simple transport standards can facilitate rapid implementation of healthcare information exchange.
3. Deploy appliances that serve as secure gateways between organizations.
They point out that the web has two basic standards - content (HTML) and transport (HTTP). Of course there are several other supporting standards such as DNS, TLS/SSL, URL syntax, CSS, etc. but to get started all you need is basic content and transport. You can learn everything you need to know to create a web page in under an hour.
At the hearings, I got that sense that much of the content we've (HITSP, HIT Standards Committee, the industry in general) proposed for healthcare such as NCPDP Script for eRx, HL7 2.x for lab, and X12 for administrative transactions is fine. There is some debate about the right level of simplification for a clinical summary standard, but I'm convinced that the SDOs will continue to refine clinical summaries in a way that ensures suitable content packages will be available for simple and complex use cases. There is additional vocabulary work to do, but that is already is in progress.
On the transport side, let's explore the options:
1. Do nothing and let the market develop a transport mechanism - after all that is what happened with HIPAA (it specified the content as X12 4010 and left implementation of transport up to the market)
I do not favor this option. In Massachusetts, NEHEN implemented secure appliances to solve the problem of data transport. We spent millions and took years to do this. HIPAA transactions are not as widely implemented as the industry would like, largely because transport standards were missing and implementation guidance for the content was not detailed enough. Of course, you could force everyone to sign up for the clearinghouse/intermediary of their choice but this creates heterogeneity, click fees, and unnecessary middlemen.
2. Specify all the standards and policies necessary for end to end secure transport.
Thus far, we've stayed architecturally neutral and provided a suite of standards for transport that ensure authentication, authorization, role-based access control, and auditing to support all policy variations. This approach has been a fine starting point, but it needs to be refined via policy so the number of standards can be constrained. For example, a policy which states that audit trails must be available showing who looked at what when is probably sufficient instead of requiring every organization to implement a standards-based audit trail. It's unclear what the business case is for a completely standardized, interoperable audit trail. Another example - If policy requires segmentation of the record into standard care, HIV care, mental health care, and substance abuse care, as well as requires that the application enables patients to record their preferences for release of these 4 segments, do we need access control standards or accept that the application adequately protects privacy?
If policies and certification ensure appropriate application behavior then point to point transport might be as simple as TLS with bilateral certificate exchange at the infrastructure level, substantially reducing the burden of implementation.
Of course, some may argue that an approach that uses simple web standards for securing transmission and leaves other privacy controls to the application cannot ensure "chain of trust" end to end security. It is true that each organization and stakeholder would have to decide if they trust the applications used by their trading partners. Our experience with NEHEN is that policy, data use and reciprocal support agreements (DURSA), and simple transport standards can facilitate rapid implementation of healthcare information exchange.
3. Deploy appliances that serve as secure gateways between organizations.
With policies and over the wire security standards, the market can develop appliances that securely transport packages of content. Some may be SOAP-based using CAQH Core or XDS/XDR and some may be REST-based. The folks at FHA Connect have done a great job creating an open source application that can serve as such an appliance.
One thing I've learned from negotiation (my Walks in the Woods) is that being dogmatic about one solution is rarely the right answer. Folks who know me often hear the word "parsimonious" - the smallest number of solutions needed to meet the needs of stakeholders. The answer is not 100 variations but a small number that provides business value - the right tool for the right job. From the work I've seen thus far, I think the transport solutions that will work for stakeholders include:
1. For those who want end to end standards controlled secure transport that guarantees integrity of documents - XDS, XDR, XDM and XCA fulfill the need. These standards are SOAP-based and enable use of WS* security controls, so they are useful for protecting privacy at the standards level.
2. For those who want standards-based security with simple implementation, an appliance such as FHA Connect, NEHEN, Intersystems' Ensemble, or Orion Health's Rhapsody is a very reasonable approach.
3. For those who want a secure channel for transporting data elements such as a problem lists, medication lists, and labs from EHR to PHR, a simple TLS and REST approach is good enough. Ideally, HITSP and the HIT Standards Committee workgroups will provide an implementation guide with standard URIs/querystrings so that we'll not have huge variation in REST APIs. Some have used the term "Healthcare Internet" to describe such an approach.
I look forward to the work of the next several months. I'm confident that HITSP, the HIT Standards Committee Workgroups, and the new HIT Policy Committee NHIN Workgroup will evaluate the options and make recommendations.
One thing I've learned from negotiation (my Walks in the Woods) is that being dogmatic about one solution is rarely the right answer. Folks who know me often hear the word "parsimonious" - the smallest number of solutions needed to meet the needs of stakeholders. The answer is not 100 variations but a small number that provides business value - the right tool for the right job. From the work I've seen thus far, I think the transport solutions that will work for stakeholders include:
1. For those who want end to end standards controlled secure transport that guarantees integrity of documents - XDS, XDR, XDM and XCA fulfill the need. These standards are SOAP-based and enable use of WS* security controls, so they are useful for protecting privacy at the standards level.
2. For those who want standards-based security with simple implementation, an appliance such as FHA Connect, NEHEN, Intersystems' Ensemble, or Orion Health's Rhapsody is a very reasonable approach.
3. For those who want a secure channel for transporting data elements such as a problem lists, medication lists, and labs from EHR to PHR, a simple TLS and REST approach is good enough. Ideally, HITSP and the HIT Standards Committee workgroups will provide an implementation guide with standard URIs/querystrings so that we'll not have huge variation in REST APIs. Some have used the term "Healthcare Internet" to describe such an approach.
I look forward to the work of the next several months. I'm confident that HITSP, the HIT Standards Committee Workgroups, and the new HIT Policy Committee NHIN Workgroup will evaluate the options and make recommendations.
Tuesday, November 3, 2009
The FY10 BIDMC IS Operating Plan
I've previously posted the Draft Clinical Systems Operating Plan for BIDMC Information Systems.
Today, I've posted the entire FY10 BIDMC IS Operating plan for infrastructure, clinical systems, financial systems, HIM, knowledge services, media services, academic computing, and our community sites.
Highlights include:
Numerous infrastructure upgrades to networking, storage, and security
Meaningful Use of EHRs for inpatient and outpatient clinical care
Upgraded supply chain, revenue cycle, and payroll functionality to support enhanced workflow and efficiency
Continued migration from a hybrid paper/electronic record to fully electronic
Enhancement to consent management education, plain language educational resources, and on- line knowledgebases
Expanded telemedicine and collaboration tools
Advanced research administration support tools.
Meditech upgrades including CPOE, eMAR, and interfaces.
The task of building better applications and more reliable infrastructure is never done, but each year we get better and better. Setting priorities that balance available resources, quality and safety is the challenge. I hope our customers and employees agree that we've set a reasonable balance.
Monday, November 2, 2009
Next Steps for our Community Quality Registry
I've previously described the Beth Israel Deaconess Physician Organization's (BIDPO) decision to create a community registry for quality data warehousing in support of meaningful use.
As the project has progressed, we've made several decisions that I'd like to share.
What quality indicators will we store?
We've inventoried all the pay for performance reporting requirements of our local payers and crosswalked it with the 17 quality metrics required for meaningful use, as documented on the new HHS Blog.
In summary, the measures will include treatment process and outcomes data for:
Acute Bronchitis
Adverse drug events
Asthma
Cancer Screening
Cardiovascular Conditions
Depression
Diabetes
HIV
Hypertension
Immunizations
Lead Screening
Medical Home
Pediatrics
Pharyngitis
Reproductive Health
Substance Abuse
Surgery Patients
Tobacco
URI
Vital Signs
You'll find the details in this presentation.
Other decisions we've made include:
1. All our data content transfers from eClinicalWorks and our home built EHR will be done using the HITSP C32 implementation guide of CCD.
2. Transport will be done using the HITSP Service Collaboration 112, specifically using TLS with certificate exchange. We will use the NEHEN network (diagramed above) for routing from our EHR hosting site to the quality data center.
3. To protect confidentiality we will pseudonymise the data, separating identifiers from the data itself. BIDPO will be able to re-identify data for queries such as assembling quality measures from different data sources, but a breach of the registry itself will not release any patient identified information.
This project will enable us to implement and refine many of the standards recommended by HITSP and the HIT Standards Committee. I will continue to report experiences from our implementation efforts which I hope will be used to enhance the standards implementation guides.
Sunday, November 1, 2009
A Weeks Worth of Food
Universoul Productions has compiled a fascinating look at what one family from different countries eats during one week. Take a good look at the family size and diet of each country. I found this amazing. Starting at the top:#1 - Chad, cost $1.23 U.S.#2- Bhutan, cost $5.03 U.S.#3- Ecuador, cost $31.55 U.S.#4- Egypt, cost $68.53 U.S.#5- Poland, cost $151.27 U.S.#6- Mexico, cost $189.09 U.S.#7-
Fake Hymens For Non-Virginal Women
As a physician, I see a lot of strange things and meet lots of interesting people. I guess I shouldn't be surprised when the oppression of women in many countries across the globe has created a market for fake hymens for non-virginal women. Since virginity is valued above all else in many religions, it was only a matter of time when the artificial hymen would be manufactured and sold. Now with
Subscribe to:
Posts (Atom)