Medical Data Intermediary Server for Secure Third-Party Access

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current technologies face challenges in securely and legally sharing medical data with external parties, such as academia and the pharma industry, due to regulatory and ethical constraints, limiting access and usage for research and drug development.

Innovation Solution

A method and system that allows patients to authorize the storage and sharing of their medical data through a digital storage agreement and sharing authorization, enabling secure and controlled access by third parties while adhering to legal and regulatory requirements, using a server with multiple interfaces connected to a central database.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If medical data is shared with external parties for research and drug development, then the value and utility of medical data is improved, but legal and regulatory compliance becomes more difficult to maintain

Engineering Contradiction:
Improvedata sharing capabilityVSAvoidlegal compliance
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent introduces a trusted third-party server as an intermediary between healthcare providers and external research parties. This server acts as a mediator that receives medical data from healthcare providers with patient consent, stores it securely, and selectively shares it with external parties under controlled conditions. The intermediary maintains legal compliance by implementing authorization verification, data encryption, and access control mechanisms while enabling data sharing for research purposes.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system segments the data sharing process into distinct functional modules: data collection from healthcare providers, patient consent management, secure storage in a centralized database, authorization verification, and controlled distribution to external parties. Each segment handles specific aspects of data management, allowing the system to maintain compliance while enabling versatile data sharing. The segmentation also allows different levels of access control for different types of external users.

Inventive Principle:
Principle #1Segmentation

2Ease of operation

If patients authorize sharing of their medical data with third parties, then data accessibility for research is improved, but data security and patient privacy control become more complex

Engineering Contradiction:
Improvedata accessibilityVSAvoidauthorization management
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The system enables patients to self-manage their data sharing preferences through a user-friendly interface. Patients can independently authorize or revoke consent for data sharing with specific third parties, select which data elements to share, and control the duration of authorization. This self-service approach simplifies the process for patients while the system automatically handles the complex authorization verification and access control logic, reducing the perceived complexity for end users.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary authorization management by obtaining patient consent before any data sharing occurs. The authorization framework is established in advance, defining the scope, duration, and conditions of data sharing. This preliminary action simplifies subsequent data access operations, as the system only needs to verify pre-established authorization tokens rather than managing complex real-time consent negotiations. The preliminary setup also enables batch processing of data sharing operations.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If a centralized database stores medical data from multiple healthcare providers, then data combination and processing capability is improved, but system complexity and data management overhead increase

Engineering Contradiction:
Improvedata processing efficiencyVSAvoidsystem architecture
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The centralized server is designed with universal functionality to handle multiple types of operations: receiving data from various healthcare providers with different data formats, storing diverse medical data types in a unified database structure, managing patient authorization records, verifying third-party credentials, and distributing data to different external users. This multi-functional design consolidates what would otherwise require multiple specialized systems, reducing overall system complexity while maintaining high data processing efficiency.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system employs parameter changes in the form of configurable data structures, encryption parameters, and access control policies. The database schema can be dynamically adjusted to accommodate different types of medical data from various healthcare providers. Encryption parameters can be modified based on data sensitivity levels, and access control policies can be changed according to patient preferences and regulatory requirements. This parametric approach allows the system to adapt to different scenarios without requiring fundamental architectural changes.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP4102796A1Method, computer program product and processing circuitry for making medical data available to third parties
Publication Date: 2022.12.14 ADDI MEDICAL AB
  • EP4102796A1 patent drawingFigure 1~2
  • EP4102796A1 patent drawingFigure 3
  • EP4102796A1 patent drawing

AI summary

Medical data are made available to third parties via a server (100). The server (100) has a first interface (110) through which a digital storage agreement (R[auth]) is obtained from a terminal (UT). The digital storage agreement (R[auth]) authorizes storage of medical data (PDID) relating to a user of the terminal (UT) in a central database (140) connected to the server (100). In response to the digital storage agreement (R[auth]), a second interface (120) of the server (100) sends a first data request (RQ1) to a primary server (JS). The first data request (RQ1) causes the primary server (JS) to forward medical data (POID) relating to the user to the second interface (120). The server (100) stores the obtained medical data (POID) in the central database (140). A third interface (130) receives a data enquiry (ENQ) from a third party (DU) with a request for the medical data (POID) relating to the user stored in the central database (140). In response thereto, the server (100) checks if the user has authorized (ACC) sharing the medical data (PDID) requested in the data enquiry (ENQ) with the third party (DU). Only if the user has authorized (ACC) such sharing, the server (100) forwards a copy of the medical data (PDID) requested in the data enquiry (ENQ) to the third party (DU).