# Health Information Exchange API Documentation > REST APIs for Kenya's national Health Information Exchange (HIE), the middleware through which hospital systems verify patient coverage, capture patient consent, and submit healthcare claims to the Social Health Authority (SHA). The documented surface is 94 operations across 77 paths in six services: Authentication, Registries, eClaims and Preauth, Consent, Shared Health Record, and Terminology. Every endpoint is versioned under /api/v1 and takes a Bearer token obtained from the Authentication service. These docs and every published spec describe the UAT environment at https://ilm-dev.dha.go.ke/uat-middleware/api/v1; no production server is declared. Most integrations start the same way, whichever service they end at: obtain a token, resolve the patient in the Client Registry, then check eligibility and benefit coverage before doing anything else. If you are integrating a claims or visit flow, read the Integration Scenarios overview first - it maps a clinical case to an ordered sequence of calls across four services and will save you guessing which of eight paths you are on. Each page below is linked as markdown. Replace the .md suffix with nothing to get the rendered HTML page, which carries the same content at roughly twenty times the size. ## Start Here Orientation, in reading order. Four pages, none of them API reference. Read these if you do not yet know what the HIE is or how an integration is expected to reach production; skip straight to a service section if you do. - [Introduction to HIE](/introduction.md): What the HIE is and which four APIs you will actually call; start here if you have read nothing else. - [Understanding Health Information Exchange](/understandHIE.md): The why behind the platform, framed around a patient's journey across facilities. Concepts only, no endpoints. - [User Journeys & Workflows](/docs/userJourney.md): The integration journey from first token to production traffic. - [Going Live with Your HIE Integration](/docs/goLive.md): What has to be true before you are allowed into production. ## API Specifications The full OpenAPI 3.0.3 contract for every service, and the fastest way to learn a request or response shape. 94 operations across 77 paths in six documents. All six declare a single server, the UAT environment at https://ilm-dev.dha.go.ke/uat-middleware/api/v1, so code generated straight from these points at UAT and not production. Read a spec before reading the guides; the prose pages explain call ordering and business rules that a spec cannot. - [Authentication](/specs/auth.json): 1 operation: exchange client credentials for the Bearer token every other call needs. - [Registries](/specs/registries.json): 3 operations across the client, facility and health-worker registries; resolve a patient here before anything else. - [eClaims and Preauth](/specs/eclaims.json): 53 operations across 41 paths, the largest surface: eligibility, visits, preauths, billing, emergency claims and dispatch. - [Consent Services](/specs/consent.json): 22 operations covering OTP and biometrics authorization, including the separate flow for minors. - [Shared Health Record](/specs/shr.json): 13 operations, FHIR-shaped, for reading and contributing to a patient's shared record. - [Terminology Service](/specs/terminology.json): 2 operations for resolving a local code to an HIE concept. ## Authentication 6 pages covering the one operation every other call depends on: exchanging client credentials for a Bearer token at POST /api/v1/tenants/token. Read before anything else, because a misconfigured facility identifier here surfaces as confusing failures much later in a claim. - [Introduction to Authentication](/docs/authentication/getting-started/intro.md) - [Security Best Practices](/docs/authentication/guides/best-practices.md) - [Troubleshooting Authentication](/docs/authentication/guides/troubleshooting.md) - [API Key Management](/docs/authentication/process/api-keys.md) - [Facility Identification](/docs/authentication/process/facility-identification.md) - [OAuth 2.0 Flow](/docs/authentication/process/oauth-flow.md) ## Integration Scenarios Nine pages that turn a clinical case into an ordered sequence of API calls across four services — 21 distinct endpoints, every one of which exists in both the published specs and the code-generated spec. Start at the overview: four fields on a single intervention-coverage response select exactly one of scenarios 1-6, and choosing wrong means calling the wrong dispatch endpoint at the end of the visit. Background: SHA is Kenya's Social Health Authority, and which of its funds covers the intervention is the first branch — SHIF (Social Health Insurance Fund), UHC (Universal Health Coverage) and PHC (Primary Healthcare Fund), or ECCIF (Emergency, Chronic and Critical Illness Fund). IP is inpatient, OP is outpatient, KEPH levels 2-6 grade a facility's capability. - [Scenarios Overview](/docs/scenarios/overview.md): The decision matrix; open this before any scenario page. Five prerequisite calls every visit shares (token, patient search, eligibility, sub-benefits, interventions), then a flowchart that picks scenarios 1-6 from four fields on one intervention. Emergency (7, 8) is deliberately not on that flowchart — it is chosen at presentation, not from flags. The OTP and biometrics consent flows are documented here once and are identical across all eight scenarios. - [Scenario 1: SHIF - Inpatient - Per Diem - No Preauth](/docs/scenarios/scenario-1-shif-ip-per-diem.md): Open when the intervention comes back PER_DIEM with needsPreauth false. The one path where you must not send a line item — it is generated from the accrued days — and where unit_price serves only as a check against your facility's KEPH-level tariff; exceed it and the whole billing request is rolled back. A claim may hold one active per-diem intervention at a time, so a ward transfer is a switch, not an add. - [Scenario 2: SHIF - Inpatient - Fee for Service - Normal/Special Preauth](/docs/scenarios/scenario-2-shif-ip-ffs-normal-preauth.md): Inpatient fee-for-service where the preauth is raised inside the visit (needsPreauth true, needsManualPreauthApproval false). Read it before writing billing code: POST /claims/lines is rejected until the preauth reaches FINALISED. It also picks which of the six preauth forms to submit — POST /preauths is a oneOf over normal, surgical, renal, oncology, optical and imaging. - [Scenario 3: SHIF - Inpatient - Fee for Service - Elective Preauth](/docs/scenarios/scenario-3-shif-ip-ffs-elective-preauth.md): needsManualPreauthApproval true with accessPoint IP: the preauth is raised and approved days before admission, against a consent token from POST /claims/authorize rather than from a claim. The part worth reading is the day of admission — no fresh authorization is created, and reusing the same patient_id and intervention_code is the only thing that links the approved preauth to the new claim. - [Scenario 4: SHIF - Outpatient - Fee for Service - Elective Preauth](/docs/scenarios/scenario-4-shif-op-ffs-elective-preauth.md): The outpatient twin of Scenario 3 — read that page for the pre-visit half, this one for the day of visit. Differs only in service_type OUTPATIENT and a visit-end POST /claims/submit carrying discharge_reason, which is rejected outright when no doctor is attached to the claim. - [Scenario 5: SHIF - Outpatient - Fee for Service - Normal/Special Preauth](/docs/scenarios/scenario-5-shif-op-ffs-normal-preauth.md): The outpatient twin of Scenario 2, identical up to dispatch. Worth opening for the discharge_reason set at submit: RECOVERED, REFERRED, ABSCONDED or OTHER. DECEASED is not one of them — it exists only on the inpatient POST /claims/discharge, whose reason set is a different enum. - [Scenario 6: UHC - Outpatient - Capitation](/docs/scenarios/scenario-6-uhc-op-capitation.md): The only capitation path and the only non-SHIF, non-emergency one: paymentMechanism CAPITATION under Universal Health Coverage, with no preauth step anywhere in the flow. Also the page for Primary Healthcare Fund visits at KEPH levels 2 and 3 and some level 4, where attachments are not required on POST /claims/lines. - [Scenario 7: ECCIF - Emergency - Identified Patient](/docs/scenarios/scenario-7-eccif-emergency-identified.md): Emergency care under ECCIF with the patient identified at presentation. Read it because almost nothing from the ordinary flow carries over: no eligibility check, no preauth, exactly one intervention per claim, billing against approved protocol tariffs instead of free-form lines, OTP consent only with no biometrics path, and submission within 24 hours. Submission is gated on the claim's doctor consent reaching APPROVED. - [Scenario 8: ECCIF - Emergency - Unidentified Patient](/docs/scenarios/scenario-8-eccif-emergency-unidentified.md): Scenario 7 for a patient who cannot be identified. The mechanic worth reading for: identifying them later re-POSTs /claims/emergency with the original payload plus beneficiary_cr_id, otp and the existing consent_token, and the protocols already added survive. If the patient is still unknown at submit, reason_for_unknown_patient becomes required and accepts only SHA_UNREGISTERED or DECEASED. ## Claims and Preauths 86 pages, the largest section, backing 53 operations. Three groups: getting-started (1 page), guides (23 pages, the conceptual and rules material), and process (62 pages, one per API step). The process pages are reference: open a specific one when you know the step you need, rather than reading through. If you do not yet know which claim path you are on, read the Integration Scenarios overview first. - [Introduction to Claims](/docs/claims/getting-started/introduction.md) - [Adding Attachments](/docs/claims/guides/adding-attachments.md) - [Adding a Claim Doctor](/docs/claims/guides/adding-claim-doctor.md) - [Benefits & Intervention Codes](/docs/claims/guides/benefit-intervention-codes.md) - [Benefit Matrix Guide](/docs/claims/guides/benefit-matrix.md) - [Special Benefit Rules](/docs/claims/guides/benefit-rules.md) - [Critical Care Rules](/docs/claims/guides/benefit-rules/critical-care.md) - [Medical Imaging Rules](/docs/claims/guides/benefit-rules/imaging.md) - [Inpatient Benefit Rules](/docs/claims/guides/benefit-rules/inpatient.md) - [Maternity Benefit Rules](/docs/claims/guides/benefit-rules/maternity.md) - [Rehabilitation for Drug and Substance Abuse](/docs/claims/guides/benefit-rules/substance-abuse-rehab.md) - [Surgical Rules](/docs/claims/guides/benefit-rules/surgical.md) - [Claim Resubmission](/docs/claims/guides/claim-resubmission.md) - [Terms of Use](/docs/claims/guides/common-scenarios.md) - [The Deceased Patient Workflow](/docs/claims/guides/deceased-workflow.md) - [Terms of Use](/docs/claims/guides/error-handling.md) - [Partial and Full Discharge](/docs/claims/guides/partial-and-full-discharge.md) - [PMF Tariffs](/docs/claims/guides/pmf-tariffs.md) - [Intervention Combination Rules](/docs/claims/guides/sha-combination-rules.md) - [Status Callbacks](/docs/claims/guides/status-callbacks.md) - [Understanding Virtual Claims](/docs/claims/guides/understandingClaims.md) - [Claim Lifecycle & Statuses](/docs/claims/guides/understandingClaimStatuses.md) - [Understanding Preauthorizations](/docs/claims/guides/understandingPreauths.md) - [Preauthorization Lifecycle & Statuses](/docs/claims/guides/understandingPreauthStatuses.md) - [Billing Workflows Process Guide: Add Attachment Workflow](/docs/claims/process/billing/addAttachment.md) - [Billing Workflows Process Guide: Add Combined Billing Details Workflow](/docs/claims/process/billing/addCombinedBillingDetails.md) - [Billing Workflows Process Guide: Add Diagnosis Workflow](/docs/claims/process/billing/addDiagnosis.md) - [Billing Workflows Process Guide: Add new line Workflow](/docs/claims/process/billing/addNewLine.md) - [Billing Workflows Process Overview: Streamlining Financial Transactions in Healthcare](/docs/claims/process/billing/billingProcessOverview.md) - [Edit Claim Line Workflow Guide](/docs/claims/process/billing/editClaimLine.md) - [Preview Payer Claim Workflow Guide](/docs/claims/process/billing/previewPayerClaim.md) - [Preview Provider Claim Workflow Guide](/docs/claims/process/billing/previewProviderClaim.md) - [Billing Workflows Process Guide: Remove Attachment Workflow](/docs/claims/process/billing/removeAttachment.md) - [Billing Workflows Process Guide: Remove Diagnosis Workflow](/docs/claims/process/billing/removeDiagnosis.md) - [Billing Workflows Process Guide: Remove line Workflow](/docs/claims/process/billing/removeLine.md) - [Resubmit Claim Workflow Guide](/docs/claims/process/billing/resubmitClaim.md) - [Set Coverage Workflow Guide](/docs/claims/process/billing/setCoverage.md) - [Status Callbacks Process Overview: Being Told When a Status Changes](/docs/claims/process/callbacks/callbacksProcessOverview.md) - [Status Callbacks Process Guide: Manage Callback Endpoints](/docs/claims/process/callbacks/manageCallbackEndpoints.md) - [Status Callbacks Process Guide: Register a Callback Endpoint](/docs/claims/process/callbacks/registerCallbackEndpoint.md) - [Status Callbacks Process Guide: Register a Callback Operation](/docs/claims/process/callbacks/registerCallbackOperation.md) - [Claim Dispatch / Visit End Process Overview: Finalizing Patient Claims and Encounters](/docs/claims/process/claimDispatch/claimDispatchProcessOverview.md) - [Close Claim Workflow Guide](/docs/claims/process/claimDispatch/closeClaim.md) - [Claim Dispatch / Visit End Process Guide: In-patient Claim Dispatch Workflow](/docs/claims/process/claimDispatch/inPatientClaimDispatch.md) - [Claim Dispatch / Visit End Process Guide: Outpatient Claim Dispatch Workflow](/docs/claims/process/claimDispatch/outPatientClaimDispatch.md) - [Eligibility Process Guide: Facility Bed Occupancy Workflow](/docs/claims/process/eligibility/bedOccupancy.md) - [Eligibility Process Guide: Benefits Coverage Workflow](/docs/claims/process/eligibility/benefitsCoverage.md) - [Eligibility Check Workflow Guide](/docs/claims/process/eligibility/eligibilityCheck.md) - [Eligibility Process](/docs/claims/process/eligibility/eligibilityProcessOverview.md) - [Eligibility Process Guide: Intervention Coverage Workflow](/docs/claims/process/eligibility/interventionsCoverage.md) - [Eligibility Process Guide: Patient Utilization Workflow](/docs/claims/process/eligibility/patientUtilization.md) - [Eligibility Process Guide: POMSF Balance Workflow](/docs/claims/process/eligibility/pomsfBalance.md) - [Eligibility Process Guide: Pre-Visit Authorization Workflow](/docs/claims/process/eligibility/preVisitAuthorization.md) - [Eligibility Process Guide: Sub-Benefits Coverage Workflow](/docs/claims/process/eligibility/subBenefitsCoverage.md) - [Emergency Case Claims Process Guide: Add a Doctor to an Emergency Case Claim Workflow](/docs/claims/process/emergency/addEmergencyDoctor.md) - [Emergency Case Claims Process Guide: Add Emergency Case Protocols Workflow](/docs/claims/process/emergency/addEmergencyProtocols.md) - [Emergency Case Claims Process Guide: Create an Emergency Case Claim Workflow](/docs/claims/process/emergency/createEmergencyClaim.md) - [Emergency Case Claims Process Overview: Capturing Emergency Care Under ECCIF](/docs/claims/process/emergency/emergencyProcessOverview.md) - [Emergency Case Claims Process Guide: Get Emergency Case Protocols Workflow](/docs/claims/process/emergency/getEmergencyProtocols.md) - [Emergency Case Claims Process Guide: Identify an Unknown Emergency Patient Workflow](/docs/claims/process/emergency/identifyUnknownPatient.md) - [Emergency Case Claims Process Guide: Remove a Doctor from an Emergency Case Claim Workflow](/docs/claims/process/emergency/removeEmergencyDoctor.md) - [Emergency Case Claims Process Guide: Resend Doctor Consent Workflow](/docs/claims/process/emergency/resendDoctorConsent.md) - [Emergency Case Claims Process Guide: Submit an Emergency Case Claim Workflow](/docs/claims/process/emergency/submitEmergencyClaim.md) - [Intervention Process Guide: Add New Intervention Workflow](/docs/claims/process/interventions/addIntervention.md) - [Intervention Process Overview: Managing Patient Services](/docs/claims/process/interventions/interventionProcessOverview.md) - [Intervention Process Guide: Restore Intervention Workflow](/docs/claims/process/interventions/restoreIntervention.md) - [Intervention Process Guide: Retire Intervention Workflow](/docs/claims/process/interventions/retireIntervention.md) - [Intervention Process Guide: Switch Intervention Workflow](/docs/claims/process/interventions/switchIntervention.md) - [Preauth Doctor Consent Process Overview: Facilitating Doctor Approval for Pre-Authorizations](/docs/claims/process/preauthDoctorConsent/preauthDocConsent.md) - [Preauths Process Guide: Pre-Authorization Cancellation Workflow](/docs/claims/process/preauths/cancelPreauth.md) - [Preauths Process Guide: Elective Preauthorization Workflow](/docs/claims/process/preauths/electivePreauths.md) - [Preauths Process Guide: Imaging Preauth Workflow](/docs/claims/process/preauths/imagingPreauth.md) - [Preauths Process Guide: Multisession Preauths Workflow](/docs/claims/process/preauths/multisessionPreauths.md) - [Preauths Process Guide: Normal Preauths Workflow](/docs/claims/process/preauths/normalPreauths.md) - [Preauths Process Guide: Oncology Preauth Workflow](/docs/claims/process/preauths/oncologyPreauth.md) - [Preauths Process Guide: Optical Preauth Workflow](/docs/claims/process/preauths/opticalPreauth.md) - [Preauths Process Overview: Obtaining Prior Authorisation for Healthcare Services](/docs/claims/process/preauths/preauthsProcessOverview.md) - [Preauths Process Guide: Remove Preauth Diagnosis Workflow](/docs/claims/process/preauths/removePreauthDiagnosis.md) - [Preauths Process Guide: Remove Preauth Doctor Workflow](/docs/claims/process/preauths/removePreauthDoctor.md) - [Preauths Process Guide: Renal Preauth Workflow](/docs/claims/process/preauths/renalPreauth.md) - [Preauths Process Guide: Surgical Preauth Workflow](/docs/claims/process/preauths/surgicalPreauths.md) - [Remittance Process Guide: Get Claims Paid by Remittance Workflow](/docs/claims/process/remittances/getClaimsPaidbyRemittance.md) - [Remittance Process Guide: Get Remittances Workflow](/docs/claims/process/remittances/getRemittance.md) - [Remittance Process Overview: Streamlining Payment Reconciliation for Healthcare Providers](/docs/claims/process/remittances/remittanceProcessOverview.md) - [Start Visit Process Overview](/docs/claims/process/startVisitConsent/startVisitConsentProcessOverview.md) - [Start Visit Process Guide: Start Visit Workflow](/docs/claims/process/startVisitConsent/startVisitWorkflow.md) ## Consent Services Seventeen pages backing 22 operations. Consent gates every encounter: creating a visit is refused unless the request carries a verified one-time password (OTP), a previously minted authorization, or a fingerprint match. A successful consent mints an opaque token that the rest of the claim journey keys on as `consent_token`. One consent covers a beneficiary at a facility for a benefit type and a workflow type while it is unexpired, so moving from outpatient to inpatient, or from admission to discharge, needs a new one. Read the biometrics guide first whatever modality you intend to use: biometrics is the default, and OTP has to be unlocked per beneficiary by the payer. Background: SHA is Kenya's Social Health Authority, the payer these flows authorize against, and CR means Client Registry. Note that 9 of the 22 operations are the shared status-callback registration surface, also reachable from the eClaims reference; the consent operations proper are the other 13. - [Biometrics Integration Guide](/docs/consent/guides/biometrics-integration.md): Start here even if you plan to use one-time passwords, because it is the only page that goes from nothing to a working authorization: install the HealthID capture app, request staging credentials, confirm the scanner reports itself, then create an authorization and complete the capture. It also carries the recovery for the most common dead end, an authorization stuck at PENDING after the capture window closed. - [Biometrics Consent](/docs/consent/process/biometricsConsent.md): The governing rule for the whole stream, and the reason not to reach for OTP first: biometrics is the default and OTP is a fallback the payer must unlock per beneficiary. Also the only page carrying the hard numbers - a 10 minute capture window and 3 attempts, after which the authorization is REJECTED and you start again with a new one - and the only description of the Hardware Server the other biometrics pages defer to. - [OTP Fallback: No Usable Fingerprints](/docs/consent/process/biometricsNotFoundOTPFallback.md): The one case where OTP opens without a whitelist request. When eCitizen has no usable fingerprints for a patient aged 18 or over, the biometrics authorization is REJECTED with the reason BIOMETRICS_NOT_FOUND_OTP_ALLOWED (authorization_reason on the status callback, authorizationReason on Get Authorizations) and the patient may consent by OTP until the end of the next day, even at a biometrics-enforced facility. Branch on that reason, never on the notes text, and do not retry biometrics for the patient. - [OTP Whitelist Request](/docs/consent/process/createOTPWhitelistRequest.md): Read before assuming a one-time password is available to you. Whitelisting is not an inline call but a request a reviewer approves, with 13 reason codes, an attachment rule that auto-rejects several of them, and a scheduled review job; a pending request blocks a second one. Three other pages route their terminal failure here, so it is the page that decides whether the OTP rail is open to you at all. - [Get Beneficiary Valid Contact](/docs/consent/process/getBeneficiaryValidContact.md): The documented pre-step to sending an OTP, and worth one read for what it implies: you cannot supply a phone number, only pick from contacts the registry already holds. It returns masked contacts with an id, prioritising a guardian for a minor and next-of-kin for a deceased patient. - [Send OTP](/docs/consent/process/sendOTP.md): Dispatches the visit OTP against a patient and a set of intervention codes. Open it when wiring that call, but do not expect the passcode back: the response carries only a request id, and the code reaches the beneficiary by SMS, so the OTP rail cannot be driven end to end programmatically. - [Send Discharge OTP](/docs/consent/process/sendDischargeOTP.md): The second consent, at the end of the encounter rather than the start. Read it before building discharge: it takes the `consent_token` the opening authorization issued and mints a separate discharge-scoped consent, which the inpatient discharge and outpatient submit calls both require. - [Get Authorizations](/docs/consent/process/getAuthorizations.md): How to confirm a capture or a passcode actually landed, and the page whose data dictionary will mislead you: every query parameter is marked not required, yet at least one of token, guid or patient_id must be supplied. It also lists only 4 statuses, a subset of the 11 the callback page documents. - [Reject Authorization](/docs/consent/process/rejectAuthorization.md): The way out of a stuck PENDING authorization, which is not inert: it blocks a fresh authorization for the same context until cleared. The endpoint takes the `consent_token` as a path parameter and no request body at all, which is the detail most likely to be got wrong from the schema alone. - [Get OTP Whitelist Request](/docs/consent/process/getOTPWhitelistRequest.md): Polls the outcome of a whitelist request, by its guid or by a facility triple. Its data dictionary contradicts its own prose about which of the two is required, so treat the prose as the intent and expect to test both. - [Minors Biometrics Integration Guide](/docs/consent/guides/minors-biometrics-integration.md): The entry point for a minor, and read it before writing any age check: the payer decides the modality and returns it as `biometric_status.use_sil_biometrics` on the eligibility response. The two mechanics worth taking from it are that a match authorizes exactly once, and that its 600 second freshness window runs from the capture rather than from the moment your callback arrives, so anything queued in between has already spent part of it. - [Minors Biometrics Enrollment Guide](/docs/consent/guides/minors-biometrics-enrollment.md): The enrol-then-verify loop as a walkthrough, with the state diagram for it. Open this before the reference page if you are implementing enrollment from scratch, and take one rule from it: drive completeness off the returned enrollment status, never off a finger count of your own, because what counts as complete is set upstream and can change without a release on your side. - [Minors Biometrics Enrollment](/docs/consent/process/minorsBiometricsEnrollment.md): The field reference for the two-captures-per-finger flow, and the page that prevents the single most likely wrong implementation in this stream: `attempts_remaining: 0` does not mean exhausted, it reads 0 on a successful verify too. The signal that obliges a re-enrol is `requires_reenroll` alongside `status: max_attempts_exceeded`. A capture is also refused outright if the facility has no callback endpoint registered. - [Minors Biometrics Consent](/docs/consent/process/minorsBiometricsConsent.md): The field reference for requesting a match, the callback body it delivers, and the ordered list of six refusal codes. The page to open when a dispatch returned 202 and nothing has happened since, because 202 is a receipt and not a result, and the read endpoint is a reconciliation route that is explicitly not to be polled. A match cannot be dispatched at all until the child is fully enrolled. - [Authorization Status Callbacks](/docs/consent/process/authorizationStatusCallbacks.md): The 11 states an authorization can report, and read it before writing any state machine over them: CLOSED can move back to AUTHORIZED, and SUBMITTED_CLAIM is an authorization state that says nothing about whether the payer received or approved the claim. Callback ordering is not guaranteed. Registering an endpoint is also a hard prerequisite elsewhere in this section, since a minors capture is refused before dispatch without one. ## Registries 6 pages backing 3 operations: the client registry for patients, the facility registry, and the health-worker registry. The patient lookup is step two of almost every flow on this site, because the id it returns is the patient_id every downstream call expects. - [Introduction to HIE Registries](/docs/registries/gettingStarted/introduction.md) - [Understanding HIE Registries](/docs/registries/guides/understandingRegistries.md) - [Facility Search Workflow Guide](/docs/registries/process/facilitySearch.md) - [Eligibility Process Guide: Patient Search Workflow](/docs/registries/process/patientSearch.md) - [Professional Search Workflow Guide](/docs/registries/process/professionalSearch.md) - [Registries Process Overview: Accessing Core Health Information Repositories](/docs/registries/process/registriesProcessOverview.md) ## Terminology Service 3 pages backing 2 operations for resolving a local code to a standard HIE concept. Relevant when your system stores its own codes for diagnoses, tests or medicines and has to send coded data rather than free text. - [TERMINOLOGIES SERVICE APIs](/docs/terminologyService/gettingStarted/intro.md) - [Terminology Service Process Guide: Fetch Concept Mappings](/docs/terminologyService/process/fetchConceptMappings.md) - [Terminology Service Process Guide: Search Hierarchical Concepts](/docs/terminologyService/process/searchHierarchicalConcepts.md) ## Shared Health Record 1 page against 13 operations, so the prose here covers far less than the API does; read the published spec at /specs/shr.json alongside it. Covers reading a patient's record across facilities and contributing to it, gated by its own consent flow separate from the claims one. - [Introduction to the Shared Health Record](/docs/sharedHealthRecord/gettingStarted/intro.md) ## Optional - [Changelog](/changelog.md): Dated record of API and documentation changes. Read it when reconciling behaviour against an older integration. - [Introduction to Consent Services](/docs/consent/getting-started/intro.md): Orientation only, and the one page here that can be skipped: no endpoint, field or sequence detail. Start at the Biometrics Integration Guide instead.