Jose Antonio Martin shares FHIR agent

Why it matters

Dr. Jose Antonio Martin used an X post on May 26 to show an AI agent built with Claude and a FHIR-native architecture for chronic-disease management. The demonstration described a system that nudges patients toward adherence and behavior change using structured clinical data rather than a standalone chatbot layer. Martin said the design was aimed at non-communicable diseases in low-resource settings, where follow-up and continuity are often hard to sustain. The post offered only a brief public outline, but the components he named map onto established healthcare standards and current vendor tooling around FHIR and clinical agents. ### What exactly did Martin say he built? Jose Antonio Martin said the agent was built with Claude, a FHIR-native architecture and behavioral-change techniques to push chronic patients toward adherence. The public description framed the system as patient-facing outreach tied to electronic health record data structures, not as a freeform assistant operating outside the record. The phrase “FHIR-native” matters because HL7’s FHIR standard defines the core healthcare objects such a system would typically read and write, including Patient, Observation, Condition, CarePlan and Goal resources, along with audit and provenance functions. (x.com) That means an adherence workflow can be attached to standard records instead of custom message tables or isolated app databases. ### Why does a FHIR-native design change how an agent fits into care workflows? (x.com) HL7’s FHIR framework is built around healthcare-specific resources and REST APIs, which is why many developers use it as the integration layer for EHR-connected applications. The practical effect is that an agent can pull medication, diagnosis, encounter or care-plan context from the same data model already used elsewhere in the clinical stack. (build.fhir.org) SMART on FHIR has become a common path for third-party applications to connect to EHRs, and NIH’s FHIR-for-Research materials describe it as a “write once, use everywhere” integration pattern. Martin’s demo appears to sit in that broader pattern: structured data in, bounded workflow action out. That is an inference from the architecture he named, not a claim he explicitly made in the post. (build.fhir.org) ### Where do the patient nudges come from in a system like this? Martin said the agent combines behavioral-change techniques with EHR-native data models. In practice, that suggests the prompts are triggered by clinical state already captured in the record — for example, adherence status, care goals, recent observations or missing follow-up steps — rather than by generic engagement scripts. HL7’s current build documentation also includes a medication-adherence extension in US Core, showing that adherence can be represented in structured form within the FHIR ecosystem. (nih-odss.github.io) That does not prove Martin used that exact resource, but it shows the standard already has a place for adherence-related data elements. ### Why did he emphasize low-resource settings and non-communicable diseases? (x.com) Martin said the design was prioritized for non-communicable diseases in low-resource settings. Chronic conditions such as hypertension or diabetes depend heavily on repeated follow-up, medication-taking and routine behavior change, which makes them a natural fit for lightweight outreach systems that can run on top of existing records. (build.fhir.org) The architecture also fits a broader healthcare pattern in which organizations try to keep automation inside core workflows instead of adding separate tools. Anthropic has been expanding Claude materials for healthcare users, while third-party developers have been publishing FHIR connectors and agent servers aimed at Epic-, Cerner- and FHIR-based environments. ### Is this a product launch or more of an implementation pattern? (x.com) The May 26 post read as a technical demonstration, not a commercial launch. Martin did not announce pricing, customers, regulatory clearance or a named deployment site in the material available publicly. The clearest takeaway is the integration pattern itself: Claude on the model layer, FHIR on the clinical data layer, and patient nudges tied to structured workflow states. (anthropic.com) Developers looking for the next step would need fuller implementation details from Martin’s thread or code artifacts, if he publishes them, and would also need to decide which FHIR resources, consent controls and audit logs govern any live deployment. (x.com)

Key numbers

• Jose Antonio Martin on May 26 shared an AI agent design that uses Claude and a FHIR-native architecture to support chronic-disease adherence.
• HL7’s FHIR standard and Anthropic’s Claude healthcare materials provide the technical backdrop for developers evaluating similar integrations.
• Jose Antonio Martin used an X post on May 26 to show an AI agent built with Claude and a FHIR-native architecture for chronic-disease management.
• The phrase “FHIR-native” matters because HL7’s FHIR standard defines the core healthcare objects such a system would typically read and write, including Patient, Observation, Condition, CarePlan and Goal resources, along with audit and provenance functions.

What happens next

• Jose Antonio Martin used an X post on May 26 to show an AI agent built with Claude and a FHIR-native architecture for chronic-disease management.
• The practical effect is that an agent can pull medication, diagnosis, encounter or care-plan context from the same data model already used elsewhere in the clinical stack.
• Is this a product launch or more of an implementation pattern?

Sources

• x.com
• build.fhir.org
• nih-odss.github.io
• build.fhir.org
• anthropic.com

Quick answers