MedMij:Vprepub-2019.01 FHIR GGZ

1 Introduction

The page describes the FHIR requirements for exchanging GGZ information between the patients and healthcare providers in the context of MedMij. The overarching FHIR requirements, described in the technical IG guide homepage, are applicable here.

2 Actors involved

Actors		Systems		FHIR Capability Statements
Name	Description	Name	Description	Name	Description
Patient	The user of a personal healthcare enviorment.	PHR	Personal health record	CapabilityStatement: Client	FHIR Client requirements
Healthcare professional	The user of a XIS	XIS	Healthcare information system	CapabilityStatement: Server	FHIR Server requirements

3 Boundaries and Relationships

The GGZ use case has similarities and differences with other use cases such as the BgZ, Medication Process, Vital Signs, GP Patient Data and Lab Results. These use cases use much of the same HCIM based FHIR profiles for exchanging information. Wherever possible every attempt is made to re-use the profiles as used in the BgZ. The GGZ use case also has unique profiles compared to the aforementioned use cases. In addition, it has a CareTeam profile without an underlying HCIM. A second thing to note is that while the selection criteria of certain sections like procedure do not match with the BgZ or other use cases, this does not affect the profiles in use. For example, it is irrelevant for the response profile for procedures if you request ' surgical procedures' or 'every procedure'.

4 Use case: retrieve GGZ information

4.1 List of invocations

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.

4.1.1 Client - PHR

The PHR system requests the patient's GGZ information using individual search interactions over multiple FHIR resources. The client can use multiple individual search operations based on specified search queries. A search interaction can be performed by an HTTP GET or command as shown:

GET [base]/[type]/{?[parameters]{&_format=[mime-type]}}

The table below shows in the first three columns the HCIM name in Dutch, in English and what HCIM content is requested. The last column shows the FHIR search queries to retrieve this information. The queries are based on the functional GGZ information exchange requirements, which are stated in the functional overview and shown in detail in this table. The queries, and more profoundly the response messages follow the profiles listed in the list of StructureDefinition section. The response content shall conform to these StructureDefinitions.

HCIM NL	HCIM EN	Content	Search URL
Patient	Patient	Identification, birthdate, gender, deceasedindicator, contact details, marital status, legal status, and general practitioner (practitioner or organization)	GET [base]/Patient?_include=Patient:general-practitioner
BurgerlijkeStaat	MaritalStatus	Known marital status	see Patient
Betaler	Payer	Insurance information	GET [base]/Coverage?_include=Coverage:payor:Patient&_include=Coverage:payor:Organization
BehandelAanwijzing	TreatmentDirective	All known treatment directives	GET [base]/Consent?category=http://snomed.info/sct|11291000146105
Wilsverklaring	AdvanceDirective	All known advance directives	GET [base]/Consent?category=http://snomed.info/sct|11341000146107
JuridischeStatus	LegalStatus	Known legal status	see Patient and FreedomRestrictingMeasures procedure
VrijheidbeperkendeMaatregelen	FreedomRestrictingMeasures	All known freedom restricting measures	"see Procedure" Due to legislation (the 'Wet verplichte ggz' (Wvggz)) HCIM FreedomRestrictingMeasures-v3.1 (release 2017) has become obsolete. Therefore, this version of the BgGGZ will not require the use and exchange of this HCIM.
Contactpersoon	Contact	First relation/contact	see Patient.contact
FunctioneleOfMentaleStatus	FunctionalOrMentalStatus	All known functional / mental status	GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006
Probleem	Problem	All known problems	GET [base]/Condition
Druggebruik	DrugUse	All known drug use	GET [base]/Observation?code=http://snomed.info/sct|228366006
Alcoholgebruik	AlcoholUse	All known alcohol use	GET [base]/Observation?code=http://snomed.info/sct|228273003
Tabakgebruik	TobaccoUse	All known tobacco use	GET [base]/Observation?code=http://snomed.info/sct|365980008
Woonsituatie	LivingSituation	Last known living situation	GET [base]/Observation/$lastn?code=http://snomed.info/sct|365508006
Gezinssituatie	FamilySituation	All known family situations	GET [base]/Observation?code=http://snomed.info/sct|365470003
GezinssituatieKind	FamilySituationChild	All known family situations of child patient	GET [base]/Observation?code=http://snomed.info/sct|55801000146105
Taalvaardigheid	LanguageProficiency	Known language proficiency	see Patient
ParticipatieInMaatschappij	ParticipationInSociety	All known participation in society status	GET [base]/Observation?code=http://snomed.info/sct|314845004
HulpVanAnderen	HelpFromOthers	All known help from others	GET [base]/CarePlan?category=http://snomed.info/sct|243114000
LaboratoriumUitslag	LaboratoryTestResult	Last known laboratory results per type (incl. medication levels like lithium)	GET [base]/Observation/$lastn?category=http://snomed.info/sct|275711006&_include=Observation:related-target&_include=Observation:specimen
AlgemeneMeting	GeneralMeasurement	All known questionaire (for example HONOS, OQ-45, CQ index, 4DKL) outcome scores.	GET [base]/Observation?category=http://hl7.org/fhir/observation-category|survey
Verrichting	Procedure	All known GGZ procedures (includes all known freedom restricting measures)	GET [base]/Procedure
TekstUitslag	TextResult	All known text results of GGZ procedures	GET [base]/DiagnosticReport
-	-	CareTeam: primary healthprofessional and other relevant healthprofessionals including the healthcare provider.	GET [base]/CareTeam?_include=CareTeam:participant
Zorgverlener	HealthProfessional	General Practitioner of the patient	see Patient, CareTeam
Zorgaanbieder	HealthProvider	General Practitioner's organization of the patient	see Patient, CareTeam

4.1.2 Server - XIS

Important sections of the FHIR specification for a server in this use case are the RESTful API section the search section.

4.1.2.1 Response to resource requests

If the search succeeds, the server SHALL return a 200 OK HTTP status code and the returned content SHALL be a Bundle with type = searchset containing the results of the search as a collection of zero or more resources in a defined order. The returned content SHALL conform to the StructureDefinition applicable for the specific HCIM request. The list of a StructureDefinitions relevant for this use case is shown in the following paragraph: List of StructureDefinitions

The result collection can be long, so servers may use paging. If they do, they SHALL use the method described below (adapted from RFC 5005 (Feed Paging and Archiving ) for breaking the collection into pages if appropriate. The server MAY also return an OperationOutcome resource within the searchset Bundle entries that contains additional information about the search; if one is sent it SHALL NOT include any issues with a fatal or error severity, and it SHALL be marked with a Bundle.entry.search.mode of outcome.

In order to allow the client to be confident about what search parameters were used as criteria by the server, the server SHALL return the parameters that were actually used to process the search. Applications processing search results SHALL check these returned values where necessary. For example, if the server did not support some of the filters specified in the search, a client might manually apply those filters to the retrieved result set, display a warning message to the user or take some other action.

In the case of a RESTful search, these parameters are encoded in the self-link in the bundle that is returned:

  <link>
    <relation value="self"/>
    <url value="http://example.org/Patient?identifier=[Patient-ID]/>
  </link>

Link to the relevant FHIR specification: http://hl7.org/fhir/STU3/http.html#search

4.1.2.2 Handling errors

If the search fails (cannot be executed, not that there are no matches), the return value is a status code 4xx or 5xx with an OperationOutcome. An HTTP status code of 403 signifies that the server refused to perform the search, while other 4xx and 5xx codes signify that some sort of error has occurred. The HTTP status code 404 is returned if a XIS did not implement an endpoint used in a request by a PHR. When the search fails, a server SHOULD return an OperationOutcome detailing the cause of the failure. For example, in case of a not implemented FHIR endpoint, the OperationOutcome would state that the resource type is not supported. Note: an empty search result is not a failure.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

• 400 Bad Request - search could not be processed or failed basic FHIR validation rules
• 401 Not Authorized - authorization is required for the interaction that was attempted
• 404 Not Found - resource type not supported, or not a FHIR end-point

In some cases, parameters may cause an error. For instance:

• A parameter may refer to a non-existent resource e.g. GET [base]/Observation?subject=101, where "101" does not exist
• A parameter may refer to an unknown code e.g. GET [base]/Observation?code=loinc|1234-1, where the LOINC code "1234-1" is not known to the server
• A parameter may refer to a time that is out of scope e.g. GET [base]/Condition?onset=le1995, where the system only has data going back to 2001
• A parameter may use an illegal or unacceptable modifier e.g. GET [base]/Condition?onset:text=1995, where the modifier cannot be processed by the server
• A data time parameter may have incorrect format e.g. GET [base]/Condition?onset=23%20May%202009
• A parameter may be unknown or unsupported

Where the content of the parameter is syntactically incorrect, servers SHOULD return an error. However, where the issue is a logical condition (e.g. unknown subject or code), the server SHOULD process the search, including processing the parameter - with the result of returning an empty search set, since the parameter cannot be satisfied.

In such cases, the search process MAY include an OperationOutcome in the search set that contains additional hints and warnings about the search process. This is included in the search results as an entry with search mode = outcome. Clients can use this information to improve future searches.

Link to relevant FHIR specification: http://hl7.org/fhir/STU3/search.html#errors

4.2 Interactions, operations, search parameters

4.2.1 Interactions

The following logical interactions are needed for the GGZ use case:

• Search

4.2.2 Operations

The following operation is needed for this use case.

• Last N Observations Query

The lastn query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results. The link will provide more detailed information and examples regarding this operation.

4.2.3 Search parameters

The following search parameter types and search result parameters need to be supported for this use case.

Search parameter types:

• token
  • Including modifier 'in'
• reference

Search result parameters:

• _include

4.3 List of StructureDefinitions

The profiles represent their entire respective HCIM and are applicable in a broader context than the exchange of GGZ information.

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.

HCIM NL	HCIM EN	FHIR Resource	FHIR Profile
Patient	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Betaler	Payer	Coverage	http://nictiz.nl/fhir/StructureDefinition/zib-Payer
BehandelAanwijzing	TreatmentDirective	Consent	http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective
Wilsverklaring	AdvanceDirective	Consent	http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective
JuridischeStatus*	LegalStatus*	Extension	http://fhir.nl/fhir/StructureDefinition/nl-core-patient or http://nictiz.nl/fhir/StructureDefinition/zib-FreedomRestrictingMeasures
VrijheidbeperkendeMaatregelen	FreedomRestrictingMeasures	Procedure	http://nictiz.nl/fhir/StructureDefinition/zib-FreedomRestrictingMeasures
FunctioneleOfMentaleStatus	FunctionalOrMentalStatus	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus
Probleem	Problem	Condition	http://nictiz.nl/fhir/StructureDefinition/zib-Problem
Woonsituatie	LivingSituation	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation
Druggebruik	DrugUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse
Alcoholgebruik	AlcoholUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse
Tabakgebruik	TobaccoUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse
Gezinssituatie	FamilySituation	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-FamilySituation
GezinssituatieKind	FamilySituationChild	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-FamilySituationChild
Taalvaardigheid	LanguageProficiency	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
ParticipatieInMaatschappij	ParticipationInSociety	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-ParticipationInSociety
HulpVanAnderen	HelpFromOthers	CarePlan	http://nictiz.nl/fhir/StructureDefinition/zib-HelpFromOthers
LaboratoriumUitslag	LaboratoryTestResult	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation
AlgemeneMeting	GeneralMeasurement	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-GeneralMeasurement
Verrichting	Procedure	Procedure	http://nictiz.nl/fhir/StructureDefinition/zib-Procedure
TekstUitslag	TextResult	DiagnosticReport	http://nictiz.nl/fhir/StructureDefinition/zib-TextResult
Zorgverlener	HealthProfessional	Practitioner	http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
Zorgaanbieder	HealthProfessional	Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization
-	-	CareTeam	http://fhir.nl/fhir/StructureDefinition/nl-core-careteam

* LegalStatus is a single concept of the HCIM FreedomRestrictingMeasures and does not represent a complete HCIM yet. This concept will become an indepentend HCIM in a future release of the HCIM.

Example instances of FHIR resources can be found on Simplifier. Please note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of any information standard.

5 Terminology, NamingSystems, Mappings

Relevant ValueSets, NamingSystems and ConceptMaps can be found in the packages referenced in the List of StructureDefinitions section.

The HCIM ValueSets used in the profiles are included in the package (or one of its dependencies). When a FHIR core ValueSet must be used instead of an HCIM ValueSet, a FHIR ConceptMap resource is provided to map the values between the two sets. An explanation about mappings can be found at in the overarching principles.

6 Release notes

Release notes can be found on the functional design page.