Initial release of specifications for AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 (CFER-CP V1.0)

Transcription

1 IMPLEMENTATION GUIDE AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Technical Specifications for Data Submission from PSO to PSOPPC AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 December 2016

2 Revision History Revision Date 12/2016 Notes Initial release of specifications for AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 (CFER-CP V1.0) AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 2 of 45

3 Table of Contents 1 INTRODUCTION Objectives Audience Program Overview Data Submission Overview Supporting Documentation COMMUNITY PHARMACY PATIENT SAFETY REPORT Community Pharmacy Patient Safety Report Validation Data Set Complete/Rejected Report APPROACH Conventions Used in This Specification Conformance Requirements XPath Notation Keywords XML Examples XML Elements, Attributes and Values in CDA Succession Management File Size Limitations File Name Limitations Use of Object Identifiers Overview of HL7 OID Management AHRQ Common Formats OID Structure Vocabularies and Value Sets Vocabulary and Value Set Example using AHRQ Common Formats Code System Vocabulary and Value Set Example Using a Standard Code System Use of Templates Document-Level Templates Section-Level Templates Entry-Level Templates Validation of CDA XML files CDA FILE STRUCTURE Major Components of a Community Pharmacy Patient Safety Report Initial XML Elements Document Element Community Pharmacy Patient Safety Report CDA Header Constraints Header Elements Header Participants Community Pharmacy Patient Safety Report CDA Body Constraints Community Pharmacy Event Section Constraints Narrative Block Community Pharmacy Event Constraints Clinical Statement Templates MoU Representation of Data Elements in CDA Sections REFERENCES AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 3 of 45

4 List of Figures Figure 1. ClinicalDocument Example Figure 2. Example of Elements, Attributes and Values Figure 3. Example of Use of Data Element ID, Answer Codes, Value Sets and Code Systems Figure 4. Value Set OID Structure Figure 5. Example of Use of Standard Code Systems Figure 6. Template OID Structure Example Figure 7. CDA Entry-Level Template Identifier Example Figure 8. Major Components of a Community Pharmacy CDA Document Figure 9. Initial XML Elements Example Figure 10. ClinicalDocument Element Example Figure 11. ClinicalDocument/typeId Example Figure 12. ClinicalDocument/templateId Example Figure 13. ClinicalDocument/id Example Figure 14. ClinicalDocument/code Example Figure 15. ClinicalDocument/title Example Figure 16. effectivetime Example Figure 17. effectivetime Unknown Example Figure 18. confidentialitycode Example Figure 19. setid Example Figure 20. versionnumber Example Figure 21. recordtarget and administrativegendercode in an Incident Report with One Patient Example 29 Figure 22. Unknown administrativegendercode in an Incident Report Example Figure 23. recordtarget Example for a Near Miss or Unsafe Condition Report Figure 24. author Example Figure 25. custodian Example Figure 26. structuredbody Example Figure 27. Narrative Block within a Section Example Figure 28. Community Pharmacy Event Section in an Incident Report Involves Two Medications Figure 29. MoU Observation Element - CD Data Type Single Answer Value Example (AHRQ Common Formats Code System) Figure 30. MoU Observation Element CD Data Type Single Answer Value Example (RxNorm Code System) Figure 31. MoU Observation Element - CD Data Type Single Answer Value Example (NDC Code System) Figure 32. MoU Observation Element - CD Data Type "Other: Please Specify" Example Figure 33. MoU Observation Element CD Data Type Multiple Answer Values Example Figure 34. MoU Observation Element - CD Data Type Unknown Answer Value Example Figure 35. MoU Observation Element ED Data Type Example Figure 36. MoU Observation Element ED Data Type Example Showing Submission of Unknown Figure 37. MoU Observation Element TS Data Type Example Figure 38. MoU Observation Element TS Data Type Example Showing Submission of Unknown AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 4 of 45

5 List of Tables Table 1. Keywords Table 2. Illegal Characters in a Well-Formed XML Table 3. AHRQ Common Formats OID Structure Table 4. Vocabulary and Value Set Example using the AHRQ Common Formats Code System Table 5. Vocabulary and Value Set Example Using a Standard Code System Table 6. Community Pharmacy Version 1.0 Patient Safety Report Related Template OIDs Table 7. Document-Level Templates for Community Pharmacy Report Type Table 8. Community Pharmacy Report Types Table 9. Sex Code Value Set Table 10. Community Pharmacy Patient Safety Report Section and Section-Level Template ID Table 11. Community Pharmacy Event-Level Data Elements Common to All Medications Table 12. Medication-Specific Data Elements AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 5 of 45

6 1 INTRODUCTION 1.1 Objectives The primary objective of this document is to provide the specifications for the required file format and data elements for transmitting Common Formats Community Pharmacy Patient Safety Report data from Patient Safety Organizations (PSOs) to the Patient Safety Organization Privacy Protection Center (PSOPPC). 1.2 Audience This document is written to serve the following audiences: Patient Safety Organizations (PSOs) Software Vendors Community Pharmacies Readers should be familiar with XML, HL7 and CDA standards. 1.3 Program Overview The Common Formats, published by the Agency for Healthcare Research and Quality (AHRQ) of the U.S. Department of Health & Human Services, were created as part of the Patient Safety and Quality Improvement Act of 2005 (Patient Safety Act). AHRQ has coordinated the development of the Common Formats for Event Reporting to facilitate the voluntary collection of patient safety event information. For more information on the Common Formats, refer to the Common Formats landing page on the PSOPPC Web Site ( The Common Formats are intended to be used to gather information on a patient safety event in order to create a Common Formats Patient Safety Report (hereinafter referenced to as report ). Reports may be submitted to the PSOPPC for data nonidentification and transmission to the Network of Patient Safety Databases (NPSD). 1.4 Data Submission Overview Patient safety event data shall be transmitted to the PSOPPC using the Extensible Markup Language (XML) file format. The XML file shall conform to the Health Level Seven (HL7) Clinical Document Architecture, Release 2.0 (CDA R2) standard. This document provides the XML CDA file specifications for transmission of reports to the PSOPPC using the AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 (CFER-CP V1.0) data elements. Transmission of the report CDA XML files by PSOs to the PSOPPC shall be performed using the secure pages of the PSOPPC website ( Access to the secure pages of the PSOPPC website requires a PSOPPC website user account. Please contact the PSOPPC Help Desk at or at support@psoppc.org for more information on obtaining a PSOPPC website user account. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 6 of 45

7 1.5 Supporting Documentation The following documents are integral to this specification and are available on the PSOPPC Web Site ( from the Technical Specifications page for Community Pharmacy Version 1.0 ( Community Pharmacy Resources Workbook The Community Pharmacy Resources Workbook complements the Implementation Guide and provides information about the data elements that will assist with the development of a report CDA XML file. It also contains the validation rules that will be applied to the data elements and the associated answer values submitted to the PSOPPC. Community Pharmacy Flow Chart The Community Pharmacy Flow Chart complements the Implementation Guide and provides the data elements and associated answer values (where applicable) that are required or recommended to be answered based on the report type and event category associated with the report. The various paths of the data elements identify the valid data elements to be included within a report. Community Pharmacy CDA XML File Samples The Community Pharmacy sample CDA XML files provide sample patient safety events and the associated CDA XML file output. The sample CDA XML files contain all recommended data elements for a complete report and conform to the Community Pharmacy Version 1.0 Technical Specifications. Community Pharmacy Data Dictionary A data dictionary is also available on the Technical Specifications page for Community Pharmacy Version 1.0 on the PSOPPC Web Site. The Data Dictionary further defines the data elements and their attributes (data element name, data element ID, answer values, answer codes, HL7 data type, guide for use, etc.). AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 7 of 45

8 2 COMMUNITY PHARMACY PATIENT SAFETY REPORT A report shall consist of the data elements, and associated answer values (where applicable) as defined in these specifications. Each report shall be submitted in a single XML file. An XML file shall contain only one report. 2.1 Community Pharmacy Patient Safety Report Each report shall be classified as one of the following report types: Incident: A patient safety event that reached the patient, whether or not the patient was harmed. Near Miss: A patient safety event that did not reach the patient. Unsafe Condition: Any circumstance that increases the probability of a patient safety event. The data elements for a complete report are defined in the Community Pharmacy Flow Chart. Refer to Section 1.5, Supporting Documentation, for more information on the Community Pharmacy Flow Chart. 2.2 Validation Data Set The Community Pharmacy Flow Chart specifies the data elements necessary for a complete report. All data elements for a complete report are required to be included in a patient safety event CDA XML file for acceptance by the PSOPPC. CDA XML files missing any of the required data elements will be rejected by the PSOPPC. 2.3 Complete/Rejected Report When a report meets the file specifications and validation rules, and includes all of the required data elements specified by the Community Pharmacy Flow Chart for the report type, the file will be accepted by the PSOPPC with an Accepted: Complete status. Files that receive an Accepted: Complete status meet all of the technical specifications for Community Pharmacy Version 1.0. A report that does not meet the files specifications or validation rules will be rejected by the PSOPPC with a Rejected status. Data from rejected files will not be used to aggregate counts of patient safety concerns by type at the national level. The submission report page on PSOPPC website ( provides the submission processing status and associated error messages. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 8 of 45

9 3 APPROACH 3.1 Conventions Used in This Specification Requirements are expressed as conformance statements, which are constraints on the base standard. The base standard for this specification is the HL7 Clinical Document Architecture, Release 2.0 (CDA R2). Though effort is made to describe all the aspects of applicable CDA R2, every aspect of the CDA R2 may not be described in this specification. Each CDA XML file shall be in the valid XML file format. Where no conformance requirements are stated in this specification, the CDA files are subject to and are to be created in accordance with the base CDA R2 specification. The CDA R2 specification is available from the secure area of the HL7 website at the following location Access to the specification requires HL7 membership. This specification, at a minimum, expects implementers to be familiar with the development and management of XML files. It also assumes familiarity and experience with validating XML files against XML schemas (.XSD documents). Knowledge of the CDA specification is helpful but not required for implementation. Additionally, experience with software development processes is expected Conformance Requirements Conformance statements provide the constraints on the XML elements, their attributes and the valid value sets applicable to the elements and the attributes. The conformance requirements for this specification are numbered sequentially and are displayed as shown in the following example: CONF-CF-example1: Conformance statement numbering and format within this specification for a CDA XML file. The format of the fonts within the conformance statements is as follows: XML elements, attributes, and standard attribute values shall be represented using the Courier New font with a font size of 10. SHALL SHOULD MAY and STATIC DYNAMIC are keywords and shall be represented using the ARIAL FONT in Bold with a font size of 10 in small caps. The value set constraints are specified as either static, meaning that they are bound to a specified version of a value set, or DYNAMIC, meaning that they are bound to the most current version of a value set. Examples of syntax for the vocabulary binding to DYNAMIC or STATIC value sets where applicable are as follows (these are example conformance statements only): CONF-CF-example2: The value for pathname of coded element (SHALL SHOULD MAY) be selected from ValueSet valuesetoid localvaluesetname codesystemoid [codesystemname] (DYNAMIC STATIC). CONF-CF-example3: The value for observation/value/@code SHALL be selected from ICD-9CM (diagnosis codes) DYNAMIC. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 9 of 45

10 CONF-CF-example4: The value for SHALL be selected from ValueSet CFSexCode (CodeSystem: HL7AdministrativeGender) STATIC. The majority of the value sets have a STATIC set of answer values defined within the AHRQ Common Formats Code System or within one of the standard vocabulary systems (e.g. SNOMED CT, LOINC etc.). Value sets that have a STATIC set of answer values are provided within the Answers tab of the Community Pharmacy Resources Workbook. The effective date for all the static ValueSets within this specification corresponds to the publication date of the Community Pharmacy Version 1.0 Technical Specifications. Value sets that have a dynamic set of answer values (such as RxNorm codes) are derived from the respective vocabulary systems. A simplified constraint is used when binding to a single code. Examples of syntax for vocabulary binding to a single code where applicable are as follows: CONF-CF-example5: The value for pathname of coded element (SHALL SHOULD MAY) be "code" [displayname] codesystemoid [codesystemname] STATIC. CONF-CF-example6: The value for ClinicalDocument/confidentialityCode/@code SHALL be "N" Normal (CodeSystem: HL7Confidentiality) STATIC. In the example conformance statements above, the elements provided in [ ] are optional. Words separated by the " " character are to be read as an "or" within the statement XPath Notation Instead of the traditional dotted notation used by HL7 to represent Reference Information Model (RIM) classes, this document uses XML Path Language (XPath) notation in conformance statements and elsewhere to identify the XML elements and attributes within the CDA document instance in which various constraints are applied. The implicit context of these expressions is the root of the document. The purpose of using this notation is to provide a mechanism that will be familiar to developers for identifying parts of an XML document Keywords The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT and SHALL NOT, in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator s Guide ( it&projectnumber=295). To convey the sense of: Table 1. Keywords Use the following: Required/Mandatory SHALL SHALL NOT Best Practice/Recommendation SHOULD SHOULD NOT Acceptable/Permitted MAY NEED NOT AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 10 of 45

11 3.1.4 XML Examples XML examples appear in various figures in this document in a fixed-width font, as shown in the example in Figure 1. Portions of the XML content may be omitted from the examples for brevity, marked by an ellipsis ( ) as shown in the example in Figure 1. Figure 1. <!--ClinicalDocument example--> <ClinicalDocument xmlns="urn:hl7-org:v3"... </ClinicalDocument> ClinicalDocument Example XPath expressions are used in the narrative and conformance requirements to identify elements because they are familiar to many XML implementers XML Elements, Attributes and Values in CDA Each CDA XML file is made up of elements, element values, attributes and attribute values. In the example in Figure 2, component, observation, templateid, etc. are elements. classcode and moodcode are attributes of the observation element. "OBS" is an attribute value of the classcode attribute. "EVN" is an attribute value of the moodcode attribute. The text "Wrong medication in container" is a value for the value element. Figure 2. Example of Elements, Attributes and Values <component> <observation classcode="obs" moodcode="evn"> <templateid root=" "/> <code code="de15" displayname="briefly describe the event that occurred or unsafe condition:" codesystem=" " codesystemname="ahrq Common Formats"/> <value xsi:type="ed" mediatype="text/plain"> Wrong medication in container. </value> </observation> The element names, attribute names and attribute values are case sensitive. The element values (which are used for user entered free text response to data elements) are case insensitive. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 11 of 45

12 The following characters when used within attribute or element values may make an XML file invalid. To ensure that the XML files are valid, these characters should be replaced by an entity reference: Table 2. Illegal Characters in a Well-Formed XML Illegal Characters Entity Reference Description < < Less than > > Greater than & &amp Ampersand &apos; Apostrophe " " Quotation mark Succession Management This specification allows updates to previously submitted reports by replacing a previously submitted file with an updated file. A report is uniquely identified by a combination of the PSO Identifier (PSO OID), Provider Identifier and Event Identifier. Each report shall have a version number, stored as an integer, which shall be incremented for subsequent versions of the report (Refer to Section for more information on the report version). Every report (whether an updated version of a previously submitted report or a new report submission) being submitted to the PSOPPC, shall always have a new ClinicalDocument/id representing a unique identifier for the document. For submitting an update to a previously submitted report, the updated CDA file shall have the same PSO Identifier (setid/@root and custodian elements), Provider Identifier (author element) and Event Identifier (setid/@extension element) as the previously submitted CDA file, but an incremented version number (versionnumber element) than the version number of the previously submitted report. Previously submitted data shall be overwritten by the updated data submitted in the most recent successful CDA file submission for the same event report. Appending new data to previously submitted files is not allowed within this specification File Size Limitations Report XML files can be submitted individually, submitted as multiple individual files, or grouped together into one or more zip files. Each submission (either individual files, or zip files) shall not be greater than 80 MB File Name Limitations Report XML and zip files (.zip file extensions only) must conform to the following file naming specifications: The file name shall be less than 45 characters in length. The file name shall not include any of the following characters: \ / & *? " < > AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 12 of 45

13 3.2 Use of Object Identifiers Object Identifiers (OIDs) are unique identifiers used to identify the different objects (sections, entries, templates, etc.) and entities (PSOs, Reports etc.) within the CDA XML file specification. OIDs are used in HL7 documents, such as the CDA and HL7 messages, to add global uniqueness to identifiers used within the document. They are also used to identify the vocabulary terminology systems, such as SNOMED and RxNorm, used in the documents and messages Overview of HL7 OID Management The approach used for the CDA file specifications is adopted from HL7 OID management which states: Object Identifier (OID) Definition: An OID is a globally unique string representing an ISO (International Organization for Standardization) identifier in a form that consists only of numbers and dots (e.g., " "). OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique number that corresponds to a leaf node on the tree. The leaf may represent an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree. OIDs are the preferred scheme for unique identifiers in HL7. HL7 Version 3 artifacts use OIDs to identify coding schemes and identifier namespaces. OIDs can be allocated by any organization using a unique OID root AHRQ Common Formats OID Structure The OIDs used in this specification are extended from the AHRQ OID. The OID used to identify AHRQ is: The Common Formats OID is extended from the AHRQ OID and is Table 3 provides the AHRQ and the AHRQ Common Formats OIDs as well as the OIDs extended from the AHRQ Common Formats OID for use within this specification. Table 3. AHRQ Common Formats OID Structure OID OID Value OID Description AHRQ OID The OID used to identify AHRQ. AHRQ Common Formats Root OID This is the root OID for this specification. All other OIDs are derived as branches of this root OID. Common Formats PSO Root OID See section Common Formats PSO Root OID Common Formats ValueSet Root OID See section 3.3 Vocabularies and Value Sets Common Formats Template Root OID See section 3.4 Use of Templates Common Formats Code System OID See section 3.3 Vocabularies and Value Sets AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 13 of 45

14 Common Formats PSO Root OID Each PSO shall be identified by a unique OID. The unique OID for each PSO shall be created using a combination of the PSO Root OID ( ) and the PSO ID (e.g. P0023) assigned by AHRQ. The PSO OID is collected as data element ID DE4, which is an Encapsulated Data Type found in the CDA XML Header. The AHRQ-assigned PSO ID for each PSO begins with the letter P, followed by 4 numeric characters e.g. P0023. The PSO ID is assigned to the PSO upon official listing by AHRQ. The PSO shall create their PSO OID using the following convention: The numeric value (not including any preceding zeros) of the PSO ID is appended to the PSO Root OID ( ). The PSO Root OID and the numeric value of the PSO ID shall be separated by a period. For example, the PSO OID for a PSO with an AHRQ-assigned PSO ID of P0023 would be: Throughout this guide we use PSO P0023 in the examples. PSOs will need to replace this value with their own PSO ID. 3.3 Vocabularies and Value Sets Vocabularies are sets of terms (represented by codes) that may be in general use (standard codes) or created locally (local codes). A value set is a subset of the vocabulary and contains a list of intended values appropriate for a data element. In CDA, vocabularies, and value sets are represented using Object Identifiers (OIDs) as illustrated in the examples in Table 4 and Table 5. Data elements are represented either by values from a value set or by a free text narrative response. The values for data elements that have a value set are identified either by using codes from a standard vocabulary or code system (e.g. RxNorm, LOINC, ICD-9CM (diagnosis codes/procedure codes), ICD-10CM (diagnosis codes/procedure codes), etc.), or when the values do not exist in any standard vocabularies, by defining local codes for them within the AHRQ Common Formats Code System. The AHRQ Common Formats Code System assigns a unique identifier (Data Element ID) to each data element. The Data Element ID along with its associated value set provides a complete representation of a data element. Each code system is identified by a unique OID, which is used to identify the code system within the CDA XML file. The AHRQ Common Formats Code System is identified by the following OID: Each unique value set is represented by an OID that uniquely identifies the value set. The OID for each unique value set in this specification is a branch of the value set subroot OID (Answer ValueSet Root). The example in Table 4 shows the value set OID for the Data Element DE285 (Type of Nutritional Products) as , which is a branch of the value set sub-root OID The Data Element ID, associated answer codes (both from standard code systems and the AHRQ Common Formats Code System), answer values, value set OIDs, and code systems for each data element within the AHRQ Common Formats are provided in the Community Pharmacy Resources Workbook. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 14 of 45

15 3.3.1 Vocabulary and Value Set Example using AHRQ Common Formats Code System Table 4 provides an example of a data element (Nutritional products/food) that is represented by a set of values encoded using local codes defined within the AHRQ Common Formats Code System. Table 4. Vocabulary and Value Set Example using the AHRQ Common Formats Code System Data Element ID: DE285 Data Element Name: Type of Nutritional Product Value Set OID: Answer Answer Value Code System Code System Name Code A1242 Dietary supplement (other than vitamins or minerals) AHRQ Common Formats A1245 Vitamins or minerals AHRQ Common Formats A1248 Enteral nutritional products AHRQ Common Formats A1249 Medical food AHRQ Common Formats Figure 3 provides an implementation sample of the vocabulary and value sets example illustrated above in Table 4. Figure 3. Example of Use of Data Element ID, Answer Codes, Value Sets and Code Systems <!--data element Ids, answer codes, value sets and code systems example--> <observation classcode="obs" moodcode="evn"> <code code="de285" displayname="type of Nutritional Product: codesystem=" " codesystemname="ahrq Common Formats"/> <value xsi:type="cd" code="a1245" displayname="vitamins or minerals " codesystem=" " codesystemname="ahrq Common Formats"/> </observation> Figure 4 summarizes the Value Set OID structure. Figure 4. Value Set OID Structure AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 15 of 45

16 3.3.2 Vocabulary and Value Set Example Using a Standard Code System Table 5 provides an example of a data element (Patient Sex) which is represented by a set of values encoded using codes from the HL7 Administrative Gender code. Table 5. Vocabulary and Value Set Example Using a Standard Code System Data Element ID: DE1106 Data Element Name: Sex Value Set: CFSex Value Set OID: Answer Code Answer Value Code System Code System Name M Male HL7 Administrative Gender F Female HL7 Administrative Gender For further information about the standard code systems used within this specification, please refer to Section 5 (References) of this document which provides relevant links to the code systems. Figure 5 provides an implementation sample of the vocabulary and value sets encoded using codes from the HL7 Administrative Gender code example illustrated in Table 5. Figure 5. Example of Use of Standard Code Systems <!--administrativegendercode shall be the sex (DE1106) of the patient--> <recordtarget> <patientrole> <id root=" " extension="1"/> <patient> <administrativegendercode code="m"codesystem=" "/> </patient> </patientrole> </recordtarget> AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 16 of 45

17 3.4 Use of Templates Templates are used to define a set of rules or constraints that can be applied to different parts of a CDA document. When used in a CDA document, the template identifier (templateid) signals the imposition of a set of template-defined constraints. The value of the templateid attribute provides a unique identifier for the templates in question. Within the CDA file, templates can be applied at the document-level, section-level and entrylevel to constrain the generic CDA specification. Document-level templates assert conformance to the constraints defined for a full document. Section-level templates assert conformance to the constraints defined for document sections. Entry-level templates assert conformance to the constraints defined for CDA entries. A report makes use of templates to define constraints that apply to the entire report (document-level template) or to specific report types (document-level templates that apply to an Incident, Near Miss, or Unsafe Condition reports) and to CDA entries (entrylevel templates that apply to each data element observation (e.g. medication type, harm, etc.)). Template identifiers are critical in this specification and are required to be included within the CDA document as defined within the specification. Submission of reports that do not conform to the template identifier constraints defined within this specification may be rejected as nonconformant. The template structure for this specification is provided in Figure 6 below. Figure 6. Template OID Structure Example Users requiring additional assistance in viewing examples, may contact the PSOPPC Help Desk at or at AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 17 of 45

18 Table 6 lists all Community Pharmacy Patient Safety Report Version 1.0 related template OIDs. Table 6. Community Pharmacy Version 1.0 Patient Safety Report Related Template OIDs Template Name Template OID Document-Level Template Name / Document Name Patient Safety Report (Generic constraints) Incident Report Near Miss Report Unsafe Condition Report Section-Level Template Name / Section Name Community Pharmacy Entry-Level Template Name Model of Meaning Data Element Patterns N/A Model of Use Data Element Patterns Model of Use Observation element Document-Level Templates Document-level templates define two kinds of constraint sets applicable to the full document instance. Document-level templates use the templateid element in the CDA header. The Community Pharmacy CDA XML document is identified by two document-level templates Patient Safety Report Generic constraints , and one of the three report type constraints: Incident Report Near Miss Report Unsafe Condition Report Section-Level Templates Section-level templates define constraints that apply to the CDA sections within the body of the CDA document. The section-level templates define the constraints related to the section and the data elements included within the specific section. This template identifies constraints such as The Community Pharmacy section MAY contain one title element valued with the following case-insensitive, text string Community Pharmacy. There is only one section for a Community Pharmacy Patient Safety Report: Community Pharmacy Event section Entry-Level Templates CDA entries represent the structured components within a document section. When included in a document section, each data element represented by a CDA element (e.g. observation, procedure, etc.) becomes an entry within the document. Each section can contain one or more entries. Each data element may have a set of constraints defined within the template. For details, please refer to Section 4.5 Clinical Statement Templates. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 18 of 45

19 Figure 7 is an example of using the AHRQ Model of Use Observation entry-level template: Figure 7. CDA Entry-Level Template Identifier Example <!--entry-level template identifier example--> <section>... <component> <observation classcode="obs" moodcode="evn"> <!--Indicating conformance to entry-level template constraints for AHRQ Model of Use Observation--> <templateid root=" "/> <code code="de1100" displayname="event Date:" codesystem=" " codesystemname="ahrq Common Formats"/> <value xsi:type="ts" value=" "/> <!--Format here is YYYYMMDD--> </observation>... </section> AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 19 of 45

20 3.5 Validation of CDA XML files Validation of a CDA file against the CDA R2 schema (CDA.xsd) can be done using freely available CDA validation tools on the web ( Validation against the CDA.xsd allows the submitter to validate that their CDA file can be performed against the CDA R2 schema to ensure that the file conforms to the basic CDA specifications. Any errors generated during this validation must be corrected before submission to the PSOPPC. The PSOPPC shall perform a comprehensive validation for every CDA file submitted. The validation includes conformity with the CDA schema, in addition to compliance to the conformance statements provided in the AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide and the Common Formats validation rules provided in Community Pharmacy Resources Workbook. Error messages generated as part of file processing and the processing status ( Accepted: Complete, or Rejected ) are available to the submitting organization through submission reports. Submission reports are accessible from the secure pages of the PSOPPC website. Upon processing completion at the PSOPPC, the submitter will receive an indicating their files have been processed. The notification contains the status of the processed files and notifies the user that any associated error messages (critical errors or informational warnings) are available in the submission reports. Submitters should review their submission reports to identify the processing status of submitted files and to view any associated error or warning messages. If a file is rejected, the submitter is encouraged to review the error messages, fix any errors, and resubmit the file to the PSOPPC. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 20 of 45

21 4 CDA FILE STRUCTURE This section describes the major components of a CDA document and the initial set of elements to be included in each CDA XML file. 4.1 Major Components of a Community Pharmacy Patient Safety Report A CDA document is wrapped by the ClinicalDocument element and contains a header and a body. Major components of a CDA document are shown in the skeletal example in Figure 8. Note: Many required components are missing to simplify the example. The header lies between the ClinicalDocument and the structuredbody elements and provides the following: Ability to identify and classify the document Ability to provide information on authentication, the encounter, the patient and the involved provider The CDA XML body contains the Community Pharmacy Patient Safety Event section. Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for further computer processing. CDA entries typically encode content present in the narrative block of the same section. For complete samples of Community Pharmacy Patient Safety Report CDA XML, please refer to Community Pharmacy CDA XML File Samples. Figure 8. Major Components of a Community Pharmacy CDA Document <!--major components of a CDA document--> <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi= xsi:schemalocation="urn:hl7-org:v3 CDA.xsd"> <!--Start of Header-->...CDA Header Elements... <!--End of Header--> <!--Start of Body--> <component> <structuredbody> <! Start of Community Pharmacy Event Section --> <component> <section> <id root=" "/>... Community Pharmacy Event Elements... </section> <!--End of Community Pharmacy Event Section --> </structuredbody> <!--End of Body--> </ClinicalDocument> AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 21 of 45

22 4.1.1 Initial XML Elements Each CDA file SHALL begin with the xml element where the value The CDA file MAY also contain the xml-stylesheet element where the value and the value as shown in Figure 9. Figure 9. <!--initial XML Elements--> <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="cda.xsl"?> Initial XML Elements Example Document Element The ClinicalDocument is the top-level element in a CDA document. CONF-CF-1: CONF-CF-2: Each CDA file SHALL contain exactly one ClinicalDocument element where the value the value and the value The ClinicalDocument element MAY contain CDA.xsd". Figure 10. ClinicalDocument Element Example <!--required CDA header element--> <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi=" xsi:schemalocation="urn:hl7-org:v3 CDA.xsd"> </ClinicalDocument> AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 22 of 45

23 4.2 Community Pharmacy Patient Safety Report CDA Header Constraints The data elements are collected within the CDA file. Some of the data elements are collected within the CDA header elements while others are collected within sections in the CDA body. The data elements included within the header shall not be included again within the CDA body. This section describes the constraints that apply to the CDA header. Header constraints are expressed in relation to the ClinicalDocument element. The header constraints are generic, which are applicable to all Community Pharmacy Patient Safety reports Header Elements The constraints on the CDA elements to be included within the header of a report are provided in this section. There are 44 unique Data Elements in Community Pharmacy Patient Safety Report. Among them, there are five administrative data elements and one patient information data element whose value shall be provided in the CDA XML header: DE1 Provider ID DE2 Event ID DE3 Report Type DE4 PSO ID DE30 Report Date DE1106 Patient Sex ClinicalDocument/typeId CDA requires that a ClinicalDocument/typeId be present to identify the constraints imposed by CDA Release 2.0, essentially acting as a CDA version identifier. CONF-CF-3: CONF-CF-4: A report SHALL contain exactly one ClinicalDocument/typeId. The value of typeid/@root SHALL be " " and the value of typeid/@extension SHALL be POCD_HD Figure 11. ClinicalDocument/typeId Example <!--required CDA header element--> <typeid root=" " extension="pocd_hd000040"/> ClinicalDocument/templateId The ClinicalDocument shall have exactly two templateid elements: One templateid shall represent conformance to the generic constraints, and the other templateid shall represent conformance to one of the three report type-specific constraints. The template names for the report types and the associated template OIDs are provided in Table 7. By requiring conformance to both the generic and the report type-specific constraints, each CDA file shall be required to adhere to all the generic and report type-specific constraints specified in this specification. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 23 of 45

24 CONF-CF-5: CONF-CF-6: CONF-CF-7: A report SHALL contain exactly two ClinicalDocument/templateId elements. The value of one ClinicalDocument/templateId/@root SHALL be representing conformance to the AHRQ Common Formats Community Pharmacy Patient Safety Report Version 1.0 generic constraints. The value of the other ClinicalDocument/templateId/@root SHALL be an OID selected from the Document-Level Templates. Table 7 represents conformance to one of the three Common Formats Report Types. Table 7. Document-Level Templates for Community Pharmacy Report Type Template Name for Report Types Template OID Incident Report Near Miss Report Unsafe Condition Report Figure 12. ClinicalDocument/templateId Example <!--template id indicating conformance to AHRQ Community Pharmacy Patient Safety Report Version 1.0 generic constraints--> <templateid root=" "/> <!--template id indicating conformance to an Incident Report-specific constraints--> <templateid root=" "/> ClinicalDocument/id The ClinicalDocument/id represents the unique instance identifier (UID) of a clinical document. The id element uniquely and universally distinguishes a document from all other documents. The id element contains a root and an extension attribute. The PSO is responsible for generating the necessary values and for ensuring uniqueness. If a Common Formats CDA file is submitted with a ClinicalDocument/id that has been previously submitted, the report shall be rejected, including any resubmissions. CONF-CF-8: A report SHALL contain exactly one ClinicalDocument/id. CONF-CF-9: The value of id/@root SHALL be the Community Pharmacy OID with the.1 branch for document s ID. (Refer to Section 3.2, Use of Object Identifiers, for more information about the specifications for the Community Pharmacy OID). CONF-CF-10: The value of id/@extension SHALL be an alphanumeric case insensitive value up to 16 characters in length for each CDA document within the PSO. (Note: The combination shall be unique.) Figure 13. ClinicalDocument/id Example <! The Community Pharmacy OID here is and the root is a.1 branch--> <id root=" " extension="1001"/> AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 24 of 45

25 ClinicalDocument/code This is a required element within the CDA file. The ClinicalDocument/code shall represent the Report type data element (Data Element ID: DE3) for the report. CONF-CF-11: A report SHALL contain exactly one ClinicalDocument/code where the value SHALL be selected from the Common Formats Report Types Table 7 (CodeSystem AHRQ Common Formats) STATIC. Report Type Patient Safety Incident Report Patient Safety Near Miss Report Patient Safety Concern: Unsafe Condition Report Table 8. Answer Code A3 A6 A9 Community Pharmacy Report Types Answer Value Code System Code System Name Incident: A patient safety event that reached the patient, whether or not the patient was harmed. Near Miss: A patient safety event that did not reach the patient. Unsafe condition: any circumstance that increases the probability of a patient safety event AHRQ Common Formats AHRQ Common Formats AHRQ Common Formats Figure 14. ClinicalDocument/code Example <!--example of a ClinicalDocument/code indicating a Patient Safety Incident Report--> <code code="a3" displayname="incident: A patient safety event that reached the patient, whether or not the patient was harmed." codesystem=" " codesystemname="ahrq Common Formats"/> ClinicalDocument/title This optional element provides the title for the type of report being submitted. CONF-CF-12: A report MAY contain exactly one ClinicalDocument/title element valued with a case-insensitive, text string corresponding to a report type from Table 7 (Community Pharmacy Report Types). Figure 15. ClinicalDocument/title Example <!--example of a ClinicalDocument/title indicating a Patient Safety Incident Report--> <title>patient Safety Incident Report</title> AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 25 of 45

26 ClinicalDocument/effectiveTime The ClinicalDocument/effectiveTime element shall represent the Report Date data element (Data Element ID: DE1103) for the report. CONF-CF-13: CONF-CF-14: CONF-CF-15: A report SHALL contain exactly one ClinicalDocument/effectiveTime. The value of effectivetime/@value SHALL be at least precise to the day (YYYYMMDD). If the Report Date is unknown, the value for effectivetime/@nullflavor SHALL be "UNK" (Unknown). Figure 16. effectivetime Example <!--example of ClinicalDocument/effectiveTime indicating the Initial report date--> <effectivetime value=" "/> Figure 17. effectivetime Unknown Example <!--example of ClinicalDocument/effectiveTime indicating the Report Date--> <effectivetime nullflavor="unk"/> ClinicalDocument/confidentialityCode Confidentiality is a required contextual component of a CDA document, where the value expressed in the header holds true for the entire document. For all reports, "Normal" confidentiality shall be used. (Normal confidentiality means only authorized individuals with medical or business need may access this clinical document.) CONF-CF-16: CONF-CF-17: A report SHALL contain exactly one ClinicalDocument/confidentialityCode. The value for confidentialitycode/@code SHALL be "N" Normal (CodeSystem HL7Confidentiality) STATIC. Figure 18. confidentialitycode Example <!--example of ClinicalDocument/confidentialityCode--> <confidentialitycode code="n" codesystem=" "/> AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 26 of 45

27 ClinicalDocument/setId The setid represents the Event identifier (Data Element ID: DE2) and is a required element of this specification. In combination with the author and the versionnumber element, the setid is used to identify updates to previously submitted reports. The setid shall remain common across all document revisions. CONF-CF-18: CONF-CF-19: CONF-CF-20: CONF-CF-21: A report SHALL contain exactly one ClinicalDocument/setId. The value of setid/@root SHALL be the Community Pharmacy OID with the.13 branch. (Refer to the "Section 3.2 Use of Object Identifiers" for more information about the specifications for the Community Pharmacy OID). The value of setid/@extension SHALL be the event identifier. The event identifier shall be up to 16 characters in length excluding XML control characters (< > &). The value of setid/@root, setid/@extension and author SHALL remain the same as that of the previously submitted report in order to update a previously submitted report. Figure 19. setid Example <!--root is the.13 branch of the Community Pharmacy OID ( )--> <!--extension shall be the event identifier within each provider (author) which shall be constant across all revisions of this report--> <setid root=" " extension="12345"/> ClinicalDocument/versionNumber The versionnumber element represents the version number of a report identified by the setid and author elements. The versionnumber element stores the version number of the document as an integer (the first version is 1; the second is 2, etc.). Each document is a member of a set of documents as determined by the value of the setid and author with the versionnumber indicating where in a series of documents a particular instance is located. The versionnumber is used for updates to a previously submitted report, as explained in section Succession Management. Hence, versionnumber is a required element in this specification. CONF-CF-22: CONF-CF-23: A report SHALL contain exactly one ClinicalDocument/versionNumber. The value of versionnumber/@value SHALL be an integer. Figure 20. versionnumber Example <!--example for ClinicalDocument/versionNumber element --> <versionnumber value="1"/> Header Participants This section describes the Participants (Patient, Provider and the PSO) in the report header. The recordtarget/patientrole/patient/administrativegendercode shall represent the Patient Sex data element (Data Element ID: DE1106 (Patient Sex)) for a report. AHRQ Common Formats for Event Reporting Community Pharmacy Version 1.0 Implementation Guide December 2016 Page 27 of 45