Implement RIM Service
The RIMService is the main persistence and query service for persistence and retrieval of HL7 V3 RIM data. The HDR RIM Java APIs allows customers to build any HL7 V3 RIM object model to represent any clinical information model and persist clinical data based on the RIM clinical models into HDR.
The Java APIs include implementation of the standard HL7 RIM standard classes, associations and data types based on RIM version 2.14.1.01.
HDR RIM Service supports generic object models constructed using the supported RIM standard and does not constrain implementations to use any specific RIM models.
All RIM objects to be updated must follow the allowed state transitions specified in the supported RIM standard.
Before implementing the RIM Service, the following must be implemented before data can be successfully persisted using the RIM Service APIs:
- Load terminologies using ETS: All coded terminologies to be used in the data
to be persisted must be first loaded into the ETS. Please refer to Implementing "Enterprise Terminology Services" section to learn how to load terminologies
into ETS.
See also:
- Programmer's Guide for more details about the ETS Services.
- Master Catalog Configuration: All of the RIM Act/Role/Entity objects must resolve to a valid master catalog id to be successfully persisted in HDR. This master catalog configuration allows implementers to have a fine grained control over what type of clinical data can be persisted in HDR. For example, users can allow only Lab and Medication data to be persisted into HDR and disallow any radiology reports to be persisted in HDR. For example, this will be helpful in building solutions where HDR is one component that is designed to store only Lab and Medication data whereas Radiology reports are designed to be processed by another non-HDR component. Similar master catalog configuration also permits configuring allowed state transitions on focal classes. For more on master catalog configuration, please refer to "Implement Master Catalog and Focal Class State Transitions".
There are several types of update behaviors that can be configured when persisting RIM objects. RIM objects can be configured only to be created OR only updated OR created or updated OR only referenced with no updates. Please refer to ReferenceModifier.java in Javadoc for more details on the update behaviors supported and their usage.
RIM Service APIs provide a fine grained query API where the users can define their queries in terms of the RIM model and retrieve data out of HDR. The query results will be returned in the RIM Java object models. For more on the RIM Service API usage please refer to the HDR Javadoc on the Oracle Help Center (https://docs.oracle.com/health-sciences/health-hdr-81/HDRAP/index.html). The query API supports querying any part of the persisted model, and also supports querying aggregated clinical data based on the query filter criteria, like patient identifier.
There are several types of update behaviors that can be configured when persisting RIM objects. RIM objects can be configured only to be created OR only updated OR created or updated OR only referenced with no updates. Please refer to ReferenceModifier.java in Javadoc for more details on the update behaviors supported and their usage.
RIM Service APIs provide a fine grained query API where the users can define their queries in terms of the RIM model and retrieve data out of HDR. The query results will be returned in the RIM Java object models. For more on the RIM Service API usage please refer to the HDR Javadoc on the Oracle Help Center (https://docs.oracle.com/health-sciences/health-hdr-81/HDRAP/index.html). The query API supports querying any part of the persisted model and also support querying aggregated clinical data based on the query filter criteria like patient identifier.
Generate SQL Queries
The SQL queries generated by the RIM query API can be optimized in three different ways. By default, in all nested select sub queries, the where conditions will be generated as a SQL IN condition. This can be modified by configuring the HDR managed server start-up JVM argument CTB_SUBQRY_OPT_METHOD with one of the values NONE, EXISTS, or JOIN. Based on the database version and configuration, you can choose an option that results in the best database SQL execution plans for the HDR generated SQL queries.
-DCTB_SUBQRY_OPT_METHOD=NONE
This is the default behavior where all nested select sub queries in the where condition will be generated as the SQL IN condition.
-DCTB_SUBQRY_OPT_METHOD=EXISTS
By setting sub-query optimization method to EXISTS, all nested select sub queries in the where condition will be generated as the SQL EXISTS condition.