Transcript System Build ppt

System Build
HIT Toolkit
Health Information
Technology Toolkit
for Physician Offices
Presenter
• Margret Amatayakul
RHIA, CHPS, CPHIT, CPEHR, FHIMSS
President, Margret\A Consulting, LLC
Schaumburg, IL
• Independent consultant, who focuses on achieving value from
electronic health records, HIPAA/HITECH, and health information
exchange. Developer of tools in Toolkit
• Adjunct faculty College of St. Scholastica, Duluth, MN, masters
program in health informatics
• Founder and former executive director Computer-based Patient
Record Institute, associate executive director AHIMA, associate
professor University of Illinois
• Active participant in standards development, former HIMSS BOD,
and co-founder of and faculty for Health IT Certification
2
Stratis Health
● Stratis Health is a nonprofit organization that leads
collaboration and innovation in health care quality
and safety, and serves as a trusted expert in
facilitating improvement for people and communities
● Stratis Health works toward its mission through
initiatives funded by federal and state government
contracts, and community and foundation grants,
including serving as Minnesota’s Medicare Quality
Improvement Organization (QIO)
● Stratis Health operates the Health Information
Technology Services Center for health care
organizations seeking to use health information
technology in support of their clinical transformation
3
Agenda
•
•
•
•
•
•
Understanding system build
System build tasks
Data conversion
Chart conversion
Interfaces
Legal health record
4
Definition of Terms
• Install
– Setting up hardware
– Loading software onto hardware
• Implement
– All activities associated with not only installation but
hardware configuration, workflow and process improvement,
loading tables with your organization’s specifications and
building the system to meet your requirements (“system
build”), testing, training, and support for actual use (i.e., golive)
• Adopt
– The state where intended users actually use the system to
achieve specified, measureable goals
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
5
Understanding System Build
• Configuration of the software to meet internal
policies, workflows, and process requirements
– Also called “software configuration”
• “Configure” = arrange parts in a specific way for a
specific purpose
Mary Smith
Floor
2W
Bed
4
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
6
System Build Tasks
• Master files and tables/data dictionary
build
– Relational database
– Values of variables
– Metadata
– Change control
– Screen layout
– Data entry shortcuts
– Alerting strategies
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
7
Relational Database
Patient File
Med Rec #
Name
Birth date
Street
City, State
Insurance
Insurance
Table
123498
Pam Bell
01121989
123 River
Small, ST
BCBS
Aetna
125678
Jo Smith
10301972
RR 3
Rural, ST
Aetna
BCBS
Paywell
Admission File
Dx Table
Name
Date
Time
Mode
Attending MD
Adm Dx
AMI
Pam Bell
02142008
0900
Ambulance
Dan James, MD
AMI
COPD
Fracture
Variable
Attending MD
Value
Dan James, MD
Provider
NPI
Table
Pat Carson, PA
8876
Dan James, MD
7543
Ted Smith, DO
1264
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
8
Values of Variables
• All computers that use a
relational database to process
data collect values of variables
from tables to form files
• Some of these variable values
will be known to you and
relatively stable, such as the
names and credentials of
providers, nurses, etc.
• Vendors ask that you capture
these values so they can be preloaded into the system master
files and tables – either by the
vendor or through you using a
wizard
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
9
Sources of Data Values
• Data values for system build may come from a variety of sources:
– A database or directory you maintain (data dictionary/metadata)
– Various forms you use (Form and Reports Inventories)
• Data values relative to payer rules, formularies, drug knowledge
are acquired by the vendor from their source (e.g., PBM) or a third
party (e.g., ICD, CPT), with any subscription fees passed to users
• Standard vocabularies recommended for use by the federal
government include:
–
–
–
–
SNOMED
LOINC
RxNorm
UMDNS
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
10
Standard Vocabularies
• SNOMED (SNOMED International)
– Originally developed by College of American Pathologists and now distributed by
International Health Terminology Standards Development Organization, Denmark,
SNOMED is licensed for use in U.S. by National Library of Medicine. It is a
systematically organized computer processable collection of over 0.5 M medical
concepts and 1.5 M semantic relationships covering most areas of clinical
information such as diseases, findings, procedures, microorganisms, and
pharmaceuticals for consistent indexing, storage, retrieval, and aggregation of
clinical data across specialties and sites of care.
• LOINC (Logical Observations Identifiers Names and Codes)
– Developed and maintained by Regenstrief Institute, includes over 41,000 names
of laboratory terms, as well as nursing diagnosis, nursing interventions, outcomes
classification, and patient care data set. Each database record includes six fields
for the unique specification of each identified single test, observation, or
measurement:
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
11
Standard Vocabularies
•
RxNorm
– Provides standard names for clinical drugs (active ingredient + strength +
dose form) and for dose forms as administered to a patient. It provides links
from clinical drugs, both branded and generic, to their active ingredients,
drug components (active ingredient + strength), and related brand names.
NDCs (National Drug Codes) for specific drug products (where there are
often many NDC codes for a single product) are linked to that product in
RxNorm. RxNorm links its names to many of the drug vocabularies
commonly used in pharmacy management and drug interaction software,
including those of First Databank, Micromedex, MediSpan, Gold Standard
Alchemy, and Multum. By providing links between these vocabularies,
RxNorm can mediate messages between systems not using the same
software and vocabulary.
•
Universal Medical Device Naming System (UMDNS)
– A standard international nomenclature and computer coding system for
medical devices used in applications ranging from hospital inventory and
work-order controls to national agency medical device regulatory systems
and from e-commerce and procurement to medical device databases.
UMDNS is maintained by ECRI and contains nearly 7,500 unique medical
device concepts and definitions (preferred terms), along with an
additional 8,000 entry terms to facilitate classifying of biomedical
information
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
12
Metadata
• Data about data
– Describes structured, or
discrete, data element
properties
– Must be kept up-to-date
– Changes must be
documented (“change
control” or configuration
management)
Attending MD
Dan James, MD
Attributes
Original
Name
Attending MD
Table
Physician
DB Name
ATTMD
Synonyms
Admitting Physician
Definition
Member of medical staff who
may admit patients
Reference
Medical Staff Bylaws
Source
Admission Screen
Derivations
None
Valid Values
Alphabetic
Conditionality
Required
Default
None
Lexicon (Standard
Vocabulary)
None
Relationship
None
Access
Any staff
(CDS) Process
Rule
Convert to NPI for billing
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
13
Importance of Metadata
• External reporting:
– Common meaning?
– Common representation?
• All data required to “fire” a rule must be present for a
clinical decision support rule to work correctly
– Changing the definitions of the data or requirements for their entry
puts use of the rule at risk
– Changes to metadata may be admissible in a court of law if there is
a question as to spoliation of evidence
•
A data administrator is often responsible for
maintaining the integrity of a data dictionary;
a database administrator makes the physical
changes in the metadata registry
•
Clinicians should approve all changes to the
data dictionary, especially as they impact
clinical decision support
•
Degree of flexibility an organization has in
managing changes to metadata varies with product
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
14
Example of Need for Change
Control
• A data element may now be required to be entered
(e.g., dose for a drug prescribed), but someone asks
for it to be changed to optional (e.g., so dose would
not always have to be entered).
• The decision to make such a change should be a
thoughtful one, with an appreciation for its impact
– If dose is not recorded by the user, will the system
automatically record a default, or can the user expect a call
from the pharmacy?
– If something goes wrong in the future (e.g., a default dose
was not changed when necessary), will you be able to track
why and when the system change was made if necessary?
– If a future version of the software depends on this data
element to be required and will not work properly as a result,
will you be able to track that it was this change that is the
cause of the problem now?
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
15
Screen Layout
• Some vendors enable screen design changes. Consider making
such changes:
– Only when absolutely necessary
– For an entire group or organization
– Such changes are costly to make and maintain
• Consider size and resolution of display screen
– Not only will some screens not display well on smaller devices used for
mobile professionals,
– But mobile professionals may use a variety of devices
• Consider user familiarity with computers
– Data entry and retrieval must be intuitive
• Instructions must be clear, but not to obstruct power user
• Icons must be able to be quickly understood (without mouse-over delays)
within context
– Navigating multiple screens may result in even a power user getting
lost
• Balance reduction of complexity with need for information density
– Regenstrief Institute has found that once a person begins to use an
EHR, one denser screen is preferred to multiple screens
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
16
Screen Layout Strategies
• Size and resolution of monitor (tablets
vs. notebooks vs. desktops)
• User familiarity with computers
– Balance reduction of complexity
with need for information density
• Sequencing, nesting, spacing,
color, icons, navigation
• Alerting
– Active
– Passive
• Variable Selection
– Balance flexibility with standardization
• Data entry shortcuts
• Templates
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
17
Data Entry Shortcuts
STRUCTURED DATA ENTRY
• “Click” boxes
• Drop down
• Type ahead
------------------• “Smart text” or macros
• Default values
• Cut (copy) and paste
• Drag and drop
• Drawing tools
• Speech commands
• “Click” boxes:
– Check box = multiple options
may be selected
– Radio button = only one choice
can be selected
UNSTRUCTURED DATA ENTRY
• Dictation/speech dictation
• Typing
• Handwriting recognition
ABILITY TO CONVERT
VALUES OF VARIABLES
TO STANDARD NARRATIVE
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
18
Alerting Strategies
• Sounds or messages to
pagers, phone
• “In-basket” functionality
• Color, sound, &/or symbols
and indicators
• Pop-up boxes (active alert)
• Appearance of message or
icon (passive alert)
• Context-sensitive templates
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
19
• Data conversion = permanently replacing data from
one application to another application, such as moving
the clinic’s patient schedule from a PMS to an EHR
• Interface = in comparison, an interface sends data
from one system to another system, where both
systems continue to operate on the data as applicable
• Master file and table build = also in comparison,
allows stable data to be pre-loaded into new system
• Chart conversion = Making (selected) content of
paper charts accessible/usable in EHR
Chart Conversion
Data Conversion
NEW
OLD
Data
Conversion
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
20
Chart Conversion
•
Chart conversion options (largely for ambulatory care)
–
–
–
–
•
Scan vs. abstract
Staff/contractor vs. physician
All of record vs. parts of record
All records vs. active records
Other issues
–
–
–
–
Policy on chart availability after conversion
Closing charts after conversion
File records after conversion vs. warehousing vs. destruction
Legal aspects
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
21
Interface Build
• Start early
– Prior to contracting, identify all interfaces
– Determine if EHR vendor can write all interfaces
• Is a third party interface developer (system integrator)
needed?
• Interface issues:
– Uni-directional or bi-directional
– What data? (all or some)
– Will a portal do as well?
• Need is to view information, not data (e.g., results review)
• Need is to access and use (hospital) applications (e.g.,
enter orders into CPOE)
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
22
Interface vs. Portal
• Interface – data entered into one system is also
sent to another system
• Portal – entranceway to access applications
and perform work at another site to which you
are authorized
Clinic
Hospital
CPOE
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
23
Representative List of
Interfaces
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
24
Legal Health Record
• Subset of all patient-specific data created or
accumulated by a healthcare provider that may be
released to third parties in response to legally
permissible requests
• Basis is Federal Rules of Evidence, where in the
business record is “that information kept in the course
of a regularly conducted business activity.”
• Rules of e-Discovery, however, do not preclude
metadata (including data dictionary definitions and
changes, as well as date/time stamps of user entries
and audit trails identifying what user accessed what
data) from being further requested via court order
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
25
Converting Data to Output for Legal Health
Record
• Will structured data
entry result in:
– Structured data output
for subsequent
processing?
– Print files intended to
represent legal health
record but are not
customary or
interoperable?
– Need to produce a
screen shot for
achieving the legal
health record?
– Reports representing
various needs, including
for auditors, legal health
record, subsequent use?
Copyright © 2005-8, Margret\A Consulting, LLC. Used with permission of author.
26
For More Support
Contact:
Stratis Health
2901 Metro Dr., Suite 400
Bloomington, MN 55425
952-854-3306
1-877-787-2847 (toll free)
www.stratishealth.org
27