240 likes | 372 Views
Evidence of Infection (Dialysis) Reporting in CDA and greenCDA:. for HAI Implementation Guide r7 May 11, 2012. Kate Hamilton, Lantana Consulting Group . Lantana Consulting Group
E N D
Evidence of Infection (Dialysis) Reportingin CDA and greenCDA: for HAI Implementation Guide r7 May 11, 2012
Kate Hamilton, Lantana Consulting Group • 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 • 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
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 --> • <!-- Globally unique document ID --> • <id root="2.16.840.1.113883.3.117.1.1.5.2” extension=“23045”/> • <!-- same set ID, new version --> • <setId root="2.16.840.1.113883.3.117.1.1.5.1.1“ extension=“22d2"/> • <versionNumber value=“2"/> • <!-- relatedDocument --> • <relatedDocumenttypeCode="RPLC"> • <parentDocument> • <id root="2.16.840.1.113883.3.117.1.1.5.2" extension=“1234"/> • <setId root="2.16.840.1.113883.3.117.1.1.5.1.1“ extension=“22d2"/> • <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