MedMij:Vpoc 1.0/FHIR iWlz: verschil tussen versies

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen
(Publish 1.0 version iWlz specification for Proof Of Concept)
 
 
(13 tussenliggende versies door 2 gebruikers niet weergegeven)
Regel 1: Regel 1:
 
__NUMBEREDHEADINGS__
 
__NUMBEREDHEADINGS__
 
__NOINDEX__
 
__NOINDEX__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: iWlz 1.0 Proof of concept (1.0-poc1) {{Sjabloon:VersieInfo|iWlz}}}}
+
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: iWlz 1.0 Proof of concept (1.0-poc8) {{Sjabloon:VersieInfo|iWlz}}}}
 
{{NoteBox|This version will be tested in a proof of concept and should not be used outside this POC}}
 
{{NoteBox|This version will be tested in a proof of concept and should not be used outside this POC}}
  
Regel 19: Regel 19:
 
This page describes the exchange of iStandaard Wet langdurige zorg ([https://istandaarden.nl/istandaarden/iwlz iWlz]) related resources using the HL7 FHIR standard. This page and all the materials provided on it are in beta version, with a goal of testing the exchange trough a Proof of Concept (PoC) within MedMij.
 
This page describes the exchange of iStandaard Wet langdurige zorg ([https://istandaarden.nl/istandaarden/iwlz iWlz]) related resources using the HL7 FHIR standard. This page and all the materials provided on it are in beta version, with a goal of testing the exchange trough a Proof of Concept (PoC) within MedMij.
  
This IG is a technical representation of the [[MedMij:Vpoc_1.0/OntwerpiWlz|functional design]] and follows the principles of the [[MedMij:V2020.01/FHIR_IG|general MedMij FHIR IG]].
+
This IG is a technical representation of the [[MedMij:Vprepub-poc_1.0/OntwerpiWlz|functional design]] and follows the principles of the [[MedMij:V2020.01/FHIR_IG|general MedMij FHIR IG]].
  
 
=Actors involved=
 
=Actors involved=
Regel 67: Regel 67:
 
The 'indicatiegegevens' are built up of individual FHIR resources, selected by the user of the XIS to form a coherent set of information relevant to the client. The Composition resource assembles the references to all individual related FHIR resources. For this purpose, the Composition profile described in [[#FHIR profiles|FHIR profiles]] SHALL be used.
 
The 'indicatiegegevens' are built up of individual FHIR resources, selected by the user of the XIS to form a coherent set of information relevant to the client. The Composition resource assembles the references to all individual related FHIR resources. For this purpose, the Composition profile described in [[#FHIR profiles|FHIR profiles]] SHALL be used.
  
Retrieving all 'indicatiegegevens' is a two-step process. Firstly, the available Composition resources are retrieved. The PHR, or the client of the PHR, selects the desired Composition. The {{fhir|Composition.id}} of the selected Composition is used for the second step in which all related information is retrieved.
+
The PHR can retrieve all available Composition resources ''and'' all referenced resources as a single searchset Bundle by using the following {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/iwlz-Indicaties|nictiz.fhir.nl.stu3.iwlz|title=custom operation}}<ref>Originally, this was a two step process using the FHIR core {{fhir|$document}} operation. However, this use case does not match the intended use of this operation. Discussions are ongoing on the introduction of a new operation in a future version of FHIR to be able to search and retrieve document Compositions simultaneously, see {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/iwlz-Indicaties|nictiz.fhir.nl.stu3.iwlz|title=the OperationDefinition}} for more information.</ref>:
 +
<pre>GET [base]/Composition/$indicaties</pre>
  
The first step can be omitted, if a different mechanism to transfer the {{fhir|Composition.id}} to the PHR is implemented.
+
The result is a searchset Bundle with all Compositions available ''and'' all referenced resources. ''Note:'' the Composition lists just the resources that act as entry points for the various concepts in the transaction, but each of these referenced resources may further refer to other resources not listed there. The server SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.
  
==Retrieve all Composition resources==
+
The Compositions returned can be sorted and/or presented to the user by the PHR based on {{fhir|Composition.event.period}} to determine active and/or the most recent 'indicatie'.
Using a [http://hl7.org/fhir/STU3/search.html search operation], the PHR retrieves Composition resources that represent the 'indicatiebesluit' from the XIS using the following predefined search operation.
 
  
<pre>GET [base]/Composition?type=http://snomed.info/sct|304784009</pre>
+
Because each Composition resource and the resources it references are a set of coherent resources that are a representation of the 'indicatie' and that cannot be interpreted individually, XIS Servers are not expected to support resolving the individual resources of the Composition document Bundle by their {{fhir|fullUrl}}. PHR systems should only use the document operation to retrieve the 'indicatie' in full.
 
 
The PHR (or its client) filters the selects or filters the {{fhir|Composition.id}} of the 'indicatiebesluit' that is to be retrieved in full. In most cases, only one Composition resource is available, but otherwise the most recent Composition (base on {{fhir|Composition.date}}) should generally be selected.
 
 
 
==Retrieve selected Composition document Bundle==
 
The PHR uses the {{fhir|Composition.id}} retrieved during the preceding step and the [http://hl7.org/fhir/stu3/composition-operations.html#document {{fhir|$document}} operation] to retrieve both the Composition ''and'' all referenced resources as a single document Bundle.<br/> <pre>GET [base]/Composition/[id]/$document</pre> ''Note:'' the Composition lists just the resources that act as entry points for the various concepts in the transaction, but each of these referenced resources may further refer to other resources not listed there. The server SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.
 
  
 
The data returned to the PHR should conform the profiles listed in the table below and (if applicable) their associated HCIMs. The resources in the response message SHALL be a valid instance of these profiles.
 
The data returned to the PHR should conform the profiles listed in the table below and (if applicable) their associated HCIMs. The resources in the response message SHALL be a valid instance of these profiles.
  
{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0|p2=nictiz.fhir.nl.stu3.iwlz|v2=0.0.1}}
+
{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0|p2=nictiz.fhir.nl.stu3.iwlz|v2=1.0.0-poc8}}
  
 
{| class="wikitable"
 
{| class="wikitable"
Regel 92: Regel 87:
 
|-
 
|-
 
| style="font-weight: bold;" | iwlz-Indicatie
 
| style="font-weight: bold;" | iwlz-Indicatie
| style="font-weight: bold;" | Observation
+
| style="font-weight: bold;" | Composition
 
| style="font-weight: bold;" |  
 
| style="font-weight: bold;" |  
 
| style="font-weight: bold;" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/iwlz-Indicatie|nictiz.fhir.nl.stu3.iwlz}}
 
| style="font-weight: bold;" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/iwlz-Indicatie|nictiz.fhir.nl.stu3.iwlz}}
 +
|-
 +
| iwlz-Beperking
 +
| Observation
 +
|
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/iwlz-Beperking|nictiz.fhir.nl.stu3.iwlz}}
 +
|-
 
|-
 
|-
 
| iwlz-BeperkingScore
 
| iwlz-BeperkingScore
Regel 125: Regel 126:
 
|
 
|
 
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/iwlz-StoornisScore|nictiz.fhir.nl.stu3.iwlz}}
 
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/iwlz-StoornisScore|nictiz.fhir.nl.stu3.iwlz}}
 +
|-
 +
| colspan="4" | ''The following nl-core profiles are used to reference an Organization in the iwlz-Indicatie {{fhir|Composition.author}}''
 +
|-
 +
| nl-core-practitionerrole
 +
| PractitionerRole
 +
|
 +
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
 +
|-
 +
| nl-core-organization
 +
| Organization
 +
| HealthcareProvider
 +
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
 
|}
 
|}
  
=Use case: send client preferences=
+
== Custom Operation ==
 +
The following custom operation is used: {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/iwlz-Indicaties|nictiz.fhir.nl.stu3.zib2017}}.
 +
 
 +
=Use case: send client profile=
 
This use case applies when a client qualifies for receiving long term care based on the WLZ and the client wants to share his preferences, contact information and contact persons.
 
This use case applies when a client qualifies for receiving long term care based on the WLZ and the client wants to share his preferences, contact information and contact persons.
  
The client preferences are based on a iwlz-Clientvoorkeuren-Questionnaire resource to be filled by the client, leading to an iwlz-Clientvoorkeuren-QuestionnaireResponse resource. The contact information and contact persons filled by the client lead to an edited iwl-Persoon Patient resource. To
+
The client preferences are based on a iwlz-Clientvoorkeuren-Questionnaire resource to be filled by the client, leading to an iwlz-Clientvoorkeuren-QuestionnaireResponse resource. The contact information and contact persons filled in or edited by the client lead to an edited iwl-Persoon Patient resource.
 
 
==Retrieve latest Patient resource==
 
To ensure that the PHR's client sees and edits the up-to-date information available, the latest version of the Patient resource is retrieved. If {{fhir|Patient.id}} is not known from the previous use case, where the Patient resource was present in the Document Bundle, or if a significant period of time has expired between retrieving the 'indicatiebesluit', a {{fhir|search}} interaction has to be done:
 
 
 
<pre>
 
GET [base]/Patient
 
</pre>
 
 
 
The server SHOULD return only one Patient resource. This resource and its {{fhir|id}} can be used by the PHR for further processing.
 
  
 
==Send transaction Bundle==
 
==Send transaction Bundle==
 
 
The PHR initiates a [https://www.hl7.org/fhir/stu3/http.html#transaction FHIR transaction] by sending an HTTP POST request composed of a FHIR Bundle resource containing one QuestionnaireResponse resource and one Patient resource to the XIS's base endpoint as shown below.
 
The PHR initiates a [https://www.hl7.org/fhir/stu3/http.html#transaction FHIR transaction] by sending an HTTP POST request composed of a FHIR Bundle resource containing one QuestionnaireResponse resource and one Patient resource to the XIS's base endpoint as shown below.
  
Regel 149: Regel 155:
 
</pre>
 
</pre>
  
In this transaction Bundle, the Patient resource has an {{fhir|entry.request.method}} of 'PUT' ({{fhir|update}} interaction), the QuestionnaireResponse has a {{fhir|method}} of 'POST' ({{fhir|create}} interaction).
+
In this transaction Bundle, both the Patient resource and the QuestionnaireResponse have an {{fhir|entry.request.method}} of 'POST' ({{fhir|create}} interaction).
 +
 
 +
''Note:'' because the PHR's client can only edit several parts of the resource, the {{fhir|create}} interaction does not force the server to accept the entire resource as is. For example, the updated content may be reviewed before merging it with the exisitng information. Performing a {{fhir|read}} interaction on the Patient resource shortly after 'POST'ting an edited version may therefore lead to unexpected results. See the [https://www.hl7.org/fhir/stu3/http.html#transactional-integrity FHIR specification on transactional integrity] for more discussion. However, it is the responsibility of the server to maintain only one version of the Patient resource.
  
''Note:'' because the PHR's client can only edit several parts of the resource, the {{fhir|update}} interaction does not force the server to accept the entire resource as is. For example, the updated content may be reviewed before merging it with the exisitng information. Performing a {{fhir|read}} interaction on the Patient resource shortly after 'PUT'ting an edited version may therefore lead to unexpected results. See the [https://www.hl7.org/fhir/stu3/http.html#transactional-integrity FHIR specification on transactional integrity] for more discussion. However, it is the responsibility of the server to maintain only one version of the Patient resource.
+
Because of the static nature of the iwlz-Clientvoorkeuren-Questionnaire within this PoC, see also [[MedMij:Vprepub-poc_1.0/FHIR_iWlz#Use_of_Questionnaire_and_QuestionnaireResponse_profiles|this paragraph]], there is no explicit connection between the QuestionnaireResponse and the Questionnaire resources using the {{fhir|QuestionnaireResponse.questionnaire}} element. The PHR can use any preferred method to compose the QuestionnaireResponse resource, as long as it conforms to the profile. For each {{fhir|QuestionnaireResponse.item}}, the PHR SHOULD fill the {{fhir|.item.text}} element with the exact text that is used during user input.
  
 
The PHR shall guarantee consistency of all FHIR resource elements with the profiles listed in the table below and (if applicable) their associated HCIMs. The resources in the request message SHALL be a valid instance of these profiles.
 
The PHR shall guarantee consistency of all FHIR resource elements with the profiles listed in the table below and (if applicable) their associated HCIMs. The resources in the request message SHALL be a valid instance of these profiles.
  
{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0|p2=nictiz.fhir.nl.stu3.iwlz|v2=0.0.1}}
+
{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0|p2=nictiz.fhir.nl.stu3.iwlz|v2=1.0.0-poc8}}
  
 
{| class="wikitable"
 
{| class="wikitable"
Regel 187: Regel 195:
  
 
=Release notes=
 
=Release notes=
Release notes can be found on the [[MedMij:Vpoc_1.0//OntwerpiWlz#Release_notes| functional design page]].
+
Release notes can be found on the [[MedMij:Vprepub-poc_1.0//OntwerpiWlz#Release_notes| functional design page]].

Huidige versie van 9 nov 2022 om 10:29


Naar medmij.nl
AfsprakenstelselFunctioneelTechnischAfspraken-Functioneel-Technisch

1 Introduction

Go to functional design

This page describes the exchange of iStandaard Wet langdurige zorg (iWlz) related resources using the HL7 FHIR standard. This page and all the materials provided on it are in beta version, with a goal of testing the exchange trough a Proof of Concept (PoC) within MedMij.

This IG is a technical representation of the functional design and follows the principles of the general MedMij FHIR IG.

2 Actors involved

The table shows the relevant actors, systems and FHIR CapabilityStatements. The CapabilityStatements demonstrate the minimum conformance requirements for the described use cases.

Actors Systems FHIR CapabilityStatements
Name Description Name Description Name Description
Client The user of a personal healthcare environment 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

Go to Afsprakenstelsel

This FHIR implementation guide assumes that the PHR system is able to make a connection to search resources at the XIS. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the 'MedMij Afsprakenstelsel'.

The MedMij 2020.01 FHIR IG is applicable to the PoC mentioned in the introduction, unless specifically noted. Some parts of this IG, where noted, are only relevant to the PoC.

Because of the specific use cases to be tested within the PoC, 'closed modeling' as specified in the FHIR STU3 Profiling Guidelines has been chosen over 'open modeling'. This allows implementers to focus on the elements that are needed for a successful exchange within the PoC. It is expected that in future versions, 'open modeling' will again be preferred in line with other information standards.

There are two pairs of Questionnaire/QuestionnairResponse resources used within this standard, one of which is being used to capture Client input. For the PoC this Questionnaire is assumed to be static. In future iterations, the use case could be extended to first retrieve the latest version of the Questionnaire from the XIS that will be used by the client to provide a QuestionnaireResponse, which is the use case of the Questionnaires information standard. Discussions on how this standard would incorporate the Questionnaires standard are ongoing.

Within the PoC, 'abonneren' (subscribe) and 'notificeren' (notify) mechanisms are to be tested. These mechanisms are not part of the FHIR IG, their specifications can be found at MedMij Afsprakenstelsel (abonneren, notificeren).

4 Use case: retrieve 'indicatiegegevens'

The 'indicatiegegevens' are built up of individual FHIR resources, selected by the user of the XIS to form a coherent set of information relevant to the client. The Composition resource assembles the references to all individual related FHIR resources. For this purpose, the Composition profile described in FHIR profiles SHALL be used.

The PHR can retrieve all available Composition resources and all referenced resources as a single searchset Bundle by using the following custom operation[1]:

GET [base]/Composition/$indicaties

The result is a searchset Bundle with all Compositions available and all referenced resources. Note: the Composition lists just the resources that act as entry points for the various concepts in the transaction, but each of these referenced resources may further refer to other resources not listed there. The server SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.

The Compositions returned can be sorted and/or presented to the user by the PHR based on Composition.event.period to determine active and/or the most recent 'indicatie'.

Because each Composition resource and the resources it references are a set of coherent resources that are a representation of the 'indicatie' and that cannot be interpreted individually, XIS Servers are not expected to support resolving the individual resources of the Composition document Bundle by their fullUrl. PHR systems should only use the document operation to retrieve the 'indicatie' in full.

The data returned to the PHR should conform the profiles listed in the table below and (if applicable) their associated HCIMs. The resources in the response message SHALL be a valid instance of these profiles.

Profile name FHIR Resource Based on HCIM Canonical
iwlz-Indicatie Composition http://nictiz.nl/fhir/StructureDefinition/iwlz-Indicatie
iwlz-Beperking Observation http://nictiz.nl/fhir/StructureDefinition/iwlz-Beperking
iwlz-BeperkingScore Observation http://nictiz.nl/fhir/StructureDefinition/iwlz-BeperkingScore
iwlz-Persoon Patient Patient
ContactPerson
NameInformation
ContactInformation
http://nictiz.nl/fhir/StructureDefinition/iwlz-Persoon
iwlz-GeindiceerdZorgzwaartepakket-Questionnaire Questionnaire http://nictiz.nl/fhir/StructureDefinition/iwlz-GeindiceerdZorgzwaartepakket-Questionnaire
iwlz-GeindiceerdZorgzwaartepakket-QuestionnaireResponse QuestionnaireResponse http://nictiz.nl/fhir/StructureDefinition/iwlz-GeindiceerdZorgzwaartepakket-QuestionnaireResponse
iwlz-Stoornis Condition http://nictiz.nl/fhir/StructureDefinition/iwlz-Stoornis
iwlz-StoornisScore Observation http://nictiz.nl/fhir/StructureDefinition/iwlz-StoornisScore
The following nl-core profiles are used to reference an Organization in the iwlz-Indicatie Composition.author
nl-core-practitionerrole PractitionerRole http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
nl-core-organization Organization HealthcareProvider http://fhir.nl/fhir/StructureDefinition/nl-core-organization

4.1 Custom Operation

The following custom operation is used: http://nictiz.nl/fhir/OperationDefinition/iwlz-Indicaties.

5 Use case: send client profile

This use case applies when a client qualifies for receiving long term care based on the WLZ and the client wants to share his preferences, contact information and contact persons.

The client preferences are based on a iwlz-Clientvoorkeuren-Questionnaire resource to be filled by the client, leading to an iwlz-Clientvoorkeuren-QuestionnaireResponse resource. The contact information and contact persons filled in or edited by the client lead to an edited iwl-Persoon Patient resource.

5.1 Send transaction Bundle

The PHR initiates a FHIR transaction by sending an HTTP POST request composed of a FHIR Bundle resource containing one QuestionnaireResponse resource and one Patient resource to the XIS's base endpoint as shown below.

POST [base]

In this transaction Bundle, both the Patient resource and the QuestionnaireResponse have an entry.request.method of 'POST' (create interaction).

Note: because the PHR's client can only edit several parts of the resource, the create interaction does not force the server to accept the entire resource as is. For example, the updated content may be reviewed before merging it with the exisitng information. Performing a read interaction on the Patient resource shortly after 'POST'ting an edited version may therefore lead to unexpected results. See the FHIR specification on transactional integrity for more discussion. However, it is the responsibility of the server to maintain only one version of the Patient resource.

Because of the static nature of the iwlz-Clientvoorkeuren-Questionnaire within this PoC, see also this paragraph, there is no explicit connection between the QuestionnaireResponse and the Questionnaire resources using the QuestionnaireResponse.questionnaire element. The PHR can use any preferred method to compose the QuestionnaireResponse resource, as long as it conforms to the profile. For each QuestionnaireResponse.item, the PHR SHOULD fill the .item.text element with the exact text that is used during user input.

The PHR shall guarantee consistency of all FHIR resource elements with the profiles listed in the table below and (if applicable) their associated HCIMs. The resources in the request message SHALL be a valid instance of these profiles.

Profile name FHIR Resource Based on HCIM Canonical
iwlz-Persoon Patient Patient
ContactPerson
NameInformation
ContactInformation
http://nictiz.nl/fhir/StructureDefinition/iwlz-Persoon
iwlz-Voorkeurscriteria-Questionnaire Questionnaire http://nictiz.nl/fhir/StructureDefinition/iwlz-Voorkeurscriteria-Questionnaire
iwlz-Voorkeurscriteria-QuestionnaireResponse QuestionnaireResponse http://nictiz.nl/fhir/StructureDefinition/iwlz-Voorkeurscriteria-QuestionnaireResponse

6 Additional remarks

6.1 Terminology

Discussions with Zorginstituut Nederland are ongoing on how to release and maintain their terminology resources. At the moment, a ValueSet and CodeSystem per 'codelijst' and bound to the applicable elements in the profiles. The CodeSystem resources do not contain the actual codes. These can be found at [1] (Excel-file). Notable exception is COD1001, which is available on GitHub.

6.2 Use of Questionnaire and QuestionnaireResponse profiles

According to the FHIR specification, a QuestionnaireResponse resource can be validated against its Questionnaire counterpart. However, it is unclear if this is supported by validators. Furthermore, it is not clear if the Questionnaire profiles and instances will actually be used in the process of composing the QuestionnaireResponse resource. Therefore, both a Questionnaire and a QuestionnaireResponse profile have been created for 'Geindiceerd Zorgzwaartepakket' and 'Clientvoorkeuren'. The QuestionnaireResponse profile describes the exact information exchange between systems and can be used for validation purposes.

7 Release notes

Release notes can be found on the functional design page.

  1. Originally, this was a two step process using the FHIR core $document operation. However, this use case does not match the intended use of this operation. Discussions are ongoing on the introduction of a new operation in a future version of FHIR to be able to search and retrieve document Compositions simultaneously, see the OperationDefinition for more information.