The following guide is general advice intended for third party IT support providers, to introduce them to Medilink, and various technical details of the system.
Medilink is a medical practice management system that's been in continual development since the early 90s.
Our focus is largely on specialists, although we do cater for mixed use (GP, Allied Health & Specialists can all be in one practice/one database).
Our desktop system includes the following modules:
-- Accounting (patient CRM, billing, reporting)
-- Medicare Online for claiming to Medicare & Health Funds
-- Integrated Tyro for claiming to Medicare/EFTPOS
-- Appointment Book (inc waiting lists, provider scheduling, SMS appointment reminders)
-- Document Management (letters & scans, send secure letters via HL7)
-- Clinical (consult notes, MIMS prescribing, view incoming result files HL7, print to path/diag img request forms)
We are moving towards modern web based platforms and have a product called Medilink Cloud which is being used by a dozen or so practices so far to view appointments, do basic billing/claiming/EFTPOS and task management - although it is admittedly still early days.
Our helpdesk details are as follows:
Phone: 1300 881 995
Email: support@medilink.com.au
Portal: https://help.medilink.com.au
Our office hours are 8:30 - 16:30 EST (we are Brisbane based). Email is probably the best way to get a hold of us for urgent or after hours enquiries.
Clients pay us a six monthly update and support subscription called MDS. This covers Medilink specific support. More info in our terms: https://www.medilink.com.au/TermsOfService.php
In terms of the technology:
The main application is a C++ exe called MPW2000.EXE. Pretty much everything else are C# .NET 4.x apps. These are all in the BIN sub folder.
A/V systems should have real-time scanners configured to exclude these binaries (and/or just the whole MEDILINK32BNT folder); scheduled overnight scans are fine though. MPW2000.EXE also needs to be excluded from DEP on Windows Servers.
We deploy updates manually via an installer. We notify users of availability via our Launcher screen (i.e. the main login screen when they start Medilink). Medicare Fee updates happen a couple of times a year in a similar methodology (notify on Launcher, they run an update tool).
The database is quite an old system called Paradox, which uses the Borland Database Engine. We have plans to migrate away from this (although that has been happening for some time - it's a complex situation).
Back-ups should focus on the MEDILINK32BNT folder of their server, i.e. the \\<THE_SERVER>\MEDILINK share. Especially the DATA/LETTERS/SCANS subfolders. Avoid real-time back-up systems even if they are incremental volume shadow copy etc as it will impact the database.
The database system is essentialy serverless** in that there is no central service. All clients access the data files directly. Borland uses lock files to ensure data integrity.
(**The computer where the data share is stored is the Medilink server, but really it's just where the data is stored.)
These lock files are probably one of our biggest support dramas though. If a client on the LAN drops out etc, it may leave tables locked to others. So often to fix problems we will be getting them to log out of Medilink and clearing \\<THE_SERVER>\MEDILINK\DATA\*.LCK files (this is largely automated though).
As a result the 2 most important factors in Medilink performance and reliability:
-- Drive on the server should be fast and unencumbered, (i.e. use an SSD, and ensure it isn't doing intensive things like page filing etc).
-- Network should be fast and reliable, (i.e. all gigabit or better, no WiFi - one flaky client can take down all others).