This NY Times article is really about employee engagement, but I guess the confrontational title gets more clicks. It has lots of stats, which I like. If you manage people check it out.
Change Management
SIIM 2014 Reflections
Another SIIM Annual Meeting is in the books. As usual, it was a great event with tons of great information, discussions and networking.
Some observations…
- There are some very bright folks working in clinical informatics that us imaging informatics folks should be collaborating with. They have cool stuff, we have cool stuff. We need to build bridges and keep each other informed.
- Enterprise Imaging is slowly catching on. We need more details documented, such as exactly what values we should be putting into which attributes/fields for specific image types, but the overall message of the need for clear and consistent metadata along with the images is finally taking hold.
- The vendors I spoke to were happy (happier than usual). It is no secret that SIIM is more about education, learning, networking and relationship building than high volume lead generation. It attracts thought leaders and people tasked with knowing how to get things done. Its members are loyal and have long careers in imaging informatics. Still, vendors that I visited seemed happy with the attendees that came through their booths. One emerging vendor closed a new customer on the exhibit hall floor (a first for them).
- Hackathons are fun and a great way to learn about new technology. The SIIM Hackathon was a ton of work to pull off, but worth every minute. When you give smart creative people effective new tools, they can do amazing things in a short period of time. Seeing the applications and intgrations that the Hackathon participants completed in a few days (hours, in some cases) was great.
- Twitter is not only a fun to interact with friends during the meeting, but also a great way to get key points of learning (in near real-time) for sessions that you could not attend. Twitter and climbing the SIIM Twitter Leaderboard ladder is also at the level of an addiction for some (you know who you are).
- Long Beach is a great little place for a meeting.
- SIIM meetings are very well run. The sessions rarely experience any technical issues. Speakers are well prepared. The agenda is clear and finding the rooms are easy. Sometimes we only notice when things go wrong, but fail to notice when they go right. SIIM staff has this ‘running a meeting’ thing down to a science.
That’s it for now. Already looking forward to SIIM 2015 in Washington D.C.
Article – Corporate Acquisitions of Startups: Why Do They Fail?
This is a great article. With the rampant acquisition of smaller companies by larger ones that is common in the healthcare IT industry, and the inevitable slowing or death of product innovation and organizational momentum when they merge (read as: are absorbed), it is very useful to know why this happens.
On a related note, if you are interested in start-ups vs. established corporate vendors, check out my article on Where to Build It?.
Article – The time is now for deconstructed PACS
Here is another article (on Aunt Minnie; you likely need an account to access, but it’s free) predicting the deconstruction of PACS (and workflow management systems, like RIS). This mirrors many of the same predictions made in the article titled PACS 2018: An Autopsy, published in JDI recently.
The author’s observations on the lack of recent innovation in PACS is likely attributable to the saturation of PACS in mature markets. Would you invest the same amount in R&D on PACS in today’s environment as you would before the PACS “gold rush” of the mid-2000’s? I touched on this in a blog post a year ago after attending the SIIM 2013 Annual Meeting.
Article – Reimbursement in medicine: One radiologist’s perspective
A good read from a bright person on medical reimbursement. Check it out.
Article – Forecasting a New Reality for Radiology — An Investment Banker’s Thoughts on How Imaging Will Evolve
A lot has been written on consolidation of Radiology practices in the U.S.. This article in Radiology Today reiterates the economic and regulatory forces behind this trend, but also includes some points on the emotional aspects felt by those that built Radiology practices and are faced with selling.
One point not raised in the article is the operational efficiencies that can be found in IT consolidation. An effective IT organization using a modern image and management platform, backed with skilled staff can enable Radiologists to focus their efforts on quality of service delivery, and not on IT installation, configuration, upgrades, etc.
JDI Article Published – Where to build It
Another article I submitted to the Journal of Digital Imaging has been published electronically.
This article compares the pros and cons of building a healthcare IT application in an Established Vendor, a Start-up or a Hospital Lab environment, examining aspects such as access to design input and validation to commercialization and transition to support.
Check it out and let me know what you think.
Favorite Blog Posts of 2013
As the first calendar year of my blog draw to a close, I thought I would compile a list of my favorite blog posts from 2013. I hope everyone has a safe, happy, healthy and prosperous New Year.
- 100th Blog Post: What I know about Software Development and Crisis Management
- The rise of the mobile-only user …and how this helps the underpriviliged
- Review of Stage 2 Meaningful Use Test Procedure for Image Results …and other MU tests
- Quebec EHR …the difference 2 years makes
- Video – Empathy: The Human Connection to Patient Care
- Designing for the ‘Public’ and the ‘Pros’
- Articles on Mobile Health Applications and FDA Regulation
- Plug-ins vs. APIs
- Article from HIMSS: PACS will not remain a self-contained data silo
- Blog posts on SIIM Web site (Part 1 and Part 2)
JDI Article Published – PACS 2018: An Autopsy
An article I submitted to the Journal of Digital Imaging has been published electronically.
Told from the year 2018, it looks back at the market and technical forces that results in the deconstruction of PACS (and RIS) as we know it.
Check it out and let me know what you think.
100th Blog Post: What I know about Software Development and Crisis Management
I started writing this blog post about this…
Opinions on policy and politics aside, this article on the struggles of healthcare.gov tells a classic tale of large software development project failures, and how not to react when trying to solve the issues.
But as I continued to write my thoughts, this became more about my views on software development and crisis management. So, enjoy (or ignore, or comment).
Hopefully, it is worthy of my 100th blog post (which this is).
On software development…
- Software development, no matter how much research is done on development methodology effectiveness, is as much art as it is science. Treat the artists like factory workers, and you get what you deserve.
- Not all software developers are great at developing all applications in all languages, using all tools. Web development, especially when connecting to legacy systems, is a specific discipline. The best Web developers don’t work at large contract system development houses, in my experience. That’s usually because there are more interesting projects in the world for them to work on.
- In software, one of the most common reasons for failure is complexity. For large projects like the one cited in the article, you have to work very hard to come up with an architecture that makes concepts and aspects of the application simple to extend and use. This is not cheap—it takes time and significant energy from artists to achieve. But, when it is achieved, it is a beautiful thing. You owe it to yourself to experience this at least once in your career.
- Never ignore or otherwise skimp on quality User Experience Design (UXD). Never.
- Designs change. New needs and unidentified technical risks are discovered. Requirements evolve. But if you want to get something done on time, quit changing the (in scope) requirements. If a good design forces you to re-write significant parts of your requirements, that is a good sign that you didn’t write effective requirements. In fact, they may not be true requirements at all. And, BTW, a list of features from a competitor’s brochure are not requirements. If you don’t how to write effective, (mostly) design-neutral requirements, learn. Start here. Then read this.
- Well-written use cases—that everyone on the team has read and understands—solve a lot of problems. So does identifying the operating environment and performance goals sooner rather than later. Tip: Print this stuff out and hang on the walls were the developers and testers sit. Or (if you want to save some trees) make a JPEG of it and ask everyone to set it as their desktop wallpaper for the duration of the project.
- Make developers create unit and integration tests for their code. Have them do code reviews with peers. Make them use code comments and consistently format their code. Make them fix their own bugs. Hold them accountable to the quality of software build they provide to the test team. Make them perform design checkpoints with their peers (or even customers) for any significant component. Anything less and they are not a serious professional developer.
- Developing for security and performance are specific skill sets, but these are most often “want to” issues. As in, if a talented developer truly wants their product to be secure and fast, they will figure out how to make it happen.
- Do daily stand ups. Make the product manager show up.
- A good tester is as valuable as a good software developer. So is a good technical documentation person. They are artists too.
- Give them all good, fast computers with at least two monitors and reliable Internet access. You want something done faster, remove inexpensive barriers.
- Don’t make them pay for coffee. And don’t buy the cheap stuff.
On crisis management (in IT)…
- The comment in the article about the “war room” is spot-on. I call it “the body cannon”. When **it hits the fan, there is usually some executive wanting to pull anyone and everyone off their current work and throw them at the problem, with no real plan. They are simply hoping that through volume, that the problem will be solved faster, when in fact it usually has the opposite affect. The better approach: select a small team of talented, trusted artists (that know the code!) and simply ask them: “What do you need?”, and then get it for them ASAP. Then, be prepared to pay the price of pulling these people off their current project (usually in the form of a schedule slip), once the crisis is over. These things are always about choices, not decisions.
- Yelling at software developers doesn’t work. People that choose a career creating art by typing all day with headphones on are not the type that react well to yelling. If you don’t know how to convey a sense of urgency without yelling, the problem is you. If you don’t understand the problem or software really well, get out of the way.
- If you have hired talented people, they can become heroes. Let them.
And, finally, if you are making an application for use in healthcare, take it seriously. Lives are at stake. It can still be fun and rewarding, but the problems within healthcare are large and demand our best efforts all the time. Now, go be great.
Don K Dennison 