Technical documentation for the Med A-Z certified APIs under 45 CFR § 170.315(g)(7) and § 170.315(g)(10), including single-patient and population services. Published in accordance with § 170.315(g)(10)(viii) and § 170.404(a)(2). CHPL Product Number 15.05.05.3150.MDAZ.01.00.1.230616.

1. Standards and versions
2. Mandatory software components
3. Mandatory software configurations
4. Technical requirements and attributes for registration with the authorization server
5. TLS enforcement
6. Secure issuance of an initial refresh token to native applications
7. Supported scopes
8. US Core Choices and References supported
9. Additional data supported
10. API Terms and Conditions

API syntax, function names, required and optional parameters and their data types, return variables and their types and structures, and exceptions and exception handling methods are documented in the OpenAPI specifications below, meeting § 170.315(g)(10)(viii)(A)(1): single patient services, population services.

1. Standards and versions

Standard	Adopted at	Version
HL7® FHIR®	§ 170.215(a)(1)	Release 4, version 4.0.1
USCDI	§ 170.213	Version 3
US Core Implementation Guide	§ 170.215(b)(1)	STU 6.1.0
SMART App Launch Implementation Guide	§ 170.215(c)	Release 2.2.0 (SVAP)
Bulk Data Access (Flat FHIR®)	§ 170.215(d)	v2.0.0: STU 2 (SVAP)
OpenID Connect Core	§ 170.215(e)(1)	1.0 incorporating errata set 1

2. Mandatory software components

Required by § 170.315(g)(10)(viii)(A)(2). A client application must implement the following in order to interact with the API and process its responses.

• An HTTP client capable of negotiating TLS 1.2 or above
• A parser for application/fhir+json
• Handling for FHIR OperationOutcome resources returned in error responses
• A FHIR R4 (4.0.1) client capable of consuming US Core STU 6.1.0 profiles
• Retrieval and parsing of the CapabilityStatement at [base]/metadata
• Paging through search results using Bundle.link entries with relation next
• An OAuth 2.0 client implementing the authorization code grant (RFC 6749)
• PKCE (RFC 7636) using the S256 method, required for all client types under SMART App Launch 2.2.0
• Retrieval and parsing of [base]/.well-known/smart-configuration
• JWS verification of the OpenID Connect id_token using RS384
• Token introspection requests, supported per § 170.315(g)(10)(vii)

Additional components for population services

• Signing of a JWT client assertion using RS384, per SMART Backend Services
• A publicly reachable JWKS endpoint, or a public key in JWK format supplied at registration
• An NDJSON parser
• Asynchronous request handling: kick-off, status polling, observance of Retry-After, and retrieval of the files in the output manifest
• Handling for the requiresAccessToken, deleted, and error fields of the Bulk Data Access 2.0.0 output manifest

The group-export operation is supported. Support for optional Bulk Data Access 2.0.0 kick-off parameters is as follows: _type and _outputFormat are honored. The only accepted value for _outputFormat is application/fhir+ndjson; any other value is rejected with HTTP 400 and an OperationOutcome. _since, _typeFilter, _elements, includeAssociatedData and patient are not supported.

3. Mandatory software configurations

Required by § 170.315(g)(10)(viii)(A)(2).

Single patient services base URL	https://fhirapi.mhealthaz.com/fhir
Population services base URL	https://fhirbulk.mhealthaz.com

The service base URL is the value that must be supplied in the aud parameter on every authorization request. Authorization server endpoints — authorization, token, introspection and revocation — are discovered at runtime from https://fhirapi.mhealthaz.com/.well-known/smart-configuration and must not be hard-coded.

• client_id — issued at registration (see section 4)
• client_secret — issued only to confidential clients using symmetric authentication
• Redirect URI — registered in advance and matched by exact string comparison
• aud — must be set to the applicable service base URL on every authorization request
• launch — required for EHR launch; omitted for standalone launch
• Token endpoint authentication — client_secret_basic for confidential symmetric clients; private_key_jwt using RS384 for backend service clients
• Refresh tokens are issued valid for no less than three months, per § 170.315(g)(10)(v)(A)

4. Technical requirements and attributes for registration with the authorization server

Required by § 170.315(g)(10)(viii)(A)(3). Registration requests are submitted to salesinfo@medaz.net. Dynamic client registration is not supported.

Attribute	Applies to
Application name	All applications. Displayed to the user during authorization.
Application type	All applications. Confidential, public, or backend service.
Organization name and contact	All applications.
Redirect URI(s)	All applications except backend services. Matched by exact string comparison.
Requested scopes	All applications. See section 7.
Privacy policy URL	All applications. Displayed to the user during authorization.
Confirmation of ability to protect a client secret	Confidential clients using symmetric authentication.
Redirect URI type per RFC 8252, and attestation of ability to secure a refresh token	Native applications. See section 6.
JWKS URI or public key in JWK format, signed using RS384	Backend service clients.

A client_id is issued to every registered application. A client_secret is issued only to confidential clients using symmetric authentication.

5. TLS enforcement

Med A-Z enforces TLS version 1.2 or above on all connections to its FHIR service, authorization server, token endpoint and bulk data file endpoints, as required at § 170.315(g)(10)(iv).

• TLS 1.2 is the minimum protocol version accepted. Connection attempts negotiating TLS 1.1, TLS 1.0 or any version of SSL are rejected during the TLS handshake; the connection is terminated and no application data is transmitted or returned.
• The minimum version is enforced at the operating system settings level on the hosting server. The setting applies to all HTTPS bindings on the server, including the FHIR service, the authorization server, the token endpoint and the bulk data file endpoints.
• Requests received over unencrypted HTTP are redirected to HTTPS. No API function is available over an unencrypted connection.

6. Secure issuance of an initial refresh token to native applications

Published as required at § 170.315(g)(10)(v)(A)(1)(iii). The authorization server issues an initial refresh token valid for no less than three months to native applications capable of securing a refresh token. The methods supported are:

• PKCE (RFC 7636), S256 method. Required on all authorization code requests from native applications. Authorization codes are bound to the code_challenge supplied at the authorization request and are not exchanged without a matching code_verifier.
• Redirect URI validation per RFC 8252. Redirect URIs are registered in advance and matched by exact string comparison. Accepted redirect URI types: app-claimed HTTPS URIs (for example https://app.example.com/redirect) and private-use URI scheme redirects (for example com.example.app:/oauth2redirect). Loopback interface redirects (http://127.0.0.1:{port}/, http://[::1]:{port}/) are not accepted, because the ephemeral port assignment described at RFC 8252 § 7.3 is not compatible with the exact string matching applied to registered redirect URIs. A single redirect URI is registered per application.
• Confidential native clients. The authorization server supports the client-public and client-confidential-symmetric SMART client types. Native applications capable of protecting a client secret may register as confidential symmetric clients.

7. Supported scopes

Published as required at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2). Med A-Z supports the SMART App Launch 2.2.0 permission-v2 capability.

Capability set	Scopes
Patient access for standalone apps	openid, fhirUser, launch/patient, offline_access, patient/[Resource].rs
Clinician access for EHR launch	openid, fhirUser, launch, user/[Resource].rs
Population services	system/[Resource].r and system/*.r. The SMART v1 suffix .read is accepted as a synonym for .r.

Resources supported

The following FHIR resources are exposed, conformant to the corresponding US Core STU 6.1.0 profiles. The authoritative list is the CapabilityStatement at [base]/metadata.

AllergyIntolerance, CarePlan, CareTeam, Condition, Coverage, Device, DiagnosticReport, DocumentReference, Encounter, Goal, Group, Immunization, Location, Medication, MedicationDispense, MedicationRequest, Observation, Organization, Patient, Practitioner, PractitionerRole, Procedure, Provenance, Questionnaire, QuestionnaireResponse, RelatedPerson, ServiceRequest, Specimen.

8. US Core Choices and References supported

Published as required at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2). Where a US Core STU 6.1.0 “must support” element offers multiple Choices or References, those supported by Med A-Z are:

Element	Choices / References supported
Observation.value[x]	valueQuantity, valueCodeableConcept, valueString
Provenance.agent.who	Reference(Organization)
MedicationRequest.medication[x]	medicationCodeableConcept (RxNorm), medicationReference
MedicationRequest.reported[x]	reportedBoolean
DiagnosticReport.effective[x]	effectiveDateTime
Immunization.occurrence[x]	occurrenceDateTime
Goal.target.due[x]	dueDate
Observation.effective[x]	effectiveDateTime, effectivePeriod
Condition.onset[x]	onsetDateTime
Condition.abatement[x]	abatementDateTime
AllergyIntolerance.onset[x]	onsetDateTime
Procedure.performed[x]	performedDateTime
ServiceRequest.occurrence[x]	occurrencePeriod
Goal.start[x]	startDate
MedicationDispense.medication[x]	medicationCodeableConcept

9. Additional data supported

Published as required at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2). This section discloses data supported by Med A-Z beyond that required by the adopted standards and implementation specifications listed in section 1.

Med A-Z does not support additional data beyond the data classes and elements specified in USCDI v3 (§ 170.213) and the US Core Implementation Guide STU 6.1.0 (§ 170.215(b)(1)). No proprietary extensions, non-standard search parameters or additional resource types are exposed through the API. The authoritative list of supported resources, profiles, search parameters and operations is the CapabilityStatement at [base]/metadata.

Group is exposed to support the group-export operation defined by the Bulk Data Access IG (§ 170.215(d)). Questionnaire and QuestionnaireResponse are exposed to support § 170.315(a)(15) social, psychological and behavioral data. Neither is a USCDI v3 data class.

10. API Terms and Conditions

Published as required by the API Condition of Certification at 45 CFR § 170.404(a)(2). These terms apply to all use of the Med A-Z Standardized API for Patient and Population Services certified to § 170.315(g)(10), CHPL Product Number 15.05.05.3150.MDAZ.01.00.1.230616. They are published in full on this page and are accessible without registration, login, or execution of any agreement.

Last updated: 08/01/2026. Enquiries: salesinfo@medaz.net.

10.1 Registration and access

• Registration is requested by email to salesinfo@medaz.net. The attributes required at registration are listed in section 4. Dynamic client registration is not supported.
• MedAZ.Net, LLC responds to a complete registration request within 3 business days and issues production credentials within 2 business days of approval.
• Registration is granted on the same terms to all application developers. Approval is not conditioned on a commercial relationship with MedAZ.Net, LLC, on the developer being a customer, or on the application not competing with any MedAZ.Net, LLC product or service.
• A registration request may be declined only where the request is incomplete, where the applicant cannot be verified, or on the grounds set out in section 10.5. Where a request is declined the applicant is given the reason in writing and may resubmit.
• Access to a production deployment additionally requires the authorization of the healthcare organization that controls that deployment. MedAZ.Net, LLC does not withhold access on any basis other than those stated in these terms.

10.2 Fees

Fees are charged in accordance with 45 CFR § 170.404(a)(3) and are based on objective and verifiable criteria applied uniformly to all similarly situated application developers.

Activity	Fee
Access to this documentation and to the OpenAPI specifications	No charge
Registration of an application and issuance of credentials	No charge
Use of the API by a registered application, including all patient-facing and population services API calls	No charge
Self-service integration using the published documentation	No charge
Developer support requiring MedAZ.Net, LLC personnel — assisted integration, custom troubleshooting, consultation or bespoke development	$150 per hour. Quoted and agreed in writing in advance of any work. Charged only where the developer requests assisted support; never a precondition of API access.

The hourly rate above is applied uniformly to all similarly situated application developers. It is reviewed annually and any change is published on this page not less than 30 days before taking effect. No fee is charged to a patient, or to any application acting on a patient’s behalf, for access to that patient’s electronic health information.

10.3 Permitted use

• A registered application may access electronic health information through the API only within the scopes granted to it, and only for the purposes disclosed to the authorizing user at the time of authorization.
• Applications must present accurate identifying information at registration and must not misrepresent their identity, publisher, or purpose to users during authorization.
• Applications must honor the scope of the authorization granted. Data obtained under one authorization must not be used for a purpose the authorizing user was not informed of.
• Applications must maintain a publicly accessible privacy policy, disclosed at registration and displayed to users during authorization.
• Applications must protect credentials and tokens. Client secrets and private keys must not be embedded in distributed public client code. Refresh tokens must be stored securely as attested at registration.
• Applications must support revocation of authorization by the patient and must cease use of revoked tokens.

10.4 Technical limitations

Published as required by 45 CFR § 170.404(a)(2). The limitations below apply to the certified API. Where a healthcare organization operating a Med A-Z deployment imposes additional restrictions of its own, those are outside MedAZ.Net, LLC's control and are not described here.

Rate limits and quotas

MedAZ.Net, LLC does not apply rate limits, request quotas, or concurrent-request caps to the certified API. No limit is placed on the number of API calls an application may make, and no application is throttled on the basis of its identity, its developer, or its volume of use.

Search result paging

Search interactions return results in pages. An application may request a page size using the _count parameter. Where results span more than one page, the response Bundle includes a next link, and an application must follow those links to retrieve the complete result set.

Bulk data export

• Export is asynchronous. A kick-off request returns HTTP 202 with a Content-Location header; the application polls that URL until the export completes.
• Poll responses carry a Retry-After header of 10 seconds. Applications are expected to honor it.
• No maximum export size is enforced. Export duration and output size scale with the volume of data held in the deployment.
• Output file retention. Output files are available for 24 hours after an export completes. Files are removed immediately when an application issues DELETE to the status URL, and are removed automatically once the retention period elapses. Requests for a file after removal return HTTP 404. Applications should retrieve output promptly and should issue DELETE once retrieval is complete.
• Output is NDJSON. application/fhir+ndjson is the only accepted value for _outputFormat. Supported and unsupported kick-off parameters are listed in section 2.

Availability and maintenance

Operating system updates are applied on Sundays within a maintenance window of 7:00 pm to 10:00 pm US Eastern Time. Actual interruption to API availability is typically 15 to 30 minutes within that window; the full three-hour period is reserved to allow for updates that take longer than expected. Other maintenance is performed as needed; where planned work is expected to interrupt availability, advance notice is given to the healthcare organization operating the affected deployment. MedAZ.Net, LLC does not currently publish a public status page or offer a guaranteed service level for the API.

Applications should handle transient unavailability by retrying with an appropriate backoff. An in-progress bulk export is not affected by a restart of the export service; the job resumes and the application may continue polling the status URL it was issued.

Deployment-specific limitations

Each Med A-Z deployment is operated by the healthcare organization it serves. The data available through the API is limited to that organization's records, and the service base URL for each deployment is published at fhir.mhealthaz.com as required by 45 CFR § 170.404(b)(2).

10.5 Suspension and termination

Access may be suspended or terminated only where an application:

• presents a demonstrable security risk to the API, to a deployment, or to patient information;
• accesses or attempts to access data outside the scopes granted to it;
• materially breaches these terms;
• has its authorization revoked by the patient or by the healthcare organization controlling the deployment; or
• is used in violation of applicable law.

Except where an immediate security risk requires otherwise, MedAZ.Net, LLC gives written notice of the reason before suspending or terminating access, and a reasonable opportunity to remedy. Where access is suspended without prior notice on security grounds, written notice of the reason is given promptly. Access is restored once the reason for suspension is resolved.

10.6 Non-discrimination

Consistent with 45 CFR § 170.404(a)(1) and (a)(4), MedAZ.Net, LLC grants API access on terms no less favorable than those it extends to itself, to its own applications, and to its affiliates. Registration, fees, technical support, service levels and access to documentation do not vary according to whether an application competes with a MedAZ.Net, LLC product or service, whether the developer is a MedAZ.Net, LLC customer, or the identity of the developer.

MedAZ.Net, LLC does not require an application developer to enter into a commercial agreement, exclusivity arrangement, or non-compete as a condition of API access, and does not impose conditions that would constitute information blocking under 45 CFR Part 171.

10.7 Changes to these terms

Material changes are published on this page not less than 30 days before taking effect. The date of last update is shown at the head of this section.

10.8 Contact and escalation

Questions, registration requests and disputes regarding these terms: salesinfo@medaz.net.