1. Programmer's Guide
  2. RIM Services
  3. Constraints on the HL7 V3 RIM Model

Constraints on the HL7 V3 RIM Model

The constraints to some of the HL7 V3 data types allow HDR to have a physical data model that gives a significant boost to the API performance.

HL7 V3 Datatype Constraints

ED.Reference.Use

HDR allows only one use code for ED.Reference instead of many. ED.Reference is generally used to store the external URL of an image or document represented by this ED. Since URL is a type of addressing mechanism, HL7 allows Use based on the base definition of an address. HDR allows just a single Use to be specified on the ED.Reference to cater to any use cases where an Use may be needed on ED.Reference.

AD.Use

HDR allows only 3 use codes for AD.Use. A single address may be used as home, office, and the third one can be used for another purpose.

AD.ADXP

The following additional constraints are placed on the number of ADXP values used in AD datatype:

  1. Only 5 street address lines (ADXP with part type SAL) are supported. Each street address line can have a maximum of 240 characters.
  2. There can be only one ADXP each with part type other than SAL. For example, there can be only one building number or one country in the address.

EN.Use

HDR allows only 3 use codes for EN.Use. A single name may be used as legal, call-by, and the third one can be used for another purpose.

EN.ENXP

There can be only one ENXP each with any part type. For example, there can be only one given name in the name. Each name part can have a maximum length of 1000 characters.

RIM Query API Constraints

  • The top-level RIM fetch object must have criteria with RIM structural codes specified.
  • Criteria is optional in child fetches but is strongly recommended in all cases where the queried RIM object model is well defined.
  • Criteria on any fetch object cannot be connective criteria specifying different structural attributes, for example: a different class code. The recommended approach to restructure such queries is to create different fetch objects for each class code. Connective criteria can still be used at any level provided the RIM structural codes are same on each of the attribute criteria. Each structural code represents a particular type of clinical information such as encounter or an observation and HDR mandates that one fetch is used for each type of clinical data retrieved.