An ai required hospital data processing method and system

Abstract

This invention provides a method for processing hospital data required for AI, comprising: constructing a data registration service and providing a unified data registration interface for receiving data registration information submitted by various data providers within the hospital according to preset registration specifications; obtaining basic patient information through the basic information interface provided by the hospital's HIS system and generating a unique identifier (UID) for each patient; constructing an AI doctor data exchange terminal for receiving data requests sent by the AI ​​doctor terminal; the AI ​​doctor data exchange terminal parsing the data request, extracting the target patient's UID from the data request, and mapping the UID to the patient's original unique identifier; the AI ​​doctor data exchange terminal concurrently initiating data requests to various data sources based on the data registration information; and the AI ​​doctor data exchange terminal receiving response data returned by each data source and performing format standardization processing on the response data; thus solving the technical problems of complex multi-system data access and low data processing efficiency in existing technologies.

Description

Technical Field

[0001] This invention belongs to the field of medical data processing technology, and in particular relates to a method and system for processing hospital data required by AI. Background Technology

[0002] In existing technologies, data integration between AI systems and internal hospital systems typically involves the AI ​​system directly connecting to the application programming interfaces (APIs) of each system, with each system provider offering data interfaces according to a pre-defined format. However, this approach has several drawbacks: First, the interfaces across systems are inconsistent, and data formats are not standardized, requiring the AI ​​system to be adapted for each system, resulting in a large workload and difficult maintenance. Second, the volume of data within hospitals is enormous, and the AI ​​system directly requesting the entire dataset can easily lead to server lag, latency, or even crashes. Third, there is a lack of a unified data registration and management mechanism; adding new data sources requires redevelopment and redeployment, resulting in poor scalability. Summary of the Invention

[0003] The present invention aims to provide a method and system for processing hospital data required by AI, so as to solve the technical problems of complex data access and low data processing efficiency of multiple systems in hospitals in the prior art.

[0004] A method for processing hospital data required by AI includes the following steps: A data registration service is constructed, providing a unified data registration interface for receiving data registration information submitted by various data providers within the institute in accordance with preset registration specifications. The data registration information includes data source identifier, data interface address, data filtering parameter definition, and data access permission information. A patient information caching service is constructed. Basic patient information is obtained through the basic information interface provided by the hospital's HIS system. A unique identifier (UID) is generated for each patient, and the patient's basic information and UID are associated and stored in the hospital's caching service. A mapping relationship is established between the UID and the patient's original unique identifier in the hospital information system. An AI doctor data exchange terminal is constructed and deployed on the hospital's internal network to receive data requests sent by the AI ​​doctor terminal; the data request carries at least the UID of the target patient; The AI ​​doctor data exchange terminal parses the data request, extracts the target patient's UID from the data request, and determines the target patient's original identifier in various hospital systems based on the mapping relationship between the UID and the patient's original unique identifier. The AI ​​doctor data exchange terminal queries the data registration information related to the target patient from the data registration service based on the original identifier of the target patient, and obtains the list of data sources to be called and their corresponding data interface addresses and data filtering parameter definitions; The AI ​​doctor data exchange terminal initiates concurrent data requests to various data sources based on the data registration information. For data sources with large data volumes, the data request carries filtering parameters obtained from the data registration information, which are used to request the data source to return a filtered subset of data. The AI ​​doctor data exchange terminal receives response data returned from various data sources, performs format unification processing on the response data, and generates a structured patient data set. The AI ​​doctor data exchange terminal returns the structured patient data set to the AI ​​doctor terminal.

[0005] Furthermore, the data registration information also includes a data format description; the data filtering parameter definition includes parameter name, parameter type, and a list of optional values.

[0006] Furthermore, the patient information caching service uses a distributed cache to store basic patient information and UID mapping relationships, and establishes a reverse index from UID to the original hospital identifier.

[0007] Furthermore, the AI ​​doctor data exchange terminal uses an asynchronous, non-blocking approach to concurrently execute multiple data source requests, and merges the response data returned by each data source into a structured patient data set in a unified format through aggregation operations.

[0008] Furthermore, the data request also carries a list of data types to be acquired, and the AI ​​doctor data exchange terminal selects the corresponding data source from the data registration information based on the data type list and calls it.

[0009] Furthermore, the data access permission information includes authentication type and authentication credentials; when the AI ​​doctor data exchange terminal initiates a data request to the data source, it adds corresponding authentication information based on the authentication type and authentication credentials.

[0010] Furthermore, the format standardization process for the response data includes: determining the corresponding data formatter based on the data source identifier, and converting the raw response data into a unified format containing data entries, timestamps, and metadata.

[0011] Furthermore, the AI ​​doctor data exchange terminal controls the maximum number of concurrent requests through a semaphore mechanism and performs timeout control on data source requests according to a preset timeout period.

[0012] A hospital data processing system for AI, comprising: The data registration service module provides a unified data registration interface, receives data registration information submitted by various data providers within the institute in accordance with preset registration specifications, and stores the data registration information. The data registration information includes data source identifier, data interface address, data filtering parameter definition, and data access permission information. The patient information caching service module is used to obtain basic patient information through the basic information interface provided by the hospital's HIS system, generate a unique identifier (UID) for each patient, establish a mapping relationship between the UID and the patient's original unique identifier in the hospital information system, and store the patient's basic information and UID in the cache. The AI ​​doctor data exchange module, deployed within the hospital's internal network, includes: The request parsing unit is used to receive data requests sent by the AI ​​doctor and extract the UID of the target patient from the data requests. The registration query unit is used to query the data registration information related to the target patient from the data registration service module based on the target patient's UID, and obtain the list of data sources to be called and their corresponding data interface addresses and data filtering parameter definitions. The concurrent request unit is used to concurrently initiate data requests to various data sources based on the data registration information. For data sources with large data volumes, the data requests carry filtering parameters obtained from the data registration information. The data processing unit is used to receive response data returned from various data sources, perform format unification processing on the response data, and generate a structured patient data set. The response return unit is used to return the structured patient data set to the AI ​​doctor.

[0013] Furthermore, the concurrent request unit executes multiple data source requests concurrently in an asynchronous, non-blocking manner, and merges the response data returned by each data source into a structured patient data set in a unified format through aggregation operations.

[0014] This invention provides a method and system for processing hospital data required for AI, which solves the technical problems of complex data access from multiple hospital systems and low data processing efficiency in the prior art. Attached Figure Description

[0015] Figure 1 This is a flowchart of AI doctor data processing provided in an embodiment of the present invention; Figure 2 This is a timing diagram of AI doctor data processing provided in an embodiment of the present invention. Detailed Implementation

[0016] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of the present invention.

[0017] This invention decouples the distribution, aggregation, and formatting of data requests from the core AI doctor system by deploying an independent data exchange terminal. The data exchange terminal initiates calls to multiple data sources simultaneously using a concurrent request approach, and then uniformly formats the returned heterogeneous data before returning it to the AI ​​doctor. This architecture distributes the data processing load across independent services, avoiding performance bottlenecks caused by the AI ​​doctor system directly processing massive amounts of raw data.

[0018] like Figure 1 As shown, the AI-required hospital data processing method and system provided in this embodiment includes the following components: Data Registration Service: Deployed within the hospital's internal network, this service provides a unified data registration interface for data providers such as HIS, LIS, PACS, ultrasound systems, anesthesia systems, and consumables systems to register their data. The service maintains a registration information database, storing basic information about each data source, including interface addresses, data formats, and filtering parameter definitions.

[0019] Patient information caching service: Deployed within the hospital's internal network, it periodically synchronizes or retrieves basic patient information in real time through the basic information interface provided by the HIS system, generates a unique UID for each patient, and establishes a mapping relationship between the UID and the original identifiers of each system. The patient information caching service uses an in-memory database such as Redis for storage to provide high-performance query response.

[0020] AI Doctor Data Exchange Terminal: Deployed within the hospital's internal network, this terminal serves as a data exchange hub between the AI ​​doctor system and various data sources within the hospital. Developed in Rust, it leverages Rust's high performance and memory-safety features to handle concurrent data requests. The data exchange terminal comprises the following core modules: - Request parsing module: Responsible for receiving and parsing data requests sent by the AI ​​doctor; - Registration Query Module: Responsible for querying data source registration information from the data registration service; - Concurrent Request Module: Responsible for concurrently initiating data requests to multiple data sources; - Data processing module: responsible for standardizing the format of the returned heterogeneous data; - Response return module: Responsible for returning the processed structured data to the AI ​​doctor.

[0021] AI Doctor App: Deployed on the hospital's internal network or in the cloud, it provides doctors with AI-assisted diagnostic functions. The AI ​​Doctor App sends data requests to the data exchange terminal and receives and displays the returned patient data.

[0022] Core process implementation: The following combination Figure 1 and Figure 2The data processing flow of this embodiment will be described in detail.

[0023] Data registration phase: Each data provider within the institute submits its data registration information through the registration interface provided by the data registration service, following the pre-defined registration specifications. The registration interface is defined as follows (described using the Rust language): / / / Data filtering parameter definition #[derive(Debug, Clone, Serialize, Deserialize)] pub struct FilterParam { pub name: String, / / Parameter name, such as "number of hospitalizations" pub param_type: ParamType, / / Parameter type pub options: Vec <paramoption>, / / List of optional values } #[derive(Debug, Clone, Serialize, Deserialize)] pub enum ParamType { String, Integer, Float, Boolean, Date, } #[derive(Debug, Clone, Serialize, Deserialize)] pub struct ParamOption { pub label: String, / / Display name, such as "First Hospitalization" pub value: String, / / The actual value, such as "1" } / / / Data registration information #[derive(Debug, Clone, Serialize, Deserialize)] pub struct DataRegistration { pub source_id: String, / / Data source identifier, such as "his_inpatient_record" pub source_name: String, / / Data source name, such as "HIS Inpatient Records" pub provider: String, / / Provider, such as "HIS vendor" pub api_endpoint: String, / / API address pub api_method: String, / / Request method, such as "GET", "POST" pub data_format: String, / / Data format, such as "JSON", "XML" pub filter_params: Vec <filterparam>, / / Filter parameter definition pub auth_info: Option <authinfo>, / / Authentication information pub registered_at: DateTime <utc>, / / Registration time } #[derive(Debug, Clone, Serialize, Deserialize)] pub struct AuthInfo { pub auth_type: AuthType, pub credentials: HashMap<String, String> , } #[derive(Debug, Clone, Serialize, Deserialize)] pub enum AuthType { None, Basic, Token OAuth2, } / / / Data Registration Service pub struct RegistrationService { registry: HashMap<String, DataRegistration> , } impl RegistrationService { pub fn new() -> Self { RegistrationService { registry: HashMap::new(), } } / / / Register data source pub fn register(&mut self, registration: DataRegistration) ->Result<String, RegistrationError> { / / Verify the completeness of registration information Self::validate_registration(®istration)?; / / Generate Registration ID let registration_id = format!("reg_{}", uuid::Uuid::new_v4()); / / Store registration information self.registry.insert(registration_id.clone(), registration); Ok(registration_id) } / / / Query registration information based on data source identifier pub fn get_by_source_id(&self, source_id: &str) -> Option<&DataRegistration> { self.registry.values().find(|r| r.source_id == source_id) } / / / Verify registration information fn validate_registration(registration: &DataRegistration) ->Result<(), RegistrationError> { if registration.source_id.is_empty() { return Err(RegistrationError::InvalidSourceId); } if registration.api_endpoint.is_empty() { return Err(RegistrationError::InvalidEndpoint); } Ok(()) } } #[derive(Debug)] pub enum RegistrationError { InvalidSourceId, Invalid Endpoint } For example, an HIS system provider can register the admission record data interface in the following way: let his_registration = DataRegistration { source_id: "his_admission_record".to_string(), source_name: "HIS Admission Record".to_string(), provider: "HIS vendor".to_string(), api_endpoint: "http: / / his-service / api / v1 / admission-records".to_string(), api_method: "GET".to_string(), data_format: "JSON".to_string(), filter_params: vec![ FilterParam { name: "Number of hospitalizations".to_string(), param_type: ParamType::Integer, options: vec![ ParamOption { label: "First Hospitalization".to_string(), value:"1".to_string()}, ParamOption { label: "Second Hospitalization".to_string(), value:"2".to_string()}, ParamOption { label: "Third Hospitalization".to_string(), value:"3".to_string()}, ], }, FilterParam { name: "Time range".to_string(), param_type: ParamType::Date, options: vec![], }, ], auth_info: Some(AuthInfo { auth_type: AuthType::Token, credentials: { let mut map = HashMap::new(); map.insert("token".to_string(), "xxxx-yyyy-zzzz".to_string()); map }, }), registered_at: Utc::now(), };registration_service.register(his_registration).unwrap(); Patient information caching stage: The patient information caching service obtains basic patient information and generates a unique UID for each patient through the basic information interface provided by the HIS system. The implementation is as follows: / / / Patient Information #[derive(Debug, Clone, Serialize, Deserialize)] pub struct PatientInfo { pub uid: String, / / Globally unique identifier pub hospital_patient_id: String, / / Internal patient ID of the hospital pub name: String, / / Patient name pub gender: String, / / Gender pub birth_date: String, / / Date of birth pub id_card: Option <string>, / / ID card number pub phone: Option <string> / / Contact number pub system_mappings: HashMap<String, String> , / / System identifier mapping / / / Patient information caching service pub struct PatientCacheService { redis_client: Client, his_api_client: HisApiClient, } impl PatientCacheService { pub fn new(redis_url: &str, his_api_url: &str) -> Self { let redis_client = Client::open(redis_url).unwrap(); let his_api_client = HisApiClient::new(his_api_url); PatientCacheService { redis_client, his_api_client, } } / / / Retrieve patient information based on hospital patient ID (first retrieve from cache, then retrieve from HIS if not found in cache) pub async fn get_patient_by_hospital_id(&self, hospital_id: &str)-> Result<PatientInfo, CacheError> { let mut conn = self.redis_client.get_async_connection().await?; / / Try fetching from cache let cache_key = format!("patient:hospital:{}", hospital_id); let cached: Option <string>= conn.get(&cache_key).await?; if let Some(data) = cached { let patient: PatientInfo = serde_json::from_str(&data)?; return Ok(patient); } / / If the cache does not exist, retrieve it from HIS. let patient = self.fetch_from_his(hospital_id).await?; / / Store in cache (expiration time set to 1 hour) let patient_json = serde_json::to_string(&patient)?; conn.set_ex(&cache_key, patient_json, 3600).await?; / / Simultaneously create a reverse index from UID to hospital ID let uid_key = format!("patient:uid:{}", patient.uid); conn.set_ex(uid_key, hospital_id, 3600).await?; Ok (patient) } / / / Retrieve patient information based on UID pub async fn get_patient_by_uid(&self, uid: &str) -> Result<PatientInfo, CacheError> { let mut conn = self.redis_client.get_async_connection().await?; / / Obtain the hospital ID via UID let uid_key = format!("patient:uid:{}", uid); let hospital_id: Option <string>= conn.get(&uid_key).await?; match hospital_id { Some(id) => self.get_patient_by_hospital_id(&id).await, None => Err(CacheError::PatientNotFound), } } / / / Fetch patient information from the HIS system async fn fetch_from_his(&self, hospital_id: &str) -> Result<PatientInfo, CacheError> { let patient_data = self.his_api_client.get_patient_info(hospital_id).await?; / / Generate a global UID let uid = format!("uid_{}", uuid::Uuid::new_v4()); / / Build the mapping of system identifiers let mut system_mappings = HashMap::new(); system_mappings.insert("his".to_string(), hospital_id.to_string()); Ok(PatientInfo { uid, hospital_patient_id: hospital_id.to_string(), name: patient_data.name, gender: patient_data.gender, birth_date: patient_data.birth_date, id_card: patient_data.id_card, phone: patient_data.phone, system_mappings, }) } } / / / HIS API client pub struct HisApiClient { base_url: String, client: reqwest::Client, } impl HisApiClient { pub fn new(base_url: &str) -> Self { HisApiClient { base_url: base_url.to_string(), client: reqwest::Client::new(), } } pub async fn get_patient_info(&self, hospital_id: &str) -> Result<HisPatientData, CacheError> { let url = format!("{} / api / patients / {}", self.base_url,hospital_id); let response = self.client.get(&url).send().await?; if response.status().is_success() { let data = response.json().await?; Ok(data) } else { Err(CacheError::HisApiError) } } } #[derive(Debug, Deserialize)] pub struct HisPatientData { pub name: String, pub gender: String, pub birth_date: String, pub id_card: Option <string>, pub phone: Option <string>, } Data exchange implementation: The AI ​​doctor data exchange terminal is the core component of this invention, responsible for receiving requests from the AI ​​doctor terminal, querying registration information, concurrently calling various data sources, and processing the returned data. Implementation is as follows: / / / Data exchange configuration #[derive(Debug, Clone)] pub struct DataExchangeConfig { pub listen_addr: String, / / Listening address pub max_concurrent_requests: usize, / / Maximum number of concurrent requests pub request_timeout_secs: u64, / / Request timeout pub registration_service_url: String, / / Registration service address pub patient_cache_service_url: String, / / Patient cache service address } / / / Data request for AI doctor #[derive(Debug, Deserialize)] pub struct AiDoctorRequest { pub patient_uid: String, / / Patient UID pub data_types: Option <Vec <string>>, / / The required data type; empty indicates retrieving all. pub filters: Option <HashMap<String, Value> >, / / Filter criteria pub request_id: String, / / Request ID, used for tracking } / / / Data source invocation task pub struct DataSourceTask { pub source_id: String, pub api_endpoint: String, pub patient_id: String, pub filters: HashMap<String, Value> , pub auth_info: Option <authinfo>, } / / / AI Doctor Data Exchange Terminal pub struct DataExchangeServer { config: DataExchangeConfig, http_client: reqwest::Client, registration_client: RegistrationApiClient, patient_cache_client: PatientCacheApiClient, semaphore: Arc <semaphore>, } impl DataExchangeServer { pub fn new(config: DataExchangeConfig) -> Self { let http_client = reqwest::Client::builder() .timeout(std::time::Duration::from_secs(config.request_timeout_secs)) .build() .unwrap(); let registration_client = RegistrationApiClient::new(&config.registration_service_url); let patient_cache_client = PatientCacheApiClient::new(&config.patient_cache_service_url); let semaphore = Arc::new(Semaphore::new(config.max_concurrent_requests)); DataExchangeServer { config, http_client, registration_client, patient_cache_client, semaphore, } } / / / Start the service pub async fn run(&self) -> Result<(), Box<dyn std::error::Error>>{ let app = axum::Router::new() .route(" / api / data-exchange", axum::routing::post(self.handle_request)) .with_state(self.clone()); info!("Data exchange client started, listening address: {}", self.config.listen_addr); axum::Server::bind(&self.config.listen_addr.parse()?) .serve(app.into_make_service()) .await?; Ok(()) } / / / Handle AI doctor requests async fn handle_request( State(state): State <dataexchangeserver>, Json(request): Json <aidoctorrequest>, ) -> impl axum::response::IntoResponse { info!("Request received: request_id={}, patient_uid={}",request.request_id, request.patient_uid); / / Acquire semaphores to control concurrency let _permit = state.semaphore.clone().acquire_owned().await.unwrap(); / / Handle the request match state.process_patient_data(request).await { Ok(data) => { info!("Request processed successfully: request_id={}", data.request_id); (axum::http::StatusCode::OK, Json(serde_json::json!({ "status": "success", "data": data }))) }, Err(e) => { error!("Request processing failed: {}", e); (axum::http::StatusCode::INTERNAL_SERVER_ERROR, Json(serde_json::json!({ "status": "error", "message": e.to_string() }))) } } } / / / Handle patient data requests async fn process_patient_data(&self, request: AiDoctorRequest) ->Result<ProcessedPatientData, ExchangeError> { / / 1. Retrieve patient information based on UID let patient_info = self.patient_cache_client.get_patient_by_uid(&request.patient_uid).await?; / / 2. Query patient-related data registration information / / Determine the data source to be queried based on patient information let data_sources = self.determine_data_sources(&patient_info,request.data_types.as_ref())?; / / 3. Construct concurrent tasks let mut tasks = Vec::new(); for source in data_sources { / / Retrieve data source details from the registration service let registration = self.registration_client.get_registration(&source).await?; / / Constructing filter parameters let mut filters = HashMap::new(); if let Some(req_filters) = &request.filters { filters.extend(req_filters.clone()); } / / Add patient identifier if let Some(patient_id) = patient_info.system_mappings.get(&source) { filters.insert("patient_id".to_string(), Value::String(patient_id.clone())); } / / Create task let task = DataSourceTask { source_id: source, api_endpoint: registration.api_endpoint, patient_id: patient_info.hospital_patient_id.clone(), filters auth_info: registration.auth_info, }; tasks.push(self.execute_data_source_task(task)); } / / 4. Execute all tasks concurrently let results = join_all(tasks).await; / / 5. Processing results, formatted uniformly let mut unified_data = UnifiedPatientData::new(&patient_info); for result in results { match result { Ok(data) => unified_data.add_source_data(data), Err(e) => warn!("Data source request failed: {}", e), } } Ok(ProcessedPatientData { request_id: request.request_id, patient_uid: request.patient_uid, data: unified_data, processed_at: chrono::Utc::now(), }) } / / / Execute a single data source task async fn execute_data_source_task(&self, task: DataSourceTask) ->Result<DataSourceResponse, ExchangeError> { / / Build request let mut request_builder = self.http_client.get(&task.api_endpoint); / / Add authentication information if let Some(auth) = task.auth_info { request_builder = match auth.auth_type { AuthType::Basic => { / / Add Basic certification request_builder }, AuthType::Token => { if let Some(token) = auth.credentials.get("token") { request_builder.bearer_auth(token) } else { request_builder } }, _ => request_builder, }; } / / Add filter parameters as query parameters request_builder = request_builder.query(&task.filters); / / Send request let response = request_builder.send().await?; if response.status().is_success() { let data: Value = response.json().await?; Ok(DataSourceResponse { source_id: task.source_id, data, }) } else { Err(ExchangeError::DataSourceError(task.source_id)) } } / / / Determine the data sources to be queried fn determine_data_sources(&self, patient_info: &PatientInfo,data_types: Option<&Vec <string>>) -> Result<Vec <string>ExchangeError> { / / Determine the data source to be queried based on the patient information and the data type of the request. / / This allows for intelligent judgment based on business rules. let all_sources = vec![ "his_admission_record".to_string(), "his_discharge_summary".to_string(), "lis_lab_results".to_string(), "pacs_imaging_report".to_string(), "ultrasound_report".to_string(), "anesthesia_record".to_string(), "consumables_record".to_string(), ]; match data_types { Some(types) => { / / Filter out the data source corresponding to the data type of the request. Ok(all_sources.into_iter() .filter(|s| types.contains(s)) .collect()) }, None => Ok(all_sources), / / If not specified, retrieves all sources. } } } / / / Processed patient data #[derive(Debug, Serialize)] pub struct ProcessedPatientData { pub request_id: String, pub patient_uid: String, pub data: UnifiedPatientData, pub processed_at: chrono::DateTime <chrono::utc>, } / / / Unified format patient data #[derive(Debug, Serialize)] pub struct UnifiedPatientData { pub patient_info: PatientInfo, pub sources: HashMap<String, SourceData>, } impl UnifiedPatientData { pub fn new(patient_info: &PatientInfo) -> Self { UnifiedPatientData { patient_info: patient_info.clone(), sources: HashMap::new(), } } pub fn add_source_data(&mut self, response: DataSourceResponse) { self.sources.insert(response.source_id, SourceData { data: response.data, retrieved_at: chrono::Utc::now(), }); } } #[derive(Debug, Serialize)] pub struct SourceData { pub data: Value, pub retrieved_at: chrono::DateTime <chrono::utc>, } pub struct DataSourceResponse { pub source_id: String, pub data: Value, } Data requests with filtering parameters: For data sources with large volumes of data, this invention supports including filtering parameters in the data request, requesting the data source to return a filtered subset of data. The implementation is as follows: / / / Example of a data request with filtering parameters pub async fn request_with_filters( data_exchange: &DataExchangeServer, patient_uid: &str, source_id: &str, filters: HashMap<String, Value> , ) -> Result<Value, ExchangeError> { / / Build request let request = AiDoctorRequest { patient_uid: patient_uid.to_string(), data_types: Some(vec![source_id.to_string()]), filters: Some(filters), request_id: uuid::Uuid::new_v4().to_string(), }; / / Send request to data exchange end let client = reqwest::Client::new(); let response = client.post("http: / / localhost:8080 / api / data-exchange") .json(&request) .send() .await?; if response.status().is_success() { let result: Value = response.json().await?; Ok(result) } else { Err(ExchangeError::DataSourceError(source_id.to_string())) } } / / / Example usage: Get data for the patient's first hospitalization pub async fn get_first_admission_data(patient_uid: &str) -> Result<Value, ExchangeError> { let mut filters = HashMap::new(); filters.insert("admission_count".to_string(), Value::String("1".to_string())); let data_exchange = DataExchangeServer::new(DataExchangeConfig { listen_addr: "127.0.0.1:8080".to_string(), max_concurrent_requests: 10, request_timeout_secs: 30, registration_service_url: "http: / / registration-service:8081".to_string(), patient_cache_service_url: "http: / / patient-cache:8082".to_string(), }); request_with_filters(&data_exchange, patient_uid, "his_admission_record", filters).await } Data uniform formatting After the data exchange terminal obtains data from various data sources, it needs to undergo format standardization processing so that the AI ​​doctor terminal can parse and use the data in a unified format. The implementation is as follows: / / / Data Formatter pub trait DataFormatter { fn format(&self, source_id: &str, raw_data: Value) -> Result<FormattedData, FormatError> ; } / / / Formatted data #[derive(Debug, Clone, Serialize)] pub struct FormattedData { pub source_id: String, pub data_type: String, pub entries: Vec <dataentry>, pub metadata: FormatMetadata, } #[derive(Debug, Clone, Serialize)] pub struct DataEntry { pub id: String, pub timestamp: Option<chrono::DateTime <chrono::utc>>, pub fields: HashMap<String, Value>, } #[derive(Debug, Clone, Serialize)] pub struct FormatMetadata { pub format_version: String, pub formatted_at: chrono::DateTime <chrono::utc>, pub original_format: String, } / / / JSON data formatter pub struct JsonFormatter; impl DataFormatter for JsonFormatter { fn format(&self, source_id: &str, raw_data: Value) -> Result<FormattedData, FormatError> { / / Convert raw JSON data to a unified format / / Different conversion logic is needed here depending on the different data sources. let mut entries = Vec::new(); / / Assume the original data is an array if let Some(array) = raw_data.as_array() { for item in array { let entry = DataEntry { id: item.get("id") .and_then(|v| v.as_str()) .unwrap_or("") .to_string(), timestamp: item.get("timestamp") .and_then(|v| v.as_str()) .and_then(|s| chrono::DateTime::parse_from_rfc3339(s).ok()) .map(|dt| dt.with_timezone(&chrono::Utc)), fields: item.as_object() .map(|obj| obj.iter() .map(|(k, v)| (k.clone(), v.clone())) .collect()) .unwrap_or_else(HashMap::new), }; entries.push(entry); } } Ok(FormattedData { source_id: source_id.to_string(), data_type: Self::infer_data_type(source_id), entries, metadata: FormatMetadata { format_version: "1.0".to_string(), formatted_at: chrono::Utc::now(), original_format: "JSON".to_string(), }, }) } } impl JsonFormatter { fn infer_data_type(source_id: &str) -> String { match source_id { s if s.contains("admission") => "admission_record".to_string(), s if s.contains("lab") => "lab_result".to_string(), s if s.contains("pacs") => "imaging_report".to_string(), s if s.contains("ultrasound") => "ultrasound_report".to_string(), _ => "general_data".to_string(), } } } / / / Formatting in the data exchange terminal impl DataExchangeServer { async fn format_source_data(&self, responses: Vec <datasourceresponse>) -> Result<UnifiedPatientData, ExchangeError> { let mut unified_data = UnifiedPatientData::new(&PatientInfo::default()); for response in responses { / / Select the appropriate formatter based on the data source let formatter: Box<dyn DataFormatter> = match response.source_id.as_str() { s if s.contains("his") => Box::new(JsonFormatter), s if s.contains("lis") => Box::new(JsonFormatter), s if s.contains("pacs") => Box::new(JsonFormatter), _ => Box::new(JsonFormatter), }; match formatter.format(&response.source_id, response.data) { Ok(formatted) => { unified_data.add_formatted_data(formatted); }, Err(e) => { warn!("Formatting failed: source_id={}, error={}", response.source_id, e); } } } Ok(unified_data) } } impl UnifiedPatientData { pub fn add_formatted_data(&mut self, formatted: FormattedData) { self.sources.insert(formatted.source_id.clone(), SourceData { data: serde_json::to_value(formatted).unwrap_or(Value::Null), retrieved_at: chrono::Utc::now(), }); } } This embodiment also provides a hospital data processing system required for AI, including: The data registration service module provides a unified data registration interface, receives data registration information submitted by various data providers within the institute in accordance with preset registration specifications, and stores the data registration information. The data registration information includes data source identifier, data interface address, data filtering parameter definition, and data access permission information. The patient information caching service module is used to obtain basic patient information through the basic information interface provided by the hospital's HIS system, generate a unique identifier (UID) for each patient, establish a mapping relationship between the UID and the patient's original unique identifier in the hospital information system, and store the patient's basic information and UID in the cache. The AI ​​doctor data exchange module, deployed within the hospital's internal network, includes: The request parsing unit is used to receive data requests sent by the AI ​​doctor and extract the UID of the target patient from the data requests. The registration query unit is used to query the data registration information related to the target patient from the data registration service module based on the target patient's UID, and obtain the list of data sources to be called and their corresponding data interface addresses and data filtering parameter definitions. The concurrent request unit is used to concurrently initiate data requests to various data sources based on the data registration information. For data sources with large data volumes, the data requests carry filtering parameters obtained from the data registration information. The concurrent request unit executes multiple data source requests concurrently in an asynchronous non-blocking manner and merges the response data returned by each data source into a structured patient data set with a unified format through aggregation operations. The data processing unit is used to receive response data returned from various data sources, perform format unification processing on the response data, and generate a structured patient data set. The response return unit is used to return the structured patient data set to the AI ​​doctor.

[0024] This invention provides a method and system for processing hospital data required for AI, which solves the technical problems of complex data access from multiple hospital systems and low data processing efficiency in the prior art.

[0025] The above description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.< / datasourceresponse> < / chrono::utc> < / chrono::utc> < / dataentry> < / chrono::utc> < / chrono::utc> < / string> < / string> < / aidoctorrequest> < / dataexchangeserver> < / semaphore> < / authinfo> < / string> < / string> < / string> < / string> < / string> < / string> < / string> < / utc> < / authinfo> < / filterparam> < / paramoption>

Claims

1. An AI-required hospital data processing method, characterized by, Includes the following steps: A data registration service is constructed, providing a unified data registration interface for receiving data registration information submitted by various data providers within the institute in accordance with preset registration specifications. The data registration information includes data source identifier, data interface address, data filtering parameter definition, and data access permission information. A patient information caching service is constructed. Basic patient information is obtained through the basic information interface provided by the hospital's HIS system. A unique identifier (UID) is generated for each patient, and the patient's basic information and UID are associated and stored in the hospital's caching service. A mapping relationship is established between the UID and the patient's original unique identifier in the hospital information system. An AI doctor data exchange terminal is constructed and deployed on the hospital's internal network to receive data requests sent by the AI ​​doctor terminal; the data request carries at least the UID of the target patient; The AI ​​doctor data exchange terminal parses the data request, extracts the target patient's UID from the data request, and determines the target patient's original identifier in various hospital systems based on the mapping relationship between the UID and the patient's original unique identifier. The AI ​​doctor data exchange terminal queries the data registration information related to the target patient from the data registration service based on the original identifier of the target patient, and obtains the list of data sources to be called and their corresponding data interface addresses and data filtering parameter definitions; The AI ​​doctor data exchange terminal initiates concurrent data requests to various data sources based on the data registration information. For data sources with large data volumes, the data request carries filtering parameters obtained from the data registration information, which are used to request the data source to return a filtered subset of data. The AI ​​doctor data exchange terminal receives response data returned from various data sources, performs format unification processing on the response data, and generates a structured patient data set. The AI ​​doctor data exchange terminal returns the structured patient data set to the AI ​​doctor terminal.

2. The hospital data processing method for AI according to claim 1, characterized in that, The data registration information also includes a data format description; the data filtering parameter definition includes parameter name, parameter type, and a list of possible values.

3. The hospital data processing method for AI according to claim 1, characterized in that, The patient information caching service uses a distributed cache to store basic patient information and UID mapping relationships, and establishes a reverse index from UID to the original hospital identifier.

4. The hospital data processing method for AI according to claim 1, characterized in that, The AI ​​doctor data exchange terminal uses an asynchronous, non-blocking approach to concurrently execute multiple data source requests, and merges the response data returned by each data source into a structured patient data set in a unified format through aggregation operations.

5. The hospital data processing method for AI according to claim 1, characterized in that, The data request also carries a list of data types to be acquired, and the AI ​​doctor data exchange terminal selects the corresponding data source from the data registration information based on the data type list and calls it.

6. The hospital data processing method for AI according to claim 1, characterized in that, The data access permission information includes authentication type and authentication credentials; when the AI ​​doctor data exchange terminal initiates a data request to the data source, it adds corresponding authentication information based on the authentication type and authentication credentials.

7. The hospital data processing method for AI according to claim 1, characterized in that, The process of unifying the format of the response data includes: determining the corresponding data formatter based on the data source identifier, and converting the original response data into a unified format containing data entries, timestamps, and metadata.

8. The hospital data processing method for AI according to claim 1, characterized in that, The AI ​​doctor data exchange terminal controls the maximum number of concurrent requests through a semaphore mechanism and performs timeout control on data source requests according to a preset timeout period.

9. A hospital data processing system for AI, characterized in that, include: The data registration service module provides a unified data registration interface, receives data registration information submitted by various data providers within the institute in accordance with preset registration specifications, and stores the data registration information. The data registration information includes data source identifier, data interface address, data filtering parameter definition, and data access permission information. The patient information caching service module is used to obtain basic patient information through the basic information interface provided by the hospital's HIS system, generate a unique identifier (UID) for each patient, establish a mapping relationship between the UID and the patient's original unique identifier in the hospital information system, and store the patient's basic information and UID in the cache. The AI ​​doctor data exchange module, deployed within the hospital's internal network, includes: The request parsing unit is used to receive data requests sent by the AI ​​doctor and extract the UID of the target patient from the data requests. The registration query unit is used to query the data registration information related to the target patient from the data registration service module based on the target patient's UID, and obtain the list of data sources to be called and their corresponding data interface addresses and data filtering parameter definitions. The concurrent request unit is used to concurrently initiate data requests to various data sources based on the data registration information. For data sources with large data volumes, the data requests carry filtering parameters obtained from the data registration information. The data processing unit is used to receive response data returned from various data sources, perform format unification processing on the response data, and generate a structured patient data set. The response return unit is used to return the structured patient data set to the AI ​​doctor.

10. The hospital data processing system required for AI according to claim 9, characterized in that, The concurrent request unit executes multiple data source requests concurrently in an asynchronous, non-blocking manner, and merges the response data returned by each data source into a structured patient data set in a unified format through an aggregation operation.

Images