HL7 FHIR Vibe Profiling: when AI enters implementation guide design

Vibe Coding is changing the way many people build software. Instead of writing every line of code, the developer describes what they need, talks it through with an artificial intelligence model, reviews the result, corrects course and repeats. AI stops being an assistant that autocompletes code and starts taking part in design, implementation, documentation and testing decisions.

Something similar is starting to happen in the HL7 FHIR world. We could call it FHIR Vibe Profiling.

The profiler describes a use case and the AI proposes resources. They hand it a form and get a first StructureDefinition. They ask for constraints and receive FSH. They ask for a terminology and get a ValueSet. It can generate examples, FHIRPath invariants, a CapabilityStatement, narrative documentation, diagrams, test cases and even a good part of an implementation guide.

Just a few years ago, producing all of those artifacts took long stretches of specialized work. Today a first draft takes far less time.

The interesting question is no longer whether we will use artificial intelligence to develop implementation guides. The question is how the profiler's work changes when building becomes this easy.

From Vibe Coding to Vibe Profiling

In Vibe Coding the dynamic is fairly simple: describe → generate → run → observe → correct. If the program doesn't compile, a test fails or it doesn't do what was expected, there is an immediate mechanism to find out.

In FHIR profiling we can start in a similar way: describe → generate → validate → correct.

We can ask:

"Create an R5 DiagnosticReport profile for a mammography report."

And we'll probably get something technically reasonable. It may compile perfectly with SUSHI. It may pass the FHIR validator. It may have seemingly sensible cardinalities, terminology bindings, Must Support elements and perfectly valid examples.

And still be completely wrong.

That is the fundamental problem of Vibe Profiling. In software, the fact that something runs correctly at least provides evidence that a certain intent was materialized. In interoperability, a resource being valid only proves that it complies with a set of technical rules.

It doesn't prove that those rules correctly represent the clinical process. It doesn't prove that two organizations interpret the exchange the same way. It doesn't prove that we identified the actors correctly. It doesn't prove that the profile solves the use case.

And it definitely doesn't prove that the guide produces interoperability.

AI knows a great deal about FHIR

Today's models can be surprisingly good at working with FHIR. They explain resources, propose mappings, generate FSH, write FHIRPath, compare modeling alternatives, suggest terminology codes, build example instances and help interpret complex parts of the specification.

That is enormously valuable. An AI can work as a kind of profiler's copilot.

We can use it to explore alternatives:

Is it better to represent this with an Observation or with a component of DiagnosticReport?

To challenge our decisions:

Give me arguments for and against making this element mandatory.

To detect inconsistencies:

Compare these three profiles and tell me whether there are incompatible constraints.

Or for repetitive work:

Generate ten valid examples of this profile covering different patient identification scenarios.

All of this drastically reduces the mechanical effort of profiling. But precisely because generation capacity grows, where the profiler's real value lies also changes.

Knowing FHIR is no longer enough

For a long time, much of a profiler's value came from knowing how to build the artifacts: how to do slicing, define bindings, write invariants, declare extensions, handle references, use FSH or structure a StructureDefinition.

AI is rapidly lowering the cost of that operational knowledge. That doesn't mean it stops being necessary. It means the profiler can spend less and less time writing the artifact and more time deciding which artifact should exist and why.

And that is where an important transformation of the role appears. The profiler of the future will need a much deeper understanding of:

• the use cases;
• the participating actors;
• the transactions between those actors;
• the clinical processes;
• the normal and exceptional scenarios;
• the semantics of the information;
• the obligations of producers and consumers;
• and the consequences each profiling decision has on real implementations.

Paradoxically, the better AI gets at generating FHIR, the more important it will be to understand everything that happens before writing FHIR.

The danger of the plausible profile

Generative models are extraordinarily good at producing plausible results. That can become one of the biggest risks of Vibe Profiling.

Suppose we ask:

"Generate a FHIR profile to exchange medical imaging reports."

The AI will probably find DiagnosticReport. It will add ImagingStudy. Maybe it will include ServiceRequest. It will recommend Observation. It will create cardinalities, flag Must Support elements and add terminologies. Everything will look reasonable.

But who generates the report? Who keeps the images? Who consumes the information? Is there always an order? Can the report exist without accessible images? Does the consumer need to retrieve the study or only the report? Should it receive a narrative representation? Should it be able to reconstruct the document the clinician saw? Are we designing document exchange, access to clinical resources, or both?

If these questions weren't answered first, the AI is doing something dangerous: it is making architecture and interoperability decisions implicitly.

And because the result looks technically correct, those decisions can go unnoticed.

Add to that a more down-to-earth risk: AI can also invent a SNOMED CT code that doesn't exist, propose an R5 element in an R4 profile or cite an extension that was never published. Every generated artifact still needs to be verified against the specification and the real terminology servers.

Compiling is not interoperating

Here lies a fundamental difference between Vibe Coding and Vibe Profiling. In Vibe Coding we can run a program. In FHIR we can validate an instance against a profile. But interoperability only appears when another actor can use that information correctly within a real scenario.

That's why the equivalent of a software test shouldn't only be:

Does the resource validate against the StructureDefinition?

It should also be:

Can actor A carry out the defined interaction with actor B using these artifacts and get the expected result?

The change looks small, but it completely transforms how we should use AI during profiling. The unit of work is no longer the resource. The unit of work becomes the interoperability scenario.

Prompting from the use case

A bad Vibe Profiling pattern would be to start by saying:

"Create a Patient profile for Costa Rica."

The AI will immediately start inventing decisions.

A much more robust approach would be to give it context first:

We have a Patient Registry actor and an Identity Consumer actor. The consumer needs to locate a person using certain national identifiers. These are the identification scenarios, these are the available data sources, these are the rules when there are multiple matches, and these are the transactions used.

And only then ask:

What FHIR constraints follow from these requirements?

The difference is huge. In the first case, the AI is designing the problem. In the second, it is helping us materialize interoperability decisions that were understood beforehand.

This is probably one of the main rules of Vibe Profiling: don't ask the AI to generate profiles first; ask it to understand the scenario first.

AI as a participant at the profiling table

We can also think about artificial intelligence differently: not as the tool that produces the profile, but as an additional participant at the working table.

During a profiling session it could be used to ask:

• Which scenario are we not considering?
• What happens if this data doesn't exist?
• How might a different implementer interpret this rule?
• Does this cardinality really follow from the use case?
• Are we confusing a data element being mandatory with an actor's obligation?
• Is there a contradiction between this example and the narrative text?
• Which FHIR artifacts are involved in this scenario?
• What should a conformance test check?

Questions like these can turn out to be even more valuable than asking it to generate the FSH. AI thus becomes a kind of permanent design reviewer.

It doesn't replace clinical experts, terminologists, architects, implementers or profilers. But it can greatly amplify their ability to explore the decision space.

The profiler goes from builder to director

Vibe Coding is sparking an interesting discussion about the role of the developer. Something similar will happen with profilers.

If an AI can produce a good part of a StructureDefinition, human work shifts toward higher-level activities. The profiler increasingly becomes the director of the modeling process:

• provides context and scopes the problem;
• recognizes when an answer is plausible but wrong;
• knows the standards well enough to challenge the AI;
• reconciles clinical needs with technical capabilities;
• decides when to use an existing resource and when to introduce an extension;
• identifies when the problem can't be solved with profiling;
• and, above all, keeps use case, actors, transactions, requirements and published artifacts consistent with one another.

AI can build very fast. But someone has to know what we are building.

From prompt engineering to context engineering

Vibe Profiling probably won't depend so much on writing "good prompts" either. It will depend on providing good context.

An AI that only has access to the base resource can generate a profile. An AI that also has access to the use cases, the minutes of the technical working groups, architectural decisions, national terminologies, other existing profiles, regulatory requirements, sequence diagrams, real examples, actors, transactions, conformance tests and previous versions of the guide becomes a far more powerful tool.

That's why the future of AI-assisted profiling may not simply be "generating FSH with a chatbot." It will be building environments where the AI has enough context to understand the intent of the implementation guide.

Human in the loop is not optional

In this scenario there is an obvious temptation. If the AI generates the profile, SUSHI compiles it and the validator reports no errors, why not publish it?

Because none of those three actors understands, on its own, the health system we are trying to represent. AI can help us find inconsistencies. SUSHI checks syntax. The validator checks conformance. But deciding that a model correctly represents a clinical, regulatory and operational reality still requires human governance.

This is especially important in health. An error in a traditional application produces a bad user experience. A semantic error in interoperability can spread across multiple organizations and remain for years as part of a national standard.

The ability to generate profiles quickly must come with an equally strong ability to review, challenge and test them.

A possible discipline for Vibe Profiling

We could imagine the process like this:

1. Human: defines the problem and the actors.
2. Human + AI: explore scenarios and requirements.
3. AI: proposes modeling alternatives.
4. Human: selects and justifies decisions.
5. AI: generates profiles, terminology, examples and documentation.
6. Tools: compile and validate the artifacts.
7. AI: reviews inconsistencies across artifacts.
8. Implementers: test the real scenarios.
9. Human: accepts, rejects or modifies the design.

And the cycle starts again.

In other words, Vibe Profiling shouldn't be prompt → profile → publish. It should look much more like:

context → scenarios → requirements → proposal → critique → artifacts → validation → implementation → feedback.

AI takes part in virtually every stage. But it owns none of the decisions.

Profiling will be faster. Thinking will still be hard.

Artificial intelligence will probably let us produce implementation guides much faster in the coming years. Generating examples will no longer be tedious. Writing documentation will be easier. Maintaining derived profiles can be partly automated. Tests can be generated from requirements. Inconsistencies can be detected automatically. We'll be able to explore several modeling alternatives before choosing one.

All of that represents a huge opportunity for small FHIR communities, national projects and organizations that today face a significant barrier of specialized knowledge.

But there is also a paradox. When building the artifacts becomes easy, bad decisions also become easy to implement.

We can generate ten wrong profiles in the time it used to take us to produce one. We can document them perfectly, generate convincing examples and create beautiful diagrams. We can even produce a guide that looks extraordinarily mature. And still have modeled the problem wrong.

That's why the profiler's key knowledge in the age of AI probably won't be remembering every element of every FHIR resource. It will be knowing what to ask. Knowing what information is missing. Knowing when a seemingly correct answer lacks enough context. Knowing how to separate clinical, functional, semantic and technical requirements. Knowing how to understand actors and transactions. And knowing how to turn human decisions into computable contracts that others can implement.

That is FHIR Vibe Profiling

Vibe Profiling isn't about asking an AI to create profiles for us. It's about bringing AI deep into the interoperability design process: to explore, challenge, generate, review, document and test. And, above all, to cut the time we spend on mechanical tasks and increase the time available to understand the problem.

AI may know practically the entire FHIR specification. It can generate a StructureDefinition much faster than we can. It can write FSH, FHIRPath and examples very quickly. But it still needs someone to give it something fundamental: the context of what we are trying to make interoperable.

Perhaps that is the true definition of HL7 FHIR Vibe Profiling:

Let AI accelerate building the guide, without letting it replace the understanding that must exist behind it.

Because in interoperability, generating artifacts was never really the hardest problem. The problem was always getting different systems, organizations and people to understand the same thing.

And no amount of code —generated by humans or by artificial intelligence— can replace that decision.