JAD vs RAD and how they can be used to evaluate hospital information system requirements

Hypothetical question:  You are a consultant to large hospital for a new, complex system and have been asked to begin an information systems requirements planning activity.  You are considering to introduce JAD and RAD as fact-finding techniques. How are JAD and RAD different from traditional approaches and why would you recommend one technique versus another in this scenario.  How do you ensure your recommendation is implemented successfully?

 

Joint Application Development (JAD) is a user oriented approach to gathering system requirements. Requirements for a complex information system are determined through group interaction. JAD teams are a collection of developers, managers, end users and other staff members who form a structured and focused team led by a formal project leader.  As stated by Alexandrou, “The objective is to analyze the existing system, obtain user input and expectations, and document the requirements for the new system”¹.

Rapid Application Development (RAD) is also a team based technique. While the goal of a JAD group is to establish the system requirements, the goal of a RAD group is to complete the entire information system project.  RAD condenses the Systems Development Life Cycle (SDLC), bringing users in on each step and continues through the development process.  RAD is composed of four phases: planning, user design, construction, and a final cutover step.  The User Design and Construction step will have numerous sub-phases cycling between prototype and user evaluation².

JAD and RAD are different from traditional approaches in that they focus on user input when establishing requirements through collaboration between different groups and (in the case of RAD) during the development process.  Instead of the IT staff collecting information on requirements and building the system, the developers and IT groups tasked with creating systems bring the users in on each stage (Shelly, 2012). Traditional methods have tasked the development groups with gathering requirements by interviewing users. JAD and RAD also differ from approaches such as the Waterfall method in that the objective is to shorten development time while increasing the end user satisfaction¹.

In comparing the two as fact finding techniques for a hospital system, an advantage to the JAD method of requirements gathering is it can produce accurate results and a greater understanding of the organization’s goals. A disadvantage to JAD is that the cost is greater than other methods such as RAD and AGILE, and can become difficult to manage if the group is too large. Also, a new development plan will need to be established to create the actual system.  An advantage to the RAD method is that it will result in faster system development as the focus is on the creation of the system, and end users would have a system they helped create.  However,  as noted by Shelly, one inherent risk of RAD is the risk that the system created will work out great in the immediate future for the users, but might not be a scalable product that will meet future business needs. Also, a rapid development cycle may lead to rushed development and inconsistent quality².

A hospital system will be very complex, and include patient medical records, billing and insurance activity, and interface with lab and pharmacy systems. This will require the cooperation of several groups with different mind sets, and I would recommend the tighter structured approach of JAD to gather and establish the system requirements.

On the assumption that I am making recommendations for the project only, I would ensure the requirements gathering is implemented successfully by requesting team rosters, and expected completion of requirements documentation.  On the assumption that I were to continue to be an integral part of the project, I would ensure the requirements gathering using JAD is completed successfully by taking on a facilitator role or stepping up as project leader, to ensure the collaborative interdepartmental sessions remain productive throughout the project.

References:

1 Alexandrou , M (2013) Joint Application Development (JAD) Methodology. Infolific: Technology. www.infolific.com. Retrieved from: http://infolific.com/technology/methodologies/joint-application-development/

2 Shelly, G. B., & Rosenblatt, H. J. (2012). Systems analysis and design, ninth edition (9th ed.) Boston: Course Technology Cengage Learning.

Healthcare.gov site: Initial Feedback on User Experience

The health insurance marketplace was set up in conjunction with the Affordable Care Act as a means for US Citizens to shop for and procure health care plans. The site is http://www.healthcare.gov and is now fully functional.
The application process is similar to that of applying for a credit card or car loan. Users log in, and set up a personal account. The sign in process guides the user to enter graduating levels of personal information of each party to be included on the plan, and language of the site is basic includes short examples. Once identity is verified using abbreviated info from credit reports, the user can then begin to complete the detailed application.  Once the application portion is completed, a PDF file is sent to a secure inbox and covers what plans the user and family members are eligible for and includes next steps to complete the process. If users are approved for coverage the next steps are to decide on medical and dental plans.

The healthcare marketplace offers an array of plan types covering a range of high premium/lower cost to higher premium and lower costs and also offers plans with out of network flexibility.  There stipulations for income verification in order to qualify for lower rates or tax credits, and also includes provisions for individuals who did not realize the impact of the mandates that require health insurance.

The general plan types are as follows³:

·         The Exclusive Provider Organization (EPO) : services are covered only when health care organizations are in the plan network

·         Health Maintenance Organization (HMO): Coverage limited to health care providers who either work for the HMO or are contracted to provide care for the HMO

·         Point of Service (POS):  Costs is less when health care providers are in the POS plan network. These do offer coverage out of network but require referrals for visits to a specialist.

·         Preferred Provider Organization (PPO): Cost is less where providers are in network but no referral is required for specialists

Plans are divided into 5 large categories as follows²:

·         Bronze: The lowest premium plans which covers approximately 60% of healthcare costs.

·         Silver: Health plans in this category pay 70% of healthcare costs on average.

·         Gold: Higher level, where health plans pay 80% of healthcare costs on average.

·         Platinum: Highest level, where 90% of costs are covered on average.

·         Also included is a catastrophic category, where less than 60% is covered (similar to older ‘major medical’ plans) and are offered only for those with special exemptions or are under 30 years old.

After running through the process on the Healthcare.gov site a few times to compare, there were a few issues to note. One specific drawback is how the user presents their income. The income itself is based on user estimates, with income verification linked to tax returns down the road¹.  The declaration is a bit muddy, and for the unemployed or the self employed, the options are not as clear and only after a few tries or a call to support do the best options become apparent.  At this point, the site is still clunky compared to sites such as Amazon or USPS, but not so much to be unusable.  Changing personal information such as income, for instance, requires the user to start at the beginning and step through all of the screens across all applicants and this process takes approximately 15 minutes. Another drawback is the dental plan options are not visible until the health plan options are selected.

The support by phone was very easy to access, and the support representatives can also step through the entire application with the users. On the site itself, there seems to be much effort to leave questions open and optional. This might make it easier for anyone with good intentions but limited knowledge of health care, but also leaves a lot of avenues and choices. The support phone representatives are available to clarify and guide, but better online documentation and descriptions could be used as many important details can be missed. Also, the best way to navigate, compare plans, or change information is not made obvious until the user calls support or makes several attempts to try things different ways.

The overall experience of getting healthcare coverage through this site was somewhat time consuming, and could be improved with better tool tips, guides for income and other personal information entry, and also more readily available plan information.

References:

1 Healthcare.gov, 2015. Health coverage options if you’re unemployed. Retrieved 4/9/15 from https://www.healthcare.gov/unemployed/coverage/#unemployedincome

2 Healthcare.gov, 2015. Marketplace insurance categories. Retrieved 4/9/15 from https://www.healthcare.gov/choose-a-plan/plans-categories/

3 Healthcare.gov, (2015). Type of plan and provider network. Retrieved 4/8/15 from https://www.healthcare.gov/choose-a-plan/plan-types/

 

 

Interoperability and EHR, New trends: The CCD

A recent development to further interoperability is the Continuity of Care Document (CCD). The continuity of care document is the tool that allows for interoperability between clinicians and EHR systems. The CCD was created and defined to allow for a common platform primarily for health care providers to exchange patient information accurately and improve patient care¹. 

The clinical care document is the file set of patient summary information, designed to be exported from a provider’s EHR system and delivered to the patient or another health care provider. The CCD is normally created by an EHR or other system used by a health care provider, and is a single standalone representation of the patient health history and medical record that can be viewed on a common platform. The development of the CCD also establishes a baseline for recommendations from the health care profession, a standard for data, and guidelines for clinical practices².

The Continuity of Care document follows the guidelines of the Clinical Document Architecture (CDA) standard, which uses Extensible Markup Language (XML). The XML format is a self contained data structure that defines the content, and this is paired with a standard HTML code to establish the display to render the document readable from a web browser.  The XML structure defines the standard groupings by clinical content, and makes use of common classes and associations. The CDA format offers a flexible approach where the data segments can be moved or re-used allowing for many combinations but still using the same data structure. The XML data starts with a header, defining the elements and then contains a body section, which is further divided into Sections, each with provisions for narratives and specific procedure entries. The Body section starts off with the clinical report and at least one section. Each section must contain one narrative block for human readability and is populated by the end user. There may also be zero or more specific entries, such as allergies, prescription drugs, problems, vital signs. These are coded for machine readability by a decision support system or another EHR system².

References:

1 HealthIT.gov (2013). Implementing Consolidated-Clinical Document Architecture (C-CDA) for Meaningful Use Stage 2 .Clinical Document Architecture Overview.  Retrieved 4/6/15 from http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertification.pdf

2 Health Level 7 (2015). HL7/ASTM Implementation Guide for CDA R2 Continuity of Care document, Release 1. Health Level Seven International. Retrieve 2/3/15 from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=6

Interoperability and the EHR: The Problem Oriented Medical Record and the EHR

The Problem Oriented Medical Record covers the two basic divisions of patient information: the demographics (including social and medical history) and the actual progress note that tracks the visit activity.

The progress note itself is divided into four sections:  The Subjective, Objective, Assessment, and Plan (known by the acronym SOAP).  The Subjective section covers the history and depicts the symptoms as reported by the patient.  The Objective section includes the observations by the healthcare provider, along with specific investigative notes and test results. The Assessment section includes the assessment or physician’s prognosis. The Plan section includes actions performed, future treatments, and also any medications prescribed by the healthcare provider². 

The development of the Problem Oriented Medical Record forms the basis of the Electronic Health Record, or EHR. The Healthcare Information and Management Systems Society (HIMSS) defines The Electronic Health Record as an electronic record stemming from any health care encounter, with information including patient information, clinical notes, historical and current medical issues and medications, and visit specific metrics such as vital signs and lab data¹.The EHR is designed as a tool to automate clinical workflow, decision making, and record patient encounter information. The EHR will also support other clinical related activity, such as data transmission, ordering systems, data interfaces for labs, x-rays, etc…, and clinical decision support systems¹.

These developments of the EHR led to modular systems which could be used in different settings, with the value to improve patient safety being recognized. The American Recovery and Reinvestment Act of 2009 brought attention to the then current inefficiencies of medical records and increased focuse on the development, standardization, and use the EHR¹. The problem oriented format is a model that current EHR applications follow for patient encounter tracking. 

References:

1 Atherton, J (2011).  Development of the Electronic Health Record. American Medical Association Journal of Ethics. March 2011, Volume 13, Number 3: 186-189.  Retrieved from: http://journalofethics.ama-assn.org/2011/03/mhst1-1103.html or http://journalofethics.ama-assn.org/2011/03/pdf/mhst1-1103.pdf

2 Benson, T. (2012). Principles of Health Interoperability HL7 and SNOMED. Springer London. ISBN: 978-1-4471-2800-7 (Print) 978-1-4471-2801-4 (Online)

Interoperability and the EHR: Do you wanna make a SNOWMED?

The core of interoperability in the context of electronic health records is to ensure the sender and recipient of any health related information can read the data in the same manner, and also send and receive the information clearly across various infrastructures². The quest for interoperability initiated the efforts to standardize medical information, which led to the formalization of an Electronic Health Record (EHR).

Traditional health care models had been based around individual visits, and largely contained in isolated paper charts or unique electronic record systems under the health care provider’s authority. These records were normally not seen by the patient and could vary in structure from provider to provider, with safety being the responsibility of the individual at the time of treatment. In a newer patient centered model of healthcare, the continuous relationship with the patient and all treatments from all providers is emphasized, with visibility of the records and control granted to the patients and sharing of treatment information available to other health care providers². The early efforts of recording health information were not scalable for a growing population. The interoperability of the electronic health record relies on standardized ways to store and transfer the information, and this escalated the development of the problem oriented medical record format and the standardization of medical terms.

In the past, the documentation of health information varied between health care organizations, and paper and electronic systems. The terminology itself was known and standard, but the means of coding, searching, and comparing was not based on a formal structure the way chemicals and other scientific data had been. A system was needed so that information could be recorded in a way that is universally understood, not only by health care and related individuals but by a variety of computer systems that would act upon health data. The Systematized Nomenclature of Medicine-Clinical Terms, or SNOWMED CT came about to address the need to have predictable values arranged in a hierarchy in order to classify and document medical treatment. SNOWMED CT follows the principles that the data from the past needs to be usable in the future, and the data quality directly correlates to patient care options that are available to EHR users².

SNOWMED incorporates identifiers that make up a value set, and within these contain the relationships and descriptions.  The general outline is a top level of case classifications, a middle level to track and evaluate the clinical activity, and a base level used in the care setting.  This allows for indexing and searching not only for the point of care and exact clinical documentation, but for public health research and disease surveillance².

The SNOMED CT is the evolved comprehensive standard for healthcare terminology and has been adopted into the EHR. The ICD family of diagnosis descriptions and sub classifications is an example of how SNOWMED is applied to medical records. A new application is the anticipated adoption of the ICD-10 diagnosis coding and classification system, which has a hierarchy of conditions and specific rules to drill down to define specific conditions.

References:

1 Atherton, J (2011).  Development of the Electronic Health Record. American Medical Association Journal of Ethics. March 2011, Volume 13, Number 3: 186-189.  Retrieved from: http://journalofethics.ama-assn.org/2011/03/mhst1-1103.html or http://journalofethics.ama-assn.org/2011/03/pdf/mhst1-1103.pdf

2 Benson, T. (2012). Principles of Health Interoperability HL7 and SNOMED. Springer London. ISBN: 978-1-4471-2800-7 (Print) 978-1-4471-2801-4 (Online)

3 HealthIT.gov (2013). Implementing Consolidated-Clinical Document Architecture (C-CDA) for Meaningful Use Stage 2 .Clinical Document Architecture Overview.  Retrieved 4/6/15 from http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertification.pdf

4 Health Level 7 (2015). HL7/ASTM Implementation Guide for CDA R2 Continuity of Care document, Release 1. Health Level Seven International. Retrieve 2/3/15 from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=6

Regarding the HL7 standard for data transfer...

The goal of health care system interoperability (and to further encourage EHR adoption among health care providers) meant making systems that could transfer key bits of information between disparate systems or other health care entities, and to do so meant using a common data format that would be readable on any computer system.  To meet this challenge, the widely recognized standard developing organization called Health Level 7 (or HL7 for short) launched in 1987. The standards developed by HL7 ensure EHR components can readily communicate and the electronic health record works as a complete system¹.  The HL7 technical standard is used for the format of the electronic messages that communicate health care events, and also used for the transmission of data such as lab tests and results from one entity to another. The full designation is “ANSI/HL7 V2.7-2011 Health Level Seven Standard Version 2.7 Application Protocol for Electronic Data Exchange in Healthcare Environments”². There have been a number of revisions that maintained backwards compatibility, and HL7 v2.7 is the current version in use in clinical applications and healthcare environments³.

An HL7 file is basically a text file or text message string divided up with specific markers or delimiters to separate the text into message segments and data fields. The message is divided into segments, and each segment contains specific fields in a standard sequence. The fields may be of different data types, and may be a single value or repeated with multiple components and start and end indicators².

Within each message segment there are a handful of text characters that are used to delineate specific parts of the message, and function "like traffic signs and signals"². The Field Separator is a pipe character (|) and is declared on the fourth character of each data segment after the segment’s identifying information. The Component Separator is the “ ^ “ character, and  this divides the field data within the field separators (Such as name divided into last and first name). The tilde ( ~ ) character represents the Repetition Separator which divides up multiple occurrences of similar information, and the slash ( \ ) is the escape character which can be used for special processing or to indicate special commands or filters. The ampersand ( & ) is used to separate subcomponents².

The messages are divided into segments, the most common being  the message header or MSH, the event type or EVN, the patient identification details or PID, patent visit request (PV1), the specimen details (OBR), the result details or OBX ².

The MSH segment defines the delimiter or field separator, the sender’s ID, the message date and time, the message type, the message control id, the processing status, and the syntax version.

MSH|Delimiters||Sender|||DateTime||MessageType|MessageID|ProcessingStatus|SyntaxVer

The EVN segment is an optional line that indicates date/time information for the event being depicted by the HL7 message.

 

EVN|Type|Date|Time|Event|Reason|Operator

The PID section contains the patient identifiers, starting with the message identifiers and any optional components, followed by the patient name (last name first, separated by a component separator) , Date of Birth, then gender, followed by optional provider information, then followed by address and postal information.

PID|||patientID^^^source^IDtype||familyName^givenName||dateOfBirth|sex|||streetAddress^addressLine2^^^postcode
 

The PV1 segment normally contains the patient’s location and care provider information

PV1|||patientLocation|||||patientsGP

The OBR segment contains lab specific information starting with the accession number used by the lab, then specific test codes and then specimen dates, site information, and optional modifier information.

OBR|||accessionNumber|testCode^testName^codeType|||specimenDate||||||||specimenSource^^^bodySite^siteModifier|requester

An OBX segment is used to represent result details, observations, code types, and abnormal indicators.

 

OBX||valueType|observableCode^observableName|observationSubID|valueCode^valueText^valueCodeType|||abnormalFlag

A complete message or message file sent from an EHR system to a Lab vendor may look like:

MSH|^~\&||^123457^Labs|||201208141530||ORU^R01|123456789|P|2.4
EVN|A28|20080501140006|||000338475^Author^Arthur^^^^^
PID|||123456^^^SMH^PI||SMITH^JOHN||19620114|M|||38 Green St^Orlando^FL^^MM1 9DL
PV1|||5N|||||G123456^DR Samwell
OBR|||54321|555789^LABTESTCODE^LN|||20120802||||||||SW^^^HAND^RT|C987654
OBX||CE|0^ORG|01|STAU||||||F
OBX||CE|600152^AMP|01||||R|||F

For support and reference, the data field names themselves are referred to by where they sit sequentially in the segment, along with the segment abbreviation itself. For example, MSH-7 indicates the seventh field of a segment called MSH. This field will be preceded by seven delimiters with or without information for other fields in between². HL7 messages can cover a variety of healthcare information transfers are sent when specified events in a clinical application designated as ‘triggers’ are enacted.  For instance, a lab order system changes status to Sample Received, and an HL7 message containing the patient info, order, results and everything a lab office needs is sent electronically to the lab system².

The HL7 format is of significance because it can be used in a variety of data transfer types or files types and is universally understood by healthcare applications.

 

References:

1 Atherton (2011). Retrieved from: http://journalofethics.ama-assn.org/2011/03/mhst1-1103.html or http://journalofethics.ama-assn.org/2011/03/pdf/mhst1-1103.pdf

2 Benson, T. (2012). Principles of Health Interoperability HL7 and SNOMED. Springer London. ISBN: 978-1-4471-2800-7 (Print) 978-1-4471-2801-4 (Online)

3 Health Level 7 (2015). HL7/ASTM Implementation Guide for CDA R2 Continuity of Care document, Release 1. Health Level Seven International. Retrieve 2/3/15 from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=6

 

 

Human Computer Interaction (HCI) principles and how these can be applied to EHR design

Human Computer Interaction (HCI) is the description of the relationship between the information system and the users. Starting with the earliest forms using plain text, HCI has evolved to the traditional Graphical User Interface (GUI), and now the goal is a more transparent interface³.

There are several basic principles which should be incorporated in designing a user interface: an understanding of the business, effective graphic elements, an approach from the user perspective and a focus on usability, use of models and prototypes during the process along with iterative feedback and comprehensive documentation.  In designing the interface, among the basic rules are to create a transparent interface using familiar terms and images. Also, the interface should provide an easy way for the user to get help.  An effective user interface design should enhance productivity and provide feedback all in an attractive package ³. As Acharaya stated, “...to achieve dependable, usable, and well-engineered interactive devices in healthcare requires applied Human Computer Interaction (HCI) research and awareness of HCI issues throughout the lifecycle, from design through to procurement, training and use”¹.

In a health care environment, the HCI takes on a more important role to ensure no adverse incidents are attributed to software or devices due to inadequate user interface design. HCI in healthcare is not different from HCI in other industries, but if not given a high enough priority, quality and other issues traced to poor HCI may persist¹. Loss of productivity during training is a big concern, and better interface design will cut down on training.  “Usability has a strong, often direct relationship with clinical productivity, error rate, user fatigue and user satisfaction–critical factors for EMR adoption” (HIMSS, 2009). Also, providers may not be able to compare EHR systems as effectively if they are not made with common HCI interactive standards².

To achieve more effective EHR utilization, the UI should be predictable and allow the providers to focus on the patient cares. In a medical environment, there may be a need to follow tradition to ensure patient safety and proper system usage.  As also noted by HIMSS², good UI design should incorporate a familiar, natural flow, and be consistent and predictable. Natural Colors can be used to consistently convey meaning.  Red should be used for warnings, stop, exit, alerts, and emergencies such as a drug interaction alert.  Yellow should be used for caution, mild warnings, or issues that require attention such as a lab result with mixed results. Green should be used to convey ‘go’, or to ‘proceed safely’, or all OK such as lab results that are normal. Blue should be used to convey cold, or advisory conditions. To accommodate users that are color blind, these should be accompanied with a secondary identifier that is also used consistently².

Another way for a UI to be more effective in health care is to match the pace of physicians. Health care providers may be very mobile, and focusing on and talking to patients. They may not be able to give full attention to the software and thus need a system designed around their workflow.  To achieve better EHR adoption, the UI should minimize the number of steps it takes to perform any function, and also be free of clutter and minimize any ‘computer’ or ‘technical terminology².

To go a bit further, designers may need to think out of the box to anticipate user perceptions and future actions and steps users may take. For instance, users in a traditional client-server app will expect to left click a mouse on a note to open and begin documenting, but will they also use the EHR on a tablet and expect a touch screen command, and will that conflict with another action? Training and support can do only so much –if health care providers are learning charting a certain way, the EHR design should keep an eye on that format and adapt current applications.

References:

1  Acharya, C, Thimbleby, H, Oladimeji, P. (2010). Human Computer Interaction and medical devices. Electronic workshops in computing (eWIC). The Chartered Institute for IT. Retrieved September 29, 2013 from http://ewic.bcs.org/upload/pdf/ewic_hci10_paper19.pdf
2  HIMSS (2009). Defining and Testing EMR Usability: Principles and Proposed Methods of EMR Usability Evaluation and Rating. HIMSS EHR Usability Task Force.  Retrieved September 29, 2013 from: http://www.himss.org/files/HIMSSorg/content/files/himss_definingandtestingemrusability.pdf
3  Shelly, G. & Rosenblatt, H. (2012). Systems analysis and design, ninth edition (9th ed.) Boston: Course Technology Cengage Learning.