WO2011153705A1

WO2011153705A1 - An approach for unifying healthcare data and applications

Info

Publication number: WO2011153705A1
Application number: PCT/CN2010/073804
Authority: WO
Inventors: Penghai Wang
Original assignee: Shanghai Tanrui Information Co., Ltd
Priority date: 2010-06-11
Filing date: 2010-06-11
Publication date: 2011-12-15

Abstract

A new approach, Domain Operating Platform (DOP), is invented to simplify information modeling for complex application domains such as healthcare, prevent modeling-introduced data heterogeneity, and eventually eliminate information silos which widely existing in enterprises by unifying enterprise master data and business applications under a single data model. The approach comprises a dynamic modeling system, called MDT (Metadata Type) modeling, and steps for realizing a twin-engine based DOP kernel. MDT modeling comprises the methodology and steps for creating MDT models from domain concept models. The embodiment of the DOP kernel comprises the structures of MDT Modeling Engine 100 and DOP Data Engine 101 and steps to implement these two engines. The steps to fulfill a MDT based data service by DOP Data Engine 10 collaboratively working with the modeling engine are described for illustrating how the invention works.

Description

An Approach for Unifying Healthcare Data and Applications

FIELD OF THE INVENTION

The present invention titled Domain Operating Platform (DOP) relates to a software approach for unifying healthcare data as an application-independent virtual data layer, integrating heterogeneous information silos at the data layer, and building a unified application platform to facilitate healthcare industry adopting SaaS.

BACKGROUND

Since late nineties of last century, visionary information technology (IT) leaders have started to reevaluate why it is very problematic and painful when applying conventional IT technologies and solutions to large-scale, complex healthcare information systems. The problems of information silos are probably the most common challenges faced by almost each enterprise today. To date few integration solutions have been successful in eliminating widely existing information silos. Fast growing demands from healthcare enterprises or cross-enterprise health organizations for large-scale information sharing have made these problems more prominent. The United Kingdom's ambitious project for modernizing the nation's healthcare system, which had been called a disaster in IT history, has demonstrated that conventional IT technologies and solutions are not able to be simply applied for large-scale, complex applications.

The great complexities and risks for large-scale IT projects are mainly due to the heterogeneity of existing legacy information systems. On the other hand, the complexity of business logic, information representation is unpredictably increased for those large-scale enterprise integration or cross-enterprise projects. Conventional software developing model, well-known software architectures, existing middleware and frameworks, including SOA (Service Oriented Architecture) and other newly emerging software platforms are not able to provide effective and efficient solution for these issues. Currently, available solutions for integrated healthcare organizations, Regional Healthcare Information Networks (RHIN) and National Healthcare Information Network (NHIN) have unmanageable cost, great risks to meet the goals, hard to scale out, and lack of the capability for long tern evolution.

Traditionally, a problem domain was divided "vertically" into disparate applications. The problems were conquered independently with little collaboration with each other. This application development paradigm has not been fundamentally changed since it was established despite the emergence of revolutionary technologies have changed the general landscape of information technology industry.

The consequence of vertically dividing and conquering an application domain was the generation of numerous heterogeneous information systems. The heterogeneity of applications resulted in great difficulties for enterprise- wide information sharing. To date, tens or even hundreds of heterogeneous information systems have been invested and used in large healthcare organizations. As businesses move toward integrated enterprises in information perspectives, information silo problems become dominant problems. When applying interconnection or messaging based approaches to integrating hundreds or thousands of heterogeneous systems, the cost for implementation, subsequent operation and evolution often become unmanageable. If no technical breakthrough could be made in this arena, the information silo problems will run into a vicious cycle and worsen in time.

Increasing demands on large, complex enterprise and cross-enterprise applications dramatically increase the complexities of the business logic, information expression and data modeling. Healthcare is a typical knowledge-intensive application domain. A modern medical institution covers tens of clinical departments, needs to deal with more than 300,000 medical concepts and handles more than one million semantic relationships among these concepts. Moreover, it is very challenging to deal with numerous business rules and workflows. A more complicated nature of healthcare application domain is its consistent knowledge updating based on new research results. This nature may require the systems evolvable over long term operation without high risk and unmanageable cost to meet consistent requirement changes.

Based on above analysis, two conclusions could be made; First, integration solutions based on traditional interconnection or messaging are neither able to eliminate information silos, nor able to prevent further generation of information silos. Second, the heterogeneity of data and dada models is the core of information silo problem. This is an inherent problem from traditional software developing paradigm. Therefore, a potential technical breakthrough should be able to eliminate the heterogeneity of data and data models at the data layer, rather any other system or service layers.

In addition, SaaS (Software as a Service), particularly cloud computing based SaaS has started to show its strong growth in consumer sectors, but it has great difficulties penetrating into business software domains. Although businesses have shown strong interests in adopting cloud computing and SaaS, concerns regarding integration, information security and other issues slowed down businesses adopting SaaS and cloud computing. According to a Forrester Research survey, the No 1 reason why companies say no to SaaS is integration issues. 66% of respondents had concerns with the cost of integrating SaaS applications with their legacy enterprise business applications. Therefore, information silo problem is also a main obstacle for enterprises to adopt SaaS applications.

SUMMARY OF THE INVENTION

The main goal of this invention is to fundamentally eliminate the data and data model's heterogeneity. The core of this invention, named Domain Operating Platform, enables 1) implementing a new type of software platform to fundamentally reduce data modeling and data unification complexities for large scale-enterprise applications; 2) introduction of a virtually application-independent data layer for enterprise applications, making enterprises easy to adopt SaaS and cloud computing.

DOP extends the strategies of Operating System and system software responsibility to the data layer which traditionally belonged to one application software, narrowing the applicable scope of a platform down to a specific application domain.

DOP's technical strategy can be summarized as:

• Focus on the data layer, fundamentally reduce the complexity for building and running large-scale applications by introducing a new data modeling system and related infrastructure and tools;

• Extend the strategies of Operating System and system software responsibility to the data layer, narrow the applicable scope of platform down to a specific application domain, expend the resource management to common devices used in application domain;

• Integrate information silos via data unification, rather system interconnection, build a development and operation platform towards to eventually eliminate information silos;

• Support virtually application-independent data layer and manage enterprise master data under one unified data model, decouple data and applications, herein decouple the lifespan of data with application life cycle;

The preferred embodiment of DOP invention includes:

• An dynamic data modeling system, including methodology, implementation approaches, and related tools;

• Two engines, i.e., MDT Modeling Engine and DOP Data Engine;

A full implementation of DOP for healthcare requires many additional service modules, supporting components and tools. These supporting components will not be included in this document because they can be implemented by publicly available technologies and solutions. Dynamic Data Modeling System

DOP Dynamic Data Modeling system, also known as MDT (Metadata Type) Modeling, is the core of the invention. The preferred embodiment for MDT modeling system can be implemented via 1) a modeling engine, 2) a set of MDT modeling services, and 3) MDT modeling software tools (MDT Designer and MDT Browser).

FIG 4 illustrates the principle of DOP Dynamic Data Modeling. In healthcare application domain, there are numerous domain concepts, such as blood pressure and hypertension. A domain concept can be represented by an object or an entity in traditional information modeling. Whether these concepts are eventually modeled as traditional database tables or modeled as a class in an object-oriented programming language, one concept could be physically abstracted and represented to diverse things in real world application developments. Meanwhile, these data models become incomprehensible for ordinary people, even domain experts.

A domain concept 401 can be represented by a domain concept model 402, which is a natural expression of the concept in human readable and understandable format. A domain concept model 402 is only a start point and often served as customer inputs of requirements for traditional data modeling process. The eventual physical model will be dependent upon the understanding of data modeling experts. It is the fundamental cause of data heterogeneity for same domain concept in different applications. With DOP dynamic data modeling, the process will be dramatically simplified. By using MDT modeling tools, domain experts can directly express the domain concept model 402 with MDT model 403, which is almost identical to the concept model 402. MDT model 403 is readable and understandable by domain experts. The modeling process ends at this point, the rest of works, including building physical data models 404 on relational database, will be handled by DOP modeling engine. Eliminating human introduced variation in this modeling process could fundamentally prevent heterogeneity generation at data model level.

MDT expressive models 403 and physical models 404 are coexisting but not tightly coupled. MDT models 403 are database-independent, human readable and understandable, capable to provide service- oriented services for application developing without need to know the details of the physical data models. The complexity of physical model 404 is hidden and variations become transparent to human users.

Due to its simplicity, MDT modeling is capable of handling data modeling for very complex, large-scale enterprise or cross-enterprise applications. Two Engines

Two engines, MDT Modeling Engine 100 and DOP Data Engine 101, are key components in the preferred embodiment of DOP kernel. FIG 1 illustrates the simplified twin engine architecture and other important components for DOP kernel.

MDT Modeling Engine 100 and DOP Data Engine 101 is a pair of tightly coupled software engines.

MDT Modeling Engine

MDT Modeling Engine 100 is a core of DOP dynamic modeling system. MDT Modeling engine and extended MDT services 104 provides two kinds of services: 1) all services associated with dynamic MDT modeling, including services for MDT modeling tools, such as MDT Designer 105 and its graphical user interfaces 106; and 2) runtime data management related to MDT services.

In order to make DOP physical data modeling independent from proprietary databases, the preferred implementation of MDT Modeling Engine 100 is not coupled with any type of backend databases. However, DOP Data Engine 101 has to be physically implemented based on one or multiple data storage platforms.

FIG 5 exhibited the basic operation sequence of how MDT modeling engine builds MDT models:

Building MDT models require 5 main steps:

1) Domain experts need to study the domain concept, build a domain concept model which correctly represents the concept, including its data representation, relationship to other concepts, associated knowledge and standard and coding, etc.

2) Find or establish MDT attribute template(s) which will be used as a start point for building the MDT model(s) as illustrated in the FIG 3, a example of MDT template(s) and model(s)

3) Build MDT model via MDT modeling tool, such as MDT Designer, by iterating each attribute and setting its properties

4) Create the expressive MDT model as shown from the step 3.4 to 3.4.3 in the FIG 5. The MDT model will be saved in the MDT repository

5) Build physical model by the modeling engine. If relational database is used, the process will be equivalent to map MDT model into columns or table(s). Data Engine

DOP Data Engine 101 is the core of DOP runtime. Accompanying the modeling engine, the data engine realized the following key ideas of this invention:

• All data operations are based on open, expressive MDT models, which hide the complexity of physical data models for complex application domains, such as healthcare

• All data operations via DOP are independent from backend databases

• Optimized for high volume, distributed, all structured and unstructured data services

FIG 7 demonstrates how DOP data engine served a data service request from a client application.

DOP data service can be fulfilled by four main steps:

1) Establish a DOP session for the DOP data service client;

2) Request a data service, such as data query, based on MDT and conditions.

DOP data service manager retrieve related MDTs by working with MDT modeling engine;

3) DOP data engine takes the data service, transforms the service to physical data model specific operations, then, executes the operation(s);

4) Close the session.

Implementation of the data management engine has to cope with backend data storage systems. Although the data engine and backend data storage are easier to be implemented by object oriented or multi-dimensional databases, the relational databases are still preferred because of its maturity and other strengths.

Preferred embodiment of DOP data engine is not bound to any particular backend storage technology or product. However, practical implementation for this part is unnecessary to reinvent the wheels. DOP could implement physical data storage part of the data management engine by leveraging matured, proven data storage technologies. In order to decouple the implementation and backend databases, the provider design pattern can be used to minimize the implementation dependency on particular technologies and products. For instance, DOP has implemented relational database data storage providers as shown in the FIG 6. Other providers can be implemented and plugged in to the data engine without need to make significant changes on other implementations. Although mapping MDT models, which are closer to object oriented or multi-dimensional models than _Λ to relational database models is quite challenging, the detailed implementation will not be covered because there is no obvious obstacles for leveraging matured object-relational (O-R) mapping technologies for the implementations nowadays.

Integrating structured data management and unstructured data management under one unified framework is also covered mainly by the data management engine. Unstructured data, such as a plain text document, or an image file, also can be modeled via MDT, unstructured data can be represented with its "tagging" information plus original file managed by unstructured data manager in the DOP data engine.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematically block diagram of the simplified DOP, including MDT modeling engine and DOP data management engine, system level services and main tools for MDT modeling.

FIG. 2 is a schematically block diagram of the MDT Modeling Engine, which is composed by 7 main software components and the MDT repository.

FIG. 3 illustrates a simple example of MDT attribute templates and MDT models.

FIG. 4 shows the principle of MDT dynamic modeling.

FIG. 5 is a sequence diagram showing basic steps to build a MDT model. This diagram also illustrated the relationship among main modules in the MDT modeling engine.

FIG. 6 is a schematically block diagram of the DOP Data Engine, which is composed of 6 main software components and the data storage management providers.

FIG. 7 is a sequence diagram showing steps of how a DOP data service is fulfilled by the data engine and MDT modeling engine collaboratively.

DETAILED DESCRIPTION OF THE INVENTION

The inventions now will be described more fully hereinafter with reference to the accompanying drawings, in which some examples of the embodiments of the inventions are shown. Indeed, these inventions may be embodied in different forms with different technical approaches, and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by the way of example so that this disclosure will satisfy applicable legal requirements. As a new solution for complex healthcare applications, building a fully functioning DOP platform will require many supplementary software components to the core parts described in this application, such as different levels of services built on the system level MDT services and DOP data services, various programming API, data integration services and administration tools. Certainly, these can be designed and implemented by publically available technologies and approaches, but it is unnecessary to be claimed in the invention.

FIG. 1 illustrates the preferred embodiment of core components for the invention. The embodiment characterized by a twin-engine architecture. MDT Modeling Engine 100 and DOP Data Engine 101 are coupled and co- worked to 1) make complicated modeling processes simple and straightforward, the modeling is simplified to represent domain concepts by readable and easy understandable Metadata Types (MDT) via intuitive user interfaces; 2) to completely hide the complexities of physical data modeling and data management in runtime; and 3) therefore human introduced heterogeneity due to modeling variations can be prevented. Twin engines and MDT Services 104 and DOP Services 107 composed the DOP kernel, i.e. the core of this invention. MDT services 104 is a set of system level services for supporting DOP dynamic modeling, and runtime MDT services for DOP Data Engine and DOP Services 107. DOP Services 107 is a set of system level services for runtime data management, system administration and other DOP system services.

Although MDT Designer 105 with graphic user interfaces for modeling and MDT model related management are not the DOP kernel components, it is included in the FIG. 1 for better description the embodiment. Unlike general purpose middleware, DOP for healthcare will be deployed with basic healthcare / medical concept MDT models and related MDT attribute templates, it may contain some of the data as well, such as standards or reference data. The data storage 103 (databases) and file systems 108 are also necessary components in the embodiment, even though these are not parts of the invention claims.

FIG. 2 illustrated the embodiment of the internal structure of MDT Modeling Engine. Basically, MDT Modeling Engine is managing two types of resources and services. First, the MDT Modeling engine is managing all modeling related resources and handling MDT services. Second, MDT modeling engine is responsible for working with DOP Data Engine in runtime and transforming MDT model based data management tasks to physical data model based data operations. As shown in the FIG. 2, MDT Modeling Manager 202 and MDT Runtime Manager 203 composed the orchestrating layer 200 to manage these two types of tasks and resources. In the service layer 201, the operation logics are implemented via an event-driven, service oriented manner. The service requests from MDT Services 104 and DOP Services 107 in the FIG 1 may be further divided into tasks, then being delegated to corresponding service handlers by MDT Modeling Manager 202 or MDT Runtime Manager 203. MDT Template Manager 204, MDT Builder 205, Physical Model Manager 207, and Standard/Coding Manager 208 are 4 sets of modeling service handlers. MDT Runtime Manager 203 is not only interfacing with DOP data services, but also closely co- working with DOP Data Engine to handle runtime data services. MDT Cache Manager 206 and Physical Model Manager 207 are responsible for handling data operation tasks associated with MDT models. MDT Repository 209 is used to store MDT templates and MDT models. The preferred embodiment is a built-in database which can be implemented by using an object-oriented database or traditional relational database.

Building a MDT model is an interactive, multi-iteration process. MDT models are human readable, understandable information models for domain concepts. As shown in the FIG. 3, vital sign is a medical concept which contains four other medical concepts, including Temperature, Blood pressure, Pulse and Respirations. Taking body temperature as an example, its MDT model, Vital Sign MDT 301, can be expressed by the attribute(s), the display name and standard codes, and related knowledge three sections. Because all 4 concepts for vital sign are independent medical concepts, the vital sign MDT in fact is a composed model, i.e., Vital Sign MDT is composed by Temperature MDT, Blood Pressure MDT, Pulse MDT and Respiration MDT.

FIG. 4 demonstrates the principle of MDT dynamic modeling. Finding and determining which a domain concept is good for modeling as a MDT or only one attribute inside a MDT model requires domain knowledge and modeling expertise. As shown in the FIG. 4, Blood Pressure is a medical domain concept 401. Its meaning is independent from different healthcare scenarios. It is a good example to be built as a MDT. On the other hand, the systolic blood pressure is another concept, it has certain meaning only when it used as one parameter in the blood pressure. Therefore, it is a good representation of an attribute rather than an independent MDT. A domain concept model 402 is a formatted representation of the concept. It at least includes a data model to represent concept related data, and usually have corresponding background knowledge and known relationships with other concepts.

MDT in fact is a new data type when it is properly defined. Some of the operations or functions can be predefined for the MDT. This is why it is called Metadata Type.

Although the invention could help domain experts to determine concepts and facilitate building the concept models, these two steps are still mainly rely on human domain experts. Once the concept has been correctly represented as a concept model, building a MDT model becomes straightforward. Domain experts can directly use MDT design tools to map the concept model to a MDT model 403.

Modeling will be ended at this point based on this invention. The rest of works, including create physical data model(s) 404, will be fully handled by MDT Modeling Engine and DOP Data Engine.

FIG. 5 illustrates main steps to build a MDT model by a sequence diagram:

1. Domain experts need to determine the concept(s) for modeling, then, build concept models based on required formats. These are mainly manual processes assisted with modeling tools.;

2. Find appreciated MDT attribute template(s) via MDT Browser or MDT Designer (as shown in FIG. 1, 105, 106);

2.1. Task is delegated to the MDT Template Manager 204 shown in the FIG. 2, MDT Template Manager searches in the MDT repository for appreciated templates;

2.1.1. MDT Repository tries to find the templates based on conditions;

2.1.2. Return found MDT attribute template(s) or not found message to MDT designer GUI;

3. Create MDT model(s) iteratively based on attribute template(s). Create attribute templates if no appreciated one found;

3.1. For each attribute, create a new attribute via MDT designer;

3.2. Set required or optional properties, such as max or min values, unite, etc.;

3.3. Set attribute measurement methods if required;

3.4. Request MDT Modeling Manager 202 in the Modeling Engine (FIG. 2) to create MDT model;

3.4.1. Delegate the request to the MDT Builder 205 (FIG. 2), map to a MDT expressive model;

3.4.2. This model can be optionally saved as a MDT template by delegating to MDT Template Manager 204 (FIG.2);

3.4.3. Save expressive MDT model to MDT repository;

3.4.4. Last steps are creating physical data model. If embodiment of the physical data storage is based on the relational database, an object to relational mapping is needed.

3.4.4.1. Creating physical models (tables or columns in relational database) tasks are delegated to the Physical Model Manager 207 (FIG. 2).

FIG. 6 demonstrates one reference embodiment for DOP Data Engine. DOP Data Engine intends to avoid any tight-coupled with any proprietary database. Similar to MDT Modeling engine, the first layer is designed for task delegating, orchestrating and management of data service requests. The service layer components are responsible for actual data operations.

Structured Data Manager 601 works as a faced and controller, keeps listening to any data operation request from DOP Data Services 107 (FIG. 1), sending a request to MDT Runtime Manager 203 in MDT Modeling Engine to transform MDT based data operation to physical data model compliant data services, then, further break the service request to sub-tasks if needed. These sub-tasks are then delegated to one concrete Relational DB Manager 604, such as SQL Server Data Manger 606. DB Data manager will work with attached SQL server to fulfill the service requests.

Unstructured data is managed in DOP in a unified way similar to structured data. A piece of unstructured data, such as a JPEG image file can be tagged by a set of properties, such as file name, data type, creation time, etc. These tagging data are managed as structured data, only unstructured data may be stored in the file system, which is managed by Unstructured Data Manager 603 and its concreted implementation, File System Manager 607 and 608.

FIG. 7 illustrates a simplified sequence how DOP Data Engine serves a data service request:

1. A DOP Service Client connect to DOP;

2. DOP session manager returns a session to the client;

3. The client submit a querybyParameters data service request to DOP Data Services 107 (FIG. 1);

3.1. The data service request is delegated to the Structured Data Manager 601 in the Data Engine;

4. Data Engine talks to Modeling Engine, MDT Runtime Manager to transform the MDT based data service to a concrete data service;

5. MDT Runtime Manager 203 try to get related MDTs;

6. Try MDT cache first;

7. If cache missed, get MDTs from MDT repository;

8. Cache these MDTs;

9. Transform MDT based data service to physical model based data service via Physical Model Manager 207;

10. Delegate the query to the concrete DB manager, and work with database to fulfill the request.

Claims

1. A method, called Domain Operating Platform (DOP), eliminates information silo problems in enterprise application domains by unifying data and business applications under a single data model, especially for the challenging healthcare industry. The method comprises the steps of: building a dynamic modeling system called MDT (Metadata Type) modeling, to simplify the data modeling processes for complex application domains; and implementing DOP kernel for building a platform.

2. The method according to claim 1, wherein a new data modeling method, MDT modeling comprises the methodology to build expressive MDT models, and steps for creating MDT models from application domain concepts.

3. The method according to claim 2, wherein the MDT modeling methodology comprises the method of: determining domain concepts for a MDT model or for an attribute in a MDT model; building or using existing MDT attribute templates; and composing a MDT model via one or more MDT attribute templates.

4. The method according to claim 2, wherein the method for creating a MDT model comprises the steps of: directly expressing the domain concept model by a MDT model, and creating corresponding physical data model by the modeling engine.

5. The method according to claim 1, wherein a method and steps for building DOP kernel, which can be comprised by a twin-engine architecture.

6. The method according to claim 5, wherein a method comprising structures and steps for building: MDT Modeling Engine and DOP Data Engine.

7. The method according to claim 6, wherein MDT Modeling Engine can be built by following functional modules, including MDT Modeling Manager, MDT Runtime Manager, MDT Template Manager, MDT Builder, MDT Cache Manager, Physical Model Manager, standard /Coding Manager and MDT Repository.

8. The method according to claim 6, wherein DOP Data Engine can be

comprised of functional modules: Structured Data Manager, Data Cache Manager, Unstructured Data Manager, Relational DB Manager and related DB Providers, File System Manager and providers.

9. The method according to claim 1 and claim 6, wherein a method comprising steps for DOP Data Engine co-working with MDT Modeling engine to make data services being independent on the physical data models.