Pragmatic standardisation of clinical models
•Download as PPTX, PDF•
0 likes•109 views
Presentation at the first Italian openEHR Day, June 6th 2019.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Pragmatic standardisation of clinical models
Similar to Pragmatic standardisation of clinical models (20)
More from Silje Ljosland Bakke
More from Silje Ljosland Bakke (13)
Recently uploaded
Recently uploaded (20)
Pragmatic standardisation of clinical models
- 1. Pragmatic standardisation of clinical models Silje Ljosland Bakke
- 2. What’s up in Norway? • Standardising clinical information • Using openEHR • Been at it since 2014 • arketyper.no is world leading • Almost 600 participants • Implementers closely involved • Working closely with openEHR Clinical
- 3. “Pragmatic standardisation”…? 🤔 Calvin and Hobbes by Bill Watterson for August 11, 1995
- 4. How do you model the (clinical) world? Photo: Haukeland University Hospital https://www.flickr.com/people/haukeland/
- 5. Principles for modelling the clinical world • Clinical information models must be defined by healthcare professionals ⇒ There must be a very low threshold to participate • Healthcare changes all the time ⇒ Models must be changeable when needed • Model content must be predictable ⇒ Tight governance is required • Vendors and solutions come and go ⇒ Models must be independent of vendors • Clinical modelling is difficult and expensive ⇒ Modelling must be done once and shared freely • Persistence and exchange must be based on identical models ⇒ Models must be suitable for a variety of use cases
- 6. This requires pragmatic standardisation • Gradually and step by step instead of all in one go • Constant maintenance instead of 5 year revision cycles • Careful selection of what to standardise and what not to • Standardisation of one reusable concept is infinitely better than no standardisation
- 7. Clinician engagement • Clinicians are busy treating patients • Traditional standardisation processes unsuitable Photo: Haukeland University Hospital https://www.flickr.com/people/haukeland/
- 10. So how to get clinicians engaged? • Make participation quick and easy • Give them something they want • Seeing is believing Photo: Haukeland University Hospital https://www.flickr.com/people/haukeland/
- 11. How much should we standardise? Photo: Haukeland University Hospital https://www.flickr.com/people/haukeland/
- 13. What must be standardised? • Only information for reuse or sharing must be standardised • If the information is only relevant within the context where its originally recorded, the definition can be local Misunderstanding alert! Reuse or sharing does not necessarily imply exchange between solutions.
- 14. Three questions about the need to standardise 1. What kind of information is this, and what is its context? 2. Will the information be reused in a structured way within the context where it was recorded? 3. Is it likely the information will be reused outside of the context where it was recorded?
- 15. Example:
- 17. 1. Cancer diagnosis w/ ICD-10 code, diagnostic certainty and date of confirmation. Context: Cancer investigation and treatment 2. Yes, both for clinical and registry use 3. Yes, for example for CDS, analytics, or reimbursement Answer: Should be standardised
- 18. 1. TNM clinical classification 6th edition, primary tumour, colon cancer. Context: Cancer investigation and treatment. 2. Yes, both for clinical and registry use 3. Perhaps? Answer: Should be standardised if possible
- 19. 1. Obscure registry specific questions about lymph node metastases, no standardised codes, phrased as a questionnaire. Context: Cancer registry 2. Yes, for registry use 3. Probably not Answer: Choose your battles…
- 20. Local definitions • Using local information models doesn’t mean the information can only exist in one solution, but that it isn’t considered relevant outside the context where it’s recorded • Data sets using local information models can still be used in several different solutions
- 21. What if you want to standardise, but run out of time? • Make sure there’s agreement on a modelling pattern • Agree on a way to differentiate drafts from published models • Next time, start modelling work at an earlier stage? 😉
- 22. Structure isn’t Nirvana • Structured information isn’t a goal in itself • Structuring should be done when it has clear, identified value • It must be possible to capture nuances using free text • For some use cases, free text is adequate or better
- 23. Thanks for listening! Photo: Haukeland University Hospital https://www.flickr.com/people/haukeland/
Editor's Notes
- Thank you so much for inviting me to speak!
- I know my name is difficult to pronounce for English native speakers. I lived in Australia for a year, and absolutely no-one got it right, so don’t feel bad.
- Standardising clinical information models using openEHR. We started doing this for real in 2014, but the initiative has roots back to 2008, with a series of feasibility studies Our clinical knowledge manager is probably the world’s most comprehensive national collection of free, shared clinical information models, with published models covering most of basic healthcare information. Almost 600 clinicians and health informaticians are registered for participation, and about 55% of them are active clinicians. We’re very happy about this, as this kind of work typically attracts former clinicians like myself more than active ones. We also work closely with the international openEHR Clinical modelling program, ensuring that our models are identical to the international ones.
- Isn’t standardisation by its nature unpragmatic? Maybe it can be made less dogmatic by applying some simple reality checks to it that is what this talk is about.
- So how do you model the clinical world? There’s SO MUCH STUFF, both in width and depth, and much of it is really complicated! And it changes all the time!
- We’ve made some principles for this modelling, that we’re trying our best to follow. …
- And this is where the pragmatic standardisation comes in. Because there’s no way we could do this with the traditional ways of doing standardisation work. Traditionally, you’d make a standard document, it’d get reviewed, and probably improved a bit, and then there’d be ballots in ISO or whichever SDO Then you’d wait 5 years, and make a revision Because the scope here is enormous, we can’t really make a standard containing everything before we start using it. So we need a way to slice the problem up into bite sized chunks that we can agree on and then start using right away Then requirements will inevitably change, and we’ll need to change the standards too. We’ll need to be able to do this right away, not in five years, and for each little chunk, not for the whole collection of things. For this we’ll need to be able to track versions and history etc of each chunk too. Again because the possible scope is so big, we need to select our battles carefully. Some things should definitely be standardised, while others would only get us headaches with very little actual gain. Finally, we have to realise that some standardisation is better than none. Don’t let perfect be the enemy of good, and so on.
- As you all know, clinician engagement is difficult Clinicians are busy treating patients, and you don’t want to take them away from that more than absolutely necessary. Again traditionally, you’d have to get clinicians out of their clinics, wards, labs and operating theatres for whole days, and send them by plane or train to a meeting in another city. Then you’d put them all in a meeting room with food and drinks, tell them to agree on something, lock the door, and wait for the white smoke. This is SO expensive, and it doesn’t lead to the results you want
- Many of the people in the standardisation meeting won’t know why they’ve been sent there, and will get really bored. Maybe even fall asleep.
- Then there’ll always be those two people who can’t agree on some detail or other, and spends most of the meeting arguing about it.
- So how do you get clinicians engaged in standardisation of clinical information? One major issue is making models that clinicians intuitively understand and identify with. To achieve this, models have to be oriented around clinical concepts, and not for example database schemas. Technical details should be hidden or translated into human language. Then you need good tools that facilitate participation. Online and asynchronous. No meetings. Or at least no all-day meetings with travelling involved. If someone needs to travel, it should be the techies and not the clinicians. Next, give clinicians something back for their effort. Something that actually impacts their daily work in a positive way, and not just the CEO of their hospital. This could be for example help with improving quality, or functionality that helps them spend less (not more!) time on information entry. Finally, there needs to be a short time frame from engagement to result. And there has to be a result! If there isn’t you’ll lose your clinician forever.
- On to the next question: How much should we standardise, and how do we make the selection?
- These two models are obviously very different in size and complexity. But they are also different with regard to whether they should be standardised. One should definitely be standardised, and the other one is probably a more local use case. So how do we make this choice?
- If we take this really back to the basics, only information that we want to reuse or share MUST be standardised, right? If the information is only relevant in its original context, the definition can just as well be local to that context. BUT! Widespread reuse or sharing within a single solution is at least as important as exchange, and is also difficult to achieve! Here you say, “why standardise if reuse is only within a single system”? Consider a large hospital EHR, which has 100k database tables. Will you be able to achieve effective reuse within that application unless you enforce pragmatic standardisation of information models across that solution? I’d say “probably not”.
- To be able to categorise the information for standardisation and the information not for standardisation, we use three questions about the purpose of the information, and where it will be used. What is the concept of this information? Can it be generalised? Will you reuse this information in a structured way at all? If not, why not use free text? Will you reuse this information in other places? If not, why not make a local definition?
- This requires an example, and we have one from the reporting of colorectal cancers to the Cancer registry of Norway.
- This is a reporting form that’s currently filled out manually, although online, by clinicians, about the investigation of the cancer. The screenshots here are in Norwegian, but there should be enough medical latin in it to enable you to get the gist of it.
- The information here is a cancer diagnosis. It will be reused within context for clinical and registry purposes It will likely be reused outside of context for decision support, analytics or reimbursement
- This information is a TNM classification of the colon cancer, with some attributes It will be reused within context for clinical and registry purposes It MAY be reused outside of context, but we don’t know for sure
- This information is rather obscure, and difficult to generalise It will be used for the registry, but probably not for clinical practice It will probably not be reused outside of the registry context, because it’s so specific
- I think it’s worth pointing out that local information definitions can be used in several different solutions or functionalities, as long as those solutions all work within the same context.
- This happens all the time. Projects don’t have time to wait, and usually underestimates the time it takes to go through a standardisation process. Since it will happen, it’s a good idea to have a plan about how to handle it: First of all, agreement on a basic modelling pattern means it will be much easier to reconcile data between the pre-standardisation and the post-standardisation models. Secondly, agreeing that pre-standardisation models will be named or tagged in a certain way, for example using a prefix or a postfix, makes it much easier to tell which of the two was used to store which data. Thirdly, try not to underestimate the time it takes to standardise things next time. Starting modelling work as soon as you have the information requirements is generally a good idea, and this should be very early in the project.
- At the end, I’d like to say that structuring information is NOT in itself a goal. It’s difficult and expensive, often more cumbersome for users, and can lead to loss of important nuances in the information gathered. So structuring should be done when it has a clear value, for clinical use, for registries or other research purposes, for necessary reporting, or if it in some cases makes information entry less cumbersome for users. Remember that it should always be possible to add nuance to structured information using free text, and in some cases free text is adequate or maybe even the better choice.