Healthcare Financial Services IG Edition 1 - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
There are a number of places where this version of the implementation guide varies from FHIR or industry 'best practise' to accommodate the current business practises in Saudi Arabia. Consideration will be given in future versions of the implementation guide to better align Saudi practices with other practise guidelines and then to reflect those changes within this guide.
ValueSet | Description of Change |
---|---|
practitioner-identifier-type | Added 'PRN' to the list of codes to be used with the Practitioner resource as the identifier.type. For now both 'PRN' and 'MD' type codes will be accepted but in future versions of the IG the support for 'MD' is likely to be removed. |
body-site | Changed to SNOMED body-site codes (https://hl7.org/fhir/valueset-body-site.html). |
Changed the length of Coding.code.display from 100 to 500 to accomodate longer display strings in code systems.
Missing data indicators in Claim.supportingInfo is handled by using proprietary sets of codes, which are not themselves harmonized, within the .reason element rather than using a standard FHIR data-absent extension placed within the element where the data would have been expected. This means that implementers must look for a choice of two optional elements rather than one required element and must program separate logic for the same missing data concept from multiple 'missing-value' code systems.
This issue is found in uses of Claim.supportingInfo for the concepts:
Category.code | SupportingInfo Element | ValueSet |
---|---|---|
vital-sign-weight | valueQuantity | http://nphies.sa/terminology/ValueSet/weight-absence-reason |
vital-sign-systolic | valueQuantity | http://nphies.sa/terminology/ValueSet/blood-pressure-absence-reason |
vital-sign-diastolic | valueQuantity | http://nphies.sa/terminology/ValueSet/blood-pressure-absence-reason |
vital-sign-height | valueQuantity | http://nphies.sa/terminology/ValueSet/height-absence-reason |
temperature | valueQuantity | http://nphies.sa/terminology/ValueSet/temperature-absence-reason |
pulse | valueQuantity | http://nphies.sa/terminology/ValueSet/pulse-absence-reason |
oxygen-saturation | valueQuantity | http://nphies.sa/terminology/ValueSet/oxygen-saturation-absence-reason |
respiratory-rate | valueQuantity | http://nphies.sa/terminology/ValueSet/respiratory-rate-absence-reason |
Several nphies CodeSystems mimic or duplicate HL7 CodeSystems, or CodeSystems used are valid HL7 CodeSystems and are flagged as experimental, or have example-styled names such as ex-some-codes. These should be replaced with the HL7 CodeSystem once they have been marked non-experimental, or renamed, and formalized into the HL7 Terminology (THO) environment.
These issues are found in the following CodeSystems:
CodeSystem | HL7 URL | nphies URL |
---|---|---|
Benefit Type | http://terminology.hl7.org/CodeSystem/benefit-type | http://nphies.sa/terminology/CodeSystem/benefit-type |
Diagnosis Type | http://terminology.hl7.org/CodeSystem/ex-diagnosistype | http://nphies.sa/terminology/CodeSystem/diagnosis-type |
Claim Information Category | http://terminology.hl7.org/CodeSystem/claiminformationcategory | http://nphies.sa/terminology/CodeSystem/claim-information-category |
Coverage Financial Exception | http://terminology.hl7.org/CodeSystem/ex-coverage-financial-exception | http://nphies.sa/terminology/CodeSystem/coverage-financial-exception |
Diagnosis on Admission | http://terminology.hl7.org/CodeSystem/ex-diagnosis-on-admission | http://nphies.sa/terminology/CodeSystem/diagnosis-on-admission |
Vision Prescription Product | http://terminology.hl7.org/CodeSystem/ex-visionprescriptionproduct | http://nphies.sa/terminology/CodeSystem/lens-type |
Related Claim Relationship | http://terminology.hl7.org/CodeSystem/ex-relatedclaimrelationship | http://nphies.sa/terminology/CodeSystem/related-claim-relationship |
Claim FundsReserve | http://hl7.org/fhir/ValueSet/fundsreserve | n/a |
Claim Payee.type | http://hl7.org/fhir/ValueSet/payeetype | n/a |
In FHIR R5 and later use Bundle.identifier and rather than Bundle.id to establish message identity. FHIR R5 contains the note:
Previous releases used a combination of Bundle.id and MessageHeader.id in an attempt to establish the message identity. This posed problems when crossing the boundaries between messaging and RESTful exchange. The current release uses Bundle.identifier exclusively to establish and maintain the message identity.
Future versions of this specification which are based on FHIR R5 and later will need to adjust the message content requirements, duplicate checking and other message handling to align with those changes.
The SupportingInfo Extension is used with the Advanced Authorization to provide relevant clinical and supporting information to the target provider in the same manner as the Claim.supportingInfo data structure (See also Overview - SupportingInfo). This extension has been defined as standalone extension containing several other standalone, full path, extensions. While this is technically valid it is not the FHIR best-practise for complex extensions. Two new extension have been provided in this IG for future consideration to replace the current SupportingInfo Extension:
It has been noted that some implementations are putting text into supportingInfo.code.text when the code is 'other' - this is not appropriate and error checking in the future will reject such usage. If the code is 'other' and the provider wishes to supply explanatory text describing the result or other circumstances then they should put the text into value[x].string or the valueString extension element.
The RTA Diagnosis and Work Related Diagnosis are declared as separate code systems and yet are actually codes from ICD10-AM therefore, in a future release the codes should be referenced within the respective valuesets as coming from the ICD10-AM code system and these codes systems would then be dropped.
MessageDefinition is a new resource which may be used in conjunction with CapabilityStatement to provide the definition and list of resources expected within a defined message structure. An example of its use has been provided in this version of the guide for the pair of messages use in the Cancellation use case. In the future the MessageDefinitions may be provided for all messages used in this guide should they prove usefull.
In the past some messages referred to the nphies base profile for a resource, for example Task and Encounter. This guide defines specific profiles for different usescases using the Task resource, such as the separate request and response profiles for each of: Cancel, Poll and Status checking. While referring to the base resource profile is currently supported, in the future validation will be performed to the more specific profiles for resources such as Task and Encounter.
Enforcement of including the profile business version number, e.g., adding "|1.0.0", to the end of the name of the profile will be included in a future update so that version management can be implemented for profiles. Note that when the business version is not supplied nphies will validate the resource instance against what nphies lists as the current business version.