NHS Developer Network
HANDI – 8th April 2013
George Hope
Agenda
• Developer Network • Purpose of the Reference Implementation• Demo of the Reference Implementation– Scenarios Based– Synchronous and Asynchronous examples
• Any suggestions on areas for improvement (content)
• Next Steps
NHS England sponsored site
•Community focused
•Forums for discussions
•Join with your OpenID and introduce yourself and project
•More content to be added soon, crypto etc
•Portal entry point for Interoperability Framework information
•RSS alerts on implementation notes
•Searchable ITK reference of RI with interaction diagrams
https://developer.nhs.uk/community-forums/forum/nhs-interoperability-framework/
Join with your OpenID and introduce yourself and your project
developer.nhs.uk
Testing and Tools
Ability to stand up testing tools and services to support community in understanding
ITK Reference Samples - http://services.developer.nhs.uk/itk-samples/
2 VMs running ITK services
Join with your OpenID and introduce yourself and your project
developer.nhs.uk
ITK Reference Implementation
HANDI – 8th April 2013
George Hope
Purpose of the Reference Implementation
• Feedback is that specifications are not user friendly• The specifications are verbose with related requirements
“sprinkled” across a number of documents.• Technically the requirements are not complex – this needs to
be demonstrated• We HSCIC need to Road Test the specifications to identify
areas for improvement• We HSCIC need to be able to assess the impact of future
change• A Resource to assist in the process of developing components
that are looking to become ITK Accredited
Developer Network ITK Objectives
• Focus on the areas where most ITK developments are placed.• Provide focus on the transport and integration layer (not
business content/payload)• Create a living reference implementation that shows how the
specifications can be implemented• Provide freely available open source software, published on
the developer network.– Easy to use– Intuitive– Online
What does v0.1 consist of?•Transp
ort and distribution layers of ITK
•Jar containing the Java interfaces and required exceptions
ITK-API
•Jar containing the reference implementation (including base Servlets)
ITK-Reference Implementation
•Business payloads covered by ITK specification (e.g. SMSP; EPaCCS)
ITK-Sample Messages
•War containing example usage of the ITK-RI
•Scenarios: 2x SMSP; Sync ADT; Async ADT; Send non-coded CDA; Application Emulator; Doc Store; Send Notification (AH)
ITK-Samples
•Maven master (project build etc.)
•Documentation
ITK-RI-mini-site
Potential Uses
• Education• Accreditation Support– Team see Reference Implementation as being a
useful tool– This is the first iteration - build upon areas that
need to be improved– Helps assess feedback from ISCF suppliers
• Accessible to Trusts – Intelligent Customer• Proving new content - e.g. Cryptography support
Reference Implementation Design principles
• Should be as simple as possible• Should be aligned to the application actor/role• Should hide underlying transport complexity - e.g.
selection of particular async pattern, multi-hop etc.• Should be easy to integrate/extend with payload APIs
– e.g. CDAAPI• Addressing is consistent for all message patterns• Could effectively extend the scope of the ITK by
standardising API for endpoint resolution, profile management, audit etc
Reference Implementation Design decisions
• Should be as simple as possible• Servlet container required for inbound HTTP• Serialisation– XSLT used for message serialisation– XPath used for message deserialisation– Static helper methods typically provided on relevant classes
• (Simple) async – is async at application layer• Message correlation (where required) is responsibility
of application layer• Simple Message Response created by Application Layer
Questions for HANDI
• General Feedback• Any suggestions on specific areas for
improvement (content)• Where next?
NEXT STEPS
• We are Refreshing the ITK Specifications during 2013
• We have a Monthly Vendor meeting for those with accredited products
• We are looking for feedback on • Next steps for the Reference
Implementation• Next steps for the ITK Specifications
Appendix - Lessons LearnedITK Improvements
• Improve Documentation– Online, accessible, searchable information– Properly collated references (e.g. Service ids, profile ids etc.)– Separate educational content from normative requirements– Separate content by audience where appropriate
• Business, Architectural, Implementation– Keep design guidelines internal
• Mitigate Complexity– Make Infrastructure Acks optional– Separate Accreditation of Transport and Payload
• Remove architectural inconsistencies where possible– Harder to do once live, but ideally we should:
• Remove coupling of Ack Framework and Payloads• Remove Distribution Envelope where appropriate e.g ReSTFUL
• When to move from SOAP 1.1 to SOAP 1.2 ?