Below mentioned are some business and processing rules to be kept in mind while implementing CMS:
The current implementation only leverages few FHIR R4 resources as defined in the 'Profiles & Transactions' section. Any resource other than that will not be stored.
When non-FHIR, or non-expected resources are passed in the context, CMS should return an error. CMS should not process the known resources.
CMS will process events in the order they come to the server. CMS will not be checking the timestamp of the event sent in. Hence for duplicate events CMS will ALWAYS overwrite the resources that were sent by the POST request.
Despite the fact that FHIRcast standard states that the server will validate and it SHALL only return FHIR resources that are authorized to be accessed with the existing OAuth 2.0 access_token, this rule is only applicable to same user or context. For this implementation, if the user can see the context in one app, they should be able to get it through a different app. Moreover, we do validate that the context belongs to the same user, so the chances of the data being hijacked by a different user are next to nill.
Every POST request to the CMS will contain an event and a FHIR resource. CMS back end service will only validate header details against the FHIR Resource (if required) and reject if does not match (i.e. Org Resource sent and does not match ORG UAO in the header, etc.). CMS back end will never build a FHIR resource, only inspect, and insert the resource.
For the event OH.userlogin:
If the hub.topic does not exist, it should return an error
If the hub.topic exists, it should return 200 with hub.topic
Powered by SIMPLIFIER.NET