Download presentation
Presentation is loading. Please wait.
1
Cerner Millennium Fundamentals
Architecture Owner: Catalyst Millennium Big Picture Effective Date: January 31, Version 21 Tracking #: ®Cerner Corporation. All rights reserved. This document contains confidential and/or proprietary information belonging to Cerner Corporation and/or its related affiliates which may not be reproduced or transmitted in any form or by any means without the express written consent of Cerner.
2
Data Flow Client Middleware Database
The end user makes a request for information at the Client tier. This request is communicated to the database through the Middleware. Once information is retrieved from the Database, it is sent back through the Middleware and provides the information originally requested by the Client tier. Patient Search in PowerChart Middleware takes this request and passes it on the Database. Database accepts the request and gathers the requested information. Middleware receives the reply and passes it to the Client. The Client tier displays all the patients for end user selection. Client In summary, this diagram shows how the data flows in the system. The end user makes a request or an inquiry at the client layer. This information is communicated to the database through the middleware. Once that information is retrieved in the database, it is sent from the database back through the middleware and, finally, provides the information to the client layer. This entire back end configuration is transparent to the end user. The end user interacts with the GUI applications, and the rest happens behind the scenes. Middleware Database
3
Tables are comprised of rows and columns
The goal is to store data values once TABLE Column 1 Column 2 Column 3 Column N Row 1 Data value Row 2 Row 3 Row 4 Row N PERSON Person_id Name_last_key Name_first_key Sex Row 1 1000 RIVERS MAVIS Female Row 2 1001 HASSLER EMMY Row 3 1002 NGUYN RAYMON Male Row 4 1003 SCOTT DILLON Row N 1004 VANHOSER EDITH The relational database that is used for Cerner Millennium is made up of hundreds of tables. Each table has multiple horizontal rows and vertical columns. Active information is stored only once on each table. This eliminates redundancy and increases efficiency.
4
Rows are also known as records of information
Rows are a list of attributes in a table TABLE Column 1 Column 2 Column 3 Column N Row 1 Data value Row 2 Row 3 Row 4 Row N PERSON Person_id Name_last_key Name_first_key Sex Row 1 1000 RIVERS MAVIS Female Row 2 1001 HASSLER EMMY Row 3 1002 NYGUN RAYMON Male Row 4 1003 SCOTT DILLON Row N 1004 VANHOSER EDITH The relational database that is used for Cerner Millennium is made up of hundreds of tables. Each table has multiple horizontal rows and vertical columns. Active information is stored only once on each table. This eliminates redundancy and increases efficiency.
5
Columns are also known as attributes of a table
Each table contains unique attributes TABLE Column 1 Column 2 Column 3 Column N Row 1 Data value Row 2 Row 3 Row 4 Row N PERSON Person_id Name_last_key Name_first_key Sex Row 1 1000 RIVERS MAVIS Female Row 2 1001 HASSLER EMMY Row 3 1002 NGUYN RAYMON Male Row 4 1003 SCOTT DILLON Row N 1004 VANHOSER EDITH Columns contain data elements. The column names are unique within a table. For example, name_full_formatted and birth_dt_tm are columns found only one time on the person table. In some instances columns connect tables to each other.
6
Data values are listed at the intersection of each row and column
TABLE Column 1 Column 2 Column 3 Column N Row 1 Data value Row 2 Row 3 Row 4 Row N PERSON Person_id Name_last_key Name_first_key Sex Row 1 1000 RIVERS MAVIS Female Row 2 1001 HASSLER EMMY Row 3 1002 NGUYN RAYMON Male Row 4 1003 SCOTT DILLON Row N 1004 VANHOSER EDITH
7
Table Relationships How do the tables relate to one another?
Common attributes are shared between tables The common attributes of tables create a “bridge” from one table to another ENCOUNTER PERSON PERSON_ALIAS encntr_id person_id active_ind reg_dt_tm person_id name_last_key name_first_key active_ind sex_cd birth_dt_tm person_alias_id person_id alias person_alias_type_cd contributor_source_cd If you have not done so already, become familiar with the data model found in this section. There will be several references to this diagram within this section. Take a look at this slide. Above each box, you find the table name. The table names on this slide are person and person_alias. The other tables on your data model include encounter, encntr_alias, code_value, and code_value alias. The primary key is noted on each table with a thin black line. What is the primary key on the person table? If you said person_id, you are correct! The foreign keys are designated with an FK in parentheses. It is formatted this way in documentation to help you learn to navigate between the tables. This notation is not part of the column name itself. The person_id is the primary key on the person table and is the foreign key providing a link to the person_alias table. Knowing these ‘links’ or ‘relationships’ will help your quest for data stored within all the Millennium tables. Both Primary and Foreign Keys will be discussed in the precedingg slides.
8
An Expanded Person Data Model
Organization _Alias Prsnl_Alias Person_Org _Reltn Organization Personnel Person Person_Prsnl _Reltn Person_Alias Encntr_Prsnl _Reltn Because this may be your first exposure to Discern Explorer and the data model, this presentation shows an abbreviated version of the data model, which you will use in class. Here you see the entire person data model. You should be familiar with the person, person_alias, encounter, and encntr_alias tables at this point. The personnel table might be new to you. All users and providers in the system will populate this table. Another new table here is the organization table. The hospitals, insurance companies, and employers that are built in the database populate this table. Relationship tables store the relationship between two tables. Take a look at the Person_Org_Reltn table. Think of all the different organizations that you as a patient might be associated with. Blue Cross and Blue Shield might be your insurance company; Cerner would be your employer, and St. Andrews Medical Center might be your hospital. The Person_Org_Reltn table would store your relationship to each of these organizations. Encounter Encntr_Person _Reltn Encntr_Org _Reltn Encntr_Alias
9
The Basic Query Structure
Select from where = Which column (attribute) do you want to see? * = a “wild-card” which selects the entire row of attributes Qualifies your select statement based on a specific attribute of the table and a data value Which table do you want to search from? Let’s take a few moments to review the basic CCL query structure. This generic template can help you create very specific select statements. What you see noted in black will be the same for all queries. The items listed in red will vary depending on what you are looking for. All queries begin with select, which helps you define what information you would like to see. Next you need to specify which columns you would like returned from the query. For class exercises, use the wildcard or asterisk. This will return all columns on the table you select. The word from needs to directly follow the asterisk. Next you will enter the table name where the information you are looking for resides. For example, if you were looking for a person’s first name, you would put in the table name of Person here. Person is the name of the table where the first name can be found. If you are writing a detailed select statement, the qualifying word where will follow the table name. The next step in creating the select statement is substituting the information that you know. If you were asked to find the first name of the person with person_id 200, you would know that the column name is person_id. The equal sign must be present and followed by the data value, which you know is 200. Your select statement for this example is…. Select * from person where person_id= This would return the row on the person table that has the person_id of 200.
10
Steps to Understanding Queries
3. What is the connection between these tables? A direct relationship may exist The PERSON and PERSON_ALIAS tables share the attribute, person_id An indirect relationship may exist The PERSON and ENCNTR_ALIAS tables are related through attributes on the ENCOUNTER table PERSON ENCOUNTER ENCNTR_ALIAS person_id name_last_key name_first_key active_ind sex_cd birth_dt_tm encntr_id person_id (FK) active_ind reg_dt_tm encntr_alias_id encntr_id (FK) alias active_ind contributor_source_cd Indirect relationship example: If I had a person name and wanted to retrieve their encounter aliases, I’d need to go through the encounter table. First, I’d need their person_id from the person table. Then, I’d use the person_id to retrieve the encntr_id on the encounter table. Finally, I’d use the encntr_id on the encntr_alias table to retrieve the alias.
11
What questions do you have?
This concludes the Data Model presentation. Millennium Fundamentals
Similar presentations
