GIIS Implementation Guide
0.1.8 - ci-build
GIIS Implementation Guide
0.1.8 - ci-build
GIIS Implementation Guide, published by CENS. This guide is not an authorized publication; it is the continuous build for version 0.1.8 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/cens-chile/giis_fhir_IG/ and changes regularly. See the Directory of published versions
Here you will find every transaction. They will have a diagram associated with each one and also the request and response of each transaction. Every transaction will have a link to an example with all the data (mandatory or not). To be able to make a transaction possible, you need to answer to the SMART protocol first here is an explanation of how does that works and here is a link to the SMART App Launch guide, which can have way more details.
Also, each transaction that is going to be shown here is a use case, which you can read in this section of the guide, and have brief explanations of what is expected.
From the external entity, the FHIR facade receives a POST with the Bundle related to the patient. The facade makes the transformation of the standardized data to send the query to the GIIS. Here is an example Bundle. This type of Bundle works just fine for either an adult or a child patient.
The example bundle comes with a related person, however, if the patient is an adult, it will never come with that information.
The external entity issues an HTTP POST type of operation, this operation will have every mandatory data plus any optional one, the FHIR Facade will receive this data and then transform it to standardized data to query it into the GIIS.
The FHIR Facade respond with a 201 Status Code, meaning that the data was stored succesfully, if everything is okay. On the other hand, if an error has ocurred, the code will be a 400 type of status code (400, 401, 403…) or a 500 Status Code meaning that there is a server type of error.
You can see an example of a request and response of every operation HERE
The external entity does a GET method to the FHIR facade in order for it to retrieve the data related to the searching being made. The FHIR Facade will then return a constructed Bundle resource with the requested data. Here is an example Bundle, the main difference is that the POST in that Bundle should be changed by a GET.
Notice that this GET has a patient.identifier value, this is to get the detail of this particular patient.
This GET method on the other hand, has some search parameters inside the GET, so this can get you from none to many patients with this parameters.
The external entity issues an HTTP GET type of operation, this operation will return every data corresponding to the type of search that is beign made (either by patient detail with the identifier or by search parameters).
The FHIR Facade responds with a 200 Status Code, returning the solicited data. If there is any type of error, there will be a 40X Status Code or a 500 Status Code meaning that there is a server type of error. If there’s a request for any of the two type of searches, it should return the same example bundle linked above.
The external entity will POST a Bundle resource in order to either register a new vaccination event or updating an existing one. Then the FHIR Facade will transform the data to query it into the GIIS. The updating of the data is handled internally on GIIS, so this example works just fine for both registering or updating a vaccination event.
There will be two cases:
For the first case, when a registration of a new vaccination event is happening, the external entity will issue an HTTP POST of a new vaccination event with every data related to it, mandatory and optional.
The second case, when updating a vaccination event (this only happens with calendarized events), the external entity will issue an HTTP PUT of the update of the vaccination event, however, this can be kind of tricky cause this update is mainly made for the dates of this vaccination event, and also, it is made internally.
Even when the POST or PUT are not linked with a Bundle, when the request is made, the facade will build this resources as a Bundle. However, it is worth mentioning it here, so there’s no doubts about the vaccination events and the patients.
The response, for both cases, will be a 201 Status Code. If there is any type of error on the data, there will be a 40X Status Code or a 500 Status Code meaning that there is a server type of error.
For searching a vaccination event we are going to first search a Patient that will have all the vaccination events related to himself/herself, this will lead to the FHIR Facade retrieve data only related to this patient, in order to construct the Immunization Bundle. In the case of the childs, they will have from 1..* vaccination events, this is because of the vaccination calendar plus any vaccination made besides it. Adults, however, will have 0..* vaccination events related to them.
The external entity issues an HTTP GET type of operation by either the vaccination event id or the patient identifier(the case shown in the diagram).
The FHIR Facade will respond with a 200 Status Code with all the data that can come with the Id used. If there is any type of error on the data, there will be a 40X Status Code or a 500 Status Code meaning that there is a server type of error.
As the response is not a Bundle,it has every resource linked with each other as references.
You can see an example of a request and response of every operation HERE
The ESAVI registration will be made over a QuestionnaireResponse resource. This is made by reference on the ESAVI IG (to see more about it click here) but was modified with the minimal set of data required in the case of the GIIS, plus some changes of cardinalities in order to get a better solution.
The external entity will send the data, this time on a QuestionnaireResponse type of resource (see the example of an answered QuestionnaireResponse here) rather than a Bundle resource and the FHIR Facade will make the INSERT directly into the GIIS database.
The external entity issues an HTTP POST type of operation by sending the data needed in order to create the Aefi Case in the GIIS Database.
This QuestionnaireResponse resource is made by answering some questions from a Questionnaire resource that is beign referenced inside the QuestionnaireResponse. In this POST you will only find answered those questions related to the CREATE inside the database.
The FHIR facade response will be a 201 Status Code if everything goes well. Otherwise there will be a 40X Status Code or a 500 Status Code meaning that there is a server type of error.
This time the QuestionnaireResponse resource will have a Patient linked to it, so firstly, this Patient has to have an existing ESAVI. The method for making this update will be a PUT, and once again, the FHIR Facade will make the UPDATE directly intro the GIIS database.
The external entity issues an HTTP PUT type of operation by sending any data ONLY related to the Aefi Case, this means that if any other data, patient or vaccine related, should NEVER be updated.
The FHIR facade response, will be a 201 Status Code if everything goes well. Otherwise there will be a 40X Status Code or a 500 Status Code meaning that there is a server type of error.
The searching will be made by the Patient identifier or another searching parameter. The FHIR Facade will SELECT the corresponding data from the GIIS database and then return it to the external entity.
The external entity issues an HTTP GET type of operation, by the Patient identifier, the vaccination event id or a range of dates.
The FHIR facade response will be a 200 Status Code if everything goes well, with all the QuestionnaireResponse related to the parameter used, so if searched by a vaccination event id there should come all the ESAVIs/AEFIs related to that search, on the other hand, if the search is done by a range of dates, there will come EVERY ESAVI on that range. If the response is not a 200 Status Code there will be a 40X Status Code or a 500 Status Code meaning that there is a server type of error.
You can see an example of a request and response of every operation HERE