Kontakt

Ansicht
Dokumentation

SIMG_ISHMED_CADEVDOC - Description of File Interface

SIMG_ISHMED_CADEVDOC - Description of File Interface

ABAP Short Reference   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.
SAP E-Book

Various parameterized documents are available for the creation of findings and logging of cardiological examinations. Some of the data entered is stored on the device during the examination. Such data must then be transferred into the processed document at the time of logging or findings creation.
For this a file interface is configured which enables the evaluation of ASCII files with any structure (for example, XML, HL7) and the transfer of examination results.
The files with the examination data are collected in a directory and transferred individually to the interface using a report. For this purpose you can use the report RN2DS_COLLECT_ALL_FILES which is supplied. When the report is run, data is formatted and initially saved in the SAP database. During the processing of a document you can use a pushbutton to transfer corresponding examination results from the database.

It is possible to import the file contents via direct file transfer, previous FTP transfer, or using HCM technology.

For each device type to be connected, an (incoming) directory must be created on an application server of the SAP system.
If the data is procured with the report RN2DS_COLLECT_ALL_FILES, the directory must be structured as follows:
The directory mustcontain a file called 'inbound_readme.txt', the interface will check the existence of this.
Below this directory there must be directories called
\work as the work directory
\save as the save directory for transferred files (test phase)
If you wish to use RN2DS_COLLECT_ALL_FILES with FTP you must also define some settingsfor SAPFTP.
The files must be ASCII files and may only contain characters, the code of which is known in the system code page of the SAP system. This should be taken into account particularly when selecting separators.
The number range object ISH_NCI0 is used for logging.

  1. Format files and save measured data in the database (without HCM)
    1. Technical settings (same as for HCM use)
      For each device to be connected, you create a logical system (transaction ONC6 ) and maintain a TXCOM entry for receipt.
      You should refer to the details of the technical settings.
    2. Customizing for interface information / formats
      Make an entry for the symbolic destination for data receipt (TXCOM) in table TN2DEVICES. You must enter the following data:
      Name of Transfer File
      Separator in File Path ( / or \ )
      Description of Ext. Date Format (e.g. DD.MM.YY)
      Description of Ext. Time Format (e.g. HH:MM:SS)
      Sex - Female
      Sex - Male
    3. Process in the interface
      For report RN2DS_COLLECT_ALL_FILES a variant using the name of the logical systemis created.
      The report is scheduled as a periodic job and monitors the Incoming directory (TXCOM-TP_NAME).
      Each transferred file with measured data is first moved to the work directory and then individually placed with the agreed file name (from TN2DEVICES) in the incoming directory. This file is further processed using the function module ISH_N2_DS_PROCESS_FILE.
      The successfully processed file is deleted and the job log contains the message concerning the number of processed messages (number of examinations) of the file. The corresponding original file is stored in the /save directory, if necessary (according to parameter Save Files) and deleted in /work.
      In case of a logical error, the interface file remains in the directory and the corresponding original file is retained in /work.
      In this case the next file is processed.
      If one of the files is incorrect, the job is canceled and the error messages are contained in the
      job log.

      The transferred data is then logged for each file as a message in table NCI0. The logs can therefore be processed with the HCM tools. However, detailed display of the fields is not possible using HCM, as the data structure is not available in the system.
      If you select 'Long Log', the system logs the entire content of the file row by row. If the indicator is not set, the system only displays the first 1024 characters of the file.
  2. Get files with HCM and save measured data in the database
    1. Customizing for HCM
      A prerequisite is that the interface file with an agreed name must exist on a directory of the application server of the processing SAP system.
      For each device to be connected, create a logical system using transaction ONC2 - with presetting – and maintain the entries for the system attributes, TXCOM, and receipt control.
      You should refer to the details of the technical settings.
    2. Customizing for interface information / formats
      A entry must exist in table TN2DEVICES for the symbolic destination for data receipt (TXCOM). Here you must enter the following data:
      Name of transfer file
      Description of Ext. Date Format (e.g. DD.MM.YY)
      Description of Ext. Time Format (e.g. HH:MM:SS)
      Sex - Female
      Sex - Male

    3. Process in the interface
      The file with the measured data is sent, with the agreed fixed file name, into the specified directory (name/path see command file).
      For report RN2DS_COLLECT_ALL_FILES a variant is created under the name of the logical system.
      The report is scheduled as a periodic job (parameter Type of Data Transfer: via HCM) and transfers the existing file for further processing using function module ISH_N2_DS_PROCESS_FILE.
      The individual records (message segments, rows) must end with carr.returnlinefeed and should not be longer the 4096 bytes (see description of HCM in transaction SPRO).
      Only the HCM functions for reading (ISHCM_RECEIVE_TABLE) and confirming (ISHCM_RESPOND_TABLE ) are used. The data is actually processed in separate programs.
      Using HCM the file is first locked and renamed ... .tmp.
      If processing is successful, the processed file is deleted and the job log contains the message concerning the number of processed messages (number of examinations) of the file.
      In case of a logical error, HCM resaves the file under the name .. .dat. If a new file has already been sent, the content of the incorrect file is attached to the new file. In this case, processing is canceled and the corresponding error message is inserted in the job log. Following uncontrolled aborts the ... .tmp file is retained in the directory; it must be deleted or provided again as an interface file, depending on the situation.

      The transferred data is logged as a message in table NCI0. The logs can therefore be processed with the HCM tools. However, the fields cannot be displayed in detail using HCM, as the data structure is not available in the system.
      If you select 'Long Log' the entire content of the file is logged row by row. Otherwise only the first 1024 characters of the file are displayed.
  3. BAdI for formatting data to be saved
    Since the files in the interfaces can exist in various proprietary formats, the concrete formatting is accommodated by a BAdI.
    The method PARSE_DATA method of the BAdI ISHMED_DS_PMDDEVICES must be implemented for the symbolic destination in use (TXCOM entry for data receipt).
    The data exists in tabular form from strings and must be converted into a table of the row structure N2DSDEVICE_DATA. In particular, the attributes required for later assignment
    Institution
    Symbolic Destination
    Examination Date
    IS-H Patient Number
    R/3 gender indicator
    Patient Last Name
    Patient First Name
    Birthdate
    are placed in separate fields.
    In addition to these primary selection fields, the content of
    Examination Type
    Case
    Order Number
    Service Number
    Examination Type
    are separated and can later optionally be used during data assignment.

    Any errors determined must be returned to a message table, in order for them to appear on the job log.
    The data formatted by the BAdI is saved in the database by standard processing.
  4. Import measured data from the database into a document
    1. Customizing for data retrieval
  • Interface - document assignment dep. on OK code
    In table TN2DEVDOC_ACT the symbolic destination of the device, from which the data is imported, is determined for the document category, version and OK code in use. If data of various examination types is received from the interface, the expected examination type can be entered here.

  • Maintain field mapping per document category
    Mapping information is required for data import into a document.
    In table TN2DEVDOC_CUST you enter which data field of the document (alias name) is filled by which device data field. In "External Code" you may need to enter a path, which uniquely identifies the external field.
    The entry is considered to be connected with the BAdI for data formatting and complies with the requirements of the implementation for the existing data structure.

  1. Calls in user exit of PMD
    In document category definition a user exit must be provided, which is responsible for the data import.
    The symbolic destination is taken from table TN2DEVDOC_ACT. An object of class CL_ISHMED_DS_DEVICES is created and the READ_DATA method is called. The user exit Z_DO_DEVDATAof the sample documents usually undertakes this task.
    The result is a table with examination data and its assignment to document fields, which must then be further processed.
    Since very different file structures can exist in the device interface, a BAdI must also be implemented for data retrieval and assignment (see below).
    Optionally, the READ_DATA method can supply the key of the selected data record, so that this information can be saved in the document. This information can be used to identify the imported data record, and, following successful data transfer, to flag the device data record for deletion (table N2DSDEVICE_DATA).
  2. Selection of measured results from the database The examination results are saved in table N2DSDEVICE_DATA and are "suitably" selected by the READ_DATA method of class CL_ISHMED_DS_DEVICES in the following sequence:
    1. Selection by institution, symbolic destination, examination date, patient number and patient data (last name, first name, birthdate).
    2. Selection by institution, symbolic destination, examination date, and patient data.
    3. Selection by institution, symbolic destination, examination date

    If several search results exist, patient data does not match or one of the required attributes, such as the examination type, does not exist, manual selection is necessary.
  3. BAdI for formatting measured results
    The actual formatting of measured results for a document is accommodated by a BAdI.
    The method PARSE_AND_MAP of the BAdI ISHMED_DS_PMDDEVICES must be implemented for the symbolic destination in use (TXCOM entry for data receipt).
    The data is stored in a table of the row structure N2DSDEVICE_DATA and must be converted into a table of row structure RN2DSDEVDOC_IMP. Any errors determined must be returned in a message table, in order for them to be displayed in the document dialog.
  • Delete no longer required data
    After a certain period of time, table N2DSDEVICE_DATA contains a wide range of data records that are no longer required.
    You can use the report RN2DS_DELETE_DEVICE_DATA to purge this table.
    If you wish to work with the deletion indicator, the imported record must be flagged accordingly in the document following the data import (see example user exit in sample documents).






    • rdisp/max_wprun_time - Maximum work process run time   CPI1466 during Backup  
    This documentation is copyright by SAP AG.

    Length: 12955 Date: 20240607 Time: 152844     sap01-206 ( 204 ms )