Posts filed under ‘Uncategorized’

Understanding NCPDP Standards

National Council for Prescription Drug Programs (NCPDP) publishes standards for the electronic exchange of healthcare information related to pharmacy services.

NCPDP standards

SCRIPT Standard Uniform Healthcare PayerData Standard Retiree Drug Subsidy Standard Prescription Transfer Standard Post Adjudication Standard Pharmacy Claim Payment Standard
NCPDP Connectivity Standard Medical Rebate Data Submission Standard  Manufacturer Rebate Standard Formulary and Benefit Standard Financial Information Reporting Standard Billing Unit Standard


 Batch Standard  Audit Transaction Standard

SCRIPT Standard for Electronic Prescribing

In this blog we will discuss the SCRIPT Standard used in Electronics Prescribing. This standard covers data exchanges between prescribers, pharmacies, intermediaries and payers.


SCRIPT is a standard data set for the interchange of prescription data and related information in the medical provider community.
So let’s talk about the formats used in this standard. There are of two types, XML and EDIFACT. The older versions such as 4.2 are in EDIFACT format.
The newer version such as 10.6 has an XML format option. If you are a member of NCPDP, you can download all their standards and the related implementation guides.

1. Version 8 and later are now using XML data dictionary. Current standard is 10.6 (as of August 2014).

2. Version 8 and earlier are in UN/EDIFACT standard (transaction types in the UIH segment indicates the message type and subject)

We will show different message types in both XML and EDIFACT format later in this post.

How does Adeptia integrate with NCPDP standards?

Adeptia is a member of NCPDP and provides full NCPDP Standards Data Dictionary, Process Templates and the Data Mapping rules to route and convert the NCPDP data into any target format. The process templates depends on the type of transaction we are working with, for example here are all the SCRIPT transactions along with their Message IDs and descriptions of the most widely used transactions:

• New prescription request  (NEWRX)

- Prescription request from the doctor to the pharmacy

• Change of new prescription (RXCHG)

- These transactions are used when the pharmacy is requesting change in the original prescription, and the prescriber’s response. An example may be to change the daily dosage of the prescribed medicine or changing the medicine to a specific manufacturer.

• Cancel of prescription (CANRX)

- This transaction is a request from the prescriber to the pharmacy to not fill a previously sent prescription, and the pharmacy’s response.

• Refill/renewals request/response or Resupply in long term care (REFREQ, RESUPP)

- These transactions are used from the pharmacy to the prescriber requesting additional refills and the prescriber’s response.

• Fill Status notification (RXFILL)

- This transaction is sent to the prescriber from the pharmacy and indicates the status of the dispensing (dispensed, partially dispensed, not dispensed).

• Medication history exchange (RXHREQ/RXHRES)

- This transaction is from a pharmacy or a doctor requesting medication history from a healthcare provider, and the medication history response.

Following are some of the other transaction types:

• Password Change (PASCHG)
• Status is used to relay the acceptance of a transaction back to the sender (STATUS)
• Verification (VERIFY)
• Drug Administration exchange in long term care
• Prescriber-reported samples for more robust medication history
• Query functions for new prescriptions

How to Implement SCRIPT Process flows in Adeptia?

Advantage of using Adeptia Integration Suite is that it enables your business users or non-technical users to configure the above transactions quickly without having to write code or to read through complex implementation guides. Adeptia has done all the work for you by providing a graphical process designer interface to allow you to configure any SCRIPT process and by giving you access to all the data dictionaries that will help in parsing, validating and converting any NCPDP data to any format. Here is an example of the New Prescription process suggested in the NCPDP Implementation guide and the template flow in Adeptia.

script process


Here is the New RX and Change RX Request/Response Process Flow template in Adeptia.

script process adeptia

Now apart from the SCRIPT processes as described above, understanding the SCRIPT data formats and how it relates to each other and more importantly how it can be converted into any another format (let’s say a database) is core to a successful implementation of a NCPDP process.

Let’s take a look at a sample SCRIPT XML message

Transport node consists of the following sections:

1. Patient information such as SSN, Name, Address, DoB, Phone.


2. Pharmacy data such as the NCPDPID, NPI, Address and Phone.

xml33. Prescriber data such as the NPI, Name, Address, Phone.

xml24.  MedicationPrescribed that contains the Drug Description, Dosage/Quantity and instructions.



Let’s take a look at a sample SCRIPT UN/EDIFACT message

A SCRIPT message interchange consists of following segments. An interchange is defined as communication between partners in the form of a structured set of messages and service segments.

Service Advice String  UNA Used to define the characters selected for use as
delimiters and indicators in the rest of the interchange that follows.
The Service String Advice must be the first segment of the message.
It is a fixed length segment. All data elements must be present.
Interchange Header  UIB The service segment starting and identifying an interchange.
Interactive Message Header  UIH The service segment starting and uniquely identifying a message.Such as SCRIPT and the subject as PASCHG.
Data Segments  PVD, STS etc.
Message Trailer  UIT  Service segment ending a message
 Interchange Trailer   UIZ  Service segment ending an interchange


A sample SCRIPT message in UN/EDIFACT format:


Here the UIH segment uniquely identifies that it is SCRIPT interchange type with NEWRX as the message type. Adeptia provides the full UN/EDIFACT data dictionary to parse and validate SCRIPT data and allows users to map it to any format.

How to map the SCRIPT data in Adeptia?

In Adeptia’s Data Mapper, simply pull up the particular XML or UN/EDIFACT Schema of the SCRIPT transaction type and map it to the target system. Sample mapping shown below.


In the mapper you can also preview the data and validate your mapping rules before saving the map.

Now each SCRIPT message would have different mapping rules depending upon the target system you would want to map the source data to. For details on how the NCPDP data processing and mapping is supported by Adeptia, please contact us at

To learn more about NCPDP Standards please visit

September 22, 2014 at 12:11 pm Leave a comment

Security concerns on using Eclipse based ETL tools

In this article we will describe how Adeptia’s web based development paradigm eliminates the security risks associated to using the traditional Eclipse based ETL products.

Restricted and role-based authorized access to Eclipse based ETL tool is non-existent and on top of that all our competitors are code generating toolkits that run on Eclipse IDE. In Adeptia you don’t write code, you configure services and at run-time the orchestration is meta-data driven. Simply put in Adeptia ETL you configure services, in other ETLs you end up writing Java or .Net code.

When determining the feasibility of any ETL or Integration product for your organization one has to look beyond the immediate needs of addressing a specific pain-point in regards to data integration. For example lots of companies choose an ETL product without comprehensively analyzing the strengths and weaknesses of the product functionality beyond data extraction, transformation and load. One of the key requirements that is often missed or skipped during the evaluation is developer access controls and user security.

Typical ETL software is Eclipse IDE based thick client that runs on the user’s local machine where the developer has full access to the software. Metadata, custom code, rules surrounding data transformations, connections to sensitive data repositories, orchestrations, and other artifacts such as deployable code is all stored locally in the workspace. Therefore this creates a critical security risk for companies who are concerned about exposing their intellectual property to outside threats.


Building any ETL solution in a local workspace poses a security risk as those artifacts can be shared deliberately or inadvertently with other companies. Data gets processed within the local workspace and the threat of losing that sensitive data to outside threats cannot be ignored. Tracking and monitoring who is developing what and what changes are being made is non-existent. Developers can keep the code in CVS but a copy of the code remains in their local workspace.

Key points to consider are:

  1. If a developer leaves your company tomorrow how does your company transfer that work to another developer?
  2. How does your company prevent the code/artifacts being lost or shared with another company or a competitor?
  3. Documenting the work is non-existent in Eclipse IDE based ETL tool.
  4. Tracking all the revisions is not scalable or manageable if the workspace is local to the user machine.

Adeptia ETL and Integration Suites eliminate these critical security risks by providing a Group/User Role based secure access to a centralized web based development interface.


Adeptia Suite is hosted on a Server and developers access the interface through a web browser with secure login.  Adeptia Suite is a software product that can be deployed either on-premise at customer location or it can be deployed in the cloud.

With a web-based development interface, Adeptia allows system administrators to create developer accounts or pull accounts via LDAP (single sign-on is supported) and define their role and access rights. And as the developers login with these access controls they are able to use specific functions of the product.


Developers can be restricted from accessing sensitive database and API connection properties and their entire activity can be tracked through an audit-trail dashboard. Developers only use their browser and log in with their credentials and the homepage of the ETL/ Integration Suite would only allow access to specific functionality based on the user role defined by the administrator.


In addition to the role based user access controls, Adeptia is a codeless solution development platform and the generated metadata is stored in a centralized repository that allows for easy tracking and management of all the activities created by the developers. Version control allows developers to check-in and check-out any artifact for updates based on the permissions granted by the owner or the administrator. Each activity created in Adeptia has its own permission options such as Read, Write and Execute for other developers in the group.


In Adeptia Suite, an Administrator can Activate or Deactivate a user through the admin console.


In Adeptia Suite, an Administrator can move and change ownership of all the objects created by a developer to another developer.


Administrators can create different groups so that the solution which the developers are building in one group can be restricted from being shared with another group. Groups also allow an easy way to organize your development team.


Another advantage that the product offers is the collaboration aspect surrounding solution development. Individual developers through permissions can also share their work with other users so that the development of a solution becomes a joint effort between different groups or users within the company. For example, the Business Intelligence group can design a process and the developers in the IT group can reuse that design and configure the process to make it functional.

Administrators have full access to all the run-time transactions and system status.


For an in-depth demo on Adeptia’s security architecture please schedule a web meeting by contacting .

August 11, 2014 at 10:13 am Leave a comment

Workflow Design that Enables Self Correction

The scenario relates to routing the workflow to another task if it’s determined that the previous task was not performed correctly or the individual missed out on completing the task at 100%, Adeptia can route the workflow to a ‘correction’ flow based on any condition such as error threshold (in this case 30% or 40%).

We would need to design the models that would be invoked if the errors exceed 30% (or whatever thresholds) and what those pre-defined ‘correction’ flows would be.

So if the initial workflow task produces errors and if they exceed 30% then the application needs to identify that error condition and then route the workflow to another flow which would allow user to correct their mistakes.

Now as part of this workflow, a report detailing what those errors are can be generated for the manager so that they can analyze the trends along with the performance of that user working on their tasks.

Here’s an example:

Customer Care process that is started when a customer calls and a representative takes the call.

Step 1: Take Call

- This first task can have several data points that needs to be captured, and what if the call center rep fails to capture those data points (there could be other scenarios as well).

Step 2: Validation / Suggest Correction sub-workflow

- Here set of rules can be applied to determine whether the work completed in the previous step is 100%. If not then that task needs to be rerouted back to the call center rep and prompt for the data points that were not captured correctly. This would be a ‘correction’

workflow to help user correct their mistakes. This flow can also generate reports (and historical reports) to give Managers analysis of user performance and completion trends (similar to KPI dashboards).

Self correction to figure out “why” something was missed in Step 1 can be based on a Rules table that can be used to dynamically determine the right process to take. Adeptia architecture supports dynamic routing and process calls that can be based on what is done in the previous step of the workflow.

Step 3: Proceed to Technician onsite visit scheduling

- Now when the customer support case is routed to a next review step to ascertain if a technician is needed to resolve the customer support complaint all the information is available to complete this workflow.

In the below screenshots we have an example that checks for errors in the previous completed task and if errors are found, user would be assigned a new task which will have the original submitted content and instructions to correct those errors. Here the instructions can be a link to a video as shown below.



February 26, 2013 at 12:35 pm Leave a comment

It is 2010, and EDI is still going strong?!?

Adeptia announced the release of its EDI Integration Solution. This software solution helps companies automate date flows that generate Electronic Data Interchange (EDI) messages from internal data or process incoming EDI messages and integrate them with internal systems, databases and SaaS applications. Besides EDI-XML integration, Adeptia includes support for trading partner configuration and management. This solution includes support for ANSI X12 and UN/EDIFACT. All X12 standards and release versions are supported – from the popular 5010 and 4010 standards to others including the 4020, 4030 and the earlier 3010. All transaction sets are also supported including the transactions related to Health Insurance Portability and Accountability Act (HIPAA).

EDI Integration An example use of this EDI Integration Solution is for growing manufacturing and logistics companies to automatically handle increasing traffic of EDI messages. Usually the smaller organizations handle EDI in a manual way by using a business person to check manually for incoming EDI messages in the mailbox, download the message, open it in an EDI translator and then visually read the information and type it into their in-house order management, accounting and ERP systems. This approach does not scale when the organization grows and is interacting with many retailers and trading partners who not only want to exchange Purchase Orders and Invoices but also Advance Ship Notices and other transactions and so there are lot of incoming and outgoing EDI messages. This requires an end-to-end, fully integrated EDI solution for automatic processing and generation of EDI messages. The Adeptia EDI Integration solution easily and quickly meets this need.

“Despite advances in XML and Web Services, EDI still remains the dominant standard for data exchange between companies and organizations. Moreover, certain EDI standards such as ACORD AL3 in Insurance industry and HIPAA/HL7 in Healthcare have shown strong growth momentum in recent years. Adeptia has further strengthened the Business to Business Integration (B2Bi) capabilities of its product line with the availability of a powerful, yet easy-to-use EDI Integration Solution.”, said Lou Ennuso, CEO of Adeptia.

July 31, 2010 at 9:02 pm 1 comment

The new, new thing – Next-Gen SaaS Integration

Document: Adeptia Unveils Next Generation SaaS Integration Solution . (1 page, 5 mins to review).

Traditional SaaS integration solutions have focused on just moving data in and out of SaaS applications. This approach may be fine for some scenarios such as data migration, reporting or synchronization. However, it is quite limiting because real world business problems require users to interact with data flows to review information, make decisions and route tasks. So, Adeptia has extended its existing SaaS Integration solution to allow SaaS applications to be integral part of customer’s business process flows.

For example, an order management process may require moving orders from to an on-premise ERP system when a sale is completed and order won. However, this process would typically require workflow steps for business users to review and configure the order. A process flow such as this with multiple user workflow steps can be easily and rapidly configured in Adeptia. Adeptia offers an SOA-based, code-free approach with built-in connectivity to many SaaS applications such as Salesforce and NetSuite.

Data integration market has evolved over the last few years as more and more companies have realized that the business problems they were trying to solve by implementing data bridges did not really do the full job. Most problems require solutions that are more complex than just moving the bits and bytes. They require the data to be validated before it can be processed, errors need to be handled, notifications sent automatically on exceptions, information presented to business users to review and make decisions etc. etc. These solutions quickly grow beyond the capabilities of typical “integration products”.

Complete solutions require flexibility to handle various situations and scenarios and this typically requires a process-centric, services-based technology that includes human workflow capability. Integration-centric process management products, such as Adeptia, are best suited for these situations.

November 17, 2008 at 3:01 am 2 comments

Integration Options for SaaS Vendors

Document: SaaS Integration for Vendors. (11 slides, 5 mins to review).

As Software as a Service (SaaS) adoption has grown exponentially over the last few years, many customers using hosted applications have started asking the SaaS application vendors to provide data integration and connectivity capabilities. For various reasons, mainly driven by business needs, customers are looking to tightly integrate their data in the SaaS app with their on-premises back-end systems and databases.

There is an excellent article on this growing need in the Oct 20th, 2008 issue of InformationWeek by Mary Hayes Weier: SaaS Integration: Real-World Problems, And How CIOs Are Solving Them.

At Adeptia in recent months we have encountered an increasing demand from our customers for easy, fast and flexible SaaS integration solutions. Primarily these have centered around integration requirements from customers using Salesforce and NetSuite applications but now we see other SaaS apps as well as the whole market experiences growing adoption.

We have had numerous discussions with a number of SaaS vendors who are looking at how should they approach this whole issue of integration. It definitely seems to surprise the SaaS companies as they have mainly focused on creating the best, feature-rich application they could and have not given much thought to integrating the customer data with their internal systems.

Here are the key elements of advice we offer to these SaaS vendors:

  • As with any other business issue, approach SaaS Integration as a STRATEGY and not a tactic.
  • This means have an end goal in mind in terms of where you want to be with your integration capabilities and address the immediate customer need in a way (tactic) that puts you on path for that end goal.
  • Address this need and grow your capabilities in an incremental but multi-phased approach.
  • Bring in the experts since Integration is tough, difficult and complex.

In terms of options available to SaaS vendors, Adeptia offers the following framework:

  • Option A: SaaS vendor provides integration services
  • Option B: SaaS vendor publishes XML/Web Services interface
  • Option C: SaaS vendor refers customers to Certified Partners

This framework is described in this document prepared by Adeptia (11 slides, 5 mins to review) and it covers the Pros and Cons of each option.

As SaaS and Cloud computing adoption grows over time, availability of viable integration options will be expected by customers of any SaaS provider. SaaS vendors who proactively take steps to implement a well-thought out integration strategy will be better positioned than those who treat it as an after-thought.

November 10, 2008 at 12:11 am Leave a comment

An Enterprise Architecture Framework for all seasons…

Document: Adeptia Enterprise Architecture Framework. (27 slides, 15 mins to review).

Over the years, as we sell and deploy our software for our customers, we are amazed to see how many companies do not have an Enterprise Architecture approach in place for their IT infrastructure. This is not just limited to smaller companies for whom an IT Enterprise Architecture (EA) may be an overkill but even many mid-sized to large businesses have not yet invested in putting an overarching enterprise architecture in place.

There are many reasons for not having this architecture in place but some of the main reasons we have observed are:

  • Growth of business from when EA was not needed to now when it is
  • Focus on day-to-day problem solving and short-term IT issues
  • Focus on “must-have” needs rather than “nice-to-have” initiatives which is how EA is perceived
  • Lack of skills in-house to drive, implement and manage EA

Although having an Enterprise Architecture in place is certainly not needed to successfully deploy Adeptia solutions, we recommend our customers to think about having fundamental practices of EA in place to get the maximum advantage from their investment in Adeptia. A well-executed Enterprise Architecture really gets the most value out of a process-centric and SOA-based software solution such as Adeptia. 

Some of the benefits of Enterprise Architecture are:

  • Aligns business strategy with technology investment
  • Creates a vision and strategy for Information Technology
  • “Blueprint” on how to view and approach IT projects
  • Presents a Functional and a matching Technology view for every initiative
  • Helps put a plan in place on how to get to the vision in an evolutionary, incremental way
  • Provides a structure for consistent IT decision making

An Enterprise Architecture for each company would be unique as it will take into account its business model, strategic objectives, size of the business and IT applications and systems. Adeptia helps its customers by providing a “framework” to help them think about a model for how to design an EA that best meets their needs. Here is a document that describes the Adeptia Enterprise Architecture Framework. (27 slides, 15 mins to review). Please keep in mind this is only a “framework”, which is a roadmap or a starting point, and not a full-blown Enterprise Architecture.

This document recommends having two perspectives to an IT Enterprise Architecture: A Functional View and a Technology View. An EA would have the following four key elements:

  • People
  • Processes
  • Systems
  • Information

Each of these elements have a number of other attributes as defined in the document.

We have found that this framework provides an excellent starting point to companies that have not thought about Enterprise Architecture or need a high-level introduction to taking a consistent approach towards all their IT projects and initiatives.

October 28, 2008 at 3:58 am 1 comment

November 2014
« Sep    

Recent Posts


Adeptia Vendors Listing


Get every new post delivered to your Inbox.

Join 1,856 other followers