Requesting “stats”?  Don’t expect your data analyst to have a crystal ball…

Standard

In Business, information is an extremely valuable asset if used and requested correctly.  When working as an eHealth Systems Administrator, I would get queries on a daily basis asking for “stats” or “data”.  A standard query would be along the lines of “Can you get me stats on medical imaging for the past 12 months”.  It’s at this point that I look around for my crystal ball…

Are they looking for a single figure (total services), or a trend (increase of services by month).  Do they need to know the demographics of the patients who are having these services, or if the services are paediatric or adult cases?  The permutations of options are endless and since I’m yet to find a magical crystal ball that gives me all the information surrounding requests, it’s important to provide the correct specifications upfront.

Here are 7 quick steps you should consider that will help you get the right information faster:

1.      Provide context for what you’re asking

“With budget restrictions we’re reviewing the staff FTE against the number of services performed, broken down by modality to present to Executive”.

By providing context of your request, it allows the data analyst to configure the information to be the most appropriate for the target audience.  In the end, this will help you look good when presenting the stats.

2.      Explain specifically what you’re trying to prove with the information

“We are trying to prove that the requests for radiology services are increasing for modalities x, y and z, and that current FTE requirements are increasing”.

Data can be presented as information in many varying ways and this is key to achieving the desired results when using the information.  By giving the data analyst some idea of what you’re trying to prove they are able to select and present the data in the most persuasive information format for you.

3.      Explain the format you expect to receive the information

“We would like the information in csv format”

While you may think that it’s obvious that you would like your information to be presented as a pie chart, the data analyst may think you’re after the raw data in a csv spreadsheet.  Save confusion and be upfront with what you’re after.

4.      Is there any specific detail you require

“We’re looking for the data broken down by month, with total value of services including GST at the end of each row”

This is one of the most crucial factors of information requests.  I’ve been through requests that have had 20 or more iterations of specification because the person requesting the information did not originally specify exactly what information they wanted displayed.  Often this is one of the most time consuming factors in delivery of information, as the later the specification is finalised, the work to retrieve the data can increase exponentially.

5.      Outline whether you have approval for this information

“This request for information has been approved by the ethics board of the organisation”

Whether you’re using the information requested for departmental use, organisational use or personal/educational use, most organisations will have some form of vetting requests for data held by the organisation.  It’s important to understand what authorisation you require and gain it before coming to the data analyst to provide the detail.  If you don’t, you may get yourself and the data analyst in unnecessary trouble.

6.      Explain if the request is time critical

“Can I please have this information by COB Tuesday?”

While you feel your request is important, please understand that it is additional workload to the data analyst.  Give the data analyst a realistic expectation of your timeline requirements and they will do what they can to work it into the schedule.  Treat everything as if it was needed yesterday, and you’ll end up having all your work at the back of the line.

7.      Remember your manners

“I realise you have a large workload and I appreciate your effort, thank you.”

Always remember that you are asking for help, and that you’re asking the data analyst to do extra work for you.  Everyone is busy, but there is always time for manners.  If you treat someone well, more often than not they’ll be willing to go the extra mile for you.

Contact me via: hello@theprojectlab.com

Is your Health Organisation building an eHealth “Web” or “Waterfall”?

Standard

The image associated to this blog post shows two typical (very simplified) structures of an eHealth environment with the same number of clinical systems.

With a big drive in implementing and upgrading Clinical Information Systems, which eHealth integration structure is best for your organisation?  Below I’ve outlined a high level overview of the two structures and how they impact on the eHealth environment of your organisation, mainly from a technical point of view.

The first structure is an eHealth “Waterfall”, and is a very typical design of early (and many current) eHealth environments.  For the most part, the clinical information systems operate independently from each other with little or no knowledge shared between them. Data tends to flow in a single direction from the patient administration system (PAS) to the clinical information system (CIS) and all roads eventually lead to the final source of truth, the electronic Medical Record (eMR) or electronic Health Record (eHR).

The second structure is an eHealth Web, and is the emerging structure that is organically building as eHealth environments and clinical information systems become more advanced.  In this structure, rather than the clinical information systems acting as digital islands from each other, they create connections and share their data, essentially creating multiple minor eMRs with a specialised clinical focus for the department who owns it.

There are pros and cons of implementing each structure, and these should be considered early before your organisation decides the structure for you.  Below I discuss some of the key considerations with each design:

eHealth Waterfall Structure:

Pros
Implementation costs are lower with minor integration requirements (less interfaces to design, configure and test). There is less duplication of data from an organisational perspective, requiring less infrastructure to host and maintain.  Change management costs are lower with fewer interfaces to test and maintain lower system outage management requirements.

Risk profile of this structure (technically) is lower (*not necessarily clinically lower) due to the data management of an eHealth waterfall structure being mostly centralised.  Also, typically there are 1-2 client facing interfaces for clinical data from a clinical information system, reducing administration requirements.  Change management to the clinical information system should only affect one clinician-facing interface (aside from the system itself) requiring review (the eMR/eHR), further reducing risk overheads.

Cons
Implementing a waterfall structure segregates your data causing a lack of ability to employ powerful automated decision support tools based on other diagnostic service results.  The segregation of data also causes a requirement to have multiple applications open and logged in (at least the clinical information system and the eMR/her) for the full patient clinical record.  This can be inefficient clinically and frustrating for the user.

eHealth Web Structure:

Pros
The ability to have Radiology, Pathology and other diagnostic service data available in an Emergency Department Information System (EDIS) can be extremely powerful in the efficient delivery of clinical services via decision support tools.  These decision support tools can reduce unnecessary tests (reducing cost to the organisation), create automated smart workflows and reduce risk to patients. Furthermore, the display of diagnostic service results can be configured to provide the most efficient view of the patient for a specific department. I.e. the requirements for layout of pathology and radiology data including what data is displayed will vary from department to department based on their clinical needs and specialty.

Cons
The unfortunate truth is the more integration involved in an eHealth environment, the more opportunity there is for error to be introduced.  The old saying of “measure twice, cut once” applies to eHealth, except it tends to be more like “measure ten times, tentatively cut once…”.  The ramifications of data being misinterpreted due to the incorrect configuration of an HL7 feed can be disastrous (and fatal). One of the increasingly difficult factors of an eHealth Administrators role is ensuring the integrity of their systems diagnostic data being displayed in remote systems.  The more systems displaying their data, the harder it gets to safely manage this.

An individual diagnostic interaction may not be a large amount of data.  However, combine the size of an organisation with a years worth of diagnostic services and you will have hundreds of thousands of interactions (and more if you’re part of a multi-site organisation).  If this data is being processed and stored by multiple Clinical Information Systems, the requirements for the ICT infrastructure sky rocket, along with the cost.

Aside from infrastructure costs to host this eHealth structure, your organisation will have increased ongoing management/administration costs for each system.  As system upgrades, security patches and configuration changes are made, there may be upwards of a hundred individual tests required to verify the integrity of the clinical data as it’s displayed. If you have six systems displaying diagnostic data from your clinical information system, then your testing requirements have grown six fold.  This effectively increases your salaried time costs by six fold for each change to eHealth systems (which may occur on a weekly or monthly basis).

Summary:

So which eHealth structure is best for your organisation?

The truth is… Both.

While it looks like there is a lot of negative impact of an eHealth “Web” structure, the fact is that it is a more complicated beast, but the clinical relevance is extremely important.

Neither one nor the other will provide the best outcome for your organisation.  Having strong governance in place to handle a hybrid setup will be the best way forward, ensuring highly technical services have the information they need to effectively support the clinical needs of the patient.

One key factor that will make the process of designing your eHealth environment easier is the implementation of a solid eMR/eHR, but I’ll leave that discussion for another day.

10 things I learnt during the Tasmanian statewide RIS/PACS project:

Standard

10 things I learnt during the Tasmanian statewide RIS/PACS project:

1. It doesn’t matter what position you hold on the project, everyone needs to step up.

In large projects, there should be no weak links.  It doesn’t matter what your title on the project team is, everyone should be backing each other to reach each milestone.  Sometimes this requires you to eat some humble pie and give others the time to shine.  If you find someone struggling, get behind them and back them up.

2. Mix your professions and get team members involved in every aspect early.

One of the most important success factors of the project was to allocate resources appropriately from the start.  We had a mix of eHealth, ICT, Clinical and Business resources allocated directly to the project.  Furthermore, these resources were able to get a first person view and interaction with each others specialties, and understood the impact of their individual decisions on the group.  This was a powerful scenario.

3. It’s important to recognise the soft skillsets of your team members, and how to utilise them.

Along with professional skillsets, it was vitally important to understand the soft skills in the project.  The presenters and the analysts, the talkers and the writers, the leaders and the followers.  Putting the right person in the right situation allows tasks to be completed efficiently and with a high degree of success.

4. Don’t underestimate the value of informal chats, especially with unofficial stakeholders.

A lot of the crucial knowledge gained during the project was the result of informal discussions.  Chatting with clinicians or IT specialists during lunch breaks, asking questions and more importantly, listening to questions.  There is a wealth of knowledge surrounding projects and tapping into that knowledge-base can be a significant factor in benefit realisation.

5. Recognise and challenge your assumptions.

There are formal assumptions recognised by the project, and there will be informal assumptions that each team member of the project will have.  It’s vitally important for the informal assumptions to be recognised early and for the team member to understand if they have the skills and knowledge to make that assumption.  The slight modification of a code set, or the addition or removal of a business workflow can have significant effects on the outcome of the project.  When making decisions, no matter how small they appear, always be willing to challenge your view of the situation and see if you require external advice.

6. Breathe

Large projects are a marathon of little sprints (which I talk about in point 8).  If you attempt to hold your breath and sprint the whole way, you’ll pass out.  Emotionally, physically and mentally, if you burn out, you’re no good to anyone.  When you get opportunities, you need to remember to breathe in the fresh air, take time to be out in the sun and rejuvenate the soul.  Each person has a different capacity to focus for varying periods of time.  Understanding what your capacity is, and when you need to take time out is important, for you and the project.

7. Learn to love the chaos

While we do our best to keep projects under control and on target, there will be situations out of your control where you will need to roll with the punches.  Instead of taking a beating, turn it into a boxing match. In our project we had two major events occur that no-one would have seen coming.  We had a volcano erupt on the other side of the world that produced an ash cloud, causing air traffic in Australia to be halted, resulting in key engineers being stranded in another part of the country.  We also had a tsunami destroy hardware we needed that was waiting on a dock to be transported from another country.  Modify your headspace to choose the situation, not let the situation choose you.

8. Recognise when you’re mid-sprint, and commit to it.  Find your “Flow”.

There are certain tasks that are quick and easy, and other tasks that require an unholy level of focus.  The best description I’ve heard of the second scenario is to require a state of “Flow”.  When in this state, you block out everything around you and focus solely on the critical factors required to get you through a situation.  Some people are better than others at recognising when they’re in a state of flow, but the key is to commit to the flow for the duration of the sprint.  Sometimes this requires you locking yourself away from distractions – allow this to happen, but only when needed.

9. Pick your battles.

Amalgamating multiple business units to use a single system and (more or less) a single workflow requires a lot of co-operation and negotiation.  The mammoth effort of this should never be under-estimated.  The key to success is understanding your core requirements, explaining them, committing to them, and negotiating on everything else.  There will be tough and un-popular decisions, but the greater good of the project needs to be considered above an individual point of view.  Be ready to put your ego in your back pocket.

10. Celebrate the wins.

A large project is not a single achievement, but a series of collaborative wins.  Remember not to take life too seriously, and celebrate the small stuff.  Recognise the efforts of those around you, and pay close attention when someone steps out of the comfort zone to reach a target.  Take the time to support and congratulate your fellow team.  It might be in the form of an email, public recognition in a meeting or a cheeky chocolate frog left on their desk during the day.  The little things count.

Image Sourced via Google with “Labelled for reuse” enabled (http://upload.wikimedia.org/wikipedia/commons/e/e5/Radiology_1300195.JPG)

eHealth needs disruption – but not as we know it…

Standard
We live in a world where we’re constantly seeking a silver bullet, a perfect pill or an “App For That”.  Over the past decade there has been a significant drive to improve health care through the integration of IT and Health.  Yet, with the vast improvements in both health and technology, we still have trouble getting it right.
 
Why?  Because we’re still using old school mindsets among a new school setting.
 
eHealth needs disruption.  However we don’t just need more technology and applications, we need education and collaboration.
 
The days of being able to focus solely on your profession are gone, and we now need to understand that we live in a connected world, and our actions directly (or indirectly) affect those around us.  No longer is the Executive table the location where Clinical, Financial, IT, Legal and other specialties come together – this should be happening at the ground level.
 
Each specialty trains for years in their specific field to become specialists in providing the best service possible in their area of expertise, regardless of what industry you’re in.
 
In the past, this worked; today, it doesn’t.
 
I’m not saying that I as an IT professional need to learn the intricacies of Neurosurgery.  But I do need to understand the impact I have on a surgeon if I knock out the IT network to their Operating Theatre.  Similarly, Doctors need to recognise that billing categories are now vitally important to get right, as the funding model for their job relies on them categorising the patients correctly.  Legal need to understand that old privacy policies may actually hinder patient care more than they support it.  We all need to understand that we’re a link in the chain of eHealth service delivery and we cannot afford to break the chain.
 
This also directly applies to eHealth Projects.  Regularly, small projects turn into medium projects, and medium projects turn into large projects due to a lack of knowledge surrounding the full lifecycle involvement (and cost) required by each specialty. 
 
From my experiences working on the floor in Hospitals, it’s inspiring to see Doctors from various specialties coming together with their combined knowledge to resolve a patients issues.  We need to take this approach and broaden the spectrum with staff from various industries (Clinical, IT, Legal, Finance etc) collaborating on a regular basis to disrupt old processes.  We need to break down the physical barriers of phone lines and email. We need to step back from technology, get out from behind the desk and meet face to face in order to find new smarter ways of utilising our current resources. 
 
For me, this is how we will disrupt eHealth.
(Image Source via Flicker under Creative Commons: https://www.flickr.com/photos/67272961@N03/6123892769)

Purchasing eHealth software or system? Here are some points to consider…

Standard

The acquisition process for a new eHealth system can often be a confusing and lengthy process for Clinicians.  This post is designed to provide a few points for the Clinician to consider, and a list of points the Clinician can query the Vendor of the software/system to be purchased.

It is important for Clinicians to understand that eHealth software purchases need to be considered as “eHealth system” purchases, as the full scope and cost of implementing and operating the software is more than the software itself.

Armed with answers to the below queries, the Clinician should get off to a head start with the ultimate aim of improving the efficiency of gaining acceptance from Management and IT/eHealth Departments.

Client Queries (Person recommending the purchase of the system/software)

  • Who is the sponsor of the project?
  • What problem is this system/software purchase going to solve?
  • Total budget for project/system
    • Is the budget single source or recurrent funding?
    • How will recurrent costs (i.e. system administration) be handled?
  • Who will provide ongoing support for
    • System Upgrades
    • Day-to-day Data Management
    • Testing & System Configurations
    • Training
    • Ad-hoc support requests
    • Etc
  • Timeline for project/system implementation
  • Impact of not approving the project/system/software
  • Any known associated projects or legislation that may impact this project?
  • Have all current relevant systems been reviewed to ensure we cannot already provide this service?
  • Expected annual growth/use of service/system (i.e. 100,000 new records per year)
  • Is there a definable Return On Investment (ROI)

 Vendor Queries (Company providing the system/software)

  • Is the “system” a local plugin, stand-alone software, client/server, cloud or other based?
  • If there is a server involved
    • Server to be provided by vendor or client?
    • Can the Server be virtual (and which platform) – or must it be physical?
  • Service Level Agreement (SLA)
    • 9-5 or 24 hour?
    • Weekdays or 7 days?
    • Required response time
      • 4 hour or next business day?
      • Onsite or remote assistance?
    • Ramifications of not achieving SLA performance?
      • Are there staged financial penalties?
        • 100% uptime full cost
        • 99% uptime 5% penalty
        • 90% uptime 15% penalty
        • Etc
    • Defined scope of SLA
      • What specifically would cause the SLA to be broken
        • Partial system outage?
        • Full system outage?
    • Costed SLA for 3,5 & 10 years (i.e. how much does ongoing support cost, and does it increase with age of the system)
    • Are system upgrades (major and minor) included?
    • Are there support services local to the Clients town?
  • What is the expected FTE requirement for client System Administration?
    • Show the Client/Vendor responsibility breakdown
  • Is the Data housed locally or remotely?
  • Is remote access required by vendor?
    • If so, what network ports are required to be open on the VPN?
  • Backup/Disaster Recovery management – who’s responsible and how
  • Cost structure?
    • License Structure (cost per record, per user, per install/PC etc)
      • Any other licence costs not included in base license (i.e. Voice Recognition maintenance)
    • Total expected cost?
      • Initial implementation (upfront cost)
      • 3 & 5 year projections (based on clients expected growth/use above)
        • Including hardware rollover – and expected timeline for hardware rollover (i.e. physical servers to be replaced at the 4 year mark at cost to Client/Vendor?)
  • Are there any third party companies involved with the service delivery (subcontracts etc)?
  • What training is provided by the Vendor
  • Are there any options/extras not included in the base purchase package
    • Provide a costed options list
  • Does the system meet industry standards where appropriate?
    • User Accounts
      • MS Active Directory integration?
    • Messaging
      • HL7 (inbound and outbound)
      • DICOM compliance
      • SNOMED Clinical Terms?
    • Databases
      • Oracle/MS SQL?

Please note this is not a definitive list of all information you will require to satisfy your organisation.  However it will give your organisation a good understanding of what specifically you’re asking them to get involved with and hopefully increase your chances of successful acquisition.

(Image sourced via Google Images with “For Reuse” filter enabled – source: https://www.flickr.com/photos/kkirugi/4543261380/ Under Creative Commons)

SIGIGIB – the acronym that changed my approach to everything

Standard

SIGIGIB – See It.  Give It.  Get It Back.

This is an acronym that was taught to me a decade ago when playing senior hockey at a local hockey club (North West Graduates).  As a team, we laughed when it was said to us, but once explained, it was a pivotal moment in the direction of my hockey, and my life.

In hockey, it’s exactly how it reads – you’re not done when you let the ball go.  Instead, get yourself in a position to help your team mate and get that ball back – then repeat.  If a team plays by this philosophy, it’s almost impossible to lose.

In business, it’s strangely similar.  Figure out the playing field, recognise what you have to give, support those around you and in return you’ll be supported back.  The earlier you figure this out, the further you’ll go.

I’ll break down the three major steps in this philosophy how I see it – and maybe this acronym can have a similar impact on you.

The Field –

The Field may be literal, or figurative.  As a member of a team, you need to size up your opponent, understand the boundaries and recognise the challenges ahead of you.  In hockey, we did this religiously, understanding the speed, skill and accuracy of our opponents before stepping onto The Field.  In business, it’s exactly the same scenario.  Don’t ever go into a meeting or business environment without understanding who will be there, what they’re known for, and what agendas are on the table.

What You Have To Give –

From my perspective, the worst thing you can do when in any team environment is not know your key skill set.  In hockey, I was a play maker.  I wasn’t particularly good at scoring goals, and I wasn’t particularly good at defending – but I knew that I could connect the dots between the defenders and the goal scorers well – so that’s where I spent my time, and it worked out well (for the most part).  In business, I do a very similar task.  I connect the strong technology specialists with the requirements of the business to create a harmony between the two.  This allows me to go into meetings with strong expectations of what my role is, and clarity of how to connect the dots.  The sooner you can define what you do in a single sentence, the more productive you will be for yourself, and those around you.

Support Those Around You –

In sport, there is a saying – “A Team of Champions will always be beaten by a Champion Team”.  In my experience, there is a reason these popular sayings stick around – because more often than not, they’re spot on.  In hockey, I was amazed at some of the final results in games, considering the teams that were playing.  The key was to see how the members of the teams played together – especially under stress.  It’s at this point when a team is under the pump, that coming together as a unified entity achieves incredible results, for everyone one involved – including you.  It’s a powerful thing when you stop focusing on your self, and start focusing on helping those around you.

So there you have it – one of the key acronyms I live my life by – and hopefully it will help you in your endeavours.

See It.  Give It.  Get It Back.

*Hat tip to Mullens and Bucket – you know who you are.

(image sourced from wikipedia.org – via google.com with “Labelled for reuse” filter enabled)