The identity crates are published. The server is being built.
FerroPIX is the Master Patient Index of the FerroHEALTH family. Every organisation issues its own identifiers for the same person; FerroPIX holds the cross-reference between them, over the IHE profiles integrators already expect, and mints the pseudonyms the clinical domain uses, so identifying data stays outside the clinical record.
Today FerroPIX publishes two crates on crates.io:
ihe-iti, the IHE identity profiles, and
nl-generic-functions, the Dutch Generic Functions. The
server, with its container image, is the next milestone.
Each profile is a feature, and none is on by default, so you
compile only what you call. Identifiers travel as secrets: no
Debug rendering, error or log line carries one.
cargo add ihe-iti --no-default-features -F pixm
cargo add ihe-atna --no-default-features
PixmClient asks a PIX Manager for the identifiers
other domains hold for a patient (ITI-83). It reads a
404 as "patient unknown" only when the profile says
so, and never reads an outage as an empty answer.
Getting
started walks through a complete query, and
the crates page covers
every feature with its API reference on docs.rs.
FerroPIX follows the IHE ITI Technical Framework and the PIXm, PDQm and PMIR guides, on HL7 FHIR R4. Each card says whether it is published today or planned for the server; the status table has every capability.
The identifier cross-reference query (ITI-83, by
GET or by POST), the demographics query
(ITI-78) and the demographics match (ITI-119), each answer held
to its profile.
The PMIR subscription and feed (ITI-94, ITI-93), the mCSD directory and its replica (ITI-90, ITI-91), and the XCPD Initiating Gateway (ITI-55) with the SAML assertion you supply.
An authorizer you supply makes the headers of each request (IUA
ITI-72), and each profile's BALP or ATNA record goes to the
ihe-atna audit trail before the answer is used.
Localization through the NVI on the pseudonymised BSN, the Mitz
closed authorization question, the LRZa address book, and the
Nuts access token request with a DPoP-bound token.
The PIXm Manager with the ITI-104 feed, the PDQm Supplier and the PMIR Registry, over a persisted cross-reference with identifier domains, linking and merge.
A pseudonym per patient and pseudonymisation domain for the clinical store, and the HL7 v2 PIX and PDQ transactions on the family's one v2 parser, with a container image pinned by digest.
What a patient index does, what FerroPIX has built and what is planned, the specification versions and the licence.
The published crates, feature by feature, with what each client sends, what it checks and what it refuses.
The settings of each client, how identifying data is kept out of logs, the audit trail, and the release and support policy.
The tracker is the worklist and the checks are committed scripts you can run yourself. A change cites the specification section it implements.
The identity crates were built in FerroFED, moved here with their history, and are published from here. The next milestone is the server: the PIXm Manager, the PDQm Supplier, the PMIR Registry, the persisted cross-reference, pseudonym minting, the HL7 v2 transactions and a container image. The tracker's milestones are the roadmap, and a release is cut when its milestone has no open issue left.