HL7 defines OID as a globally unique string representing an ISO Object Identifier (OID), in a form that consists only of numbers and dots (Example: 2.16.840.1.113883.3.1). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. OIDs are created in HDR through the DataTypeFactory.newOID method.
All HDR objects are uniquely identifiable, based on internal identifiers that are system generated at the time of creation. Each such identifier takes the form of an Instance Identifier DataType, which consists of a root and an extension that together uniquely identify an HDR object.The root uniquely identifies the implementing organization represented by this instance of HDR. The extension uniquely identifies this specific instance of the HDR object (e.g. an act, role or entity). Note, user defined or externally supplied instance identifiers may also be persisted for an object. These are in addition to the system-generated identifier. The root of these IIs is modeled as InternalOID RootId. InternalOID has two mandatory attributes, namely RootName and RootId. RootName can be one of the string constants defined in OIDService. RootId is of type OID. ConfigurationFactory methods can be used to create a blank instance of InternalOID.
A set of InternalOIDs must be configured during implementation to enable HDR to generate identifiers. The OIDService interface is used to configure the InternalOID values. HDR will suffix the root with the appropriate extension, to provide the unique identifier for the object.
See Also:
HL7 web site
current version-3 ballot documentation for details about OID and II data types, and >>http://www.hl7.org/oid/
for more information about OIDs.ISO/IEC 8824 standard standard for the ISO standard for further details on OIDs.
Oracle Healthcare Data Repository Implementation Guide for information about HDR Internal OIDs.
Examples: This section contains the following code samples:
Example 6-1 Set up OID Service and Required Factories
The following code sample shows how to set up the service and factories required:
// Get the OID service OIDService oidService = mServiceLocator.getOIDService(); // Create the configuration factory instance ConfigurationFactory configFactory = ConfigurationFactory.getInstance(); // Create the datatype factory instance DataTypeFactory.getInstance();
Example 6-2 Create an Internal OID
The following code sample shows how to configure an Internal OID with a new root id. Use the appropriate factory methods to create the instance of OID and InternalOID:
// Create an OID datatype instance using the datatype factory OID rootOID = dataTypeFactory.newOID("9.989898.5"); // Create the Internal OID object using the configuration factory InternalOID internalRootOID = configFactory.newInternalRootOID(); // set the root for the Internal OID internalRootOID.setRootId(rootOID); // create the Internal OID using the service oidService.registerOID(internalRootOID);
Example 6-3 Query an Internal OID
The following code sample shows how to query an Internal OID. Pass the appropriate Root Name constant as the parameter to this service method. All Root Name constants are defined in OIDService:
// Find the InternalOID using the get method InternalOID internalOID = oidService.getOID(OIDService.INTERNAL_ROOT);
Example 6-4 Query All Internal OIDs
The following code sample shows how to query all Internal OIDs. This method returns all InternalOIDs configured in the system:
// Find all the InternalOIDs using the get all methodInternalOID[] new line/Enter internalOIDs = oidService.getAllOIDs();
Example 6-5 Update an Internal OID
The following code sample shows how to configure an Internal OID by updating its root value. This same method is used for update and to create operations. Update is not allowed if some RIM objects are already using the root:
// Create an OID datatype instance using the datatype factory OID rootOID = dataTypeFactory.newOID("9.989898.9"); // Create the Internal OID object using the configuration factory InternalOID internalRootOID = configFactory.newInternalRootOID(); // set the root for the Internal OID internalRootOID.setRootId(rootOID); // update the Internal OID using the service oidService.registerOID(internalRootOID);
Profile options are configurable preferences that affect the way an application behaves. Application developers can control how their HDR based applications operate by defining new profile options using Oracle Self Service Web Applications and programming the applications to inspect their values at run time to determine behavior. System Administrators can then use Oracle Self Service Web Applications to control operational aspects by setting the values of relevant profile options for specific organizations and users.
The primary use of the Profile Option service ProfileOptionService is to retrieve profile option values at run time. The Profile Option Service also provides methods to let you define profile options and set their values at multiple levels. Typically you define and set profile options using Oracle Self Service Web Applications rather than defining them programmatically.
There are three profile option levels:
Site
User
These sections help you to:
See Also:
Oracle Healthcare Data Repository Implementation Guide for information about implementing Profile Option Services using Oracle Self Service Web Applications.Examples: The following code samples help you to:
When you define a new profile option, you specify constraints to describe valid values for that profile option, and you can also specify whether your end users can change the value of a profile option. The ProfileOption value object is constructed using the ConfigurationHelper factory class.
If a profile option value type is LOOKUP, you should specify an active concept list that belongs to the LOOKUPS_GROUP group. No validations are performed against the profile option value if the value type is not LOOKUP.
Profile options have system administrator access settings and user access settings to control who can view and change values at certain levels. System administrator settings control which values are visible to and updateable by a user in a system administrator role. A system administrator has default access to all values at all levels. Access settings specify updateable and visible flags for each level for each profile option. When updateable flags are set to Y, visible flags must be set to Y. User access settings are similar but are restricted to the user level. Therefore there is only one set of user access updateable and visible flags per profile option and they default to Y. These flags control whether a user can view or update personal values for this profile option. You can use the getProfileOptions method to retrieve a list of profile options that are accessible by system administrator or other user.
Table 6-1 Profile Options for HDR:
PROFILE_OPTION_CODE | PROFILE_OPTION_NAME | DESCRIPTION | Permitted Values |
---|---|---|---|
ETS_MLS_LANGUAGE_CODE |
ETS MLS Language Code |
Default language code. |
ISO 639 alpha-2 Language Code |
ETS_MLS_COUNTRY_CODE |
ETS MLS Country Code |
Default country code. |
ISO 3166 alpha-2 Country Code |
CTB_AU_AUDIT_FLAG |
CTB: Auditing On |
Flag to switch ON/OFF Auditing. |
Y/N |
CTB_AU_RECEIVE_MSG |
CTB: Audit Receive Message |
Flag to specify if IMP should create an audit log for message received. Set to 'Y' to audit; set to 'N' otherwise. |
Y/N |
CTB_MS_STORE_MESSAGE |
CTB: Store Incoming Message |
Flag to specify if IMP should store incoming message. Set to 'Y' to store; set to 'N' otherwise. |
Y/N |
CTB_AU_UPDATE_OID |
CTB: Audit Update OID |
Flag to specify if any change in HDR OID configuration should be audited. Set to 'Y' to audit; set to 'N' otherwise. |
Y/N |
CTB_MTK_SCHEMA_DIR_PATH |
CTB: MTK schema upload path |
Location where the custom schema and MIF files will be uploaded in the HDR server. |
Valid middle tier server location to upload MTK custom schema. |
CTB_XDS_B_REGISTRY_ASYNC_URL |
CTB: XDSb Registry Asynchronous Endpoint URL |
XDSb Document Registry's Asynchronous URL. |
URL |
CTB_XDS_B_REGISTRY_URL |
CTB: XDSb Registry URL |
XDSb Document Registry's URL. |
URL |
CTB_XDS_DOCUMENT_IMPORT |
CTB: XDSb Document Import |
Flag to specify if IHE XDS.b document import mode should be turned on. Set to 'Y' to enable document import; set to 'N' otherwise. |
Y/N |
CTB_XDS_AUDIT_SERVER_PORT |
CTB: XDSb Audit Server Port |
ATNA audit logging server port number. Either UDP or TLS port based on CTB_XDS_AUDIT_SERVER_TRANSPORT_PROTOCOL value. |
Port number |
CTB_XDS_AUDIT_SERVERNAME |
CTB: XDSb Audit Server Name |
ATNA audit logging server hostname or IP address. |
Hostname or IP address |
CTB_XDS_AUDIT_SERVER_TRANSPORT_PROTOCOL |
CTB: XDSb Audit Server Transport Protocol |
The protocol to be used for IHE ATNA audit logging. |
UDP or TLS |
CTB_XDS_REPOSITORY_UNIQUE_ID |
CTB: XDSb Repository Unique Id |
IHE XDS.b document repository unique id. |
Valid OID |
CTB_XDS_WS_ATOMIC_TRANSACTION |
CTB: XDSb WS-Atomic Transaction |
Flag to specify if XDS.b Document Registry is invoked using WS-Atomic Transaction Protocol. Set to 'Y' to enable; set to 'N' otherwise. |
Y/N |
CTB_EN_USE_VAL_CRITERIA |
CTB: Validation Criteria for EN_USE |
Depending on this criteria, the concept list for validating EN will be picked. 0 for CL_EN_USE, 1 for CL_EN_USE_EXT and 2 for CL_EN_USE union CL_EN_USE_EXT. |
0,1 or 2 |
Example 6-6 Create a Profile Option
This code sample creates a profile option within the following constraints. Its purpose is to create a profile option for use in the subsequent examples in this section. You should use Oracle Self Service Web Applications and avoid programmatic creation of a new profile option. Note that the example can be executed only once for any given ProfileOptionCode.
Value type is LOOKUP; use the concept list CTB_YES_NO.
System Administrator access only.
Site level and User level are updateable and visible.
ConfigurationHelper configHelper = new ConfigurationHelper(); ProfileOptionService profileOptionService = serviceLocator.getProfileOptionService(); //Construct profile option value object ProfileOption profileOption = configHelper.newProfileOption(); //Set the profile option code. scenarioProfileOptionCode is a String variable, and must be unique. profileOption.setProfileOptionCode(scenarioProfileOptionCode); profileOption.setProfileOptionName("Scenario Profile Option"); profileOption.setDescription("Profile option created by programmers guide."); //Setting value type constraint. Valid value is null or LOOKUP profileOption.setValueTypeCode("LOOKUP"); //Lookup type is any concept list in the LOOKUP_GROUP group profileOption.setConstraint1("CTB_YES_NO"); //By default, all levels are Y. So you must turn off other levels. profileOption.setOrgVisibleFlag("N"); //This profile option only allows system administrator role to view and change //the profile option value. The user access flag must be turned off. profileOption.setUserAccessVisibleFlag("N"); profileOption.setUserAccessUpdateableFlag("N"); //Create the profile option now profileOptionService.createProfileOption(profileOption);
After the profile option is created, a system administrator or other user can set profile option values at each profile level by calling the setProfileOptionValue(ProfileOptionValue) method. Whenever you set profile option values, the prior values are overwritten. An exception is thrown when constraints set in the profile option are not met. Refer to setProfileOptionValue(ProfileOptionValue) (in the Oracle Healthcare Data Repository API Documenation) for more information about exceptions thrown by this method. The ProfileOptionValue value object is constructed using the ConfigurationHelper factory class.
Example 6-7 Set a Profile Option Value at Site Level
The following code sample sets a profile option value at the Site level for the profile option [scenarioProfileOptionCode] created in Example 6-7. Its purpose is to set the Site level option used in the later examples in this section. The Site level option values affect the way all applications run at a given installation and should be set using Oracle Self Service Web Applications rather than setting the values programmatically.
ProfileOptionValue siteLevelProfOptionVal = configHelper.newProfileOptionValue(); siteLevelProfOptionVal.setProfileOptionCode(scenarioProfileOptionCode); //Set the level value. The valid values are SITE and USER. siteLevelProfOptionVal.setProfileOptionLevelCode("SITE"); //The profile option value must be a valid value in the CTB_YES_NO concept list. siteLevelProfOptionVal.setProfileOptionValue("N"); profileOptionService.setProfileOptionValue(siteLevelProfOptionVal);
Example 6-8 Set a Profile Option Value at User Level
The following code sample sets a profile option value at user-level (sysadmin) for the profile option [scenarioProfileOptionCode] created in Example 6-7. Its purpose is to set the User level option used in the later examples in this section. The User level option values affect the way the application runs for a given user and should be set using Oracle Self Service Web Applications rather than setting the values programmatically.
ProfileOptionValue userLevelProfOptionVal = configHelper.newProfileOptionValue(); userLevelProfOptionVal.setProfileOptionCode(scenarioProfileOptionCode); //Set the level value. The valid values are SITE and USER. userLevelProfOptionVal.setProfileOptionLevelCode("USER"); //The profile option level value must be a valid user account login identity. userLevelProfOptionVal.setProfileOptionLevelValue("SYSADMIN"); //The profile option value must be a valid value in the CTB_YES_NO concept list. userLevelProfOptionVal.setProfileOptionValue("Y"); profileOptionService.setProfileOptionValue(userLevelProfOptionVal);
Your HDR-based application can retrieve profile option values in two ways:
By retrieving a profile option value at a level such as User for a particular instance of that level, such as user name(login identity).
By retrieving a profile option value without specifying any level. In this case, the system automatically accounts for level precedence, and returns the most appropriate value. User level has higher precedence than Site level.
Example 6-9 Retrieve a Profile Option Value for Current User
The following code sample retrieves the value of profile option [scenarioProfileOptionCode] created in Example 6-8 for the current login user. It retrieves the profile option value of Y set in Example 6-9.
//Get the current login user's login identity SessionService sessionService = serviceLocator.getSessionService(); String value = profileOptionService.getProfileOptionValueForLevel(scenarioProfileOptionCode,"USER" 'SYSADMIN'); //Retrieve the value set in Example 6-9 String value = profileOptionService.getProfileOptionValueForLevel(scenarioProfileOptionCode,"USER",loginId);
Example 6-10 Retrieve a Profile Option Value at any Level
The following code sample retrieves the value of profile option [scenarioProfileOptionCode] created in Example 6-7 without specifying a level:
String value = profileOptionService.getProfileOptionValue(scenarioProfileOptionCode);
The Site and User level option values were set for [scenarioProfileOptionCode] in Example 6-8 and Example 6-9. This method returns the current login User's value of Y because the User level has higher precedence than the Site level.