The Emerging Discipline of Regulatory Informatics
By Sarah Kramer, CMIO, Yuma Regional Medical Center
Then came Stage 2, later modified, and Stage 3. The Physician Quality Reporting System (PQRS) was merged with MU and Value Based Modifier (VBM) via Medicare Access and CHIP Reauthorization Act (MACRA), which enrolled providers in Merit-based Incentive Payment System (MIPS) unless they were part of an Alternative Payment Model (APM) such an Accountable Care Organization (ACO), per the Quality Payment Program (QPP). For the hospitals, traditional core measures began to be transitioned to Inpatient Quality Measures (IQR). We optimize Computerized Provider Order Entry (CPOE) and plan for Electronic Prescribing of Controlled Substances (EPCS). To improve adherence with radiology utilization, we implement Appropriate Use Criteria (AUC) decision support software.
Webinars are attended and we learn about proposed rules and how to comment on them before they were finalized. It became an inside joke that we were in charge of complying with an “alphabet soup” of regulations and informatics initiatives. Over time, the role of the project manager changed. We struggled with titles. It became more of a program than a project. It involved quality measures, but was not “Quality.” Established project management requires skills such as Agile because of a baseline need, but since so much of the troubleshooting and dependencies depended upon the Office of the National Coordinator (ONC) “certified” Electronic Health Record (EHR), a generic Project Management Professional (PMP)-certified project manager would no longer do. There appeared to be a new sort of discipline that required a thorough understanding of the capabilities and build options of the incumbent EHR, but also the ability to interpret, guide, document and audit how the EHR had been deployed.
The main differentiator between a health system Regulatory Informatics manager compared to its pharmaceutical cousin, is the client-facing aspect
A few months ago, in an effort to clarify but also generalize the title of our project manager position, we settled on “Regulatory Informatics”.
If there are other titles and descriptors out there that are superior, it’s time to get these into circulation. The closest thing I could find is “Regulatory Information Management” that is used by the pharmaceutical industry. This has different roots and structure than the program management needed by informatics teams, yet has important similarities. One is the assumption that regulatory requirements are not going away. The other is its emphasis on documenting decision, interpretations of applicable law, and archiving documentation for future audits.
The main differentiator between a health system Regulatory Informatics manager compared to its pharmaceutical cousin, is the client-facing aspect. Like many health systems, we support a number of different customers, including independent practitioners, practice managers, hospital quality, and compliance teams, etc. Each of these audiences requires role-specific guidance presented in a concise, trustworthy form. They are all busy and rely on the Regulatory Informatics lead to give them what they need to know, on their timelines. There are also government representatives or proxies that will need clarification of reports, mostly with regard to how patients were included or excluded from various measures.
Core skills for this role seem to include the following:
1. Translational communication: being able to take arcane information and synthesize it into written, visual, and spoken media depending on the needs of the audience. Good listening skills are often a must, since the various constituents often use very different words in their requests.
2. Project and program management skills, including the ability to decipher upcoming regulatory needs and use this to forecast capital and operating budgets, skills composition and hours needed for execution of any software configuration needed.
3. A strong technical background is critical. Regulatory Informatics is a discipline that demands understanding of interoperability standards, including application programming interfaces (APIs), HL7, LOINC, SNOMED, etc. It typically requires technical coordination with state and federal agencies, testing of data file uploads, and cooperative arrangements with other health systems to test information exchanges. The most successful individuals I’ve recruited to such a role had application certification from our EHR vendor, Epic.
Although legal and compliance training may be of benefit, it may also be a stumbling block, so as to avoid the temptation of absorbing too much interpretive power into this role. It is operational leaders who should maintain final decisional authority as to how to respond to and comply with regulatory demands of the EHR.
The breadth and pace of regulatory change is not likely to go away, and interoperability, transparency and utilization management are integral to our ability to afford to deliver interventional and preventive health care to our aging yet tech-savvy population. We need capable individuals acting as aggregators and leaders of these efforts. We might as well give it a name.