Database of Scriptum

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;

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.

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 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.

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.