Advance Beneficiary Notice (ABN) Support

Today we start upgrading our draw station app to support Advance Beneficiary Notices (ABNs).

The formatting is not a problem, because I know how to use groff and ghostscript to make PDFs which match the specs.

The calculation of benefits is being done by the LIS, not because we can't parse the same file that they do, but because the client wants a single instance of this kind of calculation, which makes sense.

Closing the loop is where we excel: we are setting up a system to capture an image of the signed (or not signed) ABN and then automatically attach that image to the draw. Furthermore, we are automatically populating a web page for the billing folks so that they can either access the image directly or see which draws do not have ABN, but should have had ABNs.

Crossing internal boundaries is essential to our success in providing automation which really works.

Here is what one of our test ABNs looks like after scanning and being automatically attached via its bar code:

Note: the image is a bit crusty because I converted the original PDF into a PNG to appease Blogger

Laboratory Manual for SoftLab

The client has a shiny new SoftLab installation from SCC. What they do not have is an automatically generated Laboratory Manual (LM) to go with their new test definitions.

They want to use their SoftLab test definitions, so far as they go, because the LIS's test definitions are what is actually in use.

But they need more attributes to create a fully features LM and they do not want to create this HTML document by hand or with a Content Management System because they want the LIS test attributes refreshed automatically every night and new LM generated early every morning.

Furthermore, they want an internal version, containing internal processing notes and procedures, and an external version, without internal material and including contact information, etc.

I defined some terms to help them understand their problem:

• core test attributes--the SoftLab test definitions
• extended test attributes--the addition ones needed for the manual

Our solution for them has the following pieces:

• a database into which to put these attributes
• a SoftLab interface to get the core attributes
• a desktop app to provide a rich UI for maintaining extended attributes
• a template-driven HTML document creator which runs automatically
• an interactive search tool to provide users with a way to search

 The system understands the differences between internal tests, orderable-only tests, resultable-ony tests, orderable & resultable tests and groups. Groups are automatically expanded as appropriate. The format and contents of the internal and external manuals varies as appropriate.

As part of getting this up and running, we provided tools for debugging the SoftLab definitions and validating the groups, especially with respect to groups of groups.