Разработка автоматизированной информационной системы медицинского секретариата и отдела приема пациентов

Курсовая работа По дисциплине: Проектирование автоматизированных систем обработки информации Тема: Разработка автоматизированной информационной системы медицинского секретариата и отдела приема пациентов

1. Анализ требований к информационной системе

1.1 Описание и анализ предметной области

1.2 Анализ функциональных и эксплуатационных требований

2. Проектирование информационной системы

2.1 Разработка архитектуры системы

2.2 Разработка модели предметной области

2.3 Разработка алгоритма функционирования системы

2.4 Проектирование интерфейса пользователя

2.5 Реляционная модель данных

2.6 Построение диаграммы классов

3. Реализация системы

3.1 Реализация программного обеспечения системы Заключение Список литературы Приложение

Разрабатываемый программный продукт является автоматизированной информационной системой медицинского секретариата и отдела приема пациентов. Целью данной курсовой работы является создание информационной системы, с помощью которой упростится поиск информации и работа с документами, как для специалистов секретариата, так и для других сотрудников больницы.

Тема данной работы актуальна, поскольку в настоящее время всё большую популярность получают компьютерные информационные системы, облегчающие работу сотрудников различных сфер деятельности, а также позволяющие быстро и качественно предоставить необходимую информацию.

Правильная организация работы сотрудников больницы является важным моментом в деятельности всего предприятия. Отдел приема пациентов, являясь точкой, с которой всё начинается, вынужден работать с большим количеством людей. Это, в свою очередь, приводит к тому, что происходит документооборот, являющийся источником большого количества бумаги. У специалистов хранится огромное число регистрационных карт, данных о пациентах, сведения о врачах и приемах, а также других данных разного рода, которые являются необходимыми при такой работе. Поэтому возможность выполнения и хранения этих документов в электронном виде является важной и актуальной. Все документы являются результатом выполнения каких-либо операций (или же исходными данными для них). Таким образом, у специалиста должна быть возможность выполнения всех операций на компьютере, что гораздо эффективнее, быстрее и удобнее.

Программный продукт разрабатывается с целью:

— автоматизации работы с документами;

— организация доступа к данным для работников регистратуры и секретариата без непосредственного участия специалиста базы данных;

— автоматизации работы с отчетами.

Цель и назначение разработки

Целью разработки приложения является создание информационной системы отдела приема пациентов и медицинского секретариата, автоматизирующей процессы создания отчетов и других документов, с помощью которых упростится ввод и поиск информации для специалистов отдела и других сотрудников.

Основные задачи разработки

1. Обеспечить авторизованный вход пользователей в систему.

2. Обеспечить создание, изменение и просмотр информации о пациентах, врачах, регистрационных карт, приема пациентов, назначенном лечении.

Программный продукт предназначен для использования в больницах.

Для разработки программного продукта применяется среда визуального объектно-ориентированного программирования Borland Delphi 7, для создания информационной системы используется программа IBExpert, сервер Firebird 2.5.

1. Анализ требований к информационной системе

1.1 Описание и анализ предметной области

Отдел приема пациентов и медицинский секретариат — это комплекс методов и процессов работы с документами, осуществляемый организацией при выполнении своих функций и задач.

С помощью информационной системы экономится время сотрудников отдела за счёт автоматизации документооборота. Внедрение программы существенно снизит время, необходимое на обработку информации и оформление регистрационных карт и других документов.

В работе больницы можно выделить следующие важные составляющие: регистрация информации о пациенте, выдача регистрационной карты пациенту, оформление приема пациента, назначение курсов лечения, создание отчетов, необходимых врачу, внесение информации о врачах. Отдел приема пациентов и медицинский секретариат предусматривает составление и оформление документов по определенным задачам: прием пациента, регистрация, назначение курсов лечения, изменение информации о пациенте, внесение сведений о врачах и т. п. Сотрудник отдела должен своевременно ознакомиться со всеми изменениями. Для работы информационной системы предполагается создание базы данных, содержащей всю информацию о сотрудниках. Внесением информации будут заниматься специалисты отдела приема и медицинского секретариата. Информационная система отдела кадров позволит значительно повысить скорость и эффективность работы сотрудников больницы. Как основной процесс в отделе приема пациентов можно выделить прием нового пациента. При приеме, пациент предоставляет информацию о себе врачу — документы, удостоверяющие личность, страховой полис, необходимые справки. Врач передает необходимую информацию в отдел приема пациентов при первичном обращении пациента. Данные из всех документов специалист отдела приема заносит в регистрационную карту. В день назначения лечения пациент регистрируется в отделе приема пациентов, при этом заносятся дополнительные сведения для регистрационной карты. При приеме пациента в больницу фиксируется прием: дата приема, регистрационный номер больного, номер палаты.

Рисунок 1.1. — Модель бизнес-процесса

1.2 Анализ функциональных и эксплуатационных требований

1. Функциональные требования пользователя

Программный продукт, разрабатываемый в рамках курсового проекта должен удовлетворять следующему перечню функциональных требований:

— регистрация для доступа пользователей к информации;

— возможность просмотра доступной информации для сотрудников;

— облегчение работы с документацией для врача;

— автоматизация работы специалистов отдела приема и медицинского секретариата.

2. Входные данные

Входными данными при работе с программным продуктом должны быть данные о врачах, пациентах вводимые пользователем вручную. Входной язык приложения — русский.

Основные документы — это регистрационные карты.

3. Выходные данные

Выходными данными при работе программы являются данные, выводимые на экран пользователя, и текстовые документы, составленные по запросам пользователя, в форматах doc. Язык выходных данных в приложении — русский.

4. Требования к интерфейсу

Программный продукт должен содержать форму для выбора категории пользователей (отдел приема пациентов, медицинский секретариат), которая будет открываться после запуска приложения.

Остальные окна программного продукта должны быть оснащены подсказками, а их функции быть интуитивно понятны пользователю. Сообщения, выдаваемые программой при прохождении каких либо действий, должны содержать краткое описание произведенных действий и содержать комментарии для облегчения дальнейшей работы пользователя.

5. Требования к надежности

При работе с программным продуктом необходимо предусмотреть:

— контроль вводимой информации, т. е. возможность отслеживания ошибок, допускаемых пользователем, и последующей реакции программы на них;

— предусмотреть блокировку некорректных действий пользователя при работе с системой.

6. Требования к программной документации

В состав сопровождающей документации программного продукта должны входить следующие компоненты:

пояснительная записка на 20 — 30 листах, содержащая описание разработки;

исходные тексты модулей на языке Delphi

откомпилированный EXE-файл на флеш-карте.

7. Требования к составу и параметрам технических средств

Система должна работать на IBM совместимых персональных компьютерах. Минимальная конфигурация:

тип процессора — Pentium;

объем оперативного запоминающего устройства — 16 Мб;

тип монитора — SVGA (15').

8. Модель вариантов использования

На основании анализа требований пользователя были выделены следующие варианты использования, представленные в таблице 1.1.

Таблица 1.1. Описание вариантов использования

Действующие лица для диаграммы вариантов использования приведены в таблице 1.2.

Таблица 1.2. Действующие лица

На основании всех выше рассмотренных вариантов использования была составлена диаграмма вариантов использования, представленная на рисунке. 1.2.

Рисунок 1.2. — Диаграмма вариантов использования

Описание варианта использования "Создание регистрационной карты пациента"

Действующие лица. Специалист отдела приема пациентов.

Заинтересованные лица и их требования:

— пациент, данные о котором должны быть занесены в базу данных;

— специалист отдела приема пациентов, который должен создать регистрационную карточку пациента.

Предусловия.

Вход пользователя в систему.

Постусловия.

Если вариант использования выполнен успешно, создаётся новая регистрационная карточка, которой будет присвоен уникальный код. В противном случае состояние системы не изменяется.

Основной сценарий.

1. Система создаёт новый документ под названием «Регистрационная карта пациента»

2. В поле «код» генерируется код документа

3. Система предлагает заполнить регистрационную карточку

4. Пользователь заполняет регистрационную карточку

5. Пользователь сохраняет данные

6. Вариант использования завершается

Альтернативные потоки:

5b. Если пользователь вводит неверные данные, система выводит сообщение «Проверьте правильность данных»

7а. Если пользователь не сохраняет данные, состояние системы не меняется, вариант использования завершается

9. Глоссарий проекта

Основными понятиями проекта являются следующие:

— специалисты;

— врачи;

— пациенты;

— регистрационные карты;

— прием;

— курс лечения;

2. Проектирование информационной системы

2.1 Разработка архитектуры системы

Разрабатываемое приложение является клиент-серверным приложением.

В фирме должны быть расположены персональные компьютеры для работы сотрудников (специалисты, секретариат) с приложением. Все компьютеры в системе соединены локальной сетью, с сервером базы данных, где будет храниться база данных со всей информацией.

На рисунке 2.1 приведена предварительная диаграмма развертывания разрабатываемого приложения — архитектура технических средств системы.

Рис. 2.1. Архитектура технических средств системы

2.2 Разработка модели предметной области

В результате анализа (раздел 1) были выделены категории концептуальных классов, представленные в таблице 2.1.

Таблица 2.1. Список категорий концептуальных классов

Пользуясь списком категорий и методом анализа словесного описания вариантов использования, составлен список кандидатур на роль концептуальных классов для предметной области. Он соответствует требованиям и принятым упрощениям для всей предметной области.

Список концептуальных классов:

— пациент;

— регистрационная карта;

— прием;

— врач;

— курс лечения.

На основании анализа словесного описания варианта использования, составлен список ассоциаций для предметной области, представленный в таблице.

На основании анализа технического задания и описания вариантов использования выделены атрибуты классов для модели предметной области, представленные в таблице 2.2.

Таблица 2.2. — Атрибуты классов для модели предметной области

2.3 Разработка алгоритма функционирования системы

Для того чтобы предотвратить несанкционированный доступ, вход в систему осуществляется с проверкой имени и пароля.

Алгоритм работы системы в виде диаграммы деятельностей приведен на рисунке 2.2.

Алгоритм работы специалиста отдела приема пациентов в виде диаграммы деятельностей представлен на рисунке 2.3.

На рисунке 2.4 представлена деятельность специалиста отдела медицинского секретариата.

Рисунок 2.2. — Алгоритм работы системы Рисунок 2.3. — Диаграмма деятельностей «Работа специалиста отдела приема»

Рисунок 2.4. — Диаграмма деятельностей «Работа медицинского секретариата»

2.4 Проектирование интерфейса пользователя

После запуска приложения на экране появляется главная форма с меню выбора категории пользователя.

2.5 Реляционная модель данных

Реляционная модель данных разработана на основе концептуальной модели предметной области. Реляционная модель данных в дальнейшем служит для разработки БД.

Таблица 2.3. — Атрибуты класса Пациент (регистрационная карточка)

Построение диаграмм последовательностей для варианта использования «Создание регистрационной карты»

На основе сценария разработана следующая диаграмма последовательности:

Рисунок 2.5. — Диаграмма последовательностей «Создание регистрационной карточки».

2.6 Построение диаграммы классов

Диаграмма классов для варианта использования «Создание личной карточки» представлена на рисунке 2.6.

Рисунок 2.6 — Диаграмма классов «Создание регистрационной карточки»

Таблица 2.4. — Операции классов

3. Реализация системы

3.1 Реализация программного обеспечения системы

медицинский секретариат информационный интерфейс

1. Разработка диаграммы компонентов

Реализация программного обеспечения системы представлена на рисунке 3.1 в виде диаграммы компонентов. Она определяет архитектуру разрабатываемой системы на физическом уровне и представляет зависимости между программными компонентами.

2. Объекты интерфейса пользователя

Система включает в себя несколько форм, каждая из которых реализована в своём компоненте на диаграмме компонентов (рис. 3.1):

Рис. 3.1. - Диаграмма компонентов приложения

Form1 — главная форма, предлагает выбор категории пользователя; Form2 — выбор объекта, над которым нужно производить операции ;

Form3 — форма создания, редактирования, удаления регистрационной карты ;

Form4 — форма приема пациента;

Form5- форма ввода, изменения, удаления данных о врачах;

Form6- форма курса лечения.

После запуска приложения на экране появляется форма авторизации. После ввода логина, пароля определяется правильность ввода, если такой пользователь существует, то выводится главная форма.

3. Классы и объекты интерфейса пользователя

Программный продукт состоит из нескольких форм: Form1, Form2, Form3, Form4, Form5, Form6, Form7, Form8.

Форма Form1

Внешний вид формы (Form1) представлен на рисунке 3.2.

Рисунок 3.2. — Главная форма В таблице 3.1 представлены расположенные на форме Form1 компоненты

Таблица 3.1. Компоненты формы Form1

Форма Form2

Внешний вид формы меню (Form2) представлен на рисунке 3.3.

Рисунок 3.3. — Форма меню отдела приема пациентов В таблице 3.2 представлены расположенные на форме Form2 компоненты

Таблица 3.2. Компоненты формы Form1

Форма Form3

Внешний вид формы «Выберите действие» (Form3) представлен на рисунке 3.4.

Рисунок 3.4. — Форма данных о пациентах

Форма Form4

Внешний вид формы «отчет — регистрационная карта» (Form4) представлен на рисунке 3.5.

Рисунок 3.5. — Форма «Отчет — регистрационная карта»

Форма Form7

Внешний вид формы «Данные о врачах» (Form7) представлен на рисунке 3.6.

Рисунок 3.6. — Форма «Данные о врачах»

Форма Form8

Внешний вид формы «Курс лечения» представлен на рисунке 3.7.

Рисунок 3.7. — Форма «Курс лечения»

Форма Form9

Внешний вид формы «Отчет — история болезни пациента» представлен на рисунке 3.8.

Рисунок 3.8. — Форма «Отчет — история болезни пациента»

Заключение

Разработанный программный продукт позволяет автоматизировать работу отдела приема пациентов и отдела медицинского секретариата. Разработанная система облегчает работу с документацией для сотрудников больницы.

В процессе создания системы в соответствии с заданием были разработаны: модель вариантов использования, концептуальная модель предметной области, диаграммы деятельности, реляционная модель данных, диаграмма состояний интерфейса, формы интерфейса, диаграмма компонентов и диаграмма развертывания. Была выполнена частично проверка и отладка системы.

Система позволяет:

— специалисту отдела приема пациентов создавать, редактировать, просматривать необходимые для работы документы: регистрационные карточки, информацию о пациентах, сведения о приеме пациентов;

— врачу за работой специалиста и секретариата.

В данной курсовой работе было проведено программирование на языке Delphi. Программный продукт содержит форму авторизации пользователей, которая открывается после запуска приложения. Данная форма содержит поля для ввода пользователем своего логина и пароля.

Таким образом, в курсовой работе удалось реализовать информационную систему отдела больницы, которая удовлетворяет заданным требованиям.

1. Архангельский А. Я. Программирование в Delphi. Учебник по классическим версиям Delphi. — М.: Бином, 2006.

2. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. — М.: ДМК Пресс, 2001.

3. Леоненков А. В. Самоучитель UML. — СПб.: БХВ-Петербург, 2001.

4. Мандел Т. Разработка пользовательского интерфейса. — М: ДМК Пресс, 2001.

Приложение

Текст программы

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, jpeg, ExtCtrls;

type

TForm1 = class (TForm)

Image1: TImage;

Button1: TButton;

Button2: TButton;

Button3: TButton;

procedure Button1Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

procedure Button3Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses Unit2, Unit6;

{$R *.dfm}

procedure TForm1. Button1Click (Sender: TObject);

begin

Form2.ShowModal;

end;

procedure TForm1. Button2Click (Sender: TObject);

begin

Form6.ShowModal;

end;

procedure TForm1. Button3Click (Sender: TObject);

begin

Form1.Close;

end;

end.

unit DM1;

interface

uses

SysUtils, Classes, IBDatabase, DB;

type

TDataModule3 = class (TDataModule)

IBDatabase1: TIBDatabase;

IBTransaction1: TIBTransaction;

procedure DataModuleCreate (Sender: TObject);

procedure DataModuleDestroy (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

DataModule3: TDataModule3;

implementation

{$R *.dfm}

procedure TDataModule3. DataModuleCreate (Sender: TObject);

begin

IBDatabase1.Connected:=True;

end;

procedure TDataModule3. DataModuleDestroy (Sender: TObject);

begin

IBDatabase1.Connected:=False;

end;

end.

unit Unit3;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ExtCtrls, DBCtrls, Grids, DBGrids, StdCtrls;

type

TForm3 = class (TForm)

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

Edit1: TEdit;

Label1: TLabel;

Button1: TButton;

Button2: TButton;

procedure DBGrid1TitleClick (Column: TColumn);

procedure Button1Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form3: TForm3;

implementation

uses DMPats, DM1, Unit4;

{$R *.dfm}

procedure TForm3. DBGrid1TitleClick (Column: TColumn);

var cn: string;

begin

cn:=Column.FieldName;

DataModule4.IBQuery1.Transaction.Commit;

DataModule4.IBQuery1.SQL.Clear;

DataModule4.IBQuery1.SQL.Add ('SELECT * FROM PATSIENT ORDER BY '+cn);

DataModule4.IBQuery1.Active:=True;

end;

procedure TForm3. Button1Click (Sender: TObject);

begin

if Edit1. Text<>'' then

with DataModule4. IBQuery1 do

begin

Close;

SQL.Clear;

SQL.Add ('SELECT * FROM PATSIENT where FAMILIA like :" FAMILIA%" ');

Params[0]. AsString:=Edit1.Text+'%';

Open;

end;

end;

procedure TForm3. Button2Click (Sender: TObject);

begin

Form4.QuickRep1.Preview;

end;

end.

unit DMPats;

interface

uses

SysUtils, Classes, DB, IBCustomDataSet, IBUpdateSQL, IBQuery;

type

TDataModule4 = class (TDataModule)

IBQuery1: TIBQuery;

IBUpdateSQL1: TIBUpdateSQL;

DataSource1: TDataSource;

IBQuery1ID: TIntegerField;

IBQuery1FAMILIA: TIBStringField;

IBQuery1IMYA: TIBStringField;

IBQuery1OTCHESTVO: TIBStringField;

IBQuery1ADRES: TIBStringField;

IBQuery1DATA_ROZHDENIA: TDateField;

IBQuery1MESTO_RABOTI: TIBStringField;

IBQuery1TELEPHONE: TIntegerField;

IBQuery1GRUPPA_KROVI: TIBStringField;

IBQuery1SRTAX_KOMPANIA: TIBStringField;

IBQuery1NOMER_STRAXOVKI: TIntegerField;

procedure DataModuleCreate (Sender: TObject);

procedure IBQuery1AfterPost (DataSet: TDataSet);

procedure IBQuery1AfterDelete (DataSet: TDataSet);

private

{ Private declarations }

public

{ Public declarations }

end;

var

DataModule4: TDataModule4;

implementation

uses DM1;

{$R *.dfm}

procedure TDataModule4. DataModuleCreate (Sender: TObject);

begin

IBQuery1.Active:=True;

end;

procedure TDataModule4. IBQuery1AfterPost (DataSet: TDataSet);

begin

IBQuery1.Transaction.CommitRetaining;

end;

procedure TDataModule4. IBQuery1AfterDelete (DataSet: TDataSet);

begin

IBQuery1.Transaction.CommitRetaining;

end;

end.

unit Unit6;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, jpeg, ExtCtrls;

type

TForm6 = class (TForm)

Image1: TImage;

Button1: TButton;

Button2: TButton;

Button3: TButton;

procedure Button1Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

procedure Button3Click (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form6: TForm6;

implementation

uses Unit7, Unit8;

{$R *.dfm}

procedure TForm6. Button1Click (Sender: TObject);

begin

Form7.ShowModal;

end;

procedure TForm6. Button2Click (Sender: TObject);

begin

Form8.ShowModal;

end;

procedure TForm6. Button3Click (Sender: TObject);

begin

Form6.Close;

end;

end.