NIST GCR 11-946 

NIST NCPDP (National Council for Prescription Drug

Programs) Analysis – Suitability Assessment

1

st American Systems and Services LLC 
NIST GCR 11-946

NIST NCPDP (National Council for Prescription Drug

Programs) Analysis – Suitability Analysis

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 – Suitability Assessment

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 52 Suitability Assessment

www.1asas.com

1st American Systems and Services LLC

469 Township Road 1535

Proctorville, OH 45669 

www.1asas.com

Author

Frank McKinney

fm@frankmckinney.com
© 1st American Systems and Services LLC Page 3 of 52 Suitability Assessment

www.1asas.com

 1

st American Systems and Services LLC | NIST NCPDP Analysis

NIST NCPDP Analysis – Suitability Assessment

Final, August 31, 2011

Contents

Introduction ................................................................................................................................................5

Quality Assessment by SCRIPT Segment.......................................................................................................7

Header.....................................................................................................................................................7

Error......................................................................................................................................................11

Request .................................................................................................................................................11

Response...............................................................................................................................................12

Pharmacy...............................................................................................................................................13

Prescriber..............................................................................................................................................14

Supervisor .............................................................................................................................................16

Facility ...................................................................................................................................................17

Patient...................................................................................................................................................19

Medication ............................................................................................................................................21

Structured Sig ........................................................................................................................................29

Observation...........................................................................................................................................32

Allergy ...................................................................................................................................................33

Diagnosis...............................................................................................................................................36

Challenges impacting SCRIPT elements in multiple segments.................................................................37

Other SCRIPT document errata ..............................................................................................................39

SCRIPT and Standard Terminologies...........................................................................................................41

Current terminology in SCRIPT, challenges and recommendations.........................................................41

A need for periodic terminology updates...............................................................................................47

Management of “External Code Lists”........................................................................................................48

Consolidation of terms and values from dissimilar standards.................................................................48

Handling of concept changes with respect to actively-implemented standards......................................48

Other Implementability .............................................................................................................................50
© 1st American Systems and Services LLC Page 4 of 52 Suitability Assessment

www.1asas.com

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

their systems.........................................................................................................................................50

ECL Version Management and the XML Schema.....................................................................................50

Document References ...............................................................................................................................52
© 1st American Systems and Services LLC Page 5 of 52 Suitability Assessment

www.1asas.com

Introduction

This document completes the review of the NCPDP SCRIPT standard by reporting on several aspects related 

to its suitability as a standard to support Meaningful Use, including:

 completeness, correctness and internal consistency of the standard

 ease of implementability for vendors and other entities building software to support Meaningful Use, 

including the quality of documentation and other materials associated with the standard

 support for Meaningful Use requirements, including compatibility with other standards named for 

Meaningful Use.

Portions of this assessment capture insights gained during the creation of a SCRIPT message data set and 

other analysis performed earlier in this project—for instance as related to SCRIPT’s compatibility with other 

standards and its use of standard terminology—while others are the result of additional review of the 

standard especially for this document. Below is an overview of the document’s contents:

General Quality Assessment. This section reviews the internal consistency, completeness and 

correctness of the SCRIPT 10.6 XML format from a structural perspective—at a detailed element 

level. The section assesses the standard section-by-section, calling out specific mechanical issues

including isolated errors as well as problems linked to larger implementability challenges described 

more globally in subsequent parts of this document.

Note: The focus of the analysis is the XML format of SCRIPT version 10.6, though the review also 

considers consistency between the XML and EDIFACT formats of the standard.

SCRIPT and Standard Terminologies. This section focuses on SCRIPT’s use of code sets and 

terminology, assessing the guidance given to implementers on use of terminology in the standard 

and the compatibility of SCRIPT’s terminology use as compared to other standards named for 

Meaningful use. The section pays special attention to four SCRIPT sections that employ standard 

terminologies: Medication (including the Structured Sig segment), Observation, Diagnosis and 

Allergy.

Management of “External Code Lists”. This section focuses on issues related to the updating and 

publishing of NCPDP’s External Code List, focusing on impacts to implementers of the SCRIPT 10.6 

standard.

Other Implementability. This section identifies other challenges presented by the SCRIPT 10.6 

standard from the perspective of the implementer, describing how the components of the standard 

fit together from an implementer’s perspective, assessing strengths and weaknesses and calling out 

opportunities for improvement. While findings from the quality and terminology reviews factor into 

this assessment, this section focuses on additional considerations:

 management of changes to the standard and documents related to it, including identification 

of errors and errata in documentation, capturing of additional guidance in response to 

implementer questions and experience

 synchronization of XML schema content with the NCPDP External Code List (ECL).
© 1st American Systems and Services LLC Page 6 of 52 Suitability Assessment

www.1asas.com

Document References. This section identifies the NCPDP documentation associated with SCRIPT 10.6 

and other documents referenced in this assessment.

The findings of this assessment funnel directly into the Standards Action Plan document: this document 

identifies challenges in the SCRIPT 10.6 standard to be resolved as well as strengths to be built upon, and the 

Standards Action plan prioritizes those and recommends actions to address them. Accordingly, this document 

focuses on identifying problems and the desirable “improved state” for each, while the Standards Action Plan 

will suggest how to accomplish those improvements through the NCPDP standards development processes.
© 1st American Systems and Services LLC Page 7 of 52 Suitability Assessment

www.1asas.com

Quality Assessment by SCRIPT Segment

This section lists quality issues related to the “quality” of the SCRIPT 10.6 standard, in terms of consistency, 

completeness, and correctness as described below:

 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.).

This section is organized according to the segments of the standard (high level composites such as “header”, 

“medication”, “prescriber”).

Header

The SCRIPT Header contains information used to...

 identify the message sender and recipient

 uniquely identify the message and optionally relate it to an earlier message

 identify the prescription to which the message pertains, both from the prescriber’s perspective and 

the that of the dispensing pharmacy

 state the time the message was sent

 provide security information

 provide mailboxing information if that applies.

The most acute challenges in this section relate to message and prescription references and use of security 

content. These are described below.

Message and prescription references

Reliable functioning of medication management workflows depends on accurate references to real-world 

prescribing and dispensing events, and to related messaging events such as the transmission of the original 

electronic prescription or an electronic prescription renewal request. Over the course of e-prescribing 

adoption, conventions have arisen in the industry for populating those references in SCRIPT messages, 

though they were not well-documented in SCRIPT implementation guidance until versions that came after 

10.6. Implementers of version 10.6 are provided with vague and inconsistent guidance in this area—causing 

confusion and leaving guidance up to the multiple prescription networks that route these messages. 

As in other cases called out in this assessment, later versions of SCRIPT contain clarifications and guidance 

that are pertinent to version 10.6, are consistent with current 10.6 industry conventions, and would provide 
© 1st American Systems and Services LLC Page 8 of 52 Suitability Assessment

www.1asas.com

great value to 10.6 implementers. However, this post-10.6 content is not referenced in any 10.6 

implementation materials, leaving implementers to either work from the sometimes incomplete guidance in 

10.6 materials or utilize—with uncertainty as to the appropriateness—guidance from later versions of the 

standard.

Starting with version 10.9, a section entitled Trace Number Usage was included in SCRIPT implementation 

guides, clarifying use of prescription and message references. Below are excerpts from that section as it 

appears in a recent version of SCRIPT.

[... additional examples provided. Source: 2010121 NCPDP XML Standard Implementation Guide]

The specific elements impacted by this lack of guidance or conflicting guidance in the SCRIPT 10.6 version are 

detailed below.

MessageID

EDIFACT: Transaction Control Reference (UIB-030-01)

Implementation Guidance - Errata

ISSUE: In the UIB element descriptions, the 10.6 Implementation Guide makes specific 

reference to the STATUS and ERROR messages in the statement: “When a STATUS or ERROR 

message is generated as a response, the response transaction's Transaction control reference 

will be echoed back to the sender...”, but this rule applies equally to other response messages 

(e.g., fill status, renewal request).
© 1st American Systems and Services LLC Page 9 of 52 Suitability Assessment

www.1asas.com

RECOMMENDATION: Adjust the statement in the 10.6 IG so that it refers to other response 

messages in addition to the Status and Error (e.g., fill status, renewal request, change 

request). 

RelatesToMessageID

EDIFACT: Initiator Reference Identifier OR Dialogue Reference - Initiator Control Reference (UIB-030-02 OR UIH030-01)

PrescriberOrderNumber

EDIFACT: Dialogue Reference - Initiator control reference OR Message Reference Number (UIH-030-01 or UIH020)

RxReferenceNumber

EDIFACT: Initiator reference identifier OR Message Reference Number (UIB-030-02 or UIH-020)

Implementation Guidance, Resolve XML/EDIFACT Mapping Conflict

ISSUE: (1) Implementation guidance on use of trace numbers is unclear in the 10.6 guide and 

the SCRIPT implementation recommendation document doesn't cover this topic. 

(3) The XML indicates that two different EDIFACT elements (UIH-030-01 and UIH-020) can

both map to the same PrescriberOrderNumber XML concept.

(4) The XML indicates that two different EDIFACT elements (UIB-030-02 and UIH-020) can 

both map to the same RxReferenceNumber XML concept.

(5) The XML indicates that two different EDIFACT elements (UIB-030-02 and UIH-030-01) can 

both map to the same RelatesToMessageID XML concept.

(6) The 10.6 Implementation Guide indicates that Trading Partner-defined usage of these 

elements is allowed, which can lead to inconsistent implementation.

RECOMMENDATION: (1) Include additional guidance on use of prescriber order IDs, 

pharmacy prescription IDs and message trace numbers. An appropriate source could be 

section 9.3 TRACE NUMBER USAGE from the Script v2010121 XML Implementation Guide.

(2) The XML schema relates EDIFACT UIH-020 Message Reference Number, UIH-030-01 

Dialogue Reference - Initiator control reference and UIB-030-02 Initiator Reference Identifier

elements to multiple, overlapping XML elements. Clarify the cases where the XML elements

should be mapped to one versus the other.

Security 

The 10.6 implementation materials provide little guidance for use of the Security section of the standard. 

Generally, additional narrative guidance would be of benefit to implementers. In addition, certain elements 
© 1st American Systems and Services LLC Page 10 of 52 Suitability Assessment

www.1asas.com

in the XML Security composite do not appear to have counterparts in the EDIFACT version of the standard, 

which could cause challenges for those migrating to the XML format or for those needing to support both 

formats. 

Lastly, the Security composite contains mandatory sub-composites made up solely of optional elements, 

which could cause questions or challenges for implementers.

Below are particular elements of interest.

Security: UsernameToken

EDIFACT: No counterpart

Implementation Guidance, Resolve XML/EDIFACT Mapping

ISSUE: This concept does not appear to be present in the EDIFACT format of SCRIPT 10.6. It is unclear 

whether there is a corollary population of the EDIFACT format. Currently, no guidance is given in the 

10.6 IG nor in the most recent SCRIPT or SCRIPT XML IG on use of this composite.

RECOMMENDATION: Clarify in the 10.6 IG that this composite is available only in the XML format and 

provide guidance on use of the composite. Reference the SOAP profile if appropriate.

 

Security: Sender

EDIFACT: Interchange Sender

Security: Receiver 

EDIFACT: Interchange Recipient

XML Schema Challenge, Implementation Guidance

ISSUE: The SecurityIdentificationType: Sender and SecurityIdentificationType: Receiver composites 

are mandatory in the 10.6 XML format, but all elements within the composites are optional.

RECOMMENDATION: Modify the XML specification to make these composites optional, or provide 

clarifying conditionality rules in the Implementation Guide indicating which elements are mandatory 

in which circumstances.

Other 

The mailboxing elements are generally thoroughly documented in the 10.6 materials. However, the 

documentation omission below was noted during test message creation. 

Mailbox: MailboxID

EDIFACT: Interchange Sender: Sender identification

XML Schema Challenge
© 1st American Systems and Services LLC Page 11 of 52 Suitability Assessment

www.1asas.com

ISSUE: The XML schema does not include annotations clarifying the mapping of XML concepts to their 

related EDIFACT elements.

RECOMMENDATION: Add EDIFACT element mapping annotations to the 10.6 XML schema.

 

Error 

The Error composite is included in multiple SCRIPT message types, and enables a sender to convey aspects of 

an error situation:

 Code enumerating the high-level category of the error condition

 DescriptionCode providing a more specific error categorization

 Description providing a textual characterization of the error.

One misstatement in the 10.6 Implementation Guide related to this section is described below.

Error: DescriptionCode

EDIFACT: Code List Qualifier (STS-020)

Implementation Guidance

ISSUE: SCRIPT 10.6 Implementation Guide error: Page 119: STS Status segment usage table 

shows Not Used for this element in Verify, but includes confusing content in the Remarks, 

apparently copied from the Status Type, Coded remarks: 

"Is not required in a VERIFY transaction. If used, Status Type (Ø1Ø/9Ø15) must be 

ØØØ and Reject Codes (Ø2Ø/1131) may not be used. Free Text (Ø3Ø/444Ø) may be 

used." 

RECOMMENDATION: Remove or correct the erroneous statement above in the 10.6 

implementation guide, Page 119: STS Status segment usage table.

 

Request 

The Request composite, included in multiple SCRIPT message types, is used to convey information clarifying 

the nature or specifics of the particular request.

As is the case for many SCRIPT elements, the allowed values for one Request element, ChangeRequestType,

are maintained in the NCPDP External Code List document. However, this element is impacted by ECL editing 

conventions that make finding the current, allowed values problematic. Background on this challenge is 

provided in contained in the Management of “External Code Lists” section later in this document. Details on 

the impacted Request elements are below.

Request: ChangeRequestType

EDIFACT: Message Function, Coded (REQ-010)

Implementation Guidance, SCRIPT Enhancement Opportunity
© 1st American Systems and Services LLC Page 12 of 52 Suitability Assessment

www.1asas.com

ISSUE: The 10.6 concept associated with this element (4343 Message Function, Coded) is not 

present in the current ECL version. Instead, the concept that replaced it in later SCRIPT 

versions—MessageRequestCode—is present, with direction to "See 4343 Message Function, 

coded for SCRIPT Versions 1Ø.11 and lower". The lack of this concept in recent ECL versions 

conflicts with guidance in the Standards Matrix document which indicates the "most recent" 

ECL may be used with 10.6. Implementers desiring to use the most recent ECL but 

implementing RxChange, Census, or the LTPAC prescription change process must also use an 

older ECL version containing the missing 4343 Message Function, Coded concept.

RECOMMENDATION: 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. See 

the section elsewhere in this document entitled Handling of concept changes with respect to 

actively-implemented standards.

Response 

As is the case for a number of SCRIPT elements, shared ECL code sets support Request segment elements

which are used in multiple SCRIPT message types. The result is that certain values available for use in these

elements that are inappropriate in certain messages. In addition, the ApprovedWithChanges sub-composite 

is allowed in a message type where it is inappropriate. Details are below.

 Response: Approved: ApprovalReasonCode

EDIFACT: Code List Qualifier (RES-020)

Response: Denied: DenialReasonCode

EDIFACT: Code List Qualifier (RES-020)

Response: DeniedNewPrescriptionToFollow: DenialReasonCode

EDIFACT: Code List Qualifier (RES-020)

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: Not all codes allowed for these elements are appropriate in all message types or composites.

(See the section elsewhere in this document entitled Consolidation of terms and values from 

dissimilar standards for additional background)

RECOMMENDATION: 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.
© 1st American Systems and Services LLC Page 13 of 52 Suitability Assessment

www.1asas.com

 

Response: ApprovedWithChanges

EDIFACT: Response Type, Coded (RES-010)

Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: "ApprovedWithChanges" is allowed as a response to a Cancel request, but that does not 

reflect a meaningful real-world scenario.

RECOMMENDATION: 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 

The Pharmacy composite is used to convey information about a sending or receiving pharmacy, including 

address and key industry identifiers. 

Identifiers

Below are challenges and opportunities related to pharmacy identifier elements in the SCRIPT standard.

Pharmacy: Identification

EDIFACT: Reference Number (PVD-020)

There are several cases where there is a mismatch between the number of allowed Identification 

instances allowed in the EDIFACT format versus the number allowed in the XML schema, including 

this element. See the section, XML element cardinality issues, elsewhere in this document for details.

 

Pharmacy: Identification

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 (qualifier))

The Identification concept is used to convey identifiers for pharmacies, prescribers, facilities and 

patients. Because the associated ECL concept contains identifier types to support all these entities, 

only a subset are appropriate for each element, and the remainder are inappropriate. See the 

section, ECL concept mixes identifier types, elsewhere in this document for details.

 

Pharmacy: Identification 

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 (qualifier))
© 1st American Systems and Services LLC Page 14 of 52 Suitability Assessment

www.1asas.com

The Identification concept does not enable differentiation between Individual and Organizational 

NPIs and DEA Numbers, and DEA suffixes are not explicitly supported. See the section, No 

differentiation between Individual and Organizational NPI and DEA, elsewhere in this document for 

details.

 

Pharmacy: Identification: StateLicenseNumber

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "0B" (qualifier))

The Identification concept does not include a state qualifier element for use with State License 

Numbers or DEA Numbers—which may be needed when an entity is licensed or registered in more 

than one state. See the section, Lacking state qualifiers for certain identifiers, elsewhere in this 

document for details.

Address

Pharmacy: Address: AddressLine2

EDIFACT: Place / Location (PVD-080-06)

Pharmacy: Address: PlaceLocationQualifier

EDIFACT: Place / Location Qualifier (PVD-080-05)

The same challenges and opportunities affecting the AddressLine2 and PlaceLocationQualifier 

address elements throughout the SCRIPT standard affect these elements. See the section, Challenges 

impacting SCRIPT elements in multiple segments, elsewhere in this document for details. 

Prescriber

The Prescriber composite is used to convey information about a sending or receiving prescriber, including 

address and key industry identifiers. 

XML representation in the Medication History Response

Prescriber

PVD Segment

Implementation Guidance, XML Schema Challenge

ISSUE: 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.

RECOMMENDATION: 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.
© 1st American Systems and Services LLC Page 15 of 52 Suitability Assessment

www.1asas.com

Identifiers

Below are challenges and opportunities related to prescriber identifier elements in the SCRIPT standard.

Prescriber: Identification

EDIFACT: Reference Number (PVD-020)

There are several cases where there is a mismatch between the number of allowed Identification 

instances allowed in the EDIFACT format versus the number allowed in the XML schema, including 

this element. See the section, XML element cardinality issues, elsewhere in this document for details.

 

Prescriber: Identification

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 (qualifier))

The Identification concept is used to convey identifiers for pharmacies, prescribers, facilities and 

patients. Because the associated ECL concept contains identifier types to support all these entities, 

only a subset are appropriate for each element, and the remainder are inappropriate. See the 

section, ECL concept mixes identifier types, elsewhere in this document for details.

 

Prescriber: Identification

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 (qualifier))

The Identification concept does not enable differentiation between Individual and Organizational 

NPIs and DEA Numbers, and DEA suffixes are not explicitly supported. See the section, No 

differentiation between Individual and Organizational NPI and DEA, elsewhere in this document for 

details.

 

Prescriber: Identification: DEANumber

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "DH" (qualifier))

Prescriber: Identification: StateLicenseNumber

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "0B" (qualifier))

The Identification concept does not include a state qualifier element for use with State License 

Numbers or DEA Numbers—which may be needed when an entity is licensed or registered in more 

than one state. See the section, Lacking state qualifiers for certain identifiers, elsewhere in this 

document for details.

Address

Prescriber: Address: AddressLine2
© 1st American Systems and Services LLC Page 16 of 52 Suitability Assessment

www.1asas.com

EDIFACT: Place / Location (PVD-080-06)

Prescriber: Address: PlaceLocationQualifier

EDIFACT: Place / Location Qualifier (PVD-080-05)

The same challenges and opportunities affecting the AddressLine2 and PlaceLocationQualifier 

address elements throughout the SCRIPT standard affect these elements. See the section, Challenges 

impacting SCRIPT elements in multiple segments, elsewhere in this document for details.

Supervisor 

The optional Supervisor segment contains the same elements as the Prescriber composite, but represents a 

supervising clinician.

Supervisor: Identification

EDIFACT: Reference Number (PVD-020)

There are several cases where there is a mismatch between the number of allowed Identification 

instances allowed in the EDIFACT format versus the number allowed in the XML schema, including 

this element. See the section, XML element cardinality issues, elsewhere in this document for details.

 

Supervisor: Identification

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 (qualifier))

The Identification concept is used to convey identifiers for pharmacies, prescribers, facilities and 

patients. Because the associated ECL concept contains identifier types to support all these entities, 

only a subset are appropriate for each element, and the remainder are inappropriate. See the 

section, ECL concept mixes identifier types, elsewhere in this document for details.

 

Supervisor: Identification

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 (qualifier))

The Identification concept does not enable differentiation between Individual and Organizational 

NPIs and DEA Numbers, and DEA suffixes are not explicitly supported. See the section, No 

differentiation between Individual and Organizational NPI and DEA, elsewhere in this document for 

details.

 

Supervisor: Identification: DEANumber

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "DH" (qualifier))

Supervisor: Identification: StateLicenseNumber

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "0B" (qualifier))
© 1st American Systems and Services LLC Page 17 of 52 Suitability Assessment

www.1asas.com

The Identification concept does not include a state qualifier element for use with State License 

Numbers or DEA Numbers—which may be needed when an entity is licensed or registered in more 

than one state. See the section, Lacking state qualifiers for certain identifiers, elsewhere in this 

document for details.

Address

Supervisor: Address: AddressLine2

EDIFACT: Place / Location (PVD-080-06)

Supervisor: Address: PlaceLocationQualifier

EDIFACT: Place / Location Qualifier (PVD-080-05)

The same challenges and opportunities affecting the AddressLine2 and PlaceLocationQualifier 

address elements throughout the SCRIPT standard affect these elements. See the section, Challenges 

impacting SCRIPT elements in multiple segments, elsewhere in this document for details. 

Facility 

The Facility composite is used to convey information about a sending or receiving long-term or post-acute 

care facility, including address and key industry identifiers. 

Identifiers

Below are challenges and opportunities related to pharmacy identifier elements in the SCRIPT standard.

Facility: Identification

EDIFACT: Reference Number (PVD-020)

There are several cases where there is a mismatch between the number of allowed Identification 

instances allowed in the EDIFACT format versus the number allowed in the XML schema, including 

this element. See the section, XML element cardinality issues, elsewhere in this document for details.

 

Facility: Identification: NPI

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "HPI" (qualifier))

The Identification concept is used to convey identifiers for pharmacies, prescribers, facilities and 

patients. Because the associated ECL concept contains identifier types to support all these entities, 

only a subset are appropriate for each element, and the remainder are inappropriate. See the 

section, ECL concept mixes identifier types, elsewhere in this document for details.

 

Facility: Identification: NPI

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "HPI" (qualifier))
© 1st American Systems and Services LLC Page 18 of 52 Suitability Assessment

www.1asas.com

The Identification concept does not enable differentiation between Individual and Organizational 

NPIs and DEA Numbers, and DEA suffixes are not explicitly supported. See the section, No 

differentiation between Individual and Organizational NPI and DEA, elsewhere in this document for 

details.

 

Facility: Identification: StateLicenseNumber

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "0B" (qualifier))

The Identification concept does not include a state qualifier element for use with State License 

Numbers or DEA Numbers—which may be needed when an entity is licensed or registered in more 

than one state. See the section, Lacking state qualifiers for certain identifiers, elsewhere in this 

document for details.

 

Facility name

Facility: FacilityName

EDIFACT: Party Name (PVD-070)

SCRIPT Enhancement Opportunity

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

(pharmacy, prescriber).

RECOMMENDATION: Consider making the facility name element mandatory in future SCRIPT 

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

Address

Facility: Address

EDIFACT: Address (PVD-080)

SCRIPT Enhancement Opportunity

ISSUE: The facility address is not a required composite for any message type, which is inconsistent 

with other similar concepts (pharmacy, prescriber).

RECOMMENDATION: 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.
© 1st American Systems and Services LLC Page 19 of 52 Suitability Assessment

www.1asas.com

 

Facility: Address: AddressLine2

EDIFACT: Place / Location (PVD-080-06)

Facility: Address: PlaceLocationQualifier

EDIFACT: Place / Location Qualifier (PVD-080-05)

The same challenges and opportunities affecting the AddressLine2 and PlaceLocationQualifier 

address elements throughout the SCRIPT standard affect these elements. See the section, Challenges 

impacting SCRIPT elements in multiple segments, elsewhere in this document for details.

Patient 

The Patient composite is used to convey information about the patient who is the subject of the SCRIPT 

message. Information typically populated in the Patient segment includes patient name, date of birth, 

address and telephone numbers. Below are challenges related to patient information in the 10.6 standard.

Identification

Patient: Identification

EDIFACT: Reference Number (PTT-050)

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: 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.

RECOMMENDATION: 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.

 

Patient: Identification

EDIFACT: Reference Number (PTT-050)

There are several cases where there is a mismatch between the number of allowed Identification 

instances allowed in the EDIFACT format versus the number allowed in the XML schema, including 

this element. See the section, XML element cardinality issues, elsewhere in this document for details.

 

Patient: Identification

EDIFACT: Reference Number (PTT-050-01 (value), PTT-050-02 (qualifier))
© 1st American Systems and Services LLC Page 20 of 52 Suitability Assessment

www.1asas.com

The Identification concept is used to convey identifiers for pharmacies, prescribers, facilities and 

patients. Because the associated ECL concept contains identifier types to support all these entities, 

only a subset are appropriate for each element, and the remainder are inappropriate. See the 

section, ECL concept mixes identifier types, elsewhere in this document for details.

Date of birth

Patient: DateOfBirth OR DateTime

EDIFACT: Century Date (PTT-020)

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: 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.

RECOMMENDATION: 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.

 

Patient: DateOfBirth OR DateTime

EDIFACT: Century Date (PTT-020)

Implementation Guidance, XML Schema Challenge

ISSUE: 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. 

RECOMMENDATION: 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.

Address

Patient: Address: AddressLine2

EDIFACT: Place / Location (PVD-080-06)

Patient: Address: PlaceLocationQualifier

EDIFACT: Place / Location Qualifier (PTT-060-05)

The same challenges and opportunities affecting the AddressLine2 and PlaceLocationQualifier

address elements throughout the SCRIPT standard affect these elements. See the section, Challenges 

impacting SCRIPT elements in multiple segments, elsewhere in this document for details.
© 1st American Systems and Services LLC Page 21 of 52 Suitability Assessment

www.1asas.com

Other patient information

Patient: PatientRelationship

EDIFACT: Individual Relationship, Coded (PTT-010)

Implementation Guidance

ISSUE: It is unclear what the anticipated and appropriate use of this element is in most prescription 

messages (presumably this information could be pertinent in a medication history request directed to 

the patient's payer).

RECOMMENDATION: 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 

The Medication composite has three variations... for conveying a prescribed, dispensed, or requested 

medication.

Medication composite in the Refill Response

Medication : MedicationPrescribed | MedicationDispensed

In the Refill Response Message

EDIFACT: DRU segment

XML Schema Challenge, Implementation Guidance

ISSUE: In the Refill Response, the Implementation Guide indicates that the Medication / DRU is 

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

prescribed medication.

RECOMMENDATION: 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.

Coded Medication

Medication : DrugCoded: ProductCodeQualifier

EDIFACT: Code List Responsibility Agency (DRU-010-04)

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: Not all code sets 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 (NDFRT) or ingredient (UNII).
© 1st American Systems and Services LLC Page 22 of 52 Suitability Assessment

www.1asas.com

RECOMMENDATION: 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.

 

Medication : DrugCoded: DrugDBCodeQualifier

EDIFACT: Reference Qualifier (DRU-010-09)

Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: The 10.6 schema at the outset of this analysis did not include the RxNorm qualifiers required 

by Meaningful Use for new prescriptions (BPK, GPK, SCD, SBD). These terminologies have been 

present in the ECL since June 2010, but the 10.6 schema included only the ECL content present in the 

October 2008 ECL document.

After notification of NCPDP, an the schema was updated with the additional RxNorm qualifiers and 

republished. However, the current published 10.6 schema still reflects the October 2010 ECL for most 

concepts, with content from newer ECL versions only for certain concepts--where requested by 

members.

RECOMMENDATION: See the sections, Management of “External Code Lists” and ECL Version 

Management and the XML Schema, below

Directions

Medication : Directions

EDIFACT: Directions (DRU-030-02 and 03)

SCRIPT Enhancement Opportunity

ISSUE: The maximum length of this 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.

RECOMMENDATION: Expand the element to accommodate all direction scenarios.

Quantity / Refills

Medication : Refills: Qualifier

In the Refill Request Message
© 1st American Systems and Services LLC Page 23 of 52 Suitability Assessment

www.1asas.com

EDIFACT: Quantity Qualifier (DRU-060-01)

XML Schema Challenge, Implementation Guidance

ISSUE: 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.

RECOMMENDATION: 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.

Medication-related date and time elements

In the following elements, a time component is supported in the XML format, whereas it would not be 

included in the EDIFACT format. Additional guidance would be valuable to assist implementers in the 

appropriate population of the date/time elements.

Medication : WrittenDate: OR DateTime

EDIFACT: Date/Time Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier

(DRU-040-01 (date type=85), DRU-040-02 (value), DRU-040-03 (format))

Medication : LastFillDate: OR DateTime

EDIFACT: Date/Time Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier

(DRU-040-01 (date type=LD), DRU-040-02 (value), DRU-040-03 (format))

Medication : ExpirationDate: OR DateTime

EDIFACT: Date/Time Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier

(DRU-040-01 (date type=36), DRU-040-02 (value), DRU-040-03 (format))

Medication : EffectiveDate: OR DateTime

EDIFACT: Date/Time Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier

(DRU-040-01 (date type=07), DRU-040-02 (value), DRU-040-03 (format))

Medication : PeriodEnd: OR DateTime

EDIFACT: Date/Ti-me Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier

(DRU-040-01 (date type=PE), DRU-040-02 (value), DRU-040-03 (format))

Medication : DeliveredOnDate: OR DateTime

EDIFACT: Date/Time Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier

(DRU-040-01 (date type=35), DRU-040-02 (value), DRU-040-03 (format))

Medication : DateValidated: OR DateTime

EDIFACT: Date/Time Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier

(DRU-040-01 (date type=BE), DRU-040-02 (value), DRU-040-03 (format))

Medication : SoldDate: OR DateTime

EDIFACT: Date/Time Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier

(DRU-040-01 (date type=06), DRU-040-02 (value), DRU-040-03 (format))

Implementation Guidance
© 1st American Systems and Services LLC Page 24 of 52 Suitability Assessment

www.1asas.com

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

when communicating this date.

RECOMMENDATION: Provide guidance on the use of DateTime versus Date types for each of SCRIPT's 

date elements.

 

Medication : DeliveredOnDate: Date

EDIFACT: Date/Time Period Qualifier, Date/Time Period, Date/Time Period Format Qualifier 

(DRU-040-01 (date type=35), DRU-040-02 (value), DRU-040-03 (format))

XML Schema Challenge

ISSUE: 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.

RECOMMENDATION: Remove the DeliveredOnDate element from the NewRx message XML schema.

Diagnosis in the Medication composite

Medication : Diagnosis: Qualifier

EDIFACT: Code List Qualifier (DRU-070-03)

Implementation Guidance, ECL Challenge

ISSUE: 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.

RECOMMENDATION: (1) Provide guidance in the Implementation Guide recommending that the 

Diagnosis: Qualifier to be populated when the corresponding Value element is populated. 

(2) Consider adjusting the standard to require the Qualifier in such cases.

 

Medication : Diagnosis: Qualifier

EDIFACT: Code List Qualifier (DRU-070-05)

XML Schema Challenge, Implementation Guidance, ECL Challenge
© 1st American Systems and Services LLC Page 25 of 52 Suitability Assessment

www.1asas.com

ISSUE: (1) See note on Diagnosis: Primary: Qualifier

(2) Incorrect annotation in the XML schema: The current annotation indicates that this XML element 

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

RECOMMENDATION: (1) See note on Diagnosis: Primary: Qualifier.

(2) Correct the annotation in the XML schema so that it relates this XML element to EDIFACT DRU070-05.

 

Medication : Diagnosis: Value

EDIFACT: Clinical Information - Secondary (DRU-070-04)

XML Schema Challenge, Implementation Guidance

ISSUE: (1) This 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.

(2) Incorrect annotation in the XML schema: The current annotation indicates that this XML element 

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

RECOMMENDATION: (1) Adjust the XML schema to make the Diagnosis: Secondary: Value element 

mandatory.

(2) Correct the annotation in the XML schema so that it relates this XML element to EDIFACT DRU070-04

Prior Authorization

Medication : PriorAuthorization : Qualifier

EDIFACT: Reference Qualifier (DRU-080-02)

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: The External Code List values for this element 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)

RECOMMENDATION: 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. (In this case, only G1/PA Number and 94/Order 

Number are valid). Update the XML schema accordingly
© 1st American Systems and Services LLC Page 26 of 52 Suitability Assessment

www.1asas.com

Potentially include direction in the Implementation Guide in addition to or in place of ECL changes

 

Medication : PriorAuthorization : Value

EDIFACT: Reference Number (DRU-080-01)

Implementation Guidance, ECL Challenge

ISSUE: This 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. 

RECOMMENDATION: Consider changing the name for this element in the XML to more 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 (Medication History only)

Pharmacy (Med History): Identification

EDIFACT: Reference Number (PVD-020)

There are several cases where there is a mismatch between the number of allowed Identification 

instances allowed in the EDIFACT format versus the number allowed in the XML schema, including 

this element. See the section, XML element cardinality issues, elsewhere in this document for details.

 

Pharmacy (Med History): Identification

EDIFACT: Reference Number (PVD-020)

The Identification concept is used to convey identifiers for pharmacies, prescribers, facilities and 

patients. Because the associated ECL concept contains identifier types to support all these entities, 

only a subset are appropriate for each element, and the remainder are inappropriate. See the 

section, ECL concept mixes identifier types, elsewhere in this document for details.

 

Pharmacy (Med History): Identification: StateLicenseNumber

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "0B" (qualifier))

The Identification concept does not include a state qualifier element for use with State License 

Numbers or DEA Numbers—which may be needed when an entity is licensed or registered in more 
© 1st American Systems and Services LLC Page 27 of 52 Suitability Assessment

www.1asas.com

than one state. See the section, Lacking state qualifiers for certain identifiers, elsewhere in this 

document for details. 

 

Pharmacy (Med History): Address: AddressLine2

EDIFACT: Place / Location (PVD-080-06)

Pharmacy (Med History): Address: PlaceLocationQualifier

EDIFACT: Place / Location Qualifier (PVD-080-05)

The same challenges and opportunities affecting the AddressLine2 and PlaceLocationQualifier 

address elements throughout the SCRIPT standard affect the elements below. See the section, 

Challenges impacting SCRIPT elements in multiple segments, elsewhere in this document for details.

Ordering Prescriber (Medication History only)

Prescriber (Med History): Identification

EDIFACT: Reference Number (PVD-020)

There are several cases where there is a mismatch between the number of allowed Identification 

instances allowed in the EDIFACT format versus the number allowed in the XML schema, including 

this element. See the section, XML element cardinality issues, elsewhere in this document for details.

 

Prescriber (Med History): Identification

EDIFACT: Reference Number (PVD-020)

The Identification concept is used to convey identifiers for pharmacies, prescribers, facilities and 

patients. Because the associated ECL concept contains identifier types to support all these entities, 

only a subset are appropriate for each element, and the remainder are inappropriate. See the 

section, ECL concept mixes identifier types, elsewhere in this document for details.

 

Prescriber (Med History): Identification: StateLicenseNumber

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 value: "0B" (qualifier))

The Identification concept does not include a state qualifier element for use with State License 

Numbers or DEA Numbers—which may be needed when an entity is licensed or registered in more 

than one state. See the section, Lacking state qualifiers for certain identifiers, elsewhere in this 

document for details. 

 

Prescriber (Med History): Address: AddressLine2

EDIFACT: Place / Location (PVD-080-06)
© 1st American Systems and Services LLC Page 28 of 52 Suitability Assessment

www.1asas.com

Prescriber (Med History): Address: PlaceLocationQualifier

EDIFACT: Place / Location Qualifier (PVD-080-05)

The same challenges and opportunities affecting the AddressLine2 and PlaceLocationQualifier 

address elements throughout the SCRIPT standard affect the elements below. See the section, 

Challenges impacting SCRIPT elements in multiple segments, elsewhere in this document for details.

Drug Use Evaluation

DrugUseEvaluation: CoAgentQualifier

EDIFACT: DUE Co-Agent ID Qualifier (DRU-100-05)

SCRIPT Enhancement Opportunity, ECL Challenge

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

drug class.

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

the External Code List

Drug coverage status

DrugCoverageStatusCode

EDIFACT: Drug Coverage Status Code (DRU-110)

Implementation Guidance, ECL Challenge

ISSUE: Usage rules for non-DEA controlled substance products is not clear. 

RECOMMENDATION: 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.

Delivery time requested

NeededNoLaterThan: TimeZone: Time Zone

EDIFACT: Time Zone (DRU-150)

ECL Challenge

ISSUE: This element is only to be used with the NeededNoLaterThan element. 
© 1st American Systems and Services LLC Page 29 of 52 Suitability Assessment

www.1asas.com

RECOMMENDATION: Consider combining the NeededNoLaterThan date with the TimeZone and 

NeededNoLaterThanReason into a single composite of related elements

 

NeededNoLatherThanReason

EDIFACT: Needed No Later Than Reason (DRU-160)

ECL Challenge

ISSUE: This element is only to be used with the NeededNoLaterThan element. 

RECOMMENDATION: Consider combining the NeededNoLaterThan date with the TimeZone and 

NeededNoLaterThanReason into a single composite of related elements.

 

Structured Sig 

The Structured Sig segment breaks out the components of a prescription’s administration directions, 

optionally codifying these aspects using standard terminologies. 

In SCRIPT version 10.6, much of the content in the segment is optional, and direction regarding its use in the 

10.6 Implementation Guide is light; a separate Structured Sig Implementation Guide is published by NCPDP, 

but is not explicitly referenced in the 10.6 SCRIPT IG or other guidance materials. Further, guidance as to the 

use of terminologies differs to some extent between the SCRIPT 10.6 and Structured Sig Implementation 

Guides—in particular, the SCRIPT 10.6 guide allows use of Federal Medication Terminologies (FMT) in nearly 

all coded elements, but the Structured Sig guide limits use of FMT to one composite.

In addition, the reference to FMT is itself very imprecise, in that there are several terminologies within FMT, 

including several subsets.

This section identifies inconsistencies in guidance between the SCRIPT 10.6 and Structured Sig 

Implementation Guides that will likely cause challenges for implementers, as well as other documentation 

points to be addressed.

Use of standard terminologies in SCRIPT is discussed further in SCRIPT and Standard Terminologies later in 

this document.

StructuredSig

EDIFACT: Structured Sig segment elements

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: 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.
© 1st American Systems and Services LLC Page 30 of 52 Suitability Assessment

www.1asas.com

Elements for which the Structured Sig v1.1 IG directs use of SNOMED only, in conflict with the 10.6 

XML schema, IG and ECL which allow both FMT and SNOMED:

StructuredSig: RouteOfAdministration: RouteofAdministrationCodeQualifier

EDIFACT: Route of Administration Code Qualifier (SIG-070-02)

StructuredSig: SiteofAdministration: SiteofAdministrationCodeQualifier

EDIFACT: Site of Administration Code Qualifier (SIG-080-02)

StructuredSig: Timing: AdministrationTimingCodeQualifier

EDIFACT: Administration Timing Code Qualifier (SIG-090-02)

StructuredSig: Timing: RateUnitofMeasureCodeQualifier

EDIFACT: Rate Unit of Measure Code Qualifier (SIG-090-07)

StructuredSig: Timing: TimePeriodBasisCodeQualifier

EDIFACT: Time Period Basis Code Qualifier (SIG-090-10)

StructuredSig: Timing: IntervalUnitsCodeQualifier

EDIFACT: Interval Units Code Qualifier (SIG-090-19)

StructuredSig: Duration: DurationTextCodeQualifier

EDIFACT: Duration Text Code Qualifier (SIG-100-03)

StructuredSig: MaximumDoseRestriction: MaximumDoseRestrictionCodeQualifier

EDIFACT: Maximum Dose Restriction Code Qualifier (SIG-110-03)

StructuredSig: MaximumDoseRestriction: 

MaximumDoseRestrictionVariableUnitsCodeQualifier

EDIFACT: Maximum Dose Restriction Variable Units Code Qualifier (SIG-110-07)

StructuredSig: Indication: IndicationPrecursorCodeQualifier

EDIFACT: Indication Precursor Code Qualifier (SIG-120-02)

StructuredSig: Indication: IndicationTextCodeQualifier

EDIFACT: Indication Text Code Qualifier (SIG-120-05)

StructuredSig: Indication: IndicationValueUnitofMeasureCodeQualifier

EDIFACT: Indication Value Unit of Measure Code Qualifier (SIG-120-10)

StructuredSig: Dose: DoseDeliveryMethodCodeQualifier

EDIFACT: Dose Delivery Method Code Qualifier (SIG-040-03)
© 1st American Systems and Services LLC Page 31 of 52 Suitability Assessment

www.1asas.com

StructuredSig: Dose: DoseDeliveryMethodModifierCodeQualifier

EDIFACT: Dose Delivery Method Modifier Code Qualifier (SIG-040-06)

RECOMMENDATION: (1) 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.

(2) Clarify for implementers how the Structured Sig v1.1 IG should or shouldn't be used in the 

development of SCRIPT 10.6 support. (Current SCRIPT 10.6 IG, Implementation Recommendations 

and Read Me documents do not reference the Structured Sig 1.1 IG).

 

StructuredSig: CodeSystem: FMTVersion

EDIFACT: FMT Version (SIG-020-02)

Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: 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.

RECOMMENDATION: (1) Provide guidance in the 10.6 Implementation Guide or addendum regarding 

population of this element when multiple FMT terminologies are used by the implementer.

(2) 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.

 

StructuredSig: FreeText: SigFreeText

EDIFACT: Directions (SIG-030-02)

SCRIPT Enhancement Opportunity

ISSUE: The maximum length of this 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.

RECOMMENDATION: Expand the element to accommodate all direction scenarios.

 

StructuredSig: FreeText: SigFreeText 
© 1st American Systems and Services LLC Page 32 of 52 Suitability Assessment

www.1asas.com

EDIFACT: Sig Free Text (SIG-030-02)

Implementation Guidance - Errata

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

errors in this element: (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.

RECOMMENDATION: Correct the SCRIPT 10.6 Implementation Guide example or provide the 

correction in an addendum.

 

StructuredSig: Dose: DoseRangeModifier

EDIFACT: Dose Range Modifier (SIG-040-12)

Implementation Guidance - Errata

ISSUE: An example in the 10.6 implementation guide shows an invalid value, "AND" for this element 

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

RECOMMENDATION: Correct the SCRIPT 10.6 Implementation Guide example or provide the 

correction in an addendum.

 

Observation 

The Observation composite has been part of the SCRIPT standard since its early versions, but has not yet 

been adopted by the industry. However, the content of the segment has been analyzed with respect to 

correctness / implementability and use of terminology.

Perhaps because it has not been thoroughly assess by the industry, the composite contains issues that would 

prevent its implementation. The points below identify the key challenges preventing the segment to be used 

as intended.

Observation: Measurement: Dimension

EDIFACT: Measurement Dimension, coded (OBS-010-01)

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity, ECL Challenge

ISSUE: SNOMED and LOINC values allowed by ECL are not allowed by the XML schema.

RECOMMENDATION: Multiple corrections needed in order to create consistency between the 10.6 

Implementation Guide, ECL, and XML schema.

 
© 1st American Systems and Services LLC Page 33 of 52 Suitability Assessment

www.1asas.com

Observation: Measurement: MeasurementDataQualifier

EDIFACT: Measurement Data Qualifier (OBS-010-06)

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity, ECL Challenge

ISSUE: (1) Allows specification of terminologies whose values cannot be expressed in the Dimension 

element (see above). 

(2) Further, the element allows an “Other” terminology qualifier, which does not adequately qualify 

the associated Dimension value the receiving system must interpret.

RECOMMENDATION: (1) Remove XML schema constraints which currently allow only the four X12 DE 

738 observation codes.

(2) Remove 4/Other value and replace with specific allowed terminologies, or provide clarification 

regarding the intended use of the 4/Other qualifier value. 

Observation: Measurement: MeasurementSourceCode

EDIFACT: Source Code List (OBS-010-07)

XML Schema Challenge, Implementation Guidance, ECL Challenge

ISSUE: (1) 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). 

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

(3) The 10.6 XML schema also holds the erroneous Oct 2010 values. (4) The SCRIPT 10.6 

Implementation Guide incorrectly refers to the Units of Presentation terminology in conjunction with 

this element rather than Measurement Unit Code

RECOMMENDATION: (1) Provide an errata note in October 2010 ECL indicating that the values 

indicated are incorrect, and that AD/ NCIt Measurement Unit Code is correct. (2) 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. (3) Correct 10.6 XML schema so that the single allowed value is AD. 

(4) 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 Allergy segment exists only in the SCRIPT Census message, which is designed for use in long-term and 

post-acute care settings. The composite is modeled after the allergy concept in the HITSP C32 CCD definition, 
© 1st American Systems and Services LLC Page 34 of 52 Suitability Assessment

www.1asas.com

though small terminology differences have arisen since its introduction—due to subsequent modifications to 

the C32.

Below are challenges related to the XML representation of the Allergy segment, including structural and 

documentation errors. Discussion of the use of standard terminologies in the Allergy segment is discussed 

further in SCRIPT and Standard Terminologies later in this document.

XML Schema Issues

Allergy: AdverseEvent

EDIFACT: Adverse Event Type ()

Implementation Guidance, ECL Challenge

ISSUE: 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". 

RECOMMENDATION: 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.

 

Allergy: AdverseEvent: CodeListQualifier

EDIFACT: Code List Responsibility Agency (ALG-040-03)

SCRIPT Enhancement Opportunity

ISSUE: The current ECL version does not reference this 10.6 concept, as it has been replaced in later 

NCPDP standards versions with another concept name.

RECOMMENDATION: 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 section 

elsewhere in this document entitled Handling of concept changes with respect to activelyimplemented standards.

 

Allergy: DrugProductCoded: CodeListQualifier

EDIFACT: Code List Responsibility Agency (ALG-050-03)

Implementation Guidance, SCRIPT Enhancement Opportunity
© 1st American Systems and Services LLC Page 35 of 52 Suitability Assessment

www.1asas.com

ISSUE: Earlier ECL value lists for this 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.

RECOMMENDATION: (1) It would benefit implementers to enable use of the most recent ECL values 

for this element.

(2) 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.

 

Allergy: ReactionCoded: CodeListQualifier

EDIFACT: Code List Responsibility Agency (ALG-060-03)

SCRIPT Enhancement Opportunity

ISSUE: The current ECL version does not reference this 10.6 concept, as it has been replaced in later 

NCPDP standards versions with another concept name.

RECOMMENDATION: 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 section 

elsewhere in this document entitled Handling of concept changes with respect to activelyimplemented standards.

Schema documentation issues

ISSUE: The XML schema annotations for the following elements is incomplete-- referencing "X" as the 

related EDIFACT element, rather than actual EDIFACT element IDs

Allergy: AdverseEvent: ItemDescriptionLong

EDIFACT: Item Description Long (ALG-040-01)

Allergy: AdverseEvent: ItemNumber

EDIFACT: Item Number (ALG-040-02)

Allergy: DrugProductCoded: ItemDescriptionLong

EDIFACT: Item Description Long (ALG-050-01)

Allergy: DrugProductCoded: ItemNumber

EDIFACT: Item Number (ALG-050-02)

Allergy: ReactionCoded: ItemDescriptionLong

EDIFACT: Item Description Long (ALG-060-01)
© 1st American Systems and Services LLC Page 36 of 52 Suitability Assessment

www.1asas.com

Allergy: ReactionCoded: ItemNumber

EDIFACT: Item Number (ALG-060-02)

Allergy: SeverityCoded: ItemDescriptionLong

EDIFACT: Item Description Long (ALG-070-01)

Allergy: SeverityCoded: ItemNumber

EDIFACT: Item Number (ALG-070-02)

RECOMMENDATION: Correct the annotations in the 10.6 XML schema, to assist implementers

 

Diagnosis 

The Diagnosis segment exists only in the SCRIPT Census message, which is designed for use in long-term and 

post-acute care settings. The composite is modeled after the problem concept in the HITSP C32 CCD 

definition, though small terminology differences have arisen since its introduction—due to subsequent 

modifications to the C32.

Below are challenges related to the XML representation of the Diagnosis segment, including structural and 

documentation errors. Discussion of the use of standard terminologies in the segment is discussed further in 

SCRIPT and Standard Terminologies later in this document.

XML Schema Issues

DiagnosisGeneral: ProblemType: CodeListQualifier

EDIFACT: Code List Responsibility Agency (DIA-030-03)

SCRIPT Enhancement Opportunity

ISSUE: The current ECL version does not reference this 10.6 concept, as it has been replaced in later 

NCPDP standards versions with another concept name.

RECOMMENDATION: 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 section 

elsewhere in this document entitled Handling of concept changes with respect to activelyimplemented standards.

 

DiagnosisGeneral: ProblemNameCoded

EDIFACT: ProblemNameCoded (DIA-040)

XML Schema Challenge
© 1st American Systems and Services LLC Page 37 of 52 Suitability Assessment

www.1asas.com

ISSUE: An error exists in the 10.6 XML schema related to this composite: The schema should allow up 

to two occurrences of ProblemNameCoded (per the 10.6 Implementation Guide), but only allows 

one.

RECOMMENDATION: Correct the 10.6 schema to allow up to two occurrences of 

ProblemNameCoded.

Schema documentation issues

ISSUE: The XML schema annotations for the following elements is incomplete-- referencing "X" as the 

related EDIFACT element, rather than actual EDIFACT element IDs

DiagnosisGeneral: ProblemType: ItemDescriptionLong

EDIFACT: Item Description Long (DIA-030-01)

DiagnosisGeneral: ProblemType: ItemNumber

EDIFACT: Item Number (DIA-030-02)

DiagnosisGeneral: ProblemNameCoded: ItemDescriptionLong

EDIFACT: Item Description Long (DIA-040-01)

DiagnosisGeneral: ProblemNameCoded: ItemNumber

EDIFACT: Item Number (DIA-040-02)

RECOMMENDATION: Correct the annotations in the 10.6 XML schema, to assist implementers

Challenges impacting SCRIPT elements in multiple segments

Below is further discussion of challenges common to elements in multiple segments of the SCRIPT 10.6 

standard, all of which are identified briefly in the impacted composite-specific sections above. 

Address Line 2 representation

AddressLine2 and PlaceLocationQualifier address elements appear in multiple SCRIPT elements. Below is a 

description of challenges associated with the mapping of the concepts to the XML format.

Address: AddressLine2

EDIFACT: Place / Location (PVD-080-06)

Address: PlaceLocationQualifier

EDIFACT: Place / Location Qualifier (PVD-080-05)

Implementation Guidance, XML Schema Challenge

ISSUE: The XML documentation is not clear regarding how these EDIFACT elements map to the 

AddressLine2 XML concept. The EDIFACT version of SCRIPT 10.6 doesn't contain a dedicated Address 
© 1st American Systems and Services LLC Page 38 of 52 Suitability Assessment

www.1asas.com

Line 2 element; instead, it has a trading partner-defined "Place/Location" with an associated 

“Place/Location Qualifier” element whose values are also trading partner-defined. These are 

imperfectly reflected in the XML format as AddressLine2. The XML also contains a PlaceLocation 

Qualifier element which apparently serves no purpose.

RECOMMENDATION: Provide mapping information to 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.

XML element cardinality issues

Identification

EDIFACT: Reference Number (elements in multiple segments)

Implementation Guidance, XML Schema Challenge

ISSUE: 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.

RECOMMENDATION: 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.

ECL Identification concept mixes identifier types

Identification

EDIFACT: Reference Number (elements in multiple segments)

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: This 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.

RECOMMENDATION: 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.

(See the section elsewhere in this document entitled Consolidation of terms and values from 

dissimilar standards for additional background)

Lacking state qualifiers for certain identifiers

Identification

EDIFACT: Reference Number (qualified for State License Number and DEA Number)
© 1st American Systems and Services LLC Page 39 of 52 Suitability Assessment

www.1asas.com

SCRIPT Enhancement Opportunity

ISSUE: The State License Number and DEA Number elements do 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.

RECOMMENDATION: Consider adding state qualifiers for state license number and DEA number 

elements, to clarify the issuing state.

No differentiation between Individual and Organizational NPI and DEA

Identification

EDIFACT: Reference Number (PVD-020-01 (value), PVD-020-02 (qualifier))

XML Schema Challenge, Implementation Guidance, SCRIPT Enhancement Opportunity

ISSUE: The 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.

RECOMMENDATION: 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.

Other SCRIPT document errata

This section identifies other guidance in the SCRIPT 10.6 Implementation Guide and related documents that is 

unclear or contains errors that could cause challenges for implementers relying on the information. 

Implementation of ePrescribing Standards 

(201009.Read.me.eprescribing.pdf)

Location: Page 3, top. Section: NCPDP SCRIPT Standard Implementation Guide Version 10.6

Text: “Data Dictionary (for field definitions and formats) – 10/2005”
© 1st American Systems and Services LLC Page 40 of 52 Suitability Assessment

www.1asas.com

ISSUE: “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” 

ISSUE (1): The most current version of the External Code List no longer contains certain 

concepts that have been replaced with new concepts in more recent SCRIPT versions, 

including:

7943 – Administration Timing Code Qualifier – SIG Segment

7919 –Body Metric Qualifier - SIG Segment

7923 – Calculated Dose Unit of Measure Code Qualifier – SIG Segment

7893 - Change of Prescription Status Flag

681Ø - Clinical Information Qualifier

Others

It would be preferable for implementers to be able to use a single ECL version when 

implementing SCRIPT 10.6, rather than needing to reference older ECL versions for certain 

elements that are no longer present in more recent ECL versions.

ISSUE (2): 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 XML Schema and ECL 

Version elsewhere in this document.

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” 

ISSUE: “Therapy” should instead be “Terminology”
© 1st American Systems and Services LLC Page 41 of 52 Suitability Assessment

www.1asas.com

SCRIPT and Standard Terminologies

The SCRIPT standard incorporates external terminologies via its External Code List (ECL) (see Management of 

“External Code Lists” elsewhere in this document), for use in identifying...

 medications (RxNorm, NDC)

 substances (UNII)

 drug classes (NDF-RT)

 a drug’s pharmaceutical characteristics such as dosage form (NCI FDA and SNOMED CT)

 other clinical concepts related to administration directions (SNOMED CT and FMT terminologies)

 allergies (SNOMED CT in conjunction with medication, substance and drug class terminologies)

 diagnoses (SNOMED CT, ICD-9, ICD10).

In certain cases, NCPDP has sought consistency of terminology use with other health information exchange 

standards such as the HITSP C32 CCD, in other cases consistency was previously achieved but later lost due 

to changes by other standards, and in other cases SCRIPT’s terminology use is unique to itself. Another 

project deliverable, Standards Compatibility in Medication Reconciliation, assesses SCRIPT’s terminology use 

versus that of the C32 CCD and ASTM CCR in detail. Below are summarized points from that analysis that 

focus on... 

 challenges for implementers created by SCRIPT’s terminology use

 opportunities to improve SCRIPT support for terminologies in terms of consistency with other 

standards and ease of implementation.

Current terminology in SCRIPT, challenges and recommendations

Below is a summary of current medication and clinical terminology used in SCRIPT 10.6, noting consistency 

with the C32 CCD and CCR, and identifying challenges and recommendations for SCRIPT.

Concept SCRIPT Terminology

Compatibility 

with C32 CCD 

and CCR Challenges and Recommendations

Drug Product and Prescribed / Dispensed Qty

Medication 

Product

NewRx: RxNorm and 

RxNorm sources (per MU 

restrictions)

MedHistory, FillStatus: 

RxNorm and others 

including proprietary drug 

databases

Where 

Meaningful Use 

rules apply, 

SCRIPT, CCD and 

CCR all use 

RxNorm.

Support for 

RxNorm is in 

place across 

SCRIPT.

ISSUE: A gap in RxNorm support exists in the Allergy 

drug co-agent element (Allergy: DrugProductCoded: 

CodeListQualifier). Unlike in other SCRIPT elements 

supporting RxNorm, the individual RxNorm qualifiers 

(SBD, SCD, BPK, GPK) are not allowed, but instead a 

single “RxNorm” qualifier. The impact of this omission is 

small, as it doesn’t prevent implementers from using 

these RxNorm concepts—since the more specific 

qualifiers aren’t needed to uniquely convey these 

concepts.

RECOMMENDATION: Add the separate SBD, SCD, BPK, 

GPK qualifiers to the ECL for this element.
© 1st American Systems and Services LLC Page 42 of 52 Suitability Assessment

www.1asas.com

Concept SCRIPT Terminology

Compatibility 

with C32 CCD 

and CCR Challenges and Recommendations

Commercial 

Product, Brand 

Name

NDC11 of generic or brand 

product, as prescribed 

(NewRx, FillStatus) or 

dispensed (MedHistory, 

FillStatus)

SCRIPT, CCD and 

CCR all use NDCs 

to identify 

commercial 

packaged 

products

No challenges or recommendations.

Dosage Form NCI NCPDP StrengthForm

(NCI subset code C89508). 

Subset of NCI FDA 

Pharmaceutical Dosage 

Form: C42636. 

Corresponds to the SPL 

Pharmaceutical Dosage 

Form (NCI subset C54456), 

with some omissions

CCD, Med History 

and CCR: When 

present, 

terminology is 

compatible

ISSUE: Both the CCD and SCRIPT standards use National 

Cancer Institute code sets to represent dosage forms, 

though with some differences. 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. However, NCPDP allows implementers 

to use additional NCI values not contained in the subset.

RECOMMENDATION: Take steps to further align and/or 

reconcile the particular set of NCI-FDA values available 

for SCRIPT with those specified in C32 CCD.

Strength Unit of 

Measure

NCI NCPDP Strength Unit 

of Measure (NCI subset 

code 89509). Corresponds 

to the SPL Potency 

Terminology (NCI subset 

C54458) but lacking some 

SPL codes and containing 

codes not in SPL

Not directly 

comparable 

between CCD, 

CCR, and Med 

History. Optional 

in all, with 

different coding

ISSUE: The NCI subset managed for NCPDP is essentially 

the same as the Structured Product Language (SPL) 

Potency Code set, but with minor differences. These 

differences may cause challenges in processes where 

SCRIPT information is consolidated with data 

conforming to SPL.

RECOMMENDATION: 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.

Medication type n/a Only supported 

by the CCD

No challenges or recommendations. Medication Type 

(Over-the-counter versus prescription) can be reliably 

determined based on the drug identifier in combination 

with other drug data sources

Ordered Quantity

Unit of Measure

NCI NCPDP Quantity Unit 

of Measure (NCI subset 

code 89510). Corresponds 

primarily to the SPL Unit of 

Presentation (NCI C87300) 

but lacks some of those 

values. Also includes terms 

in SPL Potency (subset 

C54458) and Unit Of 

Measure (subset C92951) 

terminologies. 

C32 CCD and 

NCPDP Med 

History / CCR use 

different NCI FDA 

terminologies. 

ISSUE: The Medication History (and CCR by reference) 

use a subset of the NCI Unit of Presentation terminology 

(C87300) whereas the C32 CCD uses the NCI 

Pharmaceutical Dosage Form terminology (C42636).

(For dose units of administration, the situation is 

reversed, with the C32 CCD using units of presentation 

and Medication History / CCR using pharmaceutical 

dosage form.)

RECOMMENDATION: 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.
© 1st American Systems and Services LLC Page 43 of 52 Suitability Assessment

www.1asas.com

Concept SCRIPT Terminology

Compatibility 

with C32 CCD 

and CCR Challenges and Recommendations

Medication Status n/a Not supported by 

the Medication 

History message

No challenges or recommendations. Medication History 

data sources are not in a position to know whether a 

medication is being actively taken by the patient. 

Interactions 

considered

CoAgent: RxNorm

Other: Proprietary NCPDP 

code values

Only in the 

SCRIPT New 

Prescription 

No challenges or recommendations.

Medication Administration

Free Text 

Directions

n/a Free text 

directions ("sig") 

not mandatory in 

the CCD or CCR

No challenges or recommendations.

Delivery Method Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Optional in all 

reviewed 

standards. 

Consistent 

terminology.

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Delivery Method 

Modifier

Recommended: SNOMED 

CT. No constraints 

specified.Allowed: FMT 

(particular terminology not 

specified. Presume NCI)

Only supported in 

the SCRIPT 

standard.

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Dose Unit of 

Administration

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI NCPDP 

StrengthForm, as specified 

for the FormCode element, 

above

C32 CCD and 

NCPDP Med 

History / CCR use 

different NCI FDA 

terminologies. 

CCD includes the 

Unit of 

Presentation 

name only (rather 

than the code 

value)

ISSUE: (1) The Medication History (and CCR by 

reference) use a subset of the NCI Pharmaceutical 

Dosage Form terminology (C42636), whereas the C32 

CCD uses the NCI Unit of Presentation terminology 

(C87300). (2) SCRIPT 10.6 and Structured Sig v1.1 IGs 

conflict regarding FMT being allowed for this element.

RECOMMENDATION: (1) (2) 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

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI NCPDP 

StrengthForm, as specified 

for the FormCode element, 

above

C32 CCD and 

NCPDP Med 

History / CCR use 

different NCI FDA 

terminologies. 

CCD includes the 

Unit of 

Presentation 

name only 

See Dose Unit of Administration comment, above.
© 1st American Systems and Services LLC Page 44 of 52 Suitability Assessment

www.1asas.com

Concept SCRIPT Terminology

Compatibility 

with C32 CCD 

and CCR Challenges and Recommendations

Route of 

Administration

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI FDA 

RouteOfAdministration 

terminology)

Different 

terminologies 

used

ISSUE: (1) The NCPDP Medication History (and the CCR, 

which refers to NCPDP Structured Sig) use SNOMED CT, 

and the C32 CCD uses NCI FDA.

(2) SCRIPT 10.6 and Structured Sig v1.1 IGs conflict 

regarding FMT being allowed for this element.

RECOMMENDATION: (1) (2) 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.

Site of 

Administration

Recommended: SNOMED 

CT. No constraints 

specified.Allowed: FMT 

(particular terminology not 

specified. Presume NCI)

Optional in all 

reviewed 

standards. 

Roughly 

consistent 

terminology.

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Administration

Timing 

(descriptive or 

based on activities 

of daily living)

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Different 

terminologies 

used – CCD uses 

proprietary HL7 

terms

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Frequency Time

Period

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Different 

terminologies 

used – CCD uses 

proprietary HL7 

terms

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Interval Time 

Period

Recommended: SNOMED 

CT. No constraints 

specified.Allowed: FMT 

(particular terminology not 

specified. Presume NCI)

Different 

terminologies 

used – CCD uses 

proprietary HL7 

terms

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Duration Period Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Different 

terminologies 

used – CCD uses 

proprietary HL7 

terms

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Rate of 

Administration

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Different 

terminologies 

used – CCD uses 

proprietary HL7 

terms

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.
© 1st American Systems and Services LLC Page 45 of 52 Suitability Assessment

www.1asas.com

Concept SCRIPT Terminology

Compatibility 

with C32 CCD 

and CCR Challenges and Recommendations

Calculated Dose 

Time Period

Recommended: SNOMED 

CT.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Different 

terminologies 

used – CCD uses 

proprietary HL7 

terms

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Maximum Dose 

Time Period

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Different 

terminologies 

used – CCD uses 

proprietary HL7 

terms

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Indication for medication use

Indication 

Precursor Text 

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Only supported in 

the SCRIPT 

standard.

ISSUE: SCRIPT 10.6 and Structured Sig 1.1 

Implementation Guides conflict: 10.6 allows FMT, but 

Structured Sig recommends only SNOMED CT be used.

RECOMMENDATION: Make SCRIPT 10.6 and Structured 

Sig 1.1 guidance consistent, to assist implementers.

Indication for

medication 

administration 

(optionally in 

conjunction with 

an observation)

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT (particular 

terminology not specified. 

Presume NCI)

Both CCD and 

SCRIPT once 

conformed to the 

VA/KP SNOMED 

problem list 

subset, but 

SCRIPT ECL does 

not reflect a 

subsequent 

change to that 

subset

ISSUE: (1) 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.

RECOMMENDATION: (1) Bring SCRIPT ECL into 

consistency with HITSP C32 CCD by conforming to the 

VA/KP SNOMED problem list subset. (2) Make SCRIPT 

10.6 and Structured Sig 1.1 guidance consistent, to assist 

implementers.

Indication value 

unit of measure

Recommended: SNOMED 

CT. No constraints 

specified.

Allowed: FMT

**Note: inconsistent with 

SCRIPT element, 

Observation 

MeasurementUnitCode, 

which only allows FMT / 

NCI MeasurementUnit 

terms

Optional in all 

reviewed 

standards. Nonspecific guidance 

in all. Internal 

SCRIPT 

inconsistency.

ISSUE: (1) 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.

RECOMMENDATION: (1) Reconcile terminology 

differences between the Observation and Structured Sig 

statements and make adjustments to make them 

consistent. (2) Make SCRIPT 10.6 and Structured Sig 1.1 

guidance consistent according to that outcome, to assist 

implementers.

Adverse Reaction (The SCRIPT Allergy segment is only in the Census message, which is in limited use in LTPAC settings only)

Type of allergy or 

adverse event

Set of SNOMED CT values 

defined in HITSP C80 Table 

2-86 Allergy / Adverse 

Event Type Value Set 

Definition

Terminology 

consistent 

between SCRIPT 

and CCD. CCR 

uses proprietary

No challenges or recommendations.
© 1st American Systems and Services LLC Page 46 of 52 Suitability Assessment

www.1asas.com

Concept SCRIPT Terminology

Compatibility 

with C32 CCD 

and CCR Challenges and Recommendations

Medication 

product

RxNorm, representative 

NDC11, UPC, or Mfr. Code

Roughly 

consistent 

terminology, with 

SCRIPT 

supporting 

additional code 

sets

ISSUE: SCRIPT allows use of additional code sets not 

used in other standards: representative NDC, 

manufacturer code and UPC.

RECOMMENDATION: Because RxNorm is recommended, 

consider eliminating support for representative NDC, 

manufacturer code and UPC in this element.

Drug class NDF-RT Roughly 

consistent 

terminology, but 

different 

constraints on 

NDF-RT range

ISSUE: 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.

RECOMMENDATION: 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.

Food UNII Roughly 

consistent 

terminology.

No challenges or recommendations.

Reaction Values are a subset of 

those defined in HITSP C80 

(v2.01) 2.2.3.4.2 Allergy / 

Adverse Event Type. 

Specifically, only Clinical 

Findings (concepts 

descending from 

404684003) are allowed, 

and not concepts 

descending from Situation 

with Explicit Context 

(243796009). 

Variance in 

terminology due 

to SCRIPT's use of 

initial VA/KP 

problem list 

definition

ISSUE: 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. 

RECOMMENDATION: 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.

Reaction Severity Values conform to HITSP 

C80 2.2.3.1.6 Table 2-67 

Problem Severity set

Consistent 

terminology in 

SCRIPT, C32. CCR 

uses proprietary

No challenges or recommendations.

Problem (The SCRIPT Diagnosis segment is only in the Census message, which is in limited use in LTPAC settings only)

Problem type Values conform to HITSP 

C80 2.2.3.1.2 Table 2-60 

Problem Type Value Set 

Definition

Consistent 

terminology in 

SCRIPT, C32. CCR 

uses proprietary

No challenges or recommendations.

Problem name Values are a subset of 

those defined in HITSP C80 

(v2.01) 2.2.3.1.1 Problem 

Value Set. Specifically, only 

Clinical Findings (concepts 

descending from 

404684003) are allowed, 

and not concepts 

descending from Situation 

Variance in 

terminology due 

to SCRIPT's use of 

initial VA/KP 

problem list 

definition

ISSUE: 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. 

RECOMMENDATION: 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.
© 1st American Systems and Services LLC Page 47 of 52 Suitability Assessment

www.1asas.com

Concept SCRIPT Terminology

Compatibility 

with C32 CCD 

and CCR Challenges and Recommendations

with Explicit Context 

(243796009).

Problem status Not supported by SCRIPT Not supported by 

SCRIPT

ISSUE: SCRIPT does not include a problem status 

element.

RECOMMENDATION: 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)

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. 

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. 

RECOMMENDATION:

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.
© 1st American Systems and Services LLC Page 48 of 52 Suitability Assessment

www.1asas.com

Management of “External Code Lists”

Terminology and other valid value sets used in the SCRIPT standard and other NCPDP standards are managed 

in a single “External Code List” (ECL) document. The ECL is updated independently of the SCRIPT standard as 

the elements requiring valid values or terminology are added to an NCPDP standard, industry conventions 

change, etc. Versions of the ECL are referred to using the date on which the version was published (e.g., “the 

April 2011 ECL”).

NCPDP typically associates an “earliest” ECL version that can be used with a given SCRIPT version (in the case 

of 10.6, the earliest ECL to be used is from October 2008). Implementers are allowed to use code sets in that 

earliest ECL version or any ECL version up to the most recent, and the NCPDP Implementation of ePrescribing 

Standards document recommends use of the most recent ECL version.

While consolidating terminologies and values into a single document and management process has its 

benefits—especially where it is useful for the same terms to be used across NCPDP standards—there are real 

challenges associated with this approach as well. This section identifies certain of these challenges as they 

affect implementers of the SCRIPT standard.

Some challenges relate to the consolidation of terms and values from dissimilar standards (e.g., prescriptions 

and claims). Other challenges are the result of editorial conventions applied by NCPDP to the ECL document. 

And lastly, some challenges are related to the way that ECL concepts are integrated into the SCRIPT version 

10.6 XML structure.

Consolidation of terms and values from dissimilar standards

In several instances, a single ECL code set is maintained to support a concept that is used (and often serves 

different purposes) in different message types. This results in cases where an element in a given SCRIPT 

message is allowed to convey values that are inappropriate in that context—values that are intended for use 

only in other message types.

RECOMMENDATION:

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.

Handling of concept changes with respect to actively-implemented standards

A clinical or administrative concept used in the SCRIPT standard may “evolve” from its original definition over 

time due to corrections from within NCPDP or changes in external industry use of terminology. This evolution 

might take the form of more or fewer valid values, references to different standard terminologies, changes in 

constraints on standard terminologies, etc.

The way in which the ECL document is updated to reflect changes has a significant impact on implementers of

an older version of SCRIPT (such as 10.6) that references such a changed concept.

In some cases, newer ECL versions apply those changes to the existing concept—enabling implementers of all 

SCRIPT versions use of the current values. This handling of changing concepts does not present a challenge 
© 1st American Systems and Services LLC Page 49 of 52 Suitability Assessment

www.1asas.com

for implementers—when they and their trading partners agree to use the newer ECL, the new value set 

replaces the old set for each 10.6 concept.

In other cases, however, the ECL omits content related to older versions of SCRIPT (including 10.6) in favor of 

content ostensibly limited to use in newer versions of the standard which are not yet allowed for use by 

federal programs. In these cases, NCPDP appears to have chosen to “replace” an existing concept with 

another that represents the same underlying domain of information. For example, the concept, 4343 

Message Function, coded, which is present in version 10.6, is replaced in the current ECL version with a 

concept named MessageRequestCode. 

The challenge for implementers arises when a 10.6 implementer references the current ECL version as 

directed by SCRIPT guidance, and they do not find certain concepts used in 10.6, such as 4343 Message 

Function, coded noted above. Instead, upon searching the text of the ECL document they will find the 

statement, "See 4343 Message Function, coded for SCRIPT Versions 1Ø.11 and lower". Upon further 

searching, however, the implementer will learn that the current ECL does not contain a definition for the 

referenced concept (4343 Message Function, coded). 

RECOMMENDATION:

Implementers would benefit from a consistent editorial policy to include all concepts included in activelyimplemented SCRIPT versions, cross-referencing as applicable to replacement concepts or versionconstrained values as applicable.

Including all version 10.6 ECL concepts in current ECL document versions 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.
© 1st American Systems and Services LLC Page 50 of 52 Suitability Assessment

www.1asas.com

Other Implementability

This section identifies other challenges presented by the SCRIPT 10.6 standard from the perspective of the 

implementer, describing how the components of the standard fit together from an implementer’s 

perspective, assessing strengths and weaknesses and calling out opportunities for improvement. While 

findings from the quality and terminology reviews factor into this assessment, this section focuses on 

management of changes to the standard and documents related to it, including identification of errors and 

errata in documentation, capturing of additional guidance in response to implementer questions and 

experience, and synchronization of XML schema content with the NCPDP External Code List (ECL).

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

version into their systems

One 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).

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.

A challenge presented by this situation is that, if an implementer wishes to use an ECL version that differs 

from what has been integrated into the XML schema, they must manually update values throughout the 

schema—a process prone to error. Further, the fact that the 10.6 schema does not typically include the most 
© 1st American Systems and Services LLC Page 51 of 52 Suitability Assessment

www.1asas.com

recent ECL version contrasts the direction given in the NCPDP Implementation of ePrescribing Standards

document (201009.Read.me.eprescribing.pdf), which states that the most recent ECL is recommended.

The XML structure in later versions of SCRIPT separates the ECL values from the rest of the message content, 

partially addressing these challenges. However, that structural change does not address inconsistency in 

NCPDP guidance regarding the preferred ECL version.

RECOMMENDATION:

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.
© 1st American Systems and Services LLC Page 52 of 52 Suitability Assessment

www.1asas.com

Document References

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.