Presentation is loading. Please wait.

Presentation is loading. Please wait.

Data Systems and Issues NCAEMSA Winter Conference 2004 Wednesday February 18, 2004 William E. Ott, MS, Paramedic CPCS Technologies www. cpcstech. com.

Similar presentations


Presentation on theme: "Data Systems and Issues NCAEMSA Winter Conference 2004 Wednesday February 18, 2004 William E. Ott, MS, Paramedic CPCS Technologies www. cpcstech. com."— Presentation transcript:

1 Data Systems and Issues NCAEMSA Winter Conference 2004 Wednesday February 18, 2004 William E. Ott, MS, Paramedic CPCS Technologies www. cpcstech. com

2 Integrated System Data Warehouse EMS Medical Examiner Hospitals Data transformation and scrubbing Medical Direction Data Reporting Law Enforcement

3 Wide Area Network (WAN) 9.6 Kbit/s <2Mbs Voice SMS e-Mail Web browsing mCommerce Internet access Document transfer Low/high quality video GPS Mobility – PAN, LAN, WAN Local Area Network wLAN 802.11b LAN <11Mbs Access hot spots LAN equivalent Wireless Bridge Workgroup Switches Personal Area Network (PAN) <1Mbs Access Synchronization 10 Meters Bluetooth

4

5 EMS as Information Workers What is involved? –Electronic patient records –CAD data pre and post response –GIS data pre and post response –System performance data –Application of performance data to the continuing education program –Personnel data –System / Vehicle data –Facility/Event preplan data

6 Threats to Information Systems Malicious abuse Denial of Service and related attacks Virus, Worm, and Trojan attacks Outside Hacker attacks Theft of service Theft of information Poorly trained IT staff Not staying current with system patches, antivirus definitions, etc.. Not performing proper system maintenance Poor or no backup and contingency plans

7 Threats to Productivity Spam –wastes resources –wastes time –offensive, dangerous Popup ads –wastes resources –annoying Malicious use of resources –wastes bandwidth, storage –violates law and privacy

8 Threats to Privacy / Confidentiality No security plan No security training or awareness Smart or Meta Tags in shared documents Social Engineering Unencrypted network Unencrypted e-mail No firewall No antivirus system Rogue wireless PDAs connecting to network and servers

9 Some Security Options Virtual Private Networking (VPN) Active AntiVirus Screening Stateful packet inspection Firewalling Proxy servers Opt-in e-mail Database encryption E-mail encryption Network / PC security policies Two Factor User Authentication Aggressive Audit logging and review

10 Sources of Threats Employees –Unintentional - acting in good faith –Intentional - disgruntled or unhappy staff –Software errors Environment –Equipment failure –Fire, flood, earthquake

11 Comprehensive Security Policy The policy must address: –Physical Security –Computer hardware and software inventory –Personnel screening and selection –Ongoing education –Access and control procedures

12 Comprehensive Security Policy Must also address: –Procedures for release of information –Disposal of data –Data backup and recovery –Contingency planning –Sanctions for noncompliance –Periodic review

13 Costs of Security Reduced access to information. Increased time and effort to access information. Hardware and software to implement security. Staff time to implement and maintain security system.

14 Physical Security Control access to servers and network equipment. Locate workstations in secure area, not easily accessible to the public. Provide surge protection and uninterruptible power supplies. Provide fire alarms and fire suppression equipment.

15 Hardware Security Hardware should be dependable. Non-proprietary to allow for easy repair and replacement. Critical systems should be mirrored and spare parts available for likely to fail components. Routine maintenance and tuning should be done. Have a service contract in place! Maintain accurate and up to date inventory.

16 Software Security Applications should be chosen with security in mind. Should have the capability of encryption for data storage and communication. System security software: –Firewall –Intrusion detection –Anti-virus –Disk defragmenter Maintain accurate and up to date inventory.

17 Access control Protect critical resources by limiting access to authorized and authenticated users. Specify: – who can access the information, –how it can be accessed, –when it can be accessed, and –under what conditions it can be accessed

18 What Are Potential Disasters? External Storms (hurricanes, tornados, floods, hail…) Accidents (planes, trains, automobiles, hazardous mat.) Regional Outages (power, communications…) Violence (civil unrest, terrorist acts, bioterrorism…) Internal Hardware Failures (servers, data stores, cyber attacks..) Accidents (fires, water leaks, electrical…) Violence (disgruntled employee, corp. sabotage…)

19 Contingency Planning Plan for interruption of service. Have alternate plan for data capture and retrieval. (Paper?) Have adequate security for alternate plan.

20 Data Backup and Recovery One of the most crucial components! Most likely component to be ignored. Practice data recovery! Use data protection schemes such as mirroring, RAID. Large agencies should consider hot sites.

21 Disposal of Data Discarded computer parts and peripherals should be dependably erased or destroyed. Removable media should be accounted for. Hardcopy printed from computerized records should be controlled.

22 System Components Transformation InputOutput Control Mechanism

23 Four Parallel Systems User system Data system Software system Hardware system Data Software Hardware User

24 Input Automatic data capture User Assisted –Optical Mark Reader (OMR) –Optical Character Reader (OCR) –Keyboard –Voice recognition Transformation InputOutput Control Mechanism

25 Transformation Data is collected and analyzed Aggregation Analysis Validation Transformation InputOutput Control Mechanism

26 Output Reporting –Ad hoc –Exception reports –Aggregate Publishing –Web-based Transformation InputOutput Control Mechanism

27 Quality improvement Education Administrative policies Medical protocols Transformation InputOutput Control Mechanism

28 Systems Architecture Stand-alone Peer network Mainframe-terminal Client-server Terminal-server

29 Stand Alone Each computer functions alone. No connection with any other computers. Easy to maintain. File transfer by sneaker net only.

30 Peer Network Computers connected to each other. Limited to file and print sharing. Connected via local area network. Share of data weakens security. No central control.

31 Mainframe-Terminal May be mini-computer or mainframe. Commonly referred to as legacy system. Dumb terminals. All activity on main computer. Connected with cable. Normally not GUI based application. Not conducive to ad hoc queries and reporting.

32 Client-Server Client are fully functional computers. Server may host applications. File sharing and printing normally done through server. Connected via local or wide area network. May be very secure. High cost of multiple client workstations (purchase and maintenance)

33 Terminal-Server New technology. Multiple dumb terminals connected to server. Applications, printing, file storage are on server. Connected via local or wide area network. Centrally maintained software. Low-cost network terminal.

34 Clustering Multiple servers. Servers are joined and share processing. Service is maintained with failure of single server. Highly dependable with little down-time.

35 Database Systems

36 Schema Pronounced SKEE-mah. The organization or structure for a database. Often used to refer to a graphical depiction of the database structure.

37 Data Components Database Tables Records Columns

38 Tables Table Name Column Names Patient PatientID Address City State ZipCode Age DOB Primary Key

39 Table A collection of similar data organized in columns and rows (records). Concept similar to a spreadsheet. Patient Table PatientIDCity StateDOB ORA4567DanvilleVA11/11/54 ORB1111OrlandoFL08/26/17 ORA1234BithloFL05/03/38 ORB5678TaftFL01/01/74 Column Row (Record) Table

40 Column Each column is a data element. The storage format for each column is defined Column names are listed at the top Patient Table PatientIDCity StateDOB ORA4567DanvilleVA11/11/54 ORB1111OrlandoFL08/26/17 ORA1234BithloFL05/03/38 ORB5678TaftFL01/01/74 Column Data Column Name

41 Data Element Data elements have different types All data in a column will be of the same type. Patient Table PatientIDCity StateDOB ORA4567DanvilleVA11/11/54 ORB1111OrlandoFL08/26/17 ORA1234BithloFL05/03/38 ORB5678TaftFL01/01/74 Column Data

42 Data Element Types Character or text Numerical –Integer –Fixed –Real Date (time) Binary or raw Memo or long Link

43 Data Elements Each field has a type. The length of the field is set for character fields. Most other fields can expand to accommodate more data.

44 Data Elements Beware! – Not all fields containing numbers should be number fields. Numbers that are not used in any arithmetic should be in character fields. Examples are Social Security numbers, telephone numbers and any other identification number.

45 Database Front-End Front-end: the interface that the user sees to input and manipulate data. Front-ends are usually built using some programming language such as: –PowerBuilder –Visual Basic –Java –Delphi Usually connect to some relational database.

46 Database Back-end Back-end: the relational database used to store and manipulate the data. Relational database management (RDBM)

47 Relational Database A collection of data items organized as a set of tables (like spreadsheets).data Tables may be linked to form new tables. Has rows and columns to show the relationships between items. Tree-like structure.

48 Flat File Database Stores information in single file. Does not allow a one-to-many relationship. Limits the amount of data that may be input per record.

49 Desktop DB vs. RDBMS Desktop include: –Access –Approach –Filemaker Pro –FoxPro All processing occurs on the standalone. Intended for smaller databases. Front-end included. RDBMS include: –Oracle –Informix –DB2 –MS SQL Processing occurs on the server. Has tools for larger databases. Requires front-end programming.

50 One-to-Many Relationship Incident Patient Event Patient Event Patient Event One Incident- Many Patients

51 One-to-Many Relationship Patient Event – IV Access Event – O2 Admin Event - Medication Event - Procedure One Patient- Many Events

52 Many-to-Many Relationship Doctor Patient One Doctor- Many Patients Doctor One Patient- Many Doctors

53 One-to-One Relationships Patient One Patient-One Home Address Home Address Ambulance One Ambulance-One Defibrillator Defibrillator

54 Keys A key field should be present in each table. Tables are related (linked) using keys. A key may be made of multiple combined fields.

55 Primary Keys Primary keys are values that uniquely identify each record within the table. Primary keys must always be filled in and not duplicate any of the other values in the table.

56 Foreign Keys Tables may contain a foreign key. Foreign keys are the primary key for a related table. Multiple records may have the same foreign key that link them to a single record in the related table.

57 Table Relationship Patient PatientID Name Address City State ZipCode Age DOB Foreign Key Treatment PatientID Treatment ID Medication Dosage Route Primary Key Same value Links the two tables

58 Table Joins May create a new table, target, from the source tables. May be temporary – called a query. May use many tables to assemble the desired data set.

59 Table Join NamePatient ID Og OglesbyOR13567 John Doe OR54321 Patient ID Medication Dosage OR54321 Epinephrine 1.0 mg OR13567 ASA 162 mg OR54321 Oxygen 12 l/m OR13567 Atropine 1.0 mg Tables are associated with the primary key Note: One-to-many relationship

60 Relational vs. Flat File Flat file databases are limited to predefined number of data occurrences. Most desktop databases are relational, however, some applications are designed as flat file.

61 Relational vs. Flat File Note: One-to-many relationship Name Patient ID Og Oglesby OR13567 Patient ID B/P B/P Time OR13567 110/80 13:45 OR13567 116/82 13:55 OR13567 120/82 14:05 Name Patient ID B/P1 Time1 B/P2 Time2 Og Oglesby OR13567 110/80 13:45 116/82 13:55 Flat File Database Relational Database

62 Table Join NamePatient ID Og OglesbyOR13567 John Doe OR54321 Patient ID Medication Dosage OR54321 Epinephrine 1.0 mg OR13567 ASA 162 mg OR54321 Oxygen 12 l/m OR13567 Atropine 1.0 mg Note: One-to-many relationship The Patient ID is the primary key in the patient table and the foreign key in the medication table

63 Table Joins NamePatient ID Medication Dosage Og OglesbyOR13567 ASA 162 mg Og Oglesby OR13567 Atropine 1.0 mg John Doe OR54321 Epinephrine 1.0 mg John Doe OR54321 Oxygen 12 l/m Patient ID Medication Dosage OR54321 Epinephrine 1.0 mg OR13567 ASA 162 mg OR54321 Oxygen 12 l/m OR13567 Atropine 1.0 mg Name Patient ID Og Oglesby OR13567 John Doe OR54321 Source Target

64 Table Joins NamePatient ID Medication Dosage Og OglesbyOR13567 ASA 162 mg Og Oglesby OR13567 Atropine 1.0 mg John Doe OR54321 Epinephrine 1.0 mg John Doe OR54321 Oxygen 12 l/m Patient ID Medication Dosage OR54321 Epinephrine 1.0 mg OR13567 ASA 162 mg OR54321 Oxygen 12 l/m OR13567 Atropine 1.0 mg Name Patient ID Og Oglesby OR13567 John Doe OR54321 Source Target

65 Reporting NamePatient ID Medication Dosage Og OglesbyOR13567 ASA 162 mg Og Oglesby OR13567 Atropine 1.0 mg John Doe OR54321 Epinephrine 1.0 mg John Doe OR54321 Oxygen 12 l/m NamePatient ID Medication Dosage Og OglesbyOR13567 ASA 162 mg Og Oglesby OR13567 Atropine1.0 mg John Doe OR54321 Epinephrine 1.0 mg John Doe OR54321 Oxygen 12 l/m

66 Reporting NamePatient ID Medication Dosage Og OglesbyOR13567 ASA 162 mg Og Oglesby OR13567 Atropine1.0 mg John Doe OR54321 Epinephrine 1.0 mg John Doe OR54321 Oxygen 12 l/m NamePatient ID Medication Dosage Og OglesbyOR13567 ASA 162 mg Atropine1.0 mg John Doe OR54321 Epinephrine 1.0 mg Oxygen 12 l/m

67


Download ppt "Data Systems and Issues NCAEMSA Winter Conference 2004 Wednesday February 18, 2004 William E. Ott, MS, Paramedic CPCS Technologies www. cpcstech. com."

Similar presentations


Ads by Google