November 10, Dear David,

Transcription

1 November 10, 2004 Dear David, Several of the OSCAR BC users, members of VCH, and UBC sat down together to discuss OSCAR deployment so far in BC, as well as opportunities and hopes for further development. We think that OSCAR has an exciting future and we would like to contribute to it. We wrote the following to capture our thoughts and ideas. We would love to hear what you think about these ideas. Also, Morgan Price and Colleen Kirkham will be in Toronto November 24-27th for the FMF. Would it be possible to meet during this time to discuss this document and a framework for BC's future contributions. Thank you, Jel Coward, Clare Heffernan, Colleen Kirkham and Morgan Price

2 Oscar: the Future and How Can BC Contribute? November 10, 2004 Contributors: Jel Coward Clare Heffernan Colleen Kirkham Morgan Price Introduction: The OSCAR open source EMR from McMaster has been adopted by several of the new practice networks in Vancouver Coastal Health as part of their practice re-design. These clinics see open source as a viable and sustainable option for an EMR that will produce clinician ownership in the project and, therefore, encourage and promote practice change. The practices also see the open source model as a more sustainable option for the adoption of EMRs in practice for the long term. In moving to BC, OSCAR has had some growing pains. BC OSCAR users needed new interfaces (to MSP billing and PathNET), and they need to be able to report on their practices in new ways, as part of the Practice Enhancement Collaborative. As the practices move forward, there are new challenges generated from the need to extract the data necessary for these practice improvement projects. OSCAR has prided itself on responding to user needs and requests and indeed has been very successful in developing one of the most feature rich open source EMRs. The move to BC has been successful, with one practice in Pemberton, fully utilising OSCAR in real-time patient care and another maternity care practice using the new OSCAR antenatal record. Bayswater Family Practice has started recording most visits in OSCAR as well as using the prescription module and the referrals. The McMaster developers have worked closely with the users to build an effective and efficient billing system. However, there have also been some challenges including duplication of work and some uncertainty on the part of BC users as to where or how to discuss ideas/feature requests. As we look to the future we need to ask What will be an effective structure for progress?. Part of the answer is almost certainly that we have to develop close integration of developers in BC with those in Ontario. It is important to avoid duplication of work and that a common vision is shared. A clear structure for commissioning development and then the incorporation of that development needs to be established.

3 This document, put together by the core BC users of OSCAR, is intended as a first step to begin a discussion about how OSCAR can develop a data structure which allows enhanced data extraction, and an operational structure which supports broad community building. Goals: To begin the discussion around: Developing a standardized, coded, patient data model in OSCAR Visualize a simple framework for feature requests and a process for developing a road map for OSCAR. To produce a document clarifying how the OSCAR collaboration between McMaster and other developers will work and how requests for features will be reviewed that can be shared with a larger community. To begin the discussion around enhancing the patient model in OSCAR Patient Model and Structured Data: A structured patient model is important in a modern EMR for several reasons. Data portability is one reason, another is the ability to provide decision support and single entry of data is important for user efficiency. In the case of BC users, there are specific requirements to develop practice profiles and reports. Profiles and reports are important to a practice as they allow clinicians to look into their practices in new ways and focus on improving the care they deliver. Currently in OSCAR, this model is present, but the majority of the information is free text. In order for the EMR to report and or act intelligently on data, some of this information needs to be coded. We are proposing that some key elements be coded in OSCAR in a manner that allows for reporting and decision support. The core data set would essentially be a cumulative patient profile including problem list (already there), past medical and surgical history, medications, allergies, immunizations, and social history. Key physical exam and all labs should be stored in a manner that allows for consistent querying, allowing practitioners to review their practice. NOTE: Some querying is definitely available in OSCAR, however, some of these areas cannot be globally queried. We feel that BC developers could play a significant role in the structuring of this core data set and in developing decision support tools to use this coded data set to improve patient care. There are other elements in OSCAR that are stored as discrete elements in the

4 SQL tables, such as the new OSCAR Measurements section and the immunization sections. These elements allow users to customize their own data structures. While user customization is a good thing, customization of the underlying data structures means that all reports and searches need to account for any changes made in every clinic that is running OSCAR. Further, the same data may be stored in a variety of places (e.g. Immunizations are stored in forms, in the clinic notes, in several OSCAR Immunization forms) and the users will assume that when queried, OSCAR will search all locations, which it does not. A framework and set of guidelines need to be established that describes how and where patient data is stored. This will help users find information and will help other developers to add new features that will be consistent with the OSCAR model. This will dramatically improve developer collaboration. It should be noted that free text is a vital part of the record and is one of OSCAR s strengths. We need to build on this functional foundation by adding the ability to code some elements and store them in a manner that will add to practice enhancement. OSCAR Road Map and Building the Community: In moving forward and expanding, the current agile model of development has served OSCAR well. As OSCAR grows we need to ask whether this model is scalable. As other parties have wanted to contribute to OSCAR, there have not been clear paths as to how to contribute and code has not been accepted because it does not fit into the internal plan for OSCAR. This might suggest that the development model is not scalable and we should perhaps consider alternatives/variations. Open source projects succeed through the strength of their communities. Time and energy needs to be spent nurturing this community. People with varying roles are needed: technical people such as programmers, architects, user interface and workflow specialists, clinical people, and marketing people who can promote the project. Obviously people do not need to be restricted to a single role. For a community to grow and thrive, members need to feel that their voice is heard and that the decision- making process is transparent. As OSCAR expands to other groups, clearer processes will be needed for planning, feature requests, and community building. While OSCAR has enjoyed successful collaboration (e.g. working with Brazil), the process for adding new functional components is unclear and pieces that have been offered or subcontracted have required significant reworking or have been excluded. Larger open source projects have gone through similar stages of development and change and so we must not let the difficulties in this process distract us from

5 the mission. We can look to the successful projects to see what has worked as we consider how to move to the next level. The Apache Foundation is one of the more well known and successful open source projects, with web servers running over two thirds of the Internet. ( On their website they describe clear pathways for contributions, and how the meritocracy of the Apache Foundation is set up. They also describe how they incorporate code and provide a consensus building voting strategy to their process. Open Office is another example of a successful open source application. Over the past four years it has grown into a successful community. ( and is being used by people all over the world in multiple languages. In their community, they maintain a To Do List which houses a wide range of items from usability testing and research to improving the installation procedure, to porting to more platforms. They have posted a series of guidelines and community member roles as well as maintaining bug lists, feature requests, etc. OSCAR, as an application in a vertical market (medicine) will not have as broad an audience nor as large a community, but it still needs to have public direction and planning in order to increase its developer and user base. The formal structure for users does not need to be as robust, but some structure and open process would help the community. A release map or road map is essential. Given the nature of funding, contribution of time, complexity, bug fixes etc timelines will vary, but a road map is critical for users to see direction, movement, and where they can make a contribution. For example, it would help the OSCAR community to promote a 2.1 release. The current release is 2.0. Currently users and developers do not know what could be in the 2.1 release, nor if there is one planned. 2.1 could be announced as an idea, with a discussion forum on oscarhome.org established to discuss features in 2.1 and to call members on of the community to submit ideas. As ideas are posted, they can be discussed and refined specifically for the next release of OSCAR. Active participation in this process by the core development team would, no doubt, lead to some interesting and helpful discussions. As the ideas come out and clarify, a user poll / vote can occur, with the highest priority pieces being put into the road map for 2.1. A 2.2 release could be considered based on the remaining suggestions. This would produce a sense of community engagement and ownership of the ideas the people who proposed the ideas would be more willing to participate and the community would be strengthened.

6 Summary: The OSCAR users in BC have committed to using OSCAR in their practices and want to see an open source EMR succeed in health care. Specifically, we hope that OSCAR will be that EMR. The BC community wants to ensure that it is known that we wish to be part of the ongoing development of OSCAR and that we wish to actively contribute to the attainment of objectives discussed in this proposal. We welcome the views of the McMaster/Ontario development team on what we have expressed here and hope that we receive a response to this discussion document.