• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Understanding basics of software development and healthcare
 

Understanding basics of software development and healthcare

on

  • 518 views

A basic presentation I used to walk through some students about SDLC and Helathcare.

A basic presentation I used to walk through some students about SDLC and Helathcare.

Statistics

Views

Total Views
518
Views on SlideShare
518
Embed Views
0

Actions

Likes
0
Downloads
14
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Intro

Understanding basics of software development and healthcare Understanding basics of software development and healthcare Presentation Transcript

  • Software, Design Principles & Healthcare Bharadwaj PV
  • Agenda
    • Introduction to Healthcare-IT
    • Design Principles
      • What is software?
      • Designing software
      • Service orientation
    • Health record management
      • Understanding EHR’s
      • Centralization of EHR’s
    • Activity
  • Healthcare IT C A R E G I V E R S P A T I E N T S TREATMENT - CARE HEALTH PROBLEM MONEY INFORMATION
  • Nature of information generated in healthcare
    • Patient centric
    • Sensitive and confidential
    Demographic Age, Gender, address, date of birth etc. Clinical Allergies, Health issues, operations (procedures) etc.
  • Understanding software
  • Understanding the 3 layers of software User Interface (UI) Business Logic Data Base $#$%#%#$%#$$%#$%#$$%#$$%#$%#$%#^Y#^%&^&%^&%*^(()&*()*(&)&*_&*)(&*
  • What is SDLC? (Software development life cycle) Gather requirements Analyze and design software Test software developed Develop software
  • Why design software?
    • Most software developers understand programming and not requirements of end users.
    • To ensure that requirements are translated into proper screens.
    • Designing is a phase on its own and requires specialized skills – functional knowledge and technical know how.
  • Design principles
    • Object oriented approach
    • Object-oriented techniques view a system as a collection of self-contained objects which include both data and processes.
    • An object is a person, place, event, or thing about which we want to capture information.
    • Each object has properties (or attributes).
    • Example of an object
    Design principles PATIENT Name Age Date of birth Gender Height Weight Blood group Object Attributes
    • Use cases
    Design principles
  • Detailed Use case modelling Use case Register patients Parent use case - Description The system must provide the facility to register a patient who has arrived. Actors Registration clerk / Nurses / Receptionists Pre-Condition A set of unique identifiers must be available Sufficient information about the patient must be available Post-Condition Patient will be registered A unique patient identifier will be associated with the patients record Use Case (Basic Flow) Patient Arrives Provides details required Registration is complete Unique ID is generated Exception(s) Alternative scenario(s) A patients record alone may arrive for consultation from an external hospital The nurse must be able to register such patients as external patients and store their information Business Rules and Validation A check must be done if the patients record exists in the system prior to registering a patient Date of birth cannot be a future date Objects Patient, Carer, relationships.
  • Design principles
    • Steps in use case modeling
    • 1. Identify use cases
    • 2. Draw the system boundary
    • 3. Place use cases on the diagram
    • G roup use cases into packages
    • 4. Identify the actors
    • 5. Add Associations
  • Hospital (system boundary) Register patient Admit patient Perform Surgery Collect Fee & Discharge ACTIVITIES
    • Some objects
    • we can identify here
    • Patient
    • Admission
    • Procedure (Surgery)
    • Fee
    Business process
  • Usability tips …
    • Clinical safety – ensure that clinical information is always displayed in a manner that in no possible way could mislead the reader
    • Prioritise information and highlight – ensure most important information is presented first and least important information is presented last to make effective use of clinician time
    • Consistent look and feel
    • Logically organized patient record
    • Flexibility to cater to different users requirements
  • Activity
    • For the given scenario, identify the system boundaries, actors and use cases.
    • Associate the identified use cases to create a health care business process.
  • Service oriented approach
    • The Microsoft definition is: Service orientation is a means for building distributed systems. At its most abstract, service orientation views everything — from the mainframe application to the printer to the shipping dock clerk to the overnight delivery company — as a service provider.
    • Service providers expose capabilities though interfaces. Service oriented architecture maps these capabilities and interfaces so that they can be orchestrated into processes. The service model is ―fractal: the newly formed process is a service itself, exposing a new, aggregated capability.
  • H E A L T H C A R E Demographic information management Clinical Information Management Managing knowledge and decision support Administrative Information Management Materials Management Cost Management Diagnostics Drugs Problems Allergy Information Other Information Prescribe a drug View past medication Services ACTIVITIES The healthcare domain viewed in a service oriented approach Drug name Drug dosage Frequency Data Elements
  • Why an e-health care records?
    • Facilitate the clinical care of individual patients by;
      • Assisting the clinician to structure his or her thoughts and make appropriate decisions
      • Acting as an aide memoir for the clinician during subsequent consultations
      • Making information available to others with access to the same record system who are involved in the care of the same patient
      • Providing information for inclusion in other documents (e.g. laboratory requests, referrals and medical reports)
      • Storing information received from other parties or organisations (e.g. laboratory results and letters from specialists)
      • Providing information to patients about their health and health care
    Source: Good practice guidelines for general practice electronic patient records (version 3.1) Prepared by The Joint General Practice Information Technology Committee of the General Practitioners Committee and the Royal College of General Practitioners
    • A patient record system that can be used to meet administrative, legal and contractual obligations by;
    • Providing medico-legal evidence (e.g. to defend against claims of negligence)
    • Providing legal evidence in respect of claims by a patient against a third party (e.g. for injuries, occupational diseases and in respect of product liability)
    • Meeting the requirements of specific legislation on subject access to personal data and medical records
    • Recording the preferences of patients in respect of access to and disclosure of information they have provided in confidence
    • Providing evidence of workload within a healthcare practice
    • Monitoring the use of external resource usage (e.g. prescribing, laboratory requests and referrals)
    Source: Good practice guidelines for general practice electronic patient records (version 3.1) Prepared by The Joint General Practice Information Technology Committee of the General Practitioners Committee and the Royal College of General Practitioners
  • Health record management
  • Chennai + Delhi + Job TRANSFER ??? ??? ??? Treatment history for 10 years Worked in Chennai for 10 years The problem …micro level + Job Transfer
  • The problem …macro level + + + System A Developed by ABC corp. System B Developed by XYZ corp. System C Developed by MNO corp.
  • The problem with disparate systems
    • Each system is designed in a different way and eventually fails to interact with other systems
    • Leads to inefficient processes in hospitals
    • Leads to availability of loopholes in the system (Insurance claims etc)
  • The case of NHS in UK + + + System A Developed by ABC corp. System B Developed by XYZ corp. System C Developed by MNO corp. Centralized patient record with a commonly defined structure Hospital 1 Hospital 2 Hospital 3
  • The solution
    • A consistent EHR must be designed and enforced by a common body (Govt)
    • The EHR must be maintained centrally as well as locally
    • The central EHR must be updated on a regular basis with the info in the local records
    • The central EHR must have appropriate security and must adhere to clinical information security standards (these standards must be laid out by a common body <Govt>)
    • Ensuring online availability of records for respective stake holders
  • Who benefits? Patients – information available centrally Clinicians – Assistance to provide treatment Government – Vast amounts of data available for research and planning of facilities Insurance companies – Availability of accurate patient history
  • Activity
    • Design an EPR (electronic patient record) that addresses the following requirements for a GP clinic
      • Assuming appointments are booked – a view to list patient appointments
      • A view of a patients medical record with various information organised in tabs
      • An option to enter patients complains and prescribe a drug