Kontakt

Ansicht
Dokumentation

ISH_HCM_CCPS_DO_CUST - SG: CCPS Customizing

ISH_HCM_CCPS_DO_CUST - SG: CCPS Customizing

Fill RESBD Structure from EBP Component Structure   ABAP Short Reference  
This documentation is copyright by SAP AG.
SAP E-Book

Procedure for Implementing CCPS Data Exchange

  1. Maintain the institution-specific agreements
Please specify the technical transmission data (sender specifications) for each institution. Also maintain the values for hospital identification. The following rules apply for CCPS: HP code 2 (field name ID2) contains the hospital code that is to be specified for outpatient cases; Hp code 1 (field ID1) contains the code for all other cases. If your hospital has only one code for both situations, please enter the same value in both fields.
You can store the corresponding values by choosing Maintain Agreements with the Institutions.
  1. Create the data collection points: Master data maintenance
Before transmitting data to a recipient, you must first create this recipient as a 'data collection point'. You do this by choosing Maintain Master Data of Data Collection Points.


  1. Maintain communication status
In the step Maintain Communication Status, please specify the communication statuses defined by the communication procedure and assign the appropriate internal codes to them (using Possible entries). You will find the external codes in the CCPS code list for "Status of Processing".
  1. Maintain application status
In the step Maintain Application Status, please specify the values defined by the communication procedure and assign the appropriate internal codes to them (using Possible entries). You will find the external codes in the CCPS code list for "Status of Processing".
  1. Activate data collection
CCPS data transfer has to be activated explicitly in the system. You activate this option in the Customizing activity Activate Communication Procedure. In the corresponding Customizing table you can specify for which communication procedure you want to carry out data exchange.
You should activate data collection only if data exchange takes place electronically. On no account activate this file creation if you are still exchanging data using forms (or any other means).
If you set this flag, corresponding background processing tasks must be installed (see below).

  1. File receipt and error processing
Planned as of Release 4.01
Program RNC301I0 takes charge of file receipt. In general, you should schedule this program to run on a regular basis (for instance, every evening). However, you can also execute it explicitly should you want to read and process messages for a particular institution or data collection point, for example.
After opening or reading the file whose name is dynamically determined from table NC301B (using the DCP-related sequential number of the file) the program performs a syntax check.
If the file structure is correct, the individual messages are processed. Each message is split up into single fields using the agreed field separator and is then transferred to the application where it is written to the database.
If internal errors occur, the messages are saved in table NC301W. Messages in which temporary errors (due to lock problems, for example) occurred can be automatically postprocessed by program RNC301I1. Messages containing other internal errors have to be checked by a clerk. You can display these incorrect messages using program RNC301I2.
  1. Maintain case exclusions
In production operation, it may be agreed with the recipient concerned that data relating to complicated cases should be communicated by other means. To prevent messages from being created and processed in such situations, you have to add the corresponding cases to the EDI case exclusion table. You can also create a short explanatory text for these entries.
  1. Activate HCM Monitor checks
It is practical to activate at least the standard background checks for EDI processing provided in the HCM monitor. For information on how how to proceed, please see Maintain Monitoring Checks.
  1. Most important steps for implementing CCPS data exchange
    1. Create the recipient in table NC301P.
    2. Maintain the directory specifications, standard, version and if applicable the character set for the agreements.
    3. Also specify the technical sender address and address type for the agreements.
    4. Maintain the same specifications for the sender (institution) and also the hospital codes.
    5. Specify the application status (Approved/Rejected) and communication status (First submission, Amendment) by assigning the codes required by Medinet to the internal values you can determine using Possible entries.
    6. Maintain the assignment of room categories to the accommodation services.
    7. Maintain the assignment of internal codes to external CCPS codes in the TNCMAPP table.
      The following fields are concerned here:
  • Nationality (T005-LAND1)

  • Nature of operation (TN14O-OPART)

  • Race (TN17R-RACE)

  • Referring source (TN14H-REFSRC)

  • Relationship (TN17B-RELSH)

  • Type of outcome (TN14B-BWART for inpatients and TN15D_ENDTY for outpatients)

  • Change reason (TNC301XI-EREASON)

  • Specialty (TNKFA_FACHR)

  • Source of admission + admission type (TN14G-GRUND)

  1. Now activate the CCPS procedure.
  2. Maintaining the IS-H data automatically triggers the CCPS processing in the background. However, the first data transfer is only initiated by the invoice or provisional invoice.
  3. First test the programs for formatting messages and creating files separately. You can then schedule these to run as a background job. For message creation you can specify whether or not you want to first process orders that have been created recently. If this is not the case, you specify the minimum age of the orders for the message formatting program. The more recent orders will then remain in the order table and will not be processed until the next program start.
  4. If you subsequently have to transmit data modifications due to hospital errors, you can use program report RNUCHREA to specify the change reasons.
  5. If you want to initiate message dispatch manually, execute program report RNCEDIU0.

CCPS Medinet 1.2 Standard

CCPS Medinet 1.2 has only been released for hospitals in Singapore that only need the limited range of required fields added since Version 1.1. Not all the fields added are filled as standard, but these can be filled by means of customer BAdI methods.

As of version 1.1, the following new fields are filled by the standard SAP delivery:

  • Discharge Ward Class
  • Country of Residence
  • Assisting Local Doctor SMC No.
  • Date of Birth of Payer (for Medisave)

Version 1.2 is activated with the corresponding assignment to agreements with data collection points in Customizing and thus allows flexibility of scheduling for hospitals implementing a new Medinet version.

SAP delivers Medinet 1.2 as a template and cannot be considered liable when hospitals implement this version, nor is SAP obliged to provide further developments of this version.






Vendor Master (General Section)   rdisp/max_wprun_time - Maximum work process run time  
This documentation is copyright by SAP AG.

Length: 9271 Date: 20240426 Time: 233500     sap01-206 ( 138 ms )