Top 10

1,322 Visits - Is Epic any different than other software vendors? Suresh Gunasekaran (page 52)

827 Visits - EMRs, Data Mining and HIPAA. Reece Hirsch (page 54)

747 Visits - HIPAA Security Rule Investigations: CMS Casts a Wider Net. Reece Hirsch (page 56)

651 Visits - Attendees Ponder HIMSS Plusses and Minuses. Mark Hagland (page 58)

614 Visits - Top Trends: What am I Missing? Anthony Guerra (page 60)

578 Visits - EMRs are Over-Rated: Top 11 Reasons. Suresh Gunasekaran (page 62)

515 Visits - “The Doctor Will See You Now - Oh, You're Dead?” Daphne Lawrence (page 66)

479 Visits - Bad Medicine, a Personal Horror Story. Jim Feldbaum (page 68)

475 Visits - 17 Killer Interview Questions … Tim Tolan (page 70)

438 Visits - Enterprise Archive: Standards and SOA - A Mount Everest? Joe Marion (page 72)

Blog 1 & 6

http://www.healthcare-informatics.com/suresh_gunasekaran

Blog 2 & 3

Reece Hirsch is a partner in the San Francisco office of Sonnenschein Nath & Rosenthal LLP, who specializes in privacy and security law matters. Hirsch's Health Care Privacy Law Blog offers a lively commentary on a wide range of privacy and security issues that are relevant to healthcare organizations, from healthcare-specific issues (such as HIPAA, electronic health records and regional health information organizations) to general privacy issues that healthcare organizations need to be aware of (such as security breach notification laws, Internet privacy and the Payment Card Industry Data Security Standard).

http://www.healthcare-informatics.com/reece_hirsch

Blog 4

http://www.healthcare-informatics.com/mark_hagland

Blog 5

http://www.healthcare-informatics.com/anthony_guerra

Blog 7

Daphne Lawrence, senior associate editor at Healthcare Informatics, believes passionately in sharing information to help her reader constituents. Her hospital background grounds her blog in real life experience; Daphne never forgets that patient care is the heart of healthcare.

http://www.healthcare-informatics.com/daphne_lawrence

Blog 8

Jim Feldbaum, M.D., is a physician consultant specializing in clinical transformation, CPOE, and interoperability. His blog presents an opportunity for physicians to share implementation tips and gripes with other physicians. Further, CIOs and software developers can learn directly from the medical practitioners regarding what functionality they require in this evolving, information-rich environment. Feldbaum is a consultant to hospitals, national consulting firms, and software developers representing the technology needs of practicing physicians and their patients.

http://www.healthcare-informatics.com/jim_feldbaum

Blog 9

http://www.healthcare-informatics.com/tim_tolan

Blog 10

Joe Marion is founder and principal of Healthcare Integration Strategies, specializing in the integration of imaging technologies with the overall healthcare IT landscape. With over 32 years of healthcare industry vendor and consulting experience in imaging and PACS, Marion has concluded that PACS is no longer just for radiology. His blog presents an opportunity to address ideas and experiences with enterprise imaging, including enterprise PACS, PACS in other service areas such as cardiology, enterprise archival strategies, EMR integration, physician accessibility, and IT's role in PACS administration.

http://www.healthcare-informatics.com/joe_marion

POSTING 1

Is Epic any different than other software vendors?

Posted on: 11.24.2008 1:42:41 PM

(1,322 hits)

Suresh Gunasekaran

Like many other healthcare organizations around the country, my healthcare organization has made implementation of information systems a major strategic priority. To that end, we have effectively pursued a single-vendor strategy over the last several years, with Epic Systems as that single vendor. Our single-vendor strategy is partially the product of our executives preferring that there is value from all of our systems being “pre-integrated,” and partially the product of the success that we've had with Epic Systems.

As a former Gartner analyst, I've watched the industry for many years and seen many vendors gain and lose market share. In the late 1980′s, SMS (now Siemens) and HBOC (now McKesson) solidified their market share as the major hospital systems players as Meditech established itself as the solution for the masses. Throughout the 1990′s, Cerner and Eclipsys gained tremendous momentum in the clinical space, and ultimately delivered their Millennium and Sunrise suites which were greeted with much sales success. Each of these vendors, during their time, was much hyped and promised to be the single vendor of choice for the future.

Although all of these vendors and their customers enjoy success today, Epic Systems has shifted to the forefront of the buzz, and is most often cited as the one-stop shop of the future. I think this is because Epic has been better at going from the Ambulatory to Inpatient product sphere gracefully, where many of the others have not been able to go the reverse route without many failed promises.

Let me put my biases on the table. We've invested millions of dollars in Epic products. My career is definitely enhanced through the continued success of our Epic partnership. This is now the second organization in which I've used Epic products. However, to be candid, the Epic bet was placed on the table before I took my present job 4 years ago. My job was to make the bet pay off.

I still believe today that a single vendor solution is limited at the current state of product development. I would have preferred a core clinical systems vendor and a separate revenue cycle systems vendor. Our organization budget and management team would never have allowed me to pursue that direction with my current organization. As CIO, my job is to deal in realities first, and possibilities second (especially in the middle of a financial turnaround).

That being said, I'm often asked (and I ask myself), what makes Epic different from the market leaders in the past? There are no simple answers…

Their products work. For the most part, Epic's greatest strength is fundamentally sound engineering. Their marketing never goes further than their product capabilities. Anything that is released works. The history of this industry is littered with systems that have been released before their maturity.

Youth is served. The average age of the Epic employee has to be lower than any other major IT vendor. That is good because this staff is very intelligent, knowledgeable on their products, hard working, committed to drinking “the Kool-Aid,” and for the most part, fearless. That is bad because many of the staff seem green at the beginning of installs, don't “click” with lifelong nurses, and lack some of the people facilitation skills that are necessary for organizational change that is necessary with any major system install.

Verona is the center of the universe. First off, the staff is excessively proud of the headquarters campus (with the kind of exuberance that dot-com employees used to rave about their offices in the Valley). On a serious note, the campus is an interesting metaphor for Epic's approach to their business and their customers. First, they have only one office in the country and all of their employees are there: their attempt to have one culture and one tight-knit company (a little tough with all of their employees). Second, they bring all of their customers there for all training sessions and user group meetings: a sincere attempt to connect your customers to your company, but also a reminder that the convenience factor for the company comes before the convenience of customers (still no regional training centers).

It's functional, but it ain't pretty. The product has always been very functional and the emphasis of the products continues to be on getting the work done (a good thing). However, for most Epic users, who use the internet and computers regularly, the Epic screens have to be the ugliest, most crowded screens they will see (sorry Carl). Okay, maybe they are not that bad, but I do get asked way too often whether Epic makes money per mouse click off of us (lots of clicks).

Honest, trustworthy people. It must be Midwestern nice manners. Or the fact that the executives are genuine, down-to-earth people. Or that the average 20-something is very polite and well mannered these days. Overall, the folks from Epic are the type of people that you like doing business with, and can trust to be true to their commitments. They aren't going to score any style points (their on-site presentations are very bland), but they score well on substance and sincerity.

The history of Epic Systems is adding a new chapter. The title of this chapter will be determined by whether customers like me are able to truly find value from having all of this in one system, or whether we will be judged harshly for having the second best of every module in the market for the sake of having it all open from the same one icon.

POSTING 2

EMRs, Data Mining and HIPAA

Posted on: 3.27.2008 6:59:52 PM

(827 hits)

Reece Hirsch

The current Healthcare Informatics online poll asks whether you would contract with an electronic medical record vendor that had an arrangement with a third party to mine EMR data for research or other purposes. It's important to remember in these situations that an EMR vendor will typically be a business associate of a healthcare provider within the meaning of HIPAA. A compliant business associate agreement must “establish the permitted and required uses and disclosures” of protected health information (PHI) by the business associate. In short, an EMR vendor can share information only to the extent that it has been permitted to do so under the terms of its business associate (BA) agreement.

BA agreements may contain optional provisions permitting “data aggregation” services, “de-identification” of PHI and use for the “proper management and administration” of the business associate. “Data aggregation” and “de-identification” have defined meanings under the HIPAA Privacy Rule. It's a little more unclear how far a vendor may go in using PHI for its own “proper management and administration” purposes. HIPAA-covered entities should never sign a BA agreement with an EMR vendor (or any other vendor, for that matter) without watching for these key phrases and understanding fully how the vendor intends to use and disclose their PHI.

POSTING 3

HIPAA Security Rule Investigations: CMS Casts A Wider Net

Posted on: 3.21.2008 6:02:43 PM

(747 hits)

Reece Hirsch

In an earlier post, I talked about the “new era of HIPAA Security Rule enforcement,” which was heralded by public statements made by Tony Trenkle, director of the Centers for Medicare & Medicaid Service (CMS) Office of E-Health Standards and Services (OES). In February, OES posted additional information about the new HIPAA security enforcement initiatives on its website, and there were a few surprises.

First, Mr. Trenkle's initial statements indicated that OES would focus its HIPAA security “investigations” on covered entities that had already been the subject of complaints of non-compliance submitted to CMS. Apparently, OES is going to being reviewing a broader range of entities. The OES website states, “Onsite investigations may be triggered by complaints alleging non-compliance, while onsite compliance reviews will typically arise from non-compliant related sources of information such as media reports or self-reported incidents.” This means that a HIPAA-covered entity that has experienced a high-profile security breach can add “OES HIPAA security compliance review” to the list of bad things that could happen to them (right alongside “class action lawsuit” and “Attorney General enforcement action”).

Second, the sample checklist that OES posted includes some items that are not strictly required by the HIPAA Security Rule. For example, the checklist indicates that OES may ask for a covered entity's vulnerability scanning plans and network penetration testing policy and procedure, along with the results from the most recent vulnerability scan and network penetration test. These measures are certainly consistent with reasonable data security practices, but they highlight that HIPAA-covered entities should not focus exclusively on the standards and implementation specifications set forth in the Security Rule. CMS' mantra during the development of the Security Rule was that the measures were intended to reflect “reasonable” security practices. These new statements from OES should tell covered entities that reasonable security is an ever-evolving standard and the letter of the Security Rule standards is only the beginning.

POSTING 4

Attendees Ponder HIMSS Plusses and Minuses

Posted on: 2.27.2008 7:51:09 PM

(651 hits)

Mark Hagland

Is it our imagination, or are we missing some CIOs?

Even as Wednesday at the HIMSS Conference in Orlando wound down a bit in the late afternoon, and many attendees left to return to colder or at least distant climes (not counting those hardy individuals who might planed to stick around through Thursday in order to hear Google, Inc. Chairman and CEO Eric Schmidt speak at Thursday morning's keynote address), attendees and observers began to wax philosophical about the pluses and minuses of this year's conference.

To begin with, some were noting the relatively small number of hospital and health system CIOs strolling the Exhibit Hall floor at the Orange County Convention Center. David Ziolkowski, vice president of Sampson Regional Medical Center in Clinton, N.C., was one who noticed. “There just aren't as many of them around this year,” said Ziolkowski, who was participating in activities at the Agfa booth as a hospital partner (Sampson is currently implementing a full suite of Agfa clinical information systems). “I'm pretty tight with my peers from North Carolina, and I've only seen a few of my North Carolina colleagues here.”

Perhaps one reason for the CIO gap, says Frances Turisco of what had been First Consulting Group (now a part of the Computer Sciences Corporation, following its acquisition by the El Segundo, Calif.-based firm in January), is that so many hospitals and health systems have already installed at least first-generation core clinical information systems. Turisco, a director in the Boston-based Emerging Practices Group at that organization, said the more significant gap is in the lack of available tools to help clinician and executive leaders of patient care organizations translate the advantages of EMRs and other clinical IS into data analysis that can in turn improve patient quality, safety, and transparency - what she and her colleagues have been calling “clinical intelligence.”

One irony of the spread of the Internet, noted Scott Grier, at director at the Nashville-based Abrio Healthcare Consulting, is that at this point in time, “There's almost nothing happening on the exhibit floor that cannot happen remotely. So I think the pendulum needs to swing towards focusing on more white paper presentations, towards more focus on interchange, and on raising the bar higher on technological capabilities,” says the Sarasota-based Grier. “We've got to find ways to make the C-suite swoon again.” This year, he says, “I can't find the C-suite people to talk to here.”

Best demo seen on the exhibit floor

Given that fully 905 IT vendors are exhibiting at HIMSS this year, it would be arrogant in the extreme for any individual to unilaterally name a standout vendor, product, or even demo. But I will venture to name the single most compelling demo I personally have seen at HIMSS, and this is it: the demonstration of semantic interoperability capabilities being offered at the dbMotion booth in conjunction with the University of Pittsburgh Medical Center. Bill Fera, M.D., the director of medical IT at UPMC, showed this reporter a software program that he and his colleagues at UPMC have co-developed in the past two years with the Hod HaSharon, Israel-based dbMotion. What was compelling about this was the level of depth of the guiding intelligence behind the tool, which brings data from a variety of disparate systems at the 23-hospital organization right to clinicians' fingertips at the point of care, on a single, integrated screen.

The most interesting aspect of this is the fact that the creators of the system (from UPMC and dbMotion, working together) have been able to successfully dovetail the clinical vocabulary, or semantics, from disparate systems from different vendors, together, making it possible to view all medication orders across ICU, med/surg, and ambulatory environments, for example, on a single screen. Dr. Fera and his colleagues have successfully cracked the code on one of the most challenging underlying problems with interoperability, overcoming the heretofore-unresolvable stumbling block over divergent clinical vocabularies from different vendors, as used in different clinical information systems in the same organization. If anyone else has reached this level of sophistication, we at Healthcare Informatics would like to know about it.

The UPMC/dbMotion demo gave this reporter a little jolt of hope amid what felt like a slightly sober mood at this year's HIMSS. No single “hot” trend, technology or theme has seemed to dominate this year, except for the aforementioned “what next?” quality/safety/workflow optimization work that countless U.S. patient care organizations are tackling, having at least implemented first-generation core clinical systems. If the vendor/exhibit side of HIMSS is going to continue to be relevant going forward, it will be because of the opportunity to learn about such innovations as this amid the usual swirl of hype and competing claims on the annual conference's exhibit floor. Every year, at least a few fascinating new breakthroughs present themselves to attendees amid the general plodding progress forward on the part of vendors and their customers. But sparks of innovation - whether from giant organizations or tiny ones - are always the most exciting elements of the HIMSS experience. May they flourish again at HIMSS 2009 in Chicago.

POSTING 5

Top Trends: What am I Missing?

3.17.2008 6:45:56 PM

(614 hits)

Anthony Guerra

I recently had a meeting at which I was asked to present some of the major trends in healthcare IT - here they are (these are rough notes):

Investment optimization: Initial monies have been spent (electronic medical record packages) - now it's time to focus on continuing education, optimization, change management, adoption, fostering adoption - getting more people to use using more of the system - how do you get the right information to the right clinician at the right time in the right format (clinical decision support)

Stark: everyone wants to lock up the docs first

ERP optimization: integrating revenue cycle management, computerized physician order entry (CPOE), operating room scheduling into enterprise resource planning for financial reporting and analytics

Efficiency: staffing/scheduling, patient logistics, asset and patient tracking

Patient safety: reducing medical errors, medication administration, CPOE, workflow management, optimization

Cross vendor application integration: integration (sharing single database) rather than interfacing - HL7, CCR, DICOM, CCHIT, HITSP, ASTM

Project management: system selection - how many to involve, super-users

Vendor relationship management: utilization of consultants in baseline, needs assessment, request for proposal development, system selection, contract negotiation, and service level agreement management (it's a marriage)

What do you think?

POSTING 6

EMRs are Over-Rated: Top 11 Reasons

Posted on: 12.13.2008 4:14:59 PM

(578 hits)

Suresh Gunasekaran

Don't get me wrong, EMRs could be great, maybe even better than the WWW.

When I lived in the Bay Area in the late 90s, I was struck by the fact that everyone said the Internet, and specifically the WWW, was earth shattering, game-changing, and would make us forget all that preceded it (in 1998!). The point being that in the 90s, we could imagine the tremendous potential of the internet age, but the realities were still a far cry from that. A decade later we have come a very long way, but still more is left on the journey.

Keep in mind that I'm a CIO who just went live with many EMR components in the past two months, so I may be a bit more deluded than usual. I take tremendous pride with what our organization has done and how much better life truly is as a result of the system implementation. However, there is a part of me that feels like some CEOs/CIOs in 1998 that read the press, spent the money, and built a fancy website for their company, and said, “now what?”

Just putting up the website didn't change the world. 1998 was the beginning: putting up a website or paying someone a lot of money to put up the website didn't change the game. However, everyone accepting that they were going to use the Internet over the period of a decade did change the world.

The healthcare industry accepting that we are going to use EMRs and President-Elect Obama affirming this direction will change the world. Here are 10 reasons why it hasn't changed yet. If you're glass is half-full, here are 10 things that will change in the next decade:

Can't Get Information Out. We've spent way too much time thinking about how we are going to get all that paper in the healthcare world into the EMR. We need to spend more time figuring out how we're going to get the information out in a cogent, actionable manner for the many clinicians that want to use it. We can't surf EMRs the way we surf the web. We need better data aggregation, handoff reports from one provider to the next, and a standard way of looking at a lifetime record.

Computers Don't Change People. An EMR does not in and of itself develop better communication between members of a care team. It gives them access to the same information, but it doesn't answer questions about what clinical processes and roles and responsibilities should be in a hospital. Even after an EMR, there will be clinical lapses: missed meds, empty handoffs, etc. Even worse, just like the e-mail age, the EMR will facilitate people talking less to one another (as an unintended consequence).

Not Enough Patient Participation. We can't type all of this stuff ourselves. We need more help from patients (who usually are pretty knowledgeable) to contribute to the information that we are collecting. Not all patients can type, but a lot more have questions and are accustomed to using their PCs to live their lives. It's time that we tap into that potential in a responsible way and start interacting with our patients over the web channel.

The Data is Ugly. Anything that isn't billing data in the healthcare industry is ugly. There are inadequate nomenclature and data standards that are applied to content across all medical specialties. My apologies to the hard working souls that are tackling these beasts across the industry (we need you), but we're not close enough yet. On top of that, even if we standardize the nomenclature, any 10 of my doctors will document the same clinical characteristic in 10 different locations in our EMR.

We Don't Know How To Drive. Our little auto industry (EMR industry) still doesn't build cars that look the same, and most of our drivers (doctors, nurses, etc.) have never seen a car before. The net effect of this is that many of our drivers drive in second gear all day, or take 3 right turns instead of taking a left turn. Vendors need to get more intuitive user interfaces, and healthcare organizations need to get better at driver's ed.

It Doesn't Know Me & Can't Listen. If I'm a doctor that sees patients, my EMR better know who I am when I walk up to the terminal (through proximity badge or some other technology) and better listen to what I have to say (voice recognition or similar technology). Typing takes too long and we need more innovative user technologies (the real killer Internet app for consumers is integration with your cell phone - what will be the killer app for users in the EMR space?).

They Don't Help You Drive Clinical Quality. Theoretically, if all of your patient information is in there, you should be able to figure out how well you perform certain interventions or how effective are your outcomes. However, EMRs place their current emphasis on getting stuff into the system: the goal is to be able to write any order the patient might need. The functionality is not developed to help you write the correct order for the patient. Lots of industry lip service to this goal; we need more technical innovation.

It's too expensive. Yes, I said it. Hospitals have very tight margins, and doing the right thing by EMR investments is just plain too expensive. Now I know that I probably could improve my cost management skills, but the stuff costs too much upfront, takes too many people to configure in the first place, and entirely too many people to take care of the system after the fact. Most healthcare IT shops are staffed liked they were developing the software themselves, not like they are managing a packaged application. Something has got to give sooner rather than later.

We need new staff. From what I can tell, to really use an EMR appropriately, you need a lot more nurses, pharmacists, and physicians to help with system development and support in the IT department. Last time I checked, these people were hard enough to come by, let alone be hired away by an IT organization or vendor. We need a new breed of healthcare IT worker that can be trained with the appropriate, relevant technical and clinical information to support a CPOE system without being a doctor.

EMRs don't make money. There is no positive correlation between using an EMR and profitability. That's because they are not intended to make your hospital more money. You can't spend this kind of money in healthcare and not get a dollar for it. An EMR won't allow you to have fewer nurses or doctors per patient. A payer doesn't pay you more for using an EMR (yet). They do pay you for managing your patients better and accurately capturing all of the services you provided them. It would be nice if the system did this for you (some systems do this some of the time - all the time would be nice).

Clinical Research. It's almost assumed that if you put this much patient care information in one place that you should be able to naturally and easily perform analytics against it. In our industry, incentives are not aligned for this purpose. In the banking, airline or manufacturing business, these analytics were lifeblood for competitive advantage. In the healthcare industry, research organizations (except at research universities) have been separate and are not used to this large availability of data. That world is just beginning to change, and normalizing this data and making it available as large data sets to researchers is not an easy process. Hopefully, soon this will change.

Unlike the Internet, there has not been a critical mass of investment in this sector to drive the innovation to revolutionize the EMR space. It remains to be seen if this innovation will come from Epic, Siemens, GE, McKesson, Meditech, etc. or from some other source. Signs point to this investment changing, but as of today, I contend the EMR is overrated. I installed my EMR, and life feels the same. However, I can see some things changing down the road.

POSTING 7

“The Doctor Will See You Now - Oh, You're Dead?”

(515 hits)

Daphne Lawrence

This really happened to me.

I was at my physician's office for my annual-and had already been there for more than an hour and a half, a typical wait time in his office. Next to me was a very old woman accompanied by her caregiver. They were there when I arrived, so she must have been waiting at least two hours. The receptionist (who books appointments a year out) finally called out the old woman's name, and the caregiver tried to rouse her from what I thought was a doze.

She was completely non-responsive.

The caregiver frantically begged the receptionist to get the doctor. “The doctor is in his office and cannot be disturbed,” was her answer. Really. She would not, even with all the patients in an uproar, go inside and get the doctor - who I'm sure had no idea what was going on. Long story short, EMS quickly arrived and took her out on a stretcher - still unresponsive… and I believe, dead.

Which, though it may seem macabre, has given me the punch line of all times: “THAT doctor? You could die waiting to see him.”

Now, I don't usually talk about ambulatory EMR/PM solutions in this space, but I always try and bring them up with my doctor (who, by the way is a brilliant clinician and for me, anyway, worth the wait.) He tells me that he is a one-man shop and it is just too prohibitive for him, cost-wise, not to mention the down time he says is involved in implementing one. So we wait, and we wait, and we wait.

For at least one of us, that wait was too long.

By the way, it's a year after this happened, time for my annual again, and I'm writing this from my doctor's waiting room.

I've already been here an hour.

(Update: I'm home and the wait was only an hour 45. Why do I do it? Because he spends time talking about my life, treats me as a whole person, asks questions about my family, remembers everything about everything I've ever told him, and can make a confident diagnosis using a stethoscope and his hands better than any doctor using an entire a panel of tests. He has oriental rugs in his exam room, art on his walls and is one of the few doctors I know, besides my dad long gone, who practices medicine as an art. I'll go to him forever.)

POSTING 8

Bad Medicine, a Personal Horror Story

5.4.2008 1:01:49 PM

(479 hits)

Jim Feldbaum, M.D.

It seems that everyone has a horror story about the care they received in the hospital. Is it because we providers deserve our patient's criticism or have they become more suspicious and alert to the risks? Maybe it has just become fashionable to knock the quality of the American healthcare delivery system?

I have had two recent personal experiences as a patient in the operating room. One was perfect. Obviously, this is about the other.

The facts are simple: I have a potentially life-threatening reaction to certain types of anesthesia and I am allergic to Ancef, an antibiotic. Furthermore, you must take into account that I am a consultant making a living by promoting and implementing mechanisms for safer healthcare delivery.

Being a physician, one could argue that the odds would be in my favor. I am more knowledgeable about medical care and I might get special treatment from my colleagues. I know how to be a good patient. I called in to the anesthesiologist a week before my surgery to review the safest route of anesthesia and I brought a printed and detailed medical history with me on the day of surgery. The surgery center's only electronic capability was for billing (it worked perfectly).

The fiasco began when I was told that the anesthesiologist with whom I had discussed my procedure a week before was not there due to a schedule change. I was assured, however that it had been discussed with his colleague that would be putting me to sleep. It hadn't. There was no record of our discussion. My nurse, a “traveler” (an agency nurse hired to work during our busy snowbird season) checked my armband and the label on my pre-op antibiotic before hanging it. I asked to see the bag of medication before I allowed it to run in. Despite my red armband it was Ancef. She was apologetic. She returned with Clindamycin, an alternative antibiotic, and having learned her lesson from the Ancef, offered me the IV bag to examine. Yes, it was clindamycin, but why was I getting an antibiotic in the first place? I asked to see the physician order sheet. My physician had faxed in a standard pre-printed order set. There was a large X by both antibiotics. To my doctor the X meant no. To my nurse it meant yes.

A doctor in scrubs approached my stretcher syringe in hand. He introduced himself as my anesthesiologist (the other was on break) while simultaneously reaching for my IV line to inject “happy juice.” I stopped him abruptly. He too was uninformed of my anesthesia sensitivity.

So what went wrong? What lesson can be learned from this horror story? Would an electronic medical record have provided some protection? Yes, an EMR with CPOE would have caught my allergy to Ancef and an appropriately implemented medication administration system would have blocked administration. Yes, CPOE would have made my physician's orders clear and unequivocal. No, there is no protection against poor communication, incompetent hand-offs, or bad policy and procedure. We need to get our house in order.

True interactivity is not about clicking on icons or downloading files, it's about encouraging communication.

-Edwin Schlossberg, 2002

POSTING 9

17 Killer Interview Questions…

Posted on: 11.4.2008 11:26:02 AM

(475 hits)

Tim Tolan

In a book I co-authored earlier this year titled, “The CEO's Guide to Talent Acquisition,” we highlighted a list of questions that a hiring managers should consider using in the interviewing process. It's not rocket science and… I am in NO way suggesting that this is a complete and comprehensive list of questions. I am only suggesting that you might find some of these questions interesting the next time you conduct an in person interview. Whether you use some of these questions or a list of your own, you should try to create an interview questionnaire that you follow in each interview session. It will make the interview flow much better and give you a way to benchmark and compare answers to the same questions.

What question do you have for me right away?

What would really surprise me about you? What else?

What's your real motivation to change jobs? No, the real reason (test, re-test)

What's your philosophy on goal setting?

What reading material would I find on your coffee table, night stand, kitchen table, car?

Tell me a story about you placed in an ethical dilemma and what happened?

How did you earn money while in college?

How far away from home have you traveled? (Have a map on your desk)

Draw me a pie chart showing how you spend an 8 hour day.

Are you a curious person, and if so, show me an example

What's your favorite success story and failure story?

What should I have asked you that I haven't?

Want to be a millionaire? Why? What are you doing to prepare for it?

How would your world change if you made $35,000 more next year?

Are you ready to resign from your job in 5 days? What will they do when you quit? What will they say about you after you have left the company?

Share some stories about the 4 most influential people you know.

Have you ever created a 30, 60, 90-day strategic plan for your job or a future job? (Well, today's their lucky day)

Happy interviewing!!!

POSTING 10

Enterprise Archive: Standards and SOA - A Mount Everest?

Posted on: 5.30.2008 6:09:04 PM

(438 hits)

Joe Marion

From my involvement in a couple of current engagements, a key dilemma facing anyone considering an enterprise image archive is the question of architecture, and is it possible to “reach the pinnacle” of a truly vendor-neutral, patient centric solution that can receive input from multiple service areas, and provide accessibility to a number of applications?

I am reminded of some recent computer technology battles that might be bell weathers for healthcare image archiving. One example is the 802.11 N wireless standard. In the words of Wikipedia, “…market demand has led the Wi-Fi Alliance to begin certifying products before amendments to the 802.11 standard are completed.” In other words, in the zeal for faster networking, people are willing to gamble on hardware in the hope that it can meet the eventual final standard.

Another good example is the Blu-Ray versus HD DVD format war. Some elements of consumers were willing to plunk down large sums of money to be pioneers before one or the other became the de facto standard. In this case, Blu-Ray won. And what about all those who bet on HD DVD? At least one retailer is capitalizing on it - Best Buy is offering gift cards to help clear out HD DVD inventory, and trade-ins to convert to Blu-Ray. Smart retailing!

The “lesson-learned” for healthcare imaging: Is there a horse race brewing in terms of enterprise image archival? A lot is made over industry standards efforts such as HL7, DICOM, and IHE as the answer to an enterprise archive. In a perfect world, everyone will interpret the standard, and vendor A's device will easily interoperate with vendor B's device. Unfortunately, it's not a perfect world, and vendors still strive for some competitive advantage. Hence, in DICOM there are fields that can support proprietary data! So, is the industry really behind the standards, or merely giving lip service to them and looking for any chance they can to gain a competitive advantage? In the case of an enterprise archive, there are those that would propose force-fitting everything into DICOM, so a non-DICOM object would be handled by enveloping it in a DICOM wrapper.

At the opposite end of the spectrum are those who subscribe to a patient-centric, service oriented architecture (SOA). The SOA concept has broad IT appeal in terms of interoperability, and might be considered as a mechanism to supplant standards, and enable different services to cope within the environment. Those that would subscribe to this approach argue that the objective is to create a “vendor-neutral” solution that can interoperate in multiple services. This sounds like a great answer, but, where is the incentive to make it work? Is it market pressure alone that will force vendors toward solutions that interoperate? Will competitiveness get in the way such that proprietary hooks preclude true interoperability?

What is the answer? I am sure there are multiple viewpoints. Having raised this issue, I would like to propose this as a forum for sharing ideas - from both users and vendors, with the objective of educating those for whom this is a concern. I welcome your comments. What do you think? Should the enterprise archive wait and be driven by standards? Or, is SOA an alternative that will win out from market pressure just as Blu-Ray has?

I welcome your thoughts!

The issue may not be to “force fit everything into DICOM, so a non-DICOM object would be handled by enveloping it in a DICOM wrapper.” DICOM value is to provide consistent metadata about the image, both general purpose metadata and modality specific metadata. That is not “simply wrapping.” DICOM has gone a long way to standardize this metadata across over 30 imaging specialties among which radiology is just. That common semantics and its support across the enterprise IT systems make the medical value of an Enterprise Image Archive. If each enterprise cooks it and bake it their own way, there will not be much interoperability achieved, or at a very low level of technology and clinical practice. As you know, the pixels of a medical image value is quite limited without the image acquisition context.

SOA is an overreaching approach to link IT and the supported business processes, with much appeal and only early realizations. You may be misreading the value of SOA in term of interoperability. It is only a set of software tool and a framework within which interoperability standards such as DICOM may be deployed. SOA does not replace or supplant interoperability standards. This may be a disappointment to you and some of your readers, but defining and standardizing in a consistent way the semantics of metadata associated with images in an enterprise archive remains a challenge where DICOM is and may remain of central value.

DICOM has been created as a “service-oriented” standard rather than a messaging standard (Hence the concept of Service Class). This makes embedding DICOM communication services into an SOA software and business architecture quite natural. So the gap between those two worlds is really small and will disappear with the new Web Services access to DICOM persistent objects under development. Hope this addresses most of your concerns.

Charles

Friday, June 13, 2008 2:17:50 PM by Damien

Hi Charles,

I'm the Lead Architect at TeraMedica, and co-Administrator of the dcm4che.org open source DICOM/IHE project.

Regarding the wrapping of non-DICOM with DICOM: I agree wholeheartedly with your assessment. One of the biggest values of DICOM is the standardization of object metadata and demographic information (all of the header attributes). From an archive perspective, the choice is whether or not to store non-DICOM objects in a DICOM-wrapped format or in their native format. The thing to keep in mind is that not all producers and consumers of clinical objects (images, video files, documents, tar files, etc.) understand DICOM. Likewise, not many DICOM applications would understand a Word document, tar file, or AVI video file even if it were wrapped in DICOM. So, I think it is necessary to offer a means of retrieving (and storing) non-DICOM content in their native format - regardless of how the content is stored internally within the archive. Obviously this would be in addition to standard DICOM services if the archived content has been wrapped in DICOM.

Regarding SOA: You're right. I think that SOA is an overused buzz word (and has been for years). It is not a silver bullet, and the implementation of an SOA is very much open to interpretation. A service oriented architecture is a collection of technologies, patterns and practices which follow some general guidelines. There are many of these guidelines, but I think the following are two of the most important:

• The services are accessible to heterogeneous consumers

• The services have well defined interfaces/contracts which are published

So, I could, in theory, take those points and say that my DICOM archive can participate in an SOA because my DICOM (and HL7) services are available to heterogeneous consumers regardless of the programming language used to implement the consumers. My DICOM interfaces are well defined by the DICOM and HL7 standards and the product's DICOM/HL7/IHE conformance/integration statements. While all of that is true, I think it is a stretch to say that this type of system (common in medical imaging) can participate in a traditional SOA - unless there is an enterprise service bus which understands DICOM and HL7, and can translate service calls from non-DICOM consumers. XML-based services (SOAP and RESTful) have been the norm in SOA implementations for years because of the ability to use a common internet protocol (HTTP/HTTPS) and an industry spanning representation of data (XML).

I'll give you an example from one of our main products: Evercore. We offer all of the DICOM and HL7 services that you would expect an enterprise healthcare archive to implement. However, we also offer a Web Service API (SOAP in some cases, RESTful in others, XDS, WADO, etc.) so that consumers and producers who do not understand “edge protocols” such as DICOM and HL7 (quoting Paul Chang there) can perform the equivalent of a C-FIND, C-MOVE, ADT, ORU, ORM, etc. Behind the scenes, it is the same business logic. However, offering these services via Web Services opens the door to a wider usage. For example, we have clients with their own web portals, Intranets, RIS, HIS, etc. - systems which are Web-based. Using our Web Service APIs they can securely initiate a number of queries, actions, and administrative functions within our system from a web page using AJAX (Java), Flash, PHP, etc. This is also useful to partners who want to embed our archiving capabilities within their own application and expose archive functionality within their own user interface.

Thank you,

Damien Evans

Lead Architect, TeraMedica

Administrator, dcm4che.org