The Centers for Medicare and Medicaid Services' adoption of the National Council for Prescription Drug Programs (NCPDP) SCRIPT standard v2017071 is set for January 1, 2020. While this new standard improves efficiency, accuracy and patient safety, the transition from the current standard (v10.6) is proving to be complex.
As an early adopter, DAW Systems has been testing the new SCRIPT standard, and we’ve learned a lot.
Here are our top five tips for a smoother implementation (be warned, this is going to get fairly technical, very quickly, but I suspect that’s what most of you are looking for at this point):
1. Catch errors before they leave the building.
NCPDP provides documentation to support the migration to SCRIPT v2017071, including an XML schema file commonly referred to as an XSD. The XSD describes the elements of an XML file in a markup language. This language can be used to check the incoming or outgoing XML prescription messages to ensure the message itself is properly formed and complies with rules (i.e. Field Lengths, Required Fields) and conditional requirements. Validating the XML can point developers to issues with the code base before it reaches the Surescripts network, thus saving immense time and energy during the course of the migration.
2. Get a head start.
Surescripts has adopted a new protocol for authenticating incoming requests called Mutual Authentication, or two-way authentication. In other words, both Surescripts and DAW use certificates, so our systems can verify each other. While it’s a much more secure approach, this may be new for many E-Prescribing vendors and users, so there’s a learning curve. Give yourself time to test. Get the connectivity piece started first so that once you’re ready to send prescriptions, you’re connected.
3. Take a holistic view.
You may think there’s an obvious approach to upgrading, whether message by message or old vs. new. However, taking a holistic view lets you to see what’s common, what’s changed and what hasn’t changed. Rather than going message by message, hit all messages at once. There are commonalities that can be done at the same time.
- Read all NCPDP and Surescripts documentation (ask your Account Manager, if you need guidance).
- Rename all fields that have changed from v10.6 to v2017071 across all message types, i.e., ZipCode is changed to PostalCode.
- Create Relationship upgrades to reflect new parent child XML structure.
- Implement Optional functionality within the 2017071 standard.
- Update your User Interface to reflect standard and backend server requirements.
- Create Business Logic changes that may affect the backend and user interface, paying special attention to the NCPDP standard and the Application Certification Requirements delivered by Surescripts. (Tip: Review the tests to ensure that the application is capable of meeting the expected results.)
- Test code base using Surescripts defined test cases.
- Complete Certification with a Surescripts Integration Manager.
- Upgrade Directories structure and calls. The directories are not part of the NCPDP v2017071 standard but have been upgraded to facilitate changes that have resulted from the migration.
- Perform Post-Certification Testing to ensure no breaking changes happened during the testing and repairing process.
- Go-Live in production.
4. Account for legacy messages.
It’s going to happen: you get to the end of a project and now the code you just pushed out means you can’t process a NCPDP SCRIPT v10.6 message because it’s no longer valid. You need to account for the messages that haven’t been reviewed by a physician. In other words, the code base might need to be able to send both v10.6 and v2017071 standard prescriptions and historical v10.6 prescriptions will still need to be accessed by medical professionals. Vendors will need to ensure read only access to historical prescription information.
5. Get to work ... and keep working.
Important things come up. Fire drills happen. But don’t let yourself get distracted. It’s in your best interest to get the code base upgraded as fast as possible. Don’t stop until you’re live, as delays will almost certainly cause outages and the deadline is fast approaching. It will take time to ensure the application is stable, and often times migrations to production environments are complex. It’s best to do this while the code is fresh in the minds of your developers.
I hope our findings prove to be beneficial to you, but I realize that one size does not fit all. Take what’s relevant and make it your own. Here’s to a more streamlined (and less stressful) migration for all of us.