NHIN HISPC SLHIE Joint Conference NHIN Core Content

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 (Care. Spark) Jamel Sparkes (Care. Spark) Mohammed Pervaiz (Delaware) Omar Bouhaddou (Federal) Marie Swall (Federal) Mike Mc. Coy (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 (NYe. C) Gil Kuperman (NYe. C, Co-Chair) Alex Low (NYe. C, Coordinator) Savithri Devaraj (NYe. C, 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 C 32 Creating the specification / overview of C 32 Specification details (constraints) Explanation of spreadsheet Instructions for implementers Appendices (minimum data set, best practices) • Spreadsheet – Detailed description of C 32, including data elements, terminologies, and optionality

Background • Began with the HITSP ER-EHR Interoperability Specification (IS 04) – Describes emergency response scenarios • IS 04 references several HITSP constructs: – – C 32 (Summary Patient Record Using CCD) C 28 (Emergency Care Summary Document) C 48 (Encounter Document) C 37 (Lab Results Document) • Chose C 32 to define the content of the summary patient record – Includes almost all the content of the other constructs • HL 7 CDA/CCD for document structure

Overview of C 32 • 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 HITSPspecified 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 IS 04 – “…ER-EHR contains at a minimum…” (p 16) • Six modules from C 32 – – – Personal Information module Support (contact info. ) module Allergies/drug sensitivities module Conditions (problem list) module Medications module Information source module

Optionality • C 32 requirements for data elements (“R” “R 2” 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 HITSPspecified 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 C 32) • 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 C 32 • Also includes data elements from C 37 (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 R 2 schema defines exact data formats • Implementers may refer to examples in the NIST site http: //xreg 2. nist. gov/cdavalidation/index. html#downloads. html

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