Patent Application
20130110542
In the medical setting, health care organizations are struggling with handling large amounts of patient data in a meaningful way. Database technologies exist for storing this patient data. However, interacting with the patient data is very difficult and cumbersome. For instance, applications that interact with the patient data have to be custom built to interact with a particular database instantiation. That is, with existing technologies, the application developer has to understand the nuances of the database for which he/she is writing the application and directly tie the application to the data. Stated another way, the interfaces an application could use to connect to the database require the application to be directly tied to the underlying database. Further, querying the database, such as by an end user clinician, requires a thorough understanding of how the database is set up; a skill set that most clinicians have neither the desire nor time to obtain.
This discussion relates to patient data and more specifically to accessing and managing patient data. One implementation can generate a user interface from which a user can select predefined entities for use by a health care management application. The entities abstract the health care management application from underlying patient data. This implementation can allow the user to select an individual predefined entity from the list or define a different entity on the user interface. This implementation can also enable the user to associate the individual entity or the different entity with a semantic tag.
Another implementation can access an entity registry that lists entities used by applications installed on a health care management platform operating on behalf of a health care organization. This implementation can identify any unbound entities in the entity registry. This implementation can also present individual unbound entities for binding to patient data of the health care organization.
A further implementation can store rules relating to entities of a patient data abstraction framework. This implementation can suggest queries based upon the rules. It can also receive a value input from the user. The implementation can generate an individual query from the suggested queries that includes the user provided value input. It can search patient data accessible to the abstraction framework with the query. This implementation can also cause query results to be presented to the user.
The above listed examples are intended to provide a quick reference to aid the reader and are not intended to define the scope of the concepts described herein.
The accompanying drawings illustrate implementations of the concepts conveyed in the present patent. Features of the illustrated implementations can be more readily understood by reference to the following description taken in conjunction with the accompanying drawings. Like reference numbers in the various drawings are used wherever feasible to indicate like elements. Further, the left-most numeral of each reference number conveys the Figure and associated discussion where the reference number is first introduced.
This patent relates to patient data and more specifically to accessing and managing patient data. This is an issue of great concern to health care organizations. A health care organization can be any type of health care related organization from a sole provider doctor's office to a nationwide chain of hospitals and clinics. Database schemas at health care organizations can be complex. Further, each health care organization can have its own way of organizing patient data. Traditionally, in order to search the database, users need to learn the internals of the schema. Clinical concepts (e.g. whether a patient is diabetic) are often defined based on several disparate data points, and these data points can change over time. To further complicate matters, each health care organization may define such concepts differently. Users, such as clinicians, want to be able to use these concepts to search but do not want to be burdened or exposed to all the internals of the database minutiae.
The present inventive concepts can provide a patient data abstraction framework (PDA). The patient data abstraction framework can abstract the end-users from the internals (e.g., minutiae) of the database schema and can enable the end-users to search the database in a manner that is more natural to their everyday language. For instance, an end-user may enter a query as “show me all patients who are on beta blockers and diuretics” without knowing what is going on ‘under the hood’.
From an application developer perspective, the patient data abstraction framework can create reusable pieces of clinical logic that can be used to define clinical concepts without requiring the development of custom code.
The discussion above broadly introduces inventive patient data management and access concepts. To aid the reader in understanding these inventive concepts,
For purposes of explanation, the present inventive concepts are explained from the perspective of features offered to various users 110. As such, each user experience is represented vertically through the layers. The illustrated users include an application developer 110(1), an information technology (IT) manager 110(2), an analyst 110(3), and a clinician 110(4). User experiences are introduced in the discussion here and will be discussed in more detail below relative to subsequent
Starting with the user experience of the application developer 110(1), the HCRM platform 106(1) can allow the application developer to write an application 104(1) without understanding the nuances (e.g., database organizational structure) of the underlying patient data 108(1)-108(N). More specifically, the HCRM platform 106(1) can provide an application virtual schema 112 that enables the application to access the appropriate underlying patient data 108(1)-108(N). For example, the application developer 110(1) can write the application to accomplish a desired functionality relating to the patient data. The application developer can then create a data manifest 114 that accompanies the application. The data manifest 114 can define entities utilized by the application 104(1). The entities can be thought of as data objects that relate to patient data. The developer can also semantically tag each entity on the data manifest. The semantic tag can be thought of a commonly understood meaning for the entity. The data manifest 114 can be entered into an entity registry 116 of the HCRM platform 106(1).
In summary, the HCRM platform 106(1) can allow the application developer 110(1) to deploy the same application 104(1) to multiple health care organizations since the application developer is now freed from tying the application 104(1) directly to the patient data 108(1) and 108(N) of a given organization.
The IT manager 110(2) can access the entity registry 116 and review the entities from the application 104(1). The IT manager 110(2) likely understands the organization of patient data 108(1) and 108(N) and can bind the entities from the application 104(1) to the underlying patient data. Once bound, at 118, the HCRM platform 106(1) can ingest the patient data utilized by the application 104(1) from the various sources of patient data 108(1) and 108(N).
Stated another way, the application virtual schema 112 can simplify the application development process and make applications portable and easy to deploy. The application virtual schema can allow application developers to define their conceptual data model that describes the things of significance to an application and deploy the application into the HCRM platform 106(1). The virtual schema objects and their attributes can be semantically annotated using ontology elements. Similarly, patient data 108(1) and 108(N) can also be semantically annotated using ontology elements during ingestion. This approach enables the lookup and binding of the virtual schema objects to the physical schema objects during application deployment time.
The analyst 110(3) can define rules using entities from the entity registry 116. The analyst then puts the defined rules in a rules library 120. The analyst can also create functions from multiple rules. The functions can be placed in a functions list 122.
The clinician 110(4) can utilize the rules defined by the analyst in the rules library to query the patient data 108(1) and 108(N) without knowing anything about how the patient data is organized or knowing anything about database structure, etc.
Stated another way, users, such as the IT manager 110(2) and/or the analyst 110(3) can create and publish re-usable units of logic (e.g., rules and/or functions) that leverage individual entities and semantically interoperable constructs that serve as a basis for queries that may be utilized by the clinician. In turn, the clinician 110(4) can consume the rules by providing semantic inputs without the user knowing details of underlying physical or logical layers of the patient data abstraction framework.
Now, consider an explanation based upon the supposition that a purpose of a health care management system is patient care. Patient care can be enhanced by being able to identify patients from the patient data that meet some criteria. For instance, the clinician 110(4) has a clinical desire to view a list of patients who meet a set of criteria. The clinician understands what those criteria are in terms of the clinical concepts that are involved and what their relevance is. However, the clinician tends to have little or no understanding of the data model at their health care organization or how those clinical concepts are expressed in terms of the data model.
The analyst 110(3) understands the organization's data model and how to define more complex clinical concepts from it. However, analysts usually are not clinicians, so they may not understand the relevance of those concepts in clinical situations. The analyst may also lack the skill set of the IT manager 110(2) so the analyst may not understand the technical details of the database schema and how data is populated in the virtual schema.
The IT manager's job is to know all about how data is stored on the disk and how it is served up to the application. However, the IT manager 110(2) does not necessarily have a clinical background or interaction with clinical users, so the IT manager likely does not have a deep understanding of what the patient data they're serving up means to a clinician.
Since no single player necessarily understands all of the parts involved in creating a list of patients based on complex clinical concepts, all of them do their parts. The first step is for the IT manager 110(2) to link up the raw patient data 108(1)-108(N) in the database to the entity model contained in the entity registry. The second step is for an analyst 110(3) to use the patient data stored in the entity model to derive a rule determining if a patient meets a set of criteria. Finally, the clinician 110(4) combines rules together to create a list of patients that meets a clinical need.
In logical layer architecture 200, patient data layer 108 is shown as the bottom layer. Recall that the patient data layer is organization specific and thus tends to be non-standardized from organization to organization. For example, one organization may record their patient temperatures in Celsius, while another records their patient temperatures in Fahrenheit. The patient data layer can be thought of as a data store that contains parsed data from source patient data 108(1) and 108(N). The logical layer architecture 200 may have further layers or sub-layers below the patient data layer 108. For instance, for each source there can be a message archive layer and a shredded layer that has one set of a table per source. At the patient data layer 108, the data can be arranged in tables. The tables and columns of the tables can be semantically tagged using ontology elements as represented generically by ontology 202.
Above the patient data layer 108 is the entity registry 116. The entity registry can be thought of as a dictionary where the published entities and their associations are stored and managed. An entity can be thought of as an object that groups ontology elements (concepts) into meaningful structures (for e.g. Patient, LabResults, etc.). The entities can be uniquely identified using a primary key.
In some implementations, entities can be grouped together in containers that are uniquely identified by a namespace. For instance, one container 204(1) can be included with the HCRM platform 106(1) (
In some implementations, a clean installation of HCRM platform 106(1) may not include any specific schema for the patient data in the patient data layer 108. Alternatively, such implementations could include a “starter kit” (completely separate from the platform) that comes with a pre-defined schema for patient data (such as Lab Results, ADT, etc.) along with semantic tags to annotate the patient data at the patient data layer. This starter kit could contain mapping between the out-of-box entities and the patient data layer that comes with the “starter kit”. Further, the entity registry may include a dictionary of semantic tags that lists the tags and their accepted meanings.
The application virtual schema 112 can be thought of as a map of concepts and their relationships to describe the data model of an application (e.g., application 104(1) of
As mentioned above, an application can describe its data model using a data manifest (
For purposes of explanation consider the following example that relates to the concepts described above relative to
Assumptions:
In some implementations, the application virtual schema 112 is created per application instance and is not shared across instances. The application virtual schema for this example consists of:
Note that #4 and #5 can be created and stored per application instance because such a configuration provides application isolation and also enables adding the capability to materialize the application virtual schema per application instance. This configuration also insulates against changes between application instances. So, when any application instance goes through an upgrade or uninstall there is no concern about any other application instance getting affected.
The following example explains how these artifacts can be used at runtime by the HCRM platform.
The custom entities can then be installed with the application at the health care organization. For instance, as part of installing the new application, the custom entities of the data manifest are introduced into the system where the application is installed (e.g., the entities from the data manifest are sent to the entity registry). The person deploying the application then “binds” the custom entity to underlying patient data that is available at that particular site (health care organization). In the example provided above relative to
In the illustrated example, someone created an entity called “BindingTest” under namespace “HCRM.NW” that is shown on the left hand pane (e.g., the entity listing region 502). The user interface (represented by screenshot 800) offers features to help with the binding. In the “Assisted Mode”, the user interface can show every attribute (same as property or column) in the entity (in example above, these are ID, F1, FirstName, LastName) and allow the user to select the underlying database column from a table to which the attribute will be bound. These possible matches can be based on semantic tags. That is, the application developer who created the entity also specified semantic tags for describing every attribute of the entity. When the HCRM platform aggregates data from various systems in a health care organization, the platform tags the data elements. During binding, the HCRM platform can match what the application developer intended with what is available at the health care organization by comparing the semantic tags. As a result of this “assisted binding”, the HCRM platform can generate a SQL query indicated generally at 802. There is also a manual mode where someone (such as the IT manager) can choose to write the SQL query manually that defines how to obtain patient data for the entity from the underlying data store (e.g., patient data). The actual patient data in the data store could be different at each health care organization where the HCRM platform is installed.
As used above, a ‘rule’ can be based on a root entity and can be of arbitrary complexity. The rule can be defined as a collection of rule predicates that has a custom internal XML representation. In some implementations, rule queries can be characterized in two ways; quick rules and custom rules. The quick rules can be provided by a rules subsystem. Custom rules and list membership rules can be created using a population management user interface (UI). In some implementations, regardless of whether the rules are quick rules or custom rules, all rule queries can have the same form:
The <Primary Key Columns> are the primary key columns of <Root Entity>. The <Root Entity> is the name of an app view (such as Patient, Visit, etc.). The <Rule Predicates> are one or more Boolean SQL expressions that limit the rows returned from <Root Entity> (such as Patient.Sex=‘F’ or Visit.AdmitDate BETWEEN @StartDate AND @EndDate). These can be arbitrarily complex expressions, as long as they evaluate to a Boolean and can fit into the WHERE clause. Other SQL constructs may be used if needed (such as GROUP BY, HAVING, aggregate functions). Joins are not required because each entity directly or indirectly related to <Root Entity> has a foreign key to <Root Entity>. In some cases, the rule query is composable as a sub-query (no common table expressions (CTEs)).
In some implementations, quick rules provided by the rules subsystem have arbitrarily complex <Rule Predicates>. Custom rules defined in the population management UI can have a single <Rule Predicate> of the form:
List membership rules are the same as list queries. The list queries are SQL SELECT statements of the form:
This form works if there is a single primary key column, such as Common.Patient.PatientID. Entities with multiple primary key columns could utilize a more complex form using common table expressions and left outer joins:
The following example can help to illustrate the above mentioned points.
List queries are used to construct list membership rules. List membership rules are treated in the same way as rule queries in the WHERE clause:
Alternatives implementations can include using SQL set operations like INTERSECT and UNION to compose list queries out of rule queries. Alternatively, rules can be combined into a single SELECT statement, but rule queries that have non-trivial forms (GROUP BY, aggregates, sub-queries) could be difficult to combine.
In some implementations there are two types of list view queries; base list view query and grid list view query. A base list view query is a SQL SELECT statement with multiple columns that may be from joined entities. If the joined entities have a one to many relationship with the <List Entity> then there may be multiple row sets per <List Entity> instance. Base list view queries are used by some subsystems to build reports and graphs.
A grid list view query is a SQL SELECT statement with multiple columns that may be from joined entities, just like a base list view query. However, grid list view queries may have scalar-valued sub-queries in the SELECT clause to limit the returned rows to one per <List Entity> instance.
List view queries are SQL SELECT statements of the form:
The following simple example can further aid in understanding the above mentioned base list view query:
The following simple example can further aid in understanding the above mentioned Grid List View Query:
Additional filters can be added to the list view query in the same manner as rules (filters can be thought of as rules attached to a list view).
The data manifest designer 2106 (also called virtual schema designer) is a visual tool that enables the application developer 110(1) to create the application's data model (virtual schema). The data manifest designer can be used to visually create and modify the virtual schema data objects, properties, associations, etc. The data manifest designer also allows the application developer to automatically generate their data model using entities available in the entity registry 116. The auto-generated objects can then be further modified manually to suit the application's needs.
The data manifest deployer 2108 can be used to deploy the application's data manifest and create mappings and other artifacts utilized by the HCRM platform 106(1) at runtime to execute queries on the virtual schema objects. In short, the data manifest deployer can create a metadata layer for the deployed application instance.
The function builder 2110 allows the IT manager 110(2) to define a function. The IT manager or similar user tends to understand the virtual schema data model and understand some basic programming and SQL concepts. The IT manager can also work with clinician 110(4) to understand the clinician's needs and then use the function builder to define the underlying functions. The function builder can store functions in the functions list 122.
The declarative algorithm builder 2112 can use (re-use) functions from the functions list 122 to support the clinician 110(4) in providing patient care. Similarly, the functions can be used for user notification, alerting, and analytics. Recall that functions can be generated from multiple rules, so in some cases, the declarative algorithm builder may use any combination of rules from the rules library 120 and/or functions from the function list to aid the user in searching the patient data in a user-friendly and effective manner.
System 2100 can represent a web-based implementation where the HCRM functionality is provided on computer 2105(5) that is remote from the user's computers 2102(1)-2102(4). The results of the functionality can then be presented to the users on computers 2102(1)-2102(4). Alternatively, system 2100 can be a distributed system where some of the functionality is provided locally and some of the functionality is provided remotely. For instance, the data manifest designer 2106 could run on the application developer's computer 2102(1) while the other components ran on computer 2102(5). In still another configuration, a fully functioning HCRM platform with the data manifest designer 2106, data manifest deployer 2108, function builder 2110, and declarative algorithm builder 2112 could operate on each user's computer. These components could then access and update a central entity registry 116, rules library 120 and functions list 122.
The term “computer” or “computing device” as used herein can mean any type of device that has some amount of processing capability and/or storage capability. Processing capability can be provided by one or more processors (such as processor 2114) that can execute data in the form of computer-readable instructions to provide a functionality. Data, such as computer-readable instructions, can be stored on storage 2116 or 2118. The storage can include any one or more of volatile or non-volatile memory, hard drives, flash storage devices, and/or optical storage devices (e.g., CDs, DVDs etc.), among others. As used herein, the term “computer-readable media” can include transitory and non-transitory computer-readable instructions. In contrast, the term “computer-readable storage media” excludes transitory instances. Computer-readable storage media includes “computer-readable storage devices”. Examples of computer-readable storage devices include volatile storage media, such as RAM, and non-volatile storage media, such as hard drives, optical discs, and flash memory, among others.
Examples of computing devices can include traditional computing devices, such as personal computers, cell phones, smart phones, personal digital assistants, or any of a myriad of ever-evolving or yet to be developed types of computing devices. Further, aspects of system 2100 can be manifest on a single computing device or distributed over multiple computing devices.
In this case at 2202, the method can generate a user interface from which a user can select predefined entities for use by a health care management application. The entities serve to abstract the health care management application from underlying patient data.
At 2204, the method can allow the user to select an individual predefined entity from the list or define a different entity on the user interface.
At 2206, the method can enable the user to associate the individual entity or the different entity with a semantic tag.
In this case at 2302, the method can access an entity registry that lists entities used by applications installed on a health care management platform operating on behalf of a health care organization.
At 2304, the method can identify any unbound entities in the entity registry.
At 2306, the method can present individual unbound entities for binding to patient data of the health care organization.
In this case at 2402 the method can store rules relating to entities of a patient data abstraction framework.
At 2404 the method can suggest queries based upon the rules.
At 2406 the method can receive a value input from the user.
At 2408 the method can generate an individual query from the suggested queries that includes the user provided value input.
At 2410 the method can search patient data accessible to the abstraction framework with the query.
At 2412 the method can cause query results to be presented to the user.
The order in which the example methods are described is not intended to be construed as a limitation, and any number of the described blocks or steps can be combined in any order to implement the methods, or alternate methods. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof, such that a computing device can implement the method. In one case, the method is stored on one or more computer-readable storage media as a set of instructions such that execution by a computing device causes the computing device to perform the method.
Although techniques, methods, devices, systems, etc., pertaining to a patient data abstraction framework are described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed methods, devices, systems, etc.
