Clinical Data: Five Moves to Stop Bleeding Risk and Start Sharing

Who This Is For and Why You Should Care

Imagine you're a practice manager at a three-clinic group. A patient walks in, tells you they had a CT scan at the hospital down the road, and asks why your staff can't just pull it up. You know the answer: your EHR doesn't talk to theirs. But the patient doesn't care about interfaces. They care that you're asking them to repeat their history and re-do tests. That's the real cost of ignoring clinical data—not just inefficiency, but actual harm and patient frustration.

This guide is for you if you're in health IT, clinical informatics, or operations, and you're tired of hearing about 'interoperability' as some distant ideal. I'm going to walk you through five concrete moves to make your clinical data work—not just store it. You'll get a specific path to follow, and I'll warn you about the trap that catches most people.

1. Know What You Have: Inventory Your Data and Its Formats

First step is boring but essential: take stock. You can't govern what you don't know exists. That means mapping your data sources—EHR, lab system, imaging, patient portal—and identifying the formats. Most legacy systems still speak HL7 Version 2, a messaging standard that's been around since 1987 and is still used by over 95% of US healthcare organizations (HL7 International). It's not going away. But modern apps expect FHIR, HL7's RESTful API standard that represents things like Patient, Encounter, and Observation as discrete resources. You need to know where each lives.

Also, know your terminologies. Lab results should be coded with LOINC, which is the international standard for identifying observations and measurements (LOINC). Diagnoses should use ICD-10 or SNOMED CT, and drugs should use RxNorm. If your data isn't coded, it's not really data—it's text. That's a problem for sharing and for analytics. So start by creating a simple inventory: system, format, terminology, and who's responsible for it. You can't fix what you can't see.

2. Choose Your Interoperability Target: FHIR R4 Is the Safe Bet

Now that you know what you have, decide what you're building toward. Don't get paralyzed by options. For patient access and modern apps, FHIR is the way. FHIR R4 (version 4.0.1) was the first release with normative content, and it's the version required by CMS's Patient Access API (Federal Register). FHIR R5 came out in March 2023 and adds more resources—157 in total—but it's still a trial-use standard. For production, R4 is rock solid. The US Core Implementation Guide, based on R4, defines the minimum data elements and interactions for US systems, and it's the foundation for national interoperability (US Core Implementation Guide).

If you're starting new development, build on FHIR R4. If you're stuck with HL7 v2 for high-throughput legacy workflows, don't rip it out—just add FHIR as a layer for new integrations. That's what most forward-thinking organizations do: keep v2 for internal messaging, use FHIR for external APIs. That way you meet the 2026 USCDI requirements without breaking your back-end.

3. Clean Up Your Vocabularies: Map to Standards Like LOINC, SNOMED, RxNorm

Data without standard codes is a swamp. If your lab interface sends 'HGB' and another sends 'Hemoglobin,' that's not interoperable. The fix is to map everything to standard terminologies. LOINC is the go-to for lab and clinical observations. As of version 2.82, released in February 2026, it has over 109,000 total concepts—including more than 66,000 lab concepts and 28,000 clinical ones (LOINC). That's a lot of codes, but you don't need all of them. You need to map your top 100 tests and observations. SNOMED CT covers clinical terms and is required in US federal systems, and RxNorm normalizes drug names across pharmacy vocabularies (NLM).

This is not a one-time project. Terminologies update—LOINC adds over a thousand new concepts each release. So set up a quarterly review: pull your mappings, check for new codes, and update. If you skip this, you'll end up with 'garbage in, gospel out'—the same test coded three ways, which breaks any attempt at quality reporting or research. One warning: don't try to map everything at once. Prioritize the data you actually share, like labs, meds, and problems. That's where the pain is.

4. Lock It Down: HIPAA Security That Actually Works

Once you're sharing data, you're a bigger target. HIPAA is not optional, and the penalties keep rising. As of January 2026, the maximum penalty for willful neglect not corrected is over $2.1 million per calendar year (Federal Register). That's not a fine you want to explain to your board. The Security Rule requires safeguards in three buckets: administrative, physical, and technical (eCFR). Most breaches happen because of basic failures—no encryption, no access controls, no training.

Do the basics well: encrypt data at rest and in transit, enforce unique user IDs, set automatic logoff, and have an emergency access procedure. NIST's SP 800-66 Rev. 2 is your practical guide—it's the official resource for implementing the Security Rule (NIST). If you're using FHIR, you also need to think about authorization—who can read what. The 'minimum necessary' standard under the Privacy Rule applies to every disclosure (eCFR). So don't give an app full access if it only needs labs.

Also, remember the Breach Notification Rule: if unsecured PHI is breached, you must notify individuals within 60 days of discovery (eCFR). That's a tight window. Have an incident response plan ready. Don't wait for a breach to figure out who's on call.

5. Share It: Don't Hoard—But Watch Out for Information Blocking

Here's the trap I mentioned: the temptation to keep data closed because it's easier. The Cures Act made information blocking illegal—that's any practice that interferes with access, exchange, or use of electronic health information (ONC). The rule applies to providers, health IT developers, and health information networks. And enforcement is real: HHS OIG can investigate and penalize developers and networks, and they've proposed disincentives for providers.

So don't hoard. But also don't share blindly. Use TEFCA, the nationwide framework for health information sharing, which is now live with designated QHINs (ONC). If you're a provider, you can connect through a QHIN or a health information exchange. And when you do share, make sure you're using the right standards—FHIR for APIs, and standard terminologies for content.

One concrete example: a patient requests their records via an app. Under CMS rules, you must provide a Patient Access API using FHIR R4 that allows third-party apps to retrieve data as directed by the patient (Federal Register). That means you need to expose data in a standard way, not just send a PDF. That's the future—and it's here now.

Bottom Line

The single best move you can make this quarter is to pick one integration—say, sharing lab results with a community partner—and do it end-to-end with FHIR R4 and standard terminologies. That forces you to clean up your data, secure it, and share it legally. Do that, and you'll have a template for everything else.

Sources

• HL7 International - https://www.hl7.org/fhir/
• ONC / HHS (Health IT) - https://www.healthit.gov/topic/health-it-basics
• NIST SP 800-66 Rev. 2 - https://csrc.nist.gov/pubs/sp/800/66/r2/final
• LOINC - https://loinc.org/
• Federal Register (CMS Interoperability and Patient Access Final Rule) - https://www.federalregister.gov/documents/2020/05/01/2020-05050/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-and