A Quasi Relational Query Language for Persistent Standardized EHRs: Using NoSQL Databases

Editor's Notes

• #2: Good Morning everyone, I am Aastha and today I am going to talk about our effort to build a quasi-relational QL for the Standardized electronic health records which have been persisted using a NoSQL database.
• #3: -To deliver quality healthcare services, the healthcare domain requires the support of IT during various phases of patient-care. These include the primary purposes and the secondary purposes as well. IT is capable to provide scalable and flexible infrastructures to support the expanding, geographically distributed needs of the healthcare domain. EHRs in a hospital are – heterogeneous in nature It comprises of dictations from physicians, structured data from the sensors, images of XRAY. And various parameters that define patient health As the healthcare moves towards BigData – the proper analysis and querying of the data within EHRs is required This can be supported to some extent by use of – data standards for EHRs, These help representing the data uniformly across organizations which are geographically distributed For interoperable exchange of data – the prominent standards existent are – HL7, CEN 13606 and OpenEHR Among these OpenEHR is the latest and increasingly accepted standard. In this study we consider the EHRs based on OpenEHR as our prime focus
• #4: Let us visualize how a seemingly simple single patient encounter generates complex and large amount of EHR data which is to be analyzed for improving healthcare services. During a single patient encounter, several patient-visit parameters may be involved during a check-up. These may include say, BP, glucose-level, BMI, Medication List and temperature. Each of these parameters is actually a complex, full-blown semantic object in itself and several properties are associated with each. These can be directly mapped to an Archetype artifact of the OpenEHR standard The term “Archetype” gives a full-fledged description of a medical concept Multiple concepts of say the archetypes together form an archetypal HER So far a set of 352 archetypes is defined by the standard, Hence we can say that an EHR can be an aggregation of maximum 352 archetypes Further, these are persisted in a database.
• #5: - But before we understand what is persisted, lets take a look at the complexity of an Archetype. The archetypes are defined by clinicians Model the a specific part of clinical recording and workflow process they are used in Divided into 4 categories, say based on explanatory descriptive concepts such as Patient Examination, discharge summary Another one which describes the entries made, say for blood pressure, weight etc which are standalone concepts These also depend on the record or observation they describe say, the action (record clinical activities), instruction given out (say medication) and the evaluation performed by the clinician (adverse reaction) Further related archetypes may be clustered together into reusable artefacts Lets consider the BP archetype in the figure: It is an observation entry type of archetype Contains parameters which are grouped as the state of the patient, the events accounted for observation, the protocol about how the particular parameters were collected and finally the data which is the core of the archetype Each of the archetypes have its own unique definition
• #6: These are defined by the archetype definition language (ADL) Which is an XML variant used to describe the parameters of the archetypes using standard terminologies It has more complex structure than the XML equivalent It represents the semantics of the archetypes and preserves the inter- and intra- archetypal relationships Each parameter is described via complete hierarchical paths and are directly convertible to XPATH expressions. These paths are queried for semantics based querying on the archetypal EHRs. It describes the admin information such as; Archetype class, rules, annotations, constraints and ontologies associated
• #7: The Ocean informatics currently proposes a declarative semantics-oriented query language AQL Which is semantic variant of the SQL and the XQuery It makes use of archetype paths for querying There are several features not supported by it But it is a developer level language and is not easy for a healthcare expert to write an AQL query each time to retrieve some knowledge from the archetypal EHRs
• #8: Going further let us quickly summarize the data management model of the OpenEHR standard The dual level model of the standard can be mapped to the traditional existent database model The reference model layer of the OpenEHR is persisted. the archetype model layer provides the conceptual or the logic level of the model. It supports queries/archetypes/templates and interfacing with the terminology The service model which is application specific is equivalent to the tradition layer of views for the different EHRs users. The need for query layer lies above this layer.
• #9: The existing db solutions fail to meet the requirements of the archetypal EHRs: Capture highly nested queryable data Use of complex hierarchical paths Return results to the users in real-time In the light of these desired features we propose to use the recent NoSQL databases why not a relational database a) pre-design the exact field structures of the data which is required in the process of DB normalization to ensure data consistency. b) Relational database model s not practical for certain forms of data that require a lot of fields to handle different types of data involved. c)This includes cases where most of the data fields are left unused due to the nature of data. d)Medical data especially clinical notes possess the above characteristics.
• #10: Up till now we have seen that each of the patient-encounter parameter is mapped to an archetype or concept Multiple archetypes or concepts together form an archetypal EHR For each EHR there may exist multiple versions These are persisted with help of the reference model of the OpenEHR Each of the archetypes is represented via an ADL The Ocean informatics proposes a declarative AQL query language based on the ADL Paths The health-worker needs to understand the syntaxes of this language in order to compose queries. This may not be his choice Hence there are two missing points here: A) the method of persistence B) an easy to use query language for the healthcare workers
• #11: We narrow down to two guidelines for our problem statement: A scalable persistence mechanism which is horizontally scalable and can take care of nested archetypal structure A new graphical or visual query language Semantics based Easy-to use for the healthcare worker Performs general-purpose queries
• #12: As we see in the figure, the complex patient encounter data is persisted in the DB And the healthcare worker looking for support of querying during patient care is generally aware of the patient id and wants to fetch his or her EHR This can be well modeled using the NoSQL DBs These may include the key-value type of store/the big table type of stores/ the graph or the document oriented DBs By using the NoSQL database a) the user does not require pre-defined schema, relationships and keys. b) they are low-cost, schema-free and horizontally scalable to accompany new resources when the need arises. c) significant for cloud-based solutions, common database approach for cloud based clinical systems. The general purpose queries of the users in this case may not be simple. They may require consideration of complex structure of the underlying database.
• #14: Next we try to explain what is our proposed system all about and where is it in the context of the EHRs, big data and persistence terminologies The proposed quasi-relational query language system is directly interfaced with the persisted patient data The user can directly formulate the query using the flattened screen forms These screen forms are the templates generated from various combinations of the archetypes The system at present takes a subset of the archetypes of the OpenEHR archetype repository
• #16: The main components of the proposed system include: Local archetype repository (subset of 40 archetypes from a total of 352 archetypes defined) The AQBE system which provides the user interface to the end-users and performs two main functions: The data-input system The query system The Persistence layer which is a document-oriented NOSQL database MongoDB
• #17: Here we present the microscopic view of the standardized EHRs system with its client-side and the server-side components The system performs a one time activity of fetching the subset of the archetypes from the OpenEHR archetype repository the ADLs and the corresponding XMLs are fetched for the selected archetypes Archetypes from all the categories are fetched for the prototype system The server-side of the system comprises of the two databases, the local archetype repository and the standardized HER repository which is NoSQL DB. The archetype parser parses the XML of the archetype and flattens it into a form to display on the UI The dbacessAPI are responsible for storing and fetching the EHR data.
• #18: Each of the archetype is serialized into a JSON document and stored in the MongoDB Each of the documents is stored with a unique id and patient id
• #22: Insert the following fields: Patient Name : Ayaan Composed by: Dr. Madaan Systolic Value: 90 Diastolic : 140 Enter the data Should display message data added successfully After that go to find option Add patient name as : Ayaan Add Find data Should display complete result
• #24: Q1: Get all the abnormal (high) blood pressure values for the patients that are recorded during patient-encounter. [single-concept, multiple EHRs] Steps for the query: Select blood pressure concept Enter systolic > 140, add Enter diastolic >90, add Find data Q2: Find all the records that recorded very high BMI (> 30) for patients between the period of December 25, 2012 to January 7, 2013 showing the increase the cases of obesity among the patients [single-concept, epidemiological query] steps for the query: a) select BMI concept b) add context value >= december 25 , 2012, add c) add context value <= January 7, 2013, add d) enter BMI value > 30, add e) Find data Q3: Get a patient’s current medication List [Single-patient query] Steps for the query: a) select medication list concept b) enter patient name, add c) find data
• #25: Q1: Get all the abnormal (high) blood pressure values for the patients that are recorded during patient-encounter. [single-concept, multiple EHRs] Steps for the query: Select blood pressure concept Enter systolic > 140, add Enter diastolic >90, add Find data Q2: Find all the records that recorded very high BMI (> 30) for patients between the period of December 25, 2012 to January 7, 2013 showing the increase the cases of obesity among the patients [single-concept, epidemiological query] steps for the query: a) select BMI concept b) add context value >= december 25 , 2012, add c) add context value <= January 7, 2013, add d) enter BMI value > 30, add e) Find data Q3: Get a patient’s current medication List [Single-patient query] Steps for the query: a) select medication list concept b) enter patient name, add c) find data
• #26: Q1: Get all the abnormal (high) blood pressure values for the patients that are recorded during patient-encounter. [single-concept, multiple EHRs] Steps for the query: Select blood pressure concept Enter systolic > 140, add Enter diastolic >90, add Find data Q2: Find all the records that recorded very high BMI (> 30) for patients between the period of December 25, 2012 to January 7, 2013 showing the increase the cases of obesity among the patients [single-concept, epidemiological query] steps for the query: a) select BMI concept b) add context value >= december 25 , 2012, add c) add context value <= January 7, 2013, add d) enter BMI value > 30, add e) Find data Q3: Get a patient’s current medication List [Single-patient query] Steps for the query: a) select medication list concept b) enter patient name, add c) find data
• #31: The table displays the list of categories of common queries desired on the EHRs It represents the queries which the current system is capable to perform The system can currently perform single-concept queries for multiple patients It can perform single-patient queries on a single-concept It can perform instantaneous queries as well as the temporal queries As part of the future work we wish to establish the query capability of the proposed system across multi-concept and life-long aggregate queries
• #32: W.r.t the query functions that the current system can perform the following table explains in detail: As we see in the table: The aggregate and join functions across patients and concepts need to be explored on the proposed NoSQL database persistence Also the nested queries and top-N queries need to be implemented.
• #33: Here we present an overview of the qualitative comparison of various persistence methods for the OpenEHR based archetypal EHRs For the first two methods the relational and the XML based persistence the dimensions are derived from the study of related work The NoSQL based results are formulated on the basis of our prototype system The results indicate that the NoSQL based persistence can provide scalability, reduced query-response time, and high granularity of querying and also indexing for efficient retrieval
• #35: The Standardized EHRs are life-long records of a patient The patient data need to be queried across any of the time-window Over the period of time: Archetypes change Templates evolve New archetypes come into existence The query-language needs to be capable to handle all these challenges.