Healthcare system integration validation

FHIR · API contracts · data references · acceptance tests

Buyer outcome: interface matrix, expected/actual scenarios, discrepancy list with evidence and a PASS/FAIL report against the agreed contract.

First scope: data sample, export or test environment. Responsibility covers agreed contracts, validation rules, scenarios and the acceptance report.

Input

Synthetic Patient, Organization, Encounter, Observation, Appointment and ServiceRequest resources.

How the check works

Contract → typed resources → references → expected/actual scenarios.

What the system detects

Missing identifier or reference, status, timestamp, inconsistent subject and HTTP response.

What you receive

Interface matrix, reference graph, evidence and JSON/CSV report.

How the result is accepted

Agreed decisions, rules and responses produce the expected test results.

Contract acceptance package

Contract, references and evidence

REJECT is an integration decision. Expected REJECT and actual REJECT give a PASS test result. The test also checks the rule and HTTP status.

REFERENCE / BASELINE

Resource references are consistent. The package includes expected rejections of invalid messages; the test passes when they are detected according to the contract.

For a technical reviewer

Inspect input, rules, run identifier and evidence in the tabs below.

Run the reference package. Then introduce the controlled change and inspect the detected discrepancy.

What you can verify here

Required contract fields, identifier and relationship consistency, negative scenarios, expected and actual results, evidence and a deterministic acceptance report.

Acceptance criteria

Reference: all scenarios PASS. Controlled change: exactly one discrepancy. Restore: PASS again with the same run ID. CSV and JSON reports contain as many results as executed scenarios.

Public scenario parameters

The system validates the exchange contract, required fields, identifiers, resource references, expected/actual values and interface responses in the described FHIR R4-style subset.

The public scenario covers data and contract interoperability using synthetic data, rather than medical decision-making. Clinical, national and certification requirements are separate project requirements. The source adapter is configured within the agreed integration scope.

Reports are isolated by browser session. The report uses a fixed evaluation clock, not the time of a clinical event.

Describe the scope

Contract supplement: HL7 v2 / DICOM metadata

FHIR remains the main model. This pack checks selected MSH/PID fields from an ADT^A01 message plus identifiers and references in DICOM metadata. The scope covers message structure and metadata; image processing and full conformance profiles require a separate contract.

Reference: all tests PASS. Controlled change: PatientID of one study changes to an unknown identifier. Expected rejection of invalid input means the test passes.