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).
Technology
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.
Article – Privacy guru knocks patient ID as ploy
I posted some thoughts recently about an article on impact of privacy on patient record sharing.
Now, here is an article that discusses the merits of giving the patient control over how they are identified and how their records should be shared.
Fundamental to this are the two approaches:
- A formal managed infrastructure that provides (cross-)identification and record transport services (like eHealth Exchange, formerly NwHIN), or;
- An ad hoc one that allows participants to send record information from point-to-point (ala the DIRECT or Blue Button Plus projects).
Some thoughts…
- As I discussed with a respected colleague of mine at the recent ACR Informatics Summit, I believe that new standards like the emerging DICOMweb (aka QIDO-RS, WADO-RS, STOW-RS) and HL7 FHIR will more easily enable ad hoc exchange of records, but the role of more formal application infrastructures, like those defined by IHE XDS (and its domain specific variants, like XDS-I) will still be used where a mandate for managed patient records across a consortium exists (such as in Canada with the Canada Health Infoway).
- As I mentioned in my prior post, society may have different motivations than those paying for the infrastructure and tools. This article attempts to express some of the concerns consumers may have about how their data is handled, which contrasts with the prior article’s statements about how “nobody under 30 cares about privacy”.
Article – New HIPAA rule could change BAA talks
As this article explains, the rules of accountability need to apply to all parts of the delivery chain, from the healthcare provider to the infrastructure vendor.
It is my experience that the readiness of the vendor to provide the necessary security controls (technical, policy, etc.) is usually not the issue. It is often the healthcare provider staff that lacks the knowledge of appropriate and effective controls that prevents proper security from being in place.
For example, even when proper single sign-on (SSO) methods are available in systems, rather than taking the time to implement this between systems (which often requires some learning), staff will often default back to wanting to simply pass a user ID and password (often a generic one) from one system to the next, because that was all they could do 10 years ago to avoid having the user log into multiple systems.
Article – US Military Scientists Solve the Fundamental Problem of Viral Marketing
Not really related to healthcare IT, but an interesting read. Shared by a friend.
PACS-centric vs. VNA-centric models for including imaging in the EMR
Like many problems, there are more than one valid solution. For the challenge of getting images to both diagnostic consumers (e.g. Radiologists) and clinical consumers (e.g. ordering physicians, EMR users), there are many ways to define a solution architecture, but two are most obvious: PACS-centric and VNA-centric.
PACS-centric
In this model, the PACS is the primary system, interfacing with modalities, providing a client to diagnostic users, as well as access to clinical users though an enterprise client embedded in the EMR. Mobile access may be direct or via a mobile EMR user interface, but it is getting images from the PACS. Enterprise images are captured and stored in the PACS (though storing to VNA and routing to PACS is also possible). The VNA’s role is primarily as an archive to (one or more) PACS.
VNA-centric
In this approach, the VNA is the primary image management system. The PACS likely still interfaces with modalities (though not always), but captured enterprise images are stored to the VNA, and sent to the PACS when needed/supported. Clinical viewing in the EMR is done by an Enterprise Viewer, which may or may not be provided by the VNA vendor. Mobile access is also through the Enterprise viewer, getting images from the VNA.
Pros and Cons
As stated, both are valid approaches, but each has some inherent strengths and challenges.
The PACS-centric solution has a high likelihood of having all parts of the medical imaging record being available in both diagnostic and enterprise viewers. Proprietary data (e.g. markups and key images) not provided through standard data objects (e.g. DICOM GSPS and KOS) are more likely to be visible in all clients. There may also be some common application configuration settings across clients, which would reduce administration complexity and cost. Getting the image management and image viewing (diagnostic and enterprise client) all working together is the burden of the vendor (i.e. it is an engineered solution designed to function as a single system).
The VNA-centric solution is better suited to support a multi-PACS environment, providing a common management and viewing platform for enterprise users—only the single Enterprise Viewer is embedded in the EMR (vs. the multiple ones provided by each PACS). Environments with multiple PACS and Mini-PACS benefit as the VNA is the common sharing (and data quality validation) point among them—this allows for a more “pluggable” solution where systems that address niche needs can be used until the primary PACS is able to replace them. In this model, the integration among the components is more complex and places a higher burden on the institution to get it all working (i.e. the informatics and IT staff need to be willing and able to put this together), even with purchased professional services from all the vendors involved.
Assuming both the PACS and the Enterprise Viewer support LDAP (Lightweight Directory Access Protocol) and/or SSO (Single Sign-On), user authentication may be equal in both approaches.
Both a well-designed PACS and VNA (and Enterprise Viewer) can provide effective multiple patient ID management methods (e.g. MPI or IHE Patient Identifier Cross-Referencing), to allow integration/exchange of patient imaging records across patient ID domains, though the VNA and Enterprise Viewer are traditionally more likely than PACS to support flexible models.
In both models, storage for the long term archive is expanded at the VNA.
More Post-SIIM 2013 Annual Meeting Reflections
For years, I have heard providers lament at the slowing (dormant?) pace of innovation in PACS and RIS from established vendors.
Why might this be happening?
It could be that the current architectures have reached their limits. It could be that, with the saturation of PACS in mature markets, vendors are reducing R&D investment in this area. It could be that they can’t sustain the talent needed to innovate, losing creative and skilled people to more interesting/promising areas of IT. It could be innovation-suppressing regulatory burdens. Or the shift of spending to support staff in order to sustain the now sprawling installed base.
Regardless of the root cause(s), I see the emergence of interest in start-ups (such as those in the SIIM Innovator Alley) and open source projects (as seen by the steady traffic at the SIIM Open Source Plug Fest) that attempt to solve problems that the larger vendors appear not to be interested in solving. It seems providers are starting to accept that they are not going to get everything they need from their incumbent PACS vendor in today’s EMR-enabled, Cloud-hosted, analytics-driven, enterprise-accessible market.
Of course, the challenge of the start-up is breaking into the provider’s enterprise where the incumbent vendor may put up some resistance (overtly or passively). And open source is only as good as the staff (or paid service provider) you have installing, integrating and supporting it.
The informatics skills and knowledge provided by SIIM are more important than ever. If SIIM is to continue to lead in providing its members the knowledge and skills they need to survive and succeed, it will likely have to adapt how it organizes the materials to align with new and evolving learning goals. It also needs to adapt the medium by which its members learn, providing focused, on-line options where travel policies and budgets mean attending the annual meeting is not feasible.
I believe in the SIIM strategic plan and am wholly committed to helping the society that has helped me so much over the years thrive.
Post-SIIM 2013 Annual Meeting Reflections
Another great SIIM annual meeting is behind us and it was great, as always. I am going to post some thoughts and reflections this week.
Today, I have been thinking about analytics and, in particular, the use of a workflow engine and a standardized set of terms and definitions (such as what is being defined in SWIM) to ensure analysis of workflow events (type, timing, relationships, patterns, etc.) consistently across systems.
There were several great talks by Dr. Brad Erickson and Chris Meenan and others on the topic and these were followed by a large turnout of engaged attendees for a SWIM demo (see pic below).
My thoughts…
- The use of a mature, off-the-shelf (open source or commercial) workflow engine has been considered by PACS and RIS vendors, with some attempting to use them in their product. It has not been widely adopted for two main reasons (I believe)…
- Most PACS from large vendors were bought, not built by them—the risk of replacing the built in logic with an external engine without introducing functional regression is high (read as: it would be expensive);
- Unless the workflow engine spans several systems, it would not have the full benefit (see more on this below).
- The workflow examples cited often started with the arrival of the image objects from the modality (initial event that starts the workflow channel). Ideally, the workflow engine extends to before the order is placed, managing the order placement, decision support to ensure the right procedure is ordered, scheduling, protocoloing, and acquisition, along with the reading and post-processing steps. It should also span to the results distribution and archiving, managing the timing and destinations of the report and the lifecycle of the historic imaging data.
- One of the limitations of using a parallel image management pipeline (e.g. sending images through a system before arriving in PACS) in order to detect the event that triggers the workflow can introduce some points of failure. Consider if the system integrated with the workflow engine goes down and images don’t get to the PACS—this outage would limit the value of the integrated image management and workflow engine system. A possible solution is to extend PACS and other systems, such as the RIS, EMR, CDS, VNA, Enterprise Viewer, document management system, etc. to expose the event information. This would allow the workflow engine to apply the desired workflow rules and orchestrate the data flow and work steps without being a potential bottleneck.
More thoughts from SIIM later. Stay tuned.
Article – FCC, FDA, ONC seek input on mHealth regs
I find the topic of this article interesting.
Here’s why…
- We have had notebooks and netbooks on WiFi accessing Web-based and other types of applications deemed medical devices (e.g. PACS) for years. The essential difference between a tablet and a netbook is the keyboard. They pose the same risk as a client application platform.
- If this is what regulators are worried about, wait til they get a load of the bigger billy goat coming across the bridge next …mobile apps are one thing, but what about a portal framework that aggregates patient data from distributed sources, in real-time? Imagine a screen where each discrete element of the patient record is managed in a different system. The values used to define and indicate normal and abnormal test results are from a public Web site. Where does the “medical device” start and end? Who is the “manufacturer” responsible if an issue arises? How do you manage the medical device labeling? With mobile, we are simply trying to figure out how to do what, in many cases, we do today, only now without a wire. …regulatory affairs folks are in for a world of change (or healthcare will fall ever farther behind the IT curve).
Article – Beware: The top 4 hurdles to a successful EHR implementation
Check out this article. Some fairly common observations for an IT veteran, but good advice for EHR buyers.
Some mitigation tips for each point (read the article for the 4 hurdles)…
- Build in resiliency. Evaluate options to operate using locally cached data , if supported.
- Learn ITIL, and follow the prescribed best practices. If you do, you won’t be putting in upgrades without putting it through a test plan on a test system before moving to production.
- If the EMR allows customization of “templates” (or forms), they need to be validated with the representative user communities before imposing them. Some structure, and form element input validation, is needed to ensure completeness and quality of records.
- The application and system performance needs to be considered in the overall plan. Inventorying and analyzing transaction and interaction types and volumes, and working with the vendor to spec a system that meets the need, if an important but often overlooked step. Also, assessing the EMR for ease of scalability prior to purchase is recommended.
In regards to the comments on the trade off of lost productivity vs. potential new revenue, check out this post from a month ago.
Don K Dennison 