In hospitals, a lot happens behind the scenes to make sure doctors, nurses, and administrators get the right information at the right time. One important part of that is reporting — turning raw data into useful summaries that support patient care and hospital operations.
This blog gives a clear picture of how reports are created using CCL (Cerner Command Language) and the Millennium database, based on real project work done in the field.
What Is CCL and What Is Millennium?
Cerner Millennium is the system that stores all kinds of hospital data patient info, lab results, visits, medications, and more. Think of it as a huge digital filing system for everything that happens in a hospital.
CCL (Cerner Command Language) is the tool used to pull information from this system. It works like SQL, but it's built specifically for Cerner. Using CCL, developers can write code that fetches data, organizes it, and shows it in a way that makes sense for the people using it whether that’s a nurse on the floor or an admin in the office.
The Process: How Reports Are Built
Here’s a step-by-step view of how reports are created in a real-world Cerner setup.
1. Understanding What’s Needed
The process usually begins with a request. It could be:
“We need a report that lists all patients with abnormal lab results in the last 3 days.”
or
“Can you update the existing report to show extra details like allergy or medication info?”
This step is about asking the right questions, understanding what exactly is needed, and making sure nothing important is missed. It's the most important part — because a clear understanding saves time later.
2. Finding the Right Data
Once the request is clear, the next step is to figure out where that data lives in the system.
For example:
-
Patient names and details → in the
persontable -
Visit info → in the
encountertable -
Lab results → in
clinical_event -
Department or location info → in
nurse_unitorlocation
Understanding how these pieces connect is key. Most reports require data from multiple tables, so the relationships (like using person_id or encntr_id) have to be mapped correctly.
3. Writing the Report in CCL
This is where the actual coding begins.
Here’s a simple example of CCL code that pulls lab results:
In real projects, the code is more complex. It may include:
-
Conditions for filtering data
-
Formatting for better readability
-
Logic to handle missing or duplicate information
-
Use of temporary tables for better performance
The main goal is to write clean, efficient, and accurate code.
4. Testing and Feedback
After writing the report, it’s tested using real data in a test environment. This helps catch issues early — like missing results, wrong filters, or performance delays.
Once the initial version is ready, it's shared with the person or team who requested it. They review it and provide feedback. Sometimes this leads to a few changes — adding or removing columns, adjusting the time range, etc.
5. Moving to Production
Once everyone is satisfied, the report is moved to the live (production) environment. This means it becomes part of the hospital's real system.
Depending on the use case, the report can be:
-
Run on demand
-
Scheduled to run daily or weekly
-
Sent by email to specific users
-
Shown as part of a dashboard
Access is also controlled so that only the right people can view or run the report.
Why This Work Matters
These reports aren’t just numbers on a screen. They:
-
Help nurses track patient conditions
-
Help doctors avoid delays or mistakes
-
Support hospital teams in planning and safety
-
Save time for people on the ground
When done well, a report becomes an invisible helper that improves patient care and reduces manual work for staff.


