If you know the port and you want to check it status, you can issue the terminal command lsof -i:<<portno>>

For example I have a docker image running on port 80, as you can see there are processes attached to this port making it unavailable 

(base) USMBP16pjamieso:FHIRZPM pjamieso$ lsof -i :80
COMMAND    PID     USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
trustd    1208 pjamieso   23u  IPv4 0x5eb92c9816be8ddf      0t0  TCP usmbp16pjamieso.fios-router.home:53920->192.229.211.108:http (ESTABLISHED)
trustd    1208 pjamieso   27u  IPv4 0x5eb92c98164d7a1f      0t0  TCP usmbp16pjamieso.fios-router.home:53921->192.229.211.108:http (ESTABLISHED)
com.docke 7158 pjamieso  755u  IPv6 0x5eb92c9337bb54a7      0t0  TCP *:http (LISTEN)

Haitem, I think there could be a misunderstanding. When you create a SQL projection of FHIR resources in your repository using the IRIS FHIR SQL Builder, the FHIR repository and the projected tables are automatically kept up to date. As you add FHIR data into your FHIR Repository, the projected table will contain the new data. Thus you don't need to take any action to perform real-time FHIR analytics.

Luis,

The major advantage of FHIR is that it is an open standard not controlled by the EMR vendors. However, I agree that it must live with other older standards that will not be "retired" soon. Nevertheless, the modern Restful nature of the standard, improved semantics, and openness, will eventually carry the day.

John,

I think you are on the right track, because creating all those certficates is the hardest part of using TLS/SSL. I am assuming you a running the Apache Web Server in a separate container from IRIS4Health but even if you are not you need to use the Web Gateway to establish secure transport from the Web Server to the IRIS4Health container. You can learn more about the Web Gateway here: https://docs.intersystems.com/irisforhealth20223/csp/docbook/DocBook.UI....
 

I key part of configuring the Server Access for TLS/SSL access is configuring the Connection Security. Here is an example of a deployment I used below:

 

 
Spoiler

 
Populating the paths to the certificates you created in the Web Gateway should enable a secure TLS/SSL connection. Good Luck.
 

I assume you are referring to 170.315(g)(10) certification. InterSystems is committed to helping customers get certified, but this is a complex process with many tests, administered through a test suite called INFERNO. I would urge you to contact your account representative if you are aiming for g(10) certification, which has a deadline of 12/31/2022.  HealthShare has many SDA transformations to FHIR that may be useful.

FHIR subscriptions are still immature FHIR technology, but much progress has been made. Early next year FHIR will add more mature resources to support FHIR subscriptions with FHIR R5. FHIR subscriptions are on our roadmap for next year after R5 is released. In the meantime, you can build a production and implement custom logic that can duplicate some of this functionality.

If you look under the "Bundle Operations" tab of the Data Management section of the IRIS FHIR Accelerator (of FHIR Server) deployment, you will see a variety of Synthetic Data Sets, including one with 390,346 resources you can easily select and load into the FHIR Server. If that is not enough, you can generate Synthetic data yourself (https://synthetichealth.github.io/synthea/) and upload it into the portal.

Probably the best way to avoid these duplicate POSTs is to use conditional update. 

The conditional update interaction allows a client to update an existing resource based on some identification criteria, rather than by logical id. To accomplish this, the client issues a PUT as shown:

  PUT [base]/[type]?[search parameters]

When the server processes this update, it performs a search using its standard search facilities for the resource type, with the goal of resolving a single logical id for this request. The action it takes depends on how many matches are found:

  • No matches, no id provided: The server creates the resource.
  • No matches, id provided: The server treats the interaction as an Update as Create interaction (or rejects it, if it does not support Update as Create)
  • One Match, no resource id provided OR (resource id provided and it matches the found resource): The server performs the update against the matching resource
  • One Match, resource id provided but does not match resource found: The server returns a 400 Bad Request error indicating the client id specification was a problem preferably with an OperationOutcome
  • Multiple matches: The server returns a 412 Precondition Failed error indicating the client's criteria were not selective enough preferably with an OperationOutcome

You can read about this operation type here: https://www.hl7.org/fhir/http.html#update