RCC for i.s.h.med MCI – Reusable Communication Components

RCC.adt allows you to transfer patient, case and patient movement data to external systems. It enables you to create ADT messages (HL7 version 2.5.1) based on changes to IS-H data via integration with IS-H event processing. Unlike with the asynchronous IS-HCM dispatch procedure, RCC.adt supports direct dispatch (independently of whether the programs RNCBLD00 and RNCSND01 have been run).

RCC.adt allows you to configure the assignment of IS-H events to HL7 structures and events. Assignments of HCM events and structures to HL7 ones and the logic for filling HL7 structures are returned in a form that you can use immediately and easily adjust or enhance.
You create messages entirely in NetWeaver AS ABAP, so you are in a familiar development environment with proven enhancement technology and yet are able to draw on all data available in IS-H/i.s.h.med when creating a message. You do not need any return connections/queries from Orchestra to create messages.

Our USP:

• HCM messages are bundled, so only one HL7 message is generated for a group of HCM events (deduplication of messages)

The components in RCC.ord allow you to implement order interfaces based on clinical orders. These enable you to send complete order items, or individual services requested in clinical orders, as OMG/ORM messages and receive order confirmations as ORG/ORR messages (HL7 version 2.5.1). You can update appointment data and order, item and service statuses stored in i.s.h.med. based on order confirmations.
You create messages and process the content entirely in NetWeaver AS ABAP, so you are in a famil-iar development environment with proven enhancement technology and yet are able to draw on all data available in IS-H/i.s.h.med when creating a message. The components we provide for creating and interpreting messages are optimized for easy enhancement using customer implementations. You do not need any return connections/queries from Orchestra to create messages.

The delivery includes a component to ensure that incoming messages are processed in the correct order. It is used to prevent inconsistencies, especially in the case of error situations that occur inter-mittently (e.g. lock conflicts). This component works at the case or patient level, so such issues will not shut down the whole interface.

Our USP:

• Dispatch can be configured to ‘order item’ or ‘service-based’ mode
• ORM and OMG messages and corresponding ORR and ORG
• OKR (object key repository) in inbound processing to take into account case revision and patient merge
• Configurable dispatch lock for prospective patients and order items without cases, with messages forwarded automatically afterwards
   

The components provided by RCC.drx allow you to receive documents and store them in i.s.h.med document management. You can receive results in structured text form as ORU messages (HL7 ver-sion 2.5) and post them as i.s.h.med PMD files. You create the target document type and the logic for assigning content during the implementation of each interface.

Alternatively, RCC.drx allows you to receive binary documents in the form of MDM messages (HL7 version 2.5), store them in an archive system via ArchiveLink or a Knowledge Provider interface and then post them as an i.s.h.med document type (PDF, XML or DTA). It is also possible to receive doc-ument links in the form of MDM messages (HL7 version 2.5) and post them as i.s.h.med document links. However, this may require additional implementations for the use of links. These must be add-ed on a customer-specific basis and are not part of RCC.drx. 

When you create documents in i.s.h.med, they are posted directly without generating batch input sessions. Any follow-up posting is done using i.s.h.med MCI standard functions. All the components mentioned above can be tailored to individual requirements using standard enhancement technolo-gy.
The delivery includes a component to ensure that incoming messages are processed in the correct order. It is used to prevent inconsistencies, especially in the case of error situations that occur inter-mittently (e.g. lock conflicts). This component works at the case or patient level, so such issues will not shut down the whole interface.

Our USP:

• OKR (object key repository) in inbound processing to take into account case revision and patient merge
• Reusable findings document type (PMD) for transferring structured results content from an ORU message

The MCI components included in RCC.dtu enable you to easily set up unaddressed document dis-patch so that you can transfer documents without specifying a particular recipient. As well as the document header data, the software transfers either structured content in the form of ORU messages or (PDF) print versions in the form of MDM messages (both HL7 version 2.5). 

To send structured content, the source must be a PMD document type. The rules for setting up the ORU messages must be specified during implementation. The software supports PMD file types with standard print formatting for MDM dispatch, and WordContainer file types (without format conver-sion) are still supported. 

i.s.h.med event control triggers the document dispatch, e.g. after document release or another status change. The components we provide for creating messages are optimized so you can enhance them easily using customer implementations.

Our USP:

• Inclusion of IHE XDS document metadata

RCC.dtd builds on i.s.h.med standard dispatch control, allowing you to transfer documents to select-ed recipients. Unlike with RCC.dtu, documents are only transferred if an explicit dispatch order has been triggered for them. As well as the document header data, the software transfers either struc-tured content in the form of ORU messages or (PDF) print versions in the form of MDM messages (both HL7 version 2.5).

To send structured content, the source must be a PMD file type. The rules for setting up the ORU messages must be specified during implementation. The software supports PMD file types with standard print formatting for MDM dispatch, and continued support for WordContainer file types (without format conversion) is also planned.
Document dispatch is triggered manually from the recipient list. The components we provide for creating messages are optimized so you can enhance them easily using customer implementations.

RCC.bar allows you to set up the interfaces for receiving and sending diagnoses and procedures as BAR messages (HL7 version 2.5), which are posted using IS-H standard functions. The components enable you to process messages relating to either diagnoses or procedures, or combined messages containing a mixture of diagnoses and procedures. Before being posted, diagnoses and procedures can be filtered and adjusted using customer-specific implementations.

The delivery includes a component to ensure that incoming messages are processed in the correct order. It is used to prevent inconsistencies, especially in the case of error situations that occur inter-mittently (e.g. lock conflicts). This component works at the case or patient level, so such issues will not shut down the whole interface. 
 

RCC.dft provides components for setting up service interfaces. These components enable you to receive case-related services as DFT messages (HL7 version 2.5) and post them via IS-H standard functions. Before being posted, services can be filtered and adjusted using customer-specific imple-mentations.

The delivery includes a component to ensure that incoming messages are processed in the correct order. It is used to prevent inconsistencies, especially in the case of error situations that occur inter-mittently (e.g. lock conflicts). This component works at the case or patient level, so such issues will not shut down the whole interface.

RCC.lab allows you to configure interface processes for receiving structured lab results in the form of ORU messages (HL7 version 2.5). The results are posted as i.s.h.med lab results (N2_LABOR). The processed message structure corresponds to the one in the program RN2GET02. As a result, existing interfaces can be converted in the sending system without any changes to content. Compared to the standard program, RCC.lab has the advantage that you can post directly without generating batch input sessions. Follow-up posting is done using i.s.h.med MCI standard functions.

The delivery includes a component to ensure that incoming messages are processed in the correct order. It is used to prevent inconsistencies, especially in the case of error situations that occur inter-mittently (e.g. lock conflicts). This component works at the case or patient level, so such issues will not shut down the whole interface.

The RCC components can be used as standalone components, or for optimum performance, they can be combined and integrated with the Orchestra interface server using OCI.com (LINK) as an adapter.