- December 14, 2017 at 6:23 pm #18211JesperParticipant@jesper-lindholt-ottosen
There is a project here around implementing EPIC, a large standard system for hospitals. Do you have experience in testing that?
I would guess it’s similar to other standard systems (Ax, SAP, sales force) in the sense that you can only customise it, and perhaps do a bit of background scripting. But just for hospital work flows.
How do you balance standard system, vs customizations?December 18, 2017 at 5:46 pm #18221RomanParticipant@rpwheeler
Lesser systems, not as huge as Epic do not qualify, do they?December 18, 2017 at 7:11 pm #18223JesperParticipant@jesper-lindholt-ottosen
bring it on 🙂 Of course! do tellDecember 25, 2017 at 5:43 pm #18237RomanParticipant@rpwheeler
The hospital system I was involved in testing deals mostly with patient intake and patient surveys. I had experience with complex system before coming to testing the hospital one: internet gambling system, if you care, and trust me, internet gambling systems care a lot about keeping records about clients and their experience. It might sound like a joke, but experience with gambling system (including back-end) prepared me and helped me in dealing with systems for hospitals.
So, what I can share about my experience
1) One wants strong people on team. It might sound obvious, but it is important. Dealing with complex systems need experienced and complex people.
2) The people on team must be good learners and want to learn. Complex system requires a lot of learning. Again, might sound obvious, but sometimes I saw thrown out (to my and others regret).
3) You want people to communicate a lot, help each other and support each other. Sometimes people don’t pay enough attention to this point, what results in people keeping problems to themselves, what makes them spend more time on problems.
4) Even where customization depends only on one and only company systems it is not a simple task. For sure I don’t know Epic internals, but every complex system has a lot of points where it can be misconfigured.
5) In reality you don’t want to think about “balance”. You may also don’t know “impact” at all. What is real concern is that you better check every important system and flow, to be sure that they work for your customers. Balance is not a question. What is a question is what you customers need always working, from the start and every day.
If you don’t know most important flows, ask your customers, make them talk to you about what they need and want most.
6) The sooner you find all important problems, the better. Again, it is not about balance, it is about making sure that important things work. Not that important things may be fixed later. Task people with this: to think where most important problems can be found earlier.
7) If it is not one-time contract, but something you expect to support, you better think about some automation. I know that everyone talks about automation these days. But some do it wrong, and you need not one matching buzzwords (like BDD), but one finding problems. Again, to have good automation and supported one you need good and strong and capable learners on team.
8) Logging. You want it. Really. Badly. Again, I don’t know what Epic logs and how they handle it, but every complex system benefits from logging, as logs help a lot to find problems and circumstances causing problems.
9) Allow your people to speak open even where they don’t agree with you. This does not mean to allow them do all they want, but knowing their ideas and concerns you may come to conclusion that they were right about something.
You may think that I hadn’t say anything very specific to hospitals, and it really is so. Surprisingly, in my experience, things developed working with other systems came true in working with hospital ones as well.
- You must be logged in to reply to this topic.