Integrating health and social careInformation to support shared careIn the second of a series of articles on the technical background to interoperability, Ann Wrightson from the CSW Group Technology Office reviews recent work on information sharing in health and social care and summarises the important factors that make information sharing work. December 2007 The last few years have seen rapid development of information sharing in the public sector, from aspirational leading-edge practice and pilot projects into mainstream policy and larger-scale implementation plans. Earlier work on information sharing such as the FAME project (Framework for Multi-Agency Environments, see www.fame-uk.org/) tended to be bottom-up in terms of organisational engagement and policy development, with heavy involvement from local government and less from central departments. Although local government is still actively involved in the broader information-sharing agenda (for example in policy development, see www.legsb.gov.uk/projects/imstandards.php) the leading role on information sharing across health and social care has now been taken strongly by the Department of Health (DH), cutting through potential complexities of cross-agency information governance and identity management through the simple expedient of insisting that DH rules shall prevail in all situations where healthcare information is involved. As you might expect, DH leadership also leads to a strongly health-oriented perspective on integration — witness the term “social care” itself. The Social Care Integration Project (SCIP) SCIP is the practical leading edge of this new wave of health and social care information sharing. There are two main pieces, managing identity and developing technical standards for integration and messaging. The first involves making sure that social services information systems conform to the same patient and practitioner identity standards as primary and secondary healthcare systems, through integration with the Spine demographics service (PDS) and by using the same standards of authentication for system users. The second aspect of SCIP is the development of a first tranche
of national messaging standards to support assessment and care
planning. These are planned to be tested in the context of “Whole
System Demonstrator” projects (for more information on the whole
system demonstrators for long term conditions, see
www.dh.gov.uk/en/PolicyAndGuidance/HealthAndSocialCareTopics/ However, there is much more to shared care integration than technical standards and identity management, so going beyond the policy and the projects, what do information systems need to do in practice to support multidisciplinary, multi-agency shared care? CSW has been involved in a number of multi-agency information sharing projects as well as the award-winning electronic single assessment process (eSAP) solution in Tower Hamlets. From our experience, there are several important factors for making information sharing work for everyone, rather than just being a technical “success”. The rest of this article looks at three of these, bringing out the implications of each one for standards-based systems integration. The patient journey and experience of multidisciplinary care The policy drivers for shared care rightly focus on the patient or service user, and their journey-like experience of multidisciplinary care. One of the key aspects of the patient journey is moving between different care settings — and of course these have different information systems. What may be less often appreciated is that different care settings have (for good reason) different information in those systems. Some of the differences are obvious, however others are subtle. The level of difficulty in a clinical context in getting even apparently simple things like dates to correspond safely can be very surprising to an IT practitioner. Difficulties in mapping between different systems of clinical terminology, and even different usages of the same terminology, are of a different order again. Some people are inclined to give up at this point, and say that the only safe thing to do is to exchange information that is already laid out so that the appropriate reader can read and understand it. This has its place, as I discussed in my last piece. However, the value of sharing structured, coded information has been well demonstrated, and should not be thrown away. The most important mistake to avoid is to believe that integrating existing data will automatically deliver information sharing. In our experience, developing a specific information architecture for the shared information is essential, as is conducting the information analysis in a way that allows issues such as usage of dates and terms to emerge naturally in the analysis process. For a large-scale project, this means close collaboration between clinical analysts, that is, individuals with both clinical and information analysis skills, and the ICT-focused system engineering or enterprise architecture function of the delivery organisation. Beyond role-based access to indepth role-based support Supporting the patient journey is, of course, the fundamental purpose, and also the delivery “sharp end” of information sharing. However, all the human actors in multidisciplinary care need to be taken seriously in the analysis and design of solutions, that is, patient-centred care should be supported by information systems that are designed to be practically useful to health and social care practitioners. One of the difficult design parameters in this area is determining how much information, of what kind, to share with whom. On one level this is a matter of privacy and security — role-based access, and so on. However, the usability of the shared information at the point of use is also very important. Information overload, which makes the key information not immediately to hand, is just as bad for safety as missing information. In our experience, user interface design for shared information is closely coupled to the information analysis. Where this is not possible, information standards intended to feed into existing systems need to be carefully designed for that purpose, and include guidance on how the information should be made evident — not just available — to systems users with different roles. Respect different operating contexts and support familiar tools Finally, a quick reality check on where this information is going to be used. Different areas of the country need different hardware. For example is it a positive benefit to carry a laptop, or a risk because it is an attractive target for theft? Also, there are different timescales for different activities, for example assessment of changed needs following a stroke, compared to long-term management of diabetes. “Wrap, don’t rip” is a technical aspect of this factor. Whilst some information systems do need replacement, for others the asset represented by the combined experience of its users and how it is used is of significant value and should not be laid aside lightly. The corresponding approach to technical integration is to populate the information-sharing standard using the information available from existing systems, and providing cross-system capabilities for shared records and workflow. Often, this means providing some kind of shared record repository with lightweight workflow that can integrate back into users' “home” applications. CSW are not the only supplier providing these capabilities — it is a promising and lively emerging market, and should gain new life in England with the completion of the upcoming “additional systems” procurement from Connecting for Health. The Interoperability series is authored
and sponsored by |
|||
|
|
|||