The role of IT in healthcare is to record, share and protect patient information, so clinicians see the right data at the right time. Electronic health records, practice management, imaging archives (PACS), patient portals and telehealth hold the data; standards such as HL7 FHIR move it between organizations; and security keeps it available, because downtime delays care.
This guide is for clinic managers, health-tech founders and the IT teams who support them. It covers the core systems, how data moves between them, the US and EU rules that now require sharing, what the Change Healthcare attack taught the sector, the proposed HIPAA Security Rule update, medical device security and, briefly, AI. It is information about health IT, not medical or legal advice.
What IT does in healthcare
Strip away the product names and healthcare IT does five jobs:
- Record care. Notes, orders, results, medication lists and allergies, with alerts when an order conflicts with what is already known about the patient.
- Coordinate care. Share the record with the next clinician, the lab, the pharmacy, the hospital across town and, increasingly, the insurer.
- Get the organization paid. Registration, insurance eligibility, coding, claims and prior authorization.
- Give patients access. Portals, apps, secure messages and video visits.
- Learn from the data. Quality reporting, population health, research and, more recently, AI models.
Under all five sits a sixth: keep the data confidential and the systems running. In most industries an outage costs sales. In healthcare it can delay treatment, which is why security and availability are design requirements here, not a layer added at the end.
The core systems: EHR, practice management, PACS, portals and telehealth
A typical clinic or hospital runs some version of each of these:
| System | What it does | What it usually speaks |
|---|---|---|
| Electronic health record (EHR) | The chart: problems, medications, allergies, notes, orders, results | HL7 v2 feeds, FHIR APIs |
| Practice management | Scheduling, registration, eligibility, billing, claims | X12 transactions through a clearinghouse |
| Lab and radiology systems | Departmental workflow: orders in, results out | HL7 v2 messages |
| PACS | Stores and serves medical images | DICOM |
| Patient portal and apps | Records, messages, bookings, payments for patients | FHIR APIs with SMART App Launch |
| Telehealth and remote care | Video visits and readings from devices at home | A video platform tied to the EHR |
The EHR is the system of record. In a small practice it often comes bundled with practice management; in a hospital, departmental systems such as the lab, pharmacy and radiology feed it, many of them through HL7 version 2 messages. HL7 calls version 2 the workhorse of clinical data exchange: it was first released in October 1987, it was designed for data that lives in departmental systems as well as a central one, and HL7 says 95% of US healthcare organizations use it.
Imaging runs on its own standard. DICOM is the international standard for transmitting, storing, retrieving and displaying medical imaging information, and it is what lets scanners, a PACS and viewing workstations from different manufacturers work together. Studies are large, so the PACS usually sits beside the EHR, which links to images rather than storing them.
Patient portals and telehealth are where patients touch the system, and both handle protected health information, so the same rules apply to them as to the EHR. During the pandemic, HHS did not penalize providers for telehealth delivered in good faith over non-public-facing remote communication tools. That enforcement discretion expired on May 11, 2023, and the transition period ended on August 9, 2023: a video platform now has to meet HIPAA like any other system that handles patient data.
How health data moves: HL7 v2, FHIR and the interface engine
Connecting systems one pair at a time does not scale: ten systems wired point to point can need up to 45 separate interfaces. Hospitals put an interface engine in the middle instead (products such as Rhapsody, InterSystems HealthShare or Mirth Connect). It receives each feed, translates codes and formats, and routes each message to every system that needs it.
FHIR (Fast Healthcare Interoperability Resources) is HL7's standard for the same job in web form. Data is divided into resources, such as Patient, Observation, ImagingStudy or Appointment, and exchanged over a REST API in JSON or XML. A developer who has built any web API can read a FHIR server on day one. The hard part is agreeing what each field means and which codes fill it, which is the job of profiles and implementation guides.
FHIR versions matter, because regulations name them:
| Version | Published | Status in September 2026 |
|---|---|---|
| R4 (4.0.1) | October 30, 2019 | First release with normative content; the version US rules name |
| R5 (5.0.0) | March 26, 2023 | HL7's current published version |
| R6 (in work) | Not yet | Second full ballot published July 17, 2026 |
The version history shows R6 still in ballot. In the US, R4 is the version that counts: US Core, the set of profiles that US implementation guides build on, is still based on R4 (its current release is 9.0.0), and it underpins ONC certification testing for patient data access.
Authorization is standardized too. SMART App Launch defines, on top of OAuth 2.0, how an app gets permission to FHIR data: launched from inside the EHR by a clinician, opened on its own by a patient, or connected as a back-end service with no user at all. The app receives a token limited to the scopes it was granted, never a login to the database.
The US rules that make sharing the default
Technology alone never made records flow: data kept inside one system also keeps patients and customers there. Three sets of US rules now push the other way.
Information blocking under the 21st Century Cures Act
The 21st Century Cures Act of 2016 made sharing electronic health information the expected norm. Information blocking is a practice by an "actor" (a healthcare provider, a developer of certified health IT, or a health information exchange or network) that is likely to interfere with access to, exchange of or use of electronic health information, unless the law requires it or an exception in 45 CFR Part 171 applies, such as the privacy or preventing-harm exceptions. The HHS Office of Inspector General can impose penalties of up to $1 million per violation under a final rule it posted on June 27, 2023, and HHS finalized separate disincentives for providers in 2024.
For a health-tech company this cuts both ways. The exceptions work as safe harbours: a practice that meets one is not information blocking, and one that does not is judged case by case. That gives you leverage when a provider or EHR developer stalls a reasonable request for data, and if your product is certified health IT, the same rule applies to you.
TEFCA: a national network of networks
TEFCA, the Trusted Exchange Framework and Common Agreement, links health information networks under one agreement, so a provider on one network can find records held on another. The first Qualified Health Information Networks (QHINs) were designated in December 2023, and health data began flowing among them within days. Every request must state its purpose: treatment, payment, health care operations, public health, government benefits determination or individual access services.
The CMS Interoperability and Prior Authorization rule
The CMS Interoperability and Prior Authorization final rule (CMS-0057-F), released January 17, 2024, applies to payers: Medicare Advantage organizations, state Medicaid and CHIP programs and their managed care plans, and Qualified Health Plan issuers on the federal exchanges. Exact dates vary by payer type; the general schedule is:
| Requirement | Generally applies from |
|---|---|
| Prior authorization decisions within 72 hours (urgent) or 7 calendar days (standard), except exchange plans | January 1, 2026 |
| A specific reason for every denial, and yearly public prior authorization metrics | 2026 (first metrics by March 31) |
| Patient Access API extended with prior authorization information | January 1, 2027 |
| Provider Access API, for in-network providers treating the patient | January 1, 2027 |
| Payer-to-Payer API, for patients who change plans | January 1, 2027 |
| Prior Authorization API: covered services, documentation rules, requests and decisions | January 1, 2027 |
The required standards are FHIR 4.0.1, US Core 3.1.1, SMART App Launch 1.0.0, FHIR Bulk Data Access 1.0.0 and OpenID Connect Core 1.0, with the Da Vinci and CARIN implementation guides recommended; payers may use newer approved versions. Drugs are excluded. A proposed rule of April 14, 2026 (CMS-0062-P) would extend electronic prior authorization to drugs and adopt FHIR as a HIPAA standard for prior authorization transactions. Comments closed on June 15, 2026; as of September 2026 it was still a proposal.
Europe: the European Health Data Space
Regulation (EU) 2025/327 created the European Health Data Space (EHDS). It was published on 5 March 2025, entered into force on 26 March 2025 and applies in stages, as the European Commission sets out:
| Date | What applies |
|---|---|
| 26 March 2027 | The regulation's general date of application, and the deadline for key implementing acts |
| 26 March 2029 | Exchange of patient summaries and ePrescriptions and eDispensations; secondary-use rules for most data categories |
| 26 March 2031 | Exchange of medical images, lab results and hospital discharge reports; remaining secondary-use categories, such as genomic data |
| March 2035 | Countries outside the EU and international organizations can apply to join HealthData@EU |
Two parts matter to IT teams. For primary use, patients get access to their records and can share them across borders in a European exchange format (EEHRxF), and EHR systems on the EU market must meet common interoperability and security requirements that manufacturers certify. For secondary use, researchers and companies can reuse health data only for listed purposes, under a permit from a health data access body, inside secure processing environments from which no personal data can be downloaded. The EHDS builds on the GDPR, the Data Governance Act, the Data Act and the NIS Directive; it does not replace them.
Why ransomware hits healthcare hard: the Change Healthcare attack
Ransomware pays best where downtime is intolerable, and few organizations tolerate downtime less than a provider that cannot see records or submit claims. The clearest recent case is Change Healthcare, a UnitedHealth Group subsidiary.
On February 21, 2024, UnitedHealth Group identified an attacker inside some Change Healthcare systems and isolated them from connecting systems. Providers who depended on those services lost a route for claims and payments: by March 9, 2024, CMS had directed its Medicare contractors to fast-track providers changing clearinghouse and to accept paper claims, and was offering accelerated and advance payments. Change Healthcare's breach report describes a ransomware attack, and on July 31, 2025 it told HHS's Office for Civil Rights that approximately 192.7 million individuals had been affected. HHS called the attack's magnitude unprecedented.
The lessons are organizational as much as technical:
- Map your vendor dependencies. The attack hit a business associate, not the providers' own networks. HIPAA still left each covered entity responsible for making sure patients were notified, although they could delegate the task.
- Keep a second route for revenue. A backup clearinghouse enrolled, tested and ready is cheaper than switching in the middle of an outage or falling back to paper claims.
- Check your business associate agreements. HHS used the incident to remind covered entities and business associates that those agreements must be in place and that breach notification must be timely.
The HIPAA Security Rule update: what was proposed and where it stands
On December 27, 2024, HHS's Office for Civil Rights proposed an update to the HIPAA Security Rule, which protects electronic protected health information (ePHI) held by covered entities and their business associates. The proposal was published in the Federal Register on January 6, 2025, with comments due by March 7, 2025. Among other changes, it would:
- make nearly all safeguards required, removing the distinction between "required" and "addressable" ones;
- require a technology asset inventory and a network map of how ePHI moves, reviewed at least every 12 months;
- require multi-factor authentication, and encryption of ePHI at rest and in transit, with limited exceptions;
- require vulnerability scanning at least every six months and penetration testing at least every 12 months;
- require network segmentation, and separate controls for backup and recovery;
- require written procedures to restore certain systems and data within 72 hours, and tested incident response plans;
- require a compliance audit at least every 12 months, and business associates to verify their technical safeguards every 12 months.
Important
As of September 2026, no final rule has been published in the Federal Register, so the existing Security Rule still applies. Do not wait for the final text: the proposed list is already a fair picture of what a defensible security program in healthcare looks like.
If you want the external scanning done for you, our security scanning service runs scheduled external scans of your websites, servers and cloud accounts, ranks findings by exploitability as well as severity, and closes each one with a re-test. Penetration tests are scoped as a separate engagement. Scanning supplies evidence for your vulnerability management; it does not make you compliant on its own.
Medical device cybersecurity: FDA section 524B
Connected devices are computers that the hospital cannot always patch on its own schedule. Since March 29, 2023, section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act, 2023 (signed December 29, 2022), has required makers of "cyber devices" to include cybersecurity in their premarket submissions. A cyber device is one that includes software, can connect to the internet and could be vulnerable to cybersecurity threats. Its maker must:
- submit a plan to monitor, identify and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure;
- maintain processes that give reasonable assurance the device and related systems are cybersecure, and make updates and patches available;
- provide a software bill of materials (SBOM) covering commercial, open-source and off-the-shelf components.
The FDA did not refuse submissions for missing this information until October 1, 2023; since then it expects every cyber device submission to include it. It updated its premarket cybersecurity guidance on June 27, 2025, adding a section on cyber devices.
For a hospital or clinic, 524B changes procurement. Ask for the SBOM and the vendor's vulnerability disclosure contact before you buy, and keep the SBOMs where your security team can search them: when a vulnerable component makes the news, you check the list instead of calling every vendor. Until the patch arrives, segmentation does the protecting. Put devices on their own network segment, reachable only by the systems that need them, such as the PACS.
A health-tech company building a device, including software that is itself a device, should plan the SBOM, the update mechanism and the disclosure process from the first design review, because all three are part of the submission.
AI in clinical settings, briefly
The AI that regulators have reviewed is mostly software that reads images and signals. The FDA's list of AI-enabled medical devices held 1,614 devices in its September 2026 update (decisions through June 29, 2026), and 1,230 of them, about three in four, were radiology devices; the FDA notes the list is not comprehensive. Our posts on AI in breast cancer screening and AI for lung cancer on CT show how two kinds of these tools are tested and where they fall short, and AI in health and wellness covers wearables, consumer apps and who protects their data.
For IT, the lesson is plainer: a model is only as good as the pipeline that feeds it. Imaging AI needs reliable DICOM routing to and from the PACS. Anything trained or evaluated on records needs consistent codes, known provenance and access controls, which is data platform work before it is AI work.
What a clinic or health-tech company should prioritize
For a clinic or hospital
- Inventory systems and data flows. List every system that holds patient data, who runs it, and how data moves between them, including vendors such as your clearinghouse.
- Protect every login that reaches patient data. MFA on email, the EHR, remote access and vendor portals; encryption on laptops and backups.
- Make recovery real. Keep backups an attacker cannot delete, restore one on a schedule and time it against the 72 hours HHS proposed.
- Build a second route for revenue. Enrol with a backup clearinghouse and test it before you need it.
- Segment and track connected devices. Ask for SBOMs, keep devices on their own network segment and record who patches each one.
- Scan what faces the internet on a schedule, and fix by exploitability, not only by severity score.
- Answer data requests through standard interfaces. A request met through a FHIR API is faster for everyone and leaves a clear record of how it was handled.
For a health-tech company
- Build on the standards regulators name: FHIR R4 with US Core and SMART App Launch for the US; watch the EHDS dates of March 2029 and March 2031 if you sell EHR software in the EU.
- Treat security as a product feature: MFA, encryption, audit logs, an SBOM and a published vulnerability disclosure process. If you handle protected health information for covered entities, expect a business associate agreement and audits.
- Separate operational data from analytics. Copy what reporting and models need into a governed platform, with the least identifying data that answers the question.
- Keep evidence as you go: scan results, penetration test reports, restore tests and access reviews. Your customers' auditors will ask for them.
Computese is not a clinical systems vendor: we do not sell EHR, PACS or medical device software. Help is available for the data work around those systems. Our data platform service builds the ingestion, the governed warehouse or lakehouse and the semantic layer, engineered with tests, lineage and access control, so every team reads the same number; personal data is classified and masked, with role, row and column-level access. For the security side, see the security scanning service described above.
