Good morning, and welcome to the Consensus Investor Webinar on AI and Interoperability. I'm Laura Hinson, and joining us today are John Nebergall, COO, and Jeff Sullivan, CTO. Before we begin our presentation, allow me to direct you to the forward-looking statement on slide two. This call and webcast may include forward-looking statements. Actual results may differ materially from the forward-looking statement projections. Additional information concerning the factors that could cause results to differ materially is contained within the discussion and documents. Thank you again for being with us today as we dive into this complex topic. Now I'll turn the presentation over to John Nebergall. Hi, my name is John Nebergall, and I'm the Chief Operating Officer of Consensus Cloud Solutions, trading on the Nasdaq under CCSI. As a quick introduction to Consensus, we're a relatively new public company who, in October of 2021, was spun out of the former J2 Global, now Ziff Davis. The company has been doing business in secure document exchange for over 25 years, and we go to market with our Conductor, formerly Summit Exchange Interface Engine, our eFax brand, Cloud Fax Service, jSign digital signature, and the Clarity Transformation Engine. Healthcare is far and away the largest sector that we serve, although we do also do measurable business in financial services, legal, and government. Our work on Clarity, in particular, has brought us heavily into the automated intelligence space, and given that development direction, today we'll be talking about AI in healthcare. I will be presenting today, along with my colleague, Jeff Sullivan, Consensus Chief Technology Officer. Let's go. A quick review of the agenda here. I'll talk about the messy state of healthcare interoperability and a specific problem in that space that it impacts millions of patients. Jeff will then walk through how the application of AI technology has offered an elegant solution to a problem that's been in play for at least the last 20 years. Finally, we'll speak about the opportunity here and how we go to market. Let's move to slide five and get started. Healthcare has been struggling with the ability to exchange information for as long as the electronic health record, or EHR systems, have been in the mainstream. Healthcare is not just a single industry, but really encompasses many commercial areas. You have hospitals, clinics, insurers, public health, social services, pharmacies, labs, home health, skilled nursing facilities, you know, the list goes on. The number of players creating and storing information is huge. Difficulty arises from a wide range of technologies and data structures used by the hundreds of electronic health record, ERP, financial, claims, and research systems in use today, resulting in incompatibility for information exchange. The effort to establish standards for information exchange in healthcare has been limited in its effectiveness because no single standard has yet emerged as a clear choice for communication. A protocol called Health Level Seven, HL7 for short, defines some parameters for information exchange, but leaves a large area open for individual interpretation. A subvariant of HL7, called Fast Healthcare Interoperability Resources, or FHIR, was designed with API-to-API connections in mind, but remained very finicky in how it's used, and only about 10%-15% of the messages use it. Finally, a closed, members-only email service called Direct Secure Messaging, or Direct for short, allows patient records as email attachments. Now, none of those three technologies really speak to each other, and no single protocol has emerged as the clear standard. As evidenced by the explosion of data you see illustrated from the Stanford Health Research Report in the lower left, the amassed repository of information is growing at an accelerating rate. Delivering quality care in today's environment relies, in part, on sharing that data. This valuable information can greatly improve patient care and allow providers to coordinate efforts for the benefit of each and every one of us. But the lack of a standard protocol for EHRs remains a hurdle. If you ask why healthcare uses fax, and they fax a lot, easy information sharing is the reason. In contrast to the electronic spaghetti bowl that is our current interoperability environment, fax is reliable, secure, inexpensive, and it verifies receipt. While we can define the problem in technical terms and think of the issue as just one more engineering challenge, there's a practical reality here that affects literally every one of us because we're all patients. While in many industries, market forces have driven competitors to compatibility, the health IT community seems as far away as it's ever been to share data across platforms as an industry goal. Another wrinkle here is that EHR systems need to communicate with a whole different set of vendors who provide pharmacy systems, claims adjudication systems, prior authorization systems, and systems specialized in the post, post-acute setting. These core systems are embedded with long roots into the organization, so changing how they communicate can cause a significant ripple effect that breaks workflows or impacts how transactions are fed into billing systems. As patients, the impact is felt as we traverse the system. Getting a referral to a specialist, receiving your explanation of benefits, or waiting for approval of a procedure or medication can result in delays of weeks and sometimes months to patients seeking care as they wait for manual processes to be executed because the EHR doesn't talk to the payer system in a language it can understand. A recent Deloitte survey was clear: the physicians expect that these systems share data efficiently. Now, if the difficulty in getting modern systems to talk each, to each other isn't enough of a hurdle, there's one more deep institutional wrinkle that comes to bear. Our healthcare system is a network of care settings, different settings for different care delivery: hospitals for acute episodes, doctor's offices for checkups, and the urgent care center for manageable industries or sudden bouts of sickness. You get the picture. Now, it is likely that most of the places you think about when you think of healthcare providers are working with a modern EHR system, doctor's offices, hospitals, multi-specialty clinics, and the like. In fact, well over 90% of those care settings have an EHR capable of processing structured clinical documents. While we have been just through the abundant and growing use of fax at hospitals, there is an entire additional set of providers that come into play. These are care settings that largely do not have EHRs, but still see millions of patients every week. In 2009, the government funded EHR purchases for hospitals, clinics, and academic medical centers. At the/ same time, many care settings were not allowed to participate in the funding, specifically excluded from participating in the EHR funding program. No skilled nursing facilities, long-term care sites, midwife birthing centers, home health, hospice, or community-based non-physician practices, like an addiction rehabilitation center, could qualify. Ironically, the practical outcome here was that the types of care settings that were most likely able to afford EHRs got them largely for free, while those least able to afford them were excluded. Along those fault lines, you see the use of tools is decidedly different. While fax is used throughout the healthcare industry, the technical core not excluded, you find even more prevalent fax use in post-acute, home-based community clinics and rural areas. Unable to get the help to afford an EHR, that's the dynamic that sets up a rather interesting problem. Here we see the traffic pattern that's developed between those with an EHR and those without. Importantly, what I'll call the outer rings of healthcare here have a great need to interact with the central core. Many of the expert specialty providers, much of the sophisticated diagnostics equipment, the payers, surgery centers, and hospitals are in that technology core. While those on the outer rings use fax traffic as their lifeline, and fax is what's called unstructured data, which is generally readable by humans but not by machines, that's the language that those outer rings speak. Conversely, structured data, or machine-readable data, is essential to have EHR systems that deliver their optimum value. In the absence of some trillion-dollar funding initiative for the outer rings, the receivers of this fax traffic typically shoulder the administrative task of manual entry of any of the messages that are received via fax. These messages are then filed electronically into the EHR. Sometimes they'll just directly file the fax document as a document in the EHR, but that's still not fully optimized. Generally, the best way to get the most value out of your database is to key that fax in and put it into a state of structured data. This is where the application of AI to interoperability can be positioned. Unstructured data creates administrative burden. Structured data, the language of EHRs, requires expensive and complex systems that are not easy to maintain for those without a dedicated IT department. Care settings without that economic strength still need to communicate with the large organizations using EHR systems, and overwhelmingly use fax to fill that need. And while effective for human communication, fax's unstructured data is not optimized to allow EHRs to operate at their highest efficiency. The difficulty is further amplified when you realize the wide variety of forms, handwritten notes, and narrative prose that defy easy standardization. It's into this messy environment that we put our new technology to work. So now let me pass this to Jeff Sullivan, who can tell us the way AI is applied to solve this problem. Jeff? Thanks, John. Let's start with a whirlwind tour of the basics. Artificial Intelligence is a blanket term describing the development of computer systems to perform tasks we typically think require human intelligence. At a basic level, AI makes use of certain technological building blocks, the most common of which are Expert Systems, Machine Learning, Neural Networks, and Deep Learning. Expert Systems are specifically programmed to deliver expert-level performance on a very narrow problem. They're useful for very structured problem spaces. Machine Learning, on the other hand, is a method of teaching computers to learn from data without being explicitly programmed. There are a number of different types of algorithms used in ML. The three most prevalent are Neural Networks, which are artificial constructs that mimic human brain function and are trained by presenting inputs and expected outputs for the network to learn. Deep learning, which uses multi-layer neural networks to learn more complex tasks and behaviors... and genetic algorithms, which mimic evolutionary behavior to select the best solution to a problem from a family of options. These techniques are often combined to construct the more advanced AI technologies like natural language processing, speech recognition, computer vision, and especially large language models, which are having quite the moment right now with the explosive popularity of products like ChatGPT. Natural language processing, or NLP, is a major area in AI that focuses on enabling computers to understand and interpret human language, most commonly applied to the written word. NLP is used in a wide variety of applications, including talking with Alexa or Siri, text chatting with bots on a website, or reading and responding to customer service emails. To convert written language into spoken language, or vice versa, we make use of speech synthesis and speech recognition. Unlike earlier technical approaches that made use of explicitly programmed algorithms with limited success, AI speech makes use of machine learning techniques to convert between spoken language and text with much more fluid and natural results. Just as NLP deals with textual or spoken communication, computer vision is a field that empowers computers to recognize objects, detect patterns, and make sense of data from images and videos. This technology has broad applications, including autonomous vehicles, surveillance systems, quality control and manufacturing, and medical imaging. Computer vision can also be used to convert images of text into actual text, which can then be processed using NLP techniques. Similarly, text generated by NLP systems can be fed into speech generation to produce fluid speech. You can see how these fields can be combined to perform even more complex tasks and workflows. But one of the biggest breaking topics in AI is something we're going to dig into on the next slide. Large language models are one of the most interesting, or at least the buzziest, things happening in AI right now. They're advanced AI models that have been trained on vast amounts of text data to understand and generate human language. We're talking millions or even billions of documents. These models use deep learning techniques and neural networks to learn patterns, semantics, and context from the data. We think of LLMs as foundation models, which means they can be used as the starting point to develop more specialized models. An important distinction in large language models is the difference between extractive and generative models. These models play a pivotal role in modern natural language processing, automation, and understanding the difference between them is crucial. Let's begin with extractive models, like the systems shown here from Google and Facebook. These are specifically designed to, as their name suggests, extract information or provide summaries of a body of text. They can identify and select key sentences or phrases, effectively condensing the content. Think of them as efficient filters that capture the essential elements from a given document or body of knowledge. Extractive models are invaluable when large volumes of information need to be distilled into concise summaries. They find widespread use in news aggregation, content curation, and even chatbot applications, providing succinct responses based on available information. By focusing on extracting the most crucial details, these models ensure the preservation of the original text's core essence. On the other hand, we have generative models like ChatGPT. Unlike extractive models that rely on summarizing existing content, generative models possess the, at times, startling ability to create entirely original content by leveraging patterns and structures built into their foundational model. Essentially, they have the ability to create language from scratch, simulating human writing. Generative models have attracted massive attention in recent months. They exhibit impressive capabilities in creative tasks, including storytelling, report writing, analysis, and even musical composition. Generative models excel in endeavors that demand creativity, imagination, and the capacity to produce coherent and contextually relevant text. However, it's important to note that generative models are subject to something called hallucination, where they generate content that appears accurate but is completely fabricated. The danger in hallucination is that it tends to be very plausible. While a hallucination like, "There's a 20-foot-tall purple wolf in my backyard," is easy to identify and discount, something like, "There's a man in a hoodie hiding in the shadows," is far more problematic. It sounds plausible, but it's completely false. Generative hallucinations tend to fall in the latter category. We'll talk quite a bit more about large language models when it comes to applying AI in healthcare interoperability. Speaking of which, we've seen some of the major challenges facing interop. Now, we want to talk about how AI might be able to help. The most significant burden to interoperability is the huge amount of unstructured data in play when exchanging health data. We understand now why that is, and it's not likely to change anytime soon. But here, there are some clear areas where AI can be productively brought to bear to improve the interoperability story in healthcare. I think there are four key facets of the interoperability problem that are most amenable to improvement, and we're going to quickly talk about each of them. A huge challenge is the extraction of data from unstructured sources, and this generally comes in the form of converting this unstructured data into a plain text format suitable for standardization and transformation. This means extracting text from things like faxes, scans, and photos, but also to data in video and audio streams. However, it can also apply to what I'd call semi-structured sources like Microsoft Excel or PDF files, and the like. In the truly unstructured cases, the best technique available to extract the data and render it into computer-readable text is the application of computer vision techniques. These go beyond the limited capabilities of basic optical character recognition and apply techniques derived from human and animal visual processing research to train systems to recognize even poor quality printed text and handwriting, which are historically a big challenge for many OCR technologies. Here we see things like Google Vision AI or Amazon Textract being offered as foundation models, which can be further trained to suit, but it's also an area where there is robust third-party development. This is because there's a lot of heuristic information in visual processing that is domain-specific. Here's a somewhat trivial example of this: a computer vision model trained on medical terms is likely to correctly infer that a nearly illegible word is lesion, whereas a more general model might conclude that the word is lesson. Now, once extracted, this raw text input will almost always need to be standardized or translated, or both, before it can be used in other healthcare systems. Sometimes you might also have multiple types of content in a single feed. For example, a fax that contains a patient discharge form, a test order, and a referral for physical therapy, and you need to organize the parts so that you can only use the bits which are relevant to your current purpose. This can be a fairly complicated task, and there are a number of AI techniques to use in the standardization process. Certainly, natural language processing is a great technology for flexibly parsing textual information and transforming it into a symbolic representation. But as we look at more complex data structures and more nuanced information being represented, we start to see more machine learning techniques being applied. Neural networks, with their ability to take specific inputs and produce appropriate outputs, are well suited to relatively simple information standardization tasks. But as the inputs get bigger and more varied, large language models tend to shine. Extractive models are the preferred use case in this scenario due to their comparatively low tendency to hallucination, so we prefer those when possible, which would be when you need to generate low to moderate complexity outputs. No matter how you get there, once you've got the data into a standard canonical format, there are a lot of options for use within the realm of healthcare interoperability. But first, we need to address the challenge on the next slide. Note that I just said getting data into a standardized format, not the standardized format. As John covered, there are a dizzying array of different healthcare data standards, most capable of representing the same data in fundamentally different ways. The problem of interoperability is the problem of knowing how to format the data you have so that the other party, whether it's an EHR, a human, or whatever, can receive, understand, and make use of it. The transformation of data from one format to another exists as one of the central problems of healthcare interoperability, because there are so very many different types of systems in most healthcare settings, and crucial data often needs to flow through several of them to reach all the places it's needed. This huge mass of data transformation activity is extremely labor-intensive, either in terms of multi-year integration projects or armies of manual labor used to rekey data from one system to another. We can make use of expert systems and neural networks to facilitate relatively simple transformations, but we'll need to rely on deep learning, extractive, or even generative models for the more sophisticated transformations of data. The latter are especially likely if the final result needs to be in a human-readable format. For example, when the recipient is in a rural clinic without access to modern EHR systems. By comparison, the problem of integration, that is, connecting one system to another so that data can flow between them, is relatively straightforward. However, this final step of the process does tend to be pretty technical and labor-intensive, and AI can lend a hand through the application of AI-driven robotic process automation systems, expert systems to generate or actually perform the integration instructions between two systems, or neural network models that have been trained so that the output of one system is the inputs of the neural network, and the output of the neural network is the input to the other system. Let's take a quick look at a couple of early use cases where we're applying AI to improve interoperability. First, we're going to talk about Clarity on the next slide. Our Clarity platform provides the foundation for our intelligent data extraction capabilities. Built on our computer vision engine, natural language processing, and proprietary extractive large language models, the clarity platform provides flexible, context-aware data extraction capabilities without requiring intensive document training sessions or time-consuming and brittle document templates so common in last-generation data extraction. As flexible and open-ended as the Clarity platform is, we found that our customers are looking for more guidance in solving targeted problems, so we've begun by rolling out business process-specific apps to address these challenges. While the Clarity platform's foundation models are designed to support multiple subject matter domains with broad capabilities, our first two Clarity apps are derived from specialized models we focused on the healthcare space. Now, before we move on, I wanted to address the obvious question about the 800-pound gorillas in the room. Namely, tech titans like Amazon, Google, and Microsoft, who are investing billions of dollars either in their own offerings on AI or in companies like ChatGPT maker, OpenAI. It's a fair question to ask why these giants won't just gobble up the whole space. I mean, they're betting big and have armies of technical talent to throw at the problem. The way we see it, there are three main reasons why Clarity is a good approach for us. First, while there is a lot of focus now on general-purpose generative AI and a lot of eye-catching headlines to go with it, we think that extractive models are the way to go for the foreseeable future, and there are far fewer of those in play. We see the generative models driving customers to us over time, as they like the promise of the technology but can't stomach the hallucination rates. Second, there is plenty of room in this space for a lot of solutions. And while many companies are chasing glamorous headlines, bringing AI to patient diagnosis, or medical research, or clinical decision support, we're squarely focused on solving administrative and interoperability challenges that are only going to increase as the labor shortage in healthcare continues to trend. We see this as a fertile, uncontroversial, and profitable space to compete in…. And last but not least, we see these large companies as providing a lot of raw capability that others can use to build solutions. But actually being able to deliver solutions that customers want is about more than just raw technical capability. You also have to be able to bring it to bear on a problem that's worth solving and worth paying for. Our extensive experience servicing thousands and thousands of healthcare providers over the full gamut of care settings, sets us apart from generic tool providers, and our ability to bring advanced technology to bear to create secure, scalable solutions sets us apart from customers who want to roll their own, but lack the experience and resources to get there or continue to maintain and extend it once they do. In fact, we're a big user of AWS, Google, and Azure offerings. We just see those as building blocks. We see Clarity as more focused and productized to specific needs. So on the next slide, we're going to look at our first app, which tackles prior authorization, which is when a patient needs to have a treatment or medication approved by their insurer before they can receive it. As you might know, prior auth is a huge challenge in healthcare today. It brings into tension the needs of the patient to get the best healthcare, and the insurance payers' desire to manage costs and ensure appropriate treatments are being prescribed. First, a couple of quick points about prior auth. According to the American Medical Association, more than 40% of all prescription and treatment prior authorization requests are received via fax, mostly because someone in the request chain doesn't have a compatible EHR system capable of doing end-to-end processing. And over 77 million prior auths require some level of manual handling each year. Another huge challenge is lack of standardization. One of our customers who focuses on prior auth shared with us that they receive more than 30,000 distinct form variations every year. Despite these challenges, there are some statutory time requirements on responses to prior auth requests, including one that dictates that whenever a request is designated as urgent, it must be responded to within 24 hours. To make matters more complicated, there's no standard way to designate this urgency. On the right of this slide is an example of a prior auth request that was faxed in. Highlighted here are important components that we want to extract. You can see that there's printed text and handwriting, a barcode, and several types of urgency markings. Now, let's talk about how Clarity can help. Our Clarity Prior Authorization app is defined to simplify the process for prior auth participants. Clarity PA takes in a customer's prior auth faxes, extracts the data in the fax, converts the data into a standardized format, like you see on the right, and provides that data back to the customer to integrate into their existing workflow. The technologies used in this app include deep learning systems for doing document classification and splitting, computer vision for reading those documents and extracting their contents into processable format, and an extractive large language model for pulling out all of the various data in the forms into a standard format to be delivered back to our customers. We extract both administrative and clinical details and offer some add-on capabilities that can further accelerate processing based on specific customer workflows. On slide 22, we look at a daily occurrence in most healthcare settings. Unstructured documents come in via fax, mail, or scan. The document relates to a patient who is at that point, unidentified. It contains one or more types of clinical documents within it, which are, at this point, unknown. What does the care setting do? Typically, this is a job for human intelligence. There will be someone whose job it is to go through this constant inflow of documents, identify which patient each relates to, understand what kind of clinical information is in the document, and render that data into a form that can be attached to the patient record, and begin the defined workflow for that care setting, whether it's patient discharge, appointment setting, lab tests, or whatever. In many care settings, the person doing this is a clinical worker, either a nurse or a doctor, who needs to perform these administrative tasks to get to the point where the clinical work can actually begin. Our Clarity Clinical Documentation app is designed to solve for this use case, offering a streamlined way to load these clinical documents directly into the client's EHR system. When the unstructured document comes in, our computer vision model is used to extract the content and put it into a textual document that's split into discrete documents and classified using a deep learning model. Each document is then ingested into an extractive model. That model compiles information about the patient and doctor demographics and clinical details contained within the documents. An expert system is used to translate the output of the extractive model into a standardized message called a Continuity of Care Document, which is a standard HL7 document type, and this CCD is then delivered directly into the customer's EHR by the Direct Secure Messaging protocol. If the EHR supports it, the clinical and demographic details in the message can be used to automatically match and attach the document to the patient's record and kick off workflows in the EHR. The nurse or doctor can spend their time with patients and not on administrative setup. On slide 24, we can see an example of a typical CD fax, in this case, a new patient form for a fictitious patient. On slide 25, we have the result of running it through Clarity CD. The clinical details are extracted from the fax. They're bundled into a direct secure message and delivered, in this case, into the NextGen EHR. All of the details have been loaded into the EHR and are ready for consumption by the team member processing patient intake. So we've seen some examples of how the AI in our Clarity platform can be applied to improve the state of interoperability in healthcare. Now, let's turn it back to John to talk a little bit about the market for AI in healthcare and our approach to serving it. Thank you, Jeff. Now that we've described the problem and how AI can solve it, we should have a look at the market. The value that is created by Clarity and understand how those economics work. Here you can see an analyst's view of AI and the impressive expected growth. But there is more to the story when you look at the total addressable market for this piece of the operational efficiency subcategory.... Now, as I've said before, healthcare faxes a lot. With that inside baseball knowledge, we look at this with a different lens. Recent analyst reports have suggested there are about 13 billion faxes sent and received in healthcare annually. From here, this audience can certainly see what the market opportunity looks like. 13 billion faxes, 3.5 pages, that's 45 billion pages plus of healthcare faxes on an annual basis, and that really sets the TAM that we're looking at here to create a substantial value for the client, for their patients, and a fair economic return for the company. Now, let's look very quickly at individual customer economics and the value proposition. Here, this lays out the key issues and advantages of the Clarity solution, as well as the unit economics that clients have to shoulder in order to input structured data into the EHR. Let's start with something more fundamental, velocity. I'm sure that you're all aware that an entire industry has blossomed in the area of revenue cycle management. The importance of accelerating the time it takes for healthcare providers to get paid for their services creates huge value and really is the poster child for time is money. Time is the first use advantage for Clarity. We see the best of our customers' efforts into key information into their systems can take as little as 2 days. Now, think of that. I get a fax for a patient referral. Now, that's money for a provider, but it takes 2 days to get that into my system, 2 days to start scheduling an appointment, 2 days of the patient waiting for a call, and 2 days of deceleration of my revenue cycle, and that's the best we've seen. The same is true with things like prior authorizations, claims forms, even public health documents. Getting structured data into the system more quickly moves the needle on both the economics and with the delivery of patient care. Clarity eliminates that lag. The next issue, keying errors, is even more important. Keying errors increase the potential for treatment errors, which increase the potential for unfavorable outcomes. You know, the National Institutes of Health published the Medical Error Reduction and Prevention Study that's been updated through May of 2023, and it states that medical errors account for between $4 billion and $20 billion per year and result in approximately 100,000 deaths. The Journal of American Medical Informatics Association published a study on keying errors when entering lab values and found the rate of overall error nearly 4%, and of those errors, over 14% were significantly incorrect. Now, with AI, the receiver is given a statistical confidence score that gives them an objective view of accuracy and guides their decision-making. Random keying errors are eliminated, and as the technology gets more documents, it continues to learn, it continues to improve, and it builds an ever-increasing level of accuracy. While the audience today is likely predisposed to just jump straight to the unit economics and hold speed and accuracy as lesser issues, you might be right in many industries, but not healthcare. In this industry, delays and mistakes can cause real harm. These advantages create significant value. They can be the difference between keeping an accreditation and losing one, can improve outcomes in meaningful ways and are central to any healthcare administrator's thinking. Finally, we come to the unit economics, and this one is likely familiar with all, to all of you. I'm probably not spoiling the story here when I jump straight to the punchline. Just like John Henry, who laid down his hammer and died, the machine wins. So for the customer, we create value in three very concrete ways: speed, accuracy, and cost. Our go-to-market is equally straightforward. We design and implement a solution based on customer needs. We then train the machine to a prescribed level of accuracy and are paid at their prevailing rates for that work. Based on customer volumes, we create a subscription service agreement that includes an upper limit of extractions and a per-page price if that amount is exceeded. Finally, I'll remind you again of the fundamentals here. 13 billion faxes, 3.5 pages per fax, and fax continues to grow. Needless to say, the market opportunity is significant. So to conclude, hopefully, now you have a bit more insight into the technology behind automated intelligence and insight into a real opportunity in healthcare interoperability that was previously thought would always require human intervention, and the thought process it takes to define the solution and the market opportunity. We thank you for the opportunity to share our insights and for your time. Now I believe we've left some room for Q&A. Thank you. Ladies and gentlemen, we will now be conducting a question and answer session. Please use the Ask Question button on the left-hand side of your screen to type in and submit a question. Please hold while we collate your questions... The first question today: How is your solution handling language-specific image data in a single document? Could page content be mixed with different language data? Thank you. Yeah, I'll take that question. So, the interesting thing about LLMs is that they understand language at a symbolic level, and so they're able to handle multiple different languages. Our foundational model, which is an extractive LLM, as I mentioned, is able to handle, I think, more than 14 different languages. We currently support English and Spanish in terms of direct application in Clarity PA. We don't do translation right now, but it is something that we're exploring because it is within the LLM's capabilities. But right now, we wanted to preserve the verisimilitude. So if you give an answer in a document in English, the answer will be presented in English. When we extract it, if you gave that answer in Spanish, that answer will be presented in Spanish again. But there is an opportunity for us to be translating between those languages and, in fact, others as well, as we move into the future. Right now, we're focusing on kind of accurately reflecting the answer that came back. Okay, thank you. The next question is a few questions in one, so I'll ask them all together. What is the underlying architecture of your LLMs? Are they based on transformer architectures like BERT, GPT, or other frameworks? What kind of data was used to train these models? Did you use a diverse and representative data sets? How large is the model in terms of parameters and training data? Do you fine-tune your models for specific tasks? And if so, how do you ensure that the fine-tuned models maintain their general language, general language understanding? How often do you update your models to incorporate new language patterns, data, or address biases? Okay, so there's a lot to unpack here. I will re-answer or restate each question as I answer it in sections, just so that I can kind of keep it straight in my head. So, yes, the underlying architecture of most LLMs is transformer-based, as is ours. It is not a generative pre-trained transformer like ChatGPT is, but it is an extractive one. So I would say the lineage traces back more to something like BERT, which is an extractive transformer-based LLM, than a generative one. But yes, it is based on transformer architecture, as all of the modern LLMs are pretty much. What kind of data we use to train the models? We train the models with over... Let's see, over one billion documents were in our training set across a number of commercial and a large amount of open source, training sets. The model parameters, I'm not sure that we're necessarily giving out exact details on this, but, we have north of 10 billion parameters in our major model. Our specialized submodels are optimized, so they can reduce the number of parameters by eliminating irrelevant kind of domain spaces. As, as I mentioned in the, the talk, the foundational model is very generalized and is able to handle sort of any domain, and it's quite large at, at, you know, north of 10 billion, parameters. The more optimized ones have been tuned. To answer your question back, do you fine-tune your models for specific tasks? The answer is yes. So we derived stuff that was focused on healthcare for these first couple of apps. They use the same basic model, but even the models for Clarity PA and Clarity CD are tuned to their specific purposes, and that allows us to optimize them so that they function more efficiently while still being able to maintain their extractive power. So, how do we ensure that those fine-tuned models maintain their language understanding? The general language understanding is all part of the core functionality, and that's not something that gets trained out. But what you might find is that if you're trying to use one of our specialized models that's tuned for healthcare and you fed it documents that were heavily, say, manufacturing-based, it would struggle with the manufacturing-specific corpus of knowledge because that part of it has been optimized away from in the extractive models in that area. How do we maintain their general language understanding? Again, as I said, that's sort of baked into the foundation, so that's not something that we're overly concerned about. The last part of this question had to do with updating the models. We update them at least on a quarterly basis. Addressing biases, I think one of the interesting things is that because we're not doing a lot of these generative things, our focus on bias is much reduced. We're really emphasizing extracting the information that's in the document and not making things up. Where you tend to hit the bias a lot more is when you're going into generative aspects and workloads, and it's trying to extrapolate what to say, and that's where the bias in its corpus can be more fully expressed. So, again, quarterly on the updates, that incorporates, you know, new language patterns, new, corpuses, new training sets, all of that stuff done on a quarterly basis. Okay, the next question: Why aren't the EHR players creating similar AI solutions? I'm sure that there are EHR players who are doing LLM solutions. Certainly, if you're reading the news, seeing that Epic is incorporating ChatGPT into their EHR. I think the reason why they're not incorporating specific solutions like we're doing in Clarity is that they are very specific to single, singular use cases. And one of the interesting sayings about all of these EHRs is that if you've seen one EHR implementation, you've seen one EHR implementation. And the reality is that whenever you implement one of these EHRs, there's a substantial amount of customer-specific implementation that is done there. That is equally true at the AI level. In fact, it's more true because you've got to deal with both training specific to what the customer is looking for and then the specific work that they're doing. EHR providers will probably flow that out into the system integrator workspace and try to allow them to help with that, but then you're really dependent on the skill set of the individual SI. Our focus here is on delivering tailored solutions that are focused on specific use cases, ones that are broadly applicable in our customer base. And so we feel like our solutions would complement anything that's being done in the EHRs rather than directly compete with it. I will also mention that most of what we're seeing right now when it comes to EHR integration, tends to be some variation on integrating ChatGPT, which is a generative large language model, with its concomitant challenges, but also with the opportunity for one and the other to both exist in the same space and in fact, for one to live with and enhance the other. So one of the things, for example, that we're able to demonstrate is if we use our extractive model and we produce our vectorized outputs from, say, a certain set of questions and feed that vectorized output as prompts into a generative model, we can produce that really fluid, flexible language, but with a vastly reduced, hallucination rate, because we've dramatically constrained the realm of opportunity for the generative model to go off the rails, if you will. So I think there's lots of space for everybody to play in this thing at the same time. Right now, what we see in EHRs is general capabilities that are going to need to be applied to specific solutions for each customer, and that's where we think we shine. Thank you. Once again, ladies and gentlemen, if you wish to submit a question, please use the Ask Question button on your webcast viewer window. The next question: What has the reception been like since you have taken this product to market? I'll take that one. You know that there's been a good deal of interest, both from end user providers as well as, partners that could use a solution like this in their overall solution set. So, we've been pleased with the response that we've gotten. We certainly feel like we're just starting to get our legs under us and the traction started. But, again, we're pleased with what we've seen so far in the marketplace. Okay, great. Is Clarity the only product that uses AI? So, I assume we're talking about ours. Otherwise, everybody knows there's a gajillion products out there with AI these days. Clarity is our AI platform. That is what we put into our products. And so I think of this in a couple of ways. Clarity is a foundational platform that we're using to embed AI-driven capabilities in a number of our products. The first of these we're seeing are these apps that we're creating, which interfaces with our eFax Corporate product line. But we do anticipate that Clarity will become a standalone product in the future that doesn't feed into any of our particular products and kind of you can feed with other other inputs. Having said that, we are certainly looking at a number of other applications, apps that we're going to be building on top of our Clarity platform, and we're also in conversations with a number of customers about direct use of the Clarity platform itself. I think that, you know, if we talk about how things ramp and roll out, what we really wanted to do, which I, you know, referred to earlier, is give some customers, something that they can implement quickly. And Clarity CD is something that is really a turnkey solution. You have a meaningful use certified EHR, you can snap it in and start using it immediately. Clarity PA is more of that traditional integration, where it's an API that performs a bunch of functions, and then you take those functions, you integrate them into your existing workflow. When you're using the Clarity platform, it's more of that kind of an integration, and so there's a broad array of areas with which it can be used. But the way we look at this, we will be delivering a number of Clarity apps over the next couple of quarters. We're not going to announce any of those right now, but I think you can look forward to, in the next couple of quarters, some interesting additional announcements on Clarity apps, and we'll also be integrating Clarity and the other capabilities that we're doing into our product lines. That's also the case that we'll be using our own Clarity platform internally as well. But from a product perspective, Clarity is our AI product. That platform will deliver multiple capabilities, many of which will be apps that we offer that are more readily consumable, but also the raw Clarity platform capabilities are also going to be available to customers as well. Okay, and how many specialized Clarity products does Consensus offer? Well, we talked about Clarity CD and Clarity PA today. We're working on some others that, again, not prepared to talk about at this point in time, but I would say look for our announcements in the coming quarters. You will see a number of additional Clarity apps, and you will also see more information about what other things are being done on Clarity in the form of use cases and press releases and whatnot. Okay, and it seems that that is all of the questions that we had today. I would now like to hand the floor back to Jeff and John for any closing remarks. Well, I'd like to thank everybody for paying attention to this. You know, we're really excited about what we're doing with the application of our Clarity platform in our products and between our products. As I mentioned just a moment ago, look forward to more exciting news to come in our earnings results and our quarterly meetings coming up. And thank you all for your attention. John, any final thoughts? I really appreciate everybody's time again this morning. The opportunity to talk about the advancements that we're making in this key area and the way that we are building value, not only for us as an organization, but for the healthcare community at large. Thank you again for your time. Thank you, ladies and gentlemen. This does conclude today's event. The replay for this event will be available this afternoon. Please use the same link to access the replay. Also, please follow up with Consensus regarding any further questions regarding the content of today's webcast. Thank you for your participation. You may disconnect.