| Oracle® Health Sciences Information Manager Health Record Locator User's Guide Release 3.0 E61283-01 |
|
| PDF · Mobi · ePub |
| Oracle® Health Sciences Information Manager Health Record Locator User's Guide Release 3.0 E61283-01 |
|
| PDF · Mobi · ePub |
Health Record Locator User's Guide
Release 3.0
E61283-01
March 2015
This guide provides information on Oracle® Health Sciences Information Manager (OHIM) Health Record Locator (HRL). It describes features and functionalities of Document Registry, Integrating the Healthcare Enterprise (IHE) standards, and Web Services with their configuration options.
This document is intended for Oracle Health Record Locator users.
HRL keeps track of patients' documents by indexing them using the Document Metadata. HRL is IHE and Cross-Enterprise Document Sharing (XDS) standards compliant and implements the XDS Document Registry Actor.
Figure 1 shows the XDS actors and transactions among them. It does not contain actors and transaction related to Document Metadata Subscription (DSUB).
HRL supports the following IHE profiles and transactions:
Table 1 Actors and Transactions Supported by HRL
| Profile | Actor | Option | ITI TXN NumberFoot 1 |
|---|---|---|---|
|
MPQFoot 2 |
Document Registry |
None |
ITI-51 |
|
MPQ |
Document Registry |
Asynchronous Web Services Exchange |
ITI-51 |
|
XDS.bFoot 3 |
Document Registry |
Patient Identity Feed (HL7 V3) |
ITI-44 |
|
XDS.b |
Document Registry |
None |
ITI-18 ITI-42 |
|
XDS.b |
Document Registry |
Asynchronous Web Services Exchange |
ITI-18 ITI-42 |
|
XDS.b |
Document Registry |
Document Metadata Update |
ITI-57 ITI-62 |
|
XPIDFoot 4 |
Document Registry |
None |
ITI-64 |
|
XDS.b |
Document Registry |
Patient Identity Feed (HL7 V2) |
ITI-8 |
|
DSUBFoot 5 |
Document MetadataNotification BrokerDocument MetadataPublisher |
None |
ITI-52 ITI-53 ITI-54 |
Footnote 1 IT Infrastructure Transaction Number
Footnote 2 MPQ - Multi-patient Queries
Footnote 3 XDS.b - Cross-Enterprise Document Sharing
Footnote 4 XPID - XAD-PID Change Management Profile
Footnote 5 DSUB - Document Metadata Subscription
Most of the IHE ITI transactions that HRL supports are through SOAP 1.2 based Web Services. The following are the SOAP 1.2 Web Services that HRL supports:
Core Registry Service (Patient Feed, Register Document Set, and Registry Stored Query) (see "Core Registry Service")
Multi-patient Query Service (see "Multi-patient Query Service")
Metadata Update Service (see "Metadata Update Service")
Web Services are implemented using JAX-WS Web Services API and stack on Oracle WebLogic server. For more information on Web Service definitions and related IHE XDS transactions, see IHE IT Infrastructure XDS Profile specifications.
The following Web Services operations and IHE transactions are supported for Core Registry Service:
ITI-44 Patient Identity Feed
ITI-42 Register Document Set
ITI-18 Registry Stored Query
The Registry Stored Query is classified into the following types:
FindDocuments
FindDocumentsByReferenceId
FindSubmissionSets
FindFolders
GetDocuments
GetFolders
GetAssociations
GetDocumentsAndAssociations
GetSubmissionSets
GetSubmissionSetAndContents
GetFolderAndContents
GetFoldersForDocument
GetRelatedDocuments
GetAll
The following Web Services operations and IHE transactions are supported for Multi-patient Query Service:
ITI-51 Multi-patient Query
The Multi-patient Query is classified into the following type:
FindDocumentsForMultiplePatients
FindFoldersForMultiplePatients
The following Web Services operations and IHE transactions are supported for Metadata Update Service:
ITI-57 Update Document Set
ITI-62 Delete Document Set
The following IHE transactions are supported in HL7v2 Server:
ITI-8 Patient Identity Feed
ITI-64 Notify XAD-PID Link Change
For details on these Web Services operations and IHE transactions, see http://www.ihe.net/Technical_Frameworks.
The Core Registry, Multi-patient Query, and Metadata Update Services are implemented as Java Enterprise Edition (EE) components.
HL7v2 Services are implemented as an optional Application server components called XPID. You must deploy the XPID component on the same Application server instance as that of the core Registry Services component.
DSUB Document Metadata Notification Broker service is implemented in an optional Java EE component. You may choose to deploy it on the same Application Server instance as that of core Registry Services or on a separate instance.
DSUB Document Metadata Publisher is part of core Registry Services component. This is enabled through the configuration parameter.
The following are the minimum hardware requirements for installing HRL:
4 GB (4096 MB) of RAM for WebLogic
12 GB of disk space
16 GB of disk space for 64-bit
The following are the software requirements for installing HRL:
Java 1.7 executable in path (for installer)
Oracle JDK 1.7.0_45+ and WebLogic Server 11g Release 1 (10.3.6.0) or WebLogic Server 12c Release 2 (12.1.2)
Oracle Database 11g Release 2 (11.2.0.4.0) or Oracle Database 12c Release 1 (12.1.0.2.0)
Oracle Enterprise Linux 5.5 or higher
Microsoft Windows x64 (64-bit) 2012 R2
Microsoft Windows x64 (64-bit) 2012
Microsoft Windows x64 (64-bit) 2008 R2
Apache Ant 1.8.2 executable in path
PATH=$PATH:<install_dir>/apache-ant-1.8.2/bin
Table 2 lists the IHE profiles supported by HRL.
Table 2 Supported IHE Profiles
| Profile Name | Version | Location |
|---|---|---|
|
Cross-Enterprise Document Sharing (XDS) |
Revision 11.0 Sept 23, 2014 |
|
|
Document Metadata Subscription (DSUB) |
Trial Implementation October 13, 2014 |
|
|
XAD-PID Change Management (XPID) |
Trial Implementation October 13, 2014 |
|
The configuration file is located under the config/hrl/config directory of the Application Server domain directory.
WebLogic: <Weblogic Middleware Home>/user_projects/domains/<domain name>/config/hrl/config/xconfig.xml
Restart the Application server for xconfig.xml changes to take effect.
The following is the structure of xconfig.xml file in which some configuration properties are specified under HomeCommunity and Registry elements.
<?xml version="1.0" encoding="utf-8"?><Config> <HomeCommunity name="home"> <Property name="propName1">propVal1</Property> ... </HomeCommunity> <Registry name="localregistry"> <Property name="propName2">propVal2</Property> ... </Registry></Config>
To enable sending ATNA UDP or TLS messages, edit the value of the following properties under HomeCommunity element and specify ATNA UDP or TLS server details:
ATNAPerformAudit: Set this value to true to enable sending ATNA audit messages. By default, this value is set to false.
ATNAsyslogProtocol: Set this value to udp or tls.
ATNAsyslogHost: Specify the ATNA UDP or TLS server host name or IP address.
ATNAMessageType: Set this value to RFC3881 or DICOM. This property represents the audit message format that the system must generate.
ATNAsyslogPort: Specify the ATNA UDP or TLS server port number.
Ensure to configure the following properties when you use TLS for ATNAsyslogProtocol:
KeyStore: Enter the file path of the keystore. For example, /home/common/cert/keystore.jks.
KeyStoreType: Specify the type of the keystore. By default, the value is set to JKS.
TrustStore: Enter the file path of the truststore. For example, /home/common/cert/keystore.jks.
TrustStoreType: Specify the type of the truststore. By default, the value is set to JKS.
CredentialStore: Enter the directory where Oracle wallet is created. For example, /home/common.
ValidatePatientId: Set this value to true (default value) to validate known patients ID before registering DocumentEntry.
XMLSchemaValidationEnabled: Set this value to true (default value) to schema validate incoming messages.
LogEnabled: Set this value to true (default value) to enable logging of registry request and response messages in the Log schema tables.
Note:
This parameter is different from enabling ATNA audit log messages.ReceiverDeviceId: Set this value to construct response messages in HL7v2 services.
ReceiverDeviceName: Set this value to construct response messages in HL7v2 services. By default, this value is set to ORACLE_HIA_RLS_XDSbRegistry.
AcceptPIDOnlyFrom: Set this property to let registry accept patient feed only from the specified domain.
Comment or delete this property to let registry accept patient feed from all domain.
MaxLeafObjectsAllowedFromQuery: Specify an integer value that determine the maximum number of document entries returned with Registry Stored Query response messages. By default, this value is set to 25.
Note:
This property is applicable only when query request contains return type value
LeafClass.TrimLogQueueMessages: Set this value to true (default value) to trim the messages logged in the Log schema tables.
MaxLeafObjectsPerLogQueueMsg: Specify the maximum number of Leaf objects to be logged per message. By default, this value is set to 5.
MaxObjectRefsPerLogQueueMsg: Specify the maximum value of Object references to be logged per message. By default, this value is set to 5.
ValidateCodeDisplayName: Set this value to true to let HRL validate the code display names in the registry metadata of the request against the codes.xml file. By default, this value is set to false.
ValidateDocEntryURISlotValue: Set this value to true to let HRL validate the URI slot value in the document metadata of the request. By default, this value is set to false.
AffinityDomainPIDAssigningAuthorityID: Set this property to let registry append the Assigning Authority ID to the received Patient ID, which does not have this value. After updating the configured Assigning Authority Id value, the registry persists the Patient ID in the database.
By default, this property is commented. To let HRL employ the above specified behavior, uncomment this property.
The format of this property value is:
&OIDOfAssigningAuthorityID&ISO
For example,
<Property name="AffinityDomainPIDAssigningAuthorityID">&1.3.6.1.4.1.21367.2005.3.7&ISO</Property>
AllowDuplicateUniqueIdInSubmission: Set this value to true to let HRL duplicate unique IDs in a submission. By default, this value is set to false.
NotificationEnabled: Set this value to true to enable publishing registry events to the DSUB Notification Broker. By default, this value is set to false.
PublishEndPoint: Specify the publish endpoint URL of the DSUB Notification Broker.
DsubValidateCodeAndCodingScheme: Set this value to true (default value) to validate code and coding scheme containing DSUB subscription message against codes file of the registry.
DefaultDaysBeforeExpiryOfSubscription: Enter an integer value, which indicates the number of days before which the subscription expires. By default, this value is set to 30.
NotificationBrokerSubscribeEndPoint: Specify the Subscribe endpoint URL of the DSUB Notification Broker.
DeleteExpiredSubscriptionsIntervalDuration: Indicates the number of milliseconds between successive invocations of the batch job to delete expired subscriptions (if any) from the database. Enter an integer value specifying milliseconds interval. The default value is 86400000 (1 day).
DeleteExpiredSubscriptionsTimerStartInterval: Indicates the duration in milliseconds after the receipt of the first subscribe request to the Notification Broker. The batch job to delete the expired records becomes active at this point. Enter an integer value specifying milliseconds interval. The default value is 86400000 (1 day).
The codes file is located under the config/hrl/codes directory of the Application Server domain directory.
WebLogic: <Weblogic_Middleware_Home>/user_projects/domains/<domain name>/config/hrl/codes/codes.xml
You can update these files with new codes as applicable. Restart the Application server for new codes to take effect.
Table 3 lists the Web Services supported by HRL. You can find the Web Service WSDL by suffixing endpoint Uniform Resource Locator (URL) with ?wsdl.
Table 3 Transactions and Web Service URL
| Transaction | Synch | Asynch | Endpoint URL |
|---|---|---|---|
|
Register Document Set-b (ITI-42) |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regsvc |
|
Registry Stored Query (ITI-18) |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regsvc |
|
Patient Identity Feed (HL7 V3) (ITI-44) |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regsvc |
|
Multi Patient Query (ITI-51) |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regmpqsvc |
|
Metadata Update - Update (ITI-57) |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regupdsvc |
|
Metadata Update - Delete (ITI-62) |
Yes |
Yes |
http(s)://<HRL_HOST>:<PORT>/hrl/regupdsvc |
Use the endpoints in Table 4 to configure your Document Metadata publisher and subscribers as needed.
Table 4 DSUB Transactions and Endpoint URLs
| Transaction | Endpoint URL |
|---|---|
|
Document Metadata Publish[ITI-54] |
http(s)://<DSUB_HOST>:<PORT>/WS-BrokeredNotificationPubl ish_Service/Publish |
|
Document Metadata Subscribe[ITI-52] |
http(s)://<DSUB_HOST>:<PORT>/WS-BrokeredNotificationSubscribe_Service/Subscribe |
|
Document Metadata Unsubscribe [ITI-52] |
http(s)://<DSUB_HOST>:<PORT>/WS-BrokeredNotificationUnSubscribe_Service/Unsubscribe?subscriptionId=<UUID> <UUID> should be a valid value as assigned by DSUB Notification Broker. |
When you execute FindDocument Registry Stored Query (ITI-18) with status parameter value of deprecated (urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated), registry returns all document versions with the status deprecated as per the IHE specification.
To query only the latest deprecated version of DocumentEntry, a new status parameter value deleted (urn:orcl.reg:names:StatusType:Deleted) is added to HRL. When this status parameter value deleted is specified in the query, registry returns the latest version of the DocumentEntry for a patient where all versions have deprecated status.
Note:
This parameter value is only applicable to FindDocument query type of Registry Stored Query (ITI-18).The $XDSDocumentEntryAuthorPerson query parameter value is used in case-sensitive manner in Registry Stored Query (ITI-18) to retrieve matching document entries.
To query for document entries with AuthorPerson value in case-insensitive manner, a new parameter $orcl.caseInsensitive.DocumentEntryAuthorPerson is added.
Registry queries executed without any filters retrieve all document entries of a patient.
You must ensure to design client document consumer actor to query with filter conditions or parameters. However, using filter may still result in large document entries and hence, Oracle recommends that you use the following queries instead of one large query retrieving all DocumentEntry metadata.
Execute large query with returnType=”ObjectRef”, which returns all document entries Object References or Universally Unique Identifier (UUID)s. This query executes faster compared to one with returnType=”LeafClass”, which returns all metadata (XML structure).
Subsequent queries can use limited number of UUIDs to query document entries metadata depending on the page size.
For example,
Executing FindDocuments query type with returnType=”ObjectRef” returns a large number of ObjectRefs (UUIDs).
Executing subsequent GetDocuments query type with returnType=”LeafClass” with limited number of UUIDs from the list returns document entries metadata (XML structure) to be processed and displayed on one page.
HRL simulates ITI-62 transaction without committing the changes or deleting the metadata entry. To simulate this, add the SOAP header SimulateTransaction to the ITI-62 request.
For example, <custom:SimulateTransaction xmlns:custom="urn:oracle:hsgbu:him:hrl:customheader">yes</custom:Simula teTransaction>
HRL supports an optional custom parameter, $orcl.order.by, for ITI-18 Find Documents query, which sorts the query result on a specific attribute. The parameter should have single value in the <sortfieldname>:<a|d> format.
where,
a is for ascending order and d is for descending order.
<sortfieldname> can be one of the following:
creationTime
languageCode
mimeType
serviceStartTime
serviceStopTime
size
For example,
<Slot name="$orcl.order.by">
<ValueList>
<Value>'creationTime:a'</Value>
</ValueList>
</Slot>
This section describes security configuration issues you must consider when implementing HRL.
The following are fundamental principles for using any application securely:
Keep software up-to-date
Keep all software versions and patches up-to-date.
Keep up-to-date on latest security information critical patch
Oracle continually improves its software and documentation. Critical patch updates are the primary means of releasing security fixes for Oracle products to customers with valid support contracts. Oracle recommends you to apply these patches as soon as they are released.
Configure strong passwords on the database
Repeat the following basic rule of security management:
Ensure all passwords are strong. You can strengthen passwords by creating and using password policies for your organization. For guidelines on securing passwords and for additional ways to protect passwords, refer to the Oracle® Database Security Guide specific to the database release you are using.
You should modify the following passwords to use your policy-compliant strings:
Passwords for the database default accounts, such as SYS and SYSTEM.
Passwords for the database application-specific schema accounts, such as ADT, HRLCORE, and LOG.
Password for the database listener.
Oracle recommends that you do not configure a password for the database listener as it will enable remote administration. For more information, refer to the section Removing the Listener Password of Oracle® Database Net Services Reference 11g Release 2 (11.2).
Follow the principle of least privilege
The principle of least privilege states that users should be given the least amount of privilege to perform their jobs. Overly ambitious granting of responsibilities, roles, grants - especially early on in an organization's life cycle when people are few and work needs to be done quickly - often leaves a system wide open for abuse. User privileges should be reviewed periodically to determine relevance to current job responsibilities.To restrict access, it is recommended to have the following default file permissions in Unix environment.
740 for executable
640 for regular files
Managing default user accounts
Lock and expire default user accounts.
Closing all open ports when not in use
Keep only the minimum number of ports open. You should close all ports when not in use.
Disabling the Telnet service
Oracle HRL standard configuration does not use the Telnet service. By default, Telnet listens on port 23. Telnet, which sends clear-text passwords and user names through a log in, is a security risk to your servers. If the Telnet service is available on any system, it is recommended to disable Telnet in favor of Secure Shell (SSH). Disabling Telnet protects your system security.
Disabling Other Unused Services
In addition to not using Telnet, the HRL standard configuration does not use the following services or information for any functionality:
Simple Mail Transfer Protocol (SMTP) - This protocol is an Internet standard for e-mail transmission across Internet Protocol (IP) networks.
Identification Protocol (identd) - This protocol is generally used to identify the owner of a TCP connection on UNIX.
Simple Network Management Protocol (SNMP) - This protocol is a method for managing and reporting information about different systems.
Restricting these services or information does not affect the use of Oracle HRL standard configuration. If you are not using these services for other applications, it is recommended to disable these services to minimize your security exposure. If you need SMTP, identd, or SNMP for other applications, ensure to upgrade to the latest version of the protocol to provide the most up-to-date security for your system.
Designing multiple layers of protection
When designing a secure deployment, design multiple layers of protection. If a hacker gains access to one layer, such as Application server, that should not automatically give them easy access to other layers, such as the database server.
Providing multiple layers of protection may include:
Enabling only those ports required for communication between different tiers. For example, only allow communication to the database tier on the port used for SQL*NET communications (by default, 1521).
Placing firewalls between servers so that only expected traffic can move between servers.
Utilizing SSL
Consider utilizing Application Server SSL service for the HRL application. The HRL application is a standard Java EE application and can utilize an industry standard security infrastructure and framework. There is no configuration required on the HRL application. The application Server (WebLogic) provides SSL service. For more information about configuring SSL to achieve SSL security for HRL, see the Application Server's documentation.
When SSL or TLS is configured, it is recommended to use TLS_RSA_WITH_AES_128_CBC_SHA cipher instead of SSL_RSA_WITH_3DES_EDE_CBC_SHA for TLS authentication.
Oracle recommends the following generic Oracle database optimizations for HRL and on the specific database behavior:
| Parameter | Value |
|---|---|
| db_cache_size | 1 GB |
| memory_target | 8 GB |
| memory_max_target | 8 GB |
| log_buffer | 3 MB |
| LARGE_POOL_SIZE | 100 MB |
| PGA_AGGREGATE_TARGET | 2 GB |
| SGA_MAX_SIZE | 4 GB |
| SGA_TARGET | 4 GB |
| SHARED_POOL_SIZE | 1 GB |
| processes | 1200 |
| session | 1350 |
| open_cursors | 1200 |
| java_pool_size | 100 MB |
Refer to the following links for standard definitions of:
Integrating the Healthcare Enterprise (IHE) Actors: http://wiki.ihe.net/index.php?title=Actors
IHE Profiles and Standards: http://www.ihe.net/profiles/index.cfm
IT Infrastructure Domain: http://wiki.ihe.net/index.php?title=IT_Infrastructure
Cross-Enterprise Document Sharing (XDS): http://wiki.ihe.net/index.php?title=Cross-Enterprise_Document_Sharing
The following diagrams illustrate the status values for an existing DocumentEntry object and new DocumentEntry object after a document relationship is applied to an existing DocumentEntry.
Note:
The Status column in the Doc_Entry database table indicates the status of that particular DocumentEntry object.where, DE01 is an existing document entry.
where, DE01 is an existing document entry.
Figure 4 Document Replacing an Addendum (APND) of an Existing DocumentEntry
where, DE01 and DE02 are existing document entries.
where, DE01 is an existing document entry.
where, DE01 is an existing document entry.
where, DE01 is an existing document entry.
Figure 8 Document Replacing a Transformation (XFRM) of an Existing DocumentEntry
where, DE01 and DE02 are existing document entries.
The following diagram depicts the status of both previous version of DocumentEntry and updated DocumentEntry when Update Document Set [ITI-57] transaction is executed against HRL.
where, DE01 is an existing document entry version and DE02 is a new version created.
The following diagram depicts the status of a DocumentEntry when Update DocumentEntry Status operation is executed against HRL.
where, DE01 is an existing document entry version. New version is not created.
Whenever a Register Document Set-b[ITI-42] transaction is executed against HRL, the newly created DocumentEntry or Folder is set with the status 'A'.
Whenever an Update Document Set [ITI-57] transaction is executed against HRL, the previous version of DocumentEntry or Folder is set with the status 'D' while the new version of DocumentEntry or Folder is set with status 'A'.
This section provides a list of commonly used acronyms.
DSUB - Document Metadata Subscription
HRL - Health Record Locator
IHE - Integrating the Healthcare Enterprise
MPQ - Multi-patient Queries
OHIM - Oracle Health Sciences Information Manager
XDS - Cross-Enterprise Document Sharing
XPID - XAD-PID Change Management Profile
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Oracle® Health Sciences Information Manager Health Record Locator User’s Guide, Release 3.0
E61283-01
Copyright © 2012, 2015, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.
 Copyright © 2012, 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
