B2B Integration for Australian Healthcare FHIR
Australian healthcare B2B integration requires secure authentication using NASH PKI certificates, mutual TLS (mTLS), and integration with government health services including PRODA, HPOS, and the HI Service. This module covers the complete B2B integration stack for FHIR implementations.
B2B connections in Australian healthcare include My Health Record API access, HI Service identifier lookups, eRequesting integrations, and secure FHIR API connections between healthcare organizations.
NASH Certificate Security
NASH certificates and private keys must be stored securely. Never hardcode certificates in source code. Use AWS Secrets Manager with encryption and strict access controls.
- NASH PKI: National Authentication Service for Health certificates
- mTLS: Mutual TLS for strong authentication
- PRODA: Provider Digital Authentication
- HPOS: Health Professional Online Services
- HI Service: Healthcare Identifiers (IHI, HPI-I, HPI-O)
- AWS Secrets Manager: Secure certificate storage
NASH PKI Certificates
NASH (National Authentication Service for Health) is the PKI infrastructure that authenticates healthcare providers and organizations accessing Australian digital health services including My Health Record and HI Service.
NASH Certificate Types
NASH certificate types and use cases
| Type | Linked Identifier | Use Case |
|---|---|---|
| Organization | HPI-O | Organization-level access (clinic, hospital) |
| Individual | HPI-I | Practitioner-level access (doctor, nurse) |
| Device | HPI-A or system ID | System-to-system authentication |
NASH Certificate Structure
NASH PKI certificate hierarchy
Loading diagram...
Certificate Lifecycle
NASH certificate lifecycle phases
| Phase | Description | Duration | Requirements |
|---|---|---|---|
| Application | Submit application via ACMS with required documentation | 5-10 business days | HPI-O, proof of identity, organization details |
| Issuance | Certificate issued by HPOS PKI CA | Immediate upon approval | Application approved, fees paid |
| Installation | Install certificate in application/system | 1-2 hours | Private key secured, certificate chain configured |
| Usage | Active authentication for B2B connections | Up to 3 years | Regular validation, secure storage |
| Renewal | Apply for renewal before expiration | Start 60 days before expiry | Updated documentation if changed |
| Revocation | Revoke if compromised or no longer needed | Immediate | Report via ACMS, CRL updated |
ACMS Portal
The Authenticated Client Management Service (ACMS) portal is used to apply for, manage, and revoke NASH certificates. Organizations must maintain an ACMS administrator.
Certificate Requirements
- Valid HPI-O for organization certificates
- Proof of identity for authorized contacts
- Organization registration details (ABN, address)
- Completed application forms
- Payment of certificate fees
- Agreement to NASH PKI Certificate Policy
Mutual TLS (mTLS) Authentication
Mutual TLS (mTLS) requires both client and server to present and validate certificates, providing strong authentication for B2B FHIR connections.
mTLS Handshake Process
mTLS trust chain for B2B authentication
Loading diagram...
mTLS Implementation Steps
mTLS Handshake and Authorization Sequence
Loading diagram...
- Obtain NASH certificate from HPOS PKI CA
- Configure server trust store with HPOS CA certificate
- Client presents NASH certificate during TLS handshake
- Server validates certificate chain to HPOS root CA
- Server extracts HPI-O/HPI-I from certificate subject
- Server authorizes based on identifier and permissions
- FHIR API access granted upon successful authentication
AWS API Gateway mTLS
API Gateway mTLS Architecture
Loading diagram...
API Gateway mTLS for HTTP APIs is typically modeled with a Regional custom domain, an S3 trust store, and a backend integration rather than a CloudFront TCP pass-through:
- Upload HPOS CA certificate to S3 trust store
- Configure API Gateway domain with mTLS
- Reference S3 trust store URI
- API Gateway validates client certificates automatically
- Extract certificate subject for authorization
- Integrate with Lambda authorizer for fine-grained access
Terraform: API Gateway mTLS
# API Gateway with mutual TLS authentication
resource "aws_apigatewayv2_api" "fhir_mtls" {
name = "fhir-mtls-api"
protocol_type = "HTTP"
tags = {
Name = "fhir-mtls-api"
}
}
# S3 bucket for trust store (NASH CA certificates)
resource "aws_s3_bucket" "trust_store" {
bucket = "fhir-trust-store-${data.aws_caller_identity.current.account_id}"
tags = {
Name = "fhir-trust-store"
}
}
resource "aws_s3_object" "nash_ca_cert" {
bucket = aws_s3_bucket.trust_store.id
key = "nash-ca.crt"
source = "${path.module}/certs/nash-ca.crt"
etag = filemd5("${path.module}/certs/nash-ca.crt")
}
# API Gateway mutual TLS configuration
resource "aws_apigatewayv2_api_mapping" "mtls_config" {
api_id = aws_apigatewayv2_api.fhir_mtls.id
domain_name = aws_apigatewayv2_domain_name.fhir_domain.id
}
resource "aws_apigatewayv2_domain_name" "fhir_domain" {
domain_name = "fhir.example.com"
domain_name_configuration {
certificate_arn = aws_acm_certificate.fhir_cert.arn
endpoint_type = "REGIONAL"
security_policy = "TLS_1_2"
}
mutual_authentication {
truststore_uri = "s3://${aws_s3_bucket.trust_store.id}/nash-ca.crt"
truststore_version_id = aws_s3_object.nash_ca_cert.version_id
ignore_expired_client_certificates = false
}
}
# ACM certificate for domain
resource "aws_acm_certificate" "fhir_cert" {
domain_name = "fhir.example.com"
validation_method = "DNS"
tags = {
Name = "fhir-api-cert"
}
}Certificate Validation
Always validate certificate expiration dates and check Certificate Revocation Lists (CRL). Expired or revoked certificates should be rejected.
Healthcare Identifiers (HI Service)
The Healthcare Identifiers (HI) Service issues unique identifiers for patients, healthcare providers, and organizations, enabling consistent identification across the Australian healthcare system.
Identifier Types
Healthcare identifier types
| Type | Full Name | Format | Scope | Use Case |
|---|---|---|---|---|
| IHI | Individual Healthcare Identifier | 16 digits (e.g., 8003608000327161) | Patients and healthcare recipients | Patient identification across systems |
| HPI-I | Healthcare Provider Identifier - Individual | 16 digits starting with 800361 (e.g., 8003619900015712) | Individual healthcare providers | Provider identification in eReferrals, prescriptions |
| HPI-O | Healthcare Provider Identifier - Organization | 16 digits starting with 800362 (e.g., 8003620000012345) | Healthcare organizations | Organization identification for MHR, eRequesting |
| HPI-A | Healthcare Provider Identifier - Device | 16 digits starting with 800363 | Medical devices and systems | Device identification for IoMT |
HI Service API
The HI Service provides SOAP and REST APIs for identifier lookups:
- Get Individual: Lookup patient by IHI
- Get Provider: Lookup practitioner by HPI-I
- Get Organization: Lookup organization by HPI-O
- Verify Identifier: Validate identifier format and status
- Search: Find identifiers by demographic details
HI Service Integration Requirements
- NASH certificate (organization or individual)
- PRODA account linked to HPI-I/HPI-O
- HI Service subscription via ACMS
- Conformant software (tested and approved)
- mTLS configuration for API calls
- Audit logging for all identifier accesses
IHI Lookup Use Case
When a patient presents, lookup their IHI using name, date of birth, and Medicare number. Store the IHI in your FHIR Patient resource identifier field for consistent identification.
FHIR Patient with IHI
Structured JSON example rendered with depth controls for easier inspection.
Click on an annotation to highlight it in the JSON
PRODA and HPOS
PRODA (Provider Digital Authentication) and HPOS (Health Professional Online Services) are essential for managing healthcare provider access to Australian government health services.
PRODA: Provider Digital Authentication
PRODA provides secure authentication for:
- HPOS portal access
- My Health Record online portal
- Medicare Online for organizations
- HI Service management
- NASH certificate management (ACMS)
PRODA Account Types
PRODA account types
| Type | For | Authentication |
|---|---|---|
| Individual | Healthcare practitioners | Username/password + MFA |
| Organization | Healthcare organizations | PRODA + NASH certificate |
HPOS: Health Professional Online Services
HPOS portal provides access to:
- Healthcare Identifiers management
- NASH certificate applications (ACMS)
- Medicare provider number management
- eHealth record access management
- Organization and practitioner registration
PRODA Linking
Individual practitioners must link their PRODA account to their HPI-I. Organizations must link PRODA to their HPI-O. This linking is required for NASH certificate applications.
Integration Flow
PRODA/HPOS Integration and NASH Issuance
Loading diagram...
- Practitioner creates PRODA account
- Link PRODA to HPI-I (verified via AHPRA or other board)
- Organization creates PRODA account
- Link PRODA to HPI-O (verified via ABN)
- Apply for NASH certificates via ACMS in HPOS
- Use NASH certificates for B2B API authentication
AWS Secrets Manager for Certificates
AWS Secrets Manager provides secure storage for NASH certificates and private keys with encryption, access controls, and automatic rotation capabilities.
Secrets Manager Benefits
- Encryption at rest using KMS
- Fine-grained IAM access controls
- Automatic rotation (for supported secrets)
- Audit logging via CloudTrail
- Version management
- Cross-region replication
- Integration with Lambda, RDS, DocumentDB
Certificate Storage Best Practices
- Store certificate and private key together as JSON
- Encrypt using customer-managed KMS key (CMK)
- Restrict access to specific Lambda functions
- Enable CloudTrail logging for all access
- Implement rotation procedure before expiry
- Never log or expose private key values
- Use IAM conditions for additional restrictions
Terraform: Secrets Manager for NASH
# AWS Secrets Manager for NASH certificates
resource "aws_secretsmanager_secret" "nash_certificates" {
name = "nash-certificates"
description = "NASH PKI certificates for FHIR B2B integration"
kms_key_id = aws_kms_key.fhir_data.arn
recovery_window_in_days = 30
tags = {
Name = "nash-certificates"
Compliance = "IRAP-PROTECTED"
Purpose = "B2B Authentication"
}
}
resource "aws_secretsmanager_secret_version" "nash_certificates" {
secret_id = aws_secretsmanager_secret.nash_certificates.id
secret_string = jsonencode({
organization_certificate = file("${path.module}/certs/nash-org.crt")
organization_private_key = file("${path.module}/certs/nash-org.key")
hpos_ca_certificate = file("${path.module}/certs/hpos-ca.crt")
certificate_passphrase = var.nash_cert_passphrase
})
}
# IAM policy for Lambda to access NASH certificates
resource "aws_iam_policy" "nash_cert_access" {
name = "nash-certificate-access"
description = "Allow Lambda to retrieve NASH certificates from Secrets Manager"
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
]
Resource = aws_secretsmanager_secret.nash_certificates.arn
},
{
Effect = "Allow"
Action = [
"kms:Decrypt"
]
Resource = aws_kms_key.fhir_data.arn
}
]
})
}
# Lambda function to retrieve NASH certificate
data "aws_lambda_invocation" "get_nash_cert" {
function_name = aws_lambda_function.get_certificate.function_name
input = jsonencode({
secret_name = aws_secretsmanager_secret.nash_certificates.name
})
}Lambda Certificate Retrieval
Lambda functions retrieve certificates at runtime:
import { SecretsManagerClient, GetSecretValueCommand } from '@aws-sdk/client-secrets-manager';
const secretsClient = new SecretsManagerClient({});
export async function getNashCertificate() {
const command = new GetSecretValueCommand({
SecretId: 'nash-certificates'
});
const response = await secretsClient.send(command);
const secret = JSON.parse(response.SecretString!);
return {
certificate: secret.organization_certificate,
privateKey: secret.organization_private_key,
caCertificate: secret.hpos_ca_certificate
};
}Certificate Expiry Monitoring
Implement CloudWatch alarms to monitor certificate expiration. Set alerts at 60, 30, and 7 days before expiry to allow time for renewal.
AWS Secrets Manager Documentation
Secure storage and rotation for NASH certificates and credentials
Read moreB2B Integration Patterns
Different B2B integration patterns suit different use cases, from direct mTLS connections to private network links.
Integration Patterns
B2B integration patterns comparison
| Pattern | Description | Use Case | AWS Services |
|---|---|---|---|
| Direct mTLS | Client and server authenticate via NASH certificates | My Health Record API, HI Service | API Gateway mTLS, NLB with mutual auth |
| OAuth 2.0 + mTLS | mTLS for client authentication, OAuth for authorization | SMART on FHIR with NASH | Cognito + API Gateway mTLS |
| PrivateLink | Private connectivity without public internet exposure | Healthcare partner integrations | VPC Endpoint, PrivateLink |
| VPN Tunnel | Site-to-site VPN for dedicated connections | Hospital to cloud FHIR server | AWS Site-to-Site VPN, Transit Gateway |
My Health Record API Integration
Requirements for MHR API access:
- Organization NASH certificate
- HPI-O for the organization
- PRODA account linked to HPI-O
- Conformant software certification
- mTLS configuration
- MHR API subscription via ACMS
AWS PrivateLink for Healthcare
PrivateLink enables private connectivity:
- No public internet exposure
- Traffic stays within AWS network
- VPC endpoint for service access
- Security group controls
- Reduced attack surface
Recommended Pattern
For most Australian healthcare B2B integrations, use mTLS + OAuth 2.0 pattern: mTLS for client authentication (NASH), OAuth for authorization (scopes), and PrivateLink for network isolation.
NASH Certificate Automation
NASH certificate lifecycle management requires automated processes for renewal, rotation, and monitoring to prevent service disruptions from expired certificates.
NASH PKI Certificate Lifecycle
NASH certificate lifecycle phases and automation
| Phase | Duration | Automation Opportunity | AWS Service |
|---|---|---|---|
| Application | 5-10 business days | Workflow automation via ACMS API (manual approval required) | Step Functions |
| Issuance | Immediate | Automated download from ACMS portal | Lambda |
| Installation | 1-2 hours | Automated deployment to Secrets Manager | Secrets Manager |
| Active Usage | Up to 3 years | Continuous monitoring and validation | CloudWatch, EventBridge |
| Renewal | Start 60 days before expiry | Automated renewal workflow with alerts | EventBridge, Lambda, SNS |
| Revocation | Immediate | Automated CRL check, alert on revocation | Lambda, GuardDuty |
mTLS Configuration for B2B Gateway
API Gateway mTLS configuration with NASH certificate validation:
- Upload HPOS CA certificate to S3 trust store
- Configure API Gateway domain with mutualAuthentication
- Reference S3 trust store URI in domain configuration
- API Gateway validates client certificates automatically
- Extract HPI-O/HPI-I from certificate subject for authorization
- Integrate with Lambda authorizer for fine-grained access control
NASH certificate flow in B2B gateway
Loading diagram...
Lambda for Certificate Rotation
Automated certificate rotation Lambda function:
import { SecretsManagerClient, GetSecretValueCommand, UpdateSecretCommand } from '@aws-sdk/client-secrets-manager';
import { ACMSClient, RenewCertificateCommand } from '@aws-sdk/client-acms';
const secretsClient = new SecretsManagerClient({});
const acmsClient = new ACMSClient({ region: 'ap-southeast-2' });
export async function rotateNashCertificate(event: any) {
const secretName = 'nash-certificates';
// Check certificate expiry
const secret = await secretsClient.send(new GetSecretValueCommand({ SecretId: secretName }));
const certData = JSON.parse(secret.SecretString!);
const expiryDate = parseCertificateExpiry(certData.organization_certificate);
const daysUntilExpiry = (expiryDate.getTime() - Date.now()) / (1000 * 60 * 60 * 24);
if (daysUntilExpiry <= 60) {
console.log(`Certificate expires in ${daysUntilExpiry.toFixed(0)} days. Initiating renewal.`);
// Initiate renewal via ACMS
const renewal = await acmsClient.send(new RenewCertificateCommand({
certificateId: certData.certificate_id
}));
// Download new certificate
const newCert = await downloadNewCertificate(renewal.certificateId);
// Update Secrets Manager
await secretsClient.send(new UpdateSecretCommand({
SecretId: secretName,
SecretString: JSON.stringify({
...certData,
organization_certificate: newCert.certificate,
organization_private_key: newCert.privateKey,
renewed_at: new Date().toISOString()
})
}));
// Notify team
await sendSNSNotification('NASH certificate renewed successfully');
}
return { statusCode: 200, body: 'Rotation check complete' };
}Secrets Manager for Certificate Storage
Secure certificate storage with rotation configuration:
- Store certificate, private key, and HPOS CA as JSON secret
- Encrypt with customer-managed KMS key (CMK)
- Enable automatic rotation (custom Lambda for NASH)
- Restrict access via IAM policies to specific Lambda functions
- Enable CloudTrail logging for all secret access
- Implement versioning for rollback capability
Monitoring and Alerting
CloudWatch alarms for certificate expiry monitoring:
- 60-day warning: Initial renewal notification
- 30-day warning: Escalate to operations team
- 7-day critical: Emergency renewal required
- 1-day critical: Page on-call engineer
- Post-renewal verification: Confirm new certificate active
resource "aws_cloudwatch_metric_alarm" "nash_cert_60day" {
alarm_name = "nash-certificate-expiry-60days"
comparison_operator = "LessThanThreshold"
evaluation_periods = 1
metric_name = "CertificateExpiryDays"
namespace = "FHIR/Security"
period = 86400
statistic = "Minimum"
threshold = 60
alarm_description = "NASH certificate expires in less than 60 days"
alarm_actions = [aws_sns_topic.certificate_alerts.arn]
dimensions = {
CertificateType = "NASH-Organization"
Environment = "production"
}
}Certificate Renewal Best Practices
Start renewal 60 days before expiry. Test new certificate in staging before production. Maintain rollback capability. Never let certificates expire in production.
Summary & Key Takeaways
Australian healthcare B2B integration requires NASH PKI certificates, mTLS authentication, and integration with government services (PRODA, HPOS, HI Service). AWS provides secure infrastructure for certificate storage and API management.
Core Concepts Recap
- NASH PKI: Certificate-based authentication for healthcare
- mTLS: Mutual authentication for B2B connections
- PRODA: Digital authentication for providers
- HI Service: IHI, HPI-I, HPI-O identifiers
- Secrets Manager: Secure certificate storage
- PrivateLink: Private network connectivity
Implementation Checklist
- Obtain HPI-O for organization
- Create PRODA account and link to HPI-O
- Apply for NASH certificates via ACMS
- Store certificates in Secrets Manager
- Configure API Gateway with mTLS
- Implement certificate validation
- Set up expiry monitoring alarms
- Test with MHR conformance environment
Next Steps
After understanding B2B integration, explore SMART on FHIR authorization, clinical terminologies (SNOMED CT-AU, AMT), and real-world implementation patterns.
Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.