Context Ontology for Healthcare: Teach AI How Patients, Care Teams, Providers and Reports Connect

Patient and Provider Ontology
AI Agents in Healthcare
Quality Reporting AI
Context Ontology Accelerator
AWS Context

With context ontology for healthcare, Mactores gives your AI a governed model of how patients and members, care episodes, care teams, clinicians, provider organizations, networks, health plans and quality measures relate, plus the rules for who may see which PHI. Agents that coordinate care, manage provider data or prepare quality reports consult that model before they answer, so their figures agree with each other and with the reports you file. We build it alongside your clinical, quality and network leads, deploy it in your own AWS account, running on the Context Ontology Accelerator today and on AWS Context when that service launches, and commit to a production date and a fixed fee in writing before any work starts.

Ask an agent how many of your patients with diabetes had their most recent HbA1c below 8% this measurement year. It finds lab results in the EHR, claims from the health plan and attribution in the ACO roster, then returns a number nobody in the quality office recognizes. One reference lab sends the test under a different LOINC code from another. The plan knows the person as a member with a subscriber ID, while the EHR knows a patient with an MRN. Whether that patient belongs to a given clinician's panel depends on which attribution rule you apply. None of those sources is wrong. The agent simply has no model of how they line up, and no quality committee will sign a rate it can't reproduce.

Start with the measure your teams count two ways

Bring both numbers and the agent's answer.

One working session shows where the counts diverge, what a first release would cover and when it could be live.

Book a scoping call

12 weeks: from kickoff to KlearTrust's claims agent working on PHI in production
~80%: of KlearTrust claims now clear inside the agent's defined authority
1st: review passed, for both HIPAA and internal audit, on that same agent
94%: of Mactores engagements delivered on or before the committed date
2008: the year of Mactores' first AWS project

Partner tier: AWS Premier Tier Services Partner
Competency: AWS Healthcare Consulting Competency
Specialization: AWS Agentic AI Specialization

Top Mactores Clients

All 21 case studies →

Customers include Safaricom, Synaptics, Flipboard, Poshmark, Seagate, HP, Adani, DocuSign, KlearTrust, Tilia, Sterne Kessler and Total Expert.

Why Do Healthcare AI Agents Need an Ontology When You Already Have FHIR?

Because FHIR standardizes how health data moves, not what it means inside your organization. Two FHIR feeds can carry one lab result under different codes, describe the same person as a member and a patient, and leave attribution and measure logic to each system. A context ontology records those local meanings and rules, so agents reconcile what FHIR delivers.

FHIR solved a real problem. US Core profiles, the Da Vinci prior authorization guides and the FHIR APIs that payers must stand up under CMS-0057-F by 1 January 2027 put more structured data in more hands than ever before. What FHIR leaves open is the layer where agents stumble. Which identifier wins when an MRN and a member ID point at one person? Which LOINC codes count toward a measure? Which clinician owns a patient under this contract, and which of three addresses is a practitioner’s current one? Semantic interoperability in healthcare begins where the resource format stops.

The appetite for AI in this work is easy to understand, and so is the hesitation. Three findings frame it:

108,478

person-hours one academic hospital spent in a single year reporting on 162 quality metrics, about $5 million in staff cost, according to a study published in JAMA in 2023.
#1

health technology hazard for 2026 in ECRI’s annual list is misuse of AI chatbots, which it warns can give false or misleading information.
6 in 10

physicians in an AMA survey of 1,000, published May 2026, worry that AI may push prior authorization denial rates higher.

Behind each of those numbers sits the same set of failures. These are the ones we meet most often in health systems and plans:

Symptom	Root cause	What the ontology settles
The agent’s quality rate doesn’t match the one you submitted	Measure logic, value sets and exclusions live in vendor engines and analyst spreadsheets the agent can’t read	Each measure as a governed definition, with its value set version and exclusions, owned by the quality office
One person is counted twice, or missed entirely	MRNs, member IDs and subscriber IDs come from separate systems with no agreed matching rule	One person identity, every local identifier attached, and the rule that links them
Care coordination tasks land at the wrong practice	Attribution differs by contract, program and payer, and nobody wrote it down in one place	Attribution rules per program, versioned by date, so the agent knows whose patient this is today
Directory answers send members to clinicians who left the network	Practitioner, location, affiliation and network status update on different schedules in credentialing, contracting and claims	One provider model linking practitioner, role, location and network, each with effective dates
A privacy officer asks why the agent displayed a restricted note	Access was checked in the application screen, not on the data path the agent used	Minimum-necessary policies applied on every query path, with each decision logged

The pressure is rising rather than easing. Payers now publish prior authorization metrics every year, CMS is preparing quality reporting to run on FHIR-based measures, and each new feed adds another place where meaning can split. Agents will be asked these questions whether or not a model exists to answer them properly.

Agent’s rate doesn’t match your report?

Send the measure, the agent’s answer and the figure you filed.

We’ll show where the two part ways.

Request a measure check

What Does a Patient, Care, Provider and Reporting Ontology Contain?

It contains the people, organizations and events your care and reporting depend on: patients and members, encounters and care episodes, care teams, practitioners, provider organizations, networks, plans and quality measures, plus how they connect. Mactores adds identity rules that tie each local ID to one record, and writes attribution, measure and access rules agents check.

Scope comes from the questions your care managers, network staff and quality analysts ask every week. We pick 10 to 20 of them, agree the correct answer for each with the person who owns it, and let that list decide which classes, links and rules the first release needs. The same list later serves as the acceptance test, so nobody has to argue about whether the work is done.

Entity	What the ontology records	Where it lives today
Patient and member	One person across clinical and coverage systems, with demographics, consent flags and every local identifier	MRN in the EHR, member and subscriber IDs in eligibility, the enterprise master patient index
Coverage and plan	Payer, product, line of business, benefit period and eligibility spans	Enrollment feeds, eligibility files, plan configuration
Encounter and care episode	Visits and admissions, and the episode that groups them, such as a pregnancy or a joint replacement	ADT messages, EHR encounters, claim headers
Care team and attribution	Who is accountable for the patient, under which program, and for which dates	ACO rosters, PCP assignment, care management platforms
Practitioner and organization	Clinicians, roles, specialties, locations, affiliations and NPIs	Credentialing, provider data management, NPPES, HR systems
Network and contract	Which practitioner, at which location, belongs to which network on which dates	Contracting tools, claims configuration, provider directories
Clinical fact	Conditions, results, procedures and medications mapped to standard codes	FHIR resources, lab interfaces, claim lines, pharmacy feeds
Quality measure	Denominator, numerator, exclusions, value sets and measurement period	Measure specifications, vendor engines, analyst spreadsheets
Rule and policy	Attribution, consent, minimum-necessary access and reporting rules	Policy manuals, payer contracts, compliance procedures

A first release hands you:

A healthcare context ontology live in your AWS account, scoped to the question set your owners signed
A person identity model linking MRNs, member IDs and subscriber IDs, with matching rules your data governance group approved
Each in-scope quality measure as a governed definition, tested against the rate you last reported
Attribution, consent and access rules expressed as checks, each with a named owner
Terminology mappings from local codes to SNOMED CT, LOINC, RxNorm and ICD-10-CM, versioned by effective date
A bank of questions with known answers that reruns on every change, plus runbooks and trained stewards

Drafted by agents

Candidate classes and links from EHR, claims, eligibility and provider data schemas
Proposed matches between local lab and diagnosis codes and standard terminologies
Draft measure logic read from specifications and your analysts’ SQL
Likely duplicate patients and practitioners, each with a confidence score
A regression run whenever anything changes

Decided by your clinical leads and our FDEs

Which identifier wins when two systems disagree about a person
Whether a reference lab result counts toward a measure
Which attribution rule applies under each contract
Which roles may see behavioral health and other specially protected records
When answers are good enough for care managers to act on

Every Mactores program divides the work this way: agents take the volume, people take the judgment. The accelerator follows the same pattern, and AWS puts its drafting speed-up at months to days. In healthcare, the weeks saved go where they matter, into the sessions where a CMIO, a quality director and a network lead agree on what an attributed patient actually is.

Where Does FHIR End and the Ontology Begin?

Most organizations already run some of these pieces. The ontology is the one that tells an agent how the rest fit together.

Capability	FHIR server	Terminology service	Master patient index	Context ontology
Exchanges standard resources between systems	Yes	No	No	Reads them as a source
Maps local codes to SNOMED CT, LOINC and RxNorm	Carries codings	Yes	No	Uses the mappings and records which ones count for each measure
Resolves one person across systems	No	No	Yes	Links that result to coverage, attribution and care team
Holds attribution, measure and network rules	No	No	No	Yes
Applies minimum-necessary access to each answer	Through scopes	No	No	Yes, on every query path
Connects patient, provider, network and measure in one model	No	No	No	Yes

Got a list of questions your teams keep asking?

We’ll size a first release around them

and agree how each answer gets checked.

Scope my first release

What Can AI Agents in Healthcare Answer Once They Share One Model?

AI agents in healthcare can then answer questions that cross clinical, coverage and provider data: which attributed patients have open care gaps, who needs a call after discharge this week, whether a listed clinician is in network at a location, and where a measure stands mid-year on your submission logic. Care managers and analysts still decide what happens next.

Coordinating care, keeping provider data straight and reporting quality lead the queue. Each one spans many systems, and its mistakes reach patients, clinicians and regulators. Prior authorization and life sciences questions reuse the same model once people, practitioners and codes are settled.

Question agents can answer	Sources involved	What the ontology resolves
Which patients attributed to our ACO left hospital in the last 48 hours with no follow-up visit booked?	ADT feed, EHR scheduling, ACO roster	Which discharge events count, and which clinician owns follow-up under that program
Which patients with diabetes are still open on the glycemic control measure, using this year’s specification and our exclusions?	Lab results, claims, pharmacy, hospice and enrollment data	The measure’s value sets, exclusions and period, held as one governed definition
Is this cardiologist taking new patients at our downtown clinic, and in which of our networks?	Credentialing, contracting, directory, scheduling	Links from practitioner to role, location and network, each with effective dates
Which directory entries haven’t been verified in the last 90 days?	Provider data management, attestation logs, directory	What counts as a verification, set against the No Surprises Act’s 90-day expectation
Which members need a medication review after a new high-risk prescription?	Pharmacy claims, EHR medication lists, care management	RxNorm-based drug classes, and which care team owns each review
How does our readmission rate compare across hospitals on the definition we report?	ADT, claims, facility master data	One governed readmission definition, planned-readmission exclusions included

Most organizations add prior authorization and directory accuracy in the second release, once identities and networks are reliable. Population health dashboards and risk models sit beside this work rather than inside it, and they run on the data foundation our healthcare data platform on AWS practice builds, with PHI controls designed in from the first pipeline.

Which answer does your care team re-check by hand?

Show us the question and where its data comes from.

We’ll map the links it depends on.

Map it with us

How Does a Context Ontology Make a Quality-Reporting Agent Give the Same Answer Every Time?

By resolving every measure question through one governed definition. On the Context Ontology Accelerator, your quality team approves the measure's population, value sets, exclusions and period once, and the agent returns the stored result without calling a language model. AWS says that ontology can later move to AWS Context, announced in June 2026 but not yet released.

Released by AWS as Apache 2.0 open source on 31 July 2026, the accelerator deploys into your own account and uses Amazon Neptune for the graph, Amazon OpenSearch Serverless for search and Amazon Bedrock for models, per the AWS announcement. It ships with no healthcare terminologies or ontologies, and AWS Support doesn't cover it. Before any PHI goes near it, we check each underlying service against AWS's list of HIPAA eligible services and the terms of your business associate addendum.

How Does One Measure Question Resolve?

Take a quality director's question: what is our year-to-date blood pressure control rate for patients with hypertension, by clinic? The accelerator answers on the simplest path that works.

01 Stored definition first. If the measure is a governed metric, the answer comes from the approved logic and the latest refresh, with no language model call and no room to improvise.
02 Graph query second. If the director asks for a cut the definition doesn't cover, such as by attributed clinician, the agent issues SPARQL against a virtual knowledge graph, which queries EHR and claims tables in place.
03 Document search last. If the answer turns on text, such as an exclusion in a measure specification or an attribution clause in a payer contract, an agent searches those documents under the same access policies.

The director gets one rate with a trace that shows which path produced it, which value set version applied and which patients were excluded and why. Ask again tomorrow and the rate is unchanged unless the data moved.

What Happens in Scan, Model and Serve for a Health System or Plan?

01 Scan. Connect the sources the first questions need: EHR reporting tables or a FHIR store such as AWS HealthLake, claims and eligibility, the provider data system, and documents such as measure specifications and network contracts. AI enriches the metadata and flags likely matches.
02 Model. Draft classes and links go to review sessions with clinicians, quality analysts and network staff. What they approve becomes W3C OWL classes, with rules written as SHACL shapes and each class tied to its source table through an R2RML mapping.
03 Serve. Agents call the model over the MCP server that ships with the accelerator, or query its SPARQL endpoint directly. Either way, the same definitions and access checks apply.

Which Healthcare Standards and Terminologies Does the Ontology Build On?

Grounding comes from your own data models and from standards like these, used under the licences your organization holds:

Standard	What it contributes	How we apply it
HL7 FHIR and US Core	Resource definitions for patients, encounters, practitioners and coverage, with an RDF representation	The shape incoming data arrives in; ontology classes map to it rather than replace it
SNOMED CT	Clinical concepts for conditions, findings and procedures, available in OWL form	Grounding for conditions and procedures; US use runs under the UMLS licence, which is granted per person
LOINC	Codes for laboratory tests and clinical observations	Groups the several codes one test can arrive under, so a measure counts it once
RxNorm	Normalized names and identifiers for clinical drugs	Drug classes for medication review and pharmacy questions
ICD-10-CM	Diagnosis codes, revised every fiscal year (FY2027 took effect on 1 October 2026)	Rules check each code against the version in force on the date of service
OMOP Common Data Model	A shared structure for observational research data	Mapping target when life sciences teams run feasibility or real-world evidence questions

Quality reporting is also shifting underneath you. In February 2026, CMS opened public comment on draft FHIR-based digital quality measures for hospital inpatient, hospital outpatient and clinician programs, as it explores moving away from today's eCQMs. A measure defined once in the ontology can feed the current submission now and the FHIR version as it arrives, without a second set of logic to keep in step.

Should Healthcare Teams Wait for AWS Context?

No. AWS plans to offer user-defined ontologies as a managed capability inside AWS Context, and it says ontologies built on the accelerator will move across. As of early November 2026, it had not announced a preview or launch date. The slow part of this work is human: getting quality, network and clinical leaders to agree on what an attributed patient, an active practitioner and a closed gap mean. That agreement transfers intact, and so do the W3C files that record it.

Want the start-now and wait paths side by side?

We'll lay your sources, measures and deadlines against both

in one session.

Compare both paths

What Are the Steps From First Question to a Healthcare Ontology in Production?

Five phases, each closed by a signed exit: pick the questions, connect and match the sources, agree definitions with clinical and quality owners, prove the answers and the access controls, then go live and hand over. Working sessions are booked around reporting deadlines, open enrollment and clinic schedules, because the people who define terms are also the busiest.

Every Mactores program runs on the same delivery model, set out in how we work, and here it bends to the healthcare calendar. Quality teams are stretched before submission windows, network teams before open enrollment, and clinicians can usually give time only in short blocks between sessions, so we plan the definition work around all three.

Phase 01
Pick the questions

What happens

Ten to 20 care, provider and reporting questions are ranked, each with an owner, its sources and a known right answer; the platform and production date are agreed

Owner

Shared

Signed exit

Question set, data use terms and SOW signed
Phase 02
Connect and match

What happens

Agents scan EHR, claims, eligibility and provider data, and person, practitioner and location matches are proposed and reviewed with their data owners

Owner

Agents and FDEs

Signed exit

Identity rules and source map approved
Phase 03
Agree the meaning

What happens

Clinical, quality and network leads settle definitions, measure and attribution rules become checks, and access policies are drafted with your privacy office

Owner

FDEs and your experts

Signed exit

Definitions, rules and access design approved by owners and the privacy officer
Phase 04
Prove it

What happens

Known-answer questions run against rates you have already reported, and every role is tested against the access policies, refusals included

Owner

Agents and FDEs

Signed exit

Known-answer and access tests signed off
Phase 05
Switch over and hand off

What happens

Agents cut over to the ontology one at a time, monitoring switches on, and your stewards take the runbooks after hands-on training

Owner

Shared

Signed exit

Customer-signed acceptance

Go-live gate. Every item must hold before an agent serves real users:

01 Every term in scope has one agreed meaning and a named steward
02 Each person, practitioner and location resolves to a single identity, with exceptions logged
03 Known-answer questions meet the pass mark agreed in phase one
04 Each governed measure reproduces the rate you last submitted, or the difference is explained and signed off
05 Minimum-necessary policies pass role-by-role tests, including refusals for specially protected records
06 Every answer stores its sources, rules, policy decision and ontology version
07 Each AWS service on the data path is confirmed against your business associate addendum
08 The accelerator release is pinned, with an upgrade path written down
09 Budgets and alerts cover graph, search and model spend
10 The runbook and on-call rota belong to your team

At the end of phase one, the fee and the production date are fixed together in the SOW. If Mactores causes a slip, we carry it. If the delay comes from your side, for example a data use approval that stalls or a reviewer who can't attend a phase exit, the extra time is charged at the time-and-materials rate written into that SOW. The complete rules live on our delivery commitment page.

Begin with the question set

Phase one ends with signed questions

and a date your quality team can plan around.

Book phase one

How Are HIPAA, CMS-0057-F and State AI Laws Enforced on Every Agent Answer?

Through rules the agent can’t route around. Minimum-necessary policies sit in the ontology and apply on every query path, prior authorization timeframes and denial-reason requirements run as checks, decisions California reserves for clinicians go to a clinician, and each answer keeps an audit record of the data touched, the rules checked and the policy decision.

Healthcare agents operate under rules a general-purpose model has never read. Gartner predicts that by 2030, half of AI agent deployment failures will come from insufficient runtime enforcement by AI governance platforms. In healthcare, that failure has familiar shapes: PHI shown to the wrong role, a denial issued with no clinician involved, an audit log that can’t say what the agent saw. The fix is enforcement on the data path itself, not a policy document filed beside it.

Access by purpose.

Policies by role, care relationship and purpose of use apply on every path an agent takes, document search included. On the accelerator, Cedar authorization and a SQL firewall do the enforcing, layered with your existing IAM roles and Lake Formation grants.
Decisions reserved for people.

Anything that denies, delays or changes care, from a prior authorization denial to a care plan change, goes to a named clinician with the evidence attached.
Change control on meaning.

Stewards approve every change to a definition or rule, and the known-answer questions rerun before it ships.
Evidence on demand.

Each answer records the data it touched, the rules it checked, the policy decision and the ontology version, which is what auditors and privacy officers ask for first.

Requirement	What it asks	How the ontology enforces it
HIPAA Privacy Rule, minimum necessary	Use and disclose only the PHI a purpose requires	Policies by role, purpose and care relationship on every query path, with documents searched under the same rules
HIPAA Security Rule, audit controls (45 CFR 164.312(b))	Mechanisms that record and examine activity in systems holding ePHI	A log per answer: who asked, through which agent, which records were read and what the policy decided
CMS-0057-F	Prior authorization decisions within 72 hours (expedited) or seven calendar days (standard) since 1 January 2026, a specific reason for each denial, annual public metrics, and FHIR APIs for prior authorization, provider access and payer-to-payer exchange by 1 January 2027, as set out in the CMS fact sheet	Timeframe and denial-reason rules as checks, plus governed metrics that match the public reporting definitions
California SB 1120	Medical necessity decisions made by a licensed physician or qualified health professional, not by an algorithm alone	Agents may recommend; denials and modifications route to a clinician with the supporting evidence
42 CFR Part 2	Stricter confidentiality for substance use disorder treatment records	A separate class for those records, with narrower policies and their own refusal tests
FDA clinical decision support guidance (revised January 2026)	Whether decision support software stays outside device regulation, including whether clinicians can review the basis for a recommendation	Every recommendation carries its sources and rules, so a clinician can check the reasoning independently

Which Questions Can Auditors and Privacy Officers Put to the Ontology?

The question	Where the answer comes from
Which agent read this patient’s record last Tuesday, and why was it allowed?	The access log and the policy decision stored with each answer
Were all expedited prior authorization requests in the third quarter decided within 72 hours?	The governed timeframe metric, by line of business
Which version of the measure specification produced the rate we submitted?	The definition history and stewardship log for that measure
Could a care manager outside the care team have seen substance use treatment notes?	Role-by-role policy tests and the query log
Why did the agent flag this member for outreach?	The trace stored with that answer: inputs, rule results and ontology release

Walk us through one rule your agents must never break

We’ll show where it sits in the model

and how we prove it holds.

Test one of my rules

Which Providers, Payers, Pharma and Medtech Teams Need Healthcare Context First?

Organizations whose agents draw on several systems that describe patients and clinicians differently. Health systems and ACOs start with care coordination and quality measures. Payers start with prior authorization and provider data. Pharma starts with trial feasibility and safety signals, and medtech with complaints and device records. Every first release targets the answer that costs most when wrong.

Health systems and ACOs

Attribution, care gaps and transitions of care drive the first questions. The ontology ties each patient to the clinician and program accountable for them, links ADT events to follow-up tasks, and holds every reported measure as one governed definition, so care managers and the quality office work from the same list. Value-based contracts add payer-specific attribution, which the model keeps side by side rather than overwriting. Clinicians stay in charge of every outreach decision the agents suggest.

Healthcare work at Mactores

Payers and health plans

Prior authorization comes first. Under CMS-0057-F, Medicare Advantage, Medicaid and CHIP plans now decide expedited requests within 72 hours and standard ones within seven days, with a specific reason for every denial. The ontology links the member, plan, requested service, coverage policy version and clinical evidence, so an agent can recommend approval with a citation and send every potential denial to a clinician. KFF counted 52.8 million Medicare Advantage prior authorization decisions in 2024, and 80.7% of appealed denials were overturned, which shows how much rides on the record behind each one. Provider directory accuracy follows on the same model.

See our healthcare practice

Pharma and biotech

Trial feasibility and pharmacovigilance lead. Disease names change, local lab codes vary between sites and one product appears under several names, so counts of eligible patients and safety cases drift from one run to the next. Mapping research data to OMOP, conditions to MONDO and SNOMED CT, and products to the IDMP ontology gives feasibility and safety agents one vocabulary, with aggregate-only access for research roles and a firm wall between safety and commercial teams. AI in life sciences becomes far easier to validate when every count can be traced.

Life sciences at Mactores

Medtech and diagnostics

Complaint handling and device traceability come first. The ontology links each complaint to its device identifier (UDI-DI), firmware version, lot and the reporting rules that may apply, so an agent can group similar events and flag those your regulatory team should review for medical device reporting. Only regulatory and quality staff finalize a report. Service and installed-base questions join in a later release, once device identities hold steady across complaint, service and manufacturing records.

Explore our healthcare and life sciences work

Digital health companies and pharmacy benefit managers usually begin with one of these four patterns, most often the payer one, and the same approach carries over.

How Is a Healthcare Ontology Engagement Priced, and What Does It Cost to Run?

A first release usually lands in 8 to 12 weeks, covering 10 to 20 questions from a few systems. The fee depends on questions, sources and sites, how far patient and provider identities disagree, how many measures and rules need encoding, and how much protected data is in scope. Both fee and date are fixed when phase one ends.

Pricing note. There is no rate card for this work. Effort follows your data: how many systems describe a patient, how many measures you report and how many policies govern access. The accelerator carries no licence fee. The table shows what moves a quote, and your signed SOW holds the binding numbers.

Driver	Why it changes the effort
Questions in the first release	Each brings its own classes, links, rules and tests
Source systems	Several EHR instances, claims platforms and provider data tools mean more mappings
Identity quality	Duplicate patients and practitioners take review sessions with their data owners
Measures and rules	Every measure specification, attribution rule and policy has to be encoded and approved
Terminology work	Local lab and diagnosis codes need mapping to standard code sets, with clinical review
Protected data classes	Behavioral health, substance use and other restricted records need extra policies and refusal tests
Platform	Running the open-source accelerator yourself means hardening, upgrades and on-call planning a managed service would spare you

Run cost. Once live, the monthly AWS bill comes from three things: the graph database, the search index and model calls. The biggest saving is routing: measure questions that resolve to a governed definition never call a model, and they tend to be the questions asked most often. Non-production environments switch off outside working hours, and your finance team sees projected cost per use case before launch.

Want a number for your first release?

Share your questions and systems,

and we'll come back with a single fee and a production date.

Get my fixed quote

Which Terms Matter for Agentic AI in Healthcare?

Context ontology: A governed model of how your organization works that AI consults before answering: the entities involved, the links between them, agreed definitions and the rules in force.
Patient identity: The single record that ties a person's MRNs, member IDs and subscriber IDs together, with the matching rule that justifies each link.
Care episode: A grouping of encounters, services and results around one condition or event, such as a pregnancy, a joint replacement or a hospital stay and its follow-up.
Attribution: The rule that assigns a patient to the clinician, practice or program accountable for their care during a given period.
Provider data management: Keeping practitioner, location, affiliation and network data accurate across credentialing, contracting, claims and the provider directory.
Quality measure: A specification for calculating performance, with a denominator, numerator, exclusions, value sets and a measurement period.
Digital quality measure (dQM): A quality measure built on FHIR data instead of one EHR's internal data model, the direction CMS is exploring for quality reporting.
Value set: The list of codes, from code systems such as LOINC or SNOMED CT, that count as a given concept within a measure or rule.
Minimum necessary: The HIPAA standard that limits each use or disclosure of PHI to what the task at hand requires.
Governed metric: A measure with one approved calculation and a named owner, resolved identically by every report and every agent.
HL7 FHIR: The HL7 standard for exchanging healthcare data as defined resources, such as Patient, Encounter and Practitioner, over web APIs.
SHACL shape: A W3C format for writing conditions that data must meet, such as every prior authorization decision carrying a reason code.
Model Context Protocol (MCP): A common interface that AI agents use to call outside tools and data sources. The ontology is exposed to agents through one.
FDE: A Mactores specialist embedded with your clinical, quality and data teams from scoping to go-live, who runs the definition sessions and is accountable for the production date in the SOW.

How Can Mactores Help You Out?

Wherever your healthcare AI stands, there is a fixed-fee way in. If agents are live but staff re-check their answers, we review those answers first. If you know the questions, we build a first-release ontology. If EHR, claims and provider data still sit apart, the data platform comes first. Each path carries a production date in the contract.

Mactores has built on AWS since 2008, and its healthcare work has always run under an auditor's eye: PHI handled by design, reviews passed on the first attempt, cutovers planned around clinical operations. That history shapes how we model context. Definitions have owners, rules have tests, specially protected records are fenced off before the first query, and nothing goes live in the middle of a reporting deadline.

Where you are	First engagement	What you get
Agents are in use, but care managers or analysts re-check every answer	Healthcare answer review	The gaps behind each wrong answer, ranked, plus a dated first-release scope
Your question list is clear, but reliable answers are not	First-release healthcare ontology	Agents answering from a live ontology, maintained by your own stewards
Clinical, claims and provider data still live apart	Healthcare data platform	A governed data foundation on AWS for the ontology to sit on

This page covers healthcare. Our context ontology services apply the same method across industries and every major platform choice, and healthcare is simply where the rules on data use are strictest. The definitions, identity rules and access policies built for one program become the starting point for the next, so a second release for prior authorization or provider data reuses most of what the first one settled. Teams that begin with quality reporting often find the patient and practitioner work already done when payer questions arrive.

If the agents themselves don't exist yet, our AI agent development services build them against this ontology, under the phase exits and contractual date described above. Many healthcare organizations run both together: the ontology fixes what a patient, a practitioner and a measure mean, and the agents act on that knowledge inside limits your clinicians and privacy office set. The ontology, mappings and rules remain yours, stored as W3C-standard files in your own AWS account and readable by any compatible tool.

Mactores holds AWS Premier Tier Services Partner status, the AWS Healthcare Consulting Competency and the Agentic AI Specialization. Our AWS partnership page lists every credential.

Bring one number your teams argue about

In the first session we find why it splits

and sketch a first release with a likely date.

Book my scoping call

What Do Healthcare Leaders Want to Know About Context Ontology?

What is context ontology for healthcare, in plain terms?

Think of it as the map and rulebook an AI agent reads before it answers a question about your organization. It names patients and members, encounters and care episodes, clinicians, organizations, networks, plans and measures, links them across EHR, claims, eligibility and provider data, and holds the rules for attribution, measures and PHI access. Because agents consult it first, their answers follow the same logic your clinicians and analysts use.

How are AI agents used in healthcare today?

Most agentic AI in healthcare today serves care coordination (who needs a call, which gaps are open), provider data (who is in network, where, and taking new patients), quality reporting (where a measure stands mid-year), prior authorization support and claims review. Agents do the lookup and assembly across systems. People keep the decisions about care, coverage and outreach, and a context ontology keeps the agents' answers consistent.

We already have FHIR APIs and a FHIR data store. Why add an ontology?

FHIR gives you standard resources and a standard way to exchange them. It doesn't decide which identifier is authoritative for a person, which codes count toward your measures, how patients are attributed under each contract or who may see a specially protected record. The ontology records those decisions and applies them, reading FHIR data, including data held in AWS HealthLake, as one of its sources.

Can a quality-reporting agent match the rates we submit?

Yes, if each measure is defined once in the ontology with the same specification, value sets, exclusions and period your submission uses. Before go-live, we run the agent against the rates you last reported and explain or fix every difference. After that, the same question returns the same rate until the underlying data changes, and each answer names the definition version it used.

Has AWS Context launched, and is it worth waiting for?

No. Announced on 17 June 2026, AWS Context still had no preview or general release date in early November 2026. Waiting costs time without saving effort. AWS says ontologies built on the Context Ontology Accelerator will carry into AWS Context, and the hardest part, agreeing definitions across clinical, quality and network teams, has to happen on either platform.

Is the Context Ontology Accelerator HIPAA eligible?

The accelerator is open-source code you deploy, not an AWS service, so it has no HIPAA eligibility status of its own. What matters is the AWS services it runs on and your business associate addendum with AWS. Before PHI enters the system, we confirm each service in the deployment against AWS's HIPAA eligible services list and configure encryption, logging and access to your policies.

Does the accelerator cost anything, and who operates it?

The code carries no licence fee under Apache 2.0, but it is self-managed and sits outside AWS Support. You pay for the AWS services it uses, and someone has to own release pinning, upgrades, monitoring and on-call. Mactores can run it for you under a support agreement or train your platform team to take it over.

Which terminologies can the ontology use, and who licenses them?

Commonly SNOMED CT, LOINC, RxNorm and ICD-10-CM for clinical data, plus OMOP, CDISC and the IDMP ontology for research and product data. Licensing stays with you. In the US, SNOMED CT comes through the UMLS licence, which is granted per individual, LOINC requires its notice, and CDISC and IDMP have membership terms. We set licensing up correctly before mapping starts.

How do you keep PHI and specially protected records out of the wrong answers?

Every class of data in the ontology carries a policy stating which roles, care relationships and purposes may reach it, and the policy runs whether the agent queries tables, walks the graph or searches documents. Substance use treatment records under 42 CFR Part 2, behavioral health notes and other restricted data get stricter policies of their own, and refusal tests prove they hold before go-live. Every answer logs what it touched.

Can an AI agent make prior authorization decisions under CMS-0057-F?

It can prepare them. The agent checks the request against the coverage policy version in force, assembles the clinical evidence, tracks the 72-hour or seven-day clock and drafts a specific reason. Approvals within its authority can move quickly, while any denial or change goes to a licensed clinician, which California's SB 1120 requires and good practice expects everywhere.

How quickly can a first release go live?

Eight to 12 weeks is typical for 10 to 20 questions across a handful of systems in one region or business line. Several EHR instances, many quality measures or a large restricted-data scope add time. We fix the date as phase one closes and put it in the SOW. Each later release, adding questions, sites or measures, gets its own date the same way.

Does this work for life sciences as well as providers and payers?

Yes. Pharma and medtech teams apply the same approach to research and product data: OMOP-mapped patient data for trial feasibility, the IDMP ontology for product identity in safety work, and device identifiers for complaint handling. Research roles get aggregate-only access, and safety data stays separate from commercial teams. A first release usually targets one study type or one product family.

Who owns what you build, and can we run it without Mactores?

Your organization owns all of it. The ontology, mappings, rules, tests and runbooks live in your AWS account and repositories, and the SOW settles IP and exit terms before any work begins. Your stewards are trained to maintain and extend it. Mactores can stay to add measures and sites or to operate the platform, but the system doesn't depend on us.

Question we didn't cover?

Send it with the measure, data or workflow involved,

and an FDE will reply.

Email lets-talk@mactores.com

Which Measure or Prior-Auth Queue Is Your AI Getting Wrong?

Show us. We'll pinpoint what your agents can't see and put a date on the fix.

01
Spend one working session with an FDE on the question, its data sources and the answers you've seen.
02
Within a week, you get our diagnosis, a scoped first release and the production date we'd commit to.
03
Agree the fixed fee in the SOW, and phase one starts.

Fix my healthcare answers lets-talk@mactores.com

A 30-day satisfaction guarantee covers the engagement, and we fix production defects found in the first 90 days after acceptance at no cost.