I experienced the uncertainty at the center of maternal care during the birth of my daughter. My water had broken, and an ultrasound quickly confirmed she was in the breech position. This meant I would need a Cesarean section. While the team was preparing for surgery, they lost my baby’s heart rate on the monitor. In that moment, everything narrowed to a single question: Was this a transient loss of signal or a sign of fetal distress?
That experience captures why digital transformation in healthcare differs so sharply from digital innovation in other industries. In my earlier role working on a big tech smart-home platform, software could be released, observed, and corrected through continuous updates. Because of the high stakes, these dynamics can’t translate to the med tech space.
Today, healthcare product teams must contend with three structural constraints that are far less pronounced in consumer technology: the clinical and regulatory consequences of failure, the fragmentation of healthcare data, and a vast install base of medical devices that may remain in service for a decade or more.
Risk shapes how software must be built
The first constraint is the consequence of failure. In healthcare, product teams must ask what risks need to be eliminated before software is released, whether an update will reach the correct device and whether the system will remain available when a clinician needs it. A failed update may not always create a life-threatening event, but it can leave an ultrasound system unavailable, prolong an appointment or interrupt care at a critical moment.
Quality management systems guide the controls used to mitigate those risks before software enters a clinical environment. The challenge is to apply those controls in proportion to the function of the technology and the potential consequences of failure. Software that directly guides diagnosis or treatment requires a different level of scrutiny from an administrative service, but even software outside the formal definition of a medical device can influence how care teams access information and coordinate work.
Identity and authentication services are relevant examples. Their purpose is to help make sure the right users can access the right applications and information. If authentication fails, the clinician may be locked out. If it is overly cumbersome, access to an application may be delayed.
These services must also protect patient information and prevent unauthorized access without imposing unnecessary friction on clinical work. A delay of a few seconds or minutes may appear minor when one transaction is considered in isolation. Repeated across clinicians, departments and shifts, even small delays can lead to operational strain adding to the burden of our healthcare professionals.
At GE HealthCare, we account for these realities by applying a risk-based development model, where quality controls, validation and release procedures are aligned with the clinical setting, the role of the software within that setting and the potential consequences if it fails.
Healthcare data remains fragmented
The second constraint is the fragmentation of healthcare data.
A hospital may rely on an electronic health record, a laboratory system, an imaging archive, a billing platform, staffing software and numerous specialized clinical applications. Each contains part of the information needed to understand a patient or manage the organization, yet the systems were often built by different vendors, at different times, and for different purposes.
Healthcare has data standards intended to help these systems communicate. HL7 and FHIR are used to exchange clinical and administrative information, while DICOM supports medical imaging data. However, hospitals and vendors may implement the same standard differently, meaning the same data can mean different things in the context of one hospital’s workflows versus another. Data fields can be organized in different ways, older systems may support only part of a specification, and local workflows may require custom interfaces.
This fragmentation can make both clinical review and operational coordination more difficult. After an imaging exam, the scan, report and patient history may sit in separate systems. When available together, they can support a more complete clinical review; when separated, the process can become slower, more manual, and harder to coordinate.
The same applies to operations. Patient volumes, staffing and capacity are often tracked separately, but together they can help anticipate pressure and adjust resources before delays escalate.
That is why at GE HealthCare we focus on interoperability, enabling authorized applications to access data across systems without necessarily centralizing it, so information can be used where it already resides.
Our aim is to reduce repeated integration work by establishing reusable connections that could support multiple applications, where appropriate. This reduces duplication and prepares the data for more advanced forms of analysis, including artificial intelligence. AI systems depend on information that is accessible, consistently defined, and structured well enough to support reliable conclusions. The data must still be governed, organized and delivered in a form that clinical and operational applications can use. Even sophisticated algorithms have limited value when essential information is missing, inconsistently defined or trapped in systems they cannot reach.
Medical devices remain in service for years
The third constraint is the long working life of medical devices.
Consumer technology is built around frequent replacement, with devices and software updated regularly. Medical equipment follows a much longer cycle. Hospitals make substantial capital investments in this equipment and expect it to operate safely over time, meaning digital transformation must account for the legacy devices designed before cloud services, subscriptions, and remote updates became standard.
Connectivity is essential, but it requires more than simply linking devices to a network. A layered approach can help, using edge devices or gateways to process data, enforce security, and manage communication with external services. This allows older equipment to participate in modern workflows without extensive modification.
Security must be built into this architecture. Public key infrastructure (PKI) can provide devices with digital certificates to verify identity before exchanging information, while network segmentation and controlled access policies reduce risk without compromising availability. Systems must also be resilient to real-world conditions, operating locally when connectivity is limited and synchronizing when it is restored.
Equally important is demonstrating clear value. Connectivity should enable capabilities such as remote collaboration, centralized software updates, and visibility into equipment usage and health, as appropriate. When these benefits are tangible, adoption becomes more likely.
Separating software from hardware can help extend the value of existing equipment by enabling selected new capabilities, including artificial intelligence, through software. This requires coordinated identity, licensing, and device-management systems so users can access the right tools without manual configuration.
The memory of clinicians searching for my daughter’s heart rate has stayed with me because it captures the central challenge of digital healthcare: the information needed to guide care must be available, intelligible and trustworthy at the precise moment a decision is made. For the mother in labor, the infrastructure is beside the point. However, what matters really is whether her clinicians can see what is happening, understand its significance and act with confidence when the next decision cannot wait.
