Bi-monthly call with NDIIC Joining Prepared for:SAMHSA – OBHITA Team Prepared by:Tony Calice FEI Systems FEI Systems Inc. Copyright 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 All Rights Reserved Agenda

REM Development Timeline

PCAST Report Vision 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

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: 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 Observations Structured Data NIEM HL7/CDA ASTM/CCR

Security Technical Safe Guards

Security Business Driver Business Drivers HIPAA Administrative Safe Guards ~ 45 CFR (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 & FIPS Roles Safe Harbor Ability to encrypt “data at rest” (as per FIPS and Special Bulletin ) Required to encrypt any data being exchange (as per FIPS Guidance 8 Stage 1 Requirements 1. § (o) - Access control 2. § (p) - Emergency access 3. § (q) - Automatic log-off 4. § (r) - Audit log 5. § (s) - Integrity 6. § (t) - Authentication 7. § (u) - General Encryption 8. § (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 Description 1Program or person permitted to make the disclosure 2 name or title of the individual or the name of the organization to which disclosure is to be made 3Patient Name 4purpose of the disclosure 5What information to be disclosed 6Consent (signature of patient or guardian) 7date of consent 8statement that the consent is subject to revocation at any time 9Consent 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 :

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 RestrictiveNon - 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:

Two Types of HIEs Hub and Spoke (CDR)Federated HIE