The IBM FHIR Server stores resources in the PostgreSQL database and uses a relational model to store historical FHIR Resource and enable search on the latest FHIR resources. The resource data is spread in a relational model that is occasionally tweaked in order to improve search or optimize the retrieval using the relational model. This article outlines debugging with VACUUM on Postgres.
Docker: ibmcom/ibm-fhir-schematool supports onboarding and offboarding of a schema in support of the IBM FHIR Server. I am working on a project that runs on OpenShift using CodeReadyContainers, and I needed to test the image with a restricted policy.
The IBM FHIR Server has support for extended operations beyond the standard C-R-U-D. The Extended Operations are supported at the System, Resource, and Instance levels. Operations are packaged as JAR files, and the IBM FHIR Server loads the specific Operation using the Java ServiceLoader framework at startup. This document outlines how to add a custom extended operation to the IBM FHIR Server.
The IBM FHIR Server supports many different persistence stores – Apache Derby, Postgres, and IBM Db2. The IBM Db2 offering includes a multi-tenancy feature with row-level permissions. Each tenant is assigned a unique internal id for the tenantName and tenantKey. The tenantKey on each JDBC connection is verified using a one-way hash, and supports `allocating` a tenant, `adding` a key to an existing tenant, `revoking` a key and `revoking` all tenant keys.
The IBM FHIR Server supports hard delete using the custom FHIR Operation Framework. The operation is called $erase; you can always read the design document.
The IBM FHIR Server has support for exporting and importing Bulk Data using extended operations for Bulk Data $import, $export and $bulkdata-status, which are implemented as Java Maven projects. The IBM FHIR Server uses JSR252 JavaBatch jobs running in the Open Liberty Java Batch Framework. The IBM FHIR Server supports storage providers S3 (aws-s3,ibm-cos), File System (file), and now Azure (azure-blob). I recently implemented support for the Azure Blob Service in IBM/FHIR Pull Request #2413. The code that supports the Azure client uses the OK Http library and not Netty to communicate with the backend. The storage provider is implemented…
I’ve been debugging a drop tablespace issue on Db2 – IBM/FHIR: 2354. The core issue was a timing problem with lots of partitions dettaching. This adds a delay to the dropTablespace so the async operation can complete, and cleanly exit with a specific error code so downstream consumers can work around the issue.
This was super helpful for debugging S3 files/folders.
If you hit this issue, per the GitHub community it’s a Windows issue that can be worked around with a Pagefile. link
[ERROR] OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000700000000, 553648128, 0) failed; error=’The paging file is too small for this operation to complete’ (DOS error/errno=1455)