What Skills Should Healthcare IT Teams Develop for Interoperability and Digital Modernization?

Healthcare IT teams need skills across six domains to support interoperability and digital modernization: FHIR implementation, HL7 v2 integration, API security, TEFCA governance, cloud architecture, and clinical AI readiness. FHIR expertise alone is not enough. Organizations that staff only one or two of these areas find that integration projects stall at the boundaries — working FHIR endpoints with no governance, or cloud data lakes with no access control.

This guide covers what each skill domain requires in practice, what the current regulatory timeline demands, and where teams typically have gaps.

What Is FHIR and Why Does Every Healthcare IT Team Need It Now?

FHIR R4 is the exchange standard for patient data required under current CMS and ONC mandates. CMS-0057-F requires payers to expose FHIR-based APIs for prior authorization and data exchange, with operational provisions due January 1, 2026 and full API compliance due January 1, 2027.

Teams need developers and architects who can build, consume, and validate FHIR resources — Patients, Observations, Conditions, DocumentReferences — and who understand the difference between FHIR as a query interface and FHIR as a persistence layer. Many implementations fail not because FHIR is wrong, but because the team doesn’t understand which problem it solves.

Practical FHIR skills include:

• SMART on FHIR for OAuth2-based authorization
• Working with at least one FHIR server (HAPI, Azure Health Data Services, Google Cloud Healthcare API)
• Mapping legacy data models into FHIR-conformant resources without losing clinical meaning
• Da Vinci Implementation Guides for prior authorization workflows (CRD, DTR, PAS) — covered in detail in the next section

What Are Da Vinci Implementation Guides and Why Do Teams Need Them?

Da Vinci Implementation Guides (IGs) are a set of FHIR-based technical specifications built to automate administrative workflows between payers and providers — replacing phone calls, faxes, and PDF forms with structured, machine-readable data exchange. HL7 International describes the Da Vinci Project as a private-sector initiative that creates standards for automating workflows, enabling real-time data exchange, and reducing administrative burden across the payer-provider relationship.

The three IGs directly referenced in CMS-0057-F compliance work are:

CRD — Coverage Requirements Discovery

Allows a physician’s EHR to query a payer in real time: “Does this procedure require prior authorization?” The answer returns inside the EHR interface without a phone call. CRD runs on CDS Hooks — a standard for triggering an external service call at the moment of a clinical decision.

DTR — Documentation Templates and Rules

Once CRD confirms that prior auth is needed, DTR pulls the required forms and pre-fills them with data already in the EHR. The clinician completes only what the system can’t supply automatically. This reduces documentation time from hours to minutes in implementations where it functions correctly.

PAS — Prior Authorization Support

Submits the completed prior authorization request directly to the payer’s system via FHIR API. The payer’s response — approval, denial, or request for additional documentation — returns to the EHR as structured data, not a letter or a phone call. A research paper published in JAMIA describes the Da Vinci PAS specification as a structured framework for routing administrative data elements from existing clinical systems into the prior authorization pipeline.

Regulatory standing:

ONC’s October 2025 Electronic Prior Authorization fact sheet cites Da Vinci IGs directly as the implementation specifications referenced in the ePA certification criteria. EHR vendors seeking ONC certification for electronic prior authorization must implement these specifications. This makes Da Vinci IGs not just a best practice but a certification requirement.

HL7 runs regular Da Vinci Connectathon events where developers test FHIR-based implementations against live payer and provider interfaces — the practical venue for teams building toward the January 2027 CMS-0057-F API deadline.

Beyond the three core IGs, Da Vinci covers adjacent workflows:

• PDex — patient data exchange between payers at point of coverage change
• PDex Plan Net — drug formularies and provider directories
• DEQM — quality measure data exchange
• CDex — clinical documentation requests between payers and providers

All specifications are publicly available on HL7.org and updated in step with regulatory changes.

Why Do Healthcare IT Teams Still Need HL7 v2 Skills?

HL7 v2 carries the operational load in most health systems today. ADT feeds, lab results, radiology orders, and pharmacy messages still flow over v2 in live production environments. Teams without v2 skills are blocked from a large portion of active integration work.

Engineers need to:

• Read and parse message segments (MSH, PID, OBX, ORC)
• Understand trigger events and handle vendor-specific v2 variations
• Transform v2 feeds into FHIR pipelines — a workflow called “v2-to-FHIR transformation”

v2-to-FHIR transformation is one of the highest-demand capabilities in healthcare integration. It requires both standards, not one or the other.

What API Management Skills Do Healthcare IT Teams Need?

Publishing a FHIR endpoint is an API management problem. Healthcare IT teams increasingly own the design, security, and lifecycle of APIs consumed by payers, app developers, third-party vendors, and internal clinical systems.

Required skills include:

• API gateway configuration, rate limiting, versioning, and developer portal management
• OAuth2/OIDC implementation with correct scope enforcement at the resource level
• Token audit logging that satisfies HIPAA requirements
• SMART on FHIR authorization patterns for EHR-embedded workflows

Many organizations have FHIR servers running correctly but API security implemented poorly. That configuration passes functional tests and fails a compliance review.

Healthcare breaches cost an average of $7.42 million per incident, the highest of any industry. In 2025, user account compromise affected 74% of healthcare organizations running in cloud environments. API and cloud misconfiguration is a primary attack vector, not an edge case.

What Skills Does TEFCA Require Beyond Technical Configuration?

The Trusted Exchange Framework and Common Agreement (TEFCA) creates a national interoperability network through Qualified Health Information Networks (QHINs). Formally designated QHINs began onboarding participants in 2024 under governance rules codified in 45 CFR Part 172.

The scale of TEFCA is growing fast. By February 2026, nearly 500 million health records had been exchanged through TEFCA — up from roughly 10 million in January 2025, according to HHS data reported at the ASTP/ONC Annual Meeting by Assistant Secretary Thomas Keane, MD. The Social Security Administration connected to TEFCA in spring 2026, with interoperability expected to cut disability claims processing times by more than 50% in many cases. TechTarget’s SearchHealthIT reports that Eric Musser, VP of federal affairs at the National Committee for Quality Assurance, described both TEFCA and CMS’s Health Tech Ecosystem initiative as working toward “reducing friction in healthcare data” and improving the patient experience across the process.

Teams connecting to TEFCA need staff who understand:

• The five exchange purposes: Treatment, Payment, Individual Access, Public Health, Benefits Determination
• What data each exchange purpose authorizes and what it restricts
• How to participate through a QHIN such as CommonWell or eHealth Exchange
• How to write and enforce data sharing agreements
• How to map organizational data flows to TEFCA use case categories

Consent and minimum-necessary-data determinations require legal and compliance expertise alongside technical configuration. ONC’s own December 2025 assessment, authored by principal deputy national coordinator Steven Posnack, identified trust — not technology — as TEFCA’s hardest implementation problem. Governance skills are the constraint.

What Does Healthcare Data Governance Actually Require?

Healthcare data governance means knowing which data assets exist across the organization, what their provenance is, who has access to them, and whether data quality meets clinical or analytical standards.

Teams consistently understaff this function. When they do, FHIR implementation projects surface the deficit mid-project: inconsistent coding, missing required fields, conflicting patient identifiers.

Practical governance skills include:

• Building and maintaining a clinical data dictionary
• Terminology mapping across ICD-10, SNOMED CT, LOINC, and RxNorm
• Managing consent flags across systems
• Master patient index (MPI) management and patient matching algorithms

Duplicate patient records are one of the most common blockers in interoperability projects and one of the harder problems to fix retroactively.

McKinsey’s November 2025 analysis identified data governance as a critical differentiator for healthcare AI. Organizations that establish governance frameworks early can convert patient records into clinical-data foundries. Those that don’t find that AI model outputs degrade in ways that trace back to data quality problems upstream.

Becker’s Hospital Review reported in December 2025 that Corewell Health CIO Jason Joseph is actively limiting access to core databases and tightly controlling how data moves throughout the organization, stating: “The health system is actively leveraging cloud data warehouse technology, furthering our investments in this area.” The article notes that health system CIOs entering 2026 see governance — not new tooling — as the determinant of AI success.

What Cloud Architecture Skills Support Healthcare Workloads?

The major cloud platforms — Microsoft Azure, Google Cloud, and AWS — have built healthcare-specific services that Clinovera uses and change what architecture options are available.

• Azure Health Data Services: bundles FHIR, DICOM, and MedTech services with Azure Active Directory integration
• Google Cloud Healthcare API: supports FHIR, HL7 v2 ingestion, and DICOM storage with de-identification pipelines
• AWS HealthLake: adds NLP-based enrichment on top of FHIR storage

Our teams have architects who can:

• Design for HIPAA-eligible services and configure Business Associate Agreements (BAAs) with cloud vendors
• Build event-driven integration pipelines using Pub/Sub, EventGrid, or EventBridge
• Orchestrate data pipelines with Azure Data Factory, Cloud Composer, or AWS Glue
• Apply de-identification techniques that meet Safe Harbor or Expert Determination standards under the HIPAA Privacy Rule

McKinsey’s analysis shows cloud providers are repositioning as the operating layer for healthcare AI — developing healthcare-specific platforms, clinical documentation tools, and workflow solutions. Teams that treat cloud security as a pre-launch checklist end up dependent on defaults that were not designed for their environment.

What AI Readiness Skills Do Healthcare IT Teams Need?

AI use cases in healthcare — clinical decision support, ambient documentation, prior authorization automation, population health modeling — run on the data infrastructure that interoperability and governance teams build. AI readiness is downstream of data quality.

Key skills include:

• Feature engineering for clinical ML models using structured, terminologically consistent FHIR data
• Understanding how data quality problems upstream cause model degradation downstream
• Evaluating AI tools using clinical metrics: sensitivity, specificity, AUC-ROC, and performance across patient subgroups
• Identifying distributional shift in model input data
• Designing RAG architectures with correct access control — the model retrieves only what the querying user is authorized to see

McKinsey’s April 2026 survey found that 33% of healthcare organizations pursuing gen AI have adopted a buy strategy, up from 19% a year prior. Enterprise deployment is replacing pilots. McKinsey’s 2026 AI Trust Maturity Survey found that only one-third of organizations report maturity level three or higher in strategy, governance, and agentic AI governance. Most teams deploying AI are doing so without the guardrails in place.

Becker’s Hospital Review surveyed health system CIOs on 2026 priorities and found a consistent theme: success in 2026 depends less on launching new AI tools and more on scaling the right ones with discipline and governance. Olga Verevkina, Clinovera’s Operational Director, mentioned that the organization’s goal is “not to continue the same rate of growth in terms of the number of AI tools, but to broaden the impact of each across an enterprise.”

The execution model for building these systems is also changing. First Line Software’s RACE Programming framework — an AI-native delivery approach that replaces traditional Scrum with a 3-tier team structure — demonstrates how healthcare software delivery itself is being restructured around AI execution. Under RACE, the bottleneck shifts from code generation to specification quality: an AI Product and ACE Software Engineer layer (the “Pit Wall”) translates clinical and business requirements into Executable User Stories precise enough for AI to build correctly. For healthcare IT teams building FHIR integrations, prior authorization APIs, or RAG-based clinical tools, this matters directly — the specification discipline required by RACE is the same discipline that determines whether a Da Vinci PAS implementation or a FHIR-to-EHR pipeline behaves correctly in production. 

How Should Healthcare IT Teams Distribute These Skills Across Roles?

The distribution of skills across roles matters as much as their presence. Here is how these domains typically map:

Data governance is the most common staffing gap. When governance is left to integration engineers as a side task, FHIR data lands in cloud data lakes with no ownership, no terminology normalization, and no documented lineage.

Healthcare organizations that invested early in clean, connected data are widening the performance gap as AI deployment accelerates. Interoperability, governance, cloud, API security, and AI infrastructure are connected domains. Staffing them as sequential phases on a multi-year roadmap means that each phase inherits the unresolved problems of the one before it.

Last updated: July 2026