In my recent blog about the Standards Work Ahead in 2012, I called DICOM a non-standard standard.
This generated numerous email messages, phone calls, and blog comments.
Let me clarify what I meant.
DICOM is a great standard that has unified many processes within organizations, linking radiology modalities and PACS systems.
Why do I believe additional work is needed?
In December, my wife visited a hospital near our home for a diagnostic mammogram. It was clear she needed followup care with a cancer care team. We decided that Beth Israel Deaconess would be ideal because of its electronic health records and personal health records that would help Kathy coordinate her care. We asked for the images to be transmitted to BIDMC and we were told that we needed to visit the radiology department Monday-Friday 9am-5pm for a CD to be created so that Kathy could drive is 20 miles to BIDMC. The CD contained a proprietary viewer that required Windows and hence was not visible on our home computers (all Mac OSX).
What would have happened in an ideal world?
1. An implementation guide for DICOM would specify required vendor neutral content - a basic set of metadata (patient identifiers, name of the radiology study, imaging techniques used etc.) that would work with any viewer - Siemens, Agfa, Philips, GE, Kodak, etc. Any vendor specific/proprietary metadata would be stored separately from the required basic content, so that extensions do not impact generic viewers. CDs with proprietary viewers and media formats should become a thing of the past.
2. DICOM combines content and transport in a single standard. Although that is create for communication within an organization, it is not sufficient for a healthcare information exchange world that uses the Direct implementation guide (SMTP/SMIME, XDR) for content exchange among organizations. The fact that vendors such as LifeImage, Accelarad, and Merge Healthcare have created their own image sharing networks suggests that more standards work is needed to create an open ecosystem of image sharing among organizations.
3. We should not require organizations who want to receive images to have PACS systems. Instead, EHRs with vendor neutral DICOM viewers should be able to incorporate DICOM content sent via Direct into patient records.
Thus our work on imaging standards should build upon the DICOM foundation we have today, but eliminate optionality for a basic set of metadata, ensure that any proprietary extensions to metadata do not interfere with vendor-neutral viewing, embrace simple transport approaches for cross organizational exchange, and enable even the simplest of EHRs to be participants in image exchange.
We'll do this work in the Healthcare IT Standards Committee from April to June, engaging the industry experts who have worked so hard on DICOM to date.
I hope that makes sense!
Tuesday, January 31, 2012
Monday, January 30, 2012
Update on the BIDMC ICD10 Project
I've written extensively about the challenge of implementing ICD10 and my belief that the billions of dollars required to implement it will not improve quality, safety, or efficiency.
I've spoken to many people at HHS, CMS and the White House about the need to rethink the ICD10 timeline, deferring it until after Meaningful Use Stage 3 which enables us to focus on improving our clinical documentation and adopt SNOMED-CT to capture structured signs and symptoms.
However, I've been told that the Affordable Care Act (ACA) includes cost savings from reduction in healthcare costs/fraud/abuse that require the implementation of ICD10. Thus, it's not likely going to be delayed.
At Beth Israel Deaconess, we're moving forward, assuming that ICD10 must be implemented by October 1, 2013. We held our kickoff meeting in June, hired external resources to create a project management office, and hired subject matter expert consultants to assist with the gap analysis, project plan and budget.
Today, I'm posting two resources for the benefit of other organizations planning their ICD-10 projects.
The first is the RFA we used to hire a consulting partner. In our case, we elected to create a single unified project for the academic medical center, community hospitals, physician organization, faculty practice, and owned community practice. We felt that creating one project for all the stakeholders would reduce costs while eliminating redundancy and aligning resources.
The second is the letter we sent to all our stakeholders, asking them to create an inventory of the software applications and processes that incorporate ICD9 and need to support ICD10.
In the next few weeks, we'll complete our detailed project plan, budgets, staffing model, and timeline. I'll share as much as I can as soon as it is available.
ICD-10 is a costly project that will have no benefits and if we're truly successful, the best we can hope for is that no one will be too upset that we implemented it.
Given a project with this many negatives (here's the AMA letter to Speaker of the House John Boehner), the least I can do is share everything we're implementing in the hopes that others will benefit from our experience.
I've spoken to many people at HHS, CMS and the White House about the need to rethink the ICD10 timeline, deferring it until after Meaningful Use Stage 3 which enables us to focus on improving our clinical documentation and adopt SNOMED-CT to capture structured signs and symptoms.
However, I've been told that the Affordable Care Act (ACA) includes cost savings from reduction in healthcare costs/fraud/abuse that require the implementation of ICD10. Thus, it's not likely going to be delayed.
At Beth Israel Deaconess, we're moving forward, assuming that ICD10 must be implemented by October 1, 2013. We held our kickoff meeting in June, hired external resources to create a project management office, and hired subject matter expert consultants to assist with the gap analysis, project plan and budget.
Today, I'm posting two resources for the benefit of other organizations planning their ICD-10 projects.
The first is the RFA we used to hire a consulting partner. In our case, we elected to create a single unified project for the academic medical center, community hospitals, physician organization, faculty practice, and owned community practice. We felt that creating one project for all the stakeholders would reduce costs while eliminating redundancy and aligning resources.
The second is the letter we sent to all our stakeholders, asking them to create an inventory of the software applications and processes that incorporate ICD9 and need to support ICD10.
In the next few weeks, we'll complete our detailed project plan, budgets, staffing model, and timeline. I'll share as much as I can as soon as it is available.
ICD-10 is a costly project that will have no benefits and if we're truly successful, the best we can hope for is that no one will be too upset that we implemented it.
Given a project with this many negatives (here's the AMA letter to Speaker of the House John Boehner), the least I can do is share everything we're implementing in the hopes that others will benefit from our experience.
Friday, January 27, 2012
Cool Technology of the Week
As Harvard thinks about how best to enable authentication across multiple schools, organizations, affiliates and populations, it has choices to make - centralize all authentication, allow every group to pursue its own strategy, or coordinated federation that includes the best of centralized and localized approaches.
Federated authentication requires a fabric of trust. Among University collaborators, InCommon.org
has been a leader in creating tools, technologies and policies that enables multiple groups within institutions and among institutions to share data based on role-based access. It does not require organizations to issue unique credentials to every collaborator. Instead it delegates authentication to trusted institutions and then creates an ecosystem of access built on trust relationships.
The underlying technology is Shibboleth.
University collaboration via policies and technologies that support federated authentication. That's cool!
Federated authentication requires a fabric of trust. Among University collaborators, InCommon.org
has been a leader in creating tools, technologies and policies that enables multiple groups within institutions and among institutions to share data based on role-based access. It does not require organizations to issue unique credentials to every collaborator. Instead it delegates authentication to trusted institutions and then creates an ecosystem of access built on trust relationships.
The underlying technology is Shibboleth.
University collaboration via policies and technologies that support federated authentication. That's cool!
Thursday, January 26, 2012
Our Cancer Journey - Week 6
On Friday January 20th, Kathy received Cyclophosphamide (Cytoxan) 1200 mg, Doxorubicin (Adriamycin) 120 mg and her pre-chemotherapy supportive medications Fosaprepitant 150 mg, Dexamethasone 12 mg and Ondansetron 8 mg.
She tolerated it well.
Her Complete Blood Count shows that her Granulocyte Count has dropped from 6690 to 3610 since the chemotherapy affects her fast multiplying white cells as a side effect of targeting the cancer. Her hematocrit has fallen from 42 to 32. She tires more easily but her appetite is good. Small frequent meals enable her to overcome any GI symptoms.
We've been told that the Adriamycin/Cytoxan is the most difficult chemotherapy. Only two more cycles to go.
The photograph above shows Kathy and me at age 21 in our Stanford graduation photo. She's always had long, luxuriant hair, even a waist length braid at one point.
On January 21st, her hair began falling out in clumps. It was not exactly painful, but felt very odd, as if her hair had not been washed in months and just did not lie on her scalp properly. In consultation with her cancer survivor friends, she decided to shave it off. Her hairdresser gave her a "GI Jane" cut realizing that the small hairs left will fall out soon, but in a more manageable and comfortable way. I seriously considered shaving my head in solidarity, but she asked me not to.
She's wearing wraps and hats to keep her head warm in the chill of winter. The colors and shapes of her hats give her an artistic and vibrant look.
Dropping blood counts, lack of energy, and no hair may sound depressing. How have we supported her mood?
She's avoided caffeine, alcohol and mood related medications. Instead she's remained positive because of the weekly activities we've planned and the future we're designing that goes beyond the statistics of 5 year survival rates.
In my professional life, I've written extensively about SOAP verses REST as standards for transport. In my personal life, Kathy and I have explored SOAP as Rest via a course on traditional soap making from Back Porch Soap. We've really enjoyed the art and chemistry of saponification, creating our own cold process soaps.
Although we're put our thoughts about Vermont farmland on hold, we've continued to think about how we can move to a more rural location which enables us to plan a long term life together raising vegetables and animals as part of self sufficiency, a lower carbon footprint, and sustainability. This dream of the future creates a guiding vision for fighting the cancer.
Finally, an interesting experience from our role as patients. Kathy has received her care in the middle of the X12 5010 transition which required every payer and provider to change their billing systems. Purely as a side effect of a payer eligibility error during the conversion, she received an $18,000 bill for her care to date. It was remedied quickly, but it illustrates the events that can occur while navigating healthcare in the US.
Wednesday, January 25, 2012
The January HIT Standards Committee Meeting
Doug Fridsma presented the HITSC 2012 Workplan and Updates from ONC. Importantly, he outlined a comprehensive portfolio of building blocks (pictured above) that categorizes the work done to date and illustrates the work done in the future.
Jim Walker presented the work of the Clinical Quality Workgroup including the scope of effort needed to support the quality improvement efforts of Meaningful Use.
Doug and Betsy Humphreys from NLM presented an Update on Value Sets and Vocabulary Mapping including the work on "one stop shopping" for downloadable and web service addressable resources.
Finally, Rob Anthony and Jessica Kahn from CMS presented an update on Meaningful Use activities including attestation achievements.
A very important meeting that sets the agenda for FY12 and creates a foundation for our preparatory work on Meaningful Use Stage 3.
Tuesday, January 24, 2012
Preparing for a Wall of Shame
Every day, I receive over 1000 legitimate, business-related emails. I've written about my email triage techniques and the notion of handling each email only once.
Over the past few months, the number of "business spam" emails has increased significantly. Whether its the economy, the death of paper-based advertising, or availability of bulk email newsletter creation applications in the cloud, it's getting overwhelming - about 500 unwanted, but vendor related emails per day.
Business spam is hard to filter since it represents professional communication from some of the largest technology companies on the planet. I purchase products from many of these companies. However, I do not want to receive any business spam from anyone.
I have never purchased a product based on business spam. In fact, the more business spam I receive, the less likely I will purchase products from advertisers filling my inbox.
I've spent the past two weeks unsubscribing from every newsletter, every mailing list, and every advertising campaign. It's challenging because companies send their advertising content to multiple variations of my email address - jhalamka, john.halamka, john_halamka at multiple variations of my domains, requiring me to unsubscribe more than 5 times in some cases.
Even more irritating are the unsubscribe functions that do not enable one click unsubscribe and require that type in your email address - how do I know what variation of my email address they used?
After a few weeks of unsubscribing as fast as I can, I'll post a list of those companies that are causing me to click delete so many times per day that I'm getting a repetitive stress injury.
I have never opted in to any business spam, so some of these companies have sunk to new lows with fine print such as "we're sending you this email and unless you unsubscribe, you've opted in to our future email". Even unsubscribing does not work because you are often opting out of a single marketing campaign and not all future communications.
The best I can do is create my own blacklist of these companies. Coming soon, the Geekdoctor Business Spam Wall of Shame!
Over the past few months, the number of "business spam" emails has increased significantly. Whether its the economy, the death of paper-based advertising, or availability of bulk email newsletter creation applications in the cloud, it's getting overwhelming - about 500 unwanted, but vendor related emails per day.
Business spam is hard to filter since it represents professional communication from some of the largest technology companies on the planet. I purchase products from many of these companies. However, I do not want to receive any business spam from anyone.
I have never purchased a product based on business spam. In fact, the more business spam I receive, the less likely I will purchase products from advertisers filling my inbox.
I've spent the past two weeks unsubscribing from every newsletter, every mailing list, and every advertising campaign. It's challenging because companies send their advertising content to multiple variations of my email address - jhalamka, john.halamka, john_halamka at multiple variations of my domains, requiring me to unsubscribe more than 5 times in some cases.
Even more irritating are the unsubscribe functions that do not enable one click unsubscribe and require that type in your email address - how do I know what variation of my email address they used?
After a few weeks of unsubscribing as fast as I can, I'll post a list of those companies that are causing me to click delete so many times per day that I'm getting a repetitive stress injury.
I have never opted in to any business spam, so some of these companies have sunk to new lows with fine print such as "we're sending you this email and unless you unsubscribe, you've opted in to our future email". Even unsubscribing does not work because you are often opting out of a single marketing campaign and not all future communications.
The best I can do is create my own blacklist of these companies. Coming soon, the Geekdoctor Business Spam Wall of Shame!
Monday, January 23, 2012
Another Shade of Blue Button
The Blue Button idea is simple - a large visible button on payer, provider, lab, or pharmacy websites enables patients to download their records in plain text.
The Veterans Administration has used it extensively. The Office of Personnel Management asked all health insurance carriers in the Federal Employees Health Benefit Program (FEHBP) to add Blue Button functions to personal health record systems. OPM administers health benefit programs for the civilian sector of the federal government, including all executive agencies, Members of Congress and their staffs, and the federal judiciary on their websites.
The Blue Button is one of several models of health information exchange being implemented.
I've summarized HIE models as:
View - a website or web service enables authorized patients, providers or payers to view data in plain text or HTML. A modest amount of programming is needed, but significant attention to security issues is important to protect the website and data sources.
Push - an EHR sends data to another EHR via the Direct standard. Since this is secure email, a modest infrastructure investment is needed to create directories, certificate management, and gateways.
Pull - an EHR queries a master patient index/record locator service to identify a patient and the locations of their records. The EHR then queries all the data sources to assemble a comprehensive medical history. NwHIN Exchange is an example of such an approach. Significant infrastructure must be built to support and maintain a pull architecture.
Since Push and Pull models require HIEs, which are still evolving, some organizations, including BIDMC and its affiliates have temporarily implemented View approaches inside Epic, Meditech, eClinical Works and self built applications.
Here's how it works:
1. The clinician clicks on a button inside their EHR. This click launches a query containing Name, Gender, Date of Birth, and Zip Code to a responding EHR. The physician does not need to respecify the patient or log in to a separate portal since the patient identity information and security credentials are sent from the querying EHR automatically.
2. The responding EHR checks the security, looks up the patient, and responds with a medical record number if the patient is found.
3. The querying EHR sends a new query incorporating the returned medical record number.
4. The responding EHR launches a web-page which displays clinical data for that medical record number.
5. All transactions are audited in the responding EHRs.
Since this approach works like magic, requires no HIE, and is fast/inexpensive to implement, our clinicians have described it as the "Magic button"
In effect, it serves as a web-based single sign application that retains patient context and enables clinicians to view data from any EHR that adheres to the Magic button implementation guide.
We see it as a temporary solution because it does not result in persistent exchange of semantically interoperable data. It simply enables a clinician to see data such as problem lists, medication lists, allergies, labs, radiology studies, EKRs, reports, and notes in remote systems without requiring a lot of training. It's better than having silos of data and sending faxes.
As HIEs come on line, push and pull models will enable the same kind of data exchange but will incorporate data from sending EHRs into receiving EHRs, enhancing workflow and improving the integrity of the record.
One other problem with the Magic button is that it does not scale very well - we now have buttons for Atrius, Needham, Milton, and eClinicalWorks practices. Clinicians ask the patient where they've received care, get their consent to view the data, and click on the appropriate magic button. As we add more affiliates, the number of Magic buttons will be hard to manage.
In future pull models, record locator services will keep an index of all the locations where patients have consented their data to be accessed.
But for now, having a kind of Blue Button that enables clinicians to view each other's records with patient consent is truly magic for those who use it.
The Veterans Administration has used it extensively. The Office of Personnel Management asked all health insurance carriers in the Federal Employees Health Benefit Program (FEHBP) to add Blue Button functions to personal health record systems. OPM administers health benefit programs for the civilian sector of the federal government, including all executive agencies, Members of Congress and their staffs, and the federal judiciary on their websites.
The Blue Button is one of several models of health information exchange being implemented.
I've summarized HIE models as:
View - a website or web service enables authorized patients, providers or payers to view data in plain text or HTML. A modest amount of programming is needed, but significant attention to security issues is important to protect the website and data sources.
Push - an EHR sends data to another EHR via the Direct standard. Since this is secure email, a modest infrastructure investment is needed to create directories, certificate management, and gateways.
Pull - an EHR queries a master patient index/record locator service to identify a patient and the locations of their records. The EHR then queries all the data sources to assemble a comprehensive medical history. NwHIN Exchange is an example of such an approach. Significant infrastructure must be built to support and maintain a pull architecture.
Since Push and Pull models require HIEs, which are still evolving, some organizations, including BIDMC and its affiliates have temporarily implemented View approaches inside Epic, Meditech, eClinical Works and self built applications.
Here's how it works:
1. The clinician clicks on a button inside their EHR. This click launches a query containing Name, Gender, Date of Birth, and Zip Code to a responding EHR. The physician does not need to respecify the patient or log in to a separate portal since the patient identity information and security credentials are sent from the querying EHR automatically.
2. The responding EHR checks the security, looks up the patient, and responds with a medical record number if the patient is found.
3. The querying EHR sends a new query incorporating the returned medical record number.
4. The responding EHR launches a web-page which displays clinical data for that medical record number.
5. All transactions are audited in the responding EHRs.
Since this approach works like magic, requires no HIE, and is fast/inexpensive to implement, our clinicians have described it as the "Magic button"
In effect, it serves as a web-based single sign application that retains patient context and enables clinicians to view data from any EHR that adheres to the Magic button implementation guide.
We see it as a temporary solution because it does not result in persistent exchange of semantically interoperable data. It simply enables a clinician to see data such as problem lists, medication lists, allergies, labs, radiology studies, EKRs, reports, and notes in remote systems without requiring a lot of training. It's better than having silos of data and sending faxes.
As HIEs come on line, push and pull models will enable the same kind of data exchange but will incorporate data from sending EHRs into receiving EHRs, enhancing workflow and improving the integrity of the record.
One other problem with the Magic button is that it does not scale very well - we now have buttons for Atrius, Needham, Milton, and eClinicalWorks practices. Clinicians ask the patient where they've received care, get their consent to view the data, and click on the appropriate magic button. As we add more affiliates, the number of Magic buttons will be hard to manage.
In future pull models, record locator services will keep an index of all the locations where patients have consented their data to be accessed.
But for now, having a kind of Blue Button that enables clinicians to view each other's records with patient consent is truly magic for those who use it.
Subscribe to:
Posts (Atom)