OpenMRS wiki - https://wiki.openmrs.org/display/projects/OpenMRS+FHIR+Module GitHub - https://github.com/openmrs/openmrs-module-fhir FHIR Specification - http://www.hl7.org/fhir/
FHIR Team: @sashrika @surangak @harsha89 @vaibhavhp
1 Like
Hi @sashrika,
Great work (of course) 
My first comment: for error management - are the error messages that are shown to us returned in the form of operation outcome resources? I think we need to return operation outcome responses with the error data if anything were to fail. For example, If you can’t complete a CREATE because an identifier type is missing etc., then instead of just throwing it, you should return an operation outcome that contains an error message - see the exception handling that happens here: http://jamesagnew.github.io/hapi-fhir/doc_rest_server.html#ExceptionError_Handling
2 Likes
Good work indeed!. Look forward to see the conditional updates works and simple audit mechanism works along with this.
@Suranga for now we throw a UnprocessableEntityException. see https://github.com/openmrs/openmrs-module-fhir/blob/master/api/src/main/java/org/openmrs/module/fhir/api/impl/LocationServiceImpl.java#L134
According to the link you posted, I think that scenario is ok. “e.g. the “validate” operation requires a response of HTTP 422 Unprocessable Entity if the validation fails”. But yes, we have to understand which errors we should throw and which error we should show as operation outcome.
We will discuss this.
@harsha89 thank you , I will focus on error management and conditional updates first.