Epic Wisdom

What is Epic Wisdom?

Epic Wisdom is Epic's dentistry application. Epic says dental clinics use it to document oral health, plan treatments and manage preventive care, and because Wisdom runs on the same patient record as the rest of Epic, a dentist sees the medical history and a physician can see the dental chart for a shared patient.

That shared record is the main reason organizations move to Wisdom. A standalone dental system holds the dental chart well but keeps medications, allergies and medical problems in another product, often at another organization.

What changes when dental care shares the medical chart?

Dental and medical teams stop working from copies. Two recent academic moves show what organizations expect from the switch.

• Ohio State: The College of Dentistry moved its clinics to the Wisdom module inside the Ohio State University Wexner Medical Center's integrated record, giving medical center and dental providers access to shared patients' records, MyChart access for patients and enhanced tooth charting.
• UT Health San Antonio: The School of Dentistry moved its clinics to Wisdom in December 2024, replacing its previous dental system, axiUm, and combining dental and medical records so dentists and hygienists can review a patient's medical history.
• Patients: Both schools point to MyChart, where patients see medical and dental records, appointments and results in one place.
• Teaching: Ohio State also describes interprofessional learning for students and faculty as a goal of the move.

For a vendor, the shift means the customer's dental data now sits behind Epic's interfaces and governance. A connection that once went straight to a dental practice database now goes through the health system's Epic team, its security review and its release calendar.

Which Wisdom data does Epic expose through FHIR?

Epic on FHIR lists dental-specific R4 resources for reading and searching dental records. They are the starting point for any app that needs structured dental data rather than documents.

• Condition (Dental Finding): Read and search for findings charted in the dental record.
• BodyStructure (Tooth): Read and search for the teeth that findings and procedures refer to.
• ServiceRequest (Dental Procedure): Read and search for planned dental procedures.
• CarePlan (Dental): Read and search for the dental treatment plan.
• RequestGroup (Dental Visit): Read and search for the procedures grouped into a dental visit.

Each of these is listed as read and search, not create. An app that needs to write back into the dental chart has to use a write path the customer enables, such as a document interface, and confirm it in the customer's test environment.

Test with the customer's data, not only the sandbox. Dental findings, procedure codes and visit groupings reflect each customer's Wisdom build, so the fields an app relies on, such as a procedure's tooth and surface, need confirming against realistic records before the design is final.

The general clinical resources still apply. Medications, allergies, problems and lab results come through the standard Epic resources, which is how a dental app checks a medication list before a procedure without a separate medical feed.

What can software do with shared medical and dental data?

Software can put the medical facts a dental team needs in front of them at the moment of care, and send dental findings to the medical teams that act on them. The value comes from the workflow, not from the data alone.

• Pre-procedure review: A chairside app reads the medication list, allergies and problem list for a shared patient before a procedure, instead of relying on a paper health history form.
• Referral loops: A dental finding that needs medical follow-up becomes a referral, and the medical team's response returns to the dental chart.
• Population views: An analytics pipeline groups patients by dental findings and medical problems together, for programs the health system runs across both.
• Patient communication: Dental results and treatment plans appear in the same patient portal the patient already uses for medical care.

Keep clinical judgment with the clinicians. Software can surface a medication list or a finding, but deciding what it means for a procedure stays with the dentist, and any logic that recommends treatment needs the same clinical review a medical decision support tool gets.

How do dental vendors exchange data with Wisdom today?

Most of the documented paths for dental vendors are HL7 v2 document and message interfaces. open.epic lists dental vendors among the current integrations of several of them.

• Provider communications: The Incoming Provider Communications Interface lists DDX Dental among its integrations and routes each letter to the recipient by preference, such as In Basket, fax or mail.
• Scanned documents: The Incoming Scanned Document Link takes HL7 MDM messages that link outside documents to the chart, and lists Dentrix among its integrations.
• Transcriptions: The Incoming Transcriptions interface, originally built to match dictations with their transcriptions, also lists Dentrix.
• Outgoing notes: Outgoing Documentation sends notes as HL7 MDM messages, in RTF or PDF, as they are saved and changed.

Imaging needs its own decision. Dental radiographs, intraoral photos and scans are produced by device software, and the customer decides where images are stored, how they are linked to the visit and which viewer clinicians open. Settle that design with the customer's imaging and Epic teams before writing any code.

Codes, claims and tooth numbers

Dental data follows its own code sets and transaction formats, and an integration has to carry them without loss.

• Dental claims: 45 CFR 162.1102 adopts the ASC X12 837 Dental transaction as the HIPAA standard for dental health care claims.
• Dental codes: 45 CFR 162.1002 names the Code on Dental Procedures and Nomenclature as the HIPAA code set for dental services.
• Business associates: Under 45 CFR 164.502(e), a vendor that handles PHI for a covered dental or medical practice needs a business associate agreement first.
• Security safeguards: 45 CFR 164.312 makes audit controls and unique user identification required for systems that hold ePHI, including a dental app's own store.

Tooth identifiers deserve a mapping table of their own. Dental systems differ in how they number teeth and surfaces, and a finding filed against the wrong tooth is a clinical error, not a cosmetic one. Map every identifier to the BodyStructure records the customer returns and test the edge cases, such as primary teeth and missing teeth.

Procedure codes need the same care. When a dental tool hands visit data to a billing system, carry the procedure code, tooth and surface as discrete fields, never as text inside a note that someone has to read and retype.

Questions to answer before a Wisdom project starts

• Which organization runs Wisdom: A dental school, a health system dental department or a dental group, each with different owners and approval paths.
• Who owns the dental build: The customer's Wisdom analysts own dental workflows, and the interface team owns HL7 v2 feeds.
• Read or write: Reads can use the dental FHIR resources; writes need a path the customer enables and tests.
• Documents or discrete data: A PDF summary in the chart is simpler than structured findings, and less useful for analytics.
• Images: Where they live, how the visit links to them, and which viewer opens them.
• Claims: Whether the vendor touches dental claims at all, and if so which system sends the 837 Dental.
• Students and supervision: In a dental school, which actions need faculty approval and how the app shows it.

Write the answers on one page and ask the customer's sponsor to sign it. That page becomes the scope for the security review, the analysts' build requests and the test plan, and it stops the project from drifting into a second integration halfway through.

Why do dental integrations miss their dates?

They usually miss because the plan assumed a dental practice database instead of an enterprise EHR. The common failure points are predictable once you know where to look.

• Direct database plans: The vendor's old integration read the dental system's tables, and Epic does not offer that.
• Wrong queue: The request goes to the ambulatory team when the dental workflow belongs to the Wisdom analysts.
• Write assumptions: The design files findings through an API that is listed as read and search only.
• Tooth mapping gaps: Identifiers are mapped for adult permanent teeth and fail on pediatric patients.
• Image orphaning: Images are stored without a reliable link to the visit, so clinicians cannot find them from the chart.
• Late security review: The health system's review starts after the build, and the BAA and access model arrive last.

Each of these is cheaper to fix in the scoping call than in testing. A short review of the customer's live dental interfaces and enabled FHIR resources can show which of them apply before any code is written.

How Agnotic can help

Dental tools that worked against a standalone practice system often need new plumbing when the customer moves to Wisdom. Agnotic Technologies builds that plumbing: FHIR apps that read dental findings, tooth records and treatment plans, HL7 MDM feeds for documents and images, and claim pipelines that carry the 837 Dental and its codes without loss.

Agnotic works with the customer's Wisdom and interface analysts from the first scoping call, maps tooth and procedure identifiers per customer, and builds to HIPAA Security Rule safeguards from the start.

Sources

• Epic: Standalone specialties, including Wisdom for dentistry
• open.epic: FHIR interfaces, including dental resources
• open.epic: HL7 v2 clinical interfaces and listed dental integrations
• The Ohio State University College of Dentistry: Epic Wisdom transition
• UT Health San Antonio: School of Dentistry adopts Epic Wisdom
• 45 CFR 162.1102: Standards for health care claims, including dental
• 45 CFR 162.1002: Medical data code sets
• 45 CFR 164.502: Uses and disclosures, including business associates