Lee Surprenant

These Javadoc are generated from the actual spec artifacts. You can see "The actual value" is coming from the definition of this field in the specification (FHIR R4B): ``` {...

I took the easy way out and just had it fall back to our search-based export. I considered opening a new "tech debt" issue for properly supporting fast-export, but after...

I worked with Prasanna to verify this one. We followed the steps from the "To Reproduce" section and we successfully exported some patients to azurite. We execed onto the azurite...

I had the same thought while reviewing. `resources/second` seems the most logical to me.

Hi @Nahuel92 and thank you for the feedback. The `com.ibm.fhir.model.resource`, `com.ibm.fhir.model.type`, and `com.ibm.fhir.model.type.code` packages are generated from the conformance artifacts that are shipped with the FHIR specification. You will see...

Really not sure where that site is getting this line from. I see nothing in fhir-parent/pom.xml (or fhir-client/pom.xml) that would indicate it should have a default scope of "test". https://search.maven.org/artifact/com.ibm.fhir/fhir-client/4.11.1/jar...

This operation seems to assume unit conversion that we don't implement at the moment (e.g. suppose you have body height measurements with some in SI and some in imperial units)....

I thought we had a backlog item for the unit conversion / "canonical unit" search, but I didn't see one and so I've now opened https://github.com/LinuxForHealth/FHIR/issues/3797 and I'm marking this...

Seeing this again: ``` WARNING: Response body: {"resourceType":"OperationOutcome","id":"ac-12-0-4-6e13de61-83fb-429b-8a14-bd53354aa837","issue":[{"severity":"error","code":"not-found","details":{"text":"The requested resource type 'Evidence' is not found"}}]} Exception in thread "pool-2-thread-5" java.lang.AssertionError: expected: but was: at org.testng.AssertJUnit.fail(AssertJUnit.java:65) at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:467) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) at...

After the fix, the test was failing 3 cases and it properly failed the test. After fixing that, it passed again.