FYI -------- Original Message -------- Subject: RE: Stat Health Questions Date: Fri, 1 Jun 2007 10:20:02 +1000 From: Ian Threlfall <[EMAIL PROTECTED]> To: Tony Eviston <[EMAIL PROTECTED]> CC: Ian Williams <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]>
Dear Tony, Thank you for your email. I am very happy to answer your questions and provide any information that you require about Stat Health Systems and our new Clinical and Practice Management application. It's true that we are entering a relatively crowded market - the important issue is whether we can provide some market differentiation for our product. Our assessment is that this market is far from satisfied with the range of products and/or vendors available and that a new product that identifies and delivers upon those unmet needs will be successful. It's important to stress that we believe that it is not solely within the 'product' that we wish to respond to current market requirements - the total solution that we will provide consists of a modern innovative application, a strong local support capability and a commitment to on-going development in consultation with our market. Now, to address your questions.... It is all too easy to address a question on design philosophy with a series of obvious motherhood statements that are used regularly by many vendors. Our team has a great deal of 'in-the-field' experience working with practices to get the best out of their clinical and practice management packages. We have identified many areas where we believe better design and different product architecture will provide real solutions. The Stat application is a fully integrated application - not just sharing a database. This allows us to look at practice 'process' and deliver tools that actually support such activities. The application must support, encourage and monitor the activities of all the professionals within the practice with the aim of providing better patient care and better business management. We have 4.5 programmers working on the project. This is backed up with a group of medical industry professionals - including a GP, an accountant, a physiotherapist, a nurse and a practice manager. The team is second to none in Australian in terms of experience within this market and we are very fortunate to have such a range of medical, management and accounting backgrounds within the team. We are a Brisbane based group - all of our staff are local and we are committed to developing and supporting our application from within Australia. As mentioned above, the Stat application is a single FULLY integrated Clinical and Practice Management tool using a single database. At this time we are developing our application using MS SQL 2005. We have chosen this for many reasons - ease of use, scalability, availability of expertise etc. The 2005 version has many features that make it a very suitable choice for this application e.g. rather than have our application polling the database continually looking for clinical 'alert' situations - MSSQL2005 can handle these tasks independently. However, the design of our application does allow us to easily move to other databases - the Data Access Layer is self contained and we can therefore build versions with different Data Access capabilities. Stat is being developed using C# within the .Net3 Framework. It is a 3 tier - 7 layer application. Clients access the application via Web Services only. Our initial release will have a WinForms client but we intend to quickly move to providing a range of options that will include PDA's, SmartPhones and browser (ASP.net) interfaces. Only about 15% of the code base resides within the 'client' and only about half of this requires redevelopment for each of these platforms. We will also fully support a Terminal Server environment. To summarise, our initial release will be Windows Server - MSSQL2005 - Windows2000/XP/Vista with ASP.net and PDA subsets available soon after. We will support multi-site installations either natively or through a Terminal Server. The application can be configured to handle multiple legal entities and multiple provider numbers per doctor - we have a great deal of experience with building such a flexible application. We have a fundamental belief in the concept that the doctor/clinic owns the data - no argument! Our job is to help you build, use and protect your data. Our application will not encrypt any data within the database. (Please note that MSSQL does provide an encryption capability that can enhance security - this, however, is under your control and this function would not limit your access to that Data.) All data including documents, images etc are contained within the SQL Database and we access all data through Web Services - there are no drive mappings etc etc. One of the advantages of our three tier model is that the SQL database does not need to grant access to each network user - only the windows ASP.net worker thread on the application server requires such permission. This significantly enhances the level of defence against an external or internal security attack. We will provide Web Service access to ALL data within the database. In this way we can ensure high levels of security and data integrity. However, we do not restrict a customer's ability to allow direct database access for external applications. We are committed to providing better 'useful' access to clinical data stored within the EHR. Our design of the clinical database will be focussed upon enhancing the ease of data extraction and analysis. This has been the 'promise' of the EHR and we aim to deliver on that promise. There is no doubt 'Messaging' is a hot topic at the moment in the health space. NEHTA has confirmed that HL7 messages transported and managed via Web Services is the 'way forward'. As you can see we will be well positioned to lead in this endeavour. We are already having discussions with pathology labs, radiology services and messaging vendors about how our applications can best communicate. The vision is that these parties will be able to interact directly with the Web Service for our Server application and 'swap' messages in real time. No doubt - for the short term - we will also have to allow for normal file structure based PIT and HL7 import and Export. We will develop migration utilities from other products. We expect to have Beta Sites operating this calendar year with a full release in the New Year. Pricing is yet to be finalised but it will be competitive. Tony, I hope that I have answered your questions and please feel free to pass this information to your colleagues. I am also very happy to handle any follow-up questions that you may have. Regards Ian Threlfall Managing Director Stat Health Systems -----Original Message----- From: Tony Eviston [mailto:[EMAIL PROTECTED] Sent: Thursday, 31 May 2007 10:11 PM To: Ian Threlfall; [EMAIL PROTECTED] Subject: Stat Health Questions Dear Ian, Ian Williams conducted our practice accreditation today and I mentioned that I would email you with the following questions. I note that your program is currently under development. The fact that you are willing to enter a fairly crowded market demands respect, and I would like to know some more about the product. I am attending a meeting in Melbourne next weekend. Most of the 20 or so GPs attending are practice owners and all have an interest in IT issues as they affect General Practice. We have a session set aside on Saturday morning to discuss and compare EHRs, and I wondered if you are able to give some specifics regarding StatHealth for mention at this session? These questions reflect some of my own biases so forgive me if I miss anything, and feel free to add anything you wish to emphasize about the product. Please advise if you are also happy to have your responses published on the Nat-Div and possibly the GPCG mailing lists. A link to the program for the meeting on 9-10th June is at http://2560cc.dyndns.org/ yours sincerely, Tony Eviston GP, 86 High St., Boonah Qld 4310 Is there an overall design philosophy that differentiates Stathealth EHR from its competitors? How many programmers (FTE) are working on SH and what percentage of the work is being done in Australia? Is StatHealth health electronic records only or does it include a billing/Practice Management program? Can you describe the data storage: one database or several? Which Database? Is there a user choice of back end database? If so, is a linux database server supported? Program architecture - two tier or three tier? Client side details: windows only or cross platform? java, windows forms or asp.net? Clients and servers - Is windows 2000 supported? XP? Vista? Terminal server support? Support for multisite integration (eg multiple sites per practice, multiple provider numbers per doctor)? What access will users have to the database (read-only and /or read-write) ie can groups of users extend the application if they wish? Will this access be via direct access to the database or via managed APIs? What is the attitude of StatHealth developers to end users developing add-on modules by directly accessing the database? (keen, nonplussed or cool) Medical Director locks in its users by means of a controversial field level encryption of some data fields. Does stathealth EHR present any impediments to users bulk exporting their complete data if they wish and whenever they wish? Can you describe the architecture of the document input, storage and management aspects of the program. Are documents stored in the database server or in the file system with database used only for indexing? Data entry points into SH: As a user will I be able to dump a .pit file in the filesystem and have SH consume it? Ditto for HL7 inputs? (User written external modules often use these methods to ensure their outputs end up in the EHR database) Any beta sites yet? Is a release date within view? Any pricing information? Will stathealth EHR implement a migration utility for unhappy MD3 users? _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
