Expected Outcome Data System for Healthcare Interoperability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current healthcare systems lack a standardized model for patient expected outcomes, leading to inconsistent data collection, translation, and communication across different healthcare systems, which hinders interoperability and efficient clinical practice.

Innovation Solution

A system that stores and processes patient expected outcomes using a model-driven approach with detailed attributes, enabling consistent data collection, translation, and interpretation, and providing a common reference model for decomposing expected outcomes into unambiguous and computable definitions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple clinical terminologies are used in different healthcare systems, then each system can represent its own expected outcomes, but interoperability and communication between systems becomes difficult

Engineering Contradiction:
Improveability to represent different expected outcomesVSAvoidcommunication between systems
Core Design Contradiction:
Adaptability or versatilityVSLoss of information

Solution Approach 1:

The patent introduces a common expected outcome terminology model as an intermediary layer between different healthcare systems. Each system maintains its own clinical terminology for representing expected outcomes, but all systems communicate through this shared intermediary model, enabling interoperability without requiring each system to adopt a single terminology.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The common expected outcome terminology model serves multiple functions simultaneously: it acts as a shared vocabulary for communication, provides a framework for mapping different terminologies, and enables consistent data exchange across diverse healthcare systems while preserving each system's unique clinical capabilities.

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

2Adaptability or versatility

If free text expected outcomes are used, then each system can document its own outcomes, but mapping and translating between systems is not possible

Engineering Contradiction:
Improvedocumentation flexibilityVSAvoidtranslation accuracy
Core Design Contradiction:
Adaptability or versatilityVSMeasurement precision

Solution Approach 1:

The patent segments expected outcome documentation into two parts: free text descriptions that preserve documentation flexibility and precision, and structured expected outcome attributes that enable machine processing and translation. This segmentation allows each component to serve its optimal function while working together.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system transforms free text expected outcome descriptions into structured parameter representations by extracting and mapping them to standardized expected outcome attributes. This parameter transformation enables precise translation and comparison across systems while preserving the original free text documentation for human review.

Inventive Principle:
Principle #35Parameter changes

3Ease of manufacture

If existing clinical terminologies are used without model-driven approaches, then systems can operate with current terminologies, but decomposition into computable definitions is not possible

Engineering Contradiction:
Improvesystem implementationVSAvoidcomputable definition decomposition
Core Design Contradiction:
Ease of manufactureVSExtent of automation

Solution Approach 1:

The patent performs preliminary decomposition of expected outcome terminologies into computable attributes and relationships before they are used in clinical systems. This pre-structuring enables automated processing, reasoning, and data exchange while maintaining ease of implementation through standardized models.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system replaces manual, ad-hoc terminology mapping and decomposition processes with automated model-driven mechanisms. The standardized expected outcome model enables computers to automatically decompose, translate, and map terminologies without human intervention, significantly increasing automation extent.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

4Ease of operation

If simple text expression of expected outcomes is used, then data collection is simple, but optimization of clinical practice and aggregate outcome management is not supported

Engineering Contradiction:
Improvedata collection simplicityVSAvoidclinical practice optimization
Core Design Contradiction:
Ease of operationVSProductivity

Solution Approach 1:

The patent adds structural and semantic dimensions to expected outcome data by organizing simple text expressions into hierarchical models with attributes, relationships, and metadata. This dimensional transformation enables complex analyses, optimizations, and aggregate management while maintaining simple text-based data collection at the point of care.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS8121860B2Patient care and treatment data structure and processing system
Publication Date: 2012.02.21 CERNER INNOVATION INC
  • US8121860B2 patent drawing
  • US8121860B2 patent drawing
  • US8121860B2 patent drawing

AI summary

An expected outcome data system stores data representing a plurality of different expected outcomes of patient care and treatment for use in providing healthcare to a patient. An acquisition processor acquires data representing an expected outcome of treatment associated with a medical problem for storage in a repository. A repository, electrically coupled to the acquisition processor, includes data representing a plurality of different expected outcomes; an individual expected outcome has an expected outcome name and is characterized by expected outcome attributes; an individual expected outcome has a plurality of attribute properties determining how an expected outcome attribute is represented. Expected outcome attributes include a focus term indicating a topic of an expected outcome, an expected outcome likelihood term indicating an assessment of likelihood of the associated corresponding expected outcome, and a client term indicating at least one target person for care. The attribute properties include a format attribute property indicating a format constraint of an expected outcome attribute and a content attribute property indicating a content constraint of an expected outcome attribute. A retrieval processor, electrically coupled to the repository, retrieves data representing at least one expected outcome from the repository.