New Zealand Rheumatic Fever FHIR Implementation Guide
0.4.9 - draft
New Zealand Rheumatic Fever FHIR Implementation Guide
0.4.9 - draft
New Zealand Rheumatic Fever FHIR Implementation Guide, published by Te Whatu Ora. This guide is not an authorized publication; it is the continuous build for version 0.4.9 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/tewhatuora/fhir-rheumatic-fever/ and changes regularly. See the Directory of published versions
#O (upper case letter 'O') from the FHIR/HL7 relationship type codes.https://standards.digital.health.nz/ns/rf-ccs-idThe patient's address in the example diagnosis encounter now has an eSAM identifier with system Url set to the HISO standard NamingSystem value https://standards.digital.health.nz/ns/nz-address-id
Renamed capability statement instance.
Reinstated Consent.performer in consent examples.
The canonical base Url for the IG has been updated to https://fhir-ig.digital.health.nz/rheumatic-fever for publishing at the official HISO IG site.
This IG now appears in the HISO Implementation Guide index (UAT)
Filtering classifiers added to various RF resource types to enable OAUTH scoping as follows:
Appointments have .serviceCategory set to $sct#58718002Encounters have .type set to $sct#58718002MedicationStatements have .category set to $sct#58718002meta.tag.code=58718002)Testing has shown that applications cannot practically use codes defined in the NZ SNOMED edition because the New Zealand Health Terminology Service (NZHTS) is unable to support lookup and validation of these codes. (This stems from SNOMED affiliate licensing restrictions affecting the NZ Edition.)
As NZ SNOMED terms are in effect unusable for NZ applications, all these codes have been brought into a CodeSystem in the IG, so the IG itself defines the codes.
The IG now has a single local CodeSystem which consolidates all the special codes needed for New Zealand rheumatic fever FHIR data representation.
This CodeSystem includes codes which previously sat in their own systems eg. the RF diagnostic certainty codes.
The various ValueSets used throughout this IG now draw all their codes from the new common IG CodeSystem, or from applicable public terminology systems (http://snomed.sct/info, http://nzmt.org.nz).
The following IG artefacts have changed to draw some or all of their codes from the new common local CodeSystem:
RFConditionDiagnosticCertaintyValueSetRFConditionRHDSeverityValueSetRFConditionSummaryDiagnosisValueSetRFDiagnosisGroupValueSetRFRelatedPersonRoleValueSet (renamed from RFCareTeamParticipantRoleValueSet)RFMedicationRequestMedicationFrequencyValueSet (renamed from RheumaticFeverMedicationRequestMedicationFrequencyValueSet)RFMedicationAllergyValueSet (renamed from RheumaticFeverMedicationAllergyValueSet)All instance examples featuring NZ-specific codings now use the local codesystem Uri in this IG instead of a SNOMED NZ edition Uri
The DiagnosisGroup (Observation) profile now requires:
RFDiagnosisObservationCodingValueSet which draws all the diagnosis SNOMED codes plus one special local code #448021000210106 (Indolent carditis (disorder))The following profiles now require use of the local code #rf-nz to categorise all instances:
CarePlan profile requires instances to be categorised #rf-nz (was SNOMED #320721000210102)Condition profile requires instances to be dual-categorised #rf-nz, SNOMED #58718002 (was SNOMED category only)CareTeam profile requires instances to be categorised #rf-nz (was SNOMED #320741000210108)RelatedPerson.relationship)Encounter example instances to use official test data
Locations now use HPI Facility identifiers from HPI test dataSeparated rheumatic fever API from shared care IG into the dedicated IG.
Observation example instances now have a .performerEncounter example instances now have a .serviceProviderdosageInstruction.route and .siteevidence[].detail references.CarePlans now illustrate use of the lifelong secondary prophylaxis extension and have been revised so that creation adn period dates are UTC dateTime values.Appointments and Encounters now have .serviceType = $sct#360271000 "Prophylaxis"| Adjusted medication frequency codes //allowed by the ValueSet to include every 10 | 13 weeks. |
Revised secondary prophylaxis medication planning and recording model: Added nested lignocaine medication request and statement; simplified appointments.
Added new model of diagnosis data representation
Added new model for planning/recording of other care appointments
Moved the LeadProvidersGroup from Examples to Definitions section
Expanded the membership of the LeadProvidersGroup to encompass all 18 NZ Rheumatic Fever Secondary Prevention Services.
Condition RF profile:
These examples have been adjusted to correctly reflect the Taranaki RF SP service as a shared care provider by referencing its HPI org Id G0M744-C
Added state transition diagrams for the expected states of secondary prophylaxis resources.
Update to existing diagram illustrating appointment planning and recording the number of planned Appointments has been reduced to one.
Developer guidance expanded about validation of resources using versioned profiles
#active rather than #proposed status.In consent-based access control, a diagram and description has been added for the Consent-on-behalf scenario (consent obtained from a related person). Other minor improvements to the description.
Fixed a few broken links in this changelog.
The SNOMED code required by the rheumatic fever profile of CareTeam was incorrect and has now been revised to 320741000210108.
Note this is a new SNOMED code for the New Zealand edition and is not yet visible in SNOMED CT browsers as of this update.
As of this IG, a business version of "1.0.0" has been set in definitions and canonical instances. Future updates from this point will increment these version numbers in the applicable artifacts using semantic versioning.
All four rheumatic fever canonical Questionnaire instances now have a business version set to "1.0.0".
The example QuestionnaireResponses for these Questionnaires now use versioned FHIR "questionnaire" references eg.
"https:/build.fhir.org/ig/fhir-rheumatic-fever/Questionnaire/MedicationsAndFollowUpGuidanceQuestionnaire|1.0.0"
The five rheumatic fever resource profiles of CarePlan | Patient | Condition | CareTeam | MedicationRequest now have a business version set to "1.0.0" instead of the IG version.
Corresponding example instances of these profiled types now use a versioned FHIR canonical reference in their metadata eg.
{
"resourceType" : "CarePlan",
"meta" : {
"versionId" : "2",
"lastUpdated" : "2023-11-07T04:00:00Z",
"profile" : [
🔗 "https://build.fhir.org/ig/tewhatuora/fhir-rheumatic-fever/StructureDefinition/nz-rheumaticfever-careplan|1.0.0"
]
},
...
ValueSets defined in this IG now have their own business version numbers set to "1.0.0" as of this IG release.
A couple of example instances now claim their resource profile as the profile (version "1.0.0") in this IG whereas previously they claimed the base FHIR R4B profile:
RheumaticFeverCareTeam)RheumaticFeverMedicationRequest)One further extension is now defined, in the RheumaticFeverCondition profile of Condition resource. The new extension named assessmentDate enables API consumers to record the date of RHD severity assessment separately from the date of diagnosis (recordedDate).
The corresponding example instance has been updated to demonstrate usage of this extension. The FHIR data model and rheumatic fever data documentation has been revised to show the additional extension element.
All identifier references to the two HPI pilot service provider orgs have been corrected to G0M086 / G0M087. Previously the second character of these identifiers was incorrectly specified as upper case letter 'O' rather than '0' zero.
One further type code has been added to the ExternalSystemIdentifierTypeValueSet ValueSet to enable clients to designate identifiers to external encounter objects.
In the rheumatic fever section of the documentation, the FHIR design diagrams (which were moved onto their own page in IG v0.3.5) are no longer duplicated on the rheumatic fever data mappings and translation page.
As a result of a design decision to constrain values of medication frequency to a standard set of frequencies (coded) used in NZ rheumatic fever secondary prophylaxis:
Dosage.additionalInstruction is no longer to be used for medication frequency).MedicationRequest named RheumaticFeverMedicationRequest has been introduced to incorporate the new extension from (2). It builds on NzMedicationRequest from the NZ Base IG.The example MedicationRequest now claims conformance with its new profile in this IG as outlined above.
The example MedicationStatement now claims conformance with NzMedicationStatement from the NZ Base IG.
partOf reference to its contained instance to avoid a Publisher QA FHIR validation error.There is now a new example Bundle showing how secondary prophylaxis encounter info can be created as three POST requests in one transaction (Encounter + MedicationStatement + QuestionnaireResponse).
Added a section to the API Developer Guide about validation of FHIR resource references.
Updates to FHIR Resource Data Model:
Base FHIR type is now consistently identified using the UML stereotype of the class
MedicationRequest resource is now shown as profiled RheumaticFeverMedicationRequest`
Usage of sliced identifiers in profiled resources is now shown more clearly.
The model now shows references going from the RheumaticFeverCondition resource to the Episurv national notifiable disease system.
Tweaked the RF Terminology page.
Added a few resource types to server Capability Statement
Patient.contact[]Whanau care teams are now represented directly in the RheumaticFeverPatient resource, as .contact[] members.
The RheumaticFeverCareTeam resource profile will now be used only for secondary prophylaxis care teams. So all instances of RheumaticFeverCareTeam resources are categorised sct#320741000210108 "Secondary prophylaxis team"
A new example RheumaticFeverPatient instance has been added showing how to model whanau members as contacts
SageWestbrookAndWhanau
RheumaticFeverPatient profile changesPatient.contact now has three new extensions capturing role (coded), relationship (string) and primary contact nature for each member of a patient's whanau/trusted delegates care team.Secondary Prophylaxis Health Assessment Questionnaire
Various items removed and one new item added [Example QR]QuestionnaireResponse-HealthAssessmentAtSecondaryProphylaxisEncounter.html) updated to match.
Medications and Follow-Up Guidance Questionnaire
One item changed from boolean to yes/no/unknown coded answer. Example QR updated to match.
Patient Medication Allergy Questionnaire
One item removed. Example QR updated to match.
The example SecondaryProphylaxisCareTeam has been adjusted to properly represent a secondary prophylaxis care team
The example WhanauCareTeam has been deleted.
Appointment examples updated to reflect changes to data dictionary, including the addition of another code for RFCCS CarePlanActivity identifiers in ExternalSystemIdentifierTypeValueSet.
A new example has been added demonstrating consent by a person related to a patient.
The example rheumatic fever patient SageWestbrook also now has some sample ContactPoint entries in Patient.telecom[].
documentation
Reorganised top nav with two new sections for COVID CINC artifacts and Consent documentation and examples.
The IG now allows for .contained resource instances in Consents
This is needed for rheumatic fever in which consent is commonly obtained from the patient's parent or another relative.
Three new extensions defined for use on Patient.contact
IG FHIR Shorthand (fsh) source code improvements
ContactPoint elements used by patient.telecom and patient.contact.telecom examples.Consent resource examples
Examples now include the .organization element as the custodian of the consent, set to the same org as .performer
An example of an #active status Consent has been added.
In the RheumaticFeverCarePlan resource profile, .addresses now has cardinality zero to many (0..*)
In the RheumaticFeverCondition resource profile, the diagnosticCertainty extension now uses codes defined in a code system in this IG because clients cannot expand the ValueSet
published on the New Zealand Health Terminology Service to codes at this time.
In the four rheumatic fever extensions defined by this IG, the context, which constrains which type(s) the extension can be used on has been changed to the applicable base type instead of the profiled type. This change means clients can use the extensions without encountering hapi validator errors / Bad Request 400 errors.
Identifiers from EPISurv, the national system which tracks notifiable disease events, are no longer to be recorded on RheumaticFeverCarePlan and have moved instead to the RheumaticFeverCondition profile. Relevant example instances have been updated.
validation errors in example resources – updates to address certain errors raised by the FHIR Validator:
In example resources which have a Reference(Organization) the reference type is now the base type Organization instead of "type" : "NzOrganization"
In CarePlan examples, subject references are now of base "type" : "Patient" instead of "type" : "NzPatient"
Also in CarePlan examples, addresses has changed from a singleton reference to an array of References (length 1) with each entry of "type": "Condition"
Revised Identifier slicing in CarePlan, Condition and CareTeam resource profiles to allow multiple references to external identifiers and capture the types of identifier being referred to.
Revised the patient medication allergy ValueSet to now use SNOMED terminology which pinpoints the medication allergy instead of substance concepts.
Patient Medication Allergy Questionnaire revised questions to codify answer yes|no|unknown, and add third question to capture Other Allergy detail as free text.
Secondary Prophylaxis Health Assessment Questionnaire revised questions in line with data dictionary changes, and [QuestionnaireResponse example]QuestionnaireResponse-HealthAssessmentAtSecondaryProphylaxisEncounter.html) updated to match.
Corrected rheumatic heart disease severity ValueSet to add missing code #301561000210102 History of heart valve replacement (situation)
Introduced new terminology QualifiedYesNoAnswerValueSet. This set of SNOMED codes applies to yes/no-type questions where it is important to be able to record an 'unknown' or 'information not available' response in a FHIR QuestionnaireResponse item.
Introduced new terminology ExternalSystemIdentifierTypeValueSet. This extends the set of FHIR Identifier type codes to define new codes for known external identifiers in NZ national systems that integrate with the Te Whatu Ora Shared Care FHIR API.
All Rheumatic fever terminology now appears in the rheumatic fever section of the Profiles tab.
Key RFCCS <-> FHIR mappings are now defined in the rheumatic fever data page.
Added Consent tab describing patient-consent-based access controls implemented by the Te Whatu Ora Shared Care API.