We’re in the early stages of planning another HSCIC Spine Connectathon, to be held at the UK eHealth Week event (it’s a slightly misnamed 2 day ‘week’ - the 19th and 20th April 2016)
As attendees of previous Skunkworks and HSCIC Connectathons, at EHI Live November 2015 and the HSCIC Open Day in Feb 2016, I’d like to hear from you what sort of things you would like us to do at the April connectathon.
I’m planning to have the Spine team available again to show developers, SMEs, etc how to connect to and transact with the NHS Spine services.
I’m also hoping to be able to spend some time doing some ‘guerrilla’ work on the Spine developer documentation, to make it easier to access, and easier to get started with.
We should also have better representation from the people who run OpenTest - the internet-facing Spine demo instance, which you can get access to. We’d like to work with them to make it easier to get an OpenTest account and get started testing Spine-connected applications.
Well, connectathons are about connecting systems up. For some things, I don’t really care how systems connect as long as they do. For other things I would prefer that systems were only connected under my control. I guess I’d like to see the concept of consent explored more as well as traditional interoperability solutions.
Enjoyed the last one but it would have been better if I’d been better prepared.
Similar to many NHS trusts developers, I was interested in getting Transfer of Care working. What I should have done is get Docker working beforehand and downloaded the HSCIC containers (if you’ve got docker installed: search for CIAO/HSCIC - although you can get away with a few it’s probably easier to download them all).
If your looking at using patient demographics service, I’d probably go for the ciao-pds-fhir docker container. Not sure of the stability/functionality but developing/using hl7 FHIR is around 10times faster than doing the same with (hl7v3) spine services.
@mayfield.g.kev would you consider writing a HOWTO: in a new thread, detailing (for n00bs) how you go about setting up these containers. You could probably start from the point ‘assuming you have Docker installed’ and go from there. It would be massively useful to the community if you could share your HOWTO with us all.
Docker part is very easy to get running (I was up and running as n00b within 5 mins). Didn’t get as far as configuring them due to lack of bandwidth for download 50Meg+ images.
Would really really recommend having documentation for how people can get going in a couple of hours or so if there’s any more connectathon run. It’s a great initiative, and it running will mean the state of documentation improves, and the general approach is to be commended.
If you have people travelling to an event, then it should be much further along in terms of usability, so as to maximise their time, and how they can contribute to the ecosystem.
Thanks @ianmoss, I’m really working on getting better and more usable developer documentation out there, although it’s hard as I am ‘outside’ HSCIC. I don’t have direct influence although my suggestions are acknowledged so there is potential for things to improve over time.
There is a will inside the HSCIC to get better at this stuff.
Who is the intended target for Spine connectivity?
I would have assumed middleware (& NHS trust integration) developers not app developers. Apps would connect to GP System or PAS system - so they are far more likely to use a simple FHIR interface (which is one of the main reasons came about - to insulate app developers from XML, SOAP, ebXML and all other types of complexity.)
Other problem is spine is you have to use NHS number which will exclude Patients apps can deal with (English/Welsh only).
@mayfield.g.kev the truthful answer is that I don’t think we fully know the answer.
You are absolutely right that middleware and integration devs are more likely to have an understanding and fluency in the right technologies to do Spine work, and therefore the average App developer would want a ‘higher-level’ interface than this, but:
GP suppliers (and I suspect many 2ndry care suppliers) have been slow to expose the kind of open, authenticated APIs and API management tools that we see outside of healthcare, eg if you look at the API portals for GoogleApps, Twitter, Trello, Twilio, Uber or anything out there on the Web.
I don’t think we can or should assume that all Apps developers will be able to (or will even want to) interact with a abstraction layer such as a GP system/PAS system - the really exciting apps of the future (which aren’t even imaginable now in the siloed landscape within which we work) would not want to be hemmed in by the limitations of a physical care boundaries, and so would need to work independently of GP systems / PAS APIs
So in truth, we’re actually finding out who we should be targeting the Connectathons to, by doing the Connectathons themselves. We’re gathering a lot of feedback about the developer documentation, the opentest signup process, etc which we’re passing back to HSCIC
I think @mayfield.g.kev puts a great question and has articulated something that was niggling me but I couldn’t put my finger on. Why are we doing this?
Spine isn’t designed or intended to have tens possibly hundreds of '000s of individual app users (clinicians and soon patients) connected to it at the same time. A huge hub and spoke type architecture. Of course this is quite common in the internet world but not in healthcare (at that scale).
The ethos of Spine is that primary/secondary/tertiary care systems connect via aggregators (middleware and the like). For Spine to do that would require careful (re)design, but it cuts to the heart of not just the Spine architecture but the whole philosophy of it, i.e. what is it, and what is it there to support?
These primary/secondary/tertiary systems support organisations who have geographic and functional care delivery boundaries. These organisations and the flows of patients, process and data between them are the shape they are because of how the NHS is designed to work in terms of care delivery and (largely) flow of money.
@pacharanero’s second point describes this new exciting world where apps aren’t tethered by physical care boundaries. It sounds great but implies to me a big shift in the whole way the NHS works. A radical change of this nature is probably vital to the NHS being able to keep pace with demand… ageing population, increasing obesity etc… but the prospect of yet another reorganisation and resulting five years plus of chaos before it beds in and starts to realise any benefits, is quite scary.
Back (somewhat) to the topic. What is Spine for and who should be its users? How can we architect now for a grand vision that seems very unclear from where I sit?
Connecting to the spine is a trick in its own right and the future most definitely looks “Spiney”. For example, the GP Connect program is to be a Spine service acting as an integration layer between GP system and the outside world. This service will be a great step forwards towards open interfaces, but I do have my reservations about the security and IG issues surrounding such an approach and am nervous about “Apps” connecting directly. That said, we need to have something to work with to crystallize the problems into something we can articulate and address.
I was going to edit my earlier post for being a bit negative.
I agree with @pacharanero about a open world and that’s a driver behind (open) FHIR API. We don’t have FHIR with UK Cerner yet but that’s a matter of time (US version can be found here http://fhir.cerner.com/) and I’d assume EPIC is similar (https://open.epic.com/Interface/FHIR). This is very similar to the API’s offered by Endeavour Health and Ripple (and over 10+ NHS trusts, ccgs or boards).
I would say it’s the job of these systems to connect to the spine and then provide equivalent open API’s. If HSCIC want apps to use the spine interfaces they should follow suit and offer a FHIR API - it would save everyone time and effort (or is this something for an open source project?).
Another reason for connecting to local systems is IG+trust concerns are reduced to workable levels. For example you can’t find a patient by NHS Number alone on the spine but you can via an intermediary system (if it knows of the patient). Suspect Endeavour Health will become the preferred way of connecting to GP systems and not spine/GPSoc or MIG - could be wrong though.
I definitely defer to everyone else who’se posted in terms of knowledge.
I was blown away by how much knowledge was in the room at the last connectathon, and the support that was offered.
I’m still pretty niave in the health systems that are out there, and would love to learn more.
I think there’s a lot of value in the NHS having one system that can deliver patient information to authorised applications, where the patient has authorised access.A lot of people seem to have burnt out attempting such things, so a drive to simplicity seems like a good effort to me.
Do system integrators (me) need to plugin to Spine? GPSoc? Should they use one format of the pateint record (CSR) or others? I don’t know. How do you identify people & can it be done simply? I don’t know.
If the benefit is that patients can have an improved level of care, because the healthcare records are more available to patients and appropiate 3rd parties, then it has to be a massive benefit.
Look forward to getting involved more, as time & budgets allow.
Don’t disagree with that. It just seems obvious we should all try to use the same format or model to exchange information (I’d argue this should be done bottom up rather than top down).
For me, it’s not whether an app should plug into the spine or not (thats down to app developer) but how it does it. Spine is a Service API and so typically the messages are large , bulky, use complex schemas and a number of interactions.
Normal pattern for enterprises ESB’s or applications is to facade these API’s into something simple.
