4. A web first organisation “We need to think about patients who choose to access us by looking on the web first, and then seek phone contact if that is what they need” Nick Chapman – NHS Direct CEO
6. The goals 40 online assessments / symptom checkers Covering over 200 clinical algorithms Produced by our Clinical Development Team Clinically safe Closely mirrors call centre processes Dispositions & explanations (Call 999, Go to A&E, Call-back from a nurse) Distributed via multiple channels Web, Digital television, Mobile devices,
7. Patients demand digital services Other NHS Services Symptoms Self Care Further triage required Call back
9. Principles & Guidelines Innovate and provide usable services Maximising benefits to the many rather than minimising risk to the few Lead in the use of best practice in usability and user centred design. Interoperable content and services, available for syndication Become the centre of excellence in digital health information services Empower patients to manage their own health and the health of their family supported by our clinicians.
10. Key requirements to fulfil Patient self service, where safe to do so Lower cost per transaction An engaging trusted user experience for patients Simple, reliable content management facilities Digital analytics to show patient demand and use Syndicated clinical content
11. 12 month stretch delivery plan Procure Partner-up with leading experts Build, migrate and change Test Launch Syndicate the HaSCs
13. Analytics NHS Direct’s online health and symptom checkers receive around 20,000 visits a day Busiest day of the week – Monday Peak usage – public holidays, health scares
16. The major challenges From phone algorithms to digitally delivered transactions Ensuring teams understand a patient centered design approach The H1N1 (Swine Flu) pandemics Measuring what we do digitally Project management – the size of the task
17. SiteCore was chosen because... It integrates with other Microsoft platforms Specifically Arezzo a clinical decision support tool from InferMed (Prime Contractor to NHS Direct) Easy to implement workflow It versions our content Inline editing out the box An easily accessed web interface An API to syndicate our services to other organisations Delivery of content across multiple channels A proven service used by major organisations
18. Building the solution Object mapping and Spark rendering Michael Edwards (@mikeedwards83)
19. Who is Eduserv? 11 years experience providing information services to public sector Not-for-profit registered charity with commercial approach 1st UK Sitecore Partner 8 years delivering Sitecore solutions
40. Why? Spark works how we want to work Spark has less friction than XSLT or Web Forms Speed, less time spent solving syntax problems Use an engine makes the solution easier
42. Q&A Twitter : #DreamcoreEU Roger Donald, Roger.Donald@nhsdirect.nhs.uk Michael Edwards, Michael.Edwards@eduserv.org.uk
Notes de l'éditeur
Features of the NHS Direct Website:Find Your Nearest – allows you to locate various health service near youHealth and Symptom Checkers – allows the user to self assess their healthDecision aids – help patients make decisions about treatments and medical testsSearch – Google powered site searchUrchin – used for analysing traffic on the siteNHS Choices & NHS Jobs – integration with third parties to provide a better service
Health and Symptom CheckersAllow the user to self assess their healthWill ask a series of questions that lead to a dispositionThe majority of site traffic goes through a Health and Symptom Checkers
Health and Symptom Checkers are delivered via the website, mobile web and XML. The XML feed allows third parties or other applications to use the Health and Symptom checkers
An example of a question that the user might be asked
When the user has answered enough questions for advice to be shown then the user might be presented with:GPSelf CareA&E999Callback
AHaSC is generated by combining data from the clinical decision engine (CDE) and Sitecore. The CDE decides which questions or advice to show the user, the content for the questions or advice is stored in Sitecore.
The CDE gives us an object model that we need to combine with Sitecore content
To do this we map the Sitecore content on to an object model using a persistence tier. Highlights:Property Attributes – indicate which fields to loadProperty types - automatic conversion from the Sitecore field to the required .NET TypeComplex types - custom types can be handled
This makes it very easy for use to pull data. We can ask for any item as a type using generics. Creating the object is handled by the persistence layer.We can also save data back to Sitecore using the persistence layer. The layer handles all mapping and conversion of data to and from Sitecore.
Demonstrates some of the data we can pull from Sitecore:Item fieldsLink items fields – i.e. fields that point at another item – this will even handle list of items returning them as a generic enumerationItem properties – e.gUrl, Id, PathAdhoc queries Parent and child relationsshipsThis allows us to fully model our Sitecore solution in an object model.
Requests for data are made through the ISitecoreService interface. This allows access to most of the basic ways of calling data from Sitecore. Since this is an interface and we are dealing with simple domain object we can fully mock this interface and fully unit test our code.
This is great because:We can focus on the business problem we are trying to solve, we don’t have to spend time making sure that mapping and conversion code work. We can also work in a full OO way and treat Sitecore as full OO data sourceDevelopment is quicker, we save time by not having to convert from the data type stored in the field to the data required by the application.We don’t have the boiler plate code in the project, e.g. converts a checkbox field to a boolean type, we know this works in the persistence tier and don’t worry about itWe can fully unit test our logic on our build server which leads to a more robust solution.
Now that we have a full object model of the content we are getting from Sitecore we needed a different method of rendering a page.
XSLT wouldn’t work with the object model and ASP.NET Web Forms is clunky.
Open source view engine that is designed to work with MVC. Luckily another member of our team created an MVC framework for Sitecore which was demonstrated at the last Dreamcore.
Advantages of spark:HTML dominates the follow of the content – you read the page as HTML rather than having to parse XSLT to HTML to understand what is going onThere less clutter which makes it easier to readIt works with our object modelAt runtime the template is compiled in to C# which makes it quickThere isn’t any view state which reduces the page payloadIt is much quicker than web forms
It was important that Spark was integrated directly into Sitecore and not bolted on. We wanted the user to assume that Sparks were native to Sitecore so they had to be accessible in the same manner a XSLTs and Sublayouts.
The template for a Spark is very simple, we just put the path to the Spark file that is being used. Note that all Spark files are include in a compiled assembly as embedded resources but this isn’t compulsory they can be stored on the file system.
We then need to tell Sitecore what it should do when it sees a Spark layout, this only takes a few lines of code.
Then we configure Sitecore to use our new rendering method. This allows us to use Spark alongside XSLTs and Sublayouts.
Why would you want to change the rendering engine?We want to work with a full object model, Spark allows this but XSLTs wouldn’tXSLT creates friction by polluting the content you want to render with lots of additional markupThe syntax is simpler in Spark which makes it quicker to write and easier to readUse an engine that makes the solution easier, i.e. if you want to output data in YAML find a rendering engine or create one that handles YAML.