Transcript:
0:06 Hello everyone and welcome. Today we're
0:08 diving into a really interesting setup
0:10 that uses Azure service bus cues to
0:13 streamline the processing of potential
0:14 claims, specifically those flagged for
0:16 potential fraud.
0:18 >> That sounds like a vital system,
0:20 especially with the need to identify
0:22 fraudulent claims quickly. How does this
0:24 all tie together?
0:26 The core idea is that dental claims are
0:28 initially created on an external system.
0:30 Once generated, they are then passed
0:33 onto an Azure service bus Q. From there,
0:35 a North52 formula kicks in, picks up the
0:38 messages, and creates the necessary
0:40 claim and detailed claim records inside
0:42 data versse, then flags them for manual
0:44 review. It's a crucial part of a broader
0:47 automated claims processing system.
0:49 So the service bus acts as a kind of
0:52 waiting room for the claims and North52
0:55 formula is what process is there
0:57 >> precisely. Let's break this down
0:59 starting with how the Azure service bus
1:01 Q is set up. First you configure the
1:04 service bus in the Azure portal. The key
1:07 here is that we're using the shared
1:08 access policies to get the root manage
1:11 shared access key. This grants the
1:13 necessary authorization to send manage
1:15 and listen to the service bus. Once
1:17 that's set, we can create this specific
1:20 queue. In our example here, we're using
1:22 the fraud review queue.
1:24 >> And how do claims actually get onto this
1:26 queue?
1:27 >> That's a great question. For testing, we
1:29 can manually put messages onto the queue
1:31 using something something like the Azure
1:33 Service Bus Explorer. We format these
1:36 messages as a JSON object. This JSON
1:39 includes critical information like the
1:41 claim ID, a patient identifier, and an
1:44 array of procedures that are part of the
1:46 claim. This array includes details like
1:48 the procedure ID and the data was
1:50 performed.
1:52 >> Okay, so claims are on the queue as
1:54 JSON. Now, how does North52 read them
1:56 and do its magic?
1:58 >> That's where the North52 formula comes
2:00 in. We've set up a formula of type
2:02 client side calculation. This allows us
2:05 to invoke directly from a ribbon
2:06 command. In this case, the fraud review
2:09 button. This ribbon command is
2:11 configured on the claims list view using
2:14 North52 quick ribbon, making it super
2:16 easy for an agent to trigger the
2:18 processing. When the command is clicked,
2:21 it activates our formula called claim
2:23 potential fraud review.
2:26 >> So an agent just clicks on a button and
2:28 the system processes the next claim in
2:31 the queue. What exactly does the NO52
2:33 formula do behind the scenes?
2:35 >> So it's a multi-step process designed
2:37 for efficiency. First, the formula will
2:40 peek at the queue to check if there are
2:41 any messages waiting. If there aren't
2:44 any, it simply exits and alerts the user
2:46 that nothing was found. If there is a
2:48 message, it proceeds. Since the message
2:50 is in JSON, the first step is to parse
2:53 the relevant information from it.
2:55 >> And then it starts creating the records.
2:57 >> Exactly. Using the parse data, the
2:59 formula creates the main claim record.
3:02 It pulls information not just from the
3:04 received JSON but also by looking up
3:06 additional details within data versse to
3:09 augment the initial claim data. After
3:12 that it loops through each procedure
3:13 listed in the JSON and creates
3:15 individual claim detail records
3:17 associating them each with the newly
3:20 created master claim.
3:22 >> So it builds out the entire claim
3:24 structure within database. What happens
3:25 after all the records are created? So
3:27 once all the processing is complete, the
3:30 master claim and the claim detail
3:31 records are created. The formula then
3:33 removes the message from the Azure
3:35 service bus Q. This prevents the message
3:37 from being processed more than once.
3:40 Finally, and this is a great user
3:42 experience touch, it automatically opens
3:44 the newly created claim record for the
3:46 end user. This allows them to
3:49 immediately begin their manual review
3:51 for potential fraud without having to
3:54 actually search for the the record.
3:57 That sounds incredibly efficient. So,
3:59 this system effectively automates the
4:01 initial intake and record creation for
4:03 the specific claims, then presents them
4:05 directly to the agent for review.
4:08 It really cuts down on manual data entry
4:10 and ensures quick follow-up on
4:12 potentially fraudulent activity.
4:14 >> Absolutely. It's a prime example of how
4:16 integrating Azure services with North52
4:18 formulas can create a powerful and
4:21 automated process, significantly
4:23 improving operational efficiency and
4:25 fraud detection. capabilities.
4:27 >> Thanks for that really clear
4:29 explanation. It really highlights the
4:31 benefits of this automated approach.
4:33 >> You're welcome. And if you or any of our
4:35 viewers should have any questions,
4:37 please visit support.North52.com.