HOWTO: Getting an HSCIC Spine OpenTest Account

I just signed up for an OpenTest / Spine Demo Access account but found the documentation on the HSCIC site is a bit lacking, hence have written up a bit of a guide here:

What is OpenTest?

OpenTest is an Internet-facing development/testing environment for NHS Spine Services APIs

Why would I need an account if I’m coming to a Connectathon?

You probably wouldn’t need one while you’re actually at the Connectathon, as we usually have HSCIC Spine Team members there, with a portable dummy Spine Services instance running on a workstation laptop. You would connect to these via the LAN/WLAN at the Connectathon and would be able to interact with the Spine that way.

However, if you wanted to carry on working with a development/testing instance of the Spine Services after you left the Connectathon, then you’ll need to register for an OpenTest account.

How do I get an OpenTest account?

  • Go to the OpenTest registration page here: and email the HSCIC Solutions Assurance Helpdesk
  • At present, registration is via emailing the HSCIC Helpdesk. (The turnaround time for me when I registered was pretty fast, approximately 12-18 hours)
  • Compared with signing up for access to other developer/sandbox APIs, though, it’s a clunky and apparently manual method of signing people up, and hopefully there will be a way we can help the HSCIC to create a ‘developer portal’ such as we have with other web services that a developer might interact with.
  • further information is here:

What happens next?

  • You get an acknowledgement email from the helpdesk first.
  • In my case I then got another email saying they were going to send me an email with the credentials in it
  • and then I got an email like this:

Attachments11:00 (33 minutes ago)
to me

Thanks for your interest in Opentest. We’ve set up a VPN login and a Spine Endpoint for you:

Login: vpn-client-*******
Password: d****************e
ODS code: *******
Party key: **********
ASID: *******

Point a browser at and login using the above login/password details (login, do not connect). This will take you to a page where you can download a connection profile and/or pre-configured client software for your operating system of choice. The same login/password is used when you use that client to connect to the VPN.

We advise that you avoid using the “connect” option on the web page. We’ve had issues reported with people trying to use that with some versions of Firefox. If you’re using OSX “El Capitan” you’ll need to turn off SIP.

Once you’re connected you can check by pinging the Spine 2 Core instance on

For talking to Spine, the SDS instance is the “core” SDS that is accessed in clear on ldap:// with an anonymous bind to (o=nhs).

Test data for PDS is at the moment available on request but in future we’ll be adding a “self service” facility for test data.

A PKCS#12 containing your endpoint certificate, key and the certificates from the trust chain is attached. There is no password on the key. Separately these are:

Endpoint Certificate:


SubCA Certificate:

RootCA Certificate:

Kind regards,

Solution Assurance Service Desk

  • So hopefully you would get something similar!

In the coming weeks I will publish a step-by-step HOWTO: guide for connecting to the OpenTest instance from Linux, and I’m happy to add HOWTOs for other operating systems contributed by the community.


1 Like

Thanks for that, Marcus - it is very useful.

Opentest is currently on some pilot infrastructure in Whitehall, Leeds. It will be getting moved onto something more permanent (and more to the point with better internet bandwidth) over the next couple of months. That should also address some of the minor but annoying differences between Opentest and the “real” environments - and make it more maintainable for HSCIC. That should also include a populated CIS, e-RS at some point, and some improvements to the network structure.

We’re interested in more than just Spine. There is an instance of the NIST “xdstools” system being worked up, and because the Opentest network allows point-to-point communications it can be used for ITK, IHE and other protocols too.

Partly because it is a pilot, and partly because once you’re in it is “open”, we’ve not gone to the effort of making a user-driven sign-on system. The “contact the Service Desk” mechanism is working pretty well, and it is also giving us useful information. So I think we’ll be keeping that for a bit.

Documentation is another matter. Opentest is just a network behind a VPN that allows us to synthesise an N3-like (sort of) static IP network accessible over the public internet. The services on the Opentest network - Spine 2 core, CIS and so on - are the same code as run in the path-to-live and the live Spine. What you’ve given here is a useful primer which I think we should turn into a page on the DDC site. But it also points to the less than ideal state of developer documentation for Spine etc - especially for the legacy HL7v3 interfaces that don’t benefit from modern tools like Swagger.


If you’re following these instructions on Mac OSX, I had success using Tunnelblick VPN client (by just downloading the User Profile from the opentest site) and it avoided the need to disable SIP on OSX.

Does anybody know of any Python implementations, helper libraries, or even just code snippets for Spine connectivity?

Don’t want to start playing / creating things that have already been done and I can just start contributing to :slight_smile:

There are opensource Java and C# implementations of NHS Spine Message Handling Systems here:

@matthew.stibbs as far as I know there are no implementations or helper libraries in Python, Ruby, JavaScript, Go, Elixir, ObjC, Swift etc

The focus has mainly been on ‘enterprisey’ languages such as Java/C#, as most of the existing market is using these. I guess the Java version of SpineTools could be used to help make Android apps. As ever, due to the trust model of the Spine, the difficulty then faced is the problem of authenticating individual users.


I think it would be easier to just leave the complex interfacing in java and expose a REST proxy or facade to other languages.

Like Marcus mentions spine is an enterprise API and the majority of implementations are java or mumps (yes mumps!). We use mumps for all our spine interfaces and java for others, they all get exposed via JSON+RESTful interface for other languages (js, mumps + php).
You can secure the interface with OAuth2 which should in theory user based authentication to be passed to the spine (I’d love to know how though!)