Archive for the ‘Visual’ tag
It is interesting how paper-trained we are. It is often hard for clinicians to think about how to design EHR systems – particularly documentation – in a way that breaks the locality of information and the paper-bound thinking of forms and move to information. I see a lot of systems out there that promote having “digital forms” that are direct copies of paper forms — including having forms that do not fit on a single screen (because they are 8 1/2 x 11 format instead of screen shaped) and “page turning” that corresponds to the pages of the form not the GUI design of the computer.
You can see how this thinking works, when clinicians request that certain forms are available on the computer. Building forms to match paper is often the quickest technical solution and one that, sadly, get’s an easy “check” from users as they can compare the form to the computer screen for “accuracy”. Without thinking too far along the path, you can see how things get developed. Quickly scanning in the blank form as a PDF to create a background that REALLY matches the form and then adding fields on top to add text. For pizzazz add some auto-populating demographics and BOOM! It works even better than paper… Four hundred forms later and you have the electronic paper record.
The forms are important – as they are a way we consistently communicate with various groups on paper and THEY have benefits of having standard forms, just like standardized electronic user interfaces improve efficiency and safety, so do standard paper forms. But the benefit is for the end consumer, not necessarily for the clinician entering the data into the form.
Often there are better ways to design systems to support a user’s workflow while supporting the required output. There are examples of how to do this – building data capture to support clinical workflow. Clinical Decision Support (CDS) can be used to ensure that the right information is captured. Reports can then be generated to print out the appropriate forms as needed. Multiple forms would use the same data and the clinician would not have to jump around re-populating different “standard” forms with multiple pages that scroll off the screen.
The tricky part is, of course, being able to capture the data in an efficient manner that provides sufficient semantics that allows the computer to translate your documentation into the various unstandardized tick boxes for concepts developed for specific forms, something that works for CDS, and is something a clinician will tolerate.
And that takes more work and a deeper understanding of the types of knowledge that are needed without the limitations of paper.
Of course, health information systems are not the only systems that have been built from their predecessors — that is how we evolve many things. Web “pages”, for example… oh and there there were trains that evolved from horse and carriages.
I have been working with a friend and colleague over the past month sketching out an idea to develop software for the XO laptop, which is part of the one laptop per child
(OLPC) project. The idea is more about how to get others to design and build software for OLPC and we can help facilitate.
We are exploring how to engage students in BC to design and develop health and health education materials with partner communities in developing countries who are part of the OLPC. It is an exciting idea to get students, both high school and university students, to get together and learn about computer science and about healthcare while flexing their creative design muscles in coming up with tools to help children thousands of miles away.
Seems like we are not the only group who has thought of this, of course. There are several projects proposed and in development through the OLPC and can be found on the OLPC Wiki.
We are piloting our OLPC-Health Design Fest this month – it’s a half day paper prototyping event. I am very excited to see how it works.