Urged for tighter restrictions on cosmetic surgery

A summary of responses from patients, the public and industry has been published as part of the review set up after the PIP breast implant scandal.
A final report, by Sir Bruce Keogh, the NHS medical director leading the English review, is due in March 2013.
Cosmetic surgeons said procedures should not be sold as "a commodity".

For more information visit this link http://www.bbc.co.uk/news/uk-20850284

Is The Traditional PC Dead?

Personal Computer makers late to the mobile game were the big losers in 2012, as CNN's Maggie Lake reports.

Increasing Time Spent With Patients And Improving Relationships : A Better Bedside Manner With iPad

Bedside care is a vital part of health care professionals' relationships with their patients at the hospital. But the staff at hospital found that modern technology sometimes made those interactions more difficult. When Apple introduced iPad, physicians at the hospital knew they'd found a solution.
A custom iPad app enables physicians and nurses to perform important tasks from the bedside, increasing time spent with patients and improving relationships.
The inability to bring information to the bedside meant physicians had to constantly shuttle between patients and tethered PCs to get status updates, schedule surgeries, prescribe drugs, view X-rays, and perform other important tasks. Since the introduction of technology in this industry physicians have been tethered to devices like PCs and forced to go seek information. Even a laptop wasn't truly mobile.
With iPad, the hospital's doctors and nurses have bedside access to everything they need, and can remain in contact with patients and their families while viewing information that is critical to their care. They can answer patients' questions immediately and make decisions about what's going to be done, with the most current information available. Nothing beats being able to use an app to pull up an X-ray on the device.
Not only has iPad increased efficiency from a provider perspective—it's increased engagement between the provider and patient.

Drug And Medical Information Apps For iDevices

This article describes Apps for the iPod Touch, iPhone, and iPad that may be beneficial to pharmacy education and pharmacy practice. The purpose is to provide examples of the types of Apps available through the App Store to support teaching, learning, and practice and to help you become familiar with the various uses of an iDevice.

APP Description Cost
ACC Pocket
Guidelines
ACC Pocket Guidelines is a clinical practice support tool set from the American College of Cardiology Foundation that provides concise, portable reference tools for clinicians. Free

Antibiotic
Pharmacology
Antibiotic Pharmacology is a fully featured flash card app that helps you learn about antibiotic pharmacology.
Included in this app are:
+ Main Deck
+ Faves Deck
+ Ignore Feature
+ Shuffle Ability
+ Choice of Primary Side
+ Search Feature
+ Index
+ Beautiful, Easy-to-Use Interface
2.99

Davis’s Drug Guide
Davis’s Drug Guide for Mobile and Web delivers up‐to‐date, comprehensive, and practical information on over 5,000 trade name and generic drugs.
PLEASE NOTE: Application requires a paid subscription to the online Davis’s Drug Guide service.
Davis’s Drug Guide for Mobile + Web includes:
• Over 5,000 trade name and generic drug listings
• High-alert notices
• Risk Evaluation and Mitigation Strategies (REMS), highlighted by an icon
• Drug-drug, drug-natural, and drug-food interactions
• Discontinued drug list
• Unique optimization for iPad, iPhone, and iPod touch interfaces
• Universal Index Search – find terms across all indexes
• “Favorites” for bookmarking important entries
• Regular updates and Web access for one year
Free

Drugs and Meds: Pill and Drug
Identification
Drugs and Meds: Pill and Drug Identification is a glossary of the most common prescription drugs (USA‐based), with images of many of the drugs (in pill form mostly) to help you identify them based on image. 0.99

Epocrates
ePocrates is a mobile drug reference used by healthcare providers at the point of care. 0.99

The iPad’s Pros And Cons In A Health Care Setting

The iPad has been popular with health care providers. This is not too surprising, as doctors, nurses and other practitioners have been using the iPad's older sibling, the iPhone, for several years, for everything from voice recording to clinical data entry. Many argue that the iPad's larger screen sets the stage for even more clinical uses.
The iPad has pros and cons associated with its use in health care. Several characteristics explain the rapid pace of iPad adoption among health care providers:
• The iPad is roughly the same size as patient charts.
• It has a large screen that can be used to share information with patients.
• The price makes it affordable for physicians.
• It can run all the medical apps available on the iPhone.
• It can be used to enter data into EHR and computerized physician order entry (CPOE) systems.

On the other hand, problems associated with iPad use in health care include the following:
• It might not be durable enough, and is difficult to disinfect.
• It does not run Flash, the Adobe Systems Inc. platform on which the majority of the Web's video is developed.
• It does not support USB devices or printers.
• It has no camera.
• Its free-form factor could give rise to ergonomic issues and security breaches -- though these issues could arise with the use of any tablet device.

Architecture of Android OS



Android uses Linux for its memory management, process management, networking, and other operating system services. The Android phone user will never see Linux or in other words our application will not make Linux calls directly.
Some parts of Android will be familiar, such as the Linux Kernel, OpenGL, and the SQL database. Others may be completely foreign, such as Android's idea of the application life cycle. You'll need a good understanding of these key concepts in order to write well-behaved Android applications. 

The Android OS is roughly divided into five sections in four main layers:
  • Linux kernel — This is the kernel on which Android is based. This layer contains all the lowlevel device drivers for the various hardware components of an Android device. Android uses Linux for its device drivers, memory management, process management, and networking. However you will never be programming to this layer directly.
  • Libraries — These contain all the code that provides the main features of an Android OS. Forexample, the SQLite library provides database support so that an application can use it fordata storage. The WebKit library provides functionalities for web browsing. They are all written in C/C++ internally, but you'll be calling them through Java interfaces.
  • Android runtime — At the same layer as the libraries, the Android runtime provides a set of corelibraries that enable developers to write Android apps using the Java programming language. The Android runtime also includes the Dalvik virtual machine, which enables every Android application to run in its own process, with its own instance of the Dalvik virtual machine (Android applications are compiled into the Dalvik executables). Dalvik is a specialized virtual machine designed specifically for Android and optimized for battery-powered mobile devices with limited memory and CPU.
  • Application framework — Exposes the various capabilities of the Android OS to application developers so that they can make use of them in their applications.
  • Applications — At this top layer, you will find applications that ship with the Android device (such as Phone, Contacts, Browser, etc.), as well as applications that you download and installfrom the Android Market. Any applications that you write are located at this layer.

Android Devices in the Market



Android devices come in all shapes and sizes. The Android OS can be seen powering the following types of devices:
  • Smartphones
  • Tablets
  • E-reader devices
  • Netbooks
  • MP4 players
  • Internet TVs
Chances are good that you own at least one of the preceding devices. The Samsung Galaxy S, the HTC Desire HD, and the LG Optimus One smartphones.
Another popular category of devices that manufacturers are rushing out is the tablet. Tablet sizes typically start at seven inches, measured diagonally.The Samsung Galaxy Tab and the Dell Streak, which is a fiveinch phone tablet.
Besides smartphones and tablets, Android is also beginning to appear in dedicated devices, such as e-book readers. The Barnes and Noble’s NOOKcolor, which is a color e-Book reader running the Android OS.
In addition to these popular mobile devices, Android is also slowly finding its way into your living room. People of Lava, a Swedish company, has developed an Android-based TV, call the Scandinavia Android TV.

What is Android?

Android is a free phone operating system that aims to get all kinds of phones running like computers and, most importantly, connecting to the web. It's been developed primarily by Google, though others have helped, and it's a project that's constantly updating, growing, and getting a new look. In this chapter, you'll learn what makes Android different from iPhones, BlackBerry phones, and other so-called smartphones.
Android is a version of the very free and open Linux operating system, but tailored for a computer that has just a few buttons and a touch-sensitive screen. It's not a single phone or line of phones, like Apple's iPhone, though the Verizon/Motorola Droid model might make you think that. Put simply, Android is a bundle of code, mostly developed by Google, that allow phones with small screens and tiny chips to do great things.

Android Features
You can have the My Tracks app follow you via GPS and record your progress on a map, or in a spreadsheet. You can listen to your MP3s or streaming podcasts, read and respond to emails, and get turn-by-turn directions as you walk around a city you don't know—all at the same time. If you can't do something, there's a good chance an app in the Android Market can do it, and you can download it at any time.
Sure, you can browse the web, make phone calls, and send text messages (or SMS, for the purposes of this guide), but you can do that on most any phone these days. What makes Android different are the features such as sync with Google, true multi-tasking, get totally customized, and use open software.
As Android is open source and freely available to manufacturers for customization, there are no fixed hardware and software configurations. However, Android itself supports the following features:
  • Storage — Uses SQLite, a lightweight relational database, for data storage.
  • Connectivity — Supports GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth (includesA2DP and AVRCP), WiFi, LTE, and WiMAX.
  • Messaging — Supports both SMS and MMS.
  • Web browser — Based on the open-source WebKit, together with Chrome’s V8 JavaScript engine
  • Media support — Includes support for the following media: H.263, H.264 (in 3GP or MP4container), MPEG-4 SP, AMR, AMR-WB (in 3GP container), AAC, HE-AAC (in MP4 or3GP container), MP3, MIDI, Ogg Vorbis, WAV, JPEG, PNG, GIF, and BMP
  • Hardware support — Accelerometer Sensor, Camera, Digital Compass, Proximity Sensor, and GPS
  • Multi-touch — Supports multi-touch screens
  • Multi-tasking — Supports multi-tasking applications
  • Flash support — Android 2.3 supports Flash 10.1.
  • Tethering — Supports sharing of Internet connections as a wired/wireless hotspot

After a few days with an Android phone—about a week of inquisitive use—you'll probably get used to how Android wants to get your data to you, and how you can get at the things you want.

HIS : Splitting A Large and Complex System Into Simpler Sub-systems

In the development of the hospital information system would be better if done through a modularization into several sub-systems. For example, in this paper we split into the following subsystems:
- Personlia
- Registration of patients coming
- Outpatient and / or ER
- Radiology and Laboratory Examination
- Inpatient
- Pharmacy
- Cashier
Modularization aims to facilitate the management of the hospital information system to be developed. By splitting a large and complex systems into simpler sub-systems will certainly be developed by several different teams at the same time, which would certainly speed up the development process. Surely that must be considered is the integration of sub-systems are interconnected.
Of the sub-system that we have designed the above will be used to construct an appropriate database schema. Each sub-system is expected to be made of the database schema, and will be even better, for further development, if in each sub-system create the database schema on each server hardware.
In an upcoming article, we try to create a database schema for above sub systems using MySQL Workbench.

Calculation of Inventory Through The Trigger Mechanism on The Transaction Table

This time we will discuss about the computerization of inventory in the warehouse (location) is done automatically at the time the transaction is entered into a purchase transaction table, into the sales transaction table, as well as mutations in the transaction table movement of goods between warehouses (locations). The assumption of this discussion is about the stock of drugs in the hospital pharmacy, the location of the drug in some places.
For the above, the following is the syntax of SQL that is run on Microsoft SQL Server 2000 Personal Edition.
CREATE TABLE [dbo].[Master_Obat] (
    [Kode_Kelompok] [varchar] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [Kode_Obat] [varchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [Nama_Obat] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [Satuan] [varchar] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [Harga_beli] [money] NULL ,
    [Harga_Jual] [money] NULL ,
    [Kode_Pabrik] [varchar] (4) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Master_Obat] ADD
    CONSTRAINT [PK_Master_Obat] PRIMARY KEY  CLUSTERED
    (
        [Kode_Obat]
    )  ON [PRIMARY]
GO
---------------------------------------------------
Master_obat tables are used to store master data medicine overall. In this table has a field that is drug code, drug name, unit, purchase price, sales price, and several other fields as needed.
---------------------------------------------------

CREATE TABLE [dbo].[Gudang] (
    [kode_gudang] [varchar] (5) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [Nama_gudang] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [Is_GudangUtama] [bit] NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Master_Obat] ADD
    CONSTRAINT [PK_Master_Obat] PRIMARY KEY  CLUSTERED
    (
        [Kode_gudang]
    )  ON [PRIMARY]
GO
---------------------------------------------------

CREATE TABLE [dbo].[StokGudang] (
    [kode_gudang] [varchar] (5) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [kode_obat] [nvarchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [stok] [int] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Master_Obat] ADD
    CONSTRAINT [PK_Master_Obat] PRIMARY KEY  CLUSTERED
    (
        [Kode_gudang]
        [Kode_obat]
    )  ON [PRIMARY]
GO
----------------------------------------------
Both of the above table is used to store information drug stocks at each location.
----------------------------------------------

Next is a purchase transaction table as shown below. At the time of the purchase transaction information is stored in two tables, namely, purchase table and table purchase details.

CREATE TABLE [dbo].[Pembelian] (
    [Nomor_Pembelian] [varchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [Nomor_Faktur] [varchar] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
    [Tanggal_Pembelian] [datetime] NULL ,
    [pemasok] [varchar] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Master_Obat] ADD
    CONSTRAINT [PK_Master_Obat] PRIMARY KEY  CLUSTERED
    (
        [Nomor_Pembelian]
    )  ON [PRIMARY]
GO

-------------------------------------------------------
CREATE TABLE [dbo].[Pembelian_Detail] (
    [Nomor_Pembelian] [varchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [Kode_Obat] [nvarchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [quantity] [int] NOT NULL ,
    [Harga_beli] [money] NULL ,
    [harga_jual] [money] NULL
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[Pembelian_Detail] ADD
    CONSTRAINT [PK_Pembelian_Detail] PRIMARY KEY  CLUSTERED
    (
        [Nomor_Pembelian],
        [Kode_Obat]
    )  ON [PRIMARY]
GO

ALTER TABLE [dbo].[Pembelian_Detail] ADD
    CONSTRAINT [FK_Pembelian_Detail_Pembelian] FOREIGN KEY
    (
        [Nomor_Pembelian]
    ) REFERENCES [dbo].[Pembelian] (
        [Nomor_Pembelian]
    )
GO

Drug stocks counting mechanism through trigger on the table purchase details, as described below. Trigger occurs when the INSERT, DELETE, and UPDATE.

SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO

CREATE TRIGGER tbl_PembelianDetail_Trigger1
ON dbo.Pembelian_Detail
FOR INSERT
AS
    declare @no_beli     varchar(12)
    declare @kod_obt     nvarchar(8)
      declare @qty     int
    declare @stk     int
    declare @hrg_beli    money
    declare @hrg_jual    money

    SELECT     @no_beli  = ins. nomor_pembelian,
        @kod_obt = ins.kode_obat,
        @qty = ins.quantity,
        @hrg_beli = ins.harga_beli,
        @hrg_jual = ins.harga_jual
    FROM inserted ins

    SELECT @stk = Stok
    FROM StokGudang
    WHERE (kode_gudang = (SELECT Kode_Gudang
                   FROM Gudang
                   WHERE Is_gudangUtama = 1))
         AND (kode_obat = @kod_obt)

    UPDATE StokGudang
    SET stok = @stk + @qty
    WHERE  (kode_gudang = (SELECT Kode_Gudang
                   FROM Gudang
                   WHERE Is_gudangUtama = 1))
         AND (kode_obat = @kod_obt)

    UPDATE master_obat
    SET harga_beli = @hrg_beli, harga_jual = @hrg_jual
    WHERE kode_obat = @kod_obt


GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO

CREATE TRIGGER tbl_PembelianDetail_Trigger2
ON dbo.Pembelian_Detail
FOR DELETE
AS
    declare @no_beli     varchar(12)
    declare @kod_obt     nvarchar(8)
      declare @qty     int
    declare @stk     int

    SELECT     @no_beli  = del. nomor_pembelian,
        @kod_obt = del.kode_obat,
        @qty = del.quantity
    FROM deleted del

    SELECT @stk = Stok
    FROM StokGudang
    WHERE  (kode_gudang = (SELECT Kode_Gudang
                   FROM Gudang
                   WHERE Is_gudangUtama = 1))
         AND (kode_obat = @kod_obt)

    UPDATE StokGudang
    SET stok = @stk - @qty
    WHERE  (kode_gudang = (SELECT Kode_Gudang
                   FROM Gudang
                   WHERE Is_gudangUtama = 1))
         AND (kode_obat = @kod_obt)

GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO

CREATE TRIGGER tbl_PembelianDetail_Trigger3
ON dbo.Pembelian_Detail
FOR UPDATE
AS
    declare @no_beli     varchar(12)
    declare @kod_obtIns     nvarchar(8)
    declare @kod_obtDel     nvarchar(8)
      declare @qtyIns     int
    declare @qtyDel     int
    declare @stk     int
    declare @hrg_beliIns    money
    declare @hrg_jualIns    money
    declare @hrg_beliDel    money
    declare @hrg_jualDel    money

     SELECT     @no_beli  = ins. nomor_pembelian,
        @kod_obtDel = del.kode_obat,
        @kod_obtIns = ins.kode_obat,
        @qtyDel = del.quantity,
        @qtyIns = ins.quantity,
        @hrg_beliDel = del.harga_beli,
        @hrg_beliIns = ins.harga_beli,
        @hrg_jualDel = del.harga_jual,
        @hrg_jualIns = ins.harga_jual
    FROM deleted del, inserted ins

    SELECT @stk = Stok
    FROM StokGudang
    WHERE (kode_gudang = (SELECT Kode_Gudang
                   FROM Gudang
                   WHERE Is_gudangUtama = 1))
         AND (kode_obat = @kod_obtDel)

    UPDATE StokGudang
    SET stok = @stk - @qtyDel
    WHERE (kode_gudang = (SELECT Kode_Gudang
                   FROM Gudang
                   WHERE Is_gudangUtama = 1))
         AND (kode_obat = @kod_obtDel)

    SELECT @stk = Stok
    FROM StokGudang
    WHERE (kode_gudang = (SELECT Kode_Gudang
                   FROM Gudang
                   WHERE Is_gudangUtama = 1))
         AND (kode_obat = @kod_obtIns)

    UPDATE StokGudang
    SET stok = @stk + @qtyIns
    WHERE (kode_gudang = (SELECT Kode_Gudang
                   FROM Gudang
                   WHERE Is_gudangUtama = 1))
         AND (kode_obat = @kod_obtIns)
   
    UPDATE master_obat
    SET harga_beli = @hrg_beliDel, harga_jual = @hrg_jualDel
    WHERE kode_obat = @kod_obtDel

    UPDATE master_obat
    SET harga_beli = @hrg_beliIns, harga_jual = @hrg_jualIns
    WHERE kode_obat = @kod_obtIns


GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO
-----------------------------------------------

Database Object Naming Standards

A naming standard is a collection of rules, which, when applied to data, results in a set of data objects named in a logical and standardized way. These names convey some information about the named objects; an element name, for example, indicates the set of possible valid values (its data domain), and its usage. Having naming standards helps to achieve efficient use and reuse of data through better understanding of what data is in the system. Standardized names enhance communications about data within the BI community, from source application developers to BI experts to end users.
These standards apply to database objects created explicitly for Business Intelligence. Use reasonably meaningful names for tables and fields. If they get too long then try to use fairly standard (but consistent) abbreviations. If in doubt, just remove the vowels (a, e, i, o, u).
For each table also have a three letter acronym. Then if you have an 'ID' field that is used in foreign key relationships, then put the three letter acronym before the '_ID' name in ALL the tables that use it including the owning table.
Develop a list of standard suffixes, for example:
_FL for flags (usually only Y and N)
_IND for indicators (typically single byte varchar2 fields)
_NO for numeric numbers
_NUM for character numbers
_DT for dates
_TS for date-time stamps
 
If you have a set of tables that are closely related then SERIOUSLY consider giving them the same prefix or name root.
As far as object naming standards go, the advice above is as good as any. Most important is to BE CONSISTENT. Google "Database Naming Standards" and look at some of the documents you find - especially those on domains with .edu. - universities are red-hot on this sort of thing.
Also search for Oracle Database Design Standards, or variants of that phrase. Someone has done this already and will have published them on the web.
 

Pharmacology Clinical Decision Support System Software

Information technology has made a significant impact on the healthcare sector. The past decade has witnessed the foray of numerous information systems and their resultant products into the hospital scenario. The number of investments in computers and types of hospital systems has increased. This is because paper medical records are cumbersome, bulky to use and difficult to manage. On the other hand digital records are much easier to handle and improve the workflow efficiency by integrating various tasks.
A Hospital Information System (HIS) can be defined as a computerized system that is designed to meet all the information needs within a hospital. This includes diverse data types such as patient information, billing, finance and accounting, staffing and scheduling, pharmacy ordering, prescription handling, supplies, inventory, maintenance and orders management, diagnostic reports related to laboratory, radiology and patient monitoring as well as providing decision support. 
Pharmacology Clinical Decision Support System, as a sub system of Hospital Information System, increases patient safety by alerting the physicians to potential errors and providing them with requested counseling information. It integrates with all computerized solutions for medicine prescription such as e-prescribing, EMR (Electronic Medical Record), PIS (Pharmacy Information system) and CPOE (Computerized Physician Order Entry). Pharmacology CDSS should consists of the following elements:
  • Alerts - Alerts the user to various types of errors involved in the prescription of medications. 
  • Counselor - on demand clinical advises related to drug therapy.
  • CCMS - Brings in-house clinical content to the point of care.
  • Tools - Provides tools for local adaptation, report generation, system configuration, etc.
  • Interface - Interfaces the prescription application and provides the information to the users via the prescription/EHR applications.
Some benefits for healthcare organizations:

·         Increases patient safety by reducing medication errors
·         Protects the goodwill of healthcare organizations and physicians
·         Simple, seamless and swift integration to existing EMR/CPOE/PIS/e-prescription solutions
·         Increases efficiency- reduces operational costs and efforts invested in law suits

Development of Computerized Nursing Process Documentation System Using NANDA, NOC, and NIC Linkages

The nursing care plan was developed by linking the nursing diagnosis, desired nursing outcome and suggested nursing intervention based on NANDA, NOC, and NIC linkage. The fetched sentences linked with each nursing activity supports nursing documentation.
The data model uses the NNN classifications to map a possible form of the nursing process in the electronic patient health record, where the nurse can choose nursing diagnoses, outcomes, and interventions relevant to the patient situation. The nurses' choice is guided both by the different classifications and their linkages, and the use of specific text components pre-defined for each classification and accessible through the respective linkages.
The main point of the system development is to give a specific code to each nursing activity in Nursing Intervention Classification(NIC), to link an expressible recording sentence with each activity, and to try to link a related nursing cost with each activity.
Although information systems may appear to be cold and literal, there is no reason why an electronic patient records system should do anything but enhance the clinical role of the nurse by saving time and improving documentation. The process of development was as follows;
  1. An expert group must be organized to develop the computer based nursing process documentation system. The range of computerization was determined to support nursing care plan and nursing documentation, and to provide the statistical data of the nursing care plans.
  2. The expert group analyzed the care planning process and nursing documentation process. The group also determined developmental principle, standard language, basic data.
  3. Organization and arrangement of basic data, database construction, designing of the user interface system, code construction, program construction were accomplished. It is a huge database.
  4. A users manual that focuses on usage instructions, standardized nursing language and nursing process was then developed.

Sample Preparation of The Hospital Database Schema

In general, the flow of services in a hospital is like this, first a patient comes in to register for the examination of physicians in ambulatory care or emergency services. Patients who had taken care of at the hospital will certainly use the medical record number previously used by the patient, while the patient who first came to the hospital services is going to get a new medical record number. At the time of enrollment to obtain health care, the patient receives a unique registration number.

Furthermore, patients who have registered earlier will be waiting in line queue in outpatient services to be handled by the appropriate physician, or if the patient signed up for emergency services must be immediately examined by a physician in the emergency services and other medical personnel.

In the next stage, doctors in ambulatory care or emergency care earlier may require further examination in clinical laboratory services or radiology services. This is certainly an attempt to confirm the diagnosis of the patient. The results of the examination in clinical laboratory services or radiology services will soon be given to the doctor, and then the doctor will give the patient the drug therapy.

After stage ambulatory care and emergency services to the clinical laboratory and radiology examinations and drug therapy is considered adequate, then there are two possibilities for a patient to move to the next stage. Two possibilities are patient immediately make payment at the cashier or, on the advice of the doctor patient continued to inpatient services.

From the description above it can be seen that the system of hospital services can be broken down into several sub-systems are interconnected. Sub system include patient registration system, the system in the outpatient, emergency service systems, systems in clinical laboratory services, radiology services system, a system in pharmacy services, payment systems at the checkout. Each of these sub-systems and sample preparation of the database schema will be discussed in further discussion.

Entities And Types of Entity in The E-R Approach

The first step in the E-R approach is to select the entities that will be used to model the enterprise. An entity is quite similar to an object, except that an entity does not have methods. It might be a concrete object in the real world, such as Nurse Paula, the Pajero Sport parked at 123 Main Street, or the Foreign Affair Building, or it might be an abstract object, such as the patient medical record account 123456789, the database course MK305, or the Engineering Faculty at UGM Yogyakarta.
Similar entities are aggregated into entity types. For instance, Kevin Cruise, Mary Hart, Joe Fitzgerald, and Giselle White might be aggregated into the entity type Person based on the fact that these entities represent humans. Kevin Cruise and Joe Fitzgerald might also belong to the entity type Patient because in our sample database these objects presumably represented patients. Similarly, Mary Hart and Giselle White might be classified as members of the entity type Nurse.

Attributes for describing entities
As with relations and objects, entities are described using attributes. Every attribute of an entity specifies a particular property of that entity. For instance, the Name attribute of a Person entity normally specifies a string of characters that denotes the real-world name of the person represented by that database entity. Similarly, the Age attribute specifies the number of times the Earth had circled around the Sun since the moment that real-world person was born.

Domains as the set of values
As in the relational model, the domain of an attribute specifies the set from which its value can be drawn. Unlike the relational model, however, E-R attributes can be set-valued. This means that the value of an attribute can be a set of values from the corresponding domain rather than a single value. For example, an entity type Person might have set-valued attributes ChildrenNames and Hobbies.

Key constraints
As with the relational model, it is useful to introduce the key constraints associated with entity types. A key constraint on an entity type, S, is a set of attributes, A, of S such that
  1. No two entities in S have the same values for every attribute in A (for instance, two different Patients entities cannot agree on both the Name and the MedicalNumber attributes).
  2. No proper subset of the attributes in A has property 1 (i.e., the set A is minimal with respect to this property).
This concept of entity keys is analogous to that of candidate keys in the relational model. One subtle point, though, is that attributes in the E-R approach can be set-valued and, in principle, such an attribute can be part of a key. However, in practice set-valued attributes that occur in keys are not very natural and often indicate poor design.
As with the relational model, we define the schema of an entity type to consist of the name of that type, the collection of the attributes, and the key constraints.

E-R diagram representation
Entity types are represented in E-R diagrams as rectangles, and their attributes are represented as ovals. Set-valued attributes are represented as double ovals. Figure below depicts one possible representation of the Person entity type. Note that in this picture Hobbies is specified as a set-valued attribute and IDCard is underlined to indicate that it is a key.

This simplicity might seem suspicious in view of the fact that entities can have set-valued attributes while relations cannot. How, then, can a set-valued attribute of an entity be turned into a single-valued attribute of the corresponding relation without violating the property of data atomicity of the relational model?
The answer is that each entity that has a set-valued attribute is represented in the translation by a set of tuples, one for each element in the attribute value.
The set-valued attribute Hobby is the trouble maker. To obtain a key of the relation in question, we must include the offending attribute. Thus, the key of the Person relation is {IDCard, Hobby}.
The following CREATE TABLE statement defines the schema for the Person relation.
   CREATE TABLE Person (
       IDCard INTEGER,
       Name CHAR(20),
       Address CHAR(50),
       Hobby CHAR(10),
       PRIMARY KEY (IDCard, Hobby) )

The preceding example is the first indication that the E-R approach alone is not a sufficient tool for guaranteeing good relational design. Next article will provide a host of objective criteria that can help the database designer evaluate the relational schema obtained by converting E-R diagrams into relations. In particular, the problem with the relation is that it is not in a certain “normal form” defined next article. That article proceeds to develop algorithms that can automatically rectify the problem by splitting such offending relations into smaller relations that are in a desired normal form.

THE E-R APPROACH FOR CONCEPTUAL MODELING

The E-R approach is not a relative, a derivative, or a generalization of the relational data model, it is not a data model at all but a design methodology, which can be applied (but is not limited) to the relational model.
Main components of the E-R approach are the concepts of entity and relationship. Entities model the objects that are involved in an enterprise—for example, the patients, physicians, and procedures in a hospital. Relationships model the connections among the entities—for example, professors teach courses. In addition,
integrity constraints on the entities and relationships form an important part of an E-R specification, much as they do in the relational model. For example, A physician/ a doctor can only perform a surgery at a given time on a given day.
An entity-relationship (E-R) diagram is a graphical representation of the entities, relationships, and constraints that make up a given design. It provides a graphical summary of the design that is extremely useful to the designer, not only in validating the correctness of the design but also in discussing it with colleagues and in explaining it to the programmers who will be using it. But unfortunately, there is no standard drawing convention for E-R diagrams, and hence there is a good deal of variation among database texts in many aspects of this approach.
After the enterprise has been modeled with E-R diagrams, there are ways of converting these diagrams into sets of CREATE TABLE statements. But unfortunately, this conversion process does not yield a unique schema, especially in the presence of constraints, because some constraints that can be indicated in the E-R diagrams have no direct counterparts in SQL.
An important advantage of this methodology is that the designer can focus on complete and accurate modeling of the enterprise, without worrying about efficiently executing the required queries and updates against the final database. Later, when the E-R diagrams are to be converted to CREATE TABLE statements, the designer can add efficiency considerations to the final table designs using normalization theory and other techniques.

Create User Interface or Application for HIS - First step : Connecting to DBMS

In this article we talk about application software that used by user to access to the hospital information system. For practical purpose, we require Delphi 7, MySQL for Windows, and ODBC Driver for MySQL.
Some example of how to connect to and query an MySQL database using Delphi 7 :
  • You could use ZeosLib freeware components in http://sourceforge.net/projects/zeoslib/
  • MySQL has a ODBC Connector that allows you to use ADO components to connect and query the database! Here is the information: http://www.devarticles.com/c/a/Delph...hi-with-MySQL/
1. Create data module form to manage database components of your project, give a name such as frmMyData.
2. On the data module form, put an ADOConnection component, give it a name such as myConn.
3. In ConnectionString properties field of myConn, type this:
Provider=MSDASQL.1;Password=somepassword;Extended Properties="DRIVER={MySQL ODBC 5.1 Driver};PWD=somepassword;SERVER=servername;PORT=3306;DATABASE=somedbname;USER=root;OPTION=3;"
4. In LoginPrompt field of myConn choose False.
5. Then we can use myConn to fill Connection properties field of ADOTable, ADOStoredProc or other ADO components in frmMyData data module form.
 

MySQL Routine (Stored Procedure) To Insert a User Into tUser Table

We assume that you have read about personnel sub system in the hospital information system that presented before at http://databasescript.blogspot.com/2012/10/entity-relationship-model-of-hospital.html
In this article will take up about inserting a user id, password and other fields that related to tUser table in personnel sub system. This procedure of inserting a user will affect to the procedure of user login at the later. Here is the syntax of creating the routine.
CREATE DEFINER=`root`@`localhost` PROCEDURE `insertuser`(
   IN p_user_id varchar(20),
   IN p_encrypted_pass varbinary(100),
   IN p_personID varchar(18))
BEGIN
 DECLARE vMidUserId varchar(3);
 DECLARE vMidIdPegawai varchar(6);
 SET vMidUserId = MID(p_user_id,1,3);
 SET vMidIdPegawai = CONCAT(RIGHT(p_personID,2),LEFT(p_personID,4));

 INSERT INTO tuser(user_id, kata_sandi,idPegawai)
 VALUES(p_user_id,
       AES_ENCRYPT (p_encrypted_pass ,CONCAT(vMidUserId,vMidIdPegawai)),
       p_personID);
END 

One important thing in this routine is the encryption of the user password. Of course you can modify the AES_ENCRYPT option with one you like. The AES_ENCRYPT also use in the login stored procedure, and we will talk about it in the later article.

Entity Relationship Model of a Hospital-Based Database System

In the ER diagram of a Hospital-Based Database System, we can view the entities are Patient, Doctor, Receptionist, Department, Medicine, Test, etc. Among these entities, relationships exist which connect all the entities in the diagram. For example, Patient, Doctor and Receptionist are connected via the relationship Appointment. In other words, a receptionist will set up a doctor’s appointment for a patient. Similarly, Doctor, Patient and Medicine are connected via the relationship Prescription. Here, a doctor may prescribe one or more medicine to a patient. In a similar way, other entities are connected via relationships in a meaningful way.
In this article will be explained about entities or tables that consist in the sub system personnel/ employee of the hospital database.
This sub system maintain some functionalities such as user login, user permission on accessing the system, etc. These tables are created by using DDL syntax in MySql Workbench for MySql database management system. We assume that you are familiar with SQL syntax.

Person
CREATE TABLE Person(
  `personID` varchar(18) NOT NULL,
  `Name` varchar(45) DEFAULT NULL,
  `Is_Active` bit(1) DEFAULT NULL,
  PRIMARY KEY (`personID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
This table will store all personnel/ employee of the hospital

Specialists
CREATE TABLE `specialists` (
  `specialistID` varchar(2) NOT NULL,
  `Title` varchar(15) DEFAULT NULL,
  `Specialist` varchar(25) DEFAULT NULL,
  PRIMARY KEY (`specialistID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
This table is for look up table used by Doctor/ Physician table.

Doctor/ Physician
CREATE TABLE `dokter` (
  `doctorID` varchar(4) NOT NULL,
  `personID` varchar(18) DEFAULT NULL,
  `specialistID` varchar(2) DEFAULT NULL,
  PRIMARY KEY (`doctorID`),
  UNIQUE KEY `personID_UNIQUE` (`personID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
This table stores the identity of each doctor, and will be used in another sub system too such as emergency room sub system, ambulatory sub system, inpatient sub system, etc

User.
CREATE TABLE `tuser` (
  `user_id` varchar(20) NOT NULL,
  `encrypted_pass` varbinary(100) DEFAULT NULL,
  `personID` varchar(18) DEFAULT NULL,
  PRIMARY KEY (`user_id`),
  UNIQUE KEY `personID_UNIQUE` (`personID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
This table stores the user id and password for each person that use the hospital information system entirely. When aplication of each sub system is launched, user will be prompted to input user id and password, if user id and password is match then system will query to table that store every user permition to the system, this table may be "user_modul" or something else like that. Of course this happen at the application level/ user interface level.
May be we need more tables such as Nurse, Officials, etc. It will be presented in next articles.

Techniques of Data Mining in Healthcare or Hospital System

Health care nowadays collects data in gigabytes per hour volume. Data mining can help with data reduction, exploration, and hypothesis formulation to find new patterns and information in health care data that surpass human information processing limitations. There is a spread of reports and articles that apply data mining to a wide variety of health care problems and clinical domains and includes diverse projects related to cardiology, cancer, diabetes, finding medication errors, and many others.
Methods in data mining use powerful computer software tools and large clinical databases, sometimes in the form of data repositories and data warehouses, to detect patterns in data. Within data mining methodologies, one may select from an extensive array of techniques that include classification, clustering, and association rules.
Classification
Classification in data mining maps data into predefined groups or classes. Also it is often referred to as supervised learning because the groups or classes are determined before examining the data. Classification algorithms require that the groups or classes be defined based on data attribute values. They often describe these classes by looking at the characteristics of data already known to belong to the classes. Pattern recognition is a type of classification where an input pattern is classified into one of several classes based on its similarity to these predefined classes. One of the applications of classification in health care is the automatic categorization of medical images.
Clustering
Clustering is similar to classification except that the groups are not predefined, but rather defined by the data alone. Clustering is alternatively referred to as unsupervised learning or segmentation. It can be thought of as partitioning or segmenting the data into groups that might or might not be disjointed. The clustering is usually accomplished by determining the similarity among the data on predefined attributes. The most similar data are grouped into clusters.
Clustering can be used in designing a triage system. Triage helps to classify patients at emergency units to make the most effective use of resources distributed. The more important is that accuracy in carrying out triage matters greatly in terms of medical quality, patient satisfaction and life security.
Association rules
Determining association rules is refers to the data mining task of uncovering relationships among data. An association rule is a model that identifies specific types of data associations. These associations are often used in the retail sales community to identify items that are frequently purchased together.
The discovery of new knowledge by mining medical databases is crucial in order to make an effective use of stored data, enhancing patient management tasks. One of the main objectives of data mining methods is to provide a clear and understandable description of patterns held in data. One of the best studied models for pattern discovery in the field of data mining is that of association rules. The accuracy and importance of association rules are usually estimated by means of two probability measures called confidence and support respectively. Discovery of association rules is one of the main techniques that can be used both by physicians and managers to obtain knowledge from large medical databases.

MySQL Workbench for working with MySQL Servers

MySQL Workbench provides a graphical tool for working with MySQL Servers and databases. It fully supports MySQL Server versions 5.1 and above. It is also compatible with MySQL Server 5.0, but not every feature of 5.0 may be supported. It does not support MySQL Server versions 4.x.
MySQL Workbench provides three main areas of functionality:
  • SQL Development: This module enables you to create and manage connections to database servers. As well as enabling you to configure connection parameters, MySQL Workbench provides the capability to execute SQL queries on the database connections using the built-in SQL Editor. This functionality replaces that previously provided by the Query Browser standalone application.
  • Data Modeling: This module enables you to create models of your database schema graphically, you can reverse and forward engineer between a schema and a live database, and edit all aspects of your database using the comprehensive Table Editor. The Table Editor provides easy-to-use facilities for editing Tables, Columns, Indexes, Triggers, Partitioning, Options, Inserts and Privileges, Routines and Views.
  • Server Administration: This module enables you to create and administer server instances.
MySQL Workbench is available in two editions, the Community Edition and the Standard Edition. The Community Edition is available free of charge. The Standard Edition provides additional Enterprise features, such as database documentation generation, at low cost. 

MySQL Workbench Editions
The Community Edition (OSS)
The Community Edition is the foundation of all MySQL Workbench editions—versions that are currently available or those that will become available in the future. All editions of MySQL Workbench are based on the Community Edition and all future improvements to the base framework and feature set will be included in this version. The Community Edition is a full feature product that puts a powerful database management tool into the hands of the MySQL community.
The Standard Edition
The Standard Edition is a commercial extension that builds on top of the OSS Edition and adds modules and plugins, enabling an optimized work flow. The highlights of this edition are:
  • MySQL Specific Schema Validation
  • Model Validation
  • General Schema Validation
  • DBDoc
DBDoc provides the following features:
  • Document complex database schemata
  • Document all SQL object types
  • Document output available in different file formats
A comparison of edition features can be found at MySQL Workbench Developer Central

MySQL Workbench is available for the following platforms:
  • Windows
  • Linux
  • Mac OS X
Binary distributions of MySQL Workbench are available for the preceding platforms. Source code distributions are also available as a tar.gz package or an RPM package.
The following sections explain the installation process for each of these platforms.

Advantages Of An ODBMS

Advantages Of An ODBMS

We can list some of the advantages that we have found in using an ODBMS environment for a website.

Simplicity
We have no doubt that the simplicity of using an ODBMS contributes significantly to our ability to rapidly develop and deploy new functionality and bug fixes. It is extremely straightforward to create and persist Abstract Data Types, since the persistence mechanism directly supports classes and objects, requiring no extra work to map classes to tables (as required by an RDBMS implementation). An ODBMS also directly supports inheritance, which means that no difficult design decisions have to be made regarding the splitting of instance variable storage across tables.
Development cycles are measured in weeks and days - not the months that have typically been the case in many projects that we have worked on. In our opinion much of our efficiency can be attributed to our use of a Java ODBMS. The transactional model of the ODBMS is easy to understand, there is no database language syntax to learn, over and above that of the implementation language. Developers do not need to
use another language to express the database schema, because the Object Model as defined by the Java application classes is the schema.

Schema Management
The persistent Object Model is identical to that of the application class hierarchy. Managing a persistent Object Model is far simpler than managing an environment where the in memory structures are different than those on disk. However, care must be taken in designing the entry points to the large collections of root objects in the system. Less experienced developers often err in creating multiple root objects for the same underlying tree of objects, leading to confusion and incoherency in the model.

Code Independence
We have found that the completely non-invasive transactional model makes it possible to insulate most business objects in the system from having any knowledge of the underlying database. This is important in the event that we might have to migrate to some other environment at a later stage.
Knowledge of the persistence mechanism system is encapsulated in 27 of the 1000 (or so) application classes. While some O/R mapping environments will allow for a clean separation of this knowledge, many OO systems making use of an RDBMS must directly embed knowledge of SQL and tables deeply in the application classes themselves.
It is important to clarify the above point, no-where in our system does any object have to actively participate in the mechanism used to persist it. This is often the case in either purchased or home-grown O/R mapping frameworks, since classes need to have some knowledge
of what tables they fit in. It is only due to the fact that objects are persisted as objects and not fragmented into various atomic database types that this is possible. The knowledge of the persistence mechanism that is embedded in the 27 or so “aware” classes is purely related to obtaining connections to the database and management of database specific transactional mechanisms.

Natural Object Model
In an environment that uses an ODBMS, objects that refer to other objects always “contain” the object that they reference. What we mean by this is that there is no distinction between an “in-memory” object and an “on disk” object. In systems that make use of an RDBMS, objects are often found to contain a key or an index to the referenced object. Once again, some O/R mapping environments remove this complexity but more often than not, the fact that the referenced object is not actually stored as an object leaks through into the Object Model. Objects are always objects in the ODBMS model, and are always available. This naturalness of expression for the developer as well as the designer is very difficult to achieve in any RDBMS environment.

Collections
Many ODBMS vendors provide highly optimized Collection classes that can be used to provide efficient management of vast numbers of objects. Iteration over (and management of) the collections is straightforward and can be used without any complicated setup routines. We believe this is a distinct advantage to developers.

Performance
Performance is vital to the online experience, online users expect snappy responses. Some architects believe that doing things in a pure OO manner leads to poor performance. In many situations involving the storage and retrieval of objects, an ODBMS does deliver significant performance gains over other persistence mechanisms. We hasten to add that there are some instances when an RDBMS will outperform an ODBMS. These instances often occur when it is
necessary to perform arbitrary queries over large collections of objects.

Design Recovery (quickly and easily correct design mistakes)
By this odd term we mean the ability to quickly and easily correct design mistakes in the class hierarchy/ schema. Since the schema of the database is the class hierarchy as defined by the Java classes in the system, changing a class definition to correct a mistake in design or implementation is relatively simple.
In systems where there is a distinction between the class hierarchy and the database schema correcting flaws can become a complicated matter. Because the schema of an RDBMS is available to other modules (possibly developed outside of the scope of the larger system) errors are often introduced when making changes to the database structure. Changes to the RDBMSs schema may differ from the expectations of external programs. Such conflicts cannot occur in a true ODBMS since there is no difference in structure between in-memory in-use instances and those persistently stored on disk. There are however other problems that can occur when changing schemas.

Retention of Objects
Developers make mistakes. In an RDBMS these mistakes may occasionally lead to situations where inadvertently deleting a row in a table can lead to dangling references, since triggers are often imperfectly implemented. An ODBMS with Garbage Collection based object removal completely eliminates this problem. Persistent objects are only “deleted” once they are no longer referenced by any other instances reachable from a well-defined root object. The ability to recover from an accidental deletion has often allowed system to recover gracefully from potentially embarrassing situations. This has occurred when flawed code eliminates the primary reference to an object. Because other objects still referenced the “deleted” object, it was possible to restore the reference and thus recover the object. Obviously this only works if a persistent Garbage Collection has not been performed.

Implementation of The Secure Hospital Database

The hospital database should be implemented on a relational DBMS that are protected from user access both by the permissions on directories containing the database files and the permissions on the database files themselves. Users cannot look at the files in the database except through DBMS and its protection scheme; that is users cannot access the database at the operating system level. Additional binary files with special format are included, making decoding of any information more difficult. Moreover, DBMS has a built-in hierarchical security system. The database administrator (D.B.A.) controls the types of access allowed to various levels of users using this system.

The security labels which were defined during the secure conceptual design phase were implemented using the notions of roles and groups supported by DBMS. The user roles handled in our implementation are: doctor, normal nurse, and special nurse. The notion of user roles was implemented using the notion of user groups, provided by DMBS (a group is an identifier that can be used to apply permissions to a list of DBMS
users associated with the identifier). After performing a study on the considered users roles, the following clearances were assigned to them: clearance level 3 to the user role doctor, clearance level 2 to the user role special nurse, and clearance level 1 to the user role normal nurse.

The data sets loaded on the hospital database are: the nurse record, the doctor record, the patient record, which contains the medical information, the laboratory information, the follow-up information and the personal patient information. Being a relational database management system, DBMS stores data in tables. The labelling of the data sets was described above. However, it can change dynamically, if one of the security
constraints is satisfied, leading to upgrading and/or fragmentation. The classification level of each tuple of a table was implemented by adding at each table a column. This column contained the tuple classification; that is 1,2,3 instead of confidential, secret, top secret. Zero (0) indicates that the data contained in the tuple is cover story. Of course, the tuple class data was only visible to the D.B.A.

Apart from that, an additional column was added to the related medical data tables, containing the flag ‘h’ (history) or ‘l’ (last). This flag was automatically updated, when new relevant data was inserted. This is one of the integrity constraints that were implemented in the database.

Users were allowed to have access to the data only trough predefined forms. An DBMS form is the electronic equivalent of a paper form; it is displayed on the computer screen and is used for data input and data display. Forms consist of trim, text that provides helpful information, and fields. The latter display the data and accept data entry.

The access types supported from the secure prototype application are insert, read, update, execute, cancel. Thus, the possibility of deleting information is excluded. This was necessary, not only for reasons of better control of the information flow, but also for reducing the possibility of fatal mistakes.

The security constraints defined earlier were implemented using rules and procedures written in SQL.

Implementation of Secure Database On a Hospital

A hospital, with health care information systems is one case of a security critical environment. It is one of the few environments, in which a confidentiality breach, wrong information or even a relatively minor loss of access to information may be life-threatening. Security is therefore an important issue which encompasses all aspects of the organization, from patient and staff safety to deeply personal information about staff and patients that is distributed throughout the organization. Due to the widespread use of the database technology, database security plays today a significant role in the overall security of health care information systems.
The development of a secure database for health care information system requires an appropriate multiphase design methodology which will guide the steps of the development and will provide tools supporting the automatic execution of some steps. The proposed methodology and security policy helps ensure all three aspects of security (secrecy, confidentiality and availability), without introducing significant overheads. It is based on the integration of mandatory and discretionary security policies and takes security into consideration from the very first steps of the design.
The choice of an appropriate security policy and a suitable secure database design methodology is crucial in each of health care environments. The two most well known proposals for the database security policies are the mandatory and the discretionary ones. Discretionary security policies govern the access of users to the information on the basis of the user’s identity and the rules specifying, for each user and each object in the system, the types of access the user is allowed on the object. Discretionary security policies are flexible and suitable for a variety of implementations. However, they provide insufficient control of the information flow (e.g. they are vulnerable to malicious attacks such as the Trojan Horses). On the other hand, mandatory security policies provide a high level of certification for security, based on the use of unforgeable security labels, which are assigned both to users and data. Thus, they allow one to track the flow of information. They are however mainly suitable to certain kinds of environments where the users and the objects can be easily classified (i.e. the military one).
None of these two major policies are sufficient by itself to cover the security needs of the health care environments. Hence, it has been necessary to propose a new security policy, which has been based on the integration of mandatory and discretionary control policies. In order to maximize the effectiveness and decrease the complexity of implementing this policy, a step by step design methodology with integrated security has been proposed. In particular, the responsibility of the role in the application determines the security label (clearance) of the user role. The security label (classification) of the data represents its level of sensitivity. The user roles are assigned a node at the user role hierarchy (URH). Then, beginning from the lower level of the hierarchy, the data items are assigned a security label equal to that of the users that must be cleared to access it. In the end, the security requirements are examined. This may lead to fragmentation of some relations and/or upgrading (since we support tuple level granularity). It must be noted that polyinstantiation - which is a characteristic of the multilevel security policy - is supported only in the form of cover stories. This is possible, due to the support of the write down mechanism (with no fear of inference), which is essential for the hospital environment.

Data Mining Process in Hospital Information System

Data mining aims at discovering novel, interesting and useful knowledge from databases. Conventionally, the data is analyzed manually. Many hidden and potentially useful relationships may not be recognized by the analyst. Many organizations including modern hospitals are capable of generating and collecting a huge amount of data.
Data stored in medical databases are growing in an increasingly rapid way. Analyzing that data is crucial for medical decision making and management. It has been widely recognized that medical data analysis can lead to an enhancement of health care by improving the performance of patient management tasks. There are two main aspects that define the need for medical data analysis.
  1. Support of specific knowledge-based problem solving activities through the analysis of patients’ raw data collected in monitoring.
  2. Discovery of new knowledge that can be extracted through the analysis ofrepresentative collections of example cases, described by symbolic or numericdescriptors.
For these purposes, the increase in database size makes traditional manual data analysis to be insufficient. New research fields such as knowledge discovery in databases (KDD) have rapidly grown in recent years. The main step in the knowledge discovery process, called data mining, deals with the problem of finding interesting regularities and patterns in data.
A simple data mining process model mainly includes 6 steps:
  1. Assembling the data.
  2. The data warehouse.
  3. Relational database and flat files.
  4. Mining the data.
  5. Interpreting the results.
  6. Result application.
We will study each step in later articles.

The Complex Database Schema of Hospital Information System

At a hospital we find daily activity correspond to medical treatment and other health care business. For example some patients come to internist get some medicine or just routine health check up, some physician get busy treating emergency patient at emergency room, at another place the patient's family go to cashier for paying the bill, etc. It is critical to understand the benefits and limitations of using these large-scale administrative databases. From an evidence-based medicine perspective, these data are important for generating hypotheses but not cause and effect relationships. In other words, the data itself are not specifically collected to address a clinical question, but rather represent a quality assurance process.
The phrase, ‘hospital information system’, is frequently used in discussions about the flow of information throughout a hospital with the assumption that everybody has the same concept in mind. Closer examination shows that this is not necessarily the case. 
Many organizations including modern hospitals are capable of generating and collecting a huge amount of data. This explosive growth of data requires an automated way to extract useful knowledge. Thus, medical domain is a major area for applying data mining. Through data mining, we can extract interesting knowledge and regularities. The discovered knowledge can then be applied in the corresponding field to increase the working efficiency and improve the quality of decision making.
Nowadays, data stored in medical databases are growing in an increasingly rapid way. Analyzing that data is crucial for medical decision making and management. It has been widely recognized that medical data analysis can lead to an enhancement of health care by improving the performance of patient management tasks. There are two main aspects that define the need for medical data analysis.
1. Support of specific knowledge-based problem solving activities through the analysis of patients’ raw data collected in monitoring.
2. Discovery of new knowledge that can be extracted through the analysis of representative collections of example cases, described by symbolic or numeric descriptors.



The Complex Database Schema of Hospital Information System