These technologies are changing how clinical teams work, helping them analyze information more quickly, automate processes and make decisions with greater confidence.

The potential is significant. If we can reduce the time it takes to design studies, understand emerging results and make decisions, we can ultimately shorten the journey from discovery to patient impact.

But there is a part of that journey that receives considerably less attention.

The time it takes to get the data ready.

This may not sound like the most exciting part of clinical development, but it is becoming increasingly important. Before teams can analyze data, share it with decision-makers or use it to support AI-enabled workflows, they need to bring it together, standardize it and understand it. Teams need to understand its provenance, trust its quality and trace the transformations it has undergone.

That has always been true. What has changed is the scale and complexity of the problem.

A modern clinical study can draw information from electronic data capture systems, laboratories, imaging platforms, wearables, external data providers and real-world data sources. Each brings potentially valuable information, but each can also introduce different structures, standards and requirements.

Bringing those sources together is not simply a matter of moving data from one system to another. It involves understanding what the data means, applying appropriate standards, maintaining its lineage and ensuring teams can ultimately use it with confidence.

And as the volume and variety of clinical data increase, so does the effort required to prepare it.

The AI conversation brings the issue into sharper focus

The growing interest in AI has made this challenge harder to ignore.

Organizations are understandably exploring how generative AI and other forms of AI can help improve productivity, automate repetitive activities, surface insights and support decision-making across the clinical development life cycle. Some of these applications could profoundly change how teams conduct clinical research.

But AI does not remove the fundamental need for good data. In many respects, it makes that need more visible.

AI can process and interpret information at a scale that would be difficult for people alone. But its usefulness still depends on the information people give it and the context surrounding that information. In clinical development, inconsistently defined, poorly structured or difficult-to-trace data can limit how confidently teams can use those capabilities.

That is why organizations increasingly need to consider AI readiness alongside data readiness.

The issue isn’t simply whether an organization has access to AI technology. It is whether the organization sufficiently trusts, standardizes and governs the data underneath the technology to support the decisions that people will ask AI to help them make.

This is an important shift in perspective. Organizations have traditionally viewed data preparation as an operational activity that happens before the more interesting work of analysis begins. But as clinical development becomes more data-intensive and more AI-enabled, that foundation increasingly determines how quickly everything built on top of it can move.

A process designed for a different era

The traditional approach to clinical data transformation has served the industry well. Teams collect, standardize, transform and review data before eventually preparing it for analysis or submission. Given the regulatory environment in which clinical research operates, there are good reasons for the discipline and control that the process requires.

The problem is that the environment around it has changed.

Clinical teams are working with more data sources, more complex studies and a wider range of analytical requirements. Teams may now need data they once prepared for a particular downstream purpose to support multiple analyses, different teams and new forms of automation. Organizations increasingly want to reuse data rather than repeatedly prepare it for individual projects.

That creates an interesting question.

Instead of continually asking how to prepare a particular data set for the next stage of a study, what if we asked how to build a clinical data foundation ready to support whatever comes next?

That is a subtle difference, but an important one.

It moves data transformation away from occurring at specific points in a process and toward becoming a capability that continuously supports the process.

From data preparation to data readiness

There are practical benefits to making that shift.

When teams consistently standardize and govern clinical data, they can spend less time resolving inconsistencies and preparing information for individual activities. Analysts can begin their work sooner. Teams can reuse data more easily. Traceability becomes part of the process rather than **something teams have to reconstruct later.

It can also make collaboration easier.

Clinical, statistical, data management and other teams often need to work with the same underlying information, but may approach it from different perspectives. A trusted and consistently governed data foundation provides a common point of reference.

The value, therefore, extends beyond efficiency. It is about creating greater confidence in the information teams use throughout the development life cycle.

That becomes particularly important as organizations introduce more AI and automation into clinical workflows. The more technology participates in interpreting information and supporting decisions, the more important it becomes to understand and trust the data underneath it.

In that sense, data transformation isn’t just preparation for analysis anymore. It is preparation for a much broader clinical development ecosystem.

Rethinking where clinical acceleration begins

Much of the conversation around clinical acceleration has focused on what happens once teams have prepared the data.

How quickly can we analyze it? How quickly can we generate insights? How quickly can we make decisions?

Those questions remain important. But there is another opportunity that sits earlier in the process.

How quickly can we turn the data generated by a study into information we can trust, reuse and apply to support those activities?

If the answer to that question remains measured in weeks or months of manual preparation and repeated transformation, then accelerating everything downstream will only take us so far.

Therefore, clinical acceleration needs to start earlier. Organizations need to connect data transformation, standardization and governance more closely to the subsequent analysis and regulatory activities. Instead of repeatedly preparing data for each downstream use, teams can work from a common, trusted foundation that supports the clinical development process more broadly.

This approach to clinical data transformation shifts the focus from repeatedly preparing data for individual tasks toward keeping data ready for reuse across clinical workflows.

That shift becomes increasingly important as clinical development moves toward more connected and AI-enabled workflows.

The foundation may determine how far we can go

There is every reason to be excited about what AI, automation and advanced analytics could bring to clinical research. They have the potential to change not only how quickly organizations work, but how they work.

But technology alone will not determine who benefits most from those advances.

Organizations also need to consider the less visible infrastructure underneath them: the standards, governance, lineage and processes that make clinical data trustworthy and reusable.

The industry has spent years finding ways to speed up analytics. The next opportunity is to look further upstream and reduce the time and effort required to prepare clinical data so teams can actually use those capabilities.

Because ultimately, the speed of the analysis is only part of the equation.

If we want to accelerate clinical development, we also need to accelerate the journey to trusted, reusable data.

The post The clinical data foundation wasn’t designed for the AI era appeared first on The SAS Data Science Blog.

What happens when a healthcare organization wants to improve operational performance, evaluate process changes before implementing them, and develop computer vision models without relying on large collections of real-world image data? A recent collaboration between SAS and a Danish medical sterilization center explored exactly that question. The project combined process analytics, simulation, digital twin technology, computer vision, and synthetic data generation within a single workflow. What began as an effort to better understand sterilization operations ultimately demonstrated how a digital twin built with Unreal Engine can support both operational decision-making and AI model development. The work was featured at SAS Innovate 2026.

Why sterilization operations matter

Every surgical procedure depends on having the right sterile instruments available at the right time. Even a single delayed instrument tray can result in 10 to 15 minutes of operating room downtime per case. These delays are costly. Operating room downtime is estimated to cost between $20 and $100 per minute. This creates significant operational and financial impact for hospitals. Beyond efficiency, sterilization directly affects patient safety. Failures in sterile processing have been linked to surgical site infections, making process reliability essential.

The Sterile Central facility involved in this project processes surgical instruments for multiple hospitals. The facility is large and primarily automated, but it still relies on human technicians for several critical tasks. Figure 1 provides a generic representation of a sterile central environment, illustrating the types of workflows and equipment interactions involved in such facilities. It currently serves regional hospitals in the capital region and is planning to expand coverage to additional hospitals.

That growth raises an important question: can the existing process handle additional demand as operations scale? Although the full workflow spans multiple floors, the pilot phase focused on the floor where most cleaning and processing took place.

Healthcare organizations are therefore under constant pressure to improve instrument availability, optimize workflows, and maintain high sterilization standards. As the organization plans for future growth, it faces familiar operational questions:

• Can the current process support additional demand?
• Where are the true bottlenecks in the system?
• How should staffing change as workloads shift?
• What operational improvements can be evaluated before making changes in the real facility?

Answering these questions requires more than intuition. It requires a detailed understanding of how materials, equipment, and people interact throughout the process. This is where digital twins and simulation become very valuable. In this blog post, we focus on developing a high-fidelity digital twin to help achieve these goals.

A roadmap for the digital twin journey

We begin by analyzing sterilization-process data, studying the workflow, and identifying important key performance indicators (KPIs) such as subprocess duration, resource utilization, inventory accumulation, and operational bottlenecks. Using these insights, we then build a high-fidelity digital twin of the sterilization facility in Unreal Engine. This virtual environment accurately represents the physical process and serves as a sandbox for experimentation and analysis.

Once the digital twin is built, it becomes the foundation for a second use case: computer vision model development. By leveraging the realistic virtual environment, we can generate synthetic data to train and validate AI models for PPE detection. Together, these use cases demonstrate how a single digital twin can create value across multiple domains, from operational optimization and process improvement to AI model development and workplace safety.

Figure 2 summarizes this project roadmap, showing how process analytics supports digital twin development and how the resulting virtual environment enables synthetic data generation for computer vision.

Building a digital twin starts with data

Before developing the digital twin, we first analyzed historical process data to understand how the facility operated. At a high level, every instrument tray moves through four main steps: unpack, pre-wash, wash, and pack. Each tray arrives from the buffer lift in a container. After unpacking, trays and containers follow separate routes until both are sterilized and a packing robot brings them back together at the end of the process flow. Instrument trays, containers, wash racks, conveyors, and automated guided vehicles interact throughout the process, creating a system that is simple to describe but complex to model.

To build an accurate model, the analysis combined information from two data sources:

• Process-scan records that tracked how trays and containers moved through the facility.
• Equipment activity records that captured utilization and operational behavior of key resources

Together, these sources created a detailed picture of both material flow and equipment performance. The analysis focused on the following four questions, as outlined in Figure 3:

1. How long does each subprocess take?
2. How are trays and containers routed through the facility?
3. Where does inventory accumulate?
4. How do staffing requirements change under different operating conditions?

The insights gathered from answering these questions ultimately provided the parameter estimates and behavioral assumptions required for the digital twin.

Finding the real bottleneck

One of the most interesting findings involved identifying the bottleneck. At first glance, washing seemed like the obvious constraint because washing cycles consumed the most processing time. However, long duration alone does not necessarily indicate a bottleneck.

To understand where congestion forms, we first checked whether a system-level Little’s Law estimate matched a historical flow-balance estimate based on cumulative arrivals and departures. We obtained the historical estimate directly from the process-scan records by tracking how inventory changed as trays entered and left the system over time. In parallel, we calculated the Little’s Law estimate at the overall system level by combining the average arrival rate with the average time trays spent in the process. The two estimates differed by only 0.8%, increasing confidence that Little’s Law reasonably approximated the observed system behavior. Once we confirmed this relationship at the system level, we extended the Little’s Law analysis to each major process step, combining arrival rates with the average time trays spent in each stage.

This step-level view let us determine where work-in-process was accumulating, rather than relying only on activity duration: Inventory was not building up ahead of the washing stations as expected. Instead, it concentrated downstream between washing and packing. In fact, the stage between the washing machine and packing table accounted for about 65% of total expected system inventory, underscoring the distinction between the longest activity and the true flow constraint.

Figure 4 shows the expected share of long-run inventory associated with each step in the process flow. Each bar corresponds to one process segment, with the horizontal axis showing that segment’s percentage contribution to total expected inventory. The result makes the downstream accumulation visible: Step 7, which represents the flow between the washing machine and packing table, accounts for the largest share of expected inventory. This visual comparison reinforces why the bottleneck assessment focused on where work was accumulating, not simply on which activity had the longest processing time. This distinction was important because it shifted attention from individual processing times to how inventory moved through the full system.

Traditional process reviews often focus on the longest activity. The analysis demonstrated that understanding flow behavior requires examining inventory, routing patterns, and staffing simultaneously. In this case, the evidence suggested that staffing allocation and downstream workflow management may have greater impact on throughput than additional washing capacity.

Insights like these become especially valuable as inputs to a digital twin environment designed to support the future testing of operational alternatives.

Creating a high-fidelity digital twin

The next step was to transform the operational analysis into a digital twin built in Unreal Engine. The resulting virtual environment reproduces the physical sterilization facility in extraordinary detail. The level of visual realism was important for two reasons. First, it helped stakeholders recognize the real workflow in the virtual environment. Second, it made the later computer-vision work possible. Visual realism enabled comparison with real footage of people working in the facility and used the virtual environment as a realistic setting for generating synthetic data.

Instrument trays move through conveyors. Washing stations operate according to observed processing characteristics. Personnel interact with equipment throughout the workflow. To make the virtual environment operationally grounded, the digital twin required more than a visual model. It also needed data-driven parameters, including distributions of processing times, conveyor speeds, washing-machine cycle times, equipment failure behavior, and locations where inventory accumulated in the flow. The operational analysis described earlier, which examined the issues summarized in Figure 3, provided these inputs, allowing the digital twin to reflect both the physical layout and the key observed patterns in the facility’s operations.

While photorealistic visualization attracts immediate attention, the most important aspect of the digital twin is not only what people see, but what they can test. The longer-term value lies in creating a virtual experimentation environment that can support future what-if analysis. This would include exploring alternative staffing policies, studying the potential impact of equipment downtime, investigating future capacity needs, and assessing operational changes before implementing them in the real facility. In this way, the digital twin becomes a decision-making sandbox. Compared with a stand-alone simulation model, the digital twin adds value by connecting process logic to a realistic visual representation of the facility. This makes operational scenarios easier to communicate to stakeholders and enables the same environment to support synthetic image and label generation for computer vision model development.

A second use case emerges: Synthetic image data generation

Once the digital twin was built, the project expanded beyond operational analysis. This raised a new question: Could the same digital twin generate synthetic data for computer vision model development? The answer was yes.

We selected a healthcare-specific personal protective equipment (PPE) detection use case. The objective was to determine whether personnel entering controlled sterilization areas were wearing required protective equipment, including medical gowns, masks, and hair nets. Figure 5 shows an example of a MetaHuman wearing medical PPE in the high-fidelity digital twin environment.

Traditionally, developing such models requires collecting real-world images, manually labeling thousands of observations, addressing privacy concerns, and managing data access restrictions. The digital twin offered a different approach. Using Unreal Engine, synthetic workers could be generated automatically with varying appearances, PPE configurations, camera angles, camera mounting positions, fields of view, lighting conditions, and environmental settings. Because the simulation environment already knows the location of every object, it can automatically generate corresponding labels and annotations. This eliminated one of the most time-consuming aspects of computer vision development.

Figure 6 shows a metahuman entering the sterilization zone from the target camera perspective, wearing different combinations of medical PPE. The bounding box coordinates and labels shown are produced automatically by the digital twin application.

Training models without real-world images

Perhaps the most striking aspect of the project is that the computer vision model demonstrated during the project was trained exclusively on synthetic imagery. The model never saw a real-world training image. Instead, automated scenario creation generated thousands of annotated synthetic images. We used these images to train PPE detection models. We then evaluated them against real-world footage from the customer environment. This is shown in Figure 7.

The real-world footage initially indicated that the model trained on synthetic data could successfully generalize to the customer setting, although a more detailed evaluation would require a clearly defined ground-truth labeling process and quantitative performance metrics.

The approach highlights several advantages:

• Reduced dependence on customer data.
• Fewer privacy and security concerns for customers.
• Faster, automated generation of high-quality labeled data.
• Greater ability to include selected rare scenarios, edge cases, and class-balance conditions in the synthetic data generation process.
• Increased dataset variation through controlled changes in scenes and camera perspectives.
• Improved portability of trained models across different customer environments.

Rather than repeatedly collecting and labeling new image datasets for every deployment, organizations can create digital environments that produce training data on demand.

Looking beyond healthcare

Although this project focused on sterilization operations, the broader lessons extend well beyond healthcare. The same digital twin framework can support manufacturing operations, logistics networks, warehouse environments, transportation systems, supply chains, and industrial safety monitoring applications.

The project also illustrates a larger trend in analytics and AI development. Digital twins are evolving beyond visualization tools. Increasingly, they serve as decision-support environments, experimentation platforms, and synthetic data generators. In many situations, the digital twin itself becomes a bridge between physical operations and AI development.

Final thoughts

This project demonstrated the power of combining process analytics, simulation, digital twins, and AI within a single framework. The operational analysis helped identify opportunities for improving sterilization workflows. The digital twin created a realistic environment for experimentation. The same virtual environment then enabled the development of computer vision models using synthetic data rather than manually labeled images. As a foundation for future work, the project also identified clear next steps. This includes expanded scenario testing, more formal what-if analysis, and quantitative evaluation of computer vision performance on real-world footage.

What began as an operational improvement initiative evolved into a demonstration of how modern digital twins can support both decision intelligence and AI innovation. As digital twin technology continues to mature, organizations may discover that the most valuable output is not the virtual model itself, but the insights, experiments, and AI capabilities it enables.

To learn more about related SAS work, readers can explore additional resources on industrial safety applications, synthetic image data and model development, and digital twins for manufacturing. Together, these resources provide broader context for how the concepts discussed in this blog apply across industries.

The post Building a healthcare digital twin for operations and AI innovation appeared first on The SAS Data Science Blog.

Connecting Claude to Viya

The starting point was the Model Context Protocol, or MCP, which exposes a set of tools that let Claude talk directly to a running Viya environment: submitting SAS code for execution, listing and downloading files, querying CAS tables, and checking on compute sessions and jobs. In practice, this meant Claude could act as a developer with real hands on the environment — writing a SAS program, running it, reading the log, and iterating — the same loop a person would go through in SAS Studio, but conversational.

That connection mattered for a design decision made early on: rather than building a separate web server, the app itself would be hosted inside Viya's own Files Service. Every file — the HTML page, its stylesheet, its JavaScript — lives as a file object in Viya and is served back over the same domain the browser is already talking to. That "same-origin" trick avoids a whole category of cross-origin (CORS) headaches that show up the moment a web app tries to call a separate API server, and it means there's nothing extra to deploy or maintain outside of Viya.

Designing the app itself

The interface itself is intentionally plain: a single order screen. One panel lets a customer pick beer styles, pack sizes, and quantities; the other collects delivery details — address, customer type, and a delivery time window. Submitting an order pushes it into the browser's local memory and, behind the scenes, syncs it to CAS tables in Viya. Below is an "Operations" section with two buttons: one to run the routing optimization, one to reset everything and start over. Once routing has run, a Results panel appears showing the solved routes.

Keeping this to plain HTML, CSS, and JavaScript — no framework, no build step — was a deliberate choice. It keeps the whole thing inspectable as a handful of files sitting in Viya's Files Service, and it means the app can be updated by simply replacing those files' contents, which is exactly the loop Claude used throughout development: write the code to create the web app and integrate it to SAS Viya, deploy it as a file update, verify it downloaded correctly, and check the result live in the browser.

Talking to CAS

The mechanism for getting order data into SAS is simple by design. Rather than building an API layer, the browser submits a small SAS program directly to a Viya compute session through the Compute service's REST endpoints. That program embeds the order data as inline SAS DATALINES, reads it into two tables — one for customers, one for order line items — and saves them into CASUSER with promote=yes, so the tables are immediately visible to any other session on the server, not just the browser's own. Before every push, the app first drops any existing versions of those two tables, so each "Submit order" and each "Reset" leaves CAS in a clean, predictable state rather than accumulating stale data. As the web app can be used by many users at the same time, all data is saved in CASUSER, so each user sees its own orders, routings and maps.

Running the routing solver

Once orders are collected, clicking "Simulate the optimal routing" submits a second, larger SAS program to that same compute session. After re-pushing the current orders, it uses %include to run the existing VRPTW solver program unchanged — the app doesn't reimplement any optimization logic, it just triggers the program that already exists on the server's file system, pointed at the CAS tables that were just populated. That program does the real work: building the network model, applying time-window lower and upper constraints, average speed, time to load and unload the goods, vehicle capacity, and produces an optimized route assignment as a CAS table, VRP_SOLUTION, along with an interactive route map written out as an HTML file with all itineraries.

Getting the results back to the browser

This is the part that took the most iteration. A compute session's REST API doesn't hand back a table as a tidy JSON payload by default — the practical channel is the session's own log. So, the SAS code sorts the solution table by route and stop sequence, then writes each row out as a specially tagged log line (ROWCSV:) that the JavaScript on the other end knows to scan for and parse into rows for the on-screen table, complete with arrival and departure times, service windows, and travel times for each stop.

The route map took a similar approach but needed an extra trick. Viya's log has a fixed line-length limit, and the map file — a self-contained Leaflet-based HTML page with an embedded route — has plenty of lines longer than that. The fix was to have SAS chunk every line into short pieces tagged so the browser could stitch them back into an exact reconstruction of the original file, rather than losing anything to truncation.

The bigger point

What made this workable wasn't any single clever trick, but the tight loop of writing code, deploying it, and verifying it against the live environment, with a person steering priorities and approving each change along the way. It's a pattern that will generalize well beyond the vehicle routing problem with time window showed here: any existing SAS program for optimization, forecasting, econometrics, or even predictive modeling can gain a lightweight, purpose-built front end this way, hosted entirely inside Viya, with no separate infrastructure to manage. This front end can be seen as an excellent approach to simulate and visualize SAS programs outcomes in a very interactive and user friendly fashion.

The division of labor is what made that loop fast. The optimization model, the business rules and the final say stayed with the person who owns them. Claude took on the development that usually slows down projects like this: REST calls, security tokens, deployment scripts, and all the checks that confirm each change was actually comitted. Nothing runs against Viya without the code and the reasoning being shown first, and most important, approved. This keeps the entire work very transparent. And the best part: each obstacle along the way became a documented pattern, ready for the next project or application.

There is still room to grow, as always. The model could re-optimize as new orders arrive during the day, combining pickups and deliveries, or size the fleet from typical demand. None of this requires rethinking the architecture, only modifications to the SAS program and eventually a few more fields and checks to the web application.

The broader takeaway is that the front end no longer has to be the expensive part of putting a model in front of the people who use it. Many organizations already own SAS programs that answer important  business questions but only reach whoever can run the code. With Claude connected to SAS Viya through MCP, and a person approving each step, those programs can become purpose-built apps in days rather than months, hosted where the data and models already live.

Learn more

• Ask the Expert webinar: Claude the Programmer
• Latitude, Longitude, and SAS: The Many Ways to Geocode Data in SAS Viya
• How Much Farther? Calculating Distance in SAS

The post Building a vehicle routing problem app on SAS Viya with Claude as the developer in the loop appeared first on The SAS Data Science Blog.

Understanding where programs are already making an impact is one part of the picture. The next step is looking ahead to where additional outreach and resources could make a difference. For our analytics initiative supporting the Kay Yow Cancer Fund, we brought together public health data from various sources to identify locations for community outreach, education and cancer screening programs.

The data came in many formats from different federal health agencies: Excel files, flat files, ZIP archives, downloadable CSVs and REST APIs. Each source had its own structure, update cycle, and technical requirements. Luckily, all sources published their data at the county level, so we had a common key to bring them together.

Individually, these datasets provide valuable insights. Together, they can reveal something more useful: where cancer burden, social vulnerability, screening access and existing resources intersect. Simply downloading and integrating these diverse data types can quickly overwhelm organizations, especially those without a dedicated data engineer or someone experienced with data.

For this project, we used SAS^® Viya^® to integrate multiple sources for analysis and visualization.

The public health data challenge

Many health datasets are publicly available, but their formats vary. We incorporated several sources for this project. Each source provides a different view into overall community health.

• U.S. Census Bureau American Community Survey (ACS), which provides demographic data through a REST API in JSON format.
• The CDC Social Determinants of Health (SDOH) datasets in Excel files.
• The National Cancer Institute (NCI), which provides cancer incidence and mortality rates in CSV files.
• The FDA provides mammography screening facility data in a TXT file within a ZIP folder.

ACS data helps quantify population characteristics and demographics. CDC SDOH data highlights factors such as economic conditions, education, transportation and health care access. NCI data show where cancer incidence and mortality rates are high and increasing or falling. The FDA mammography facility provides physical screening locations to help address breast cancer prevention needs and identify service gaps. We also leveraged data on Kay Yow grant recipients to show where community investments already exist.

No single dataset can tell the Fund where outreach is needed most. Looking at them together, however, begins to show where high cancer burden may overlap with social vulnerability, lower screening rates and gaps in access to care.

For the Kay Yow Cancer Fund, we set out to create an analytical and interactive dashboard to identify counties with high rates of different types of cancer, high levels of social vulnerability and low rates of cancer screening and prevention to plan EmPOWERment Tours. The Tours provide communities with cancer education, screening awareness and access to local health resources.

The dashboard provides the Fund with another way to identify communities where outreach, education and screening resources could have the greatest impact.

Connecting data across formats

Answering that question first required us to bring very different types of data into the same environment.

For this project, we used several techniques to ingest the data:

• We downloaded and processed Census API data using PROC HTTP.
• We retrieved CDC datasets directly from downloadable CSV endpoints.
• We read ZIP archives published by the FDA and other Federal Agencies.
• We loaded all datasets into SAS Viya for scalable analytics and visualization.

The code and scripts are relatively straightforward because SAS provides the capabilities needed to interact with modern data sources, such as REST APIs and less modern but still valuable ones, such as flat files.

What I love the most about SAS is that, as a data analyst, I can develop a script that reads in these data sources directly into the platform for integration, analysis and visualization. I don’t have to download a file, upload it to a server and then import it to SAS. All I need to do is save my script program file and I can rerun the code if I change environments or the data refreshes.

As a bonus, I can keep all my scripts in a single GitHub repository that integrates with SAS Data and AI Studio – my personal preference for a SAS programming IDE – and with VS Code.

Back to the coding techniques I used in this project.

PROC HTTP lets me interact directly with web APIs and data services without requiring additional tools. It supports standard HTTP methods, including GET and POST, and lets me access REST APIs and web services directly from SAS programs.

After more than 15 years of programming in SAS, I think PROC HTTP may be my favorite PROC.

The following shows how to access the Census ACS data in JSON format as an example. SAS has a purpose-built access engine that reads JSON files and presents them like a traditional SAS table.

The code uses the following SAS procedures and statements:

• FILENAME statement
• PROC HTTP
• LIBNAME statement with the JSON engine
• DATA step

ACS data is very wide, with non-descriptive variable names, so after this initial ingest step, we need to perform post-processing and apply variable labels. Luckily, the JSON library also includes descriptive variable labels for each variable code, making it a convenient one-stop shop!

Similarly, federal agencies sometimes publish compressed files. SAS provides FILENAME ZIP functionality that allows programs to inspect and extract ZIP contents programmatically within SAS workflows. This blog post by Chris Hemedinger provides an excellent example of using FILENAME ZIP to access data files stored in ZIP archives without relying on external utilities. I used his approach to develop the script below for reading FDA mammography facility data.

The following code demonstrates how to download a compressed file from the FDA and use the SAS ZIP filename method to read mammography facility data directly from the archive.

The code uses the following SAS procedures and statements:

• Macro variables and functions
• FILENAME statement
• PROC HTTP
• DATA step
• INFILE and INPUT statements
• INFORMAT, FORMAT and LABEL statements

These capabilities allow data engineers and analysts like me to spend less time wrestling with file formats and more time understanding what the data can tell us.

Creating a common geographic language

Bringing the datasets into one environment solved one problem. Making them speak the same geographic language created another.

Every data source can describe geography differently. One data set may contain county names. Another may contain five-digit ZIP Codes. A third may provide latitude and longitude coordinates. Others may use state and county FIPS codes.

Without standardization, we can’t accurately combine the datasets.

In this project, we chose the county FIPS code as our common key. We then used text functions to concatenate the state and county FIPS codes to create our key codes and a unique geographic identifier.

That common identifier helped us to analyze demographic data, social determinants, metrics, health care access information and Kay Yow Cancer Fund grant recipient information together at the county level.

Now we could move beyond isolated statistics and see how different conditions overlap within the same community.

Bringing it all together with mapping and visualization

After we connected the datasets, we could look at demographic indicators, social determinants, health care resources and the Fund’s existing investments together.

That’s where the data starts becoming useful for the Fund.

Rather than reviewing cancer rates, screening access, social vulnerability and existing investments separately, the Fund can ask how those factors intersect within individual communities.

For example:

• Which counties have elevated social risk indicators, high cancer incidence rates and low cancer screening rates?
• Do those counties have local or mobile mammography facilities?
• Which communities with low cancer screening rates sit near Kay Yow Cancer Fund grantees?
• Where might additional outreach programs have the greatest impact?

Those questions shift the analysis from understanding individual datasets to understanding communities.

The bigger opportunity

While this example focuses on the Kay Yow Cancer Fund’s mission to improve cancer screening and community outreach, the underlying lesson applies much more broadly.

Important questions rarely live in one single data set.

Understanding where a community needs support may require organizations to consider health outcomes alongside demographics, economic conditions and access to existing services and resources. Any one of those factors provides only part of the picture.

For the Kay Yow Cancer Fund, bringing them together creates a stronger understanding of where programs already make an impact and where future community outreach efforts might provide the greatest benefit.

That's also how this work builds on what came before it. Measuring impact helps us understand what programs have already accomplished. Connecting that evidence with the conditions communities face can help inform what happens next.

The goal is not simply to collect more data. The goal is to connect the right data so organizations can see what they couldn’t before and make better decisions as a result.

Support the Kay Yow Cancer Fund

Help advance the Kay Yow Cancer Fund’s mission to improve outcomes for women facing cancer through research, education and access to care.

Learn more about the Kay Yow Cancer Fund →

Hear more perspectives on health care

Join us for The Health Pulse podcast as we explore fresh perspectives on digital transformation, data and innovation across health care and life sciences.

References

• Chris Hemedinger, Using FILENAME ZIP to unzip and read data files in SAS (May 11, 2015) https://blogs.sas.com/content/sasdummy/2015/05/11/using-filename-zip-to-unzip-and-read-data-files-in-sas/
• SAS Documentation, Overview: PROC HTTP : https://documentation.sas.com/doc/en/pgmsascdc/v_078/proc/n0t7v16eitluu2n15ffpfeafqszs.htm

The post Can data show where cancer outreach is needed most? appeared first on The SAS Data Science Blog.

In Part 1 of this series, we toured the model zoo. We covered what separates LLMs, SLMs, VLMs, reasoning models, and diffusion models, and the deeper split between discriminative and generative approaches. Knowing which model to reach for is a good start. But a model on its own is inert. It answers when spoken to, and that is the whole of the interaction.

This post covers the two layers that sit on top of the model and largely determine what an AI system can actually accomplish. The first is autonomy: how much initiative the system takes, what it is permitted to touch, and how much human oversight it requires. The second is the plumbing: the standards and structures, namely Skills, the Model Context Protocol, and the agent harness, that let a model reach beyond its own context window and take action in the world.

Both layers are where much of the recent terminology explosion has landed, and both are where the distinctions matter most in practice.

The Autonomy Spectrum: Chatbots, Copilots, and Agents

Another area ripe for confusion is the spectrum of AI autonomy. The terms chatbot, copilot, and agent get used loosely, but they describe meaningfully different levels of capability and independence.

Chatbots are the most familiar. They are reactive, conversational interfaces that wait for a prompt and generate a text response. No tool access, no persistent state beyond the current conversation window, no ability to take action in the world. Ask a chatbot a question, and it answers. That is the extent of the interaction. Most consumer-facing AI assistants still operate at this level.

Copilots represent a step up. A copilot augments human work by suggesting actions: code completions, document edits, analytical next steps, dashboard configurations. The critical distinction is that the human remains in control. The model proposes; the human takes action. GitHub Copilot suggests code completions, SAS Viya Copilot recommends model pipeline configurations, and an AI assistant drafting an email for your review are all copilot-level interactions. Copilots accelerate human productivity without removing human judgment or approval from the process.

Agents are where the real paradigm shift occurs. An agent operates autonomously in a loop: it plans, takes action by invoking tools, observes the results, and decides what to do next. The critical differentiator between a copilot and an agent is autonomy plus tools. Instead of proposing the next step for a human to accept, an agent executes its own plan against external systems. That said, autonomy does not mean unchecked capabilities. It is often wise and prudent to design agents so that any potentially destructive or irreversible actions, such as deleting data, sending communications, modifying production systems, or committing financial transactions, are gated behind explicit human review and approval. Only after an agent has proven itself reliable should these gates be relaxed, and even then, only in a very controlled and observable way.

The best agent architectures make this easy by design, enabling routine read-only and low-risk operations to flow freely while surfacing high-stakes decisions to a human for confirmation. The goal is not to hobble the agent but to ensure that the speed and scale of automation never outrun human judgment on the actions that matter most.

To paraphrase Andrej Karpathy, from his YouTube clip, “[With AI] we can outsource intelligence, but we cannot outsource our understanding or responsibility.” Table 1 compares and contrasts these tools.

Table 1: The Autonomy Spectrum -- Chatbots, Copilots, and Agents

The Plumbing: MCP, Skills, and Harnesses

If model architecture and autonomy define what an AI system can do, the plumbing defines how it does it. Three concepts have emerged as the foundational building blocks of modern agentic systems, and understanding the distinction between them is essential.

Skills

Skills are reusable, file-based definitions of repeatable workflows. Typically, a skill is simply a Markdown file with natural language instructions. Whereas a tool is a single function (call an API, run a query), a skill can encapsulate an entire workflow: search relevant documents, summarize them, format the output, and present it to the user. If tools are functions, skills are modules composed of multiple functions that an AI agent can understand and follow.

Model Context Protocol (MCP)

MCP is an open standard introduced by Anthropic and has been widely described as "the USB-C of AI" because it standardizes how agents connect to external tools, data sources, and services.

Before MCP, every tool integration was bespoke. Connecting an agent to Slack required custom code. But connecting it to a database required different custom code. Connecting it to a file system required even more custom code. MCP eliminates this fragmentation. Build an MCP server on the tool side once, and every AI client that supports the protocol (Claude, ChatGPT, VS Code, etc.) can connect the same way.

At its core, MCP is a combination of workflows, tools, and reference documentation. However, it lets you to easily connect your AI agent to 3rd-party tooling and APIs without having to know how to call them programmatically. The LLM handles that aspect.

Skills vs. MCP: When to Use Which

Because skills and MCP both extend what an agent can do, it is natural to wonder when to reach for one versus the other.

Use skills when you have a repeatable process or tightly scoped workflow that you want to codify and reuse. "Analyze a clinical trial data set, flag anomalies, and generate a summary report" is a skill. So is "run the quarterly compliance check against these five data sources and produce a formatted findings document." Skills encapsulate business logic, sequencing, and output formatting into a self-contained unit that can be invoked reliably every time. They are well suited for local execution where security and authentication are not primary concerns: file manipulation, text processing, data transformation, or any workflow that operates on data already within the agent's environment.

Use MCP when you want to enable users to interact with your tools or APIs via conversational natural language instead of programmatic commands, and you want to do so across different environments. This is the key shift MCP unlocks. Rather than requiring a user to know the right API endpoint, construct a query, or navigate a CLI, they simply describe what they need in plain English.

The agent then translates that intent into the appropriate tool calls through MCP. "Show me last quarter's revenue by region" becomes a natural language request that MCP routes to the right database query, analytics API, or reporting service behind the scenes. MCP is designed for remote tool calling across authenticated gateways, handling the handshake with external services, managing credentials, and respecting access controls, making it the right choice when the agent needs to reach beyond its local sandbox into enterprise systems, third-party APIs, or cloud services that require governed authentication.

That doesn't mean the two are mutually exclusive. A skill might orchestrate several MCP tool calls under the hood, or an MCP server might utilize embedded skills. The line is blurry, but generally, skills define the workflow while MCP provides the integration. Table 2 provides more context and differentiation.

Table 2: Skills vs. MCP -- When to Use Which

Harnesses

Another term you may have heard thrown about is “harness”. A harness is the complete runtime infrastructure wrapping an AI model: the orchestration loop, tool dispatch, memory management, context assembly, error handling, and guardrails. Martin Fowler and Birgitta Böckeler of ThoughtWorks crystallized this with a simple formula: Agent = Model + Harness. The model provides the intelligence; the harness provides the structure that makes that intelligence reliable and useful.

A useful way to think about this is with a car analogy. The model is the engine, but the harness is the rest of the vehicle. An engine by itself sits on a shop floor and spins. It takes a chassis, steering, brakes, a transmission, and a dashboard to turn that raw power into something that actually gets you where you need to go safely. The harness provides the steering (context assembly and tool routing), the brakes (guardrails and human-in-the-loop gates), the transmission (memory and state management), and the dashboard (observability and logging). Swap in a more powerful engine and the car gets faster, but without the rest of the vehicle, horsepower is just noise. And crucially, good harness design is modular: as models improve, components of the harness that compensate for model weaknesses can be removed. Table 3 spells out this analogy explicitly.

Table 3: The Harness as a Car Analogy

An excellent blog post by the author of bits-bytes-nn, titled "From Prompts to Harnesses: Four Years of AI Agentic Patterns," traces the evolution of AI engineering rigor over the past few years across three distinct eras:

•  Prompt Engineering (2022-2024): "What should I say?" The industry believed instruction quality was the sole determinant of AI response success.
• Context Engineering (2024-2026): "What information should I provide?" The realization that what fills the context window and is available to the AI agent matters more than the prompt itself.
• Harness Engineering (2026+): "What system should I build?" The acceptance that the design of the entire system is the real problem to be solved. And that intelligent systems can make up for inadequate models.

The core thesis is compelling. As agentic AI proliferates within software development, engineering rigor does not disappear. Rather, it relocates to a higher level of abstraction. This covers writing code, curating context, and designing the environment in which agents operate. For analytics and data science practitioners, this pattern is familiar. It mirrors the evolution from hand-coding statistical models to configuring automated pipelines to designing governed analytical ecosystems. The abstraction level rises, but the need for rigor remains. Table 4 summarizes this recent history.

Table 4: Three Eras of AI Engineering

Coming Up Next

Autonomy and plumbing determine what an agent can do. The next question is what it knows. Part 3 turns to retrieval: how to ground a model in your own enterprise data, and how standard RAG, knowledge graphs, and the newer PageIndex approach compare when you need answers that are accurate, traceable, and defensible.

Additional Resources

• Anthropic: Building Effective Agents
• Anthropic: Harness Design for Long-Running Application Development
• From Prompts to Harnesses: Four Years of AI Agentic Patterns
• Martin Fowler / Birgitta Böckeler: Harness Engineering
• Andrew Ng: Agentic AI Design Patterns
• Model Context Protocol (MCP)

Blog Series:

• Part 1: The Model Zoo: LLMs, SLMs, and VLMs, Oh My!
• Part 2: From Chatbots to Agents: The Autonomy Spectrum and the Plumbing Beneath It

The post From Chatbots to Agents: The Autonomy Spectrum and the Plumbing Beneath It appeared first on The SAS Data Science Blog.

As technology continues to evolve rapidly, ethically centered model design is becoming increasingly important. In this post, we provide a brief overview of SAS Models and describe how all SAS models are built using SAS’ core principles for responsible innovation.

The SAS Applied AI and Modeling division is focused on designing and building trustworthy, industry-focused models. Drawing on decades of SAS expertise, these models help organizations solve complex business challenges with proven approaches. Examples of business problems addressed include:

• Credit Card Fraud
• Payment Integrity for Food Assistance
• Entity Resolution
• Medication Adherence
• Supply Chain Optimization
• Industry Safety
• Document Analysis

Challenges around building ethical AI models

Currently, no single global standard exists for designing ethical AI models. When organizations fail to clearly document assumptions and risks, AI models often become opaque, difficult to explain, and hard for users to trust. Given these challenges, the SAS Model development group collaborates with industry experts, consults the SAS Ethics Committee, and applies the SAS core principles for responsible innovation when developing our models.

SAS core principles for responsible innovation

The SAS core principles for responsible innovation include human-centricity, inclusivity, accountability, privacy and security, robustness, and transparency. SAS incorporates these principles into the selection, design, and function of all SAS Models. Over the next few sections, we will highlight each core principle and provide examples of how our models take into account each of these principles during design and implementation.

Human centricity: Promote human well-being, human agency and equity

SAS puts people first by developing models that improve well-being. For example, we have built models to support worker safety in the manufacturing industry, medication adherence risk in the health care industry, and payment integrity in the public sector. Each of these models focuses on using data to improve the human condition or help ensure services reach the right people.

Additionally, SAS designs its models with end users in mind. Model pipelines allow end users to control and review the data used to train and develop models. This helps ensure the model reflects their specific population, use case, and business use case.

Lastly, SAS Models are also designed to help eliminate bias and promote equity. For instance, the medication adherence risk model incorporates SAS procedures that assess the model for bias across sensitive variables such as race and gender. By incorporating bias assessments into model design, we enable end users to examine and control for equity during model deployment.

Inclusivity: Ensure accessibility and include diverse perspectives and experiences

Inclusivity is a feature of our model development, both in the selection of models to build and in the models themselves. We include diverse stakeholder feedback throughout model development to capture diverse perspectives. By including diverse stakeholder feedback, we help ensure our models reflect real-world complexities and help prevent bias. Before beginning work on a new model, our development group collaborates with several divisions across SAS and external stakeholders to review model design. Throughout model development, we set up regular touchpoints with stakeholders to review model design and output. Additionally, SAS ensures accessible model design by internationalizing our models for use in many languages. Lastly, to ensure all reports are accessible to everyone, SAS Visual Analytics reports are designed using accessible color palettes.

Accountability: Proactively identify and mitigate adverse impacts

To help ensure accountability in all our models, we proactively identify and mitigate risks and potential biases throughout the model lifespan. Examples of ways we mitigate bias include: thoughtful data procurement, extensive model testing, and documenting appropriate model applications. All SAS Models come with extensive documentation highlighting known risks. The documentation includes clear intended-use statements to help prevent inadvertent use of the model for purposes that deviate from the original design. To help mitigate and control bias, model designers carefully select data that accurately represents trends and associations found in the target population. Furthermore, SAS Models include procedures to check for missing variables and outliers that may skew model results.

Privacy and security: Protect the use and application of an individual's data

From model development to model deployment, we focus on preserving privacy and providing model security. SAS ensures privacy when developing models by using de-identified, synthetic data, or digital twin data to develop models. To prevent external access, SAS compiles the code for all SAS Models. Licensing checks also ensure only authorized users can access them.

Beyond development, our SAS Viya models leverage the privacy and security features built into SAS Viya. This includes features like automatic detection of sensitive data and data lineage tracking. SAS has prioritized the security and compliance of SAS products, with certifications from many regulatory and compliance organizations, including FEDRAMP and NIST. Learn more about SAS certifications.

Robustness: Operate reliably and safely, while managing potential risks throughout a life cycle

The SAS Modeling group uses several approaches to ensure models perform consistently and accurately across environments. First, SAS Model pipelines use champion model analysis to identify the best-fitting model based on the end user’s data. Champion model analysis deploys several model types to identify which performs best on the end user’s data. Second, our models include model-fit statistics that give end users tools to monitor model and concept drift. Third, we run all models through extensive above-the-line and below-the-line testing before deployment. Lastly, all our models leverage our own CI/CD pipeline to update and version models with the latest security and dependency updates available from SAS.

Transparency: Openly communicate intended use, risks, and how decisions are made

Transparency ensures that all end users clearly understand the model and how it arrived at its results. To support transparency, all SAS Model documentation includes detailed information about the model. SAS includes model assumptions, data requirements, potential risks, modeling decisions, and intended use statements in all model documentation. Furthermore, all our models are designed to clearly show how decisions are made and empower users with the ability to monitor the model for concept or model drift. For example, to help monitor concept drift, model pipelines include output tables such as variable importance and Shapley values to support interpretation.

Responsible AI is a team practice

Incorporating AI ethics into our modeling process helps us build better, safer, and more trustworthy models. For SAS Model developers, responsible design means asking hard questions early, documenting decisions clearly, involving the right stakeholders, and collaborating with customers to review model performance over time.

READ MORE | Trustworthy AI at SAS

LEARN MORE | SAS Responsible Innovation and Trustworthy AI Online Course

The post AI ethics and SAS Models: Designing models with trust, transparency, and accountability appeared first on The SAS Data Science Blog.

Which region drove the increase in sales?

How did that compare with last year?

Which products contributed most to the change?

What started as a simple question about a dashboard has become a deeper analytical exploration. But traditionally, answering that next question can mean searching through other report pages, finding a different dashboard or asking an analyst or report designer to create an entirely new view of the data.

That creates a gap between curiosity and insight.

For business users viewing reports in SAS^® Visual Analytics, SAS^® Viya^® Copilot helps close that gap. Instead of being limited to the questions a report was originally designed to answer, users can ask their own questions about the underlying data and explore the answers instantly.

Let's explore how Viya Copilot helps report viewers move beyond the dashboard and discover the insights that matter to them.

When the dashboard sparks curiosity

Reports and dashboards are designed to answer important business questions. They bring together the right data, metrics and visualizations to help users understand what is happening. In fact, the most useful dashboards should lead to new questions.

A dashboard might show overall sales performance, but a user might want to understand how sales changed in a particular region. A report might show profit by product, but the next question could be how those products performed over time. Or a user might want to see a familiar measure broken down by a category that isn't currently displayed.

Traditionally, answering these questions requires another step. Users might need to search through the report for an existing visual, navigate to another dashboard or ask another team to create a new report.

Viya Copilot introduces a more direct path.

When the next answer isn’t already in the report

When viewing a report, users can ask Viya Copilot questions about the underlying data using natural language. Copilot interprets the question, queries the available data and returns the result as a visualization.

For example, a user might ask:

• "Show me sales for the Northeast region."
• "How did revenue change over the last 12 months?"
• "Break profit down by product category."
• "Which regions had the highest sales last quarter?"

Copilot can use existing measures and columns from the report's data to answer these questions, applying the appropriate categories, measures, filters or ranks based on what the user asked.

This means users no longer have to search through report pages for the right chart or wait for another team to build a new view.

They can ask the question and explore the answer immediately.

From predefined views to self-service exploration

A report author's job is to create a focused analytical experience. That often means selecting the most important metrics, dimensions and visualizations for a particular audience.

But no report can anticipate every question a user might have. And it shouldn’t have to.

That's where conversational analytics can extend the value of a report.

With Viya Copilot, users aren't limited to the views that were originally included in the report. They can describe what they want to see and Copilot can create a new visualization to help answer the question.

This gives report viewers more room to explore without requiring report authors to build every possible analysis in advance. Business users can explore beyond the predefined dashboard while still working within the report's analytical context.

The result is a more dynamic experience: the report provides the starting point, and the user's questions determine where the analysis goes next.

Understanding how Copilot answered your question

Natural-language questions make analytics more accessible, but users also need to understand how their questions were translated into analytical results.

Viya Copilot provides transparency into how it interpreted a question and built the resulting visualization. By expanding the information pop-up, users can see which categories and measures Copilot selected from the available data, as well as the filters or ranks applied based on the question.

This transparency is especially important when a question requires a calculation that doesn't already exist in the report. Copilot can generate new expressions on the fly to create ad-hoc measures, such as aggregated or periodic calculations. For example, a report might contain sales and profit, but a user might want to understand profit margin. Or they might want to compare a measure across time using a periodic calculation.

When Copilot creates a new calculation, the expression logic is available alongside the visualization, allowing users to validate how the result was calculated.

Whether Copilot uses existing measures and columns or generates a new expression, users can see how their question translates into the analytical result. This helps make conversational analytics not only more accessible but also more transparent and trustworthy.

More freedom to ask, without giving up control

Self-service exploration doesn't mean giving users ungoverned access to data.

Governance remains part of that experience. The ability to explore beyond predefined views still operates within boundaries established by the report designer.

The report designer determines which data Viya Copilot can access when responding to a user's questions about the report. By default, only data items assigned to objects in the report are available to the viewer.

From there, report designers can choose to allow viewers to access any data item in the report's data source, even when that data item is not explicitly used in the report. Or they can disable the SAS Viya Copilot pane completely for report viewers.

That creates an important balance: viewers gain more freedom to follow their questions, while report designers and organizations retain control over the data available to Copilot.

From report viewing to insight discovery

A dashboard doesn’t have to anticipate every question its viewers might ask. It can provide the context, trusted data and starting point, while giving users room to follow the questions that emerge.

Business users can move from consuming the analysis created for them to exploring the questions that matter to them, while remaining within the analytical and governance boundaries established by the report designer.

With SAS Viya Copilot, the report becomes less of a fixed destination and more of a starting point for exploration. The dashboard provides the starting point. The questions users ask determine where the analysis goes next.

Learn more about how SAS Viya unifies data, analytics and governance in one platform, so teams can deliver transparent, trustworthy insights at scale.

The post Beyond the dashboard: how SAS Viya Copilot lets curiosity lead the analysis appeared first on The SAS Data Science Blog.

In an earlier series on multimodal transformers, I introduced zero-shot transformer models and highlighted two standout examples: GLiNER for named entity recognition and SAM for image segmentation. A follow-up post made the case for Small Language Models as a practical middle ground between traditional NLP and full-scale LLMs and ended with a prediction: the future of enterprise AI would be built on top of smaller, locally deployed models. That prediction seems to be coming to fruition faster than I expected.

The goal of this post, and of the four that follow it, is to cut through the noise. Rather than one sprawling field guide, I have broken the material into a series of shorter, focused installments meant to familiarize a practitioner with emerging technologies and techniques: the model zoo (this post), the autonomy spectrum and the plumbing that supports it, the retrieval architectures used to ground models in enterprise data, and the shifting economics of inference. And lastly, to take a look at how SAS is putting all of it into practice. Taken together, they are meant to serve as a field guide for analytics practitioners navigating this rapidly evolving terrain.

In just a few months, the AI landscape has undergone what can only be described as a technological and terminological explosion. New standards, new architectural patterns, new product categories, and an avalanche of acronyms have emerged at a pace that makes even seasoned practitioners feel like they need a glossary just to follow the conversation. As Andrej Karpathy quipped in 2023, "the hottest new programming language is English." Three years later, he was only half right. English is still part of the equation, but the real engineering has moved far beyond crafting the perfect prompt.

Different Types of Models

We begin where most confusion starts: with the models themselves. One of the first sources of confusion in the current AI landscape is the sheer variety of model types. You will hear people throw around terms like LLM, SLM, VLM, reasoning model, and diffusion model almost interchangeably, but they refer to meaningfully different tools with distinct strengths. See Table 1 for an overall summary.

Large Language Models (LLMs) are the headline-grabbers. These are text-centric models with parameter counts ranging from tens of billions to trillions. GPT-5, Claude Opus, and Gemini Pro all fall into this category. They excel at general-purpose reasoning, open-ended generation, and complex multi-step tasks. They are also expensive to run, typically costing between $2 and $30 per million tokens, and they generally require significant compute infrastructure. Think of LLMs as the senior architects of the AI world: brilliant generalists who can tackle almost anything, but whose time is expensive and best reserved for tasks that genuinely require their breadth.

Small Language Models (SLMs) range from a few million to roughly 10 billion parameters. Key examples include Microsoft's Phi-4 Mini (3.8B parameters), Meta's LLaMA 3.2 (1B and 3B variants), NVIDIA's Nemotron Nano, and the GLiNER family I discussed in the previous series. SLM inference costs are 5 to 20 times lower than LLMs. A June 2025 NVIDIA position paper, "Small Language Models are the Future of Agentic AI," argues that most agentic work (parsing commands, calling tools, producing structured output, summarizing, routing) is repetitive and narrow, making SLMs the natural fit. They can be fine-tuned to strict output formats, run on local consumer-grade hardware, and deliver real-time latency without heavy parallelization. Think of them as a junior employee or intern who can consistently accomplish a well-defined task.

SLMs also play an increasingly critical role in AI safety and governance. Because they are fast and cheap to run, they are ideal for implementing computationally efficient guardrails within a larger agentic process: scanning inputs for prompt injection or jailbreak attempts, detecting toxic or harmful content in model outputs, and enforcing content policy compliance, all in real time and without the latency or cost penalty of routing every safety check through a full-scale LLM. In an agentic workflow where a single user request might trigger dozens of model calls, having lightweight SLM sentinels standing guard at each step is far more practical than asking the expensive orchestrator to police itself. If LLMs are the architects, SLMs are the skilled tradespeople: fast, efficient, and excellent at executing well-defined tasks, including keeping the rest of the system honest.

Vision Language Models (VLMs) fuse a vision encoder with a language decoder, enabling the model to process images and text jointly. They span sizes from compact (Qwen2.5-VL at 7B parameters) to frontier scale. The key distinction is multimodal input: whereas LLMs and SLMs can accept only text as input, a VLM can accept both text and images. This enables them to look at scanned PDFs, photographs, charts, or diagrams and understand what they see in context. This makes VLMs invaluable for document understanding, visual question answering, and any task where layout or visual structure of information matters as much as the words themselves.

Reasoning Models are a more recent designation given to frontier LLMs. Standard LLMs generate responses token-by-token in a single forward pass, essentially "thinking out loud" as they write. Reasoning models, by contrast, are trained to perform an explicit chain of thought before producing a final answer. They allocate additional compute at inference time, working through a problem step by step internally before committing to a response.

It’s akin to a model performing “Type II thinking” from Daniel Kahneman’s book, “Thinking Fast and Slow”. Most frontier LLM models now include a thinking parameter that can be toggled to influence the amount of effort (and tokens) that should be spent in “thinking” mode. The trade-off is straightforward: reasoning models are slower and more expensive per query (that extra thinking consumes tokens), but they dramatically outperform standard models on tasks requiring multi-step logic, mathematical proof, code debugging, and complex analytical reasoning. For straightforward generation tasks like summarization or translation, a standard LLM is faster and cheaper. For complex tasks where getting the answer right matters more than getting it fast, reasoning models are increasingly the tool of choice.

Diffusion Models operate on an entirely different principle from the language models above. Rather than predicting the next token in a sequence, diffusion models learn to generate data by gradually reversing a noise-addition process. During training, the model learns how to take pure noise and iteratively refine it into coherent output. This approach has proven spectacularly effective for image generation (Stable Diffusion, DALL-E 3, Midjourney), video generation (Sora, Runway), audio synthesis, and even molecular design.

More recently, diffusion-based architectures have begun appearing in code generation and structured data synthesis, blurring the line between generative media and traditional AI tasks. For enterprise applications, diffusion models are most relevant in scenarios involving synthetic data generation, visual content creation, and augmenting training data sets where real-world data is scarce or sensitive.

Table 1: Different Language Model Variants

The key takeaway is that these are not competing alternatives. They are complementary tools designed for different jobs, and the most effective AI systems use them in thoughtfully designed combinations. An agentic workflow might use a reasoning model to plan a complex task, delegate extraction work to an SLM, hand visual document processing to a VLM, and generate synthetic training data with a diffusion model, all orchestrated by a reasoning LLM acting as the coordinator.

Generative vs. Discriminative: A Foundational Distinction

Underneath all the terminology above is a more fundamental split that predates the current wave of generative AI entirely: the difference between discriminative (deterministic) models and generative models. Traditional predictive analytics — credit scoring, fraud detection, churn prediction — is built almost exclusively on discriminative models. Given a set of inputs, a discriminative model learns the boundary or mapping to a specific output: a class label, a probability, a risk score. Feed it the same inputs twice, and it returns the same answer every time. That determinism is precisely why these models have been the backbone of regulated industries for decades: their behavior is reproducible, auditable, and explainable through reason codes, variable importance analysis, or heuristics.

Generative models — including every model type discussed above work differently. Rather than learning a fixed mapping from input to output, they learn the data's underlying distribution and then sample from that distribution to produce new content. Feed a generative model the same inputs and, even with the temperature set to zero, you will get different (though hopefully equally valid) answers. That is a feature, not a bug, when the goal is creative or open-ended output, but it is also exactly why generative AI introduces governance challenges that classical discriminative models never had to contend with: hallucination, output variability, and prompt-level attack surfaces.

Hallucination means a model can state a plausible-sounding falsehood with complete confidence; output variability means the same input can yield inconsistent decisions over time, which complicates audit trails and reproducibility; and prompt-level attack surfaces mean a carefully crafted input can manipulate the model’s behavior in ways a static scoring algorithm was never exposed to. Each is a new class of risk that governance frameworks built for discriminative models were never designed to catch.

Both are AI models, but the distinction has important implications for use case suitability. See Table 2 for a summary of these subtleties.

Table 2: Discriminative vs. Generative Models

This is not an either/or choice. The most mature AI programs pair the two. A discriminative model handles the deterministic decision that must be defensible in an audit (approve or decline, flag or clear), while a generative model handles the surrounding tasks that benefit from flexibility (summarizing the case for a reviewer, drafting an explanation letter, or extracting unstructured details that feed the discriminative model’s inputs).
The ideal setup for an enterprise use case might involve using deterministic analytic models upstream.  Then feeding the model artifacts to a downstream generative model. This can assist with understanding the outputs and providing human reviewers with guidance on how to interpret and act on the results.

Ultimately, knowing which category a given model belongs to is the first step in knowing what kind of governance, monitoring, and validation are required to convert a prototype into a vetted, production-ready solution.

Coming Up Next

Knowing which kinds of models exist is only half of the picture. Ultimately, choosing well also means understanding the systems we build around them. The next post in this series moves up a level of abstraction to look at the autonomy spectrum, the meaningful differences between a chatbot, a copilot, and an agent, and the plumbing that makes agentic behavior possible: Skills, the Model Context Protocol, and the harness that turns a capable model into a reliable system.

Blog Series:

• • Part 1: The Model Zoo: LLMs, SLMs, and VLMs, Oh My!
  • Part 2: From Chatbots to Agents: The Autonomy Spectrum and the Plumbing Beneath It

The post The Model Zoo: LLMs, SLMs, and VLMs, Oh My! appeared first on The SAS Data Science Blog.

Highly trained nurses and clinicians spend hours navigating fragmented medical records: scrolling through PDFs, interpreting handwritten notes and cross-referencing guidelines; not because the work requires their expertise, but because the information they need isn’t readily accessible. The real challenge isn’t clinical complexity. It’s operational friction.

As workforce shortages continue to strain health care systems, much of the conversation has focused on forecasting demand and optimizing staffing levels. But there is another, often overlooked lever: how efficiently existing clinical resources are actually used.

Before asking how many reviewers are needed, it’s worth asking a simpler question: how much of their time is truly spent reviewing?

The operational reality behind prior authorization

In prior authorization and medical necessity review, decisions must be evidence-based, consistent, and auditable. But the path to get there is anything but efficient.

Clinical documentation arrives in fragmented formats, from scanned PDFs, faxes, discharge summaries, and operative notes, each with its own structure, or lack thereof. Reviewers must determine the appropriate policy, locate relevant evidence within the record, and document a defensible rationale.

The work is meticulous, but much of it is not clinical. It is administrative navigation disguised as clinical review.

This creates a bottleneck. Throughput slows, turnaround times increase, and highly specialized clinicians spend the majority of their effort on tasks that do not require their level of training. In a constrained workforce environment, this is not sustainable.

From documents to intelligence

Addressing this challenge begins with transforming unstructured medical records into something usable.

Traditional approaches stop at digitization, simply converting images into text. But in healthcare, text alone is not enough. What matters is meaning.

SAS® Document Analysis for Health Record Review extracts clinically relevant concepts directly from medical records, including diagnoses, procedures, medications, lab values, and timelines, and organizes them into structured, analytically ready formats. Each extracted element is linked back to its original source, preserving the traceability required in regulated environments. This creates a foundation where clinical data is no longer buried in documents, but accessible and ready to be used for downstream analytics.

The real shift, however, happens when that intelligence is embedded directly into decision workflows.

Embedding intelligence into review

Once clinical data is structured, it can be aligned directly to policy criteria within the review process.

In practice, I’ve leveraged SAS® Retrieval Agent Manager to retrieve relevant clinical evidence, map it to discrete policy requirements, and return a structured response such as met, not met, or unknown, along with traceable citations tied to specific pages in the medical record.

Instead of asking reviewers to interpret both the guideline and the medical record simultaneously, the system presents a structured, evidence-backed view, turning what was once a manual search into a guided validation process.

For example, in a knee replacement use case for a patient, rather than manually searching for documentation of prior conservative treatment, the system surfaces relevant evidence, such as physical therapy duration or imaging results directly within the checklist, with links back to the exact page in her medical record where the information was identified.

At the core of this approach is guideline-locked AI. Rather than allowing models to generalize across multiple sources, the system anchors every evaluation to a single, deterministic policy, ensuring decisions remain consistent, explainable, and aligned to clinical and regulatory expectations.

Governance before generation

Equally important is what happens before any AI-driven reasoning occurs.

The process is orchestrated through a governed decision flow, implemented through SAS Intelligent Decisioning, where policy mapping, provider validation and routing logic are enforced deterministically with automated business rules before any evaluation takes place.

This ensures the correct policy is selected, providers are validated, and exceptions are routed appropriately. Only then is structured clinical data passed into the AI-driven evaluation layer.

The result is not open-ended automation, but a bounded system where AI operates within clearly defined clinical and regulatory constraints.

Shifting how clinical time is spent

The impact of this shift is not just technical, it is operational.

For the reviewer, the experience changes entirely. Instead of navigating fragmented documentation, they enter through a centralized interface where cases are triaged and contextualized within SAS® Visual Analytics.

Drilling into a case reveals a structured checklist of clinical criteria, supporting evidence, and direct links back to the original medical record. Reviewers can jump directly to the exact page where evidence was identified, eliminating manual search. If there are additional needs to further triage the data and case, the reviewer can directly ask questions based on the patient’s specific medical records and policy guidelines.

What was once a time-consuming process becomes a focused review centered on validation and decision-making.

Building trust through transparency

In healthcare, automation without transparency is not an option.

Black-box outputs are difficult to trust and even harder to defend. By contrast, an evidence-based framework ensures that every decision can be traced back to both the policy and the underlying medical record.

Reviewers are not asked to trust the system. They are enabled to verify it instantly.

This is where automation and auditability converge.

Extending beyond prior authorization

While prior authorization is a natural starting point, the implications extend further.

The same approach can be applied to pre-payment claims review, post-service medical necessity validation, and broader payment integrity workflows. Anywhere clinical decisions depend on unstructured documentation the opportunity exists to reduce friction and improve consistency.

A more practical path to resource optimization

By transforming unstructured data into structured intelligence and embedding it into governed decision workflows, organizations can unlock capacity within existing teams. Not by asking more of clinicians, but by removing the barriers that slow them down.

In that sense, AI-driven medical record intelligence is not just a technology investment. It is a practical way to extend the impact of a limited workforce while improving the experience of the people at the center of it.

Learn more

• Scaling submission automation with SAS Clinical Acceleration on Viya
• Detecting Alzheimer's earlier with AI
• How to build predictive health care AI from data to decision
• A Digital Assistant for Medical Record Review

The post Optimizing clinical and operational resources through AI-driven medical record intelligence appeared first on The SAS Data Science Blog.

The SAS Viya MCP Server addresses that challenge by exposing SAS data, analytics, models and decisioning capabilities as standardized MCP tools that AI assistants such as Claude Cowork and other MCP-compatible clients can securely consume. Rather than executing the analytical work itself, the AI assistant becomes an orchestration interface, while SAS Viya remains the trusted execution layer behind the workflow.

This post highlights a credit evaluation use case and the architectural components behind it. The centerpiece is a 10-minute demo of SAS Viya MCP Server and Claude Cowork. Watch it now, or keep reading for a closer look at the architecture behind it.

Beyond tool calling: MCP for enterprise analytics

Large language models (LLMs) excel at understanding language and reasoning over information, but they have no inherent awareness of enterprise data, analytical assets or business processes. MCP provides a standardized way for AI assistants to discover and invoke enterprise capabilities.

The SAS Viya MCP Server extends that concept by exposing trusted SAS assets as governed tools. Available as an open-source project on GitHub, the SAS Viya MCP Server currently includes more than 40 capabilities spanning data governance, data access, AutoML, model management, reporting and interaction with deployed models and decisions.

This makes it possible to orchestrate analytical workflows through natural language while execution, governance and lifecycle management remain within SAS Viya. Existing analytical investments including models, decision flows, governance frameworks and domain expertise can be reused rather than recreated inside LLM applications.

Banking use case: Credit evaluation

In the banking demo, Claude Cowork orchestrates creating a credit classification model designed to predict whether an applicant represents a good or bad credit risk. Using a recently released data set from Santander AI Lab to augment a well-known German credit data set, a natural language request coordinates multiple activities across SAS Viya:

• Data ingestion
• Data profiling and governance review
• Automated machine learning
• Model evaluation and comparison
• Model publication
• Operational scoring

The value is not that an AI assistant can build a model. The value is that the assistant can coordinate a governed analytical workflow while trusted SAS services perform the underlying analytical work. The result is a more efficient path from data to insight without sacrificing transparency or control.

Governance is built into the architecture

Many agentic AI demonstrations focus on automation. Regulated industries such as banking require more than automation. They need workflows that can be reviewed, explained and controlled.

In this workflow, analytics and model management remain within SAS Viya. Users can examine profiling results, review model pipelines, validate outputs and understand how results were generated rather than relying on a black-box process.

Human approval also remains part of the model life cycle. Models generated through the workflow are not automatically deployed; stakeholders review and approve assets before deployment. That distinction matters in banking and other regulated environments where oversight, validation and approval are mandatory.

What technical teams should notice

Pay attention to several architectural patterns in the demo:

• SAS capabilities are exposed as standardized MCP tools, rather than through custom integrations.
• Analytical execution remains inside SAS Viya while the AI assistant orchestrates activity.
• Governance, auditability and access controls remain enforced through existing SAS capabilities.
• Enterprise platform details and internal SAS endpoints are not exposed directly to the underlying LLM.
• Human approval remains part of the model lifecycle before deployment.
• Existing SAS assets, models and analytical workflows can be reused rather than rebuilt for each AI assistant experience.

These patterns are applicable well beyond credit modeling and can be extended to fraud detection, marketing optimization, customer intelligence, anti-money laundering and other analytics-driven business processes.

Take the next step

If you're ready to move from concept to hands-on practice, dive into these resources:

1. Free Hands-On Lab: Agentic AI - How To with SAS Viya

Use SAS Agentic AI Accelerator to:

• Register, publish, and deploy proprietary and open source LLMs.
• Build decision workflows that combine LLM judgment with deterministic models.
• Deploy AI-driven decisions into Azure AI Assistants.
• Monitor model cost, performance, and sentiment.
• Gain practical experience with AI governance in a real-world environment.

2. Training: SAS Decisioning Learning Subscription

A new SAS Viya MCP Server chapter will teach you how to:

• Connect Claude Cowork to SAS Viya.
• Connect GitHub Copilot to a governed SAS Viya environment.
• Work within enterprise-grade governance and decisioning frameworks.

The post Building a governed banking workflow with SAS® Viya® MCP Server and Claude Cowork appeared first on The SAS Data Science Blog.