Hi Everyone,
Hoping to connect to the collective wisdom here in ehealth Forum. Like many hospitals we are looking to replace the functions that the Orion Soprano Medical Template applications (SMT) performs and I am interested in learning about how other hospitals have or are looking to address this issue. Any and all information gratefully received.
Many thanks
Karen Shaw
Hi Karen, I suggest you start by documenting the key clinical workflows that this type of application needs to support. By doing this you will be able to articulate how well the current application supports these workflows and where improvements need to be made. As you know, there is a difference between documenting an assessment in ED, for example, and simply posting it to the patient record, compared with having the documentation trigger a workflow downstream; notifying a surgical team for example or notifying a ward charge nurse of any special nursing care needed.
Supporting integrated hospital care with well integrated systems is the goal so looking at the bigger picture first and then drilling into workflows in more detail is a good start. Rarely in healthcare do we only replace the functionality that an existing system provides. Typically newer applications offer a lot more so understanding the workflow and requirements will be vital when you start looking at alternative solutions. Happy to discuss in more detail if you like. Chris.
HI Chris,
Absolutely agree. We know that SMT functionality replacement is only going to touch the surface and wonât address the gaps in clinical workflow that exist. However, we have a burning need to replace it soon before it goes out of support. We also have plans for the future functionality it doesnât touch but this will require funding. I have begun looking at our current workflows and will definitely take your suggestion on board and build it into my work. Thanks very much,
.
Hi Karen,
Yes, we are also on the lookout to see what is possibly going to replace SMT around the country. I like Chrisâs thinking that a system that can have downstream workflow initiation will be valuable.
As a pharmacist one part of the SMT templates we utilise is the documenting for medicines reconciliation and discharge medicine tables. Naturally a priority for safe medication management is to be able to communicate a medicines reconciliation at time of admission, transfer and discharge.
What ever the tool chosen, whether within the product replacing SMT or a product that can easily be incorporated into the PMS, it needs to be able to capture a point in time when medicine can be safely documented and utilised within the prescribing system or discharge function. I am following this post to understand the issues further.
Kind regards
Taryn
Various departments at Christchurch Hospital have been gradually working on a transition from SMT to CarePathways. It has been quite a long process.
The greater frustration is that the time and capital invested here is probably not easily transferrable/generalizable â and, like you, we have no idea what everyone else is working on.
Thanks @taryndavids and @rradecki , from the comments and conversations I have been having lately it appears we are all in the same boat in that we donât have a single viable alternative for the functions that SMTs perform for us. The approach we are taking is an ecosystem approach I think. Itâs likely that we will split up the functions performed by SMTs and replace these functions with separate products. The difficulty comes in finding good, future focused alternatives for all functions. A work in progress for us but continued discussion and sharing is definitely the way forward. Happy to collaborate if anyone is interested.
Our decision point was to either switch to Cortex (homegrown) for clinical documentation (like our inpatient teams) or to develop a replacement within HealthConnect South (Orion). While I donât know what the ultimate future will be for HCS/Orion, limitations in Cortex (iPad only) and the long-term viability of the platform led us to stay within HCS.
Itâs frustrating to hear weâre all building things differently and have heterogeneous processes, rather than unifying and streamlining â or that places like Waitemata are developing their own clinical platforms like eNotes; ought we be planning to discard Orion in the future for their superior homegrown solution, or should they be adopting ours to prevent duplication of effort/investment?
Oh Ryan, I so share your frustration on this one!!! This is THE primary frustration that has driven me to attempt to pull us all together into a community, i.e. the eHealth Forum.
So, how on earth do we pull together effectively and change to a nationally collaborative approach???
Imagine having Waitemataâs solution widely visible and implementable, an iterative national library of key clinical workflows as per @Chrisâs thoughts for them to draw upon, a configured eMM solution honed and tweaked by Taranaki ready to drop in.
We could move in this direction impressively by
Further discussed here:
I absolutely agree with @NathanK and @rradecki the challenge is now do we work together to gain homogeneity without sacrificing usability and localisation. However, i donât actually think many of us have got to the point of developing anything (funding appears to be a major issue for us all) and the positive side of that is that we have an opportunity to collaborate. Our Enterprise Architects here are hooked into a number of regional and national groups looking to develop roadmaps and this is a good start and Iâve been pushing the (clinical) user voice in this. Iâll have chat to them about any work at national level we could hook into to get more working together. Letâs keep this discussion going and try to solve it together!
I donât understand the politics and have very very little in-depth background in this field. But working together makes sense to me.
Can I just be a dissenting voice (shocking and surprising I know)? We need a common standard to support the exchange of information between us.
The snag with monolithic systems from a single provider is just that. They are usually EOL at the point of their design. Any subsystem problem takes the system down for everyone everywhere. There is no commercial incentive to innovate or even listen. There is no ability for local innovation or local customisation.
The problems we all highlight and feel currently are the problems of a monolithic system from a single provider. The solution is not to do the same again with a different provider and expect the outcome to be different.
In my opinion, clinical systems need clinical informatician leadership and ownership, not vendor capture. This also means wider clinician participation in the whole design, build, and run cycle.
We canât continue with the mantra of âAs a clinician, my priority is that I want to be in charge rather than the project being successfulâ
I realise this is a heretical position, but our colleagues and patients need better.
I would argue that the level to which we go multiple-supplier vs. single-supplier comes down to where we decide the workflow âboundariesâ to be. The hospital inpatient point-of-care workflow from admission to discharge is primarily a single workflow with care-delivery coordinated across multiple groups. Underlying this overarching process there are, as we know, multiple âsub-workflowsâ and documentation requirements, some of which are unique but many of which are common across specialities. Using different systems causes databases and user interfaces to become fragmented. This may or may not be acceptable depending on your perspective but it certainly causes workflow problems, classic examples being the problem with CPOE when the clinician needs to access three systems (or more) to place requests for meds, labs and imaging, the lack of decision support when doing so, and the difficulty in creating comprehensive clinical summaries on discharge if the data resides in multiple databases. There will be counter arguments of course but overall I would promote a single-supplier system for key clinical point-of-care processes with integration where appropriate and a careful look at the acceptability of the trade-offs in either approach. Developing some high level national design principles would seem to be a good starting point.
100% agree. Itâs a message that has been around for a while so why is it, apart from a few notable examples, not happening? I like simple analogies and this sounds to me like deciding to build a new house and have the builder design it for you. No disrespect to builders but the only people who know how they want their new house to function are the people who will be living in it. Perhaps thatâs for another topic.
We have some people working on this off the back of the Covid work. More on the interoperability side than the user experience.
There is another thread where someone from Health Alliance is trying to figure out how to reduce the 100k forms in use (I think in the community in the Northern region).
The reality is there are lots of tech options as forms are a well understood and it is a regularly implemented use case in many industries.
Where this all falls down is the ability to codify the data (Snomed) and the ability to integrate data into and out of the forms (FHIR).
The interesting question as Greig points out is the point of aggregation of functions. Talking to @davidryannz and @Alistair we need to think about the connection between free text entries; forms and tasks and how they go together (SOAP normally includes all three). And @rradecki âs question to me has been - how do we get consumers to fill some of this stuff out?
Our work as I mentioned above includes the implementation of âquestionnaireâ (form); tasks and goals as apis to facilitate transit of these between those that fill them out - we are calling them âcare plan apisâ but only in the technical sense of them being the tech components of a care plan. Am trying to get observation in there too at the moment.
Jon
I think we could also look at an iterative national library of key clinical data sets. Iâm talking about the data that is collected 90% of the time for any clinical procedure. Applications still need to provide for local preferences, research etc. but most of the time the data collected is the same. National EWS is a good example. When you build EWS electronically there is no requirement to follow the paper format, only collect the data and build the rules as prescribed to generate the score. Having standard data sets for clinical procedure documentation would help manufacturers improve their designs out of the box, shorten implementation times, and improve interoperability. As well as the basic data, it would be helpful to define conditional rules. âIf this, then thatâ rules based on user responses allowing data entry screens to flex base on user responses. I noted you used the word âiterativeâ @NathanK. Really important that libraries are kept up to date and there is a cost in doing so. But we do it for other standards so why not clinical documentation?
A more interesting conversation starts to happen when you move thinking away from just replacing clinical documentation with an electronic version, to the concept of âdigitising workflowsâ
That reframing leads to a number of new priorities when designing or choosing the right tool for the right situation and new definitions of âwhat success looks likeâ i.e.
As discussed higher up in this thread no single toolkit currently exists to cover off every need and requirement, and hence different tools are likely needed for different situations and problems to solve.
From experience - if you are working in a framework of digitising workflows then success in this model really means having a device with you at all times ie. mobile, with workflows localised to departmental level. By natural extension, the locus of control for developing and maintaining these workflows is best done by departmental clinicians in a bottom up model with appropriate tool sets to enable this.
This can also lead to unexpected positive consequences, where the clinicians, using that toolkit, solve problems that managers and vendors didnât know existed.
Emergency department needs are not the same as inpatient needs which of course are also not the same as outpatient needs. An ecosystem model with shared standards is where wider success for digitising our health system can be achieved.
100% agree @Alistair . We need to improve, not replace what we have which only constrains the design and limits innovation. When it comes to building reference tables on CIS projects for different customers there tends to be a fair amount of content re-work each time so I wonder if having a library of data sets (not forms) for common procedures be feasible.
@Chris yes. Totally agree.
Tagging in @jon_herries 
Maybe we could start with smoking - has to be done in lots of places and even by the consumer. Of course everyone does it differently and there isnât a standard for what we capture.
Jon
I think a couple different issues are getting a bit crosswired in this conversation.
Everyone here sees the value of having standardised data sets and standard APIs for applications to access these data. This isnât exactly âdigitising a health workflowâ, but at least providing the underlying foundation to do so.
While it absolutely has value to establish a foundation that can support multiple different vendor solutions, thereâs no inherent value to having a diverse assortment of vendors and local customization across each hospital/locality/region.
There ought absolutely be an open-standards underlying structure from which a patientâs digital footprints reside upon which any innovation or vendor could be deployed â but success ought also be measured by how quickly any superior product diffuses throughout the entire health system.
Wires well untangled thank you @rradecki .
Standard data sets along with design guidelines will help with âdiffusionâ. In a rollout scenario across a region, if âdownstream hospitalsâ (for want of a better term) are not given the opportunity to contribute to the design up front, then what was intended to be a rollout will become a rebuild, guaranteed, and we know how painful that will be, particularly on a live environment. Leaving this to chance is not an option - the diffusion must be directed based on flexible, upfront clinical design - the âunderlying foundationâ.
Regarding multiple vs. single supplier solutions, the way to solve this is to base the solution around the main workflows. Point-of-care clinical processes from admission to discharge are clinically coordinated so it will take a single system to support these core processes. This includes ED, theatre, ICU and if you try to separate these then the value to be gained from IT is reduced. Appropriate integration with other systems (communications, acuity, clinical equipment, lab, PACS, CSSD, external systems etc.) is fine as long as data is pulled into a central EMR to support real-time clinical decision support and retrospective analysis.