Stanley M. Huff, MD - PowerPoint PPT Presentation

1 / 44
About This Presentation
Title:

Stanley M. Huff, MD

Description:

Dept. of Veterans Affairs. Sue E. Bowman, RHIA, CCS. AHIMA (Staff ... Veterans Administration. Valerie J. Watzlaf, PhD, RHIA, FAHIMA. University of Pittsburgh ... – PowerPoint PPT presentation

Number of Views:151
Avg rating:3.0/5.0
Slides: 45
Provided by: amia
Category:
Tags: huff | stanley | veterans

less

Transcript and Presenter's Notes

Title: Stanley M. Huff, MD


1
Healthcare Terminologies and Classifications An
Action Agenda for the United States
  • Stanley M. Huff, MD

2
Terminologies and Classifications Policy Task
Force
  • Created in December 2005
  • Formed by the AMIA AHIMA Advocacy Committee
  • One face-to-face meeting in March 2006
  • Multiple conference calls
  • Funded in part by a grant from

3
Task force charge
  • Describe the need for a coordinated policy on
    terminologies and classifications
  • Map a high level, near term plan to accelerate
    the rate of adoption of reference terminologies
    and adoption of modern classification systems
  • Outline requirements for ongoing adoption and
    maintenance of terminologies and classifications

4
Joint Task Force Members
  • Margaret A. Skurka, MS, RHIA, CCSIndiana
    University
  • Don E. Detmer, MD, MA AMIA
  • Mary H. Stanfill, RHIA, CCS, CCS-PAHIMA (Staff
    Liaison)
  • Jennifer Hornung Garvin, PhD, RHIA, CPHQ, CCS,
    CTR, FAHIMAVeterans Administration
  • Valerie J. Watzlaf, PhD, RHIA, FAHIMAUniversity
    of Pittsburgh
  • Kathy Giannangelo, RHIA, CCSAHIMA (Staff
    Liaison)
  • Keith E. Campbell, MD, PhD (Chair)Informatics,
    Inc.
  • Suzanne Bakken, RN, DNSc, FAANColumbia
    University
  • Gail Graham, RHIADept. of Veterans Affairs
  • Sue E. Bowman, RHIA, CCSAHIMA (Staff Liaison)
  • Stanley Huff, MDIntermountain Healthcare
  • Linda L. Kloss, MA, RHIA, CAEAHIMA
  • Christopher G. Chute, MD, DrPHMayo Clinic
    College of Medicine

5
Joint Task Force Products
  • Qualifying Statements and Principles for the
    proposed SNOMED Standards Development
    Organization (SNOMED SDO)
  • These principles could be applied to many
    terminology development projects
  • White Paper (just released yesterday)
  • Healthcare Terminologies and Classifications An
    Action Agenda for the United States
  • Download www.ahima.org/perspectives

6
Executive Executive Summary
  • Lots of good things have been done
  • Make sure we continue to fund and support current
    activities
  • Vision of a future state
  • There are some things that we need to work on

7
Recommendations
  • Create a publicly funded R D project to prepare
    specifications for coordinated solutions
  • Create a centralized terminology authority
  • Adopt sound principles of terminology development

8
Good things
  • NLM
  • National license for SNOMED CT
  • Contract support for LOINC
  • Contract with HL7 for use of CHI terminologies
  • Mappings between terminologies
  • SNOMED CT to ICD-9CM
  • LOINC to CPT

9
More good things
  • UMLS Metathesaurus
  • RxNorm
  • RxNorm
  • FDA
  • Improved NDC codes
  • DailyMed

10
DailyMed
Chemical Structure
UNII codes
Therapeutic Intent
Drug Class
Active Ingredient
Clinical Kinetics
Mechanism Of Action
Drug Component
Clinical Drug
Dosage Form
Physiologic Effect
Finished Dosage Form
Indication
Clinical Effects
Drug Product
Packaged (NDC) Drug
11
And yet more good things
  • SNOMED SDO
  • Health Information Technology Standards Panel
  • NCI
  • caBIG, DSR, NCI Metathesaurus, LexBIG, Vocabulary
    services
  • VA
  • NDR-RT, Vocabulary standardization

12
The vision for the future
  • Coordinated creation and adoption of models and
    standard terminologies to support
  • Longitudinal conception to grave EHR
  • Real-time patient specific decision support
  • Sharing of data within and outside of the
    enterprise
  • Clinical and administrative research and analysis
  • Algorithmic assignment of billing and
    classification codes
  • Sharing of decision support logic and protocols
  • Standard, open, modular, application development
    environment

13
Longitudinal conception to grave EHR
  • Comprehensive of all categories of clinical data
  • History, physical, pharmacy, laboratory,
  • All types of data
  • Text, numeric, coded, images, sounds,
  • Retained for 100 years
  • The legal record for all or part of the patients
    data
  • The data will outlive any particular application,
    service, programming language, database, or
    message format

14
Real time, patient specific, decision support
  • Alerts
  • Potassium and digoxin
  • Coagulation clinic
  • Reminders
  • Mammography
  • Immunizations
  • Protocols
  • Ventilator weaning
  • ARDS protocol
  • Prophylactic use of antibiotics in surgery
  • Advising
  • Antibiotic assistant
  • Critiquing
  • Blood ordering
  • Interpretation
  • Blood gas interpretation
  • Management purpose specific aggregation and
    presentation of data
  • DVT management
  • Diabetic report

15
Sharing of data
  • Sharing within the enterprise
  • Between ADT/Registration, LIS, RIS, Labor and
    Delivery
  • Sharing outside the enterprise
  • Adverse event reporting (drugs and devices)
  • Morbidity and mortality reporting
  • Patient safety reporting
  • Quality of care reports - HEDIS measures
  • Regional Health Information Networks
  • Bio-surveillance, infectious disease reports
  • Cancer registries and disease specific
    repositories

16
Data representation
  • Not just terms and codes!
  • Data representation consists of two main parts
  • Information model (expressed as syntax)
  • Semantics (codes and terms)

17
Why do you need a formal model?
Site 1

kg
2.9
Dry Weight
Site 2
kg
2.9

Weight
Wet
Ideal
18
Relational database implications
How would you calculate the desired weight loss
during the hospital stay?
19
Model fragment in XML
  • Pre-coordinated representation
  • ltobservationgt
  • ltcdgtDry weight (LOINC 8340-2) lt/cdgt
  • ltvaluegt2.9 kglt/valuegt
  • lt/observationgt
  • Post-coordinated (compositional) representation
  • ltobservationgt
  • ltcdgtWeight (LOINC 3141-9) lt/cdgt
  • ltqualifiergt
  • ltcdgt Weight type (LOINC 8337-8) lt/cdgt
  • ltvaluegt Dry (SNOMED CT 13880007) lt/valuegt
  • ltqualifiergt
  • ltvaluegt2.9 kglt/valuegt
  • lt/observationgt

20
Administrative research and analysis
  • Automation of coding and abstracting for billing
  • DRG grouping
  • Reporting of quality measures (HEDIS)

21
Definitions
  • Primary use of data
  • Collection, processing, and display of data which
    is specific to an individual person for the
    purpose of providing care and services to that
    person
  • Includes data exchange with other sites for the
    care of the individual
  • Secondary use of data
  • Processing and aggregation of data for uses other
    than direct patient care
  • Use of the data for any purpose other than the
    purpose for which it was initially collected

22
Almost Typical Clinical Data Flow(Primary use
of data)
Interface Engine
23
Chart Abstraction and Coding(Secondary use of
data semi-automated)
24
Future?
Interface Engine
25
Clinical research and analysis
  • Clinical research at Intermountain Healthcare
  • HgbA1c in diabetics
  • Detection of adverse drug events
  • Effects of inducing labor prior to 39 weeks
  • Clinical trials
  • Post-marketing information on drugs and devices
  • Enrollment

26
(No Transcript)
27
  • Rates today (2004-5) at about 270 per year
  • Generates gt1 million per year in net cost
    reductions at LDS Hospital alone

28
(No Transcript)
29
Definitions
  • Terminologies
  • Used to capture complete clinical information
  • Highly detailed, immense granularity
  • Classifications
  • Used to categorize items (instances, cases) into
    groups
  • Used for billing, reporting, analysis

30
Levels of Inference
31
Aggregation Logics
  • The idea is that there could be a set of shared
    public computable rules or algorithms to assign
    classifications or to create inferences
  • Chris Chute

32
Aggregation Logics by domainrule-based
aggregations (Chris Chute)
Decision Support and Error Detection
Public Health and Surveillance
Reimbursement and Management
Outcome Research and Epidemiology
Findings
Interventions
Events
33
Creating a new kind of Healthcare IT market place
  • Separate application development (front end) from
    data persistence (back end)
  • Common detailed models and terminology are shared
    public infrastructure, not market advantage or
    product discriminator
  • Competition is based on making the best
    application and/or providing the best back end

34
Order Entry API (adapted from Harold Solbrig)
Application
Update Medication Order
Interface
Service
Update PharmacyOrder WHERE orderNumber 4674
MUMPS Database
Data
35
Order Entry API Different Client, Same Service
(adapted from Harold Solbrig)
Dept of Defense
Application
Update Medication Order
Interface
Service
Update PharmacyOrder WHERE orderNumber 4674
MUMPS Database
Data
36
Order Entry API Different Server, Same Client
(adapted from Harold Solbrig)
Dept of Defense
Application
Update Medication Order
COS
Interface
Update PharmacyOrder WHERE orderNumber 4674
Service
Cerner Repository
Oracle Tables
Data
37
Order Entry API (adapted from Harold Solbrig)
. . .
Application
Interface
Service
Data
38
What things need to be in place to create a new
market place?
  • Standard set of detailed clinical data models
    coupled with
  • Standard coded terminology
  • Standard APIs (Application Programmer
    Interfaces) for healthcare related services
  • Open sharing of models, coded terms, and APIs

39
Executive Summary
  • Lots of good things have been done
  • Make sure we continue to fund and support current
    activities
  • Vision of a future state
  • There are some things that we need to work on

40
Things that we can work on
  • Fragmented governance, uncoordinated development
  • No standards for the development process
  • Proprietary and complex licensing
  • Complex distribution, especially of updates
  • Uncoordinated release cycles
  • Lack of incentives to cooperate
  • No interoperability across EHR vendors

41
Vision and goals
  • US policy coordinates with other countries
  • UK, Australia, Canada
  • US participates with other countries in
    terminology development
  • There is transparency in the terminology
    development process
  • The terminology development process is open

42
Recommendations
  • Create a publicly funded R D project
  • Prepare specifications for coordinated solutions
  • Plans for consolidating terminologies where
    possible
  • Critical elements licensing, technology, data
    integrity, requirements, maintenance, education,
    conformance
  • Roadmap for change
  • Guide to the public and private sectors
  • Governance model for a central terminology
    authority
  • Develop a governance model for a centralized
    authority
  • Accountable to end users and implementers
  • Consideration of lesson from Australias model

43
Recommendations
  • Create a centralized terminology authority
  • Public and private funding
  • Oversee funding and development of US
    terminologies and classifications
  • Define the governance structure for the US role
    in SNOMED SDO and a national release center
  • Support non proprietary development of standards
  • Identify certification standards and processes
  • Oversee development of implementation guides
  • Adopt sound principles of terminology development
  • Infrastructure and tools for development
  • Transparent processes

44
  • Questions?
  • Funded in part by a grant from
Write a Comment
User Comments (0)
About PowerShow.com