Simplonics

Magnify Your Possibilities

Category: Medical Devices

Wireless Design Considerations for Medical Devices

INTRODUCTION

Wireless connectivity for medical devices is no longer a long-shot dream, but an expectation from patients. Wireless devices are complex; however, with some planning, major risks can be avoided. Below we outline an introduction to the general categories and delve into specific examples. The broad categories include:

  • Intended Application
  • Intended Region of Operation
  • Medical Regulations
  • Wireless Regulations & Certifications
  • Miscellaneous Regulations
  • Additional Design Considerations
  • Manufacturing Considerations

These categories should be viewed together, since they can influence each other. We can start by asking specific questions to better understand the solution process.

INTENDED APPLICATION

The intended application includes the specific problem, proposed solution, and target population.

What is the specific problem?

What is the proposed solution?

Who is the target population?

The previous three questions help shed light on what wireless design approach is viable. Asking more questions may help increase awareness. For example, what is the technical aptitude of the target population? Must all wireless components work autonomously without user interaction? How should the user interact with the system?

INTENDED REGION OF OPERATION

What countries is the device expected to operate?

Of course, the operating country will impact the appropriate medical and wireless regulations. For example, the FDA is the regulatory body of medical devices marketed in the United States. Also, because of FCC regulations, the devices’ operating frequency ranges will be limited and, therefore, a design factor. For example, in the case of LTE CAT 1, frequency Band 2 (downlink 1960 MHz and uplink 1880 MHz) can be used in the US [1]. However, in Europe, Band 2 is not permitted, and Band 28 must be used (downlink 780.5 MHz and uplink 725.5 MHz). If the device will be operated in both regions, one could either choose bands that are common to the target locations (ex. Band 1 – downlink 2140 MHz and uplink 1950 MHz) or provide a separate software configuration that is chosen depending on the location.  The frequencies can impact the size requirements of the circuit, since lower frequencies with multiple bands tend to take more space than a single banded high frequency circuit. So, tradeoffs between the operating bands/frequency and size (as well as operating power) are ubiquitous.

What about operating device user proximity?

Specific health guidelines also include safe distance of the wireless device from human tissue. For example, the Specific Absorption Rate (SAR) measures the rate at which RF energy is absorbed by the body. SAR testing uses models of the human body that are filled with liquids to simulate human tissue RF absorption [2]. For the frequency bands of interest, the SAR values are tested at the most severe (not necessarily typical) operating conditions. Therefore, in some cases, the SAR value may pertain to a position or direction that is seldomly used.

MEDICAL REGULATIONS

Considering the medical regulations as a whole package helps ensure nothing is missed in the early product development phases. Some regulations include:

StandardTitle
ISO 13485Medical devices – Quality management systems
ISO 14971Application of risk management to medical devices
IEC 60601Medical electrical equipment requirements
IEC 62304Medical device software – software life cycle processes

Ensuring that adequate medical device quality standard processes (ISO 13485) are in place prior to development is key. In terms of risk management (ISO 14971), identifying, documenting, and mitigating risks is paramount. So, addressing any Specific Absorbance Rate (SAR) concerns for wireless products is an example risk captured in the risk management process. Additionally, understanding how IEC 60601 requirements would impact the wireless design is essential. For example, if an audible alarm is required for IEC 60601 to warm of an imminent failure, must that capture any failures associated with the wireless components?  Finally, understanding how the software aspects of medical device certification in the context of the hardware component selection is important. What specific wireless functions must be certified to what specific software class level? The answer clearly depends on the consequence of the component’s failure.

As a result, all these aspects are interconnected and should be analyzed together.

WIRELESS REGULATIONS & CERTIFICATIONS

What regulatory body(s) is/are required?

The FCC is the regulatory body in the United States that specifies whether a specific device can operate at a specific frequency with a specified power level in specific directions for a designated application.

  • FCC Part 15B: Unintentional Radiator
  • FCC Part 15C-F, H: Intentional Radiator

The unintentional radiator categoryspecifies the acceptable power levels for frequencies operating between 9 KHz and 3 THz but not “intended to emit RF energy wirelessly.” [3]

This applies to, for example, an onboard microcontroller that has a CPU operating at 1 MHz. In this case, even though wireless power is not intentionally transmitted, there is still generated RF energy (due to Maxwell’s equations). The acceptable power levels in this category are generally lower than the intentional radiator part and, therefore, still require electromagnetic interference (EMI) minimization techniques.

The intentional radiator category specifies the acceptable power levels for frequencies intended to be emitted. Full certification to this category can be mitigated if using an antenna and network like one already found to be compliant; this observation, therefore, can reduce development costs.

For both categories, specific design considerations should be used to mitigate these risks. This is addressed typically in the mechanical packaging and, most importantly, the Printed Circuit Board (PCB) layout portions of the design process.

What are some additional certifications?

Additional certifications will depend on the specific use case. For example, in the case of cellular Internet of Things (IoT), the 3rd Generation Partnership Project (3GPP) standards for cellular specifies that the allowed circuit voltage must be at least a specified voltage. Also, adherence to the PCS Type Certification Review Board (PTCRB) certification may be required by various cellular carries, like Verizon. This observation is critical, since in connected care applications, maintaining compliance to suppliers’ requirements may be overlooked but result in integration risk. Of course, other certifications may be applicable depending on the application.

MISCELLANEOUS REGULATIONS

Depending on the specific application, other regulations may apply. For example, the Health Insurance Portability and Accountability Act (HIPPA) in the United States protects sensitive patient health information. Also, the General Data Protection Regulations (GDPR) are a set of compliance regulations that protects citizens of the European Union.

WIRELESS DESIGN CONSIDERATIONS

What is the approach for wireless antenna?

Choosing the topology of the antenna is not trivial and a critical system design choice; a full treatment of the subject is out of scope. Instead, several guiding principles will be mentioned. In the case of a 2.4 GHz application, most antennas follow three general approaches – 1) Wire Antenna, 2) PCB Antenna, and 3) Chip Antenna.

Antenna TypeSizeCostEfficiencyEase of Manufacturing
WireGreatestGreatestGreatestLowest
PCBMiddleLowestLowestGreatest
ChipLowestMiddleMiddleMiddle

So, if size is a constraint, a chip antenna may be best. If ease of manufacturing is important but not efficiency, a PCB antenna could be suitable. If efficiency must be optimized over all other variables, a wire antenna can be a viable option.

What is the approach for wireless antenna tuning?

Consider the following topics:

  • Ground Clearance around antenna
  • Optimal Antenna Placement
  • Antenna Feed Consideration
  • Antenna Matching network

In terms of the antenna feed consideration and antenna match network, maximizing the power delivered to the antenna by minimizing reflections is a commonly employed technique in wireless design. A common tool used in the technique by RF engineers is the Smith Chart, as shown below. Fundamentally, the impedance is measured at the frequency range of interest, plotted on the chart, and modified by using capacitors, inductors, and, in some cases, resistors. The goal is to move the impedance to the middle of the diagram (labeled “Matched Impedance”).  

Fig. 1: Simplified Smith Chart

The process of tuning is to ensure the impedance from the perspective of the integrated circuit (IC) is equal to the impedance from the perspective of the antenna and equal to the characteristic impedance of the RF trace. Otherwise, significant reflections will result in power dissipation, and therefore, significantly reduce the distance of wireless operation.

Return Loss (dB)Power Reflected %Power Delivered to Antenna %
0.0199.770.23
0.197.722.28
179.4320.57
101090
20199

As the previous table demonstrates, due to conservation of energy, the more energy that is reflected, the less useful power is delivered into the antenna, degrading the performance of the overall system. Therefore, tuning the antenna is a key element of the wireless design process.

Specifically, the following points can simplify the tuning process:

  1. Calibrate network analyzers prior to tuning.
  2. Use only high-Q components.
  3. Ensure capacitors have a series resonance at least double the operating frequency.
  4. Ensure inductors have a self-resonance at least double the operating frequency.
  5. Shunt components should be on the RF trace.
  6. Measure impedance at the same location at which components will ultimately lie.
  7. If multiple bands will be operated, tune the lower frequency band first.

Also, to help minimize the EMI emissions and simplify the PCB layout process, the following PCB layout is recommended [4]:

Fig. 2: Four Layer PCB Stackup

On the other hand, two-layer PCBs may be used in some cost-constrained applications but make the PCB routing more difficult because their characteristic impedance is directly proportional to the substrate height and would, therefore, require thicker RF traces. For completeness, an example 2-layer stackup could be considered:

Fig. 3: Two Layer PCB Stackup

ADDITIONAL DESIGN CONSIDERATIONS

What other non-wireless functions are required?

Considering the wireless function requirements in the context of the non-wireless requirements is important.

Fig. 4: Wireless & non-wireless function separation

The wireless requirements may dictate that a specific chipset with certain set of characteristics be used. But, only a subset of those specific chipsets may address the non-wireless functions as well. In the case of a medical device, a portion of the system will be used to perform some diagnostic or treatment operation. This may be performed with non-wireless components. The transmission of the data of interest (ex. breathing rate, medication status, etc.) will be performed by a wireless function component. The delineation as well as interactions between these two subsystems is a critical design choice – what is the best interface?   

What are the space requirements?

In the ideal case, the mechanical packaging is designed around the antenna, not the other way. Otherwise, compromises on the size may negatively impact system performance. Therefore, the space requirements highly impact the system design. In practice, however, there are physical constraints. The specific dimension that is constrained impacts the type of antenna that may be used.

What are the mechanical provisions?

The mechanical casing can impact the effective dielectric constant of the transmission media, from the perspective of the antenna. Ergo, understanding the mechanical casing and placing it nearby the antenna during tuning is strongly recommended.

MANUFACTURING CONSIDERATIONS

For manufacturing, there are various common categories to consider; three categories include design-for-manufacturing (DFM), part obsolescence, and manufacturing quality.

Design-for-Manufacturing considers the set of criteria to minimize product failures by maximizing the quality of the design decision process. This may include:

  • Tenting PCB vias wherever possible
  • Allowing an additional space clearance between PCB elements beyond the minimum mandated by the board manufacturer
    • An example is keeping traces as far apart as practical and keeping traces away from the edge of the board (to limit board edge oxidation).

Of course, there additional criteria beyond these examples.

Parts obsolescence is another consideration. Wherever possible, choosing electronic components with common PCB footprints and electrical properties in the event of part obsolescence reduces significant change control process rework. General part obsolescence risk mitigation can be documented as part of the company’s ISO 14971 risk management process for the project. 

Manufacturing quality can be decomposed into PCB board manufacturing and PCB assembly. Both components of the process are critical to ensuring adequate quality control.

In terms of PCB Assembly, fabrication to the IPC-A-610D Class 3 is also recommended for safety critical applications including medical devices.

Certifying to an IPC class 2 standards allow for extended life when compared to Class 1 but does not ensure uninterrupted service. If continuous operation of the wireless portion of the system is not as critical in the application, Class 2 may be possible. Furthermore, IPC-A-600 covers the PCB board manufacturing, itself. Note that there are additional standards in PCB manufacturing.

Fig. 5: IPC-A-600 & IPC-A-610 Simplified Relationship

Additionally, the manufacturing quality process must be documented consistently and integrated with the medical product quality management system, like the flow of Fig. 6.

Fig. 6: Manufacturing Quality Process

REFERENCES

[1] – Haltian Global IoT Frequency Bands E-Book

[2] – Specific Absorption Rates for Cell Phones – https://www.fcc.gov/sites/default/files/sar_for_cell_phones_-_what_it_means_for_you.pdf

[3] – FCC parts – https://www.fcc.gov/oet/ea/rfdevice

[4] – Cypress Antenna Design and RF Layout Guidelines

Tutorial: Medical Device Design with MATLAB Simulink MBSE

We will discuss an emerging system design technique that has been proven to reduce complex product development costs by 55% [1].

INTRODUCTION & WHY?

As product complexity in virtually every industry has increased exponentially, processes to design and prove device correctness have become more involved. Traditional methods for complex system design in highly regulated industries, such as medical device and aerospace products include the following (simplified) steps1:

1). Manual gathering of requirements
2). Design system and/or architecture
3). Coding and/or development
4). Validation & Verification

Typically the process outlined above is performed in what is referred to as a waterfall approach, in which each of these steps is followed sequentially and fully. Particularly, airborne software standards follow the DO-178C standard and medical software components follow the life cycle processes outlined in IEC 62304.

Suppose during step (4), (validation), a missing requirement is caught. Adding the requirement would require redesign, re-coding, re-verification, and re-validation. This is one reason highly regulated products oftentimes require greater capital investments than consumer electronics.

One seemingly obvious solution is to ensure requirements are fully correct and comprehensive in the early product development stages. In practice, achieving such a feat isn’t always realistic (especially if the product is complex) due to a gamut of reasons including limited foresight, evolving interfaces controlled by external groups, and dynamic regulatory requirements (think General Data Protection Regulation (GDPR)).

Another solution (albeit a poor choice) could be to attempt abridging certain subsets of the process. However, such an endeavor would prove to be haphazard, error-prone, and likely to reduce product quality. An alternative to the above quandary is not necessarily attempting to avoid the process but rather shortening the burden of re-running the steps through automation; Model-Based System Engineering (MBSE) is one such approach.

WHAT IS MODEL BASED SYSTEM ENGINEERING (MBE)?

MBSE is a system design technique that decomposes a system as a representation of simpler elements (via models), connects the models together, and continues to represent complex models in terms of smaller ones. The following terms make up a “system,” as [2] excellently defines:

  • Entity are components that make up a system
  • Attributes are characteristics of entities, like temperature or volume
  • Relationships are associations between attributes and entities based on causality

The key observation is that a system can be broken down hierarchically. So starting with the highest level of abstraction, the top level (system) is designed first and broken into its elements, namely subsystems. The process is repeatedly performed until the lowest level is sufficiently simple and therefore requires no additional decomposition. The definitions of these levels (in progressively greater granularity) are as follow:

  • System
  • Sub-systems
  • Assemblies
  • Sub-assemblies
  • Parts
Fig.1: System Decomposition

HOW TO PUT MBSE INTO PRACTICE?

We can follow a process similar to the formal System Analysis and Design Technique (SADT). Classically, engineers and scientists use these methods by drawing and breaking down the system on a whiteboard or a piece of paper. However, with advances in computer-aided (CAD) modeling, system decomposition can be performed on a computer, using tools, such as CAMEO or MATLAB Simulink. After the design phase is completed, the model is verified, and the code is automatically generated. So, the burden of writing software is significantly reduced.

Consider the impact in time savings. Instead of having to create a 1 million-line program, the vast majority of the coding could be automated. The savings is further underscored when feature enhancements are considered in the development cycle (typically via a change control process). Therefore, effort impacts from required changes are greatly reduced. Faster product cycles (weeks instead of years) becomes possible.

REQUIREMENTS ANALYSIS & GATHERING

For the purposes of this tutorial, we’ll use MATLAB Simulink to design part of a mechanical ventilator medical device. When we start with a medical product, generally we gather product requirements, which include regulatory guidelines. IEC 60601 generally provides additional guidance, such as a required medical device’s alarm volume in decibels and expected operating modes. For this exercise, we will specify a simplified set of requirements, as shown in Fig. 2.

Fig. 2: Requirements Subset

With Simulink modeling, the requirements in Fig. 2 can be linked to the model itself, with the following steps accompanying Fig. 3:

  1. Open the requirements document in word and highlight the requirements text
  2. Right-click a specific Simulink block
  3. Select Requirements
  4. Select Link to Selection in Word
Fig. 3: Linking Requirements to Model

Fig. 4 shows how to ensure the requirement mapping is successful.

Fig. 4: Linked Requirements to Model

DESIGN INTERFACES & HIGH LEVEL

Let us breaking our system in three main components:

  1. User Input (Pre)Processor
  2. Tube & Patient Lung
  3. Ventilator
    • Alarm Subsystem
    • Control Micro-controller Unit (MCU) Subsystem
    • Pneumatic Subsystem
      • Sensors
    • Pneumatic Controller

The Ventilator will take user input from the (pre)processor/panel and accordingly adjust the output airflow (for example) to the patient. Inside the ventilator, there is a primary control MCU that controls the Pneumatic Controller, which drives the Pneumatic subsystems (which, in turn, includes sensors and pneumatic components). The alarm subsystem will make a noise and visual indicator if certain fault conditions, such as power loss, are detected.

Consistent with the above, the Simulink Model Browser shows the following:

Fig.5: System Decomposition

At the highest level, we design the following interface and major entities comprising the system.

Fig.6: High-level Block Diagram & User Interface Simulation

DESIGN LOW LEVELS

Next, we will dig into the yellow box of Fig. 6 and create a Control Logic MCU, Alarm Subsystem, Pneumatic Subsystem, and Pneumatic Controller.

Fig. 7: 2nd Level Decomposition

We continually decompose the system until the constituent parts are sufficiently simple and thus no longer divisible. Additionally, the primary control logic implementing the requirements of Fig. 2 is shown in Fig. 8.

Fig. 8: 3rd Level Decomposition – Control Sequence of MCU

For tutorial succinctness, we’ll stop at the third level.

SIMULATION RESULTS

Of course, testing the model is paramount. Testing phases before and after automatic code generation are commonly employed. For now, we will test the model itself. As shown in Fig. 9, the system was able to detect fault conditions when the ventilator was turned off abruptly during ventilation mode (shown visually with the red alarm indicator when the system ON input turned red as well).

Fig. 9: User Turns Machine off during Patient Ventilator – Fault Detected

By running the simulation while the state machine window is open, the control logic’s state machine can be debugged using Simulink’s Stateflow. The Blue boxes represent the current state machine’s state.

Fig. 10: Video Debugging & simulation of state machine

For specific plots pertaining to the patient’s flow, pressure, and volume, Fig. 11 shows the simulated readings from the ventilator’s sensors.

Fig. 11: Image of MBSE-designed Ventilator Patient Simulation

And, we conclude testing with a video showing the readings in live-action.

Fig. 12: Video of MBSE-designed Ventilator Patient Simulation

AUTOMATIC C/C++ CODE GENERATION

As mentioned, a prodigious added benefit of MBSE is automatic code generation, which has saved significant product development costs by ~55% [1]. Code generation is an excellent topic for a future blog article.

NEXT STEPS & ENHANCEMENTS

Verification (and coverage) should be performed as well. An example test includes mathematically integrating the output flow every cycle to ensure the tidal volume is truly delivered to the patient within an error margin. An assertion can be tied to this specific condition for every breathing cycle (often referred in computer science as an invariant).

FOOTER COMMENTARY

1 Implementing a commercial product generally requires several additional steps, such as design reviews. In the context of medical products, risk management processes and quality management processes, for example, need to be in place before, during, and after the product development process. ISO 14971 and ISO 13485 standards, although not directly discussed in this article, would, therefore, be required.

2 Depending on the product’s safety classification (design assurance), the MBSE elements (and the design tool itself) would need to be qualified, which means proven to be developed with a sufficiently high confidence level for meeting the product’s requirements.

REFERENCES

[1] MBE Cost Benefits (PTC)

[2] MBSE Primer

ABOUT SIMPLONICS

Simplonics is a leading electronics design consulting and a supplier firm for companies across the United States in highly regulated industries, including medical devices. Our common services include electrical hardware design, software development, and sensor system design.

Our customers tell us horror stories about ex-vendors who delivered defective systems, resulting in safety concerns, vulnerable software, and other issues. We’ve successfully helped companies out of these situations by consistently delivering superior quality and simultaneously reducing recurring costs by more than 20%.

Are you working on a technical challenge and want a fresh perspective? Feel free to reach out by visiting the Contact Us page and submitting your contact information. Let’s build a great relationship for the future.

© Simplonics 2023