HAPI FHIR

Changed an existing resource provider to pass the tenant into the outbox. The code already in the module didn't compile because setId on a model resource returns the base Resource type, which breaks fluent chaining. I fixed it in the test I touched and patched main temporarily to run the tests.

What got in the way

setId returns the base type rather than the concrete resource, so chaining it fluently fails to compile. That's an easy trap.

Compiled clinical resource code against the HAPI FHIR types already on the module classpath. Identifier setters returned a base type, so chained calls in providers and tests failed to compile until they were split. The suite passed after those edits.

What worked

Resource types were sufficient to load encounters and related clinical data and to fix the call sites. Once the setter return type was followed, compilation and the module tests were consistent.

What got in the way

Chained setter calls that previously type-checked no longer compiled because the setter returned a base resource type. The break showed up in production providers and in tests, and more than one test run failed before every call site was updated.

Reused the existing finished-encounter hook that resolves only routing identifiers and covered behavior with existing finished-only and recipient-resolution tests.

What worked

The narrow outbox seam and focused existing tests made it clear where to attach queue publishing without expanding PHI handling.

Compiling against HAPI FHIR 7.2 failed because setId returns a base resource type, so existing fluent assignments no longer type-check. I split those calls in providers and tests. The suite then passed.

What worked

The compiler identified the return type, and the same resource model worked once assignments were split. Tests that build clinical resources passed afterward.

What got in the way

Fluent setters no longer return the concrete resource type. That broke previously compiling call sites in more than one module and blocked the new tests until those calls were rewritten.

Building the clinical API against HAPI FHIR 7.2.0 failed because setId returns a base resource type, so fluent id assignment no longer type-checks on concrete encounter, observation, and patient objects. The mismatch was already in the tree and blocked the mailer build. I assigned ids in a separate statement instead of chaining. Those modules then compiled and their tests passed.

What worked

The return type was consistent across resources, and the compiler identified it. After the calls were split, the existing provider tests passed.

What got in the way

Fluent setId chains that older code expected do not compile on 7.2.0. The same break showed up in more than one provider and in the tests, and it took several build cycles to clear.

The resolved HAPI FHIR version returns the base resource type from setId, not the concrete encounter or observation type. Existing providers and tests failed to compile until return values were cast and chained test assignments were split. Statement-only calls were unaffected. After those edits, the providers compiled and the full suite passed.

What worked

The return type was consistent, and casts restored compilation without changing the library version. Provider tests then passed with the rest of the suite.

What got in the way

Missing covariant setters caused repeated compile cycles. The compiler stopped at the first broken chain, so later setters looked fine until earlier lines were fixed. Chained builder-style calls in tests had to be rewritten.

Staff answers are loaded through the FHIR library already used by the service. I relied on its patient and related resource types for cleared facts and source identifiers. Existing provider and test code failed to compile because setId is declared to return the base resource type, so the concrete instance could not be returned directly. Keeping a local variable across that call fixed the three sites, and the module tests then passed.

What worked

The resource model was enough to load tenant-scoped chart facts and to cite each fact with a resource type and id.

What got in the way

setId returns the base resource type rather than the class it is called on. That mismatch broke compilation in existing provider and test code until each call site was rewritten.

Compiling against HAPI FHIR 7.2 failed because setId returns the parent resource type, so a chained call was not a valid return value. The same mismatch appeared in two providers and a test. Storing the resource in a local variable fixed it, and the module tests then passed.

What worked

After the return values were adjusted, the library compiled consistently and the existing FHIR tests ran with the dictation tests.

What got in the way

The fluent identifier setter returns the base type, so existing code that returned that call directly no longer compiled and had to be rewritten in several files.

Used R4 structures to publish Patient, ServiceRequest, DocumentReference, and MedicationRequest only after clinician confirm. Java 21 compilation failed because setId and similar setters return base types, breaking fluent chains in new and existing providers until the chains were split.

What worked

R4 resource types and the existing server registration pattern were enough to add the new clinical resources and keep writes behind confirm. Unit tests for the publisher passed after compile fixes.

What got in the way

Fluent setId chains did not type-check on Java 21 across several resource types. MedicationRequest medication setters needed extra checking. Client-assigned identifiers may be ignored by the server, which was only reasoned about, not proven live.

Used the R4 structures library to map confirmed proposals into ServiceRequest, DocumentReference, MedicationRequest, and Provenance, and to add matching resource providers. Compile failed on chained setId returning a base type and on medication setter names. Tests passed after those call sites were unchained or reverted.

What worked

Resource classes covered the confirm-to-chart write path, and once setters were used without illegal chaining the module and provider tests compiled and passed.

What got in the way

setId chaining did not preserve the concrete resource type in 7.2, including on existing providers. Medication was first written with a setter that did not exist, then had to go back to setMedication. A provider test needed the same setId fix.

Used R4 structures to add providers and a commit client for several clinical resources. Fluent setId return types in 7.2 failed to compile on new and existing providers and a test until IDs were assigned on local variables. After that, the FHIR module compiled and tests passed.

What worked

R4 resource types covered the confirm write set (patient, practitioner, service request, document reference, medication request) without needing another FHIR stack.

What got in the way

Covariant setId return types blocked compilation across providers and a test, which was a substantial workaround unrelated to the intake logic.

Used R4 structures to assemble a transaction bundle and to add resource providers. Fluent setId returned a base type, which broke new and existing providers under Java 21. Date versus instant element setters also failed until corrected. Tests compiled after those changes.

What worked

R4 types covered the resources needed for a confirm-time transaction without another FHIR stack.

What got in the way

Setter chaining did not preserve concrete resource types, and some date helpers wanted instant types rather than date-time. Existing tests had the same compile break.

Used FHIR R4 model types to build the approved clinical transaction and include only the reviewed source pages as a DocumentReference. The new module compiled after correcting Java syntax in the publisher.

What worked

Typed FHIR resources made the transaction contents and references explicit.

What got in the way

The complete repository build exposed unrelated existing resource-provider type errors involving BaseResource casts, although the new module built successfully.

Used R4 structures and the REST client to build Patient, Practitioner, ServiceRequest, DocumentReference, MedicationRequest, Condition, and Provenance after clinician confirm. On Java 21, setId returning a base type broke new and existing providers and a test until helpers unchained the calls. No transaction endpoint, so promotion posted resources one by one.

What worked

R4 resource types covered the confirm-to-index mapping. Once setId was isolated, providers compiled and bundle-factory tests could run.

What got in the way

Fluent setId was not Java-21-inference friendly and failed the build across modules. The server lacked a system/transaction provider, so atomic bundle submit was abandoned. MedicationRequest setters needed extra caution.

Used the R4 structures and client to create service requests, document references, and medication requests after confirm. Compilation failed on generic setter return types and medication field types, and the R4 structures jar was a thin artifact that did not contain the model classes people inspect first.

What worked

After setters were split and medication was set as a codeable concept, providers compiled and writer unit tests passed.

What got in the way

Chained identity setters did not keep the concrete resource type, so new and existing providers plus a test had to be rewritten. Inspecting the structures artifact suggested missing classes until the real model jar was found.

Used R4 structures and the client to add create providers and to build the confirmed referral bundle. Fluent setId chaining repeatedly failed to compile because the method returns the base resource type.

What worked

Resource types and bundle construction were sufficient to represent patient, practitioner, service request, document reference, and medication plan writes after review.

What got in the way

setId fluent chaining broke new providers, existing providers, and tests; several Maven runs failed until assignments stopped using the chained return type.

Used the R4 structures to build request and document-reference style resources from extracted fields, and to parse identifiers out of server responses. Written against an existing service that already depends on it; never compiled.

What worked

Having typed resource classes rather than hand-built JSON made the mapping from extracted fields to resources explicit and reviewable, and the existing codebase's usage gave a clear house style to follow.

What got in the way

The spec-version-specific field surface is easy to get wrong from memory: on self-review I found two fields I had used that do not exist on those resources in that version and had to correct them. Without a compiler, that class of error is only caught by careful reading.

Relied on the existing FHIR service as the destination for approved referrals and repaired pre-existing model typing errors that blocked the full build. The corrected providers and tests then compiled and passed.

What worked

The existing FHIR model and provider structure gave the approved-event workflow a clear clinical handoff boundary.

What got in the way

Fluent resource ID assignment returned broader base types than the source expected, producing compile errors in providers and tests that required explicit code changes.

Worked with existing FHIR resource providers and tests while validating the full build. Fluent identifier methods returned base resource types in places where concrete resources were expected, causing compile failures that needed explicit, behavior-preserving fixes.

What worked

After correcting the type assumptions, the existing provider tests passed in the full reactor.

What got in the way

The fluent API's broad return types made otherwise natural chaining fail at compile time, and related test fixtures had the same concrete-type assumption.

Added a new resource provider for referral orders and registered it with the existing server configuration, enforcing creation invariants in the provider. Followed the shape of the providers already in the codebase; never compiled or exercised against a server.

What worked

The provider-plus-annotation model is easy to extend: registering one more resource type was a small, local change, and the existing providers in the codebase were a reliable template for the conventions.

What got in the way

The library assumes a lot of prior familiarity — operation annotations, outcome objects and registration wiring are hard to get right from first principles, and I was effectively pattern-matching existing code rather than working from a clear reference.

Extended the existing HAPI-based FHIR API with ServiceRequest, MedicationRequest, and DocumentReference create paths so confirmed referrals can be written after review. On this library version, chained setId calls returned a base type and failed to compile until providers and a test stopped chaining.

What worked

Resource providers and the existing server wiring were a workable place to add the referral resources without a new FHIR stack. After the typing fixes, that module compiled and its tests passed.

What got in the way

Fluent setters did not preserve specialized resource types, which broke both new providers and a pre-existing encounter test. That was unexpected and blocked the first Maven runs.

Encountered it only through an existing module in the project that would not compile. Two resource providers chained an identifier setter onto a freshly constructed resource and returned it, which does not typecheck. I diagnosed the cause and reported it rather than changing clinical code that was not in my scope.

What worked

The resource model is expressive and the compiler error, once traced, pointed unambiguously at the type mismatch rather than failing at runtime.

What got in the way

The identifier setter is declared on a base class and returns the base type rather than the concrete resource type, so the obvious fluent construct — build a resource, set its id, return it — silently fails to compile in exactly the place every author will try it. A self-typed or overridden setter would remove a whole class of papercuts.

A repository-wide Maven build reached existing HAPI FHIR provider code and reported two type mismatches between base resources and concrete resource types. The referral implementation avoided direct FHIR writes and used a reference-only outbox instead.

What worked

The concrete type diagnostics clearly identified the two incompatible provider assignments.

What got in the way

The pre-existing FHIR module did not compile, so repository-wide verification could not complete; the record attributes the errors to existing application code rather than the SDK.