Evidence of Infection (Dialysis) Reporting in CDA and greenCDA: for HAI Implementation Guide r7 May 11, 2012

Kate Hamilton, Lantana Consulting Group Focus on design and implementation of Clinical Document Architecture (CDA) compliant systems: validation, document management, authoring, data conversion, and web services for information exchange. Kate Hamilton Senior Information and Process Analyst Working in IT information management since 1985; focus on implementation success With the HAI CDA project since it began in 2007

Topics Today HL7 CDA and interoperability The Implementation Guide package The IG, sample files, and vocabulary Technical files for validation and display CDA XML The EOID and VAT CDA Reports Header, and body sections The data How to find and read a template Topics for working with CDA Brief look at the EOID Report as greenCDA

A Working Approach There’s a lot in this package Suggestion: All the HAI CDA reports – but you want just two of them Superstructure for interoperability – but you are reporting just to NHSN Suggestion: Look at Table 5 in the IG for an overview of the report type Open the sample file in an XML editor – see where the data goes Look up the templates in the IG – see what variations are allowed

Context

Background: RIM  CDA  HAI IG Model is built in layers from abstract to concrete: Reference Information Model (RIM) Specialized for clinical information and serialized as XML (Clinical Document Architecture / CDA) In an IG, that general model is constrained for a given use case CDA Header and body Header: information about the document, the patient, the facility, the encounter Body: Sections that contain clinical statements (entries) Rules for a report type are set by the IG constraints. Example of a value constraint: CDA observation → Infection Condition Observation [the value] SHALL be selected from ValueSet 2.16.840.1.114222.4.11.3196 NHSNInfectionConditionCode

Implementation Guide (IG) Organization Introductory material including document conventions HAI header, sections, and library of clinical statements The core IG content is a set of templates (patterns) An IG defines an implementation of the CDA model Balloted through HL7 under the Structured Documents Working Group HAI IG covers 12 report types / 23 NHSN forms Template identifiers relate the IG to the XML document instance Table 5 outlines the report types Use templateIds to track from a report type down to its clinical statements EIOD is the numerator report; VAT (vascular access types) is the denominator report.

Sample Files and Other Artifacts Vocabulary Excel file: The value sets and single-value bindings used in the IG Sample report files (XML): One sample file for each report type, briefly commented Display stylesheet (XSLT): Display the narrative blocks in a browser Generate-narrative transform (XSLT): Generate narrative blocks from coded entries Schematron (XSLT) Validate conformance to IG constraints: goes beyond CDA Schema Run it locally, or use CDA Validator www.lantanagroup.com/validator/ For AU Reports, choose HAI IG r6 (six)

The XML Of It: An Observation <observation classCode="OBS" moodCode="EVN" negationInd="true"> <templateId root="2.16.840.1.113883.10.20.5.6.19"/> <code codeSystem="2.16.840.1.113883.5.4" code="ASSERTION"/> <statusCode code="completed"/> <value xsi:type=”CD” codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" code="370388006" displayName="Patient Immunocompromised"/> </observation>

Header Details, Single-Person Reports The document The patient The encounter

Header Details, Single-Person Reports document id recordTarget – the patient author encounter – id, location, date Many other details are possible in a CDA document The HAI implementation guide sets the values for required elements IG Table 3 summarizes the differences between single- person and population-summary headers in HAI CDA

Evidence of Infection (EOID) Report Three sections used in most HAI CDA Reports Risk Factors Details Findings (“drug/bug tests”) Table 5 shows their content in EOID Reports The templateIds link to the template definitions Example: The NHSN protocol – If a positive blood culture was obtained, report antimicrobial resistance results Look up the report-level requirements for EOID in Table 5, and follow the link to the template definition It says – If a positive blood culture was obtained, a Findings section is required.

Vascular Access Type (VAT) Summary Report One encounter, with The location reported on Five Summary Data Observations One of those has a child Observation <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.5.6.69"/> <code codeSystem="2.16.840.1.113883.6.277" codeSystemName="cdcNHSN" code="1851-5" displayName="Number of Patient Days"/> <statusCode code="completed"/> <value xsi:type="PQ" unit="d" value="100"/> </observation>

CDA-Specific Topics Instance identifiers Values Value sets and code systems True/false, nullFlavor, and text alternatives Document succession management Locations that have no unit ID

Instance Identifiers Instance identifiers in CDA documents, such as patient IDs or document IDs that you assign, must be globally unique. In CDA, identifiers have one or two parts: an object identifier (OID) and optionally an extension. They are used to identify many kinds of objects, including facilities, procedures, people, documents, and code systems. HL7 maintains an OID registry at http://www.hl7.org/oid. Once an OID is assigned to an object such as a facility, a vendor, or a terminology manager, a representative of that organization manages the subdivisions of that OID. For example, if a facility is assigned the OID 2.16.840.1.113883.3.117.1, the facility representative might assign subdivisions of that OID as follows: 2.16.840.1.113883.3.117.1.10 staff 2.16.840.1.113883.3.117.1.20 patients Using this example, a patient ID might be <id root="2.16.840.1.113883.3.117.1.20" extension="253"/>

Value Sets and Code Systems A value set is a list of concepts that can be used with a data item. It has an identifier, such as 2.16.840.1.113883.13.13 for the NHSNDrugSusceptibilityFindingCode value set. The value-set identifier documents the set of concepts that can be used with a data item. The vocabulary file hai_voc.xml lists the value sets used in the HAI Implementation Guide, including those used in the EOID Report. Each concept comes from a published code system, such as LOINC, SNOMED CT, RxNorm, or the cdcNHSN code system. Code systems also have identifiers. For example, the codeSystem identifier for result interpretations is 2.16.840.1.113883.5.83 HL7 Observation Interpretation. The vocabulary file hai_voc.xls (or its equivalent ,hai_voc.xml) provides the linkage between the value set and the code system. For a few concepts, such as administrativeGender, the codeSystem is fixed by CDA.

True/false True/false questions Many data recorded by NHSN are answers to true/false questions. Example, “Was the patient admitted?” This is recorded as a negation Indicator. When a negation indicator is required, the HAI template description notes how to use it.

nullFlavors and Text Alternatives No data to record CDA makes a strong distinction between recording a value and recording the reason no value was provided, such as “no information” or “not applicable”. Values commonly used in the HAI IG are UNK -- unknown NI -- no information Text alternatives Most data in the HAI Reports is coded, but sometimes the protocol allows text instead. On a form this is indicated as “Other (specify)”. When a text value is allowed, the template specifies how to record it.

Document Succession Management In the header Every document instance has a unique ID A document instance can be replaced by a later version Useful when doing test submissions To replace a document instance Consider it to be version 1 of a set of versions of that document Assign a unique identifier to the set (Now you have two identifiers – (a) the document instance, (b) the set it belongs to) To record that one document instance is a replacement for another Increment the version number Include a relatedDocument element recording the replaced document’s ID and specifying the relationship of the new version (for HAI, always RPLC = replace)

Document id, setId, versionNumber, relatedDocument <!-- In version 1 --> <!-- Globally unique document ID --> <id root="2.16.840.1.113883.3.117.1.1.5.2” extension=“1234"/> <!-- set ID and version --> <setId root="2.16.840.1.113883.3.117.1.1.5.1.1“ extension=“22d2"/> <versionNumber value="1"/> <!-- In version 2, which is a replacement for version 1 --> <id root="2.16.840.1.113883.3.117.1.1.5.2” extension=“23045”/> <!-- same set ID, new version --> <versionNumber value=“2"/> <!-- relatedDocument --> <relatedDocument typeCode="RPLC"> <parentDocument> <id root="2.16.840.1.113883.3.117.1.1.5.2" extension=“1234"/> <versionNumber value=“1"/> </parentDocument> </relatedDocument>

Locations That Have No Unit ID How to record a location that has no ID <participant typeCode="LOC"> <participantRole classCode="SDLOC"> <!-- the location ID --> <id root="2.16.840.1.113883.3.117.1.1.5.1.1" extension="9W"/> <!-- the location type --> <code codeSystem="2.16.840.1.113883.6.259" code=“1250-0" displayName="All inpatient beds combined"/> <!-- the scoping entity: not required if id is present --> <scopingEntity classCode="PLC"> <id root="2.16.840.1.113883.3.117.1.1.5.1.1"/> </scopingEntity> </participantRole> </participant>

greenEOID and greenSummary The CDA model is Interoperable – all the semantics are in the document instance, nothing assumed or implied Competent – can be used for any clinical document That’s important for the data recipient and the archive The greenCDA approach hides a template’s unused options. Database export as greenCDA Run a transform to fill in the full CDA detail

Thank You! A pleasure to work with implementation Covered a lot of ground today, from overall context down to CDA specifics. There will be questions! Ask now or email: nhsncda@cdc.gov nhsn@cda.gov – vocabulary questions e.g. locations