1 HDR Components

Figure 1-1 Example of a typical HDR solution:

Description of Figure 1-1 follows
Description of ''Figure 1-1 Example of a typical HDR solution:''

Oracle Healthcare Data Repository (HDR) includes solution components critical to the creation of applications that support the management and provision of care in diverse healthcare settings. The associated functionality includes content from administrative, clinical and financial healthcare domain areas. This Programmer's Guide complements Oracle Healthcare Data Repository API documentation.

HL7 Reference Information Model (RIM) Version 3 provides a model of the healthcare domain, including compatibility with XML messaging. By focusing on standard interfaces, HDR makes it easy to build applications using industry standard tools (thanks to J2EE) and to interoperate with other healthcare systems (thanks to HL7).

The Java API is used by programmers to develop healthcare applications. The messaging interface is used to exchange data with other computing systems. HDR-based applications typically use both systems.

At an architectural level, HDR has three key interfaces with other software:

  • The Java Application Programming Interface (API): The Java API lets customers write applications using HDR services. Because services are exposed as Remote and Local EJBs, client code can either be co-located on the middle-tier with HDR, or reside on its own tier, communicating via Java RMI. See "Java APIs".

  • HL7 version 3 Based Messages: HDR supports the transmission of well formed HL7 version 3 messages that conform with the Oracle Healthcare Data Repository HL7 Version 3 Messaging Conformance Specification. This interface supports interoperability between HDR based applications and third party applications. See "Messaging Interface".

  • Services: The service interfaces are a standards based collection of Enterprise Javabeans (EJBs), each of which provides a functional service. Its architecture is driven by two complementary standards: Java 2 Platform, Enterprise Edition (J2EE) and HL7 Version 3. J2EE provides industry standard interfaces and protocols for the plumbing of the system. See "Services".

Services





Service Categories


    

  • 

    Client-side Classes: Represent the HDR public Java Applications Programming Interface, which includes an implementation of the HL7v3 Reference Information Model (RIM) and abstract data types specification.
    

    • 

  • 

    Foundation Services: Provide repositories for domain information. Enterprise Terminology Services (ETS) provide a centralized repository for storing coded medical terminologies. RIM Services provide a repository for storing any element of medical information that can be modeled in accordance with the RIM.
    

    • 

  • 

    Application Services: Provide higher level services based on the foundation services. HDR supplies the following application services:
    

      

    • 

      Inbound Message Processor (IMP): Provides for the receipt of HL7v3 messages.
      

      • 

    

    • 

  • 

    Configuration Services: Provide Java APIs for configuring various HDR aspects.
    

    • 

  • 

    Audit Services: Provide auditing of critical HDR functions.
    

    • 



Service interfaces are not EJB interfaces by themselves; they are implemented by bean wrapper classes that wrap EJB Local and Remote bean interfaces. Similarly, the server-side EJB implementations delegate to Application Modules (AMs) within the Oracle Application Development Framework (ADF, formerly BC4J). The EJBs themselves are stateless with container managed transactions.


This architecture provides several benefits:


    

  • 

    Bean Wrapper classes hide the differences between Remote and Local mode EJBs. This lets application developers switch deployment models with minimal impact on their own code.
    

    • 

  • 

    Container Managed Transactions (with some exceptions) let application developers use the Java Transaction API (JTA) to manage distributed transactions involving HDR and their own services.
    

    • 

  • 

    Stateless EJBs provide superior middle-tier scalability to stateful approaches.
    

    • 











Java APIs


HDR services are exposed to programmers through Java APIs, which include the following elements:




Client-side Service Classes


The classes described below are called client classes because in remote deployments they reside on the client application side of the network, while the service implementations themselves reside within an application server on a remote computer. All client classes required to use any HDR services are packaged together into a zip file hdr-client-1.0.0-SNAPSHOT.zip in the client directory of hdr-1.0.0-SNAPSHOT.zip. This file must exist in the class path of any application that uses HDR, along with supporting EJB classes.


    

  • 

    Data Transfer or Value Objects (DTOs): These objects represent snapshots of HDR's internal data model and are used to exchange data between HDR and client applications. Note that for the HL7 package these objects are called RIM objects and reside in the oracle.hsgbu.hdr.hl7.rim package.
    

    • 

  • 

    Factories: Factory classes are used to create data transfer objects for submission to HDR services. Different services use different factories, and some may use multiple factories.
    

    • 

  • 

    Service Interface: Each service has at least one corresponding Java interface. These interfaces contain methods that provide the functionality of the service. Services typically provide CRUD-style operations for some part of the HDR data model, but may also define higher-level business logic. The service interfaces do not provide business logic; business logic is defined by client-developed applications based on HDR.
    

    • 

  • 

    Fetches and Criteria Objects: These objects support the complex search and retrieval operations supported by many services. A criteria object defines a filter that specifies which objects to retrieve. Criteria are analogous to a SQL WHERE clause. A fetchmap defines the kind of data to be returned. It is analogous to a SQL SELECT clause. Criteria and fetches can refer to different (albeit related) objects. For example, a query may be defined to retrieve all encounters (the fetch) for a given patient (the criteria).
    

    • 



Client applications use the ServiceLocator class to retrieve a handle to a service, rather than instantiating services directly. The ServiceLocator provides a single point from which clients establish connections to HDR and access its services. Instantiating the ServiceLocator and establishing a session with HDR is described in "The Service Locator".










Integrating the Healthcare Enterprise (IHE)


HDR supports sharing documents that conform to IHE standards across healthcare enterprises. The documents are stored in an HDR repository, and metadata identifying the documents is stored in a Document Registry.


See also:


"Integrating the Healthcare Enterprise"








Messaging Interface


HDR can send and receive HL7 version 3 messages that conform with the Oracle Healthcare Data Repository HL7 Version 3 Messaging Conformance Specification, and HDR provides services that can parse and construct XML messages. These services are exposed in essentially the same way as normal HDR services and have a Java API that can be called programmatically by ISV (Independent Software Vendor) code.


HDR messaging services (IMP) can also be accessed through an interface engine and an adapter such as HDR Gateway, which is in turn responsible for the transport-layer issues of sending and receiving messages over the network. This is the typical way that messaging is used by an HDR application. The Implementation Guide describes how to configure the HDR Gateway.




Inbound Messaging Services


Healthcare enterprises typically operate a number of departmental systems such as ADT, diagnostic departments, pharmacy, and others that may be acquired from multiple vendors. Such systems require messaging services to communicate events and request actions from applications throughout the enterprise.


To route the message from the source system, an external interface engine that handles HL7 message translation and routing must be implemented for IMP (Inbound Message Processor) to function. Although a single interface engine is typically required, multiple interface engines can be implemented. An interface engine is not included with HDR. However, Oracle B2B/BPEL can be used as an Interface Engine.


The Inbound Message Processor (IMP) provides message interpretation, persistence, and acknowledgement services to HDR applications for processing inbound messages from external systems. IMP supports XML formatted inbound messages that conform to the HL7 version 3 messaging standard and compliant with messaging schemas of HDR supported message types.


See also:"HDR Messaging Services"










Concurrent Program Service for Scheduling Jobs


HDR provides a JMS queue based job scheduler service called ConcurrentProgramService, which is exposed on ServiceLocator as a stateless session bean. ConcurrentProgramService is used to schedule the following jobs.


Loading Messaging Metadata


Messaging metadata load can be scheduled as a background job using the ConcurrentProgramService.loadMessagingMetadata() API call. The API returns a request ID that can be used to monitor the job status using the ConcurrentProgramService.getJobStatus() API.


Loading MTK Schema to HDR Server


Messaging Toolkit (MTK) schemas from a local directory specified in the profile option value for profile code CTB_MTK_SCHEMA_DIR_PATH, can be loaded to HDR server location using the ConcurrentProgramService.loadMTKCustomSchema() API.


Loading MTK Interaction Schema to HDR Server


Composite message schema can be created using the Messaging Toolkit (MTK) custom interaction schemas using the ConcurrentProgramService.loadMTKCustomInteractionSchema() API.








Enterprise Terminology Services


Enterprise Terminology Services (ETS) is a core component of HDR that incorporates a range of terminology systems and provides extensive terminology services to HDR applications, including the following principal features:


    

  • 

    Consistent and real-time access to all terminology content - whether standards-based or user-defined.
    

    • 

  • 

    Support for standards-based terminologies:
    

      

    • 

      SNOMED, LOINC, and FDB terminologies through a specialized model (referred as Core terminologies in ETS).
      

      • 

    • 

      Other terminologies like ICD9, CPT4, and HCPCS through a generic model.
      

      • 

    

    • 

  • 

    Support for user-defined terminologies.
    

    • 

  • 

    High level of terminology integration - between different terminologies and between different versions of the same terminology.
    

    • 

  • 

    Support for user-defined containers of terminology content such as Concept Lists and Classifications. These containers can be used for building application interfaces, constraining and validating attribute values, and generating context-sensitive reports.
    

    • 

  • 

    Multi language support (MLS) on concept descriptions (except Classifications and editable terminologies).
    

    • 



See Also:


The Implementation Guide for the prerequisites and procedures necessary for the implementation of ETS Services.








Profile Option Services


Profile options are configurable preferences that affect the way an Oracle application looks and behaves. System administrators can control HDR behavior by setting profile option values. Application developers can control application behavior by programming their applications to perform in accordance with customized profile option values.


Examples of typical profile options include the following:


    

  • 

    Language: Determines the language in which the application is displayed to users.
    

    • 

  • 

    Date Format: Determines the format (mmddyyyy, ddmmyy...) for date displays.
    

    • 



System administrators can set profile options at the following levels:


    

  • 

    User (highest level)
    

    • 

  • 

    Org
    

    • 

  • 

    Site (lowest level)
    

    • 



The profile option values set at each level define runtime values for each user's profile options. An option's runtime value is the highest level setting for that option.


A profile option can be set at more than one level. When a profile option is set to more than one level, an order of precedence applies: Site has the lower priority, superseded by Org, which is further superseded by User. A profile option value entered at the Site level can thus be overridden by value entered at the Org level, and value entered at the Org level can thus be overridden by the value entered at the User level.


See Also:


The Implementation Guide for the prerequisites and procedures necessary for the implementation of Profile Option Services.




Create, Set, and Update Profile Options


The HDR ProfileOptionService enables users to manager profile options and its associated values at various profile levels.




Creating Profile Options


Create new profile options using the ProfileOptionService.createProfileOption API.


For example, a physician order entry application could define a profile option that defines the default sort order of patient problem lists (by date, severity,...).







Updating Profile Options


Update profile options using the ProfileOptionService.updateProfileOption API.









Create and Update New Profile Option Values


Create new profile option values for the already created profile options using the ProfileOptionService.setProfileOptionValue API.


You can update existing profile option values for the already created profile options using the ProfileOptionService.setProfileOptionValue API.










Audit Services


HDR auditing services let you log and monitor all HDR activities, to monitor security policy and regulation compliance by recording actions taken by users during sessions. Such actions could include invoking an API, performing a custom function, or other defined events.


HDR Configuration Manager, a GUI tool, lets security administrators define auditing policies. Implementation of HDR Audit Services includes the following steps:


    

  • 

    Enabling HDR Audit Services
    

    • 

  • 

    Initializing existing audit event types
    

    • 

  • 

    Creating new audit event types
    

    • 

  • 

    Invoking HDR Audit Services
    

    • 





Enabling Audit Services


The HDR Audit Service [AuditService] is a core HDR interface that lets you log and monitor HDR activities, to monitor security policy and regulation compliance—by recording actions taken during user sessions. Such event records can help detect actual or attempted violations of policy and operation procedures.


HDR Audit Services can be enabled (turned on) or disabled (turned off) globally. When enabled, audit events of all seeded and user-defined audit event types can be audited. When disabled, Audit Services is not operative.


Auditing is turned on or off by setting the profile option CTB: Auditing ON to Y or N respectively. By default, CTB: Auditing ON is set to Y on install. Use the ProfileOptionService to update this value. The profile option service API to update this profile option is:


ProfileOptionService.setProfileOptionValue










RIM Service


HL7 Reference Information Model (RIM) Version 3 provides a model of the Healthcare Domain, including compatibility with XML messaging. By focusing on standard interfaces, HDR makes it easy to build applications using industry standard tools (thanks to J2EE) and to interoperate with other Healthcare systems, thanks to HL7.