See one, do one, teach one

Part of graduate medical education (GME) in procedural and surgical specialities is completing a breadth of procedures under supervision with increasing autonomy. In cardiolovascular training programs for example, fellows complete hundreds of reads on echocardiograms and procedures in the cath lab as part of their training. By the time a trainee has completed several hundred of something, they are likely able to handle simple cases themselves and may even be able to teach their juniors the basics.

As part of this culture of graduated responsbility, trainees around the country are expected to maintain a log of their procedures. These logs service several purposes:

  • They help attest that a trainee has received sufficient exposure to be able to practice independently
  • They demonstrate the variety and volume of procedures the training program provides, which is an important factor in the maintenance of a program's accreditation and number of trainees that can be accepted
  • They can serve as a log of interesting cases for case discussion and presentations

Despite its importance, procedure logging is a manual process in most programs and is redundant to clincal documentation. I've long felt that if we consider the clinical record as the source of truth, then the necessary procedural experience data can be extracted from it. If the clinical record is not adequately structured for secondary reporting, then we ought to make it so.

This is the premise upon which I've worked to improve the experience of my cofellows at The University of Chicago Medical Center, and now the trainees at The University of Pennsylvania.

Restructuring clincal documentation for secondary reporting

During my cardiology fellowship training at The University of Chicago, I pursued Epic Physician Builder training. For the project component of this training, I restuctured our post-procedural documentation in the cath lab to capture procedural attribution for fellows.

In the cath lab it's commonplace to write a short note after the procedure that summarizes what was done for the patient. I developed a data model using SmartData that captured procedural metadata for extraction:

For those familiar with Epic documentation tools, I used SmartPhrases and SmartData Elements to model and store this data which were later used for report generation. For those unfamiliar, these are note templating tools that allow data to be stored in a structured format. This structured data can be extracted using Epic Clarity which is their SQL data analytics warehouse.

I later published on this work in the Journal of Graduate Medical Education, a milestone I summarized on Twitter:

This was exciting work but incomplete, as it only addressed the data storage and extraction portion of the problem. Most training programs have trainees maintain portfolios that contain procedure logs in applications such as: MedHub, New Innovations, or the ACGME's Case Log System.

SeeDo: automated transmission of extracted Data

Peep the hair growth in the couple years between

As I finished the end of my cariovascular training and Biomedical Informatics Masters program at The University of Chicago, I decided to pursue Epic certification in Caboodle, Clarity, and Clinical Data Model. This gave me the tools and I needed to extract nearly any structured Epic data for secondary use.

Nearing graduation I was recruited to join the faculty of the Cardiovascular Division at The University of Pennsylvania. I was drawn to PennMedicine because of it's rich history of in-house custom software development within the Center for Health Care Transformation & Innovation. It really is a special place.

When I got here I noticed the same duplication of effort - clinical documentation happening in parallel with administrative educational portfolio documentation in MedHub. This time, I had more tools. I developed a web application called SeeDo (after the medical training addage "see one, do one, teach one") that extracts structured metadata from Clarity about fellow-interpreted echocardiograms. After an opportunity to review this data without complaint, SeeDo pushes this information directly to MedHub using their web API.

Critically, since the source of the information is the trusted clinical record, the fellow and their supervising faculty don't need to do anything if they are in agreement with the extracted data.

The flow of data looks roughly something like this:

For those interested, the stack used is NestJS, Postgres, Prisma, and Databricks as our enterprise data lake. There's currently no frontend but that may change.

What next?

I think our professional societies and EHR vendors ought to make this kind of thing happen for everybody. In the meantime if you are at an Epic institution, especially one that uses Epic Cupid, I'd be more than happy to share with you the Clarity queries that are the foundation for the procedure data extraction. if you'd be interested in having me do it all for you, let me know.