By Eric Andrew Kristof, RN, CAHIMS | Healthcare IT Professional | HIMSS Arkansas Chapter Member
About This Series: The HIMSS Word of The Day is a running blog series drawing from the HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025) — the authoritative reference for healthcare IT professionals and the primary study resource for CAHIMS and CPHIMS certification. Each post paraphrases the term in plain language, grounds it in real-world healthcare IT context, and adds a bedside nursing perspective you won’t find in a textbook.
📖 The Term: JAD (Joint Application Development)
Source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025)
🔍 Plain-Language Definition
The HIMSS Dictionary describes JAD (Joint Application Development) as a development method built on steady interaction between the people who will use a system and the people who design it. Its center is a set of structured, focused workshops held early in the development lifecycle, based on the idea that settling requirements up front improves the final product and avoids errors that are costly to fix later.
A 2007 Project Management Institute (PMI) conference paper by Jonasson describes the method in more detail. It says IBM pioneered joint application design in the late 1970s and early 1980s, and that James Martin later popularized it as a key technique for rapid application development. In place of separate interviews with each department, followed by a team trying to reconcile the differences alone, JAD brings stakeholders together for a number of sessions, normally two or four in the paper’s account. With a facilitator’s guidance, they work out and agree on the requirements. The paper argues that this builds ownership early, and that prototypes reviewed in the sessions help users picture the end product. The paper is a practitioner’s account, not a controlled study.
The same paper names the main roles in a JAD session. The facilitator leads the group toward consensus and should be neutral about the outcome, which is why project managers and developers usually make poor facilitators. The scribe records decisions and the reasons behind them. The analyst makes sure the right questions are asked and the models are accurate. The customer or business representative supplies the requirements. A sponsor opens the session and signals support, subject matter experts join for parts of it, and developers attend mainly as observers at first. Practical tools include ground rules agreed by the group and a “parking lot” for topics that need attention but not at that moment.
Terms vary. The Dictionary says “development,” and many sources, including the studies below, say “design.” Both are abbreviated JAD, and authors describe the details in different ways. The paper also advises choosing one version and training facilitators and participants in it.
| Role | Main job in a JAD session |
|---|---|
| Facilitator | Leads the group to consensus and stays neutral |
| Scribe | Captures decisions, reasons, and models |
| Analyst | Asks the right questions and checks the models |
| Customer / users | Provide the requirements and give the final say |
| Sponsor | Opens the session and shows management support |
| Subject matter experts | Explain a process or technology when needed |
| Developers | Listen and clarify, mostly as observers early on |
⚠️ Exam Alert: JAD is a facilitated workshop method for agreeing on requirements early, with users and designers in the same room. It is not the same as RAD (Rapid Application Development), which is a broader development approach that often uses JAD, or Agile, which gathers requirements through iterations. Do not confuse JAD sessions with use cases, which are descriptions of how users interact with a system. In the Assessment Center project, use cases were written after the sessions.
🌐 Why It Matters: Real-World Healthcare IT Context
The case for JAD is intuitive: get the right people in one room, let them argue it out, and avoid expensive surprises later. The question is whether the health IT literature shows it. A PubMed search run for this post found few papers that use JAD at all, and none that compare it with other methods. The sources below show how teams have used it, along with background on the related field of participatory design. Each was checked against its published text or abstract, and the type of study is noted.
The method itself. Jonasson’s PMI paper (2007) gives the origin, roles, and steps summarized above. It is the main general source in this post and is a practitioner’s conference paper, so its recommendations reflect experience rather than tested evidence.
A nursing information system. Fang and colleagues, in Technology and Health Care (2015), developed an Admission Care Management Information System for in-patient admission. Their team used a spiral development model, data collection, observation of the work environment, use-case modeling, and conferences of Joint Application Design to complete requirements analysis and design. The system covered admission nursing management, inter-shift meeting information, and links to drug management and physical examination records. They evaluated it with a questionnaire on nurses’ acceptance and satisfaction, based on an information success model. The authors report that user satisfaction, perceived self-involvement, age, and information quality were positively related to personal and organizational effectiveness, and conclude the system was practical and effective for communicating and documenting admission information. The abstract does not give the number of nurses surveyed, and the study does not test the contribution of JAD itself.
An epilepsy patient portal. Power and colleagues, in Epilepsia (2020), described the development of PiSCES, a portal to the Irish National Epilepsy Electronic Patient Record. They used ethnographic research, document analysis, and joint application design sessions to elicit requirements, then built a specification of modules that guided development. Features include a care summary, care goals, clinic letters, and tools to prepare for a clinic visit. This is a project description that makes the case for the portal. It reports how requirements were gathered, not outcomes for patients.
A research survey tool. Gershon and colleagues, in Quality of Life Research (2010), described the development of Assessment Center, a free web-based resource for storing, administering, and sharing patient-reported outcome instruments. It grew out of the National Institutes of Health-sponsored PROMIS project, and researchers use it to build study-specific websites that deliver PROMIS computerized adaptive tests and other instruments. JAD sessions with representatives from numerous institutions produced a general wish list of features. Use cases were then written so that user expectations matched programmer specifications, and development used daily scrum sessions, weekly usability acceptability testing, and continuous quality assurance. The authors call it a case study that highlights collecting and incorporating user input throughout development. It shows JAD being combined with agile practices rather than replacing them.
Participatory design in health IT. Kanstrup and colleagues, in Studies in Health Technology and Informatics (2017), reviewed 47 health IT papers from the Participatory Design Conferences held from 1990 to 2016. They found a large volume of work on digitalizing health information, records, and work procedures, a shift from health workers and hospitals toward patients, relatives, and citizens, and a growing number of methods. This is a review of one conference series, and it places JAD within a larger family of methods that involve users.
Taken together, the sources show JAD used as a requirements tool in nursing, patient-facing, and research software, usually alongside other methods. They do not show that it produces better systems than the alternatives.
Common JAD problems:
- Inviting the wrong participants, or too few of the people who do the work
- Using a facilitator who is not neutral, such as the project manager or a developer
- Sessions without a scribe, so decisions are lost
- Sessions that wander without ground rules or a parking lot
- Assuming sessions replace observation, interviews, and testing
- Treating the session output as final even after the work changes
What supports effective JAD sessions:
- A neutral, trained facilitator who knows the business area
- Clinicians and other end users who do the work, not only managers
- Visible sponsor support at the start
- Ground rules, a parking lot, and written records of decisions and reasons
- Prototypes and use cases to check that requirements match expectations
- Follow-up testing with users, as in the scrum and usability steps used for Assessment Center
🏥 The Nurse’s Perspective: Clinical, Bedside, & Workflow
Nurses often supply the knowledge that determines whether a system fits the work.
At the Bedside
Bedside nurses know where documentation slows care, which screens are skipped, and what information is missing at handoff. When a nurse takes part in a requirements workshop, those details can enter the design. The nursing admission system study measured nurse acceptance, which reflects how closely the product matched daily work.
In Clinical Workflow
Nurse informaticists commonly act as analysts, subject matter experts, or facilitators in design sessions. They translate between clinical language and technical terms and help the group keep sessions focused on actual tasks, such as admission, shift change, and medication follow-up. Record keeping matters, since a decision that is not written down returns as a rework request later.
In EHR Implementation (Go-Live Perspective)
Many EHR projects include structured design and validation workshops before go-live. During an Epic Go-Live, analysts at the elbow see which of those decisions held up in practice and which did not, and they feed what they learn back to the project team. That record helps the next round of sessions begin from real examples rather than assumptions.
🎓 CAHIMS / CPHIMS & HIMSS Perspective
CAHIMS Exam Domain Mapping
JAD connects requirements, stakeholders, and project delivery:
| CAHIMS Domain | How JAD Appears |
|---|---|
| Healthcare & Technology Environments | System development approaches and user involvement in design |
| Clinical Informatics | Clinician input to requirements, workflows, and documentation tools |
| Healthcare Information & Systems Management | Requirements gathering, use cases, prototypes, and testing |
| Management & Leadership | Facilitation, sponsor support, consensus building, and scope control |
Key Terms to Know Alongside JAD
- Requirements — statements of what a system must do or be
- Use Case — description of how a user interacts with a system to reach a goal
- SDLC (Systems Development Lifecycle) — stages through which a system is planned, built, and maintained
- RAD (Rapid Application Development) — development approach built on fast cycles and user feedback
- Participatory Design — approach that involves users as partners in designing a system
- Stakeholder — person or group with an interest in a project or its results
HIMSS Organizational Position
HIMSS offers education and research on health information and technology topics through its Resource Center. Members can find related information on the HIMSS Resource Center page.
🧭 More HIMSS Word of The Day Terms
Related terms in the Project and Change Management series:
Browse all Project and Change Management terms or the A–Z glossary.
🔗 Explore Further: External References
- Project Management Institute — Jonasson (2007), Determining project requirements: best practices and tips (PMI Global Congress 2007, North America) https://www.pmi.org/learning/library/determining-project-requirements-best-practices-7278
- Fang et al. (2015), Technology and health care : official journal of the European Society for Engineering and Medicine — The development and evaluation of a nursing information system for caring clinical in-patient https://pubmed.ncbi.nlm.nih.gov/26578276/
- Power et al. (2020), Epilepsia — The development of an epilepsy electronic patient portal: Facilitating both patient empowerment and remote clinician-patient interaction in a post-COVID-19 world https://pubmed.ncbi.nlm.nih.gov/32668026/
- Gershon et al. (2010), Quality of life research : an international journal of quality of life aspects of treatment, care and rehabilitation — The development of a clinical outcomes survey research application: Assessment Center https://pubmed.ncbi.nlm.nih.gov/20306332/
- Kanstrup et al. (2017), Studies in health technology and informatics — Developments in Participatory Design of Health Information Technology – A Review of PDC Publications from 1990-2016 https://pubmed.ncbi.nlm.nih.gov/28125408/
- HIMSS — Resource Center https://www.himss.org/resource-center
Term source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025). All definitions in this series are paraphrased for editorial purposes. Readers are encouraged to consult the primary source for exact language.
Eric Andrew Kristof, RN, CAHIMS is a Healthcare IT professional and HIMSS Arkansas Chapter member based in Hot Springs Village, AR, with hands-on Epic Go-Live experience and a diverse healthcare and IT background. He writes at kristof.org at the intersection of clinical care and healthcare technology.
Leave a Reply