Open dtr-agency opened 2 years ago
Design review workshop 26/03/22 confirmed single EOB (ExplanationOfBenefit) profile is best split into an two given the targeted rules for two benefits schemes:
DocumentReference example(s) for MHR system needed to demonstrate how / if these can be generated from an original upload payload for Medicare /DVA Benefits Report and Pharmaceutical Benefits Report.
FHIR Architecture Review Outcomes on MBS set of profiles
Changes from FHIR Architecture Review complete.
FHIR Architecture Review Outcomes on PBS set of profiles
Changes from FHIR Architecture Review complete.
May 2022 QA Preview - http://build.fhir.org/ig/AuDigitalHealth/ci-fhir-r4/branches/2022May/package.tgz Release 1.0.0 is limited to the FHIR R4 conformance artefacts that define the controls on data persistence for the following record types: Australian Immunisation Register, Australian Organ Donor Register, PBS/RPBS Claim Information, MBS/DVA Claim Information.
The FHIR R4 conformance artefacts are a set of StructureDefinitions that define the FHIR structures required, the data element definitions, and their associated rules of usage including the use of extensions and terminology. These conformance artefacts will be published in an Agency FHIR NPM package for use with FHIR and FHIR-aware tools. The FHIR package contains the validation form (JSON + SCH) of the conformance artefacts for direct use in validation operations and example resource instances that demonstrate use cases and conformance requirements.
While these artefacts and their package have been developed in conjunction with this Agency FHR implementation guide – publication and release of the implementation guide is not in scope. The implementation guide is provided to assist readers and users in understanding the Agency FHIR NPM package. See http://build.fhir.org/ig/AuDigitalHealth/ci-fhir-r4/branches/2022May/index.html
Development and internal design architecture review is complete, internal unit testing is underway via AN-3, Clinical Informatics peer review is underway via AN-5, AN-6, AN-7, and AN-8.
Testing completed with convention issue identified: Fixed via https://github.com/AuDigitalHealth/ci-fhir-r4/commit/be7d05d646e9ea0b4baa4a7eff668db1a35bd096
Clinical Informatics peer review changes: https://github.com/AuDigitalHealth/ci-fhir-r4/commit/9e4ecc09b851f5d7984d1404c6c80430823ea55a and https://github.com/AuDigitalHealth/ci-fhir-r4/commit/0af08972f10ba4a3408d4d2d6ce17fbe5ea4b1d6
Feedback raised during the assurance period from internal testing, CI SME design review, and NIO have been addressed. A new frozen QA Preview baseline is available.
Changes from internal assurance between v1.0.0-qa-preview and v1.0.0-qa-preview2 :
ADHA profiles amended (changes listed above): • ADHA Record of Consent from Australian Organ Donor Register • ADHA Record of Claim against MBS or DVA • ADHA Record of Claim against PBS or RPBS • ADHA Australian Immunisation Register Notice • ADHA Core Document Reference • ADHA Core Flag • ADHA Core Medication • ADHA Core Observation • ADHA Core Organization • ADHA Core ServiceRequest • ADHA Core Specimen • ADHA Core Substance • ADHA Diagnostic Result Observation • ADHA Imaging Result Observation • ADHA Pathology Result Observation • ADHA System Device
June 2022 QA Preview - http://build.fhir.org/ig/AuDigitalHealth/ci-fhir-r4/branches/2022June/package.tgz Release 1.0.0 is limited to the FHIR R4 conformance artefacts that define the controls on data persistence for the following record types: Australian Immunisation Register, Australian Organ Donor Register, PBS/RPBS Claim Information, MBS/DVA Claim Information.
The FHIR R4 conformance artefacts are a set of StructureDefinitions that define the FHIR structures required, the data element definitions, and their associated rules of usage including the use of extensions and terminology. These conformance artefacts will be published in an Agency FHIR NPM package for use with FHIR and FHIR-aware tools. The FHIR package contains the validation form (JSON + SCH) of the conformance artefacts for direct use in validation operations and example resource instances that demonstrate use cases and conformance requirements.
While these artefacts and their package have been developed in conjunction with this Agency FHR implementation guide – publication and release of the implementation guide is not in scope. The implementation guide is provided to assist readers and users in understanding the Agency FHIR NPM package. See http://build.fhir.org/ig/AuDigitalHealth/ci-fhir-r4/branches/2022June/index.html
Cycle 2 internal unit testing continues via AN-3. Cycle 2 clinical Informatics peer review continues via AN-6, AN-7.
Review and testing for this profile is complete. Next step is to mark as Active v1.0.0 and pass regression testing.
Advice provided from NIO that Service Requestor from Services Australia for MBS has never been received in the past, and is not part of the live feed design. Associated issue https://github.com/AuDigitalHealth/ci-medicare-records/issues/21 raised to update live feed conformance specification.
Impact to design ADHA Record of Claim against MBS or DVA ExplanationOfBenefit.referral is not to be supported and the ADHA MBS Service Claim Item profile governing that element is not required.
Actions
The final baseline of the ADHA FHIR NPM package & IG is released for assurance as 1.0.0-qa-preview3. This version reflects final design agreements with NIO and Oracle and addresses feedback raised during the assurance period.
http://build.fhir.org/ig/AuDigitalHealth/ci-fhir-r4/branches/2022Aug/package.tgz
Changes from internal assurance between v1.0.0-qa-preview2 and v1.0.0-qa-preview3:
ADHA profiles removed as part descoping ExplanationOfBenefit.referral:
This version is undergoing internal release readiness and regression testing via AN-477, and publication readingess review via AN-431, Agency Governance review via Collaborate.
Prerequisites
The issue / feature
Change description
Develop and publish an payload definition for R4 of a record of the claim of an item claimed against the Pharmaceutical Benefits Schedule (PBS), Repatriation Pharmaceutical Benefits Scheme (RPBS), or Medicare Benefits Schedule (MBS) to provide an initial baseline as input a the piece of work to provide FHIR R4 endpoint for the exchange of digital health information recorded on the Medicare registries between individuals, healthcare providers, and the My Health Record system infrastructure in Australia.
The purpose of this exchange is to supporting data sourced from the Services Australia Medicare repositories.
Reports of completed claims for a patient against the PBS, RPBS, or MBS are uploaded from Medicare repositories to the MHR system and surfaced to patients, related parties, providers, and clinical information systems via the MHR supported access channels (National Consumer Portal, National Provider Portal, B2B Gateway, etc.).
What it actually enables people to do
How awesome would it be?
Support transition from STU3 to R4 of digital health exchanges of an individual's information in relation to the Medicare program.
Workarounds
N/A
Additional context
See the current STU 3 implementation - TBD complete this section.