C798 Informatics System Analysis and Design, catalog number NURS 6702, is a three-CU course in the MSN Nursing Informatics specialty that builds on C790. It covers interoperability, functionality, data access and user satisfaction, and asks students to analyse reports and to integrate federal regulations into system design. It is the largest course in the specialty and the one that most resembles the actual job, because it forces you to hold clinical need, technical constraint and regulation in the same document.
What NURS 6702 is actually testing
System analysis begins with a truth that is easy to say and hard to practise: you cannot design a replacement for a process you have not described. So the first competency scored is analysis of the current state, in enough detail that the reader can see the work. Who does what, in what order, with what handoffs, and where the current system makes them do something twice.
The second is requirements. A requirement is not a feature request. It is a statement of what the system must do, written so that it can be tested, traced to a source and prioritised against other requirements. Functional requirements say what the system does. Non-functional requirements say how well: response time, availability, accessibility, auditability. Nurses new to this work overweight the functional and forget that a system which does everything correctly in nine seconds per screen will be hated.
The third is interoperability, which the catalog names directly. Systems in healthcare exchange data through defined standards and vocabularies, and a design that assumes integration will simply happen has skipped the hardest and most expensive part of most projects.
The fourth is regulation. The catalog says students integrate federal regulations into system design, which means the requirements list has to contain items that come from law rather than from users: privacy and security safeguards, audit capability, patient access to their own data, and the certification requirements a clinical system operates under.
User satisfaction is the fifth, and it is a design input rather than a survey administered afterwards. Systems fail on adoption more often than on function, and the design has to show how it will be usable by the people expected to use it under real conditions.
Turning scored aspects into a section plan
Your Course of Study holds the rubric, not the WGU catalog. Count the aspects before writing, and expect a three-CU design course to carry more of them than the two-CU courses around it. Each is scored on its own against a three-point scale and each needs a 2.
The word budget, worked. Suppose eight scored aspects and directions asking for about 2,600 words. Reserve 150 for an opening naming the system and the problem and 120 for a close, leaving 2,330 across eight aspects, or about 291 each. Then weight it. The requirements aspect deserves 400, since functional, non-functional and traceability all live there. The interoperability aspect deserves 360, because standards and exchange scenarios take room. That leaves 1,570 for six aspects at about 261 each.
Build the current-state workflow first, as a numbered sequence with actors. Everything else in the document refers back to it, and a design written without one tends to solve problems the reader cannot see.
A structure that fits a system analysis and design deliverable
Task directions govern where they specify a format. Where they do not, this arrangement follows how design documents are read.
| Section | What belongs in it | What earns the aspect |
|---|---|---|
| Problem and scope | The clinical problem, the boundary of the system and what is out of scope | An explicit out-of-scope statement, since scope creep is the standard failure |
| Current state | Workflow as a numbered sequence with actors, timings and handoffs | Detail sufficient to locate the waste and the risk |
| Stakeholders | Who is affected, what each needs, where needs conflict | Conflicts named rather than averaged away |
| Functional requirements | What the system must do, each testable and traced to a stakeholder or regulation | Traceability; an untraced requirement is somebody's preference |
| Non-functional requirements | Performance, availability, accessibility, security, auditability with targets | Numbers attached, since a target without one cannot be tested |
| Interoperability | What data crosses a boundary, in which standard, using which vocabulary | Named standards and a concrete exchange scenario |
| Regulatory integration | The federal requirements the design must satisfy and how each is met | Requirement mapped to design element, not listed in a paragraph |
| Usability and adoption | Clicks, screens, training, and how satisfaction will be measured | Adoption designed for rather than hoped for |
| Report analysis | The reports the system must produce and who acts on each | A named consumer and decision for every report |
| Risks and mitigation | Technical, clinical and organisational risks with responses | Downtime and data migration addressed, since both always happen |
| References | APA list of standards, regulation and informatics literature | Standards and rules cited to their issuing bodies with versions |
Number your requirements and refer to them by number in the later sections. A design that says the interoperability approach satisfies requirements 14 and 15 is doing traceability, which is what separates a design document from an essay about a system.
Evidence craft in system design
This course draws on three separate authorities and mixing them up is the most common technical error.
- Cite exchange standards and clinical vocabularies to the organisations that maintain them, with a version. These are living documents.
- Cite regulation to the rule or an authoritative summary, not to a vendor page or a training deck. Where a certification requirement applies, name the programme.
- Cite usability and adoption claims to research. Human factors work in health systems is a real literature and it is more persuasive than assertion.
- Label vendor documentation as vendor documentation. It is legitimate for describing capability and useless for establishing benefit.
- Give every non-functional target a number and a measurement method. Fast is not a requirement; a stated response time at a stated percentile is.
- Quote sparingly. Regulatory and standards text is heavily reproduced, and WGU runs submissions through a similarity check.
The habit that most improves a design document is writing the downtime procedure. Every clinical system fails eventually, and a design that describes what nurses do during an outage, how data is captured on paper and how it is reconciled afterwards demonstrates that the author has thought past go-live. It is also the section most often missing.
What separates Competent from a submission sent back
Aspects score on their own, and requirements and regulatory integration are where returns concentrate.
- The current state is described concretely enough that the problem is visible.
- Every requirement is numbered, testable and traced to a source.
- Non-functional requirements have numeric targets.
- Each regulatory requirement is mapped to a specific design element.
- Interoperability names standards and describes a real exchange scenario.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so a return costs schedule rather than standing. Terms run six months at a flat rate, so the effective cost of the specialty falls as you close courses inside a term. C798 is a three-CU course sitting in front of the four-CU field experience, and the field experience is the least flexible course in the sequence because it depends on other people's calendars.
Six mistakes that cost time in C798
- Designing without describing the current state. A solution to an undocumented problem cannot be evaluated.
- Requirements written as wishes. If it cannot be tested, it is not a requirement.
- Only functional requirements. Performance, accessibility and auditability decide whether a system is tolerable.
- Assuming interoperability. Name the standard, the vocabulary and what crosses the boundary.
- Listing regulations without mapping them. The aspect wants requirement to design element, one by one.
- No downtime plan. Systems fail, and a clinical design that ignores that is incomplete.
How support works on this course
C798 is the heaviest course in the informatics specialty and the one where structure saves the most time. Send the rubric out of your Course of Study with the task directions and the work starts with the current-state workflow and the scope boundary, because everything downstream depends on both. From there you get a numbered requirements set with traceability, non-functional targets with numbers, standards and vocabularies located and cited to their maintainers, a regulatory mapping table, an adoption plan and a downtime procedure.
The boundaries hold. Objective assessments at WGU are proctored, so we prepare only, never sit them, and never ask for portal credentials. On the field experience we never complete practice hours, contact mentors or sites, sign placement paperwork or fill in hour logs.
Questions students ask about C798
Is C798 the same course as NURS 6702?
Does C798 require C790 first?
Which federal regulations does the course expect?
Writing a system design for C798?
Send your Course of Study rubric and the task directions. We build the current state and scope first, then a traceable requirements set with regulatory mapping.
Where C798 sits in WGU's programs
The July 2026 catalog places this code in 2 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.