1 / 17

INFO-I530 (Foundation of Health Informatics)

INFO-I530 (Foundation of Health Informatics). Sample Clinical Information Systems. Lecture #8. Lecture in a Nutshell. AZ-VUB Clinical Information System Background Technological Environment Information System Components Results HEGP Clinical Information System Background

Download Presentation

INFO-I530 (Foundation of Health Informatics)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. INFO-I530 (Foundation of Health Informatics) Sample Clinical Information Systems Lecture #8

  2. Lecture in a Nutshell • AZ-VUB Clinical Information System • Background • Technological Environment • Information System Components • Results • HEGP Clinical Information System • Background • Component Based Architecture • Results

  3. AZ-VUB Clinical Information System • Background • Teaching hospital of the free University of Brussels (VUB). • Active beds  679 • Staff Members  2655 • Nurses  1050 • Physicians  410 • Number of admission per month (mean)  2400 • One day hospital care (% of admissions)  45% • Outpatient visits per month  37000 • Visits in the emergency department per day  150

  4. AZ-VUB Clinical Information System cont. • Technological Environment • The institute has developed an architecture that supports the integration of components. • Components are designed in three levels of: Conceptual, Implementation and Deployment. • At the most abstract level, the conceptual level, the basic shape of the solution is defined with the respect of the functional and non-functional requirement specified for the application domain. • At the implementation level, the architecture defines how an object works. This level specifies the structure of the data object and the code. • At the development level the physical components are installed on a set of servers in a distributed architecture.

  5. AZ-VUB Clinical Information System cont. A logical view: framework for component software at AZ-VUB

  6. AZ-VUB Clinical Information System cont. • Information System Components • All applications are logically integrated in basic common components of: • Authorization Component • Patient Component • Activity Component • Medical Component • Knowledge and Terminology Component • Resource Component • Workflow Management

  7. AZ-VUB Clinical Information System cont. Logical view of the AZ-VUB component architecture

  8. AZ-VUB Clinical Information System cont. • Authorization Component • The interaction between a user and the clinical information system is controlled by the authorization component. This component sets the access rights of individual users according to legal, medical and organizational requirements. • Patient Component • Provides a unified repository for storing patient identification, patient demographics and patient localization data. The component provides various navigation facilities to access the patient records. • Activity Component • It represents the communication vehicle between the requester and the performer. It includes writing patient orders, scheduling, performing certain activities and finally billing the patients. • This component is linked to a clinical decision support system that may provide billing feedback, optimization of resource scheduling and management, and real-time rule-based prompts and alerts for clinical encounters.

  9. AZ-VUB Clinical Information System cont. • Medical Component • It contains medical records and documents. Medical records may contain multimedia content that will be stored in a digital format (ECG and …). Medical documents (textual data) may have highly-structured, semi-structured or poorly-structured documents. Medical documents are usually stored in an XML format. • Knowledge and Terminology Component • It contains an expert system to detect adverse drug events. It also uses ICD9-CM to cope with the diversity of medical terms. • Resource Component • It provides information to support the management activities for financial, organizational and medical purposes. A resource can be tangible or intangible. • Workflow Management • Medical care is a collaborative activity. Most components are “workflow-enabled” which integrates the system into the physicians’ workflow.

  10. AZ-VUB Clinical Information System cont. • Results • Provider order entry • Lab order entry per month  40,000 • Direct lab entry by physicians  15% • Delegate entry  85% • Imaging order entry per month  10,940 • Direct imaging entry by physicians  70% • Delegate entry  30% • Drug order entry per month  38,000 • Direct drug entry by physicians  70% • Delegate entry  30% • Hardware architecture • Unix Server  6 • NT Server  8 • Personal Computers  1400 • Portable Computers  75 • PDA per ward  40 • Printers  400

  11. HEGP Clinical Information System • Background • The Hospital European Georges Pompidou (HEGP) - State owned university hospital located in southwest Paris, France. • Active beds  725 • Nurses  1100 • Physicians  400 • Number of admission per month (mean)  4000 • One day hospital care (% of admissions)  25% • Outpatient visits per month  19000 • Visits in the emergency department per day  120

  12. HEGP Clinical Information System cont. • Component-Based Architecture • Component Selection Process: Components were selected not only on their intrinsic capabilities and functions but also on their capacity to be integrated into the overall architecture. Basic constraints in the request for proposal were the following: • Published application program interfaces (APIs) • External exchanges through standardized messages • Immediate compliance with the CCOW (Clinical Context Object Workshop) recommendations for components involved with patient data management, currently driven by HL7 • Existence of import or synchronization facilities to load reference tables from a terminology component • Capacity to use an external authorization component • Access to the detailed model of the component to allow easy access to tables through SQL queries and facilitate data integration

  13. HEGP Clinical Information System cont. Functional architecture of the HEPG information system

  14. HEGP Clinical Information System cont. The access module

  15. HEGP Clinical Information System cont. The imaging cycle

  16. HEGP Clinical Information System cont. • Results • Provider order entry • Lab order entry per month  50,700 • Direct lab entry by physicians  65% • Delegate entry  35% • Imaging order entry per month  10,940 • Direct imaging entry by physicians  55% • Delegate entry  45% • Hardware architecture • Unix Server  10 • NT Server  45 • Personal Computers  1600 • Portable Computers  85 • Network Printers  400 • HEGP opened with approximately 1000 less staff than the three closing hospitals.

  17. Summary • AZ-VUB Clinical Information System • Background • Technological Environment • Information System Components • Results • HEGP Clinical Information System • Background • Component Based Architecture • Results

More Related