Short entry for some work that I stumbled upon accidentally during vacation.
http://healthcare.nist.gov/resources/docs/FirstAmerican/NIST_NCPDPMedRecStdsOverview.pdf
This seems very consistent with the dimensions that we are working on (and I will try to formalize) for Medication Documentation (link missing :-( ). In any case, if the analysis goes to the data mechanisms we discussed in IHE Pharmacy, the amount of technical work seems very very small when compared to the dissemination and awareness material.
We are close to a medication structure compatible with
- NCPDP
- Blue Button
- CCR
- CDA / IHE Pharmacy
- HL7 v2 / IHE Pharmacy
- Vaccines
Sunday, 15 September 2013
Saturday, 30 March 2013
Use of Barcodes in Healthcare
This seems old and not including e.g. GS1 who has applied a great effort to consistent adoption.
But it's a very comprehensive and useful guide.
I'd put this on my must-read before any healthcare/pharmacy automation process.
Implementation Guide for the Use of Bar Code Technology in Healthcare
Most of this can be applied for basic uses of RFID. althought fortunately RFID technology is allowing uses that were not possible with barcode.
But it's a very comprehensive and useful guide.
I'd put this on my must-read before any healthcare/pharmacy automation process.
Implementation Guide for the Use of Bar Code Technology in Healthcare
Most of this can be applied for basic uses of RFID. althought fortunately RFID technology is allowing uses that were not possible with barcode.
Friday, 3 August 2012
Tuesday, 22 May 2012
Healthcare Big Data
Part 2: The method
The fun part with designing a big data system is that both ends of the tunnel have a fuzzy light: the data is not in a stable, normalized form, and the intended presentation is itself not clear, mostly because a better idea of what we want is only possible when we start having something.
Coming up with a universal data model that covers all the cases is not possible, for the simple reason that the goals are many, and they are growing and changing.
To address this challenge, I started using a simple analysis methodology:
I separate the scenarios from the use cases, and they both evolve hand in hand.
- Use Cases are the intended actions that rely on the data, independent of the fact that the data may be available.
- Scenarios are the conditions and data that can be available, regardless of their use.
According to W. H. Inmon (if I’m not misquoting; I lost the reference), the data analysis does not present the information needed for use cases. It represents what we could possibly do with it (In a next post I’ll make a good analogy where this should be clear).
For big data, we can iteratively build up the data model as more use cases are found; and iteratively build up possible uses for the data, as more data becomes available and is integrated / federated into the data model.
These two aspects are synergetic: New use cases can provide need for new data, and availability (or unavailability) of data can determine the uses for that data.
This applies to data and metadata:
Unavailability of some data can be interpreted differently (not having a report of administration of an injection in a hospital has different impact and meaning from a patient’s lack of reporting taking anti-depressive medication).
The information quality may depend on who provides it (for example some cultural factors will influence the customer’s report of use of drugs, contraceptives, etc.)/
When building the model (and very carefully separating it from the use cases), my rule is: keep everything just in case. For example, a cell phone can have an attached device that monitors the patient’s glucose levels. This is not the same as a measurement by a nurse, but we don’t want to waste this information just because a hospital currently does not want to use it.
Thursday, 10 May 2012
Healthcare Big Data
Part 1: Introduction
When it comes to big data, healthcare is an excellent place to find it.
Data is structured and captured in different manners, there’s lots of data, and it is hard to get any sensible information out of this data put together.
In healthcare, traditionally, data (and models) are split by department; data needed for a department were modelled according to the needs of that department. Most of this data is not shared. But data that represent patient or workflow information could be shared: patient demographics, patient location/status, current attending physician, allergies, wound documentation, which user accesses the patient record...
The need for cross-department (and cross-institution, and cross domain) data is emerging as important e.g. for decision making. This data is important for clinical reasons (informed decision making), and operational reasons (e.g. Meaningful Use in the US, and the growing interest in Europe for operational/efficiency improvements).
Even breaking the boundaries between healthcare domains will be insufficient: Healthcare data is not a silo. Institutions and patients collaborate on health data, but also other institutions can play a role. Work and social environment, demographics information, etc. can be potentially relevant.
Coming down to spaceship earth, within a healthcare organization, information can be captured anywhere, and this information is getting more stretched to be viewed under different perspectives.
Data Interfaces (messages) are usually designed to provide just enough data for continuation of a workflow. And these data are modelled for the specific needs of the originating system. If we want to know a patient’s full history, there will be some collage work, especially if we want the information to be in a usable form.
Here I propose a look at the problem, the possibilities and the goals, and I present a way of jumping across these water lilies. The keyword is: Iterate.
Next:
- Part 2: The approach
- Part 3: The delicious analogy
Wednesday, 21 March 2012
Data are not a byproduct, but the fuel for an operable system
As systems focus more on data, its meaning and its use in different contexts, it seems fair to affirm that while Data was the byproduct of previous software applications, data is presently the circulating blood of applications and system architectures.
Sunday, 26 February 2012
System requirements and system specifications
I am putting effort in system delivery - making sure that the product developed really works, and helps!
Observing that software development processes are still clones of "hardware" system design (where one piece is designed in detail for a few months, and implemented in the next months), I have struggled with one conception that contributes to lack of quality and effectiveness, and - very important - to collaboration between the participants:
The notion that the initial plan is complete and accurate, and deviations are accidents.
or
The idea that once we know the plan, we know the outcome.
The final detailed specifications of a system are changing even after delivery, and the capture of this information can help make a product great, by allowing good knowledge of the product.
This seems essential in complex system design, and in healthcare it is an absolute must.
It also seems essential in Agile development, where the focus is in delivering value time after time, and clinging to an initial plan is not a (good) option.
So, the delivery phase of a system should include documenting any relevant aspects that were not detailed upfront.
- How the screen actually looks like
- What is the impact of the technical choices in functional aspects (like performance constraints, etc.)
- What detailed findings are there that can provide additional info
...and yes,
- What have we learned that can trigger new requirements or ideas.
This seems much better than the exuberance of documents to guess what is going to be the outcome.
In short - it is impossible to know all the details upfront, but this doesn't mean that details are not important.
Observing that software development processes are still clones of "hardware" system design (where one piece is designed in detail for a few months, and implemented in the next months), I have struggled with one conception that contributes to lack of quality and effectiveness, and - very important - to collaboration between the participants:
The notion that the initial plan is complete and accurate, and deviations are accidents.
or
The idea that once we know the plan, we know the outcome.
The final detailed specifications of a system are changing even after delivery, and the capture of this information can help make a product great, by allowing good knowledge of the product.
This seems essential in complex system design, and in healthcare it is an absolute must.
It also seems essential in Agile development, where the focus is in delivering value time after time, and clinging to an initial plan is not a (good) option.
So, the delivery phase of a system should include documenting any relevant aspects that were not detailed upfront.
- How the screen actually looks like
- What is the impact of the technical choices in functional aspects (like performance constraints, etc.)
- What detailed findings are there that can provide additional info
...and yes,
- What have we learned that can trigger new requirements or ideas.
This seems much better than the exuberance of documents to guess what is going to be the outcome.
In short - it is impossible to know all the details upfront, but this doesn't mean that details are not important.
Tuesday, 10 January 2012
RFID and tracking of stuff
Going back to hardware days.
Getting myself an RFID reader to start playing with cards, tracking and the corresponding software.
Expensive stuff - will get a cheaper one:
http://www.alibaba.com/product-gs/510277926/13_56Mhz_NFC_RFID_reader_factory.html
- Tracking people
- Tracking things
- Tracking things that appear with other things, or with people
- Tracking flows of things across places.
Getting myself an RFID reader to start playing with cards, tracking and the corresponding software.
Expensive stuff - will get a cheaper one:
http://www.alibaba.com/product-gs/510277926/13_56Mhz_NFC_RFID_reader_factory.html
- Tracking people
- Tracking things
- Tracking things that appear with other things, or with people
- Tracking flows of things across places.
Wednesday, 28 December 2011
Scenarios for good use of medication information
A system for keeping track of medication data would eventually see these scenarios:
(scenarios --> refer to available data, and what kind of static initial conditions can exist)
- Patient’s medication is inside the same system and follows the basic scenario workflows – prescribed, and validated, dispensed and administered exactly as prescribed. CMPD.
- (Chronic) patient is inside the hospital and all his medication activity is recorded inside the same system and follows the basic scenario workflows – prescribed, and validated, dispensed and administered exactly as prescribed
- (Chronic) patient is inside the hospital and all his medication is inside the same system and follows the basic scenario workflows. In addition, patien has a contrasted exam and a surgery in the hospital.
- (Chronic) patient is inside the hospital and all his medication is inside the same system and follows the basic scenario workflows, but medicaton is replaced in the Pharmacy by an equivalent
- Patient is admitted to new hospital and reports known history to admitting physician
- Patient is admitted to new hospital and history is fetched from community repository
- Patient is admitted to new hospital and history is fetched from community repository, but from wrong patient
- Patient is admitted to new hospital and history is fetched from community repository, patient reports additional medication to admitting physician
- Patient is admitted to new hospital and history is fetched from community repository, patient reports verbal dose changes to admitting physician
- Patient is admitted to a country but his medication history is available in another country
- Patient is admitted to hospital for surgery. Search reveals that there is no current medication, but many years ago, patient took antidepressives that may still affect anesthesia. Complete history for the last X months (for vertain type of medication) is fetched from community repository in another country
- Patient has a new treatment. In one of the therapies, there is a mismatch between the expected treatment start time and the real dispense time.
- Patient has a continued treatment. In one of the therapies, there is a mismatch between the expected treatment start time and the real dispense time.
- Patient is admitted to the hospital. Admitting physician builds the patient’s medication history from all sources and other consumers in the hospital reuse that information.
- Patient is admitted to the hospital with infection. Patient refers previous antibiotic treatment followed correctly, and prescription and dispense data are according to patient’s statement. Antibiogram indicates treatment was not effective, and patient admits that 2 doses were skipped and taken after time.
- Phychiatric patient reports adherence. Physician suspects the opposite.
- Patient is admitted with complications, physician suspects the use of oral contraceptive but patient denies it for cultural reasons.
AND...
A system for keeping track of medication data would eventually be used in these cases:
(use cases --> refer to processing of the data, and what kind of dynamic behaviour can be expected)
- The health authorities decide to investigate the long-term effects of a counterfeit medication. Using unique medication item identification (see ePedigree), the patients that took the counterfeit medication are identified, and this is checked with the condition that was being treated with the medication. The patients are identified and called for a consultation.
- To eradicate H. Pylori, the physician wants to determine the ideal therapy. The physician consults the patient's previous treatments, which shows that a previous protocol was followed by the patient at home. The physician wants to investigate whether the treatment was properly followed, including administration times, to investigate whether there can be some resistance to the previous antibiotics.
I'll later post the features that are required by these use cases.
Real use cases also to follow.
(scenarios --> refer to available data, and what kind of static initial conditions can exist)
- Patient’s medication is inside the same system and follows the basic scenario workflows – prescribed, and validated, dispensed and administered exactly as prescribed. CMPD.
- (Chronic) patient is inside the hospital and all his medication activity is recorded inside the same system and follows the basic scenario workflows – prescribed, and validated, dispensed and administered exactly as prescribed
- (Chronic) patient is inside the hospital and all his medication is inside the same system and follows the basic scenario workflows. In addition, patien has a contrasted exam and a surgery in the hospital.
- (Chronic) patient is inside the hospital and all his medication is inside the same system and follows the basic scenario workflows, but medicaton is replaced in the Pharmacy by an equivalent
- Patient is admitted to new hospital and reports known history to admitting physician
- Patient is admitted to new hospital and history is fetched from community repository
- Patient is admitted to new hospital and history is fetched from community repository, but from wrong patient
- Patient is admitted to new hospital and history is fetched from community repository, patient reports additional medication to admitting physician
- Patient is admitted to new hospital and history is fetched from community repository, patient reports verbal dose changes to admitting physician
- Patient is admitted to a country but his medication history is available in another country
- Patient is admitted to hospital for surgery. Search reveals that there is no current medication, but many years ago, patient took antidepressives that may still affect anesthesia. Complete history for the last X months (for vertain type of medication) is fetched from community repository in another country
- Patient has a new treatment. In one of the therapies, there is a mismatch between the expected treatment start time and the real dispense time.
- Patient has a continued treatment. In one of the therapies, there is a mismatch between the expected treatment start time and the real dispense time.
- Patient is admitted to the hospital. Admitting physician builds the patient’s medication history from all sources and other consumers in the hospital reuse that information.
- Patient is admitted to the hospital with infection. Patient refers previous antibiotic treatment followed correctly, and prescription and dispense data are according to patient’s statement. Antibiogram indicates treatment was not effective, and patient admits that 2 doses were skipped and taken after time.
- Phychiatric patient reports adherence. Physician suspects the opposite.
- Patient is admitted with complications, physician suspects the use of oral contraceptive but patient denies it for cultural reasons.
AND...
A system for keeping track of medication data would eventually be used in these cases:
(use cases --> refer to processing of the data, and what kind of dynamic behaviour can be expected)
- The health authorities decide to investigate the long-term effects of a counterfeit medication. Using unique medication item identification (see ePedigree), the patients that took the counterfeit medication are identified, and this is checked with the condition that was being treated with the medication. The patients are identified and called for a consultation.
- To eradicate H. Pylori, the physician wants to determine the ideal therapy. The physician consults the patient's previous treatments, which shows that a previous protocol was followed by the patient at home. The physician wants to investigate whether the treatment was properly followed, including administration times, to investigate whether there can be some resistance to the previous antibiotics.
I'll later post the features that are required by these use cases.
Real use cases also to follow.
Thursday, 20 October 2011
Some existing boundaries in Healthcare management
Some boundaries still to be addressed in Healthcare - an outsider's perspective:
- The gap between "clinical products" and "physical/logistic items".
When a physician wants clinical information for prescribing, he has the clinical attributes of a product (or product type). But for the pharmacist, this item has also logistic features, like location, price, packaging... And they are referring to the same thing.
- The difference between a catalog item (e.g. Renault 5 TL) and an instance of that (my first car, license plate FZ-09-62)
This very simple difference (or the lack of awareness) is breaking implementations of barcodes, RFIDs,
-The separation between Clinical domains and Healthcare Management.
After seeing struggles between clinicians and business managers, the gaps between these 2 domains are obvious. The conflicting interests are usually taken (wrongly) as reasons for discussing who's better. To me, the most obvious is that multi-criteria decision making is common, and healthcare management (minimizing costs, maximizing benefit to patient and society) is a clear example where bridges are needed.
- The gap between "clinical products" and "physical/logistic items".
When a physician wants clinical information for prescribing, he has the clinical attributes of a product (or product type). But for the pharmacist, this item has also logistic features, like location, price, packaging... And they are referring to the same thing.
- The difference between a catalog item (e.g. Renault 5 TL) and an instance of that (my first car, license plate FZ-09-62)
This very simple difference (or the lack of awareness) is breaking implementations of barcodes, RFIDs,
-The separation between Clinical domains and Healthcare Management.
After seeing struggles between clinicians and business managers, the gaps between these 2 domains are obvious. The conflicting interests are usually taken (wrongly) as reasons for discussing who's better. To me, the most obvious is that multi-criteria decision making is common, and healthcare management (minimizing costs, maximizing benefit to patient and society) is a clear example where bridges are needed.
Sunday, 16 October 2011
On Stock management in Pharmacy
Daily examples to describe some problems around the resupply of items in a Pharmacy:
The most usual approach to organized supply of items seems to be
Minimum Level Reordering
In this case, (which introduces the concept of reorder point), the reorder quantity can be fixed, but the frequency of refills depends on the consumption.
This is like we go shopping (for a predetermined number on units) immediately when we see we are short on some item.
In other cases, there may be a continuous (e.g. weekly) supply. In this case the frequency is fixed, but the refill amount depends on the quantity needed . This is when we go monthly or weekly to a big store - the amount we buy is usually variable.
Personally, like everyone, I think, I do not buy when the stock is below a given level. I note it in my list, and I consider the time between purchases and other factors to determine the quantity to buy.
More interesting for healthcare (but trivial to any person): when I go shopping, I take into account not only the current stock, and the usual stock, but also any additional factors that may influence e.g. the desired stock level - taking into account that I have one more person with me will increase the amount of food that I must buy.
This introduces the notions in Operations Research, where much advanced knowledge exists, and should be applicable to healthcare.
Healthcare logistics are still one step behind "normal" logistics, and the exploration of use cases should permit some innovation in healthcare.
The most usual approach to organized supply of items seems to be
Minimum Level Reordering
In this case, (which introduces the concept of reorder point), the reorder quantity can be fixed, but the frequency of refills depends on the consumption.
This is like we go shopping (for a predetermined number on units) immediately when we see we are short on some item.
In other cases, there may be a continuous (e.g. weekly) supply. In this case the frequency is fixed, but the refill amount depends on the quantity needed . This is when we go monthly or weekly to a big store - the amount we buy is usually variable.
Personally, like everyone, I think, I do not buy when the stock is below a given level. I note it in my list, and I consider the time between purchases and other factors to determine the quantity to buy.
More interesting for healthcare (but trivial to any person): when I go shopping, I take into account not only the current stock, and the usual stock, but also any additional factors that may influence e.g. the desired stock level - taking into account that I have one more person with me will increase the amount of food that I must buy.
This introduces the notions in Operations Research, where much advanced knowledge exists, and should be applicable to healthcare.
Healthcare logistics are still one step behind "normal" logistics, and the exploration of use cases should permit some innovation in healthcare.
Tuesday, 11 October 2011
User Interface guidance
Good design guidance from Microsoft about healthcare systems.
Nice move, addressing medication first.
Tuesday, 27 September 2011
Supply of Medical Devices
A nice video on supply of medical devices.
Optimizing the Supply Chain of Medical Devices: A Shared SaaS Platform for Suppliers and Providers
This reminded me of my field visits, where the sales Rep keeps a trunk stock, and a paper report or an application acts as a stock manager.
Some interesting concepts:
- Physician Preference Items (100 to 20000 US$ each, ca 40% of total hospital supply expenses)
- Consignment items
- Write-offs (I no longer find write-offs an issue, only the fact that they are not controlled/observed)
- Reverse logistics ARE important (Recalls, expired items)
Some concepts I keep present:
- 3 most important things seem to be traceability, traceability and traceability. Easy traceability, as in "show me your RFID/Barcode, I will know where you are". Ubiquitous traceability, as in "tell me often where you are".
- A rigid system would not work. Any system should not be limiting the marketing and distribution models
- Integration with other processes (charging, clinical) is a common requirement. For example tracking an item that has been implanted...
When it comes to inventory...
All you know is that you're wrong. But how wrong?
Optimizing the Supply Chain of Medical Devices: A Shared SaaS Platform for Suppliers and Providers
This reminded me of my field visits, where the sales Rep keeps a trunk stock, and a paper report or an application acts as a stock manager.
Some interesting concepts:
- Physician Preference Items (100 to 20000 US$ each, ca 40% of total hospital supply expenses)
- Consignment items
- Write-offs (I no longer find write-offs an issue, only the fact that they are not controlled/observed)
- Reverse logistics ARE important (Recalls, expired items)
Some concepts I keep present:
- 3 most important things seem to be traceability, traceability and traceability. Easy traceability, as in "show me your RFID/Barcode, I will know where you are". Ubiquitous traceability, as in "tell me often where you are".
- A rigid system would not work. Any system should not be limiting the marketing and distribution models
- Integration with other processes (charging, clinical) is a common requirement. For example tracking an item that has been implanted...
When it comes to inventory...
All you know is that you're wrong. But how wrong?
Monday, 12 September 2011
Going Agile
The team decided to implement Scrum.
Based on lessons learned with the best, we have a team that is willing to deliver working software and get frequent feedback.
The formula comes down to 3 things:
- Engage
- Always be ready to deliver frequently
- Evaluate your delivery frequently, and how to make a better delivery next time.
The product is an innovative one, so much benefit should come from this new approach.
Based on lessons learned with the best, we have a team that is willing to deliver working software and get frequent feedback.
The formula comes down to 3 things:
- Engage
- Always be ready to deliver frequently
- Evaluate your delivery frequently, and how to make a better delivery next time.
The product is an innovative one, so much benefit should come from this new approach.
Sunday, 11 September 2011
New Zealand Pharmacy Community Pharmacy process and messages
Something from the other side: A business process description and a set of messaging standards.
HL7 v2 in community.
http://www.ithealthboard.health.nz/sites/all/files/10030.1%2BEPharmaceutical%2BBusiness%2BProcess%2BStandard%2Bv1.pdf
http://www.ithealthboard.health.nz/sites/all/files/10030.2%2BEPharmaceutical%2BMessaging%2BStandard%2Bv1.pdf
HL7 v2 in community.
http://www.ithealthboard.health.nz/sites/all/files/10030.1%2BEPharmaceutical%2BBusiness%2BProcess%2BStandard%2Bv1.pdf
http://www.ithealthboard.health.nz/sites/all/files/10030.2%2BEPharmaceutical%2BMessaging%2BStandard%2Bv1.pdf
Saturday, 10 September 2011
Subscribe to:
Posts (Atom)