AOHC 2018 in New Orleans represented a whole different experience for me.
I attended this year’s meeting wearing two hats — conference participant with 25 years of experience as an occupational health physician working for a global Fortune 100 company, and company representative as the new chief product evangelist for Enterprise Health. As such, I was able to evaluate the clinical informatics-related courses and activities I attended from the unique viewpoint of both a user and a health information technology provider — and came away with an appreciation that these two perspectives are more complementary than dissimilar.
A major theme I heard across the clinical informatics-related sessions and the Health Informatics Section meeting is that the OEM community needs to articulate and align on what core requirements are needed in OM EHR software products. Clearly, many OEM physicians are not pleased with what they currently use. In the “OEM-based Electronic Health Records” session, Dr. Kenji Saito cited the 2013 JOEM articlewhich described a national survey of OEM physicians and EHR use with two key points:
67.1% of participants use an EMR for clinical purposes (with or without billing features) and an additional 14.6% for billing purposes only (no clinical);
Only 60% of the total EMR users reported satisfaction with their EMR.
Perhaps ACOEMshould develop a position statement to outline the specific unique needs that should be addressed in EHR software to enable its use across the varied OEM practices landscape — ACOEM’s occupational & environmental medicinecompetencies document details the complexity of practice settings: Clinical OEM Care Focus, OEM Clinical Specialist and OEM Population Management. As Dr. Ismail Nabel pointed out in the “Occmed Informatics: Identifying Clinical Informatics Competencies for the Occupational Medicine Physician” session, OEM should leverage clinical informatics competencies to address the strong need to develop clear, specific OEM requirements for a highly-functioning EHR in OEM practices.
It would seem that the recently-formed Health Informatics Section can and should play a major role in collecting insights and driving consensus from several other ACOEM sections (e.g. Corporate Medicine; Health and Human Performance; Medical Center Occupational Health; Private Practice in OM; and Work Fitness and Disability; etc.) to effectively meet its section’s key objective of “Interfacing with EHR vendors about EHR specifications and the needs of OEM practices”. The section is off to a good start in collecting and presenting various points of view.
In the “OEM-based Electronic Health Records” session sponsored by the Health Informatics section, Dr. Paul Papanek shared his view of “What Does OM need in an EHR?”. In this presentation, he noted three key areas where OM leads the nation compared to other medical specialties:
Assessment of function — work ability
Attention to workplace exposures
Targeted communication with stakeholders outside of the medical team
Further, he outlined six areas of need for OM in an EHR:
Record Industry & Occupation (“I&O”) — connect to NIOSH’s NIOCCS database engine
Record functional/work status — standardized “work note”
Offer secure electronic messaging with other stakeholders
Record “sentinel” job exposures and risk factors
Exchange relevant OH (workplace screening) data with a Personal Health Record (PHR)
Have adjustable firewalls within the EHR for certain OH encounters
In the same session, Dr. Robert McLellan presented “Introducing and Using Occupational Health Data in EHRs”. He highlighted the work involved by NIOSH, ACOEM and several other organizationsto get support for occupational information to be required in all EHRs (non-OM and OM) via the Health Level 7’s (HL7) Work and Health Functional Profile(WHFP) — this profile aligns on “Industry and Occupation” coding with specific requirements that it:
shall be used to manage data for two or more current/recent jobs;
should manage data for hours worked for most recent job; and
may provide, for an EHR used in an OH clinic, the ability to manage information about Personal Protective Equipment used at work.
After Drs. Papanek and McLellan completed their presentations, Dr. Zeke McKinney spoke about “OEM-based EHRs: Applying the Theory”. He discussed the evolution of general standards/certification/requirements for EHRs in non-OM clinical practice settings (by the ONC-Office of the National Coordinator for Health Information Technology) and how this adoption of certified EHRs is incentivized by Centers for Medicare & Medicaid (CMS). He noted organizations that can advocate for OEM-based EHR standards including NIOSH EHR Working Groupand ACOEM Health Informatics Section. Last, he outlined where he felt that many existing EHRs fail to meet OEM needs and theoretical gold standards — some similarities to Dr. Papanek’s earlier comments (e.g. OEM data segregation/firewalls; OEM discrete data capture needs; and OEM reporting needs). NOTE: Many of the EHR shortfalls discussed by Dr. McKinney are already addressed by Enterprise Health’s occupational health IT system.
So, what are my primary takeaways from this year’s AOHC meeting?
Many OEM physician colleagues are not happy with their current EHR products because they fail to meet specific OEM provider needs in various OEM practice settings. There is an opportunity for OEM EHR software companies to collaborate with ACOEM members via the Health Informatics section (and other key ACOEM sections) to work on addressing unique OEM-specific practice needs as outlined by Drs. Papanek, McKinney and others.
I know that Enterprise Health is committed and able to address these challenges. After all, Enterprise Health is the only available OEM-specific EHR that is powered by Certified EHR Technology, includes a certified employee portal with Personal Health Record (PHR) capabilities, and has interoperability in its DNAwith over two decades of experience starting with development of one of the first Health Information Exchanges (HIE) to electronically connect hospitals, doctors and other healthcare providers in a local network to exchange medical information.
So, let’s keep the dialogue going and get to work on defining and aligning on these important requirements for OEM-specific EHRs. We’re doing well; together we can do better.