D911 is Transforming Healthcare Through Technology, listed at WGU as MHA 6912 and worth three competency units. It examines how information technology is used in healthcare settings to improve patient care, efficiency and decision making. The word that matters in that description is used. Nobody is asking you to evaluate software. They are asking you to explain how a specific technology changes what a specific group of people do during a specific part of their day, what that is worth, and what has to be true for it to stick.
Write about the work, not the product
Take a paper proposing a patient portal expansion. The weak version describes the portal: messaging, results release, appointment requests, bill payment. All accurate, all available from any vendor page, none of it scoreable as analysis. The strong version describes the day it changes. Patients who currently phone during business hours to ask for results now read them at 9pm. The call volume that reaches the front desk drops, so two staff shift to prior authorization work. Clinicians receive a new stream of messages that nobody has scheduled time for, which is where the initiative usually fails.
That last sentence is the one that earns the aspect. Technology in healthcare rarely fails technically. It fails because it moves work from one group to another without moving the time, the training or the money with it. A submission that names the group receiving the new burden, and says what is being given to them in exchange, is doing the thing this course exists to teach.
The second discipline is to write about the current state before the future state. If you cannot describe the process as it exists now, with a number attached, you cannot show improvement later, and the benefit aspects will have nothing to rest on.
Turning the aspects into a technology case
Aspect detail sits in your Course of Study, not the catalog. In this subject aspects tend to cluster around problem definition, technology description, workflow impact, benefits, risks, and implementation. Sort yours before drafting, and notice that only one of those clusters is about the technology itself.
The word budget, worked. Assume a 2,000 word paper with ten scored aspects. Hold 140 for a framing paragraph that names the organization and the process, leaving 1,860, or 186 per aspect flat. Technology description aspects are the ones students overspend on, so cap them at 120 each. If two aspects are descriptive, that releases about 130 words. Workflow impact and benefit aspects should sit at 260, because each has to carry a before, an after and a measure. Risk and implementation aspects sit near 220. Write the numbers next to the headings and check them at the halfway point, because in this subject the description section grows quietly while you are reading vendor material.
Draft the risk section early rather than last. In technology writing the risks are the most specific content you will produce, and drafting them early tends to sharpen the benefit claims made earlier in the document.
The shape of a healthcare technology proposal
Where directions prescribe a structure, follow it. Where they do not, this arrangement puts the emphasis where the scoring is and keeps the paper out of vendor language.
| Section | What belongs here | The question it must answer |
|---|---|---|
| Problem | The operational or care problem, with a current measure | What is broken, and by how much |
| Current workflow | The steps today, who does each one, how long it takes | Where exactly does time or accuracy leak |
| Proposed technology | Capability described in functional terms, not brand terms | What can it do that the current process cannot |
| Future workflow | The same steps after adoption, with the changes marked | Which task disappears, which is created, and for whom |
| Benefits | Care, efficiency and decision quality effects, each with a measure | How would we know it worked |
| Costs and resources | Licensing, interfaces, training, staff time, ongoing support | What is the full cost, not just the purchase price |
| Risks and safeguards | Privacy, security, downtime, data quality, workflow burden, equity of access | What could go wrong and what is in place if it does |
| Adoption plan | Champions, training, phased rollout, feedback loop, measurement | Who makes this stick after the launch |
Interoperability deserves a paragraph inside the costs row. Systems that cannot exchange information with what you already run create duplicate entry, and duplicate entry is where clinical staff quietly stop using new tools.
Evidence craft in technology writing
This subject has more promotional literature than almost any other in the program, so source discipline matters.
- Separate vendor claims from independent evidence in your own sentences. A supplier's case study is evidence that an implementation happened, not that it delivered what it claims.
- Use peer reviewed evaluations for effect sizes and professional or agency publications for standards and adoption context.
- Quantify current state from real operational measures where you can, and label estimates clearly where you cannot.
- Treat privacy and security as design requirements rather than as a compliance paragraph. Say what data moves where, who can see it, and what the access control model is.
- Address equity explicitly when the technology involves patients directly. Portals, remote monitoring and video visits all depend on devices, connectivity and language, and a proposal that ignores that will widen a gap it claimed to close.
- Cite in APA at the point of the claim, including standards documents and data sources.
The most persuasive paragraph in a technology case is usually the one describing what happens when the system is unavailable. Naming the downtime procedure, and who is responsible for reconciling records afterwards, signals that you have thought past the demonstration.
What separates Competent from a submission sent back
The dominant return is the feature list wearing a proposal's clothes. Nothing is wrong in it, and the workflow, benefit and risk aspects are all thin because the paper never described anybody's day. The second return is benefits with no baseline, where improvements are claimed against a current state that was never measured. The third is the implementation plan with no owner, which reads as optimism rather than as management.
Passing submissions look concrete. One process, named. A current state with at least one number. A future state written as the same steps with changes marked. Benefits attached to measures that already exist or that you say how to start collecting. A cost line that includes training and support, not only licensing. And an adoption plan naming who champions it and what happens in the first thirty days.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so a return costs queue time rather than a score, and in a six month flat rate term the queue is the part worth avoiding. In this course the most common rebuild is adding the current state that should have been written first.
Where a proctored objective assessment accompanies this course, our role is preparation only. We drill the vocabulary, work practice items and give an honest readiness call. Assistance during a proctored assessment is out of the question, and portal credentials are never requested.
Six mistakes that cost time in D911
- Describing the product instead of the process. Features belong in one short section. The rest of the paper is about work changing hands.
- No current state measure. Without a baseline there is no benefit, only a promise.
- Ignoring who absorbs the new burden. New alerts, messages and documentation land on someone. Name them and address it.
- Purchase price as the cost. Interfaces, training, backfill during training and ongoing support usually exceed the licence.
- Privacy handled as a sentence. Say what data moves, who sees it, and how access is controlled and audited.
- Adoption assumed. Clinical staff adopt tools that save them time. Say what this one saves and who will hold the rollout together.
How we work this course with you
Send the task directions and your rubric and you get the process chosen and mapped first, current state and future state side by side with the changed steps marked, a benefit table where every claim has a measure attached, and a section plan with word counts that keeps the description section from eating the paper. On review we check that every benefit traces back to a workflow change and that somebody is named for every step of the rollout.
Questions D911 students ask
Should I name a specific vendor product in the paper?
How do I write about a workflow I have never seen?
Is artificial intelligence a safe topic for this course?
Writing the D911 technology case?
Send the MHA 6912 directions. You get a mapped workflow, a benefit table and a section plan back.
Where D911 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. 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.