We’re preparing for witness testing with the IM1 team as part of acquiring access to the Partner API, and I wanted to understand what the usual process looks like.
For those who have been through this before:
Do they ask you to explain the use case first?
Do you need to share your screen and demonstrate the full end-to-end flow?
Do they focus mainly on the functionality and API usage, or do they also ask to review the code?
Is there anything specific we should prepare before the witness testing session?
Any guidance or experience would be really helpful. Thanks!
No code review, just the features that tickle the API
Use cases should be included in the SCAL docs you submitted to get to this point
Nothing special to worry about
Agenda for our one with EMIS in January. This was an RFC vs initial assurance, but process is the same.
*
A demonstration of the fully functional, release ready version of your solution
*
Error handling must include a user-friendly message with a clear instruction
*
Audit logs of all transaction calls
*
Logins within the solution: successful and unsuccessful (passwords - MFA, 16 char min, medium level of complexity)
*
Any patient data in the third-party product must match data in EMIS Web
Partner API Specifics:
*
Role Based Access Controls- Who has access to what
*
Get Matched Patient use - Solutions returns no data or shows error message when incorrect details are entered
*
Solution is able to refresh data correctly and on demand
*
All coded data being filed into EMIS Web must be SNOMED CT compliant
*
When filing, there is a clinician review in the product and no auto filling is completed without preapproval
*
Use of Get Current Patient ID- 2 EMIS Web clients/Instances open at the same time
*
API sessions are handled appropriately. Confirm Session Time-outs of the product
Good luck! How long did you wait to get to this point, if you don’t mind my asking…?
Thank you very much for your response regarding the witness testing. We’ve been waiting almost a year to get to this point, so I really appreciate your guidance.
The reason I’m asking in this much detail is that we’ve already waited a long time to reach the witness testing stage, and we really want to make sure we don’t miss anything that could result in another delay or having to wait again for a further testing slot.
Thanks again for sharing the witness testing points. I just have a few questions based on these requirements:
Do they usually ask infrastructure-related questions as well, such as where the application is hosted, server setup, database, security, or deployment architecture? If yes, do they normally ask us to show the infrastructure or just explain it?
For audit logs, we currently save each Partner API transaction in a separate audit database, including request and response details. During witness testing, will they expect us to demonstrate these logs live? Are there any specific fields or details they normally check in the audit logs?
We have one use case where a single user action triggers multiple Partner API calls. For example, we first get the required sessions, then book an appointment, and immediately update the appointment status to “Left.” Is there any concern with calling multiple Partner APIs sequentially as part of one workflow?
For API session handling and session timeout, do they usually ask us to show the timeout happening during the demo, or is explaining and showing the configured session behaviour enough?
For error handling, do they expect us to demonstrate different failure scenarios live, such as incorrect patient details, API failure, expired session, or unavailable EMIS Web connection?
For role-based access control, will they expect us to log in with different user roles and demonstrate what each user can and cannot access?
For patient data matching between our solution and EMIS Web, do they normally compare the data manually during the witness test, or just ask us to demonstrate the relevant patient workflow?
Is there anything else you would recommend we prepare in advance that commonly comes up during Partner API witness testing?
I’ll keep replying here vs DM as other might find it useful
Caveat: This is our experience - it does seem to be a bit “make-it-up-as-we-go-along” at times…
Yes. That’s again part of the SCAL (Architecture and CS & IG Tabs) and usually queried prior to a witness test. Can’t recall ever showing them our consoles etc other than demoing a full DR failover in GPSoC days.
We do the same. Just show them the events from an action in your service.
No problem with that, as long as they are within the acceptable uses for the interface. For example - you can’t use the transaction IM for patient facing stuff. If you’re battering an endpoint they might have an issue with it and ask for a change, though.
Can’t recall them ever asking that.
Yes - all that lot should be covered in the “IM1 Requirements” bit of the SCAL with screenshots, but they will want you to demo it.
Guess this depends on your use case, but they generally expect roles to be managed in EMAS manager. Unless you’re doing something particularly niche, I don’t think they’ll bother.
If there’s any manual or automatic linkage, they’ll want to see that in action.
I think you’ve covered it. Don’t skimp on the internal support for the call (i.e. make sure you have the domain gurus to hand) as you really want to finish everything on the call and not go back into the IM1 wait void
