|
||||
         
|
Our own HLx for TelemedicineAuthors: Dr S B Gogia, Dr S B Bhattacharya SummaryA part of an initiative by IAMI, an attempt is being made to create a standardized method of record keeping for users of Telemedicine systems in India. The authors have attempted to create SQL statements for recording basic details of the patient, providing him a universally applicable unique ID which allows easy transfer of patient data across various clinics and hospitals. The provided script will be available as an open source over which vendors can create Telemedicine apps de novo or as an addition to the existing applications provided by them. After a review of existing HIS and EMR systems, some components of record keeping like history and existing prescriptions have been added as they should be essential components of a patient record and are important for decision making and patient management India is recognized as being in the forefront of the Information Technology revolution. What is less known is that besides having the best Software persons, our country also has some of the best healthcare professionals in the world. Our excellent facilities, our low cost have made our country a possible health tourism destination. But, while planning to provide outsourcing of medical facilities to patients from all over the world, we should remember that a large segment of our own populace has virtually no medical facilities within accessible reach. Telemedicine is expected to correct this imbalance to some extent. The Telemedicine revolution has overtaken many countries but we are yet to reap the proved benefits. Whatever isolated progress has taken place has been uncoordinated and unconsensual. The other feature has also been the lack of serious involvement of the medical community in these developments. Telemedicine networking is being hindered by a few problems These are:
Some of the above points are also opportunities. The lack of generalized availability of these apps means that a more co-ordinated approach can be made. Western Medical facilities had been computerized very early, mostly from pressure from Insurance companies. However, the similar vendor based approach made interchange of data very difficult. This lead to creation of standards of which HL7 is a very notable example and is now recognized as the de facto standard. However HL7 has been found unsuitable for our needs. This does not preclude us from creating our own standards. Availability of common record keeping processes will allow apps which talk with each other will ensure faster and painfree adoption of EMR systems as well as Telemedicine. With a view of these problems a common Telemedicine structure is being prepared to cover all centres in India by the Indian Association for Medical Informatics (www.iamindia.org). The author was officially appointed the co-ordinator of this preparation. This paper is being presented more as an approach document for consensus among our esteemed members. The Approach and DirectionIf we take any patient's record, it consists of several pages, the first page is the facesheet or patient card. Following that in sequential order is the patient's history and examination, Prescription, investigation reports, operation notes and then several pages of follow up notes, revised prescriptions, wherein the manual record becomes disorderly and confusing to browse through. However the first few pages are consistent. Doctors reach a diagnosis through their four of their five senses i.e. See (written reports, Examination, X ray, ECG etc), Hear (History taking, Stethoscope), Feel. (Examination), and Smell. Taste is almost never used for diagnosis. Similarly, a distant diagnosis through telemedicine should provide access to a similar (should we say sensible?) diagnostic reach. For transmission, the components of any record have to be broken into a computer (and distance) recognizable form. The same is shown in Figure 1.
What is to be remembered that if we need to transmit the data as shown in the figure it should be in a common mode, that is the computers should first talk with each other and perform a proper hand shake, something akin to a Fax transmission. Our general approach here, as should be, is to create an absolutely common mode for the facesheet, some commonality in the casesheet and thereafter have a more flexible data exchange modes for the less common portions of the records. However the investigations should be transmitted through recognizable media and all should be able to read them. Since the facesheet is the key component of the Record, it should be exactly the same. For that we are proposing first of all a concept of a unique Patient ID, which is exactly the same – at least for telemedicine purposes among all vendors. It is also felt that the unique patient id concept is required on similar lines all over the world and in the current concept of a globalized village, a patient can travel virtually anywhere to get the best possible treatment for his /her problem. General Details
Now we can analyze the general suggested flow for the proposed Telemedicine record keeping mode
Benefits of this sort of flow
Works even if data links are down Suggested ProtocolThe suggested protocol asks for the unique identifier app to run at all clinics/ healthcare service providers.
Some Remaining Issues (Some answers are already there in the MIT document, but need to be spelled out)Work required for Other items
There has been a question as to - Should we use DICOM / Proprietary PACS or Open Source? We believe that with the improvement of JPEG standards, as well as the fact that it is free, we should create images in open source. Telemedicine Structure scriptThis is the suggested first list for approval. The color codes for structure and comments should be obvious. Once converted to text this should be able to run through any RDBMS Location Id has to be included in each table. Which will help to identify a particular site. Table Patient_MasterThis is the key table,
*/ create table tm_user.patient_master ( tm_loc_id char(10) not null, //added by default to each row indicating the original organization – part of primary key for import purposes - The suggested protocol for loc_id is [Country code](Separator)[State code](Separator)[Location_code](Separator)[identity of doctor/clinic/hospital]. Suggested separator is underscore(_) or slash(/) tm_cr_no char(15) not null, // char is used to add year and other text which is mutually agreed upon.Relevant part specific to patient is auto incrementing value tm_opdno integer, //not essential - specific for location to remember daily number currently – may be used in future for a particular cause tm_admno varchar(15), //for future use or for specified id numbers generated as above tm_date date not null, // date first seen tm_prefix char(6), // Dr/Mr/Ms/ tm_fname varchar(30), tm_mname varchar(20), //suggested by MIT, I prefer only First name and last name tm_lname varchar(20), tm_age varchar(15), //age is a text field to allow possibility of days weeks, months and even hours. Number alone is by default years tm_sex char(1), //Male, female, unknown, indeterminate tm_address varchar(80), tm_city varchar(30), // use this to store district if rural patient tm_state varchar(35), //clickable from list – choice of merging it with location id tm_pincode numeric(7), //we use six in India - one digit extra for future use tm_telno varchar(30), //telephone numbers are always text as there are too many special characters tm_date_of_birth date, //do not make this essential as many do not remember – however entry of DOB creates automatic age entry tm_doc_incharge varchar(40), //Doctor maintaining records tm_status integer, //codes for OPD only, admitted, follow up, referred to others, LAMA, tm_referring_doc varchar(30), //Referring doctor or company paying (Insurance) tm_s_d_w_of varchar(30), //Father/LG/Husband Name tm_diagnosis varchar(99), //Initial Diagnosis - tm_marital_status char(4), //codes for married/single/divorced /widowed etc tm_nationality varchar(30), //clickable list tm_religion varchar(20), //clickable list tm_occupation varchar(20), //clickable list tm_spl_problems varchar(99), //Known Allergies, diabetes, hypertension for quick notification tm_email varchar(30), tm_bl_gr char(3), //Blood Group tm_image varchar(80), //link to one main photo of patient (send images separately) tm_prev_id varchar(30) // entry of record to link to for import /export , primary key (tm_loc_id, tm_cr_no) ); Index: patient_m_fname_idxcreate index patient_m_fname_idx on tm_user. patient_master ( tm_fname ASC); Index: patient_m_lname_idxcreate index patient_m_lname_idx on tm_user. patient_master ( tm_lname ASC);
/* Table: casesheet
Essential - allows multiple rows per patient but only one recommended no repeats at least for same date default entry of current datetiime in "tm_date" loc_id to be added to primary key */ create table tm_user.casesheet ( tm_cr_no char(15) not null, //dependent of patient master tm_loc_id char(10) not null, //dependent of patient master tm_date timestamp not null, //current time – part of primary key tm_index char(15), //auto increments through coding, visit number helps other person to see also allot his own numbers tm_cheif_complaint varchar(50), //presenting complaint – add duration to complaint tm_cheif_complaint1 varchar(50), //presenting complaint – add duration to complaint tm_cheif_complaint2 varchar(50), //presenting complaint – add duration to complaint tm_past_hx varchar(99), //Past problems. Allergies, operations tm_family_hx varchar(99), //Family disease and relevant details tm_history long varchar, //Can write a detailed history, coding from existing forms can convert to text tm_examination long varchar, //Can write a detailed examination, coding from existing forms can convert to text tm_findings varchar(99), //use this to store patient images – linked to file path tm_modified_on timestamp, //stores the time when it was last modified, same as tm_date for first time entry tm_diagnosis varchar(199), //diagnosis at time of current history tm_sec_diagnosis varchar(40) //2nd diagnosis at time of current history, or may be used as additional filed for misc information , primary key (tm_crno, tm_date, tm_loc_id) ); /* Table: prescriptionEssential - multiple rows per patient, date of creation is second primary key index (name may be changed) is autoincrement thru coding - loc_id to be added to primary key */ create table tm_user.prescription ( tm_cr_no char(15) not null, //dependent of patient master tm_loc_id char(10) not null, //dependent of patient master tm_date timestamp not null, //current time tm_index char(15), //auto increments through coding, visit number helps other person to see also allot his own numbers tm_hosp_course varchar(255), //progress since last visit tm_advise long varchar, //the actual prescription, may be converted to text from forms tm_opdno integer, //register entry number for that date or keep for future use tm_revisit datetime, //time for next appointment tm_curr_diagnosis varchar(180), //diagnosis for current treatment tm_curr_doctor varchar(50) //doctor creating the prescription , primary key (tm_cr_no, tm_date, tm_loc_id) ); /* Index: register_rx_idx */ create index register_rx_idx on tm_user.prescription ( tm_opdno ASC); / Table radiology This will additional to sending images separately. The same format to be used for all image forms including endoscopy, US etc, ECG should ideally be separate as its number will be of one type only */ create table tm_user.radiology ( tm_cr_no char(15) not null, //dependent of patient master tm_loc_id char(10) not null, //dependent of patient master tm_date timestamp not null, //current time of creation of Radiology image tm_radiology_no char(15), //use different sets of number for Ultrasound, Xray, CT etc - required for later searches as register entry number in local area of origin tm_invest_reqd varchar(50), //type and location of investigation –e.g “US Whole Abd” tm_final_report varchar(80), //summary of report – generally only this is sent tm_report long varchar, //Choice of sending this detailed report may allow reverse transfer tm_image varchar(255), //image file path, may add 2-3 images with default separators tm_s_no varchar(30) // used in importer area as source id , primary key (tm_loc_id, cr_no, tm_date) ); Table Messages standard Messages generated to be standardized across the network for all users */ CREATE TABLE messages ( msgid char(40) not null, //change from char to varchar msgtitle varchar(255), msgtext varchar(255), msgicon varchar(12), msgbutton varchar(17), msgdefaultbutton decimal(16, 0), msgseverity decimal(16, 0), msgprint char(1), msguserinput char(1) , primary key (msgid) );
/* Table user_id */ //User records for security and access definitions these are only suggested for smooth working and will not be exported. CREATE TABLE userid ( user_id char(6), password char(14), user_name varchar(30), perm char(1), primary key(user_id));
//Entries to the userid table the first entry has to be created through SQL as no separate form is provided. Vendors can create forms at their own level
INSERT INTO userid VALUES ( 'dba', 'G', //or any value which can be remembered 'DBA', 'D'); /* Table co_finyear*/ //Billing Year create table co_finyear ( co_comp_id numeric(3), tm_finyear_id numeric(3), tm_startdate datetime, tm_enddate datetime, primary key(co_comp_id, tm_finyear_id) ); AcknowledgementsThe authors wish to thank Ms Abhikalak Consultants for help in creating the exact SQL script
| Home |
About Us |
Members | Links | What's New | Contact Us | Our History | IAHI | Mentors |
© Indian Association for Medical Informatics, Webmaster - Webmaster | |||
