NIST GCR 11-947 

NIST NCPDP (National Council for Prescription

Drug Programs) Analysis – Standards Action Plan

1

st American Systems and Services LLC 
NIST GCR 11-947

NIST NCPDP (National Council for Prescription

Drug Programs) Analysis – Standards Action Plan

Prepared for 

 National Institute of Standards and Technology

Gaithersburg Md 20899-8202

By

1

st American Systems and Services LLC

August 31, 2011 

U.S. Department of Commerce 

John E. Bryson, Secretary

National Institute of Standards and Technology 

Patrick D. Gallagher, Under Secretary for Standards and Technology and Director

This publication was produced as part of contract SB1341-10-CN-0085 with the National Institute of

Standards and Technology. The contents of this publication do not necessarily reflect the views or policies of

the National Institute of Standards and Technology or the US Government.
1

st American Systems and Services LLC

NCPDP Analysis – Standards Action Plan

August 31, 2011

Prepared by 1st American Systems and Services LLC

for 

National Institute of Standards and Technology

© 1st American Systems and Services LLC

All rights reserved.
© 1st American Systems and Services LLC Page 2 of 20 Standards Action Plan

www.1asas.com

1st American Systems and Services LLC

469 Township Road 1535

Proctorville, OH 45669 

www.1asas.com

Authors

Frank McKinney

fm@frankmckinney.com

Laura Topor 

ltopormn@msn.com
© 1st American Systems and Services LLC Page 3 of 20 Standards Action Plan

www.1asas.com

 1

st American Systems and Services LLC | NIST NCPDP Analysis

NIST NCPDP Analysis – Standards Action Plan

Final, August 31, 2011

Contents

Introduction ................................................................................................................................................4

Summary of SCRIPT 10.6 Quality Opportunities ...........................................................................................5

Summary of other SCRIPT 10.6 Opportunities............................................................................................15

Terminology-Related Recommendations ...............................................................................................15

ECL Management Recommendations.....................................................................................................17

Other 10.6 Documentation Recommendation........................................................................................17

Approach for Addressing Opportunities.....................................................................................................19

Document References ...............................................................................................................................20

NCPDP documentation ..........................................................................................................................20

Project deliverables referenced in this document ..................................................................................20
© 1st American Systems and Services LLC Page 4 of 20 Standards Action Plan

www.1asas.com

Introduction

This document proposes an action plan to address the areas of opportunity in the NCPDP SCRIPT 10.6 

standard identified in the Suitability Analysis project deliverable. The intent is to provide a summary of 

improvement opportunities and possible actions to be performed by NCPDP—with participation from its 

members and NIST—to address those opportunities.

Below is an overview of the document’s contents:

 Summary of SCRIPT 10.6 Quality Opportunities. Identification of gaps and opportunities 

related to basic internal consistency and correctness of the messages for which test data was 

created. 

 Summary of other SCRIPT 10.6 Opportunities. Identification of challenges and opportunities 

related to SCRIPT’s use of standard terminology, compatibility with other standards, 

documentation, and other implementability factors as documented in the Suitability Analysis.

 Approach for Addressing Opportunities. This section presents a set of approaches for 

addressing the opportunities highlighted in the report, to be pursued through collaboration 

with NCPDP.

 Document References. This section identifies:

o NCPDP documentation associated with the SCRIPT 10.6 standard

o project deliverables referenced in this document.
© 1st American Systems and Services LLC Page 5 of 20 Standards Action Plan

www.1asas.com

Summary of SCRIPT 10.6 Quality Opportunities

Below are areas representing opportunities to improve the quality of the SCRIPT 10.6 standard, including the 

XML schema, implementation guides, and related documentation, with respect to...

 internal consistency within the XML format of the standard (e.g., representing a given concept the 

same way in different parts of the schema)

 consistency between the SCRIPT 10.6 XML and EDIFACT formats (e.g., ensuring that concepts are 

represented in an equivalent manner)

 completeness in representing included concepts, for the intended purposes (e.g., the ability to 

represent the aspects and variations of a concept necessary to meet current industry and regulatory 

needs), and

 correctness of the SCRIPT 10.6 specification and documentation (e.g., the accuracy of element 

descriptions, examples, etc.).

Note: More detailed descriptions of these recommendations and the conditions underlying them are 

contained in the Suitability Analysis document.

Header

 In the 10.6 Implementation Guide, include additional guidance on use of prescriber order IDs, 

pharmacy prescription IDs and message trace numbers

 Based on the guidance above, clarify how the EDIFACT elements, UIH-020 Message Reference 

Number, UIH-030-01 Dialogue Reference - Initiator control reference and UIB-030-02 Initiator

Reference Identifier relate to their comparable XML elements. Currently, XML annotations are 

unclear and overlap

 In the 10.6 Implementation Guide, adjust UIB element descriptions to better reflect the guidance 

above

 In the 10.6 Implementation Guide, include additional guidance on use of prescriber order IDs, 

pharmacy prescription IDs and message trace numbers

Security

 In the 10.6 Implementation Guide, include additional guidance on use of the Security composite, 

referencing other pertinent external documentation (e.g., regarding SOAP usage) as appropriate

 In the 10.6 XML, address the condition with the Sender and Receiver composites in which the 

composites are mandatory, but all elements within the composites are optional

 In the 10.6 XML, add EDIFACT element mapping annotations for the Mailbox segment to the 10.6 

XML schema

Error

 Remove or correct the erroneous statement above in the 10.6 implementation guide, Page 119: STS 

Status segment usage table where content in the Code List Qualifier element is apparently copied 

from the Status Type, Code remarks
© 1st American Systems and Services LLC Page 6 of 20 Standards Action Plan

www.1asas.com

Request

 A SCRIPT 10.6 ECL concept in this composite, 4343 Message Function, Coded, is not clearly defined in 

recent ECL versions. See the ECL Management Recommendations section of this document.

Response

 Not all values allowed for ApprovalReasonCode and DenialReasonCode elements are appropriate in 

all message types or composites (Approved, Denied, DeniedNewPrescriptionToFollow). See the ECL 

Management Recommendations section of this document.

 "ApprovedWithChanges" is allowed as a response to a Cancel request, but that does not reflect a 

meaningful real-world scenario. Add clarification in the 10.6 implementation guide (through Errata or 

other means) that ApprovedWithChanges is not an appropriate response to a Cancel request. Adjust 

or remove this option in later SCRIPT versions.

Pharmacy

 There is a mismatch between the number of allowed Identification instances allowed in the EDIFACT 

format versus the number allowed in the XML schema for the Pharmacy Identification element. See 

Challenges impacting multiple sections: XML element cardinality issues, below for details.

 The pharmacy Identification concept mixes identifier types for pharmacies, providers, facilities or 

patients; only a subset of these are appropriate for pharmacies. See the ECL Management 

Recommendations section of this document.

 The Identification concept does not enable differentiation between Individual and Organizational 

NPIs and DEA Numbers, and DEA suffixes are not explicitly supported. See Challenges impacting 

multiple sections: Individual vs. Organizational Identifiers, below for details.

 The Pharmacy State License Number and DEA Number elements do not have state qualifiers. See the 

section, State qualifiers for certain identifiers, elsewhere in this document for details.

 The Address Line 2 and Place Location Qualifier elements present challenges throughout the 10.6 

XML format. See Address Line 2 representation, below.

Prescriber

 In the Medication History Response, the Prescriber composite prior to the medication history loops is 

mandatory; however, every element within the Prescriber composite is optional. As a result, an 

empty composite (<Prescriber> </Prescriber>) is sufficient. Clarify the intent for population of the 

Prescriber composite in the main section of the medication history response message. Provide the 

related guidance for use of the element in the 10.6 Implementation Guide.

 There is a mismatch between the number of allowed Identification instances allowed in the EDIFACT 

format versus the number allowed in the XML schema for the Prescriber Identification element. See 

Challenges impacting multiple sections: XML element cardinality issues, below for details.

 The Prescriber Identification concept mixes identifier types for pharmacies, providers, facilities or 

patients; only a subset of these are appropriate for prescribers. See the ECL Management 

Recommendations section of this document.

 The Identification concept does not enable differentiation between Individual and Organizational 

NPIs and DEA Numbers, and DEA suffixes are not explicitly supported. See Challenges impacting 

multiple sections: Individual vs. Organizational Identifiers, below for details.
© 1st American Systems and Services LLC Page 7 of 20 Standards Action Plan

www.1asas.com

 The Prescriber State License Number and DEA Number elements do not have state qualifiers. See the 

section, State qualifiers for certain identifiers, elsewhere in this document for details.

 The Address Line 2 and Place Location Qualifier elements present challenges throughout the 10.6 

XML format. See Address Line 2 representation, below.

Supervisor

 There is a mismatch between the number of allowed Identification instances allowed in the EDIFACT 

format versus the number allowed in the XML schema for the Supervisor Identification element. See 

Challenges impacting multiple sections: XML element cardinality issues, below for details.

 The Supervisor Identification concept mixes identifier types for pharmacies, providers, facilities or 

patients; only a subset of these are appropriate for prescribers. See the ECL Management 

Recommendations section of this document.

 The Identification concept does not enable differentiation between Individual and Organizational 

NPIs and DEA Numbers, and DEA suffixes are not explicitly supported. See Challenges impacting 

multiple sections: Individual vs. Organizational Identifiers, below for details.

 The Supervisor State License Number and DEA Number elements do not have state qualifiers. See the 

section, State qualifiers for certain identifiers, elsewhere in this document for details.

 The Address Line 2 and Place Location Qualifier elements present challenges throughout the 10.6 

XML format. See Address Line 2 representation, below.

Facility

 There is a mismatch between the number of allowed Identification instances allowed in the EDIFACT 

format versus the number allowed in the XML schema for the Facility Identification element. See 

Challenges impacting multiple sections: XML element cardinality issues, below for details.

 The Facility Identification concept mixes identifier types for pharmacies, providers, facilities or 

patients; only a subset of these are appropriate for facilities. See the ECL Management 

Recommendations section of this document.

 The Identification concept does not enable differentiation between Individual and Organizational 

NPIs and DEA Numbers, and DEA suffixes are not explicitly supported. See Challenges impacting 

multiple sections: Individual vs. Organizational Identifiers, below for details.

 The Facility State License Number and DEA Number elements do not have state qualifiers. See the 

section, State qualifiers for certain identifiers, elsewhere in this document for details.

 The facility name is not a required element, which is inconsistent with other similar concepts 

(pharmacy, prescriber). Consider making the facility name element mandatory in future SCRIPT 

releases, to ensure adequate identification of the sending or receiving facility.

 The facility address is not a required composite for any message type, which is inconsistent with 

other similar concepts (pharmacy, prescriber). Consider making the facility address composite 

mandatory in appropriate message types in future SCRIPT releases, to ensure adequate identification 

of the sending or receiving facility.

 The Address Line 2 and Place Location Qualifier elements present challenges throughout the 10.6 

XML format. See Address Line 2 representation, below.
© 1st American Systems and Services LLC Page 8 of 20 Standards Action Plan

www.1asas.com

Patient

 The location of the patient identification composite is different in the XML format of the Medication 

History and Verify messages than in all other SCRIPT messages. Note the different element sequence 

for Medication History and Verify messages in the 10.6 Implementation Guide, and consider making 

the sequence consistent in future SCRIPT versions

 There is a mismatch between the number of allowed Identification instances allowed in the EDIFACT 

format versus the number allowed in the XML schema for the Patient Identification element. See 

Challenges impacting multiple sections: XML element cardinality issues, below for details.

 The Patient Identification concept mixes identifier types for pharmacies, providers, facilities or 

patients; only a subset of these are appropriate for patients. See the ECL Management 

Recommendations section of this document.

 The location of Patient Date of Birth is different in the XML format of the Medication History and 

Verify messages than in all other SCRIPT messages. Note the different element sequence for 

Medication History and Verify messages in the 10.6 Implementation Guide, and consider making the 

sequence consistent in future SCRIPT versions.

 The XML schema supports a date/time representation of the Date of Birth, in contrast to the EDIFACT 

format in which the Date of Birth format is CCYYMMDD. It is questionable whether the time portion 

is useful / meaningful in the DateOfBirth element. Add guidance to the 10.6 Implementation Guide 

describing the cases where the time format is appropriate for DateOfBirth (if any). Adjust the XML 

schema to remove the date/time aspect of patient date of birth.

 The Address Line 2 and Place Location Qualifier elements present challenges throughout the 10.6 

XML format. See Address Line 2 representation, below.

It is unclear what the anticipated and appropriate use of the Patient Relationship element is in most 

prescription messages (presumably this information could be pertinent in a medication history 

request directed to the patient's payer). Add guidance to the 10.6 Implementation Guide describing 

the expected use of this element. Potentially limit use to the message(s) in which cardhholder 

relationship is appropriate.

Medication

 In the Refill Response, the Implementation Guide indicates that the Medication / DRU segment is 

optional... neither prescribed nor dispensed medication is required. But the XML schema requires a 

prescribed medication. Clarify whether the standard intends for a prescribed medication to be 

required in the Refill Response message. Adjust the 10.6 Implementation Guide or XML schema 

based on that determination.

 Not all code sets allowed in the DrugCoded / ProductCodeQualifier elements would be appropriate in 

a new prescription or other given message type. For example, the standard does not anticipate that a 

prescription would be created for a drug class (NDF-RT) or ingredient (UNII). In the ECL, in cases 

where not all values for a concept are applicable in all composite / element instances where it 

appears, provide a separate set of code values for each instance containing only the applicable 

values. Update the XML schema accordingly. Potentially include direction in the Implementation 

Guide in addition to or in place of ECL changes.
© 1st American Systems and Services LLC Page 9 of 20 Standards Action Plan

www.1asas.com

 Like other ECL concepts, allowed Drug Database Qualifiers are “hard-coded” into the 10.6 XML 

schema, causing challenges for implementers that wish to use the most recent version of the External 

Code List. See the section ECL Management Recommendations, below.

 The maximum length of the Directions element is insufficient for certain situations, e.g., where 

dosing is based on a clinical reading and a number of different variations must be provided. Expand 

the element to accommodate all direction scenarios.

 In the Refill Request message, prescribed drug loop, the schema does not allow the "R" (original 

number of refills) value, in conflict with the Implementation Guide specification and example. This 

appears to be an error in the XML schema. Confirm the omission of the Quantity: Qualifier "R" value 

in the Refill Request's prescribed medication loop. If the intent was to allow the "R" value, correct the 

schema accordingly.

 No direction is given regarding whether and when it is necessary to include the time portion when 

communicating the dates associated with the medication: Written, Last Fill, Expiration, Effective, 

Period End, Delivered On, Validated, Sold. Provide guidance on the use of DateTime versus Date 

types for each of SCRIPT's date elements.

 The XML schema allows a DeliveredOnDate in the New Prescription message; however, this element 

is only used in the Fill Status and subsequent messages in long-term and post-acute settings to 

indicate the date on which the medication was delivered to the facility. Remove the DeliveredOnDate 

element from the NewRx message XML schema.

 The diagnosis qualifier (ICD-9, ICD-10, etc.) is optional in both the Implementation Guide and schema, 

with no conditionality stated. It would be appropriate to require the Diagnosis: Qualifier element 

when the Diagnosis: Value element is populated. If not populated, the receiving system may not be 

able to use the coded diagnosis content. Provide guidance in the Implementation Guide 

recommending that the Diagnosis: Qualifier to be populated when the corresponding Value element 

is populated. Consider adjusting the standard to require the Qualifier in such cases.

 The current XML schema annotation for Diagnosis Qualifier indicates that this XML element relates to 

EDIFACT DRU-070-04. Instead, should reference DRU-070-05.

 The Diagnosis Value element is specified as optional in the XML schema, but given the XML structure, 

including Secondary Diagnosis without a code value would result in an effectively "empty" composite.

Adjust the XML schema to make the Diagnosis: Secondary: Value element mandatory.

 The current XML annotation for the Diagnosis Value element indicates that it relates to EDIFACT DRU070-05. Instead, should reference DRU- 070-04.

 The External Code List values for Prior Authorization Qualifier range from State License Number (0B) 

to BIN Location Number (BO), in addition to Prior Authorization Number (G1) and "order number" (94 

- Pharmacy or Prescriber File ID). See the ECL Management Recommendations section of this 

document.

 The Prior Authorization Value element has two usages as described in the Implementation Guide--

conveying prescription order numbers in the Medication History response message and 

communicating a prior authorization number in other messages. The XML element naming is not 

reflective of the two uses. Consider changing the name for this element in the XML to more 
© 1st American Systems and Services LLC Page 10 of 20 Standards Action Plan

www.1asas.com

accurately reflect the stated usages (including stating the order number in Medication History 

messages), or potentially adding an element dedicated to each purpose.

 Dispensing Pharmacy (used in Medication History). See Pharmacy items above related to 

Identification and Address.

 Ordering Prescriber (used in Medication History). See prescriber items above related to Identification 

and Address.

 The list of DUE co-agent qualifiers associated with this element does not include NDF-RT, for drug 

class. Consider adding drug class / NDF-RT to the list of allowed co-agent qualifiers in the External 

Code List

 Drug Coverage Status usage rules for non-DEA controlled substance products is not clear. Provide 

additional guidance on the use of the DrugCoverageStatusCode for cases where the prescribed 

medication is not a controlled substance. Consider discontinuing use of the field for non-controlled 

substance prescriptions if adoption of the element has not occurred.

 The Time Zone element is only to be used with the NeededNoLaterThan element. Consider 

combining the NeededNoLaterThan date with the TimeZone and NeededNoLaterThanReason into a 

single composite of related elements.

 This NeededNoLaterThanReason is only to be used with the NeededNoLaterThan element. Consider 

combining the NeededNoLaterThan date with the TimeZone and NeededNoLaterThanReason into a 

single composite of related elements.

Structured Sig

 The maximum length of the FreeText directions element is insufficient for certain situations, e.g., 

where dosing is based on a clinical reading and a number of different variations must be provided. 

Expand the element to accommodate all direction scenarios.

 The SCRIPT 10.6 Implementation Guide and the Structured Sig v1.1 Implementation Guide are 

inconsistent with respect to the terminology allowed in the Sig segment. The 10.6 IG and associated 

ECL allow both FMT and SNOMED CT concepts in nearly all Sig elements, whereas the Structured Sig 

v1.1 IG recommends that FMT only be used in one element. 

Provide consistent guidance between the SCRIPT 10.6 and Structured Sig 1.1 Implementation Guides 

and ECL for terminologies to be used in Sig segment elements. Update the associated XML schema 

valid values to match the consistent guidance.

 There are several FMT terminologies that are allowed to be used in the Structured Sig segment, not 

all contained in the NCI NCPDP subset (e.g., route of administration), and not all are updated on the 

same schedule. An implementer that uses multiple FMT terminologies may need to set this value to a 

date that reflects one but not all FMT terminologies used.

Provide guidance in the 10.6 Implementation Guide or addendum regarding population of this 

element when multiple FMT terminologies are used by the implementer. Consider limiting the use of 

FMT to the one concept recommended for FMT in the Structured Sig 1.1 Implementation Guide, 

which would help to clarify expected terminology use for implementers, and would also avoid the 

need to choose between FMT version dates when populating this element.
© 1st American Systems and Services LLC Page 11 of 20 Standards Action Plan

www.1asas.com

 Errata: An example in the 10.6 implementation guide (12.31.4 Tapered dose, page 367) contains two 

errors in SigFreeText: (1) it exceeds the maximum length of 140 characters for this element, and (2) it

omits the value in loops after the initial SIG loop.

 Errata: An example in the 10.6 implementation guide shows an invalid value, "AND" for 

DoseRangeModifier (12.31.4 Tapered dose, page 367). Corrected in later implementation guides.

Observation

 SNOMED and LOINC values allowed by ECL in the MeasurementDimension element are not allowed 

by the XML schema. Make corrections needed to create consistency between the 10.6 

Implementation Guide, ECL, and XML schema.

 MeasurementDataQualifier element allows specification of terminologies whose values cannot be 

expressed in the Dimension element (see above). Further, the element allows an “Other” 

terminology qualifier, which does not adequately qualify the associated Dimension value the 

receiving system must interpret. (1) Remove XML schema constraints which currently allow only the 

four X12 DE 738 observation codes. Remove 4/Other value and replace with specific allowed 

terminologies, or provide clarification regarding the intended use of the 4/Other qualifier value.

 MeasurementSourceCode element: 

o The Oct 2010 ECL values don’t support the units of measure that would be associated with 

observations (within the NCI NCPDP subset, the appropriate terminology would be AD, NCI 

Measurement Unit Code). 

o The April 2011 ECL appears to mis-document this concept as Measurement Unit Code.

o The 10.6 XML schema also holds the erroneous Oct 2010 values. 

o The SCRIPT 10.6 Implementation Guide incorrectly refers to the Units of Presentation 

terminology in conjunction with this element rather than Measurement Unit Code

Provide an errata note in October 2010 ECL indicating that the values indicated are incorrect, and 

that AD/ NCIt Measurement Unit Code is correct. Correct the current ECL so that Measurement 

Source Code contains the content currently identified in the ECL as Measurement Unit Code. Provide 

a cross-reference to the EDIFACT name Source Code List and code 7991. Correct 10.6 XML schema so 

that the single allowed value is AD. Correct 10.6 Implementation Guide to replace the reference to 

Units of Presentation with Measurement Unit Code. Optional: Include other unit of measure 

terminologies (SNOMED CT, other) in the ECL and XML schema.

Allergy

 The XML schema incorrectly defines the AdverseEvent composite as mandatory, which prevents 

compliance with the business rule "if Y in NoKnownAllergies, then rest of segment is empty". This is 

an error in the XML schema that NCPDP recognized and corrected in XML 10.11, but not in 10.6. A 

workaround would be to populate the ItemDescriptionLong filed with a static value like "NONE." The 

proper handling of this situation should be documented in the 10.6 Implementation Guide or an 

addendum, to assist implementers

 The current ECL version does not reference the 10.6 Adverse Event Code List Qualifier concept, as it 

has been replaced in later NCPDP standards versions with another concept name. It would benefit 

implementers to continue to include all 10.6 concepts in ECL versions during this period in which 
© 1st American Systems and Services LLC Page 12 of 20 Standards Action Plan

www.1asas.com

version 10.6 is being adopted. The current practice of removing references to SCRIPT 10.6 concepts 

causes implementers time and confusion. See the ECL Management Recommendations section of this 

document.

 Earlier ECL value lists for the AdverseEvent: DrugProductCoded element do not include the specific 

RxNorm term types; instead has a single "RxNorm" qualifier. The replacement concept, 

AllergyDrugProductCodedQualifier contains the necessary RxNorm qualifiers but isn't allowed for use 

with 10.6. It would benefit implementers to enable use of the most recent ECL values for this 

element. It is unclear why the typical practice of adjusting ECL value sets over time for existing SCRIPT 

elements is not followed in the case of this particular element. This may be an instance where a more 

formal ECL maintenance process for SCRIPT elements would result in greater predictability for 

implementers.

 The current ECL version does not reference the 10.6 ReactionCoded concept, as it has been replaced 

in later NCPDP standards versions with another concept name. It would benefit implementers to 

continue to include all 10.6 concepts in ECL versions during this period in which version 10.6 is being 

adopted. The current practice of removing references to SCRIPT 10.6 concepts causes implementers 

time and confusion. See the ECL Management Recommendations section of this document.

 The XML schema annotations for several Allergy elements are incomplete-- referencing "X" as the 

related EDIFACT element, rather than actual EDIFACT element IDs.

Diagnosis

 The current ECL version does not reference the 10.6 Problem Type Code List Qualifier concept, as it 

has been replaced in later NCPDP standards versions with another concept name. It would benefit 

implementers to continue to include all 10.6 concepts in ECL versions during this period in which 

version 10.6 is being adopted. The current practice of removing references to SCRIPT 10.6 concepts 

causes implementers time and confusion. See the ECL Management Recommendations section of this 

document.

 An error exists in the 10.6 XML schema related to the Diagnosis: ProblemNameCoded composite. The 

schema should allow up to two occurrences of ProblemNameCoded (per the 10.6 Implementation 

Guide), but only allows one.

 The XML schema annotations for several Diagnosis elements are incomplete-- referencing "X" as the 

related EDIFACT element, rather than actual EDIFACT element IDs.

Challenges impacting multiple sections

XML element cardinality issues

In the 10.6 Implementation Guide, the number of occurrences of several identifier elements is

constrained (prescriber, supervisor, pharmacy and facility Identification limited to three occurrences, 

patient Identification to two), but the XML format allows unlimited occurrences. Resolve the 

inconsistency in the number of allowed Identification instances and provide implementation 

guidance by updating the XML schema and annotations and/or providing a correction to the 10.6 

Implementation Guide.
© 1st American Systems and Services LLC Page 13 of 20 Standards Action Plan

www.1asas.com

Address Line 2 representation

AddressLine2 and PlaceLocationQualifier address elements appear in multiple SCRIPT elements, and 

mapping of these elements between the EDIFACT and XML formats is unclear. Implementers would 

benefit from additional mapping information in the SCRIPT 10.6 Implementation Guide and/or XML 

schema clarifying the relationship between these XML concepts and their EDIFACT counterparts. 

Eliminate the PlaceLocationQualifier element in the XML Schema

Individual vs. Organizational Identifiers, and support for DEA Suffix

The Identification concept does not enable differentiation between individual and institutional NPIs 

and DEA Numbers. While the type of identifier can typically be inferred from the identifier’s location 

(e.g., in the prescriber segment versus the pharmacy), exceptions exist—such as a resident physician 

using their hospital’s DEA number, or a prescriber with a single-person practice identified with their 

organizational NPI. In addition, DEA suffixes are not explicitly supported, such as those assigned to 

practitioners that prescribe controlled substances under the authority of their institution. Today, DEA 

suffixes are placed after the DEA number in the same element, and proper interpretation of the suffix 

depends on participants following a formatting convention to separate the suffix from the DEA 

number.

Consider adding NPI and DEA Number types that specify whether the IDs are individual or 

organizational (e.g., individual NPI, organizational DEA Number). Add explicit support for DEA suffix.

State qualifiers for certain identifiers

The Identification concept used to represent State License Numbers and DEA Numbers does not 

include associated state qualifiers. This may present an issue when the prescriber or pharmacy is 

licensed in more than one state or a prescriber is registered with the DEA in more than one state. 

Consider adding state qualifiers for state license number and DEA number elements, to clarify the 

issuing state.

ECL Identification concept mixes identifier types

The Identification ECL concept mixes identifier types for pharmacies, providers, facilities or patients.

Only a subset of these are appropriate for each element, and the remainder are inappropriate. In the 

ECL, in cases where not all values for a concept are applicable in all composite / element instances 

where it appears, provide a separate set of code values for each instance containing only the 

applicable values. Update the XML schema accordingly. 

Other SCRIPT document errata

Implementation of ePrescribing Standards

Location: Page 3, top. Section: NCPDP SCRIPT Standard Implementation Guide Version 10.6
© 1st American Systems and Services LLC Page 14 of 20 Standards Action Plan

www.1asas.com

Text: “Data Dictionary (for field definitions and formats) – 10/2005”

“10/2005” should instead be “10/2008”, to match the table that follows, indicating that the 

correct data dictionary version for SCRIPT 10.6 is the October 2008 version. 

Text: “External Code List (for field values) - most current” 

Several 10.6 concepts are no longer detailed in the current ECL. 

The recommendation to use the most recent ECL version is unique to this document. 

Elsewhere, it is stated that use of the October 2008 ECL up to the most recent is allowed, but 

no recommendation is made. It would be beneficial to implementers for NCPDP to give clear 

and consistent guidance regarding the ECL version to be used, and further to integrate the 

preferred version into the SCRIPT 10.6 XML schema. 

See ECL Management Recommendations below.

External Code List (ECL)

(external_code_list_201104.pdf)

Location: Page 269, top. Section: V. APPENDIX V– CODE SET QUALIFIER VALUES

Text: “Value 2 =FMT Federal Medication Therapy” 

“Therapy” should instead be “Terminology”
© 1st American Systems and Services LLC Page 15 of 20 Standards Action Plan

www.1asas.com

Summary of other SCRIPT 10.6 Opportunities

Broader SCRIPT 10.6 opportunities are summarized below. These are detailed further in the Suitability 

Analysis document.

Terminology-Related Recommendations

Below are specific, terminology-related recommendations based on review of SCRIPT 10.6’s use of standard 

terminologies in the context of other industry standards named for Meaningful Use. (See other project 

deliverables Standards Compatibility in Medication Reconciliation and Suitability Analysis for additional 

background and details.)

Element-level recommendations

 Dose form (FormSourceCode/FormCode, Structured Sig:DoseFormCodeQualifier/DoseFormCode). 

Take steps to further align and/or reconcile the particular set of NCI-FDA values available for SCRIPT 

with those specified in C32 CCD. While both the CCD and SCRIPT standards use National Cancer 

Institute code sets to represent dosage forms, the C32 CCD limits values to the NCI pharmaceutical 

dosage form terminology (C42636), whereas NCI provides a subset of those terms for use in SCRIPT.

 Strength unit of measure (StrengthSourceCode / StrengthCode). Consider aligning and/or reconciling 

the NCI/SCRIPT Strength Unit of Measure with the SPL Potency Terminology, to aid those integrating 

the two standards in a workflow.

 Ordered Quantity Unit of Measure (Quantity: UnitSourceCode / PotencyUnitCode). SCRIPT uses a 

subset of the NCI Unit of Presentation terminology (C87300) whereas the C32 CCD uses the NCI 

Pharmaceutical Dosage Form terminology (C42636). Work with owners of the C32 to align and/or 

reconcile the NCI/SCRIPT Unit of Presentation terminology with the NCI Pharmaceutical Dosage Form 

terminology used in the C32 CCD, to aid those integrating the two standards in a workflow.

 Dose Unit of Administration (Structured Sig: DoseFormCode / DoseFormCodeQualifier). SCRIPT 10.6

uses a subset of the NCI Pharmaceutical Dosage Form terminology (C42636) for this concept, 

whereas the C32 CCD uses the NCI Unit of Presentation terminology (C87300). Also, SCRIPT 10.6 and 

Structured Sig v1.1 IGs conflict regarding FMT being allowed for this element. Work with owners of 

the C32 to align and/or reconcile the NCI/SCRIPT Strength Form terminology with the NCI Unit of 

Presentation terminology used in the C32 CCD, and consider recommending the NCI FDA codes in 

Structured Sig to aid those integrating the two standards in a workflow.

 Maximum Dose unit of Administration (Structured Sig: MaximumDoseRestrictionUnitsCode / 

MaximumDoseRestrictionCodeQualifier). See Dose Unit of Administration, above)

 Route of Administration (Structured Sig: RouteOfAdministrationCode / 

RouteOfAdministrationCodeQualifier). Consider recommending use of NCI FDA Route of 

Administration in SCRIPT as is used in the C32 CCD, to aid those integrating the standards in a 

workflow. (SCRIPT allows the NCI FDA terminology, but the Structured Sig Implementation Guide 

recommends SNOMED CT for this element).

 Indication for medication administration (Structured Sig: IndicationTextCode / 

IndicationTextCodeQualifier). The allowed set of SNOMED CT codes is restricted further in the C32 

CCD than in the NCPDP or CCR standards. (2) SCRIPT 10.6 and Structured Sig 1.1 Implementation 

Guides conflict: 10.6 allows FMT, but Structured Sig recommends only SNOMED CT be used. Bring 
© 1st American Systems and Services LLC Page 16 of 20 Standards Action Plan

www.1asas.com

SCRIPT ECL into consistency with HITSP C32 CCD by conforming to the VA/KP SNOMED problem list 

subset. Make SCRIPT 10.6 and Structured Sig 1.1 guidance consistent, to assist implementers.

 Indication value unit of measure (Structured Sig: IndicationValueUnitofMeasureCode / 

IndicationValueUnitofMeasureCodeQualifier). This concept is coded differently within SCRIPT 

(between the Observation segment and Structured Sig). (2) SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but Structured Sig recommends only SNOMED CT 

be used. Reconcile terminology differences between the Observation and Structured Sig statements 

and make adjustments to make them consistent. Make SCRIPT 10.6 and Structured Sig 1.1 guidance 

consistent according to that outcome, to assist implementers.

 Adverse Reaction Medication Product (DrugProductCoded: CodeListQualifier). Add the separate 

RxNorm SBD, SCD, BPK, GPK qualifiers to the ECL for this element

 Adverse Reaction, Medication Product (Allergy: DrugProductCoded: ItemNumber). SCRIPT allows use 

of additional code sets not used in other standards: representative NDC, manufacturer code and UPC. 

Because RxNorm is required for Meaningful Use, consider eliminating support for representative 

NDC, manufacturer code and UPC in this element.

 Adverse Reaction, Drug Class (Allergy: DrugProductCoded: ItemNumber). NDF-RT is the 

recommended terminology for this element in all reviewed standards. However, the allowed set of 

NDF-RT codes is restricted further in the C32 CCD than in the NCPDP or CCR standards. Consider 

further constraining the NDF-RT concepts allowed in SCRIPT to match those allowed by the C32 CCD, 

to assist implementers with both standards in their workflow.

 Adverse Reaction: Reaction (Allergy: ReactionCoded: ItemNumber). Both the C32 CCD and SCRIPT 

standards refer to the VA/KP SNOMED CT Problem List Subset. However, a variance has arisen due to 

a change to the original HITSP specification, on which the SCRIPT direction was based. Consider 

updating SCRIPT’s ECL to reflect the current VA/KP SNOMED problem list subset, benefitting 

implementers with both SCRIPT and C32 CCD in the same workflow.

 Diagnosis: Problem Name (Diagnosis: ProblemNameCoded: ItemNumber). Both the C32 CCD and 

SCRIPT standards refer to the VA/KP SNOMED CT Problem List Subset. However, a variance has arisen 

due to a change to the original HITSP specification, on which the SCRIPT direction was based. 

Consider updating SCRIPT’s ECL to reflect the current VA/KP SNOMED problem list subset, benefitting 

implementers with both SCRIPT and C32 CCD in the same workflow.

 Diagnosis: Problem Status (Not supported by SCRIPT). SCRIPT does not include a problem status 

element. Consider adding a problem status element to the SCRIPT Diagnosis segment, using 

terminology consistent with the C32 CCD (SNOMED Code from C80 2.2.3.1.8 Table 2-70 Problem 

Status Value Set Definition—active, inactive, resolved)

 Make SCRIPT 10.6 and Structured Sig 1.1 guidance consistent for all elements in which both FMT and 

SNOMED CT codes are allowed by SCRIPT 10.6, but further constrained by SIG 1.1 guidance.

A need for periodic terminology updates

Certain of the element-level challenges in the summary above suggest a need for NCPDP to periodically 

review industry terminology usage—in order to keep SCRIPT consistent with other standards. 
© 1st American Systems and Services LLC Page 17 of 20 Standards Action Plan

www.1asas.com

For example, the Diagnosis segment specifies a subset of SNOMED CT problems that matched the VA / Kaiser 

Permanente SNOMED problem list subset also used in the C32 CCD. However, over time, the definition of 

that problem list subset was amended in the C32 to include another set of SNOMED concepts. NCPDP did not 

likewise update its problem list definition, and as a result SCRIPT and the C32 CCD became out of sync. 

Based on this experience, it is recommended that NCPDP actively monitor the terminology used in standards 

with which it wishes SCRIPT to be consistent, and update its terminology use as needed.

ECL Management Recommendations

Handling of concept changes with respect to actively-implemented standards

Include all version 10.6 ECL concepts in current ECL document versions. This will enable an

implementer to use a single ECL version rather than needing to "mix and match" versions in order to 

cover all 10.6 concepts. This will also reduce confusion for implementers who reasonably expect the 

current ECL version to cover all concepts included in the most recent SCRIPT version in use in the 

industry and named in federal regulation.

Consolidation of terms and values from dissimilar standards

In the ECL, in cases where not all values for a concept are applicable in all composite / element 

instances where it appears, provide a separate set of code values for each instance containing only 

the applicable values. Update the XML schema accordingly.

ECL version management and the XML schema

The structure of the version 10.6 XML is such that external code list values are “baked in” to the 

schema. As such, the schema reflects the External Code List at a particular point in time (if one 

version of the ECL is integrated in its entirety) or a particular mix of External Code List concepts (if the 

schema contains values from more than one ECL version, which is the case today). NCPDP has 

typically not updated the 10.6 schema with each update to the ECL, but instead has made 

adjustments as requested by implementers... for example, adding the RxNorm coded drug values as 

required by federal Meaningful Use rules.

Implementers would benefit from clear and consistent guidance from NCPDP on the preferred ECL 

version to be implemented, and for that version to be reflected in the SCRIPT 10.6 XML schema, with 

updates to the schema made with each ECL version. Further, direction regarding the use of value sets 

from multiple ECL versions in a given 10.6 implementation would be helpful towards consistency 

between vendors.

Other 10.6 Documentation Recommendation

Maintenance of up-to-date implementation materials for those integrating the SCRIPT 10.6 version into their 

systems.
© 1st American Systems and Services LLC Page 18 of 20 Standards Action Plan

www.1asas.com

A significant challenge for implementers is that an error, omission, or weakness of a given SCRIPT version is 

typically addressed by NCPDP in a later version of the standard—but is not corrected in the specification or 

implementation materials of the version containing the issue. Because SCRIPT 10.6 was created in 2008, 

several SCRIPT versions have followed it, and several of its weaknesses have been addressed in this manner, 

with resolutions in later versions.

For the implementer of 10.6, these recent-version corrections are of little use; the implementer remains 

limited to the specification and implementation materials of the 10.6 standard. NCPDP does not have a policy 

of capturing a version’s errors or issues in a way that can be distributed with the version itself, to highlight 

these challenges or to provide clarifications or work-arounds for implementers. Instead, the implementer 

must look to newer versions of the standard and apply its improved guidance—where applicable—back to 

10.6.

RECOMMENDATION:

It would be beneficial to implementers for NCPDP to have a program by which implementation experience is 

captured and made available in conjunction with the standard it applies to, in an addendum to the standard, 

errata, and/or other forms. Such a process would be a means for gaining industry consensus on clarifications 

to unclear or under-specified aspects of SCRIPT 10.6 or other versions, and capturing them to prevent the 

need for individual implementers and trading partners to arrive at them separately (potentially with different 

outcomes).
© 1st American Systems and Services LLC Page 19 of 20 Standards Action Plan

www.1asas.com

Approach for Addressing Opportunities

The challenges and recommendations outlined in this analysis vary in a number of respects: urgency, nature 

of resolution, breadth of impact, types and number of stakeholders, etc. Appropriate steps to review these 

recommendations, determine whether to take action, approaches for addressing the challenges, etc. will 

likewise vary.

September / October 2011

o Share the Suitability Analysis and Standards Action Plan documents with stakeholders from NCPDP

o Discuss the issues identified and identify those to pursue, potentially in a phased manner

o Identify approaches for addressing prioritized issues

o May be technical corrections needed to the SCRIPT Standard or opportunities to develop 

additional tools to support implementation (editorial guide/FAQs/RxNorm toolkit)

o Issues would be addressed through the existing NCPDP processes, i.e. staff function or 

member-led task group

November 2011

o Present project outcomes and NPDP standardization input at the NCPDP Joint Technical Work Group 

Meeting

o Discuss possible priorities and determine approaches and interest in task group or other actions

o Coordinate next steps

February 2012

o Update on items approved at November meeting for NCPDP related action could include:

o Status reports.

o DERF (data element request form) submission

 If approved by the Work Group, this would proceed through the standards approval 

process

o New Project Development Request
© 1st American Systems and Services LLC Page 20 of 20 Standards Action Plan

www.1asas.com

Document References

NCPDP documentation 

The following NCPDP documentation associated with SCRIPT 10.6 is referenced in this assessment.

 SCRIPT 10.6 Implementation Guide, October 2008. (Approval Date for ANSI: November 12, 2008)

 Data Dictionary, October 2008

 NCPDP Standards Matrix

 SCRIPT Implementation Recommendations, Version 10.6 (April, 2011)

 Implementation of ePrescribing Standards “read me” document (201009.read.me.eprescribing.pdf)

 ECL versions October, 2008 (earliest for use with SCRIPT 10.6) and a current ECL during the course of 

this assessment (April, 2011)

 Structured Sig version 1.1 Implementation Guide

SCRIPT XML Standard, version 2010121. (Approval Date for ANSI: January 28, 2011) – Source of Trace 

Number Usage content recommended as guidance for SCRIPT 10.6 implementers.

Project deliverables referenced in this document

The following deliverables from the NIST-sponsored NCPDP analysis project are referenced in this document:

 Standards Compatibility in Medication Reconciliation

 Suitability Analysis