Purpose & Scope

This manual is the print-and-reference companion to a self-contained SCORM 1.2 e-learning course, HIPAA Training for LIMS/LIS Users. It is not a substitute for the course, and it is not legal advice or a restatement of the regulation itself — it is a bridge between the two.

What this manual covers

The manual has three jobs. First, it explains what the accompanying course does and does not teach, so training coordinators can decide where it fits in a broader compliance curriculum. Second, it walks an LMS administrator through installing and tracking the SCORM package on their own platform. Third, it reproduces the core reference content of the course — PHI recognition, the Privacy and Security Rules, access controls, breach response, and business associate obligations — in a linear, searchable, printable form that works as a standalone job aid long after the course itself has been completed.

What this manual is not

Intended audience

Relationship to LabCourses

This manual and its accompanying course are published as part of LabCourses, LabLynx's training and certification add-on application. The course itself is a standards-based SCORM 1.2 package, so it can be delivered through LabCourses or imported into any other SCORM 1.2-compliant learning management system your organization already uses — it does not require LabCourses to run.

How to Use This Manual With the Course

The manual and the course cover the same nine topics, but they are built for different moments: the course for first-pass, interactive learning; the manual for lookup, review, and citation afterward.

Recommended workflow

1. Assign the course first. The SCORM package is interactive — it includes a clickable sample LIMS/LIS record for practicing PHI recognition and a scored knowledge check that reports a pass/fail mastery score back to your LMS. That interactivity is best experienced before reading the equivalent reference material.
2. Use the manual for review and lookup. Once a learner has completed the course, this manual becomes the thing they keep open for reference — searchable, linear, and printable.
3. Use the manual for onboarding and audit documentation. Because it is a standalone HTML file, it can be attached to an onboarding checklist, linked from a policy, or printed for a training binder without needing LMS access.

Chapter-to-module correlation

Every content module in the course has a directly corresponding chapter in this manual, so a learner or auditor can move between the two without hunting for equivalent material.

Inside the SCORM Package

The course is packaged to the SCORM 1.2 standard, the most widely supported e-learning interoperability standard across commercial and open-source learning management systems.

Package Contents & Manifest

The download in Chapter 4 is a single .zip archive built as a standard SCORM 1.2 content package. Its manifest (imsmanifest.xml) declares one organization containing one SCO (shareable content object):

Installing in Your LMS

Because it follows the SCORM 1.2 standard, the package installs the same way any SCORM 1.2 course does in a compliant LMS. Exact menu names vary by platform, but the sequence is consistent:

1. Download the .zip package from Chapter 4 — do not unzip it. Most LMS platforms expect the packaged .zip as-is.
2. In your LMS, locate the course or content import function (commonly labeled "Add Content," "Import Package," "Upload SCORM Package," or similar).
3. Select SCORM 1.2 as the package type if your LMS asks you to specify a standard rather than auto-detecting it from the manifest.
4. Upload the .zip file directly. The LMS will read imsmanifest.xml to register the course title, organization, and mastery score automatically.
5. Assign the resulting course to the appropriate learners, groups, or roles as you would any other course in your catalog.

Tracking & Completion Data

The course reports standard SCORM 1.2 CMI data elements back to the LMS as the learner progresses:

• cmi.core.lesson_status — set to incomplete on first launch, and to passed or failed once the knowledge check is submitted, based on the 80% mastery threshold.
• cmi.core.score.raw / min / max — the learner's knowledge-check score, reported on a 0–100 scale.
• cmi.core.lesson_location — the last section the learner viewed, so progress resumes correctly if the learner exits and re-launches later.
• cmi.core.session_time — time spent in the current session, recorded on exit and before the browser unloads the page.

Because progress is tracked at the section level and committed continuously, a learner who exits mid-course and relaunches later returns to the same section rather than starting over.

Download the Course Package

The button below downloads the complete SCORM 1.2 package as a single .zip file, ready to import into your learning management system exactly as described in Chapter 3.

What Is HIPAA?

HIPAA — the Health Insurance Portability and Accountability Act of 1996 — established national standards protecting individually identifiable health information. Three parts of it matter most to anyone using a LIMS or LIS day to day.

Why lab systems carry particular exposure

A laboratory is a covered entity in its own right when it bills electronically, and any vendor or contractor that creates, receives, maintains, or transmits PHI on the lab's behalf — including many LIMS/LIS software vendors, hosting providers, and interface engines — is a business associate bound by the same rules.

A LIMS/LIS holds patient identifiers alongside clinical data continuously, interfaces with instruments, EHRs, and billing systems, and is touched by many different roles in a single day. Each of those is a point where PHI could be seen, sent, or stored incorrectly — which is why lab system users specifically need this training, not just a general compliance overview.

PHI in a LIMS/LIS Record

PHI is not simply "anything medical." It is health information combined with one of a specific set of identifiers that make it traceable to a particular person.

The 18 Safe Harbor identifiers

HIPAA's Safe Harbor method for de-identification lists 18 identifier categories. In a LIMS/LIS, the most common ones to watch for include:

• Names
• Geographic subdivisions smaller than a state (including full zip codes)
• Dates tied to an individual — birth, admission, discharge dates
• Phone numbers, fax numbers, and email addresses
• Social Security numbers
• Medical record numbers and account numbers
• Health plan beneficiary numbers
• Device and vehicle identifiers and serial numbers
• Full-face photographs and comparable images
• Biometric identifiers
• Any other unique identifying number, characteristic, or code

No field is PHI in isolation — but a record is, once linked

A lab value with nothing else attached to it is just a number. The moment that same value sits in a record next to a name, a medical record number, or an accession number tied to a specific person, the entire record becomes protected — including the fields around it that wouldn't have been identifying on their own.

"Clinical Data" fields aren't identifying in isolation, but they are protected the moment they sit in a record with any Direct Identifier — which, in a real LIMS/LIS record, is always. Free-text fields deserve extra caution because they frequently contain identifying details typed in by hand.

The Privacy Rule

The Privacy Rule governs when PHI may be used or disclosed. Treatment, payment, and healthcare operations — often shorthanded as TPO — are permitted uses that don't require special patient authorization.

The minimum necessary standard

Even when a use is permitted, HIPAA expects access to be limited to what's reasonably needed for the task at hand. This is why LIMS/LIS role design matters: a phlebotomist accessioning a specimen doesn't need visibility into a patient's full billing history, and a billing clerk doesn't need to see clinical interpretive comments.

The Security Rule

Where the Privacy Rule governs who may use PHI, the Security Rule governs how electronic PHI (ePHI) must be protected. Its requirements fall into three categories that work together — a gap in any one weakens the others.

Administrative Safeguards

Risk analysis and management, workforce training, sanctions for violations, and a designated security officer responsible for overseeing the program.

Physical Safeguards

Workstation placement and screen privacy, facility access controls, and secure disposal or reuse of devices and media that once held ePHI.

Technical Safeguards

Unique user access controls, audit logging, data integrity checks, and encryption of data in transit and at rest.

Access Controls & Audit Trails in LIMS/LIS

Several technical safeguards show up constantly in day-to-day LIMS/LIS use.

• Unique user IDs. Every person gets their own login. Shared or generic accounts are one of the most common findings in a security audit, because they make it impossible to tell who actually took a given action.
• Role-based access. Each account is granted the access tier its job actually requires — see the minimum necessary discussion in Chapter 7.
• Automatic logoff. Sessions end after a period of inactivity, so a forgotten, unattended workstation doesn't stay open indefinitely.
• Audit trails. The system records who accessed, viewed, edited, or exported a given record, and when.
• Periodic access review. Accounts are reviewed regularly and disabled promptly when someone changes roles or leaves the organization.

Breach Recognition & Reporting

A breach is an impermissible use or disclosure of unsecured PHI that compromises its privacy or security — unless a documented risk assessment shows a low probability that the information was actually compromised. That risk assessment is not a call an individual user makes alone; it belongs to the privacy or security officer.

What This Looks Like in a LIMS/LIS

• Results faxed, emailed, or released to the wrong recipient
• An interface mapping error that routes one patient's results into another patient's record
• A lost or stolen laptop, tablet, or USB drive containing exported PHI
• A staff member browsing a record with no work-related reason to do so

Notification Timelines

Once a breach is confirmed, affected individuals and HHS must generally be notified without unreasonable delay, and no later than 60 days after discovery. Breaches affecting 500 or more individuals also require media notification. That 60-day window is a ceiling, not a target.

1. Report immediately. Tell your privacy or security officer as soon as you notice something, even if you're not sure it qualifies as a breach.
2. Don't investigate or fix it yourself. Preserve logs, emails, and other evidence rather than deleting or altering anything.
3. Cooperate with the review. The four-factor risk assessment and any required notifications are handled by the people responsible for that process.

Business Associate Agreements & Third-Party Interfaces

Any vendor or contractor that creates, receives, maintains, or transmits PHI on the lab's behalf must sign a Business Associate Agreement (BAA) before that access begins.

A BAA doesn't replace safeguards — it contractually binds the vendor to protect PHI the same way the lab itself must.

Where this shows up around a LIMS/LIS

• Interface engines routing HL7 messages between instruments, the EHR, and the LIS
• Cloud hosting or managed-service providers with access to the system or its data
• Remote support technicians troubleshooting the software
• Reference labs or couriers receiving specimens along with identifying order information

Everyday Do's and Don'ts for Lab System Users

None of these are exotic rules — they're the everyday habits that keep the safeguards described in earlier chapters actually working in practice.

Knowledge Check Question Bank

This chapter reproduces all ten questions from the course's scored knowledge check, along with the correct answer and explanation for each. It is intended for trainers and compliance reviewers — not as a study sheet for learners in place of the course itself.