Bi-monthly call with NDIIC Joining

Prepared for: SAMHSA – OBHITA Team

Prepared by: Tony CaliceFEI Systems

FEI Systems Inc. Copyright 2009-2010 - All Rights Reserved

Page 3

•Patient Ed MU, Web MD link•PCAST•Update on MU Security Requirements Analysis (Tony)•Update on ONC Webcast (Tony)•(Any other Bi-monthly call topics)

FEI Systems Inc. Copyright 2009-2010 - All Rights Reserved

Agenda

REM Development Timeline

PCAST ReportVision• Universal access• Robust platform for

developers*• Data Exchange• Privacy Protection

on all data• Data Aggregation

Needs• Universal Language• Digital Infrastructure

for locating patients• Unburdening of

government role in the harmonization

Transport Layer

Security Layer

Privacy Layer

Interoperable Layer

Universal Language

* create user interfaces, decision support, storage, and archiving services that will be broadly available to end-users and will not require major capital investments

Interoperable Records

Portable, structured data

3 Aspects of the Interoperable Record

• Transport*• Protocols (such as

HTTPS)• Messages (such as XD*)

• Ontology: Organization of information

• Semantics: Paired understanding of observations

Observation

Patient Record

Observations recorded in Visits*

* “…EHR Modules to be certified for an ambulatory setting, they will need to be designed to enable the user to electronically record, modify, and retrieve a patient’s problem list over multiple encounters.” 45 CFR Part 170

Observations codified from Visits*

Observations

• Problems• Medications• Allergies• Lab Results• Immunizations*• Symptoms*

Vocabulary Standards

• Problems: ICD-9 or SNOMED CT

• Medications: Any source vocabulary that is included in RxNorm

• Allergies: <No endorsement by ONC>

• Lab results: LOINC • Immunizations: CVX for vaccines• Symptoms: SNOMED*• Procedure Codes*: CPT or ICD-9

* Optional/Not required for Stage 1 Certification

Seems clear, where’s the conflict?There are at least 3 ways to organize observations• NIEM• HL7 • ASTM

Observations

Codified ObservationsStructured Data

NIEM

HL7/CDA

ASTM/CCR

Security

Technical Safe Guards

Security Business Driver• Business Drivers

• HIPAA Administrative Safe Guards ~ 45 CFR 164.308 (a)(1)

• HIPAA Safe Harbor• Federal Information Security Management Act (FISMA)

MU Security

• Two Aspects• Accountability

• Identify Users and roles• Audit

• Track: date, time, patient identification, user identification

• When: An “Entity” preforms a Create, Modify, Access, Deleted on a patient record

• Protect Integrity of log as per FIPS 180-3 & FIPS 140-2

• Roles

• Safe Harbor• Ability to encrypt “data at rest” (as per

FIPS 140-2 and Special Bulletin 800-111)

• Required to encrypt any data being exchange (as per FIPS 140-2 Guidance

8 Stage 1 Requirements

1. §170.302(o) - Access control

2. §170.302(p) - Emergency access

3. §170.302(q) - Automatic log-off

4. §170.302(r) - Audit log

5. §170.302(s) - Integrity

6. §170.302(t) - Authentication

7. §170.302 (u) - General Encryption

8. §170.302(v) - Encryption when exchanging electronic health information

2 Technical Safe Guards

Encryption

• Prevents access to record by making contents unreadable

Message Digests “Hash Values”

• One way algorithm that produces a value associated with data (usually at the time it is written to a file or read from a file)

Privacy Preferences

# Element Description1 Program or person permitted to make the disclosure2 name or title of the individual or the name of the organization to which disclosure is to be

made3 Patient Name4 purpose of the disclosure5 What information to be disclosed6 Consent (signature of patient or guardian) 7 date of consent 8 statement that the consent is subject to revocation at any time 9 Consent expiration (date, event or condition upon which the consent will expire)

9 Elements of Consent Needed for 42-CFR Disclosures

Legal Action Center for the Substance Abuse and Mental Health Services Administration. (2010, 6 17). Frequently Asked Questions: Applying the Substance Abuse Confidentiality Regulations to Health Information Exchange (HIE). Retrieved 10 11, 2010, from The Substance Abuse and Mental Health Services Administration : http://www.samhsa.gov/HealthPrivacy/docs/EHR-FAQs.pdf

HIE Consent Models

Opt-Out (non 42 CFR complaint)• In this model, all

patient information is shared with any participant on the HIE unless patients indicate otherise

Opt-Out with exceptions • In this model, all

patient information is shared with any participant on the HIE unless patients indicate otherise

Opt-In • In this model, all patient

information is shared only when patient consent is given

• This requires patient knowledge and explicit authorization to share eBHR with each node on HIE

• Durability of Consent: • Hub and Spoke:

Temporary (one-time authorization) to "Until Death"

• Federated HIE: Temporary to some "reasonable" criteria

Opt-In with exceptions • In this model, some patient

information is shared only when patient consent is given

• This requires patient knowledge and explicit authorization to share eBHR with each node on HIE

• Durability of Consent: • Hub and Spoke:

Temporary (one-time authorization) to "Until Death"

• Federated HIE: Temporary to some "reasonable" criteria

No Sharing• The eBHR

is only shared in an emergency "break the glass" scenario

Restrictive Non - Restrictive

Goldstein, JD, M. M., Rein, MS, A. L., Hughes, JD, P. P., Lappas, JD, J. K., Weinstein, S. A., & Williams, B. (2010, 03 23). CONSUMER CONSENT OPTIONS FOR ELECTRONIC HEALTH INFORMATION EXCHANGE: POLICY CONSIDERATIONS AND ANALYSIS. Retrieved 10 11, 2010, from HealthIT.hhs.gov: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_911197_0_0_18/ChoiceModelFinal032610.pdf

Two Types of HIEs

Hub and Spoke (CDR) Federated HIE