{"id":7698,"date":"2018-07-25T02:15:29","date_gmt":"2018-07-25T02:15:29","guid":{"rendered":"http:\/\/orionhealth.weareiceberg.co\/?p=877"},"modified":"2024-08-13T02:28:02","modified_gmt":"2024-08-13T02:28:02","slug":"how-to-involve-clinicians-in-health-it-projects","status":"publish","type":"post","link":"https:\/\/orionhealth.com\/global\/blog\/how-to-involve-clinicians-in-health-it-projects\/","title":{"rendered":"How to Involve Clinicians in Health IT Projects"},"content":{"rendered":"\n

HL7\u00ae FHIR\u00ae<\/a> is an established standard for significantly lowering the technical barriers to healthcare interoperability<\/a> by building on concepts that are widely used in other domains such as the finance and travel industries. This provides concepts familiar to the implementer community and makes FHIR easier for organisations and people unfamiliar with healthcare to participate. It also allows them to bring forward their innovative ideas for the benefit of patients and providers.<\/p>\n\n\n\n

But what about the healthcare providers themselves? How does FHIR help them participate? The issue is that healthcare is inherently more complex than other industries, partially due to the increased security needs around sensitive medical information. Healthcare is also a domain that we are learning about rather than defining \u2013 and these days with the advances in genomics and other disciplines it is becoming ever more so. We need clinicians deeply involved in healthcare projects \u2013 it\u2019s well recognised that\u00a0projects that are clinically led have a higher success rate<\/a>\u00a0than those that are technically led.<\/p>\n\n\n\n

FHIR does help \u2013 but it\u2019s not enough by itself. In the past few months we\u2019ve been working on a process to make it easier for clinicians to communicate their requirements to the technical people responsible for implementing them. This is being tested in a New Zealand project to capture Adverse Events, and make that information available to those delivering medical care, as well as for reporting and other analytical purposes. <\/p>\n\n\n\n

We started the project by firstly defining the requirements \u2013 what we wanted to achieve (as described above). This included a number of specific scenarios to cover off the range of use we were expecting.<\/p>\n\n\n\n

Next, we described the high level architecture within which the project would operate. This helped us define the nature of the exchanges needed to fulfil the requirements. In our case we wanted to capture Adverse Event data and store it in a common repository for sharing and analysis, respecting privacy of course.<\/p>\n\n\n\n

To define the information needed, we used the\u00a0clinFHIR Logical Modeler.<\/a>\u00a0This allowed us complete freedom in terms of the actual layout of the individual data elements, but meant that we could take advantage of the datatypes defined by FHIR \u2013 which both saved time and will make the eventual transition to \u2018real\u2019 FHIR artefacts easier. In practice we used a data projector to display the model as we were building it, and updated it in real-time during regular meetings. This saved time compared to sharing and reviewing documents that had been updated separately. Having created the first draft of the model, we used a new clinFHIR component \u2013 conMan (Connectathon Manager \u2013 a purpose-built tool for supporting FHIR connectathons) \u2013 to automatically create a Forms based User Interface from the Logical Model into which we could enter the data required for each of the scenarios that we defined in the first step. This allowed us to validate that the model was fit for purpose \u2013 that it has \u2018spaces\u2019 for all the information that we require.<\/p>\n\n\n\n

The next steps for the Adverse Event project will be:<\/p>\n\n\n\n