RDS Extended Edition includes all of the functionality of the standard edition as well as
The principal difference between the environments where the respective versions of RDS is employed is the way documents or the forms making up the medical record are issued.
In day hospitals, the admission is a very controlled process - RDS functions in a prescriptive way where the forms for the episode are generated and issued on demand. Consequently each document carries an identifier that is unique to that forms instance in that episode.
In a general hospital setting, some of the forms (principally admission or financial related documents) are handled in a prescriptive fashion. The balance of the forms however are going to be added to the chart in an uncontrolled manner. The extended edition offers several facilities to easily convert that paper chart into an EHR and also provide some quality assurance measures.
Each of the following methods can be used to uniquely identify a specific form for a specific patient. The scanning / identification processes do not require that documents of different types be separated for batch processing.
| Method | Components | Comment |
| Form Barcode + Admission Label with Barcode | The form carries a barcode (specific to the form e.g. MR24) that is included on the form when it is printed. The patient's association with a particular instance of the form is by a patient label carrying a barcode that is unique to the admission or episode. | The patient labels can be produced in quantity at the time of admitting and travel with the chart or they can be printed on demand. Barcodes can be placed anywhere and in any orientation. This is an absolute means of identification with strong QA benefits in identifying potential lost forms. |
| Automatic Form Recognition + Admission Label with barcode | RDS recognises the form (automatic de-skewing and sizing is applied) from a standard library. The patient's association with a particular instance of the form is by a patient label carrying a barcode that is unique to the admission or episode. | This is a very strong and robust means of identification with strong QA benefits in identifying potential lost forms. |
| Automatic Form Recognition + Zonal OCR | RDS recognises the form (automatic de-skewing and sizing is applied) from a standard library, or may use OCR to recognise the form type. RDS identifies the patient by searching specified zones for printed characters (OCR) that carry name, UR Number, etc. | This is a very convenient process as it does not change the way forms and charts are used in the workflow. If the OCR process is not confident in identifying the patient the identification will require subsequent operator intervention. Quality assurance reporting can identify the absence of forms that would typically be present in the chart for such an admission. |
| RDS generates the form(s) on demand. | A single barcode unique to that patient admission instance of the form. | An absolute identification process with absolute tracking of the form for loss in the workflow. |
RDS Extended Edition provides a growing suite of functionality and interfaces to allow it to work as part of a composite HIMS environment. Some of those items are
| Item | Comment |
| Microsoft SQL Server 2005 | The database is open for reporting. Extensive use has been made of stored procedures to minimise network traffic and optimise performance. |
| HL7 messaging | These types are supported; A01, A03, A04, A08, A28, A29, A31, A40, S12, S13, S14, S15, S26 |
| User Security | Active Directory, LDAP |
| Workflow Management | Integration with third party workflow managers via an extensive API and event triggers |
| Multi-Site and Multi-PAS | RDS allows for a single database to cover multiple locations with the one patient being held uniquely within RDS but possessing multiple UR or file numbers from potentially different PAS at the different locations |
| Data Security | RDS meets requirements of appropriate Evidence, Health Records, etc legislation as well as Australian standards for Electronic Document Management and Medical Records. |
| API | A COM-based API exposes all Dox functionality to third party applications, scripts, .NET, Java and any environment capable of accessing COM objects. The Dox GUI makes use of this same API for its functionality. |
| Web Service | The Dox document grouping and viewing capabilities are exposed via a web service for simplified embedding in other web applications. |