As per the FDA press release "the diverse and rapidly developing industry of health information technology requires a thoughtful, flexible approach,” said HHS Secretary Kathleen Sebelius. “This proposed strategy is designed to promote innovation and provide technology to consumers and health care providers while maintaining patient safety. Innovative health IT products present tremendous potential benefits, including: greater prevention of medical errors; reductions in unnecessary tests; increased patient engagement; and faster identifications of and response to public health threats and emergencies. However, if health IT products are not designed, implemented or maintained properly, they can pose varying degrees of risk to the patients who use them. The safety of health IT relies not only on how a product is designed and developed, but on how it is customized, implemented, integrated and used"
In the days when web applications were king, this type of insight was doable with simple web analytics and similar tools. Today, continual experience optimization is much more difficult because of:
Multiple interaction channels. You must collect, correlate, and analyze data in a coherent way across multiple channels of customer interaction. A single customer interaction may cross between channels or even use more than one channel at the same time.
Many back end servers. You must integrate data from multiple back end servers including recommendation engines, commerce, mobile application servers, digital asset management, community, collaboration, messaging, and more.
The need for rapid change. You must quickly change any or all of your digital experiences and back end services based on what you’ve learned.
The need for contextual experiences. You must use each individual customer’s context to dynamically adjust experiences in real-time.
There’s a big mistake often made with business architecture — a very big mistake, yet a very subtle mistake. As you might expect, there are a number of mistakes one might make with business architecture, but there’s a particularly big and common one that multiplies its effect through all the others.
The mistake is this: To position business architecture as a new layer on top of your existing processes and structures for EA domains such as application architecture, information architecture, and infrastructure architecture.
Here’s the issue: The traditional way many organizations have pursued EA, it should have been called “enterprise technical architecture” — ETA. The central focus has been on the likes of technical standards and reference architectures for application implementation — i.e., on the technology — and not on the enterprise itself. In a phrase, ETA is “technology-centered,” leading us to odd behaviors like assuming it’s only natural that business users, product data, customer data, and the rest will be fractured and split across multiple applications. We put applications at the center and make the business gyrate and adapt around our siloed and broken applications.