This portal provides an open platform for user feedback and product change requests. Anyone can add an idea and remain as a Guest, but please consider signing up so that others can see who has created the ideas!
Note: this is a public facing web portal, any text here can be viewed by anyone over the internet, so please consider carefully the content you wish to share and please do not post anything of a sensitive nature.
In the current version of the onboarding toolkit, resources can be set to Clinical Safety and Public to allow testing of resources prior to Go Live. Additional resources can be added, as they become available, but can only be sleeted from a prepopulated list. Additionally, resources of the same type cannot be added, for example Encounter or documents.
With the move towards data maturity projects, multiple resources of the same type will become more common and to follow the current practice of viewing restrictions set to Clinical Safety prior to Go Live approval, this would impact on live resources.
For example, at NLAG, there are four different encounter types, which will be delivered at different stages. If ED Encounters were to go live, then a month later Inpatient Encounters were to to be made available, to follow the approval process, the Encounters resource would have to be set to Clinical Safety until approval was gained to go live with Inpatient Encounters. This would also restrict the existing ED Encounter resource and disrupt access to the live resource.
Similarly, there is a likelihood that there will be more than one type of document resource, which would be similarly affected when additional documents were made available.
There would also have to be a consideration of how this would fit with the recent data standards work that has been completed. However, the ability to control an individual resource within a resource type would be of significant benefit to all data maturity projects going forward and will maintain the availability of existing live resources.
A work around has been provided that resolves this issue. Will mark as 'Will not implement'.
Hi, a further suggestion on how to implement this which might be easier / cheaper, and also avoid performance issues.
1) In the Console, add a new status against the Resources, so now there are three options:
Public
Clinical Safety (all items) <--- Cosmetic change of wording
Clinical Safety (granular) <--- This is new
2) When the new item for "Clinical Safety (granular)" is selected then:
It sets the status of the "real" Resource Type (eg Encounter) to "Public"
It adds behind-the-scenes a new Resource Type with a CS prefix (eg CS_Encounter) and status of "Clinical Safety". (Any Resource Type with this special prefix is purely behind-the-scenes and is invisible in the list on the Console screen)
It pops up a message box to inform the user "Resources of type <<Encounter>> will be publicly visible. Please load new items for clinical safety testing into the special Resource Type <<CS_Encounter>>"
And finally, when you change the status selection AWAY from "Clinical Safety (granular)" then it tidies up by deleting the CS_ prefixed Resource Type from the list for that Data Provider. (And pops up a message box "Resources of type <<CS_Encounter>> will no longer be visible. Now testing is complete, please ensure all data is migrated to the main <<Encounter>> resource type")
And that's about it. All the normal Exchange routing should just work, and be as efficient as normal, based on the Resource Type.
3) In the Portal, use this new prefix in queries where the user is doing granular Clinical Safety testing
The easiest way would probably be to clone the Panel and make a "Clinical Safety" version of it. Eg "Encounters - granular Clinical Safety testing", which is based on resource type "CS_Encounters" instead of normal "Encounters"
The final part of the puzzle is how the Data Provider swaps data items to-and-from between "CS_Encounter" vs "Encounter" - eg to release them when the testing is complete. And the answer to that is that the new "FHIR Fix" job can be used to very flexibly select and update the data items.
To be confirmed, but I think performance will be OK if we do it the way I suggest. Because then there will only ever be a very small number of clauses to check - ie only for organisations that are currently in Clinical Safety testing (as soon as the testing is finished then the restriction clauses will be deleted). That is the reason for suggesting that approach.
Needs to be estimated, but I do suspect - although a good feature to have - that it will not be a trivial piece of work
could I please ask about the urgency of this request and also how big a problem it will solve? As Tim points out it could be a large piece of work and we would probably have some concerns about performance as the system will need to traverse through a complex set of clauses before it's able to display the data
we may need to think more laterally for a solution...
Some thoughts on implementing this.
Currently there is the "Resources" screen for each data provider - this lists the resources available and gives a status of "Public" or "Clinical Safety" only.
- Remove the status, so that it becomes a simple list of Resources available
- Add a new section to the screen "Clinical Safety Testing Restrictions"
This new section would basically be a list of "WHERE" clauses to be applied to restrict the data returned
- This could just be the Resource type (eg all Encounters)
- Or it could be the Resource type plus other fields (eg Encounters of type Inpatient)
- There could be multiple restriction entries for a Resource type (eg Encounters of type Inpatient. AND another line for Encounters of type Outpatient)
- It would be nice if the screen offered a user-friendly way to enter the most common requirements (eg Resource Type, Encounter Type, Document Type). And then an "advanced" text box to enter "code" for anything else
On the backend there will need to be a fundamental rewrite. Currently the Clinical Safety restrictions are applied as the query comes in, based on the Resource Type (which is obvious from the query request). This will need to be moved and instead applied to the result set returned (as it is only then that we will know if the data matches these more complex critieria).
It will be quite a large piece of work!