Setting Verbose mode for a Boomi Process using a Dynamic Process Property
In most instances developers will have to accommodate certain reporting, notification and logging requirements of a given interface within the Dell Boomi AtomSphere platform.
Often times, the logging or emailing may need to be disabled for testing and/or faster iterative cycling through test cases and, of course, to not annoy the user community with email test messages.
The most straightforward way to accomplish or implement a verbose or Test Mode Boolean flag (as is very common in other platforms) is to create and enable a Dynamic Process Property and then assign its default value while allowing to reassign the same with extensions directly after deployment.
Dell Boomi provides the concept and implementation of extensions to allow developers and administrators to have distinct values for different environments without having to use multiple connectors of the same type.
As an example in a given scenario where a Dell Boomi Process uses a disk connector to read a file but the file location changes from environment to environment.
1. Test Server file folder location: C:\TEST\Inbound
2. QA Server file folder location: C:\QA\Inbound
3. Production Server file folder location: C:\PROD\Inbound
It’s no secret that paying for healthcare in the United States is extremely difficult to do. Payment systems for healthcare across the country are highly fragmented; many payers and providers use multiple formats for remittance. This creates challenges and frustration for patients, providers, and insurance companies, particularly at a time when there is increased pressure to reduce costs. Other industries use B2B automation processes in standard languages like EDI to standardize and automate payment systems; B2B challenges abound for the healthcare industry.
The B2B challenge in healthcare remittances
Thanks to the Affordable Care Act, there are now in motion some new initiatives related to healthcare payment reform – chief among them, the transition from fee-for-service to value-based care. “The ramifications of this transition for payers are significant,” says John Tyler, Data Science Platform Manager at Premera Blue Cross. “Payers are going to…
TriZetto’s QNXT is a widely adopted platform for claim processing and membership administration. QNXT relies on the Microsoft stack, particularly BizTalk, .Net and SQL Server, to process and store EDI messages.
These technologies give developers many tools for customizing and tracking HIPAA transactions, but the complexity of implementing business rules and lifecycle reporting on EDI data are constant concerns for health plan payers.
Tallan’s T-Connect EDI Management Platform is an optimized integration solution founded on three core design principles:
An accessible API. One of the most common challenges our partners face is implementing business logic on EDI. T-Connect loads all HIPAA transactions into a fully compliant hierarchical data structure that can be manipulated with familiar tools such as Visual Studio and .Net.
Full database persistence. Going from EDI to a relational database is a frequent business need, but capturing the full set of fields present in an 837 alone represents…
On the provider side of healthcare integration, HL7 (particularly v2) is a critical message type to understand. While it is standardized and heavily used by various EHRs/EMRs, it’s used in slightly different ways. There are efforts to further standardize and normalize its use across the board (such as with v3/FHIR), many EHRs and EMRs continue to use 2.x messages. Common HL7 messages include admissions/transfer/discharge (ADT), scheduling (SIU), lab orders and results (ORU, ORM), and medical reports (MDM). Choosing the right platform can be challenging.
Some of the challenges of HL7 2.x messages include:
The ability to add non-standard custom segments or additional data anywhere in the message (whether they are completely custom “Z Segments” or other segments that aren’t typically part of the message, such as IN1 segments in an ADT message to include additional insurance information).
A myriad of parsing and manipulation libraries…
Over the past few years, the healthcare industry has undergone a complete overhaul of how it processes information. This was brought about by a growing list of new and complicated regulations handed down by federal and state governments that stem from the Healthcare Insurance Portability and Accountability Act (HIPAA) and the Patient Protection and Affordable Care Act (ACA), designed to improve the efficiency and effectiveness of the industry. These regulations include standardization of the electronic transmission of Electronic Data Interchange (EDI), which also protect the security and privacy of electronically transmitted information provided by their patients.
These mandates created an immediate challenge to healthcare organizations, because it required the industry to take increased ownership and control of Electronic Health Records (EHR). In order to meet this demand quickly, healthcare providers scramble to leverage a variety of methods to manage their EDI…
This month we are happy to announce new versions of a few of our products adding additional features and capabilities.
First, we have updated our T-Connect EDI Database to support the full ANSI X12 EDI 837 transaction set. This includes full support for Institutional, Professional, and Dental transaction sets. The EDI Database Toolkit is our proprietary set of databases constructed to store and archive EDI messages and is included in our EDI Accelerator package, or can be purchased as a standalone product.
We have a new version of our T-Connect HIPAA EDI Accelerator available. The EDI Accelerator is our flagship product allowing for rapid deployment of a complete end to end EDI intake and storage solution based on the Microsoft BizTalk Server platform.
The T-Connect EDI Viewer has been updated with backwards compatibility for the EDI ANSI Version 4 (004010). The EDI…
All of us who have worked on EDI integration know the pain of maintaining the integrity of the EDI messages coming into the system, as well as the value of validating them right from the pipeline-gate. To aid in this, Microsoft BizTalk Server supports out of the box verification of structural integrity with extended schema validation settings. The great part about this is that it allows us to reject any incoming EDI transactions right out of the gate and return those results in the generated ACK file. This way, we ensure that we don’t let invalid data into the system, while also making the sender aware of our “bad data” rejection.
However, as great as this feature is, it still leaves a major validation pain point.
Let’s consider following scenario.
Let’s say in the case of EDI 837 transactions, we consider REF*D9 as…
In September of last year, we released the T-Connect EDI Splitter For BizTalk. We are proud to announce the release and immediate availability of the newest version of the T-Connect EDI Splitter. For the uninitiated, the EDI File Splitter is a Microsoft BizTalk Server pipeline component that enables the rapid splitting of large EDI files within BizTalk Server. These split files are delivered to an user configurable folder location. Along with additional features added to the EDI Splitter for BizTalk, we are also releasing a standalone application for Microsoft Windows available today: The T-Connect EDI Splitter for Windows
EDI files offer many advantages in business and health care messaging, and BizTalk offers a premier suite for handling EDI interchanges and agreements. At the same time, EDI files are notoriously difficult to read, even for EDI experts and highly skilled Business Analysts. The T-Connect EDI Viewer is designed to address this gap. It supports converting the HIPAA EDI 837 transaction sets (for Professional, Institutional, and Dental) as well as the HIPAA EDI 834 Enrollment transaction set to a human-readable and printable PDF format.
The T-Connect EDI Viewer offers a library and a pipeline component that can be used to convert EDI messages sent to BizTalk into a PDF version of their Paper Form equivalents. This conversion could be done as part of an existing integration, or using archived/historical data on a case by case basis. The PipelineComponent offers a very simple way…