OpenHIE POS ↔ Client Registry: FHIR R4 Postman collection via OpenHIM
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Ask
From Umer Nisar (Biosecurity, Parkville), via Slack:
Look at OpenHIE specification for functional req re integration between a POS and client Registry:
Pick very basic few requirements e.g. find client, validate client, register client
Assume Api gateway in the middle (OpenHIM), all calls will go to OpenHIM endpoint (this will be useful for setting Postman env variables)
Generate FHIR R4 collection for it and examples. See Jim's Ontoserver (terminology) collection as reference point.
Please Share and Review with me once ready
Confirmed shared understanding (Joern Guy Süß, Biosecurity, Herston):
- Someone learning FHIR and OpenHIE wants to understand, in context, what a scenario looks like where a POS queries a Client Registry per OpenHIE functional requirements.
- The deliverable is a Postman collection (FHIR R4), with environment variables baked into the collection, in the style of Jim Steel's Ontoserver terminology collection.
Why this lives in FHIRLab (not a standalone repo)
This is intended as a learning example on the FHIRLab website, alongside the existing postman/learning/ FHIR fundamentals collection — following the same pattern (a themed sub-collection with its own README documenting sources/rationale).
Scope
- Pick a small, basic subset of OpenHIE POS ↔ Client Registry functional requirements: find client, validate client, register client.
- Route every call through an OpenHIM API gateway channel (never directly to the Client Registry).
- FHIR R4 Postman collection with request examples, modelled on Jim Steel's Ontoserver collection style.
Deliverable
- FHIR R4 Postman collection with baked-in environment variables (OpenHIM channel URL + credentials)
- Example requests for: find client (IHE PDQm), validate client (
$match), register client (IHE Patient Identity Feed) - README documenting the IHE/FHIR mapping and citations, matching
postman/learning/README.md's style - Share with Umer for review
Work in progress on branch 2-openhie-pos-cr-postman-collection in the canonical GitLab dev repo (core-website), reconciled here once ready per this repo's MAINTAINING.md process.
Originally tracked at https://gitlab.com/australian-e-health-research-centre/digital-health-strengthening-standards-capability/experiments/instant-openhie/-/work_items/1 — moved here since this is an example for the FHIRLab website, not the OpenHIE infra experiment repo.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading postman/learning/README.md and MAINTAINING.md, then compare Jim Steel's Ontoserver collection for structure and examples. Prepare the FHIR R4 Postman collection and README in the documented style, covering find, validate, and register client requests through OpenHIM with environment variables, then share it with Umer for review.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- gitlab, postman
- Domain
- api, backend-api-design, documentation
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 30/100