# Presentation: 215444

## NHIN / HISPC / SLHIE Joint Conference

***NHIN / HISPC / SLHIE Joint Conference***
**NHIN Core Content Specification for Exchange of the Summary Patient Record**
***May 1, 2008***
*Dallas, TX*
**Gil Kuperman**
**Jeff Blair**

## Core Content WG membership

- Matt Weaver (CareSpark)
- Jamel Sparkes (CareSpark)
- Mohammed Pervaiz (Delaware)
- Omar Bouhaddou (Federal)
- Marie Swall (Federal)
- Mike McCoy (Indiana)
- Lonnie Blevins (Indiana)
- Paul Fu (Long Beach)
- Sumit Nagpal (Med Virginia)
- Gerard Filicko (Med Virginia)
- Richard Franck (NCHICA)
- Geoff Lawson (NCHICA)

- Jeff Blair (New Mexico, Co-Chair)
- Dave Perry (New Mexico)
- Dave Handren (New Mexico)
- Ben Stein (NYeC)
- Gil Kuperman (NYeC, Co-Chair)
- Alex Low (NYeC, Coordinator)
- Savithri Devaraj (NYeC, Support)
- Chris Clark (West Virginia)
- Mazhar Shaik (West Virginia)
- Carol Bean (ONC, Liaison)
- Bob Yencha (HITSP, Liaison)
- Virginia Riehl (CCHIT, Liaison)

## Core Services Content Workgroup charter

- Develop a set of NHIE specifications that address the content requirements of the NHIE core services
- Specifications should cover:
- Type of data, including a minimum data set
- Terminologies / value sets
- Rules (optionality, etc.)
- HITSP constructs are the starting point

## Context

- The NHIN Trial Implementations contract calls for the exchange of summary patient records to be demonstrated in September 2008 as part of the base year contract
- This data specification is intended to be used in conjunction with query and retrieval services that will be specified by the NHIN Cooperative’s Technical and Security Services Workgroup

## Intended uses of the specification

- A structured summary patient record that can be used for lookup and retrieval
- Minimum data set for the emergency responder-EHR use case
- Requires HITSP-specified value sets
- Summary patient record for other purposes, for example discharge summaries, referrals, Wounded Warrior Use Case, etc.

## Specification structure

- Narrative document (15 pages):
- Introduction / goals
- Background / rationale for use of C32
- Creating the specification / overview of C32
- Specification details (constraints)
- Explanation of spreadsheet
- Instructions for implementers
- Appendices (minimum data set, best practices)
- Spreadsheet
- Detailed description of C32, including data elements, terminologies, and optionality

## Background

- Began with the HITSP ER-EHR Interoperability Specification (IS04)
- Describes emergency response scenarios
- IS04 references several HITSP constructs:
- C32 (Summary Patient Record Using CCD)
- C28 (Emergency Care Summary Document)
- C48 (Encounter Document)
- C37 (Lab Results Document)
- Chose C32 to define the content of the summary patient record
- Includes almost all the content of the other constructs
- HL7 CDA/CCD for document structure

## Overview of C32

- 17 data modules
- Demographics, language, support, provider, insurance, allergy, condition, medications, pregnancy, information source, comments, advance directive, immunization, vital signs, results, encounter, procedure
- Constraints
- Required/required if known/ optional
- Repeating constraints
- Terminology constraints
- 155 data elements
- 48 data elements with a HITSP-specified value set
- 58 required data elements
- 16 that are both required and have a HITSP-specified value set

## Details of the specification

- Requirements for a minimum data set
- Optionality
- Required value sets

## Minimum data set

- A set of basic requirements sufficient for a clinician responding to a patient in an emergency situation, expressed in a computable format
- Can be used for multiple purposes
- Mentioned in introduction to IS04
- “...ER-EHR contains at a minimum...” (p16)
- Six modules from C32
- Personal Information module
- Support (contact info.) module
- Allergies/drug sensitivities module
- Conditions (problem list) module
- Medications module
- Information source module

## Optionality

- C32 requirements for data elements (“R” “R2” and “O”) remain unchanged

## Requirements for value sets / terminologies

- Compliance with HITSP-designated value sets is required for all data elements within the 6 modules of the minimum data set
- Compliance with HITSP-designated value sets is optional for data elements within the 11 modules that are not part of the minimum data set

## Requirements for value sets (continued)

- When translation is performed to obtain a HITSP-specified code, the original code must be sent too
- E.g., if translate from ICD-9 to SNOMED, send ICD-9 code too
- If HITSP codes are not available, supply local codes along with terminology identifier
- A few differences from HITSP constructs
- Adverse event, problem status, result type (rationale given)
- Requirements for information source module
- Author data element is required
- Must specify individual, system/device and organization
- Discussion:  Semantically processable vs. semantic interoperable – not in scope

## Spreadsheet description

- Modules, sections, and data elements
- Module constraints in module header
- Section headers contain an XPath expression identifying the location of the element within the CDA
- Data element fields
- ID, name, optionality / repeating values, data source, additional constraints (if any from C32)
- For data elements that have a HITSP-specified value set, the “data source” field is a hyperlink to the value set specification
- Value set specification includes name, OID, author, version, base code set
- Each element includes code, code OID, code description
- “Missing” – in CCD implementation guide but not in C32
- Also includes data elements from C37 (lab report document)
- Included because lab results are used in two or more use cases

## Specification spreadsheet

## Instructions for implementers

- CCD Implementation Guide provides templates
- CDA R2 schema defines exact data formats
- Implementers may refer to examples in the NIST site
- http://xreg2.nist.gov/cda-
- validation/index.html#downloads.html

## Slide 18

## Summary

- Have created specification for structured summary patient record
- Intended to be used in conjunction with technical specifications
- Core Content WG now working with Use Case WGs on Use Case specifications
- Will leverage work done to date
- Drafts due 5/31