aehrc / aehrc/FHIRLab

OpenHIE POS ↔ Client Registry: FHIR R4 Postman collection via OpenHIM

Open
#4 0 comments 0 reactions 0 assignees View on GitHub

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.