Defining electronic health record functionality – a process driven approach

We recently released an architecture specification for functionality in clinical IT systems for Helse Nord (see first post and about pages for more on Helse Nord). Or, to be more precise;

a future state description for how electronic health record (EHR) and medication systems should support surgery pathways at the hospitals of the region.

This post features the major business impact, some architecture experiences and a list of lessons learned from this work.

The architecture specification covers this scope:

  • Breadth: It spans two areas of business functionality (general EHR and medication support in surgery pathways)
  • Domains: Processes with information needs and application functionality
  • Abstraction: It is described in logical terms over all but functionality choices are informed by planned physical IT.
  • Future state date: 2021

It is the primary outcome of collaboration between health care professionals, IT expertise and architects in Helse Nord. It was recently signed off by top management as the target specification and preferred method by which to further define and implement the EHR and medication systems across hospitals in the region.

This initiative was mentioned in a previous post that touched upon some of the benefits of coordinating modelling of processes, information needs and applications. Now, a few months later, models have been modelled, arguments have been had and application functionality has been selected.

All objectives were not met but we finished standing after an educational journey where we discovered a liveable EA fit for this real world problem.

Business outcome

The core business value lies in the selection of functionality between two potentially overlapping systems (EHR and medication). Redundant functionality in this case is not only bad usability but a real danger to patient safety since we are dealing with functionality for administering medication and measuring vital patient signs. This rids implementation projects of the burden of making such choices and enables them to focus on implementation.

Defining electronic health record functionalities

The resulting document and models now represent a specification for how the systems should be configured for functionality and thus give input also to which integrations needs to be enabled. The architecture contributed by informing and supporting the selection process with process models, domain principles and a standard reference for EHR system functionality definitions.

Architecture side-effects

The ambition is to use the described approach as a template to extend the architecture. This will increase the quality of the architecture since covering more processes, patient pathways as well as more systems will benefit the functionality selection. This is an important outcome of reuse and an important acknowledgement of the architecture approach in general in the organisation. We have also gained valuable experiences and architecture outputs as follows:

  • Model templates and guidelines for process and information modelling were developed and tested.
  • Standard for EHR functionality was chosen (the HL7 EHR-System Functional Model)
  • A practise of process driven approach to specifying IT was tried and tested
  • Stakeholder engagement, facilitation and participatory techniques were tested
  • Domain specific architecture principles were developed

Examples of lessons learned

This blog is primarily about what has been tried and tested and the lessons learned from that. Working with the target architecture we have seen many issues and challenges in architecture development:

  • Domain knowledge is vital when scoping the effort (and defining the future state)
  • Outcome-first approach when scoping the modelling ambition (trade-off with architecture practise requirements)
  • Experiences with industry standard for functionality definitions (useful but challenging)
  • Identify and agree early on the total set and quality of model types and their fit to the overall process
  • Be explicit on what factors you consider in the architecture choices and consider a rough guide on how and when they are applied.
  • Make room for deviations, i.e. don’t over-engineer to the degree that you have difficulties to allow them.

This post represent an account of the work behind these experiences and is written to be reused and referred to in future posts examining these. So for now I’ll settle for this list of lessons learned that you can expect to read more about on these pages.

See you soon and thanks for your attention!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s