Virtual Reality

[Ref.: Jerry Isdale, Version 2.1, Oct 8, 1993]

Virtual reality is a way for humans to visualise, manipulate and interact with computers and extremely complex data (according to The Silicon Mirage).

The visualisation part refers to the computer generating visual, auditory or other sensual outputs to the user of a world within the computer. This world may be a CAD model, a scientific simulation, or a view into a database. The user can interact with the world and directly manipulate objects within the world. Some worlds are animated by other processes, perhaps physical simulations, or simple animation scripts. Interaction with the virtual world at least with near real time control of the viewpoint is a critical test for a 'virtual reality'.

A number of uses of virtual reality in medicine is currently available. Rendering of 3D images from CT or MRI or Ultrasound scans - like Spiral CT scanning, tele-endoscopy, tele-angiography, etc. Note-worthy points being that CT scans deliver the maximum x-radiation and ultrasounds (till mid-1999) do not all in any manner or form. MRI delivers magnetic radiation and their detrimental effects are still being debated, but are mostly expected to be minimal.

While CT scans are vital for bony structures, MRI is excellent for soft tissues. MRI's cannot visualise bones as well as CTs can, but CT cannot produce saggital (longitudinal) sections of the body, only coronal (transverse) while MRI can. Ultrasound is mostly used in the studies of the foetus since the safety of any other scan (CT/MRI) has not been established to any comfortable levels.

Such machines that are capable of rendering virtual reality images have a prohibitive price tag and undergoing procedures using such machines are consequently expensive. However, as more and more medical professionals opt to use the capability that these machines impart to their effectivity of treatment, it is expected that the use of these machines would become more widespread, their costs would come down and therefore the prices that the patients would have to pay more affordable.

The telemedical network can store these images and they may be retrieved as and when necessary. Hence, even if the patient has to go to some particular place to undergo the procedure, the images can be viewed time and time again by medical personnel having access to the database.

This would also allow for better training of personnel. 3D images an be used for demonstrating and practising various invasive procedures using virtual reality tools like the cockpit/cab compartment or the desktop as the screen and a sensor-enabled glove. The student may devote long stretches of simulation hours of practise in order to perfect his skills without endangering lives. Various situations, all of them taken from real-life, may be encountered and the student evaluated and perfected in his techniques.

There is an interesting area of VR called "haptics", which is the generation of touch and force feedback information. It being a very new science and very few studies done on rendering of true touch sense, almost all systems till 1993 have focused on force feedback and kinaesthetic senses. These haptic rendering systems can provide good clues to the body regarding the touch sense, but are considered distinct from it. They could however allow for "virtual" touching too, and if and when it does so, it shall be none too soon. [Top]

Fuzzy Logic

[Ref.: "What is Fuzzy Logic?", © Togai Infralogic, 1993]

Introduced by Dr. Lofti Zadeh of U.C. Berkeley in the 1960s, fuzzy logic is a superset of conventional (Boolean) logic that has been extended to handle the concept of partial truth - i.e., truth values between "completely true" and "completely false".

A fuzzy expert system is an expert system that uses fuzzy logic instead of Boolean logic where something either true or false and nothing else. Fuzzy logic essentially is a collection of membership functions and rules that are used to reason about the data. The rules are usually in the form as follows:

if x is low and z is high
then y is medium

where x and z are known data values (input variables) and y is computed data value (output variable), low is a membership function defined on x, high defined on z, and medium on y. The part of the rule between the "if" and "then" is the rule's premise or antecedent, which is a fuzzy logic expression that describes to what degree the rule is applicable. The part following the "then" is the rule's conclusion or consequent, which assigns a membership function to each of one or more output variables. Most tools for working with fuzzy expert systems allow more than one conclusion per rule. A typical fuzzy expert system has more than one rule and the entire group of rules is collectively known as rulebase or knowlegebase.

Next, we need to know how to apply this knowledge to specific values of the input variables to compute the values of the output variables and this process in referred to a s inferencing. In a fuzzy expert system, the inference process is a combination of four subprocesses: fuzzification, inference, composition and defuzzification (optional).

I do not wish dwell too much on this aspect as it tends to become progressively heavier and one would dizzy spells from all this fuzzy stuff. I have mentioned this point here because an excellent area for application of this type of logic is in the field of medical sciences where 2 + 2 can be anything (within a reasonable range, of course). Being an imperfect science, where almost the same signs may either mean the same disease or completely different ones and only progressively costlier investigations and evaluation by experts can actually bring forth the correct diagnosis, Clinical Decision Support Systems (CDSS) need to have a certain degree of fuzzy logic incorporated within it to be of any significant value. [Top] [Elaboration]

List of Codes

Each of the following have their own distinct use. The visitor is requested to visit relevant sites for detailed discussion on each of these. I plan to write an overview of each of the following in near future.

Read Codes - Clinical Classification of Medicine, by Dr. James Read, UK
EUCLIDES - European standard for clinical laboratory data exchange
LOINC - Laboratory Object Identifier and Numerical Code
SNOMED - Systemised Nomenclature of Medicine
SNOMED-RT
CPT 4 - Current Procedural Terminology
CPT 5 - The 5th revision of Current Procedural Terminology
ICD 10 - International Classification of Diseases 10th revision
ICD 9-CM - International Classification of Diseases 9th revision-Clinical Modification
DRG Databases
IUPAC Codes
ACR - Index for Radiological Diagnosis
NDC - National Drug Codes
NANDA - North American Nursing Diagnosis Association
DSM-IV
UMDNS - Universal Medical Device Nomenclature System
NIC - Nursing Intervention Classification
CDT
UMLS - Unified Medical Language System [Top]

Use of Codes

The use of codes makes a lot of sense. Medical professionals, especially doctors are notorious in not only the use of medical jargon but also in expressing the same idea in various ways. {No wonder a number of them have been great literary figures - Sir Arthur Conan Doyle, the creator of Sherlock Holmes was one!}

Unfortunately, this creates an immense problem for such simple creatures as computers are. They are unable to interpret humans at the best of times, (after all their world is so marvellously simple, consisting of a series of 1's and 0's only) and then to figure out semantics and hidden meanings a bit too much.

Such confusion is rampant but the consequences have mercifully been limited because mostly the computers store and retrieve data verbatim and let the humans figure out for themselves what they might or might not have meant. This has its own drawback - the humans are confused instead, thereby defeating the very purpose of the use of such immensely costly systems. If the nurse did not understand 100% what the doctor meant, just imagine what consequences would that have, mind simply boggles at the very thought.

So, a device needs to found out to eliminate as far as practicable this state of seemingly perpetual confusion. The way out is to learn the lesson from the marvellous world of computers themselves. They "talk" to each other through codes, why not use codes (not necessarily a series of 1's and 0's) instead. Some code(s) that can be reasonably understood with less chance of confusion.

The other offshoot of use of codes is the ease of data transmission. Since codes are all that are transmitted, and they being smaller in size, the data loss and development of faulty or cryptic data is minimised.

Moreover, in the telemedical context (particularly in the manner in which I envisage telemedicine to be like, i.e., a world-wide network where medical personnel can freely collect information) the inevitable requirement would be is to find a way whereby a German-speaking doctor could communicate with his French-speaking colleague, each interacting in his own language and the other understanding with equanimity. This is possible because both of them are interacting with the computer using codes.

The same code mean the same thing in the various languages. The downside is that there has to be a translator of sorts that can effectively translate the code into the desired language. Softwares can handle this and because of the high processing power of the present day computers, the time lag is barely significant.. [Top]

Explication of the Codes

Now, if the above does sound confusing, if not downright intimidating, perhaps I can use a corollary to try and describe what is going on.

If you care to remember, DNA strands are nothing but a sequence of nucleic acid bases that are nothing but codes, which give rise to specific proteins. A particular set of DNA with a string of nucleic acid bases interlined in a specific manner determines what it ultimate protein or sequence of amino acids that it will translate itself into.

Without going into too much detail, it may be recalled that the DNA by itself does not do anything. It is the tRNA (transfer-RNA) that copies the bases (or codes) from within the nuclei. The tRNA chain then comes out of the nuclei in to the cell and is again copied in to mRNA (messenger-RNA). Both the tRNA as well as mRNA have a beginning (initiator) code and an end (terminator) code. This code is made up of sequence of three nucleic acid bases, and a specific set of bases cause a particular amino acid to be tagged. Different amino acids tagged on to each other in a specific sequence gives rise to a specific protein. The presence or absence of even one amino acid could at times prove lethal as the protein so formed could be incompatiable with the healthy existence of the organism in which it has been formed.

All that the ribosomes, which actually does the reading and translating of the code and then generating the specific protein from the amino acids, actually does is to read the initiator (or the header) base of the RNA string as brought to it by the mRNA (messenger-RNA) and then tag the various amino acids according to the bases of the RNA on to each other.

Once the terminator (or footer) base is encountered, the ribosome ceases to tag any more amino acids on to the protein and releases the protein as being complete. If, for any reason there is any fault in the copying process (DNA to tRNA or tRNA to mRNA) or in the DNA base sequence itself, whereupon faulty proteins are generated, it really is not the ribosome's problem.

All codes may be thought of as the nucleic acid bases, and the codes as the DNA or RNA. The ribosome is the programme that reads the codes and the protein as the regenerated original data that the code represents. As faulty proteins could be life threatening, faulty decoding of the data could prove lethal too.

Mother nature has made elaborate arrangement by way of natural laws for the accurate generation of proteins. Similarly, these codes perform the same function of attempting to generate an accurate information. [Top]

Health Level 7 [HL7]

[I have decided to devote a whole section to this particular topic because I am totally convinced that this one standard is absolutely necessary for any telemedical project to be of any significant value, especially of a world-wide network. Here I have only given the summary. Some examples I have taken from a series of papers published by the HL7 organisation. For a more detailed discussion, please follow the relevant links obtainable from most search engines...]

Established in March 1987 on the occasion of a conference held by Dr. Sam Schultz at the Hospital of the University of Pennsylvania, HL7 became an ANSI accredited standards developing organisation in June 1994. Since then HL7 is participating in ANSI's Health Information Standards Board (HISB).

HL7 or 'Level 7' refers conceptually to the definition of the highest level of the Open System Interconnected (OSI) model of the International Standards Organisation (ISO) which is that of an application-to-application interface placed in the seventh layer of the OSI model.

The HL7 standard is primarily focused on the definition of the -

data to be exchanged
timing of the exchanges, and
communication of certain application-specific errors between the applications

The protocols that refer to the lower layers of the OSI model are sometimes mentioned to help implementors understand the context of the Standard. They are also sometimes specified to assist implementors in establishing working HL7-based systems.

The standard currently (1998-99) addresses the interfaces among various systems that send/receive:

patient admissions/registration, discharge or transfer (ADT) data
queries
resource and patient scheduling
orders
results
clinical observations
billing
master file update information
medical records
scheduling
patient referral
patient care

The primary goal is to provide standards for the exchange of data amongst the various healthcare computer applications that eliminate or substantially reduce the custom interface programming and programme maintenance that may other wise be required.

The standard does not try to assume a particular architecture with respect to the placement of data within applications. Instead it is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Instead, HL7 serves as a way for inherently disparate applications and data architectures operating in a heterogeneous system environment to communicate with each other.

The very nature of the diverse business processes that exist within the healthcare delivery system prevents the development of either a universal process or data model to support a definition of HL7’s target environments. In addition, HL7 does not make a priori assumptions about the architecture of healthcare information systems nor does it attempt to resolve architectural differences between healthcare information systems. For at least these reasons, HL7 cannot be a true "plug and play" interface standard.

The message formats prescribed in the HL7 encoding rules consist of data fields that are of variable length and separated by a field separator character. The rules describe how the various data types are encoded within a field and when an individual field may be repeated. The encoding rules will be applied where the environment does not include relevant software to do the encoding.

The data fields are combined into logical grouping called segments. These segments are separated by segment separator characters. Each segment begins with a 3-character literal value that identifies it within a message. Segments may be defined as required or optional and are permitted to be repeated.

Individual data fields are found in the message by their position within their associated segments.

All data is represented as displayable characters as in ASCII displayable character set (hexadecimal values between 20 and 7E, both inclusive) unless modified in the message header segment. The field separator is required to be chosen from the ASCII displayable character set. All other special separators and other special characters are also displayable characters, except that the segment separator is the ASCII CR (carriage return or Enter) character.

A special point of interest is the fact that HL7 standard allows one to use any code, even one that has not been created yet, to be used for transmission of data. The only point that must be taken care of is that the receiving system must be able to recognise the code and interpret the code correctly.

It makes common sense to create a standard that may help in accurately reading data, especially medical data. HL7 is currently in revision 2.3 (mid-1999) and understandably requires careful consideration and handling.

Just a small taste of a sequence of HL7 message and its meaning is as follows. {I will add an elaboration to this topic in a couple of months time and try to make it less confusing than what it appears to be.} It is quite complex (although appearances are deceptive as the saying goes). However, it still demonstrates the point that it provides a sound platform for transmission of a number of diverse types of data and codes with respect to telemedicine. (I have taken all of these examples from a paper on HL7 from the HL7 organisation. So all credits are to them, and not me. The translation has been "touched up" by me. I am not happy with this section as it written right now, I shall therefore revise it asap. So watch this space. I shall do this over and above the promised elaboration.)

Delimiter Values: Segment Terminator is <cr> i.e., carriage return or hex 0D and it terminates a segment record. Field Seperator is | and it seperates two adjacent data fields within a segment. It also seperates the segment identifier from the first data field in each segment. Component Seperator is ^ and it seperates adjacent components of data fields where allowed. Subcomponent Seperator is & and it separates adjacent subcomponents of data fields where allowed. If there are no subcomponents, this character may be omitted. Repetition Seperator is ~ and it seperates multiple occurrences of a field where allowed. Escape Character is /

AD - Address

Components: <street address (ST)> ^ < other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ <address type (ID)> ^ <other geographic designation (ST)>

Example: |10 ASH LN^#3^LIMA^OH^48132^USA|

Translation: [field seperator] 10 ASH LN {Lane} (Street Address - the street or mailing address of the person or institution) [component seperator] # 3 (apartment or suite number) [component seperator] LIMA (city name) [component seperator] OH (Ohio - State or province) [component seperator] 48132 (Zip or postal code as a string) [component seperator] USA (country ID according to ISO 3166) [field seperator].{ The rest is not supplied as it was not necessary.}

CE - Coded Element

This data type transmits codes and the text associated with the code. To allow all six components of a CE data type to be valued, the maximum length of this data type must be at least 60.

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>

Example: |F-11380^CREATININE^I9^2148-5^CREATININE^LN|

Translation: [field seperator] F-11380 (Identifier - Sequence of characters (the code) that uniquely identifies the item being referenced. Different coding schemes will have different elements here.) [component seperator] CREATININE (Text String - Name or description of the item in question. E.g., myocardial infarction or X-ray impression. Its data type is string ) [component sperator] I9 (name of coding system as a string - Each coding system is assigned a unique identifier. This component will serve to identify the coding scheme being used in the identifier component. The combination of the identifier and name of coding system components will be a unique code for a data item Each system has a unique identifier. ASTM E1238-94, Diagnostic, procedure, observation, drug ID, and health outcomes coding systems are identified. When an HL7 table is used for a CE data type, the name of coding system component is defined as HL7nnnn where nnnn is the HL7 table number.) [component seperator] 2148-5 (Alternate identifier as a string) [component seperator] CREATININE (Alternate text) [component seperator] LN (name of alternate coding system) [field seperator] These three components are defined analogously before for the alternate or local coding system. If the Alternate Text component is absent, and the Alternate Identifier is present, the Alternate Text will be taken to be the same as the Text component. If the Alternate Coding System component is absent, it will be taken to mean the locally-defined system.For HL7-defined tables which have not been adopted from some existing standard, the third component, "name of coding system," is constructed by appending the table number to the string "HL7." Thus, the field RXR-2-site, is a CE data type which refers to HL7 table number 0163. Its "name of coding system" component is "HL70163".

CK - Composite ID with Check Digit

This data type is used for certain fields that commonly contain check digits, e.g., PID-3-patient Identifier list. If a site is not using check digits for a particular CK field, the second and third components are not valued.

Components: <ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)>

Example: |128952^6^M11^ADT01|

Translation: [field seperator] 128952 (ID number as a number) [component seperator] 6 (Check digit as a number - The check digit in this data type is not an add-on produced by the message processor. It is the check digit that is part of the identifying number used in the sending application. If the sending application does not include a self-generated check digit in the identifying number, this component should be valued null.) [component seperator] M11 (Code identifying the check digit scheme employed. The check digit scheme codes are defined in HL7 table 0061. Here M11 indicates that modulation 11 algorith is being used) [component seperator] ADT01 (Assigning authority HD or Hierarchic Designator- The assigning authority is a unique name of the system that creates the data. It is an HD data type. It is equivalent to the application ID of the placer or filler order number. Assigning authorities are unique across a given HL7 implementation.) [field terminator]

[Top] [Elaboraton]

Natural Language Processing (NLP)

The area of use of NLP in medicine could be in medical transcription and feedback from the computer. Medical personnel would be immensely benefited if they could interact with the computer by using speech. Manipulation of the images would definitely require the use of some pointing devices (like the trackball/joystick/mouse/pen/touch-screen), but the machine could still provide the feedback using voice.

The doctors could of course feed in/retrieve data or query the database using their own voices and the machine would present the data in an useful manner (i.e., talk back or ask for further clarification in cases where such are necessary). Graphical depiction of statistical data and analysis thereof. [Top]

Video-Conferencing

[I owe immense gratitude towards Mr. Mark Brommeyer of Australia for the immense help he has provided me by giving me the addresses of Australian sites (especially in the Queensland area) where this is being actively used. Without this help, I could not have written this section and, worse, would have hopelessly clung on to the notion that video-conferencing is not an useful area for telemedicine. When I initially did my research in 1997, the general consensus amongst developers and users of Telemedicine was that video-conferencing of not much use because of the low quality of pictures transmitted. How much change took place in 2 years time that one can only watch with wonder at the times to come.]

The current telemedicine facilities use tele-conferencing technology to allow people (medical personnel, administrators, insurers, health care providers, patients, their relatives, etc.) in various locations to meet for improving health care without travelling. The current practice incorporates the use of medical image (x-ray/ultrasound/CT/MRI scans), video-conferencing consultations, multi-disciplinary and specialist support, along with CME.

Such telemedicine facilities are basically video-phones (i.e., phones that allow the callers to see each other while talking) most commonly done using digital telephone lines. It is expected that this will necessarily lead to faster diagnosis and early start to the treatment.

Increasingly, tele-conferencing is used by major medical conferences to connect delegates world wide and also demonstrate procedures (also carrying out "live" surgeries) where every move made by the surgeon is seen by all. Simultaneous question-answer sessions can also be held. This has not only greatly enhanced the effectivity of such conferences but also allowed for faster upgrade of one's skills and knowledge base without having to travel a lot.

Not only procedures but also presentations by delegates may be made - with the presenter being in London and the actual conference in Canberra (the presenter may have bleary eyes since there is around 9-hours difference between the two, well, nobody is perfect and neither all situations!) or vice-e-versa.

Tele-imaging systems send images from one point to another through digital computer assisted transmission, typically over standard telephone or ISDN lines, satellite connections or over a local area network. The images can be retrieved from imaging modalities directly, or by digitising films, or digitising video signals. Special digitising equipments are available for digisiting films while video cameras may be directly hooked on to computers using e.g., a video card. These images may then be transported directly, or through imaging gateways, and sent to a variety of medical imaging modalities, such as archives, display stations, and print spooling devices. It is now coming to include the interfacing with HIS/RIS systems in the process of transporting digital images.

Only a few technical details follow. The current video-conferencing standard is H.320. Picture-in-picture monitors and autofocus with pan-tilt-zoom controlled cameras and audio at 7 kHz full duplex are the basic machinery required. Standard data ports are used for data transmission. Standard 128 kbps lines using 64 kbps ISDN lines are preferred for connection. [Top]

Some additional definitions:

[Ref. From the PACSpage by Eric John Finegan]

PACS - Picture Archiving and Communication Systems

It offers:

picture viewing at diagnostic, reporting, consultation and remote workstations
archiving on magnetic or optical media using short or long-term storage devices
communications using local or wide area networks or public communications services, and
systems that include modality interfaces and gateways to healthcare facility and departmental information systems offering one integrated system to the user. [Source: NEMA]

DICOM - Digital Imaging and COmmunications in Medicine

The DICOM standard is a set of rules that allow medical images to be exchanged between instruments, computers, and hospitals. It establishes a common language that guarantees a medical image produced on one vendor's machine will be displayable on the workstation from another vendor.

Telemedicine

Telemedicine is the process of using present-day telecommunications and computer technology to enhance the performance of medicine, particularly in the area of delivery of medical care. It uses information technology to deliver medical services and information from one location to another with minimal of delay. [Top]

Multimedia Patient Records

A multimedia patient record permits the reviewing medical doctor to examine information from current or previous encounters while continuing to interact with the patient.

It also permits the reviewing physician to store-and-forward information from the encounter for review or for progress tracking.

Components and Functionality of an Medical Record (according to a report developed for the AMA by the Health Information Technology Institute of Mitretek Systems, Inc., the following system dimensions should be when defining the system):

Data Content - core to any system that supports medical practise are the data elements captured and contained in the medical recording including the following-

Patient Identifier - for the physician practise, this element becomes especially important when exchanging patient information with other systems (e.g., hospital, laboratory testing, and payers)

Medical history and profile - should include the standard medical information captured during an encounter such as family history, surgeries, immunisations, risk factors, and health and activity status, providing a historical database

Drug reactions - includes allergies and other serious adverse alerts (e.g., allergy to the medication selection)

Problem list supported by a data dictionary - should have a problem-based orientation with status

Health status or functional status - should allow use of a standard tool to measure health status

Encounter data - should include vital signs, chief complaint, and pertinent encounter data (e.g., results of physical examination, history of present illness, and physical findings)

Consultant reports

Hospital discharge summaries

Medications - current medications, discontinued medications (with reasons for discontinuance), and a link with prescription writing and patient information should be included

Laboratory test results - should include automated entry, with use of standard code sets used for reporting results and the ability to document review (e.g., digital signature)

Radiology/Imaging results; and Ancillary study results

Decision Support/Patient Data Content (e.g., prevention guidelines, clinical practice guidelines, and patient education materials)

Functional Requirements - Data capture (e.g., patient registration information and integration with other systems such as inpatient and other settings) and should include:
1. Data output (e.g., graphic displays of test-result trends, alerts for abnormal results)
2. Adequate performance of system (e.g., rapid update information and adequate response time)
3. Order entry and results reporting - automated methods to perform these functions
4. Decision support - linkages to expert systems, reminders, automated warnings, and clinical guidelines, with a clear means for the physician to override these functions
5. Managed Care/Insurer communications - formulary, cost information, and authorisation
6. Billing - should be integrated into administrative system, able to verify eligibility, and support appropriate coding systems (e.g., CPT and ICD codes)
7. Quality management (e.g., health plan employer data information systems, severity measures)
8. Human interface requirements (e.g., type of device, ease of use, and design)
9. Technical requirements (e.g., architecture, architecture model, communications, security, integration, network management, and standards and protocols)

A CPR is electronically maintained information about an individual’s lifetime health status and health care. The computer-based patient record replaces the paper medical record as the primary source of information for health care meeting all clinical, legal and administrative requirements. It is seen as a virtual compilation of non-redundant health data about a person across a lifetime, including facts, observations, interpretations, plans, actions and outcomes. The CPR is supported by a system that captures, stores, processes, communicates, secures and presents information from multiple disparate locations as required.

The Institute of Medicine (IOM) of the National Academy of Science report identified the following 12 critical attributes in an computerised medical record system, referred to as the IOM’s "Gold Standard":

provides problem lists;
measures health status and functional levels;
documents clinical reasoning/rationale;
provides longitudinal and timely CPR linkages with other patient records;
guarantees confidentiality and audit trails;
provides continuous authorised-user access;
supports simultaneous user views in the CPR;
provides access to local or remote information resources;
facilitates clinical problem solving;
supports direct physician entry;
supports practitioners in measuring and managing costs and in improving quality; and
provides flexibility to support existing and evolving needs of each speciality.

The AMA (American Medical Association) offers the following guidelines

to assist physicians and computer service organisations in maintaining the confidentiality of information in medical records when that information is stored in computerised data bases:

Confidential medical information should be entered into the computer-based patient record only by authorised personnel. Additions to the record should be time and date stamped, and the person making the additions should be identified in the record.
The patient and physician should be advised about the existence of computerised data bases in which medical information concerning the patient is stored. Such information should be communicated to the physician and patient prior to the physician’s release of the medical information to the entity or entities maintaining the computer data bases. All individuals and organisations with some form of access to the computerised data bases, and the level of access permitted, should be specifically identified in advance. Full disclosure of this information to the patient is necessary in obtaining informed consent to treatment. Patient data should be assigned a security level appropriate for the data’s degree of sensitivity, which should be used to control who has access to the information.
The physician and patient should be notified of the distribution of all reports reflecting identifiable patient data prior to distribution of the reports by the computer facility. There should be approval by the patient and notification of the physician prior to the release of patient-identifiable clinical and administrative data to individuals or organisations external to the medical care environment. Such information should not be released without the express permission of the patient.
The dissemination of confidential medical data should be limited to only those individuals or agencies with a bona fide use for the data. Only the data necessary for the bona fide use should be released. Patient identifiers should be omitted when appropriate. Release of confidential medical information from the data base should be confined to the specific purpose for which the information is requested and limited to the specific time frame requested. All such organisations or individuals should be advised that authorised release of data to them does not authorise their further release of the data to additional individuals or organisations, or subsequent use of the data for other purposes.
Procedures for adding to or changing data on the computerised data base should indicate individuals authorised to make changes, time periods in which changes take place, and those individuals who will be informed about changes in the data from the medical records.
Procedures for purging the computerised data base of archaic or inaccurate data should be established and the patient and physician should be notified before and after the data has been purged. There should be no commingling of a physician’s computerised patient records with those of other computer service bureau clients. In addition, procedures should be developed to protect against inadvertent mixing of individual reports or segments thereof.
The computerised medical data base should be on-line to the computer terminal only when authorised computer programs requiring the medical data are being used. Individuals and organisations external to the clinical facility should not be provided on-line access to a computerised data base containing identifiable data from medical records concerning patients. Access to the computerised data base should be controlled through security measures such as passwords, encryption (encoding) of information, and scannable badges or other user identification.
Back-up systems and other mechanisms should be in place to prevent data loss and downtime as a result of hardware or software failure.
Security:
1. Stringent security procedures should be in place to prevent unauthorised access to computer-based patient records. Personnel audit procedures should be developed to establish a record in the event of unauthorised disclosure of medical data. Terminated or former employees in the data processing environment should have no access to data from the medical records concerning patients.
2. Upon termination of computer services for a physician, those computer files maintained for the physician should be physically turned over to the physician. They may be destroyed (erased) only if it is established that the physician has another copy (in some form). In the event of file erasure, the computer service bureau should verify in writing to the physician that the erasure has taken place.

[Top]

Telemedicine Workstations

While store-and-forward workstations may be as simple as a personal or laptop computer fitted with a modem for the purpose of transferring records of a patient encounter, normal interactive workstations are built on to a personal computer. The computer runs the medical record software and integrates the videoconferencing and file transfer capabilities of the workstation.

The videoconferencing component of a telemedicine workstation is called a codec (short for coder/decoder). The codec understands a videoconferencing protocol and permits the exchange of information between telemedicine systems.

Communications with other telemedicine workstations is accomplished through various types of communications and networking hardware. Many workstations employ a special file transfer card to transmit data to another site. These range from cards designed to communicate via the V.35 protocol to normal modems and ethernet cards. Many ISDN workstations make use of an inverse-multiplexer to bond multiple ISDN lines into a single interface useable by the codec or file transfer board. Other types of communications interfaces includes ATM, TCP/IP, leased lines, and switched-56 circuits. [Top]

Robotic Surgery in Cardiology

Recently, voice controlled robotic arms (that respond to verbal commands of the surgeon) have been employed in a reputed institution in India to perform coronary artery by-pass surgery (CABS). There are various advantages to this procedure where only three key-holes needs to be made in the chest near the heart and three robotic probes are introduced. These robot arms perform a number of tasks. It not only responds to the verbal commands of the surgeon performing the surgery but also produces a 3D image of the heart. The best of all is the fact that these robotic probes are able to continuously adjust (based on the same principle that is used in the anti-skid technology by the auto car makers to allow for the simultaneous braking of the four wheels of the car even though each wheel is moving at different speeds - the anti-skid technology allows for the car to "intelligently" interpret the wheel movements and make such adjustments as necessary so as to make all the wheels to behave as if they were moving at the same speed) the image being transmitted so that the surgeon sees the 3D image of a still heart even though it is beating. The surgeon performs the operation as if he were doing it on a still heart and therefore no heart-lung machine is required and the heart does not need to be stopped. This allows for lower morbidity and mortality rate as well as lesser number of indoor stay in the hospital.
In telemedicine, this procedure would allow for remote surgery. And it is not "pilot-less surgery", rather "distance surgery - telesurgery". The surgeon can be sitting next to the patient, the next room, or even half-way across the world. All he needs is a good resolution monitor, ability to speak (using microphone and headphones), and a perfect communication that will not break, and viola!
This whole idea originally came from NASA for they wished to have such facilities in place that would allow specialists to treat the people manning the space station for it was not possible to have a specialist for every medical condition on-board and the 100 odd people in the space station may urgently require medical attention, even operative procedures, which have to be effectively handled from an earth-based station. The Indian institution took up the idea and made it a reality.
[Top]

Cybersurgery

Somewhere in the contents of this site you must have read that people who matter thought cybersurgery would never be popular as 'pilot-less flying' didn't since who with any sense would allow a surgeon present "virtually" operate on oneself? That was April 1997. In January 2000, it is the latest craze on the Net (according to The Sunday Times, London). That is the speed at which both Information Technology and people's attitude towards it is changing, amongst other things...
Actually, it is not a form of macabre voyeurism per se. It is opined, in the article, that watching such operations could actually help potential patients make up their minds as to whether or not they want a particular surgery to be performed on them. I agree.Today, you can e-mail your scanned picture and for a fee get advise on what cosmetic (plastic) surgery you require and what would the costs involved be.
Therefore, what was hypothised around three years ago has become reality today. The wonders of technological progress. I now hypothise (January, 2000) that 'telemedicine' would be a subject that will be offered as a super-speciality to post-graduate medical students within the next five years. By ten years it will be one of subjects of a regular medical under-graduate curriculum. By January 2011, we shall all see... :)
[Top]

This page has become too large, by my estimates at least, so I have decided to add another page and continue with more updates... So please click on this link to go on...