It is a key principle of the FHIR RESTful APIs that all resources are versioned. Without this support, no updates to data can ever be safely performed. This is explained in the Managing Resource Contention and Transactional Integrity sections of the FHIR standard. While we recognise that it is not necessary to persist versioned access to historical records, it is important that the latest record version can be ascertained.

David Hay, Product Strategist at Orion Health, has written a blog post on how systems that don’t fully support versions can handle this requirement in a simple and straightforward way.

You are welcome to use your own ODS index (i.e. to find an organisation by name/address etc.). However, you will need to perform an SDS lookup using the ODS code to resolve the FHIR endpoint that represents that ODS code for the purpose of using the Care Connect APIs.

The list of error codes is intended to allow consumer applications to make sense of errors that the human operator could potentially do something about. We recognise there is a cost-benefit trade-off in this space and will look to only introduce error codes (beyond those of the base FHIR specification) when they add sufficient value. For example, a 400 (Bad Request) error code in isolation doesn’t help you determine which input parameters are malformed. Similarly, a 422 (Unprocessable Entity) doesn’t in isolation help you determine which business rule or integrity constraint has caused an operation to fail.

Defining a small number of supplementary error codes to be included in the Operation Outcome entity allows sense to be made of these failing interactions.