'Accepting FHIR Resource 'Patient' as a RequestBody in spring boot

I want to accept the JSON body of Patient FHIR resource as @RequestBody in Spring boot API. I tried to do this:

@RestController
@RequestMapping("/api")
public class DemoController {

    @PostMapping("/Patient/save")
    public String savePatientDetails(@RequestBody Patient p) {
        IGenericClient client = fhirContext.newRestfulGenericClient("http://localhost:8080/fhir");
        MethodOutcome s = client.create().resource(p).prettyPrint()
                .encodedJson()
                .execute();
        return s.toString();
    }
}

Using the Patient model from HAPI FHIR(https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/Patient.html)

And called the above endpoint using postman with below request body:

{
    "resourceType":"Patient",
    "name": [{
        "use": "official",
        "given": ["temp"],
        "family": "temp"
    }],
    "birthDate": "1996-04-07"
}

but its giving below Jackson deserialization error:

[nio-8081-exec-1] .c.j.MappingJackson2HttpMessageConverter : Failed to evaluate Jackson deserialization for type [[simple type, class org.hl7.fhir.r4.model.Patient]]: com.fasterxml.jackson.databind.JsonMappingException: Conflicting setter definitions for property "referenceElement": org.hl7.fhir.r4.model.Reference#setReferenceElement(1 params) vs org.hl7.fhir.r4.model.Reference#setReferenceElement(1 params)
2022-02-25 09:32:43.332  WARN 71185 --- [nio-8081-exec-1] .c.j.MappingJackson2HttpMessageConverter : Failed to evaluate Jackson deserialization for type [[simple type, class org.hl7.fhir.r4.model.Patient]]: com.fasterxml.jackson.databind.JsonMappingException: Conflicting setter definitions for property "referenceElement": org.hl7.fhir.r4.model.Reference#setReferenceElement(1 params) vs org.hl7.fhir.r4.model.Reference#setReferenceElement(1 params)
2022-02-25 09:32:43.356  WARN 71185 --- [nio-8081-exec-1] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.web.HttpMediaTypeNotSupportedException: Content type 'application/json;charset=UTF-8' not supported]

Thanks in advance.

javaspring-bootjacksonhl7-fhirhapi-fhiralgorithmshortest-pathdijkstra


Solution 1:[1]

One option here is to transform the original graph of flights to directly encode the idea that once you’ve taken a C flight, all future C flights are free.

For each airport x, create two nodes x1 and x2. The idea is that node x1 corresponds to being in airport x without having ever taken a C flight, and x2 corresponds to being in airport x having taken at least one C flight.

Now add edges as follows. For each A or B flight from an airport x to an airport y at price p, add an edge from x1 to y1 at price p and from x2 to y2 at price p. These correspond to taking A and B flights at their established price. Then, for each C flight from an airport x to an airport y at price p, add an edge from x1 to y2 at price p (this is where you pay the one-time cost of using C flights) and from x2 to y2 at price 0 (this flight is free now that you’ve already paid the up-front cost to use C flights).

If you run Dijkstra’s algorithm in this modified graph starting at a node x1, you can find the cheapest flight to an airport y by looking at the costs to get to y1 (not using any C flights) and y2 (using at least one C flight). The paths through the new graph will tell you which flights to take.

This doubles the size of the input graph, which will slightly slow down Dijkstra’s algorithm but won’t asymptotically affect the runtime.

Solution 2:[2]

I think you can keep a flag alongside the costs to each node that indicates you have already used a C flight or not. This flag will dictate whether the next C flight costs you or not.

In other words, instead of setting all the C edges to zero when you use a C edge, keep this local to the state of each tried path.

You could prioritize paths where the flag is set over other paths with equal costs but with an unset flag. This is a heuristic that helps your algorithm find the solution faster, but it would have done so nonetheless eventually.

Now, when you start Dijkstra, paths with C cost included will come forward in the priority queue as soon as a multiple of A or B paths cost at leas as much as a C path that includes a C. From there it's just a standard Dijkstra as far as I understand.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 templatetypedef
Solution 2 user1984

Related Questions