PDMS (Patient Data Management System): What you should consider from a regulatory perspective

PDMS stands for patient data management system. These clinical information systems are typically used in hospitals, especially in departments that treat patients in intensive care.

PMDS are experiencing a new boom in Germany as a result of the funding provided by the Hospital Future Act (Krankenhaus-Zukunftsgesetz, KHZG).

This article provides

• an overview of PDMS,
• a regulatory classification (e.g., qualification as a medical device),
• and assistance for risk management.

1. PMDS: Functionalities and requirements

Patient data management systems (PDMS) must fulfill many requirements and offer many functions:

• data collection and integration
• patient monitoring
• clinical decision support
• reporting and analysis

On the one hand, PDMS have the functionalities of a “normal” clinical workstation, such as managing patient master data, medical histories, diagnoses, findings (e.g. laboratory), medication and other therapies.

On the other hand, they are characterized by close integration with medical technology: They record data from patient monitors (e.g. blood pressure, pulse, oxygen saturation) and also from ventilators.

1.1 Data collection and integration

A PDMS must be able to collect and integrate patient data from various sources, such as patient monitors, ventilators, electronic health records (EHR), laboratory information systems, radiology information systems (RIS), and other clinical systems.

This data often includes patient demographics, medical history, test results, imaging studies, and medication information, as well as “device data” from, e.g., ventilators.

1.2 Patient monitoring

A PDMS should provide real-time patient monitoring to detect changes in the patient's condition and alert caregivers. This includes monitoring vital signs, medication, ventilation, and other parameters specific to the patient's health.

1.3 Clinical decision support

Users expect a PDMS to support them in making clinical decisions. These are

• decisions about the type of patient care,
• warning of drug interactions,
• monitoring of fluid balance,
• help with dosage calculation,
• diagnostic recommendations, and
• prioritizing patients.

1.4 Reporting and analysis

Advanced reporting and analysis functionality is common with PDMS. This helps hospitals with

• billing (the type and duration of ventilation, in particular, have a major impact on remuneration),
• evaluation of patient outcomes,
• tracking key performance indicators, and
• identifying areas for improvement.

Many PDMS help generate reports on

• patient demographic data,
• clinical outputs and issues, and
• financial performance, including opportunities for billing improvement.

2. Regulatory classification

2.1 Qualification of PDMS as medical devices

2.1.1 PDMS as a documentation system

Clinical information systems used exclusively for documentation (as many manufacturers claim for their hospital information systems) do not fall under the definition of “medical device.”

A system only becomes a medical device if it is used for the treatment or diagnosis of diseases and injuries or for monitoring physiological parameters.

Although many PDMS allow the monitoring of physiological parameters, some manufacturers argue that these records are for documentation purposes only.

2.1.2 PDMS as a medical device

However, if the intended purpose includes calculations, e.g., concerning the patient's fluid balance or the interaction or contraindications of medication, it can no longer be denied that the PDMS is used for therapy. Alarm functions are also likely to serve this purpose.

The PDMS is, therefore, a medical device (usually a class IIa or IIb device) that must be developed and operated in accordance with the legal requirements.

2.2 Regulatory requirements for PDMS in Europe

This is why most PDMS now count as medical devices. Consequently, manufacturers must fulfill and demonstrate compliance with the General Safety and Performance Requirements (GSPR). The EU Medical Device Regulation MDR determines GSPRs in Annex I, among others:

• software life cycle processes (IEC 62304)
• risk management (ISO 14971) (see below)
• IT security lifecycle processes (IEC 81001-5-1)
• usability engineering (IEC 62366-1)
• QM system (ISO 13485)

In addition, PDMS operators are subject to data protection requirements (e.g., requirements of the GDPR). These can only be fulfilled if the manufacturers of PDMS create the technical prerequisites for this, including the option to delete specific data.

2.3 Regulatory requirements for PDMS in the USA

Since the 21st Century Cures Act, many software applications no longer count as medical devices. The FDA has published a guidance document that addresses the characteristics and classifications of data acquisition systems in hospitals. These include Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices.

The rules for qualifying medical devices differ in Europe and the USA. However, the FDA's requirements for medical devices (if they are qualified as such) are comparable to the requirements of the MDR. It is, therefore, advisable to prepare the approval documents for both markets together.

However, manufacturers of PDMS in the USA should consider further regulatory requirements:

1. HIPAA
   The Health Insurance Portability and Accountability Act (HIPAA) sets national standards for the privacy and safety of health data. PDMS must comply with HIPAA regulations to ensure the safety and confidentiality of patient data.
2. CMS
   The Centers for Medicare and Medicaid Services (CMS) requires hospitals to implement electronic health record systems that meet certain standards to qualify for incentive payments. PDMS must also meet these standards to qualify for CMS incentives.

3. Risk management for PDMS

The MDR requires an acceptable benefit-risk ratio. This means that PDMS manufacturers should quantify their benefits and weigh them against the risks.

3.1 Determining the benefit of a PDMS

Examples of the benefits of a PDMS are:

• Documentation using a PDMS is completer and more correct than manual documentation.
• Miscalculations and incorrect medication are less likely.
• Patients in critical condition are identified more quickly and accurately.
• The workload of medical staff is reduced.

3.2 Know typical error sources

To ensure that the benefits actually outweigh the risks, manufacturers are obliged to avoid or at least minimize typical errors.

Examples of these errors are

• software bugs, e.g., in the implementation of algorithms
• interoperability problems: For example, data is not transferred, not transferred correctly (e.g., wrong unit), or not transferred at the specified time between the PDMS and medical technology or other devices and systems. Not only the PDMS but also the other systems and devices are possible sources of error.
• incorrect configuration of the PMDS (also by the operator)
• problems with usability: for example, users do not perceive alarms, confuse patients, enter incorrect data, or misunderstand information.
• lack of IT security of the components and the design (“security by design”)

3.3 Identify and avoid hazards, risks, and harm

These errors can result in hazards, for example:

• Patients are not treated because a user has illegally not paid attention to the primary alarm of a medical device but has relied on information in the PDMS.
• Patients are incorrectly fed or supplied with fluids because, for example, the fluid balance was calculated incorrectly.
• Patients receive the wrong medication or doses because of incorrect medical documentation.
• A cyber attack causes the PDMS to fail. The PDMS is no longer adequately monitored, so necessary medical interventions are not carried out.

4. Summary and conclusion

Patient data management systems (PDMS) have become indispensable in hospitals, especially in intensive care units. Without these systems, it would be difficult for clinical staff to keep track of the flood of data generated by medical devices in particular and to monitor and treat patients adequately.

Because PDMS are almost always used to monitor and treat illnesses and injuries, they count as medical devices. Therefore, PDMS manufacturers must comply with the legal requirements for medical devices and observe other regulatory requirements.

The regulatory requirements and handling of PDMS differ only slightly from those of other SaMD (Software as a Medical Device).

However, the risks and benefits of a PDMS are specific to this product class. The risks also depend on the specific installation and the associated medical devices and software applications.

Support for manufacturers of PDMS

Consulting on the regulatory clinical strategy

When developing a PDMS, consult our experts on time for the regulatory and clinical strategy. This way, you can be sure that you

• correctly qualify, classify, and promote your device in compliance with the law,
• determine the regulatory requirements and
• meet them as quickly and easily as possible to avoid both unnecessary costs and trouble with authorities and notified bodies.

Support with the transfer of legacy devices

If your devices have been on the market for a long time, you must continuously determine and comply with the state of the art. Particularly during the transition of certificates from MDD to MDR, manufacturers would do well to check or restore the conformity of their systems with the help of a neutral outside perspective.

In many cases, existing products suffer from a defect in IT security. This is where we can help with subsequent activities such as threat modeling or penetration tests.

Help with risk management files and post-market surveillance

Risk management is the central regulatory requirement. Experience has shown that many manufacturers find it difficult to keep their documentation up to date through their own post-market surveillance. We can support you with advice and assistance by reviewing your risk management files or through our post-market surveillance services.

Inspection of the QM system and audit preparation

An internal device or system audit by our experienced auditors, who have also worked for notified bodies, helps you identify and close gaps early before an assessment by the notified body.