Data: Input- Structure- Storage

Kinkajou : Yes. Let’s look at some of the medical records systems and their features.

Dr Xxxxx : I’ll cover the issue with a from the point of view of a number of aspects/ modules, (not mutually exclusive).

 

 

Medical Data Input

Kinkajou : Who Inputs Data? / Works with Data:

GP Australia Data Input Source

Dr Xxxxx : There are several different ways of looking at this problem. One method is to look at the actual identity of the person inputting or using the data. The second is to at the location person inputting/working with the data. And lastly it is to look at the organisation in which individual may be working.

When we look at the actual identity of the person inputting or using data, classical identities emerge such as: doctors, nurses, reception or front office staff, practice managers or back-office staff, and allied health personnel.

Doctors usually input by typing (In the big world):
SOAP style notes are popular” Subjective Objective, assessment, Plan:
Some would use history/ examination, diagnosis, investigations, management : same thing, slightly different words).

Nurses: Would add clinical management notes, but shortcuts are generally optimised for the doctor with little emphasis on the different aspects of the nursing process in medical care. Common differences in Australia are that nurses asked permission to give patients in the treatment; nurses usually document not only the nature of an injection, but the site of an injection and the type of dressing; this is a usually substantially better at documenting warnings. While I’m sure this may happen in other settings, doctors usually use shortcuts due to time and financial restraints to their consultations. ECG Setup and Data

Front office staff / reception staff: There is often a need to record difficult aspects of patient interactions or to communicate information that they have acquired regarding the patient, which they believe will impact the patient’s care. Another typical ploy is when patients tell the reception staff how urgent their problem is, and then simply asked the doctor for a routine item such as a prescription. Contact management information is essential in dealing with people/patients who have learnt to manipulate the system.

Management staff/back room staff: Financial management usually occurs at this level. There is often a need to feedback to doctors regarding consistent financial coding errors. Patient relevant information often arrives via invoices or requests for information, and needs to be recorded. There is much systemwide information required at this level, as typically the medical organisation interacts with external “financial” agencies for payment.

Medical And paramedical users would often typically use software that is tailored specifically to one type of health provider.

Anaesthetic Data

 

 

Dr Xxxxx :  Medical software can be designed with specific specialties in mind such as:

• Otolaryngology.
• Pain management.
• Orthopaedics.
• Neurosurgery.
  
  
• Anaesthesia.
• Triage management.
• Physicians or internal medicine doctors.
• Neonatal clinics.
  
  
• General ophthalmologists to ophthalmic surgeons.
• For intensive care units.
• Mental health professionals.
• Emergency department.
  
  
• Orthopaedic.
• Outpatient and inpatient treatment.
• Paediatrics, paediatricians.
• Family practice.
  
  
• Plastic surgeons. 
• Speech therapy. 
• Psychologists.
• Chiropractors.
  
  
• Physical therapists, OT and physiotherapists. 
• Nephrologists.
• Pathologists.
  
  
• Outpatient / addiction medicine clinics - includes e-prescribing for controlled substances. 
• Sleep clinics
  
  
  

Health Centre Typical

Data Structure Considerations

Dr Xxxxx : Another method of considering who inputs the data is to consider the size of the organisation.

• Large organisations generate problems specific to their size. Patients can easily be lost in the waiting room, lost in transit, or can be lost between procedures. Large organisations have very different requirements for managing medical consultations small ones. Another significant problem occurs when two people access a single patient file within an organisation. The most common conflict arises when front office staff booking in the patient, leave the file open blocking out the medical practitioner from access to the file.
  
  
• Also the types and complexity of data structures required to hold information for large organisations are different than for small organisations due to cost and volume optimisation constraints. Big data needs big storage and big processing. Little organisations need individual and cheap.
• In this day and age, there is a growing direction of using patients to input their own data. Booking forms on paper are being pushed out of the system as much as possible to be replaced with online web or tablet based systems.

The final method of considering who inputs data is to consider the location.

• Desktop data input is a very different environment to
• ambulatory data input is a very different environment to
• bedside data input is a very different environment to
• remote access data input is a very different environment to
• someone who inputs data who does not have an office at all
• Someone who inputs data at community health, rural health, vs. a hospital all have different data entry environment.
  Healthy or Not? What can you see? Paill?
  

Dr Xxxxx : Other unusual environments:

• Disabled clinics or homes.
• Medical student training.
• Wound care clinics.
• Outpatients. 
• Hospital outreach solutions. 

Kinkajou : We need to consider :
How medical personnel (doctors or other) Input Data:

Dr Xxxxx : To some extent this is a restatement of some of priorities. Mobile or ambulatory data input systems such as Tablet PCs, mobile phones; small laptops and other devices can connect to their databases in a number of different ways. The connection (wireless based) can be to internal computer networks, web/cloud based systems, remote systems, and other external agencies (typically pathology and radiology being very common).

Note that many people outside of any consultation may be responsible for inputting data. Again typically pathology, radiology, and letters from specialists feature prominently in medical situations. Where information arrives in letter format, it needs to be converted to an electronic format and then OCR transcribed.  Where images are involved, these need to be archived under specific formats and under specific structures, most typically using the name of the patient as a file header.

DataBase Structure

Kinkajou : Data Storage:

Dr Xxxxx : Data is perhaps most typically stored on internal hard drives on an internal computer network. This type of system is popular because it can be physically secured and electronically secured. It is also typically cheaper for very large systems than off-site storage solutions. Since data resides close to the CPU of the server, data bottlenecks are generally substantially reduced. However this type of system is not suitable for many medical/paramedical practitioners.

Cloud-based have begun to be implemented for many more mobile practitioners.

Web-based (browser) systems rely on the functionality of the browser. This typically provides many inbuilt features are essential for communications. Encryption security as well as ease of use are very commonly appreciated advantages.

DataBase Server

Dr Xxxxx : INPUT Systems

• Web-based? Browser based?
• Transcription and speech/ voice recognition or dictation technologies.  (Create your own voice commands).
• Scanning
• Mobile and touch screen versions. 
  
  
• Handwriting recognition using a Tablet PC
• Smartphone, iPad or a computer. 
• Electronic patient registration and history forms from their website. 
• Data migration
  
  
• Utilizing a wireless barcode solution.
• Text & multimedia messaging.
• Video/ web conferencing. 
  
  
• Collaborative charting.
• Automatic code capture.

. Touchscreen Data Input

Standards for Medica Data Storage

Dr Xxxxx : I won’t go into standards much except to drop few meaningless names. I’ll use some US examples to keep it relevant to the bulk of our audience.

A data dictionary is the most basic level of standards functionality.

• HIPPA compliant
• DGI / ONC-ATCB certified
• SaaS model
  
  
• Open source
  ONC certified and free to use. 
• SNOMED-CT functionality.
  
  
• CCHIT Certified
• ONC-ATCB certified HER
  
  
• , HIPAA-compliant wireless networks to leading handheld devices. 
• CCHIT certified repository
  
  

Don’t forget the operating systems of the computers: Windows, apple Mac, Android

Don’t forget some of the background software you never see: Microsoft.NET platform

Kinkajou : Types of Data Stored:

Dr Xxxxx : In a medical practice/paramedical practice, not all data is in electronic text format. Images are common. Graphs and charts are common. For example sleep reports, ECG and spirometry all generate typically pictures rather than text.

Where systems are required to store large volumes of non-text data, they need to be substantially larger and require optimisations to enable fast retrieval and usage by practitioners.

Many imaging practices in Australia are tending to send their images by CD/DVD. What is interesting are some of the concessions made to optimise data transfer. Many of the CD/DVD’s carry warnings that the images contained are not suitable for interpretation. (They may not provide enough resolution, or not provide as much resolution as was available at the time of imaging).

Many images on CDs/DVDs carry their own proprietal imaging software. So some images may not be able to be seen on Apple Mac versus Windows versus android systems. Also in Australia, typically the images take up to 20% of an average consultation time to load, assuming the practitioner has access to a CD/DVD ROM drive, which is becoming less often the case with the move away from total desktop systems to server/thin client architectures.

Answer: read the report and plead lack of skill looking at X-rays.

Goo : (This may be a self-fulfilling prophecy if you avoid looking at enough of them).

Modular Application Structures

 

 

 

 

Kinkajou : Information

Dr Xxxxx : Many electronic health record systems attempt to build in substantial libraries of medical content.  The problem comes with cost and licensing issues. Many practitioners often have little time to use these databases for any more than fleeting instances. The Internet can be a reasonable source of much data, often to a high technical standard.

To maximise value extracted from medical reference material, requires integration of the electronic health record with the medical information. A classic example is the need to check interactions using a “recognised” database for HIV drug users.

Many medical systems check interactions between listed drugs. But if one is looking for a new drug and attempting to choose the lowest interaction drug available, existing systems do not generally support this type of endeavour.

If the data is sufficiently integrated, it can be allowed to make decisions: in effect clinical decision-making software. This is another important long-term achievement in electronic health records. However, to implement this successfully requires structured data and structured information being combined with intelligence: three things to join.

Kinkajou : Functionality: is really a derivative of information processing

Modularity the Concept

Dr Xxxxx : Some practitioners manage chronic illnesses using a team of carers. This will of course demand the integration of software for the entire group of providers.

Requirements for Software systems storing imaging are very different to software systems storing text information.

Communications between practitioners, to agents outside of the system, And to front and back office staff are very important.

Translation can become important when dealing with patients with language limitations.

Data storage has standards applicable. These can simply relate to file format of the images stored / degree of data compression.

These can also relate to complex issues such as the need for a data dictionary. A data dictionary gives each data element a unique and identifiable name. This is extremely obviously useful on the case of pathology. But comes with severe obvious limitations as well. Changes in units of a measurement can be handled with difficulty.

E.g. When RBC Folate testing in Brisbane moved from ng/l to mM/l, the reference ranges in Brisbane defaulted back to the old values in both main pathology companies in town for several years. Essentially for a few years in Brisbane, we were in that unique situati0on of having no one in the entire city and perhaps most of the state having deficiency in folic acid nutrition for several years.

Similarly, if the pathologists decided to use a different reference range because the government is saying there are too many people with deficiencies existing, reference ranges and computerised records can move as well, even for older values.

And finally if tests are undertaken using a new protocol, the reference ranges may need to be different as well. If the new test profile has an increased 5% absorption of the tested chemical (such as Folate) to some other reactant, or altered test efficiency, then the test results will change by consistently. The new results may be consistently 5% better or worse than the old results. This can be important where the deficiency states may be marginal.

So a data dictionary begins to expand as subfields need to be added to each data element to cope with problems foreseen or experienced. A data dictionary with just header fields is actually quite a bulky and thick document.

Drs may need to access the medical record remotely. However remotely accessing real-time waveform and patient data is a very different proposition to accessing existing records.

Devices matter, as standards, operating systems and interoperater varability range substantially.

 

 

 

 

Doctors Needs in Medical Data Storage

Kinkajou : Doctors Require

Dr Xxxxx : To be able to record information from patient contacts, for example either by the SOAP notes example or by the history, examination, diagnosis, investigation, management protocol.

Template-based medical chart system with predefined choice lists and macros that can be customized to different specialities. 
A certified e-prescribing system that can run stand-alone or integrate with EHR/PMs looking to add an e-Rx module. 

They need to be able to prescribe scripts of medicines for patients. E-prescribing, is the killer app of the medical computing world. Strangely enough even this simple requirement can be handled quite badly by my computer systems, mainly due to the varying demands of individual practitioners.

For example, some practitioners wish to see a pallet of all medications prescribed upfront to maximise prescribing speed. Other practitioners wish to see only current active medicines that the patient is taking so that legal decisions can encompass the reality/totality of the medications the patient is conserving on a daily/regular basis.

Medical interactions feedback can be hierarchical menu based and quite recurrently annoying. By forcing practitioners to focus their attention on the warnings, the practitioners learn to automatically bypass the warnings at speed because there are so many of them or presented one by one. In a complex patient you can easily lose 20% of the average consultation in Australia due to the interactions between medicines. (Try it with warfarin and a few drugs!).

Clinical decision support systems look at combining medication information, interactions, and knowledge of the patient’s medical conditions to maximise appropriate care for the patient. Hopefully systems achieve Decision support intelligence features, integrates disease management templates to allow better chronic disease management.

Medical practitioners need to be able to communicate with other parties: reception staff, management or backroom staff, Allied health providers, other medical practitioners, hospitals.

Specific reports need to be able to be generated quickly. For example, medications lists for patient compliance, medication lists for travel, medication lists for pharmacists involved in patient care, reports to legal people, immunisation reports, and medical summaries for other carers or practitioners.

Coding diagnoses needs to be simple, easy and relevant to the uses required. I would add the point of view that much of what the record is junk. It is very unlikely to ever matter to a patient in the long term, how often he has had a cough or cold of the last few decades. (Yes! Yes! There are exceptions. What happens if the patient has……).

Some medical software boasts that it is able to mimic a doctor’s thought processes, in its workflow implementations. Strangely enough, I have yet to see anything as effective as a doctor squealing arrows and joining bits and pieces with abbreviations on paper. (Yes! Yes! Our system is so much better than that……). Some software even boasts customisable templates or data input fields. Macros are commonly used, usually to create verbiage which fills a file and make it look like a lot has been done.

You can’t recreate a paper type record in an electronic computer system. There are too many entrenched ways of doing things via computer that are just difficult to use. (For example, try skipping from the line above to the line below where a system won’t let you add a new line before the end of a line. Yes, it’s just a programming glitch. But there are a lot of them.

Patient reminders and recalls are important.

Patient problem list management and management plan creation.

Patient allergies are important. One of the main medical software systems in Brisbane has failed over many years to discriminate between an allergy and a reaction to a medicine. For example small erythromycin and experiencing nausea and stomach pain is unlikely to be an allergy.

However if it is coded as an allergy the medicine can ever been used again, except by a practitioner who enjoys living on the wild side. If it were coded as an irritation, it will be obvious the medicine could be used in specific circumstances with consideration, if required.

Again the multilayer menu system of recording this information takes so long that many practitioners just don’t bother recording allergies reactions. (No! No! I hear you say. “Look at the evidence you fool”, I say.)


ECG Data Collected as well

Since starting computer records, I’ve never been slacker at recording information. Paper was in many ways easier. And you held the data template in your head. You could action it right away. Now, with an advanced computer system.

You can search for you enter data click open up new menu which you can click to enter new data click to another field where you may or may not be compulsorily made to feel in a number of sequential fields and then click to another field. If you’re lucky in clicking the last field, you actually saved it, otherwise you have to start all over again. Again this is the hierarchical menu problem. People just don’t work like that.).

Patient portal, billing: doctors need to be able to code a patient regarding their consultation billing. It is after all the whole point of the transaction.

 

Dr Xxxxx : Other stuff:

• Outcomes assessment library
• Writing software for Medicaid waiver providers.
• Collaborative charting,
• Automatic code capture,
  
  
• Creating graphs within charts from stored structured data.
• Patient tracking: people get lost in big centres. The nurse needs to tell you when they have done what you asked them to do. You need to be out of find where your patient is, in a management process.
  
  
• Patient education
• patient handouts
• Dr Education and handouts: simple and fast is usually a good format.

Providers to automate as many tasks as possible. Tasks need to be fairly modular but carry an appropriate level of integration. Certain warnings are important. The most important is whether the patient has paid the last consultation. Not a problem in Australia (due to Medicare), but definitely would be a problem in many parts of the world.

 

Front Office / Practice Management Staff Require

Kinkajou : Front Office / Practice Management Staff Require

Dr Xxxxx :

• Control scheduling / appointment, perhaps even color-coded scheduling, single screen patient encounter functionality and intelligent scheduling technology. 
• Practice management, appt. confirmations, recalls, marketing, auto dialler, reduce no shows, staff management, and increase productivity. 
• A new growth area is the ability to make appointments online.
• Wait time analysis.
  
  
• Comprehensive insurance and patient billing. 
  Patient registration, / assessment of ID,
  charge and credit posting,
  Tracks payer performance from a single point of control and shares Medicare compliance rules globally. 
  Revenue cycle management features
  optional automated bad debts /
  Collection agency tracking functionality.
  
  
• Invoicing, and document management.
• Clinical orders tracking.
• Marketing.,
• Messaging., 
  
  
• Integrated faxing tools. 
• Online connectivity solutions enable providers to connect with other providers, patients, payors, and pharmacies online.
• document management system designed to use over a network
• Practice management system
  
  
• with on-the-fly custom templates
• Modularity
• Mobile features. 
• Remote support for off-site staff
  
  
• ability to implement your EMR incrementally (just in case the planned growth, never happens
• Instant user customisation along with free text notes, modifiable templates. 
• Access to system maintained databases such as practitioners in a region.
  
  
• (I never ceases to amaze me that each organisation aims to create its own database. Government organisation for aged care greater database of caregivers in this region. As does pathology. As does Medicare. As does each single practice. As do community service organisation such as Lifeline and Australia.

Doctor with Tablet
Doctor with Tablet

Usual computer system necessities:

Erasmus : Usual computer system necessities:

• security,
• backup,
• password protection,
• virus protection,
  
  
• cookie control,
• malware and
• Adware control.
• Access security
  
  
• Software adjustment restrictions: permissions fro in Linux terms: R W C D access and process access control.
• Network access control
• Data transfer system that enables healthcare providers to securely exchange patient health information
  
  
• Mobile features. 
• Remote support for off-site staff
• Wireless features

Dr Xxxxx : Miscellaneous

Documentation of daily treatment encounters through and drop downs, and easy point and click technology (At least somebody thinks this stuff is a good idea).

Interactive forms, and interactive patient portal. 

Graphics and natural language generator. (This sounds really good until you find out what it really means. I remember the graphic for recording information about lesions found around the anus, was a circle representing the anus. Oh the marvels of technology!)

I don’t action know at this next bit means but it sounds good. I’ve included all of the above descriptions to give you some idea of how really complex electronic health record is. It’s not about just stick and information a bit of paper.

Customisable EHR software program with an embedded natural language interpreter (NLI), a real-time text interpreter

Coding software that reads SOAP-note template documentation and analyses the coding algorithms

Analysis Capabilities: System capable of comparative patient data

Translation: multiple languages: Not a bad option. If you can use voice dictation, it can be voice translated as well, or at least translated from one voice into the printed version of another language with same language subtitles to allow for checking of communication accuracy.

 

 

Kinkajou : So what words of wisdom can you give us Goo?

Goo :  This proposal has a long long way to go. Again the social aspects are the most difficult. Everyone thinks they need to be there to help the birth of this child. However, the reality of human groups is that the most consensus and progress is reached with very small groups such as 4 to 5 people. In keeping with the modular design for the program, suggest a modular development design as well. Again fortify people in a group per module may well be a good way to go.

Some problems may not be solvable. If you know to some extent with the message is, how do you encrypt the message? How do you make sure that if the key is lost or data is corrupted, that the message will not be lost as well? To what extent is an individual responsible for themselves? To what extent is society responsible for an individual and his records?