The central region is getting close to delivery of our first tranche of forms based in the Orion Health Care Pathways (CPW) tool and we are starting to get good at building forms using this tool ourselves now.
This email serves two purposes –
Find out who has what in terms of forms built using CPW. This is the first step in an unashamed attempt to copy anything we like the look of… to date I’m aware of
a. The midland region has built a discharge summary
b. Canterbury has at least one form - I’m unsure if it’s in use more widely in the south island.
boast a bit and offer to share what we have. I anticipate that the other regions will be going through something similar as SMT becomes incompatible with SQL upgrades, and as always, it would be good to share.
a. I’m kinda proud of the admission to discharge workflow we have around medications – although that’s a couple of steps from go-live yet.
Would you mind letting me know what forms you have built using CWS, and whether you’d be prepared to share?
Well done Mat, that’s awesome, maybe we need an inperson conversation on the topic at one of the upcoming meetings? Be good not to recreate! I can’t comment unfortunately as Waikato has chosen to not go ahead with a midland implementation of Orion and additionally I am off to a new role in 2 weeks. However avidly watching this space!
Auckland DHB has been using previous applications from the Orion suite and kept migrating to the newer products including CWS and now Care Pathways. Care Pathways migration has been the responsibility of our Data and Analytics team (Health Intelligence). There is a lot of demand for more CPs to be created.
Thanks Lucy!
Has the ADHB strategy been mostly about replicating functionality from the legacy product (SMT presumably) or are the team trying to leverage some of the newer functionalities in CWS/CPW.
Might be good to hear what forms you currently have built in CPW - as mentioned, I’m on the prowl to steal any and everybodys work I can
Good question mate! I believe the plan is to stick with our current CWS offering (which is actually rather good and we own the code) until such a time the organisation feels it is ready to move on.
OK, so it’s more about staying with Orion, but not moving to the regional instance, is that fair? I’d be interested to know how well the older versions of OH concerto cope with some of the widgets and components which make CPW actually work better than SMT… will have to get you to gimme a demo sometime!
Hi Mat, funnily enough I was just chatting to @rpapps and Debbie Beesley at SIAPO about digitisation of forms and the need to collaborate nationally on this, so linking him into this conversation.
Have been asked to comment on this thread. Understand not really answering matt question but gives another perspective.
At chch for inpatients we taken completely different approach and have gone with sense medical.
The end users build the content using a seperate application. Forms can be built by clinicans with no coding. Simple forms can be done within hours.
The data is all exported to data warehouse.
We have governance rules re form building.
We have ability to snomed code.
Notes published in hcs both as tab and in cdv tree.
There is still much to do but we like this approach as controlled by the clinical teams not the vendors. There is no cost to building a form other than clinican time.
They can be iterated at will.
We have built well over 200 forms.
We are deployed across allied health, nursing and doctor specialities. We in all services at christchurch campus bar emergency and nicu. Currently rolling out obstetrics and anesthetics.
Regards
Sax
Weighing in here from Counties Manukau Health. We are in the process of adopting Orion’s Care Pathways at present and are working with our counterparts at Auckland DHB and Waitemata DHB who are further along in the implementation of Care Pathways.
Care Pathways drives our Regional COVID assessment and monitoring forms.
Keen to network with other users to discuss and look at sharing content.
Regards,
Aaron
I am sure CWS has some great uses, but some advice as to what you should not build with CWS. Many health registries keep data for a combination of benchmarking performance against Australasian and international standards, and to enable both future planning and research questions to be answered in an ad-hoc manner. For ICU this will be APACHE, ANZROD, and for PICU the PIM series of mortality prediction models. I also look after similar databases, for example patient transports and liver transplants. Having the data on site rather than stored overseas with international registries makes auto generating reports at non standard intervals, sharing data between departments and allows answering ad-hoc questions quickly and easily.
Moving 1 such registry has created unbelievable time wasted for our organisation, our admin/data entry person and myself, and I would advise others against it.
CWS is a GUI first design, as opposed to data first. It creates a non-normalised database (no foreign key constraints at a database level and joins requiring string manipulation between different fields and sometimes tables rather than just combined keys), and what should be stored as numeric formats are usually stored as text and need converting in order to run simple filters such as where lactate between 3 and 12. To move back to a simple data first SQL view of the data (1 row per ICU admission, about 128 fields) took 2 senior DBAs over 16 man hours (23 000 characters), and each query to extract useful data for benchmarking and resource utilisation questions (which used to take about 200 milliseconds) takes about 12 to 20 seconds. Simple changes take many months to implement (this might be an ADHB problem). In adding new rows of data when a 1 to many relationship exists, after about row 40 it takes about 7 seconds to add each additional row.
For other such databases and registries, we are currently playing around with Oracle APEX to assess its suitability.
Hey Brent! Many thanks!
I’m glad you saved me here. I just finished sending off an email about how I wanted a future state where ICU data was collected in teh CWS form. Now I’ll go an eat humble pie, and maybe copy and paste a lot of what you just posted.
With regards the ICU data collection for ANZICS, The bad news is that it’s a pig of a job nomatter how you do it. - Lance Elder built me an Oracle DB for the purpose of ICU data collection and ANZICS submission over a decade ago in Dunedin… Granted it was something where the front end also was designed to facillitate clinical care, but it took several months to build, and then almost double that time again to get the reporting sorted. … but I take your point and will take your advice!
Thasnk Rebecca! I’m seeing this as a thread with significant interest!
You make good points. The central region has an associated data extract application called RADA. We will certainly check that CWS is or can be surfaced via this route.
Dear All,
I’m very grateful for the responses! Thanks! I’m hearing two things from this tread, as well as some personal emails on this topic.
I’m hearing a few big picture messages:
there is a strong desire to share, and there are several different forms out there. Creating a list (?a Wiki on Discourse? ) of who has what is likely to be helpful. I might need some help doing this!
there is a desire to learn how to develop these forms independant of Orion Health. Our region has plans to organise a workshop to teach DHB developpers how to develop in the CWS forum, and I’m wondering what interst there woudl be from other DHBs in such a workshop?
a show and tell session of who has what at an upcoming CILN event may be warranted.
Thanks Saxon!
from what I see of the Cortex/OH balance, building in Cortex seems to be easier and faster, and it’s a product which has had great uptake in Canterbury. Cortex has a number of strengths over the OH product - while OH has some things it does better than Cortex. While a DHB is still tied to OH for CPW forms building, its definatley slower and more expensive to build in the CPW tool, once the DHB becomes able to build on their own, this liberates them significantly, but still requires IT support to build.
From what I understand, deciding which format a form should be built in probably warrats the following factors - I’d be interested in your opion on this observation, as I’m a Cortex non user (not through lack of trying on my part I might add).
Cortex seems to be easy to build forms in from the start, and the focus has been on freeing clinicians to build their own forms. To build a simple form might take a few hours. Its a good format for building a specific form for a specific service which needs to record specific information. It’s probably not a good platform for single a complex form which pushes and pulls information to and from multiple sources and needs to serve the needs of many services.
CPW form building is based on components. When you have the components already, they can be recycled into a new form in minutes. Depending on the complexity, a component may take months to build.
For example, if I wanted to build an ICU discharge summary in our region now, our guys here could probably knock up a form in 30 - 60 minutes which could have any number of free text fields, as well as use the components we currently have - integration to medication module and the the problems list, automatically display upcoming appointments and radiology tests etc.
HOWEVER- to add a new component would take time and work. If I wanted that form to include the APACHE IIIJ admission diagnosis list woudl be a new component - this would take significant hours to build, and would possibly require OH support with our current level of expertise.
Happy to help if you take the lead. Could be tackled many ways within Discourse, be good to have it structured.
Are you most interested in existing CWS forms / components, aspirations for the same, other possible solutions to this problem, the digital forms people are using, or something else?
Thanks Nathan
My personal interest is two fold: exisitng CWS forms and existing CWS components around the country (who has what).
The seperation of forms from components is somewhat arbitrary, but if we can capture who is doing what and how that woudl be ideal.
There may be others who have joined this discussion who have other desires, and I woudl anticipate that a discussion woudl rapidly progress to what we want in a future state…
I have started a google doc - which anybody can edit - and this may be the simplest way.
Hi Mat, thought I’d jump in here to provide a bit more info re Cortex forms and the Cortex Designer app.
We already have functionality in the Cortex Designer app which allows for building what we call “Resources”. These allow for a group of components, i.e. text fields, options components, SNOMED tokens, photo or document scanning components etc to be bundled together and then for that bundle to be re-usable by any form designer in their own forms. This allows for consistency of data collection both in the front end presentation and back end data keys. Resources can be easily created by form designers and then shared globally across different departments.
Looking forward, our focus over the 1st half of 2021 for Designer enhancements is going to be on creating FHIR based resources. These will be “drop in” components for form designers to be able to use that adhere to FHIR concepts i.e. Conditions (Problem Lists), Observations, Procedures, MedicationStatements etc.
The beauty of these is by being FHIR based they will be read/write, both for editing of info in other places in Cortex as well as providing interoperability with other apps and systems for consistency of data and coding across the patient’s digital record.
Thanks Alastair,
It certainly sounds like Cortex continues to evolve rapidly! keep up the amazing work, it’s been impressive and exciting to watch! Cortex is something I still haven’t given up on getting in Hawkes bay… but lets just say that things don’t always go as smoothly or quickly as desired.
Sounds like the FHIR interoperability may be a significant add to functionality and itegration.
Cheers
