Check out this article by my friend, Gorkem Sevinc, on open source software in imaging informatics. Remember to check out the Open Source Plugfest and the Hackathon at SIIM 2014 in Long Beach California.
Technology
Article – Intelligent virtual assistants
A friend sent me this article on “intelligent virtual assistants” today.
I think this type of technology has merit, but not in the applications that they describe. Accessing patient history information (“Accessing prior reports and specific report content”) or performing a query (“show me all unread chest CT cases”) is already solved with effective EPR client/data integration and proper worklist configuration.
Where this has merit, I believe, is when the new report is being created, and specific words are used, the assistant can then comb through the available data and automatically create links (e.g. a link to lesion measurements before and after cancer treatment), highlight key info to the physician (e.g. because they used the word “x”, some potentially important lab values automatically pop up in the corner as a notice), or in communication (e.g. initiating real-time consults with an available colleague from a list of appropriate specialists based on specific words being used in the report).
To have value, the assistant has to automate the mundane and has to deal with context across data formats, like scrolling through several pages of info in the EMR to see is any of it relates to the current exam (i.e. will impact the reader’s diagnosis).
JDI Article Published – REST Enabling the Report Template Library
I contributed to an article recently published in the Journal of Digital Imaging. The primary author is Brad Genereaux (@IntegratorBrad). His blog is here.
This article examines the use of a REST API to discover, retrieve and use structured radiology report templates from an on-line report repository.
Check it out and let me know what you think.
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.
How Long Before a Computer Writes the Radiology Report?
I play Fantasy Football. Usually very badly. For those that don’t know about this hobby/addiction, this will explain it.
Why am I talking about Fantasy Football on a blog about healthcare IT? Because an intriguing feature showed up this year (I have been in the same league since 1998) on the site that manages our league.
After each week, an article describing the battle between my team and my scheduled opponent’s team appears. It is well-written, insightful and sometimes entertaining. The thing is: it is not written by a human.
The quality of the writing is what makes this interesting. You wouldn’t know that a trained journalist had not written the article unless you knew that a computer did it. Take a look at the image below and tell me that sounds like a computer wrote the article pictured within it.
(BTW, for those Fantasy Football fans that read the article, I missed the playoffs, so the victory described is hollow …I really am terrible at Fantasy Football).
Considering the uniqueness of the scenario—the odds of exactly my 9 starting players playing my opponent’s starting 9 players are extremely rare considering the hundreds of players to choose from, even considering there are tens of millions of leagues operating on the site (yes, Fantasy Football is that big)—the text of the article is highly personalized.
Back to healthcare IT, and how this relates.
Consider the wealth of structured clinical data and diagnostic findings that could be combined with genomic data to produce an information model of a patient. Now consider that an application could take that information and automatically turn it into a narrative report that is optimized for different consumers—for example, one for the GP, one for the specialist, one for the patient, one for the home-based caregiver, etc.
Hyperlinks could make extended clinical or reference data available with the press of a finger.
Obviously, a qualified healthcare professional needs to review and sign/finalize the results before they should become part of a patient’s medical record, but imagine how the report could become more useful to the reader, if tailored to their needs, and how much typing and editing could be saved.
Once all this patient data is unlocked using secure REST-based APIs, like those defined in HL7 FHIR and DICOMweb, some very powerful applications can emerge and revolutionize how results are created.
The interpretation of the images is the high value add that Radiologist provide, not typing or dictating—why not free them up to spend more time with their eyes on the pixels and let the computer do the typing?
Inspiration for innovative solutions to problems comes from all types of places. You just have to look for it. 🙂
Figure 1 – Rare example of A Fantasy Football victory
Reflections on RSNA 2013
I have attended the RSNA show for over a decade, but always as a vendor. My days consisted of many meetings with many customers of varying needs, trying to convince them that the products that our company made were superior to those offered across the aisle by the competitors.
This year was my first year as a consultant. I attended on behalf of clients, meeting with several vendors to discover how their solution could help my client meet their business and clinical objectives.
In short, I was on the other side of the fence for the first time. And it was enlightening.
First, as a vendor, you are on your feet for hours, actively listening, talking, and demonstrating software or presenting information at a high energy level. It is exhausting and your body feels it by the end of the show.
As an attendee, representing a recognized and respected healthcare institution, I had a much different experience. Upon arrival at the vendor’s booth, we (I was accompanied by one or more representatives from the hospital), were led to the comfy couches. We were offered water or coffee or a latte. Everyone was attentive and polite. I would be lying if I said that I did not enjoy this more than the grueling schedule of vendor staff (do thank them when you see them—they work very hard at RSNA).
My personal user experience aside, I had some observations on the way vendors manage the interaction with a potential (or existing) customer.
Caveat: I am not a sales person and have not been one in any capacity since working retail just out of high school. I do not profess to be a sales expert, but I have observed some of the best and worst at their craft, so I know some things about the art of selling.
Observation #1: Vendors do not ask enough questions
I thought this was Sales 101. Qualify the lead.
What problem are they trying to solve? Why did they come to the booth? What are they trying to learn/accomplish during the appointment? Where are they in the buying cycle? Do they have budget? Who is involved in making a decision? What solutions are under consideration?
It did vary from vendor to vendor, but I was amazed at how few questions were asked. Most just went right into their pitch, often trying to convince us of something that we already knew or believed.
Observation #2: Vendors fail to understand the roles of the people in the meeting
Vendors need to remember who the actual buyer is in the meeting. In every meeting, we clearly defined our titles and roles. I was always identified as a consultant. My client representatives were of roles that make buying decisions, yet in some meetings, the sales person made all their eye contact, and spoke directly, with me. In one case, they did this so much, I felt awkward for my client—they were practically ignored. Consultants may be decision influencers, but when you have an actual decision maker in the meeting, pitch to them.
Observation #3: Vendors don’t prepare well enough for meetings with existing customers
If you are a vendor that already does business with the customer, be prepared for the meeting. Know the outstanding issues that customer is having. Know which of your company’s products are installed there and what version they are on. Know the basic installation details (e.g. physical deployment) and which user communities are using the product.
If you don’t know these things, asking them in the meeting does not instill confidence in the customer, especially if there are some outstanding issues to be resolved.
And don’t tell the customer that they are the only one having these problems. It only makes them feel worse.
Observation #4: Solutions are stabilizing
I didn’t see anything that really amazed me. As a person involved mostly in product definition and development with a vendor, we were always told (often by sales people) that everyone else had amazing products and that we were so far behind. In my experience, the solutions offered in various categories do vary in their strengths, but none are abjectly poor at what they are intended to do.
The quality of sales professional varied more than the quality/functionality of the products offered, quite frankly.
In seeking solutions, it is not so much about finding the best product, but the product that fits the institution’s needs the best. Which requires that you know what those needs are, of course.
Observation #5: Analytics are evolving; So are monitoring solutions
Lots of vendors are offering some form of analytics package. Especially those offering products to optimize workflow (they get lots of info that they can make use of in those HL7 messages).
System monitoring is improving, but still have a ways to go. I think customers need to become better educated as to what is possible with a well-designed system monitoring solution, and the benefits (so that they can get the budget approval needed to put it in place).
Check out the Blog Post: Driving Developer Adoption
Brad Genereaux, co-chair of DICOM Working Group 27, posts on how to drive developer adoption.
Definitely worth a read (be sure to follow him if you work in healthcare IT).
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 