MedMij:V2019.01 FHIR AllergyIntolerance
{{#customtitle:MedMij FHIR Implementation Guide AllergyIntolerance 2.0.0}}
Introduction
This page describes a patient's use case, in a personal health record (PHR) context, for exchanging allergy and intolerance data. Functional specification of this use case is described in the functional design wiki pages. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.
Actors involved
| Persons | Systems | FHIR Capability Statements | |||
|---|---|---|---|---|---|
| Name | Description | Name | Description | Name | Description |
| Patient | The user of a personal healthcare enviorment. | PHR | Personal health record |  CapabilityStatement: Client
|
AllergyIntolerance client requirements |
| Healthcare professional | The user of a XIS | XIS | Healthcare information system | CapabilityStatement: Server
|
AllergyIntolerance server requirements |
Use case: Retrieve AllergyIntolerance information
This FHIR implementation guide assumes that the PHR system is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right XIS nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, for whose context (token) has been established using the authentication mechanisms described in the 'Afsprakenstelsel'. Each XIS Gateway is required to perform filtering based on the patient associated with the context for the request, so only the records associated with the authenticated patient are returned. For this reason, search parameters should not be included for patient identification.
Introduction
The retrieve AllergyIntolerance transaction is used by the PHR to retrieve allergy and intolerance information from the XIS.
Actors
| Transaction group | Transaction | Actor | Role |
|---|---|---|---|
| Retrieve AllergyIntolerance(PULL) | Retrieve AllergyIntolerance request | Patient (using a PHR) | Request allergy and intolerance information from the XIS |
| Retrieve AllergyIntolerance response | Healthcare professional (using a XIS) | Serves allergy and intolerance information to the PHR |
Invocations
PHR: request message
The request message represents an HTTP GET query from the PHR to the XIS.
Trigger Events
When the patient(PHR) wants to obtain allergy and intolerance information, it issues a retrieve AllergyIntolerance request message.
Message Semantics
The PHR executes an HTTP GET conform to the FHIR RESTfull and search specification against the XIS's AllergyIntolerance endpoint. This search query has the following format.
GET [base]/AllergyIntolerance
Search Parameters
No query parameters are defined for this use case. The PHR searches on all AllergyIntolerance resources available for the patient using a HTTP GET on the AllergyIntolerance endpoint without parameters.
Expected Actions
The XIS shall process the query to discover AllergyIntolerance resources that match the patient in the context.
XIS: response message
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the allergy and intolerance medication information.
Trigger Events
The XIS completed processing of the Retrieve AllergyIntolerance request message.
Message Semantics
Based on the query results, the XIS will either return an error or success. When the XIS needs to report an error, it SHALL use HTTP error response codes and SHOULD include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not any AllergyIntolerance resources are found, the HTTP status code SHALL be 200.
The response message shall be a Bundle resource of type "searchset" containing zero or more FHIR resources as entries. If the XIS is sending warnings, the Bundle resource SHALL also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
Message resource content
The returned data to the PHR should conform to the ZIB AllergyIntolerance profile. The table below shows the relevant ZIBs and their profiles. The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.
|
|
MedMij uses the FHIR Packaging mechanism. This conveniently bundles all examples, profiles and other conformance resources you need into a single download. For more background information see the the FHIR implementation guide. This version of the information standard depends on Nictiz package 1.3.x. Please note that the direct links to the various conformance resources below will take you to the latest version, which might not match the package version. At time of writing, there is no way to render the conformance resource as found in the package. This is on the roadmap for Simplifier. |
| ZIB name NL | ZIB name EN | FHIR Resource | URL profile |
| Patient | Patient | Patient | http://fhir.nl/fhir/StructureDefinition/nl-core-patient |
| Zorgverlener | HealthProfessional | Practitioner | http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner |
| AllergieIntolerantie | AllergyIntolerance | AllergyIntolerance | http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance |
Expected Actions
The PHR processes the results according to application-defined rules. The PHR should be robust as the response may contain AllergyIntolerance information resources as mentioned in the former section.
Interactions, operations, search parameters
Interactions
The following logical interactions are needed for the retrieve medication information transaction:
Operations
No operations are defined or needed for this transaction.
Search parameters
No search parameters are defined or needed for this transaction.
Terminology, NamingSystems, Mappings
Terminology
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here here and can be downloaded as a .zip in XML or JSON format.
NamingSystems
Relevant NamingSystems can be found here.
Mappings
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found here.
All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
Annex: Document history
Release notes
Release notes can be found on the functional design page.
History
| Release | Date | Description |
|---|---|---|
| 2019.01 | 30-09-2019 |
|
| 2019.01 | 11-03-2019 |
|
| 2018.06 | 12-11-2018 | Added section about Terminology, NamingSystems, Mappings. |
| 2018.06 | 15-10-2018 | Added version in title, and document history. |