How timely should the information from EMR integrated with centralized EHR?
There are different types of data that can be integrated between EMR and EHR, such as
1) Patient admission
2) Lab Order/Result
3) Medication prescription/dispense
4) Discharge summary, etc
Should the above information instantaneously integrated with EHR whenever the it is available in EMR? or should it be integrated with EHR only when the patient is discharged or at the end of patient visit with exchanging of complete summarized information such as CCD?
If the patient is still in one healthcare institution, why is the need to push the data from EMR to EHR? More timely the data is pushed to EHR, there will be possibly more update and correction such as lab result correction. Sometimes due to manual process involved, some of the local update at EMR may not be propagated all the way to EHR.
If cross-institution diagnosis is required at this stage during in-patient stay, then wouldn't it be more accurate and complete to access the EMR data instead of the subset data held within EHR.
What's your views?
Showing posts with label EA. Show all posts
Showing posts with label EA. Show all posts
Sunday, May 27, 2012
Monday, December 12, 2011
Building Foundation going beyond EHR
Last Month I attended 3rd Annual Electronic Health Records (EHR) Asia 2011, during pre-conference workshop, I shared my experience in building adaptive enterprise foundation that goes beyond the current EHR capabilities. Below I summarized the key challenges we faced and the approaches of tackling these issues so that EHR scales up progressively to meet ongoing business needs.
1. Plan and design enterprise architecture with business capability centric view to support end-to-end care giving.
The boundary between EMR and summary care record EHR becomes increasingly fuzzy. Traditionally we plan IT systems from care setting perspective, however due to the fact that healthcare delivery is undergoing transformation to support patient centric care giving from primary care, inpatient acute care and the step-down care, there is increasing need for more efficient information flow to support seamless integration of care giving and transfer.
Just like Service Oriented Architecture design, enterprise architecture planning needs to be driven with "SOA style" - Business capability as Service, care setting is the context of the service, care provider/giver and patient are the consumer of the service.
2. Articulate the business benefits and value proposition from the perspective of the entire healthcare ecosystem.
The benefits of EHR is not equally shared by different stakeholders within the healthcare ecosystem, also the time of realizing these business benefits by different stakeholders are not synchronized. For example, in order to provide quality clinical analytic, we need to improve data quality at the point of data entry, however this will incur additional cost of system upgrading and might still increase the workload of data entry giving the current technology limitations and constraints. The additional workload during data entry might lead to time saving at another step of entire care giving process, also improved data quality and thus patient safety as whole.
However those benefits might not be realized immediately, thus at early planning stage, we need to highlight business value with the view from the entire care delivery perspective instead of individual setting perspective, also lays a foundation to allow different stakeholders to realize business benefits as early as possibly to drive up the adoption and at the same time progressively move up the IT capability ladder to enjoy more business benefits.
3. Role of different healthcare interoperability standards/specification
One of the question asked during the workshop is "What standard shall I use? e.g HL7v2, HL7v3, ISO13606, IHE" .
The common mistake in the current healthcare interoperability space is the notion of "all or nothing". To decide what interoperability standards to use, firstly we need to be clear that the above mentioned standards or specifications play different roles in healthcare interoperability, they are not equal, neither exclusive, they are complementary to each other to play its intended role in the entire software development life cycle.
Secondly we should define an architecture framework esp SOA reference architecture to position each respective standard/specification's role in the reference architecture to guide the overall solution design and implementation.
More detail can be found at EHR conference 2011.
1. Plan and design enterprise architecture with business capability centric view to support end-to-end care giving.
The boundary between EMR and summary care record EHR becomes increasingly fuzzy. Traditionally we plan IT systems from care setting perspective, however due to the fact that healthcare delivery is undergoing transformation to support patient centric care giving from primary care, inpatient acute care and the step-down care, there is increasing need for more efficient information flow to support seamless integration of care giving and transfer.
Just like Service Oriented Architecture design, enterprise architecture planning needs to be driven with "SOA style" - Business capability as Service, care setting is the context of the service, care provider/giver and patient are the consumer of the service.
2. Articulate the business benefits and value proposition from the perspective of the entire healthcare ecosystem.
The benefits of EHR is not equally shared by different stakeholders within the healthcare ecosystem, also the time of realizing these business benefits by different stakeholders are not synchronized. For example, in order to provide quality clinical analytic, we need to improve data quality at the point of data entry, however this will incur additional cost of system upgrading and might still increase the workload of data entry giving the current technology limitations and constraints. The additional workload during data entry might lead to time saving at another step of entire care giving process, also improved data quality and thus patient safety as whole.
However those benefits might not be realized immediately, thus at early planning stage, we need to highlight business value with the view from the entire care delivery perspective instead of individual setting perspective, also lays a foundation to allow different stakeholders to realize business benefits as early as possibly to drive up the adoption and at the same time progressively move up the IT capability ladder to enjoy more business benefits.
3. Role of different healthcare interoperability standards/specification
One of the question asked during the workshop is "What standard shall I use? e.g HL7v2, HL7v3, ISO13606, IHE" .
The common mistake in the current healthcare interoperability space is the notion of "all or nothing". To decide what interoperability standards to use, firstly we need to be clear that the above mentioned standards or specifications play different roles in healthcare interoperability, they are not equal, neither exclusive, they are complementary to each other to play its intended role in the entire software development life cycle.
Secondly we should define an architecture framework esp SOA reference architecture to position each respective standard/specification's role in the reference architecture to guide the overall solution design and implementation.
More detail can be found at EHR conference 2011.
Thursday, September 15, 2011
How to effectively manage changes in architecture
Yesterday I had very interesting conversation with one Gartner Enterprise Architect, one thing he pointed out that one of the most important aspects of EA is to manage and document changes instead of documenting goal state blueprint, things are constantly changing, technology is also evolving, blueprint will only be in the game of catching it up with reality.
Reflecting on what he said, in fact it is also completely true in application architecture design and even at most lowest level class object modeling. One of the OO principle - Open-closed principle, is essentially guiding OO design to manage the OO dependency thereby change can be introduced in a more efficient manner - more consistent, quicker, easier and no side effect to the existing code base.
This also applies to information modeling. if the information designer takes the mindset of developing blueprint information model, in reality it will end up trying to catching up with real needs, and becomes irrelevant in the end. Two real practical difficulties make the goal state blueprint information model unrealistic, 1) It is hard to know all the possible use cases and scenarios upfront. 2) Business need is always evolving, new use case or scenario will arise. For more detail, you can refer to my earlier post about the fallacy of superset information model.
Having said the above, then shall we do not do any thing, just wait for things to happen and then passively react to it? No, we still need to create some level of goal state artifact, but bear in the mind things will change, and thus refine the architecture to manage the changes proactively and efficiently with the following steps
1) Think about the potential possibly changes that might be introduced in the future
2) Treat these changes as external stimulus, analyze the impact to the existing architecture
3) Within the architecture, different components will react to the changes with different level of sensitivity, some could be very fragile and subject to every minor changes, some might be relatively stable.
4) Based on the level of sensitivity, re-structure the design, group the components based on its sensitivity to external stimulus, and organize the component relationship and dependency so that the dependency is managed consistently
5) During re-structuring the component design, you may find some components react to changes inconsistently, fragile in one scenario, but rather stable in another scenario. If we encounter this situation, we may need to think about whether the component has too many responsibilities, so what we need to do is to separate the concerns.
6) During the refactoring the design, you may find that there are just too many permutations that the architecture can manage the future changes efficiently. That's when we should remember that architecture is things hard to change, you can further read Martin Folwer's article - Who Needs an Architect?
Hope the above useful.
Reflecting on what he said, in fact it is also completely true in application architecture design and even at most lowest level class object modeling. One of the OO principle - Open-closed principle, is essentially guiding OO design to manage the OO dependency thereby change can be introduced in a more efficient manner - more consistent, quicker, easier and no side effect to the existing code base.
This also applies to information modeling. if the information designer takes the mindset of developing blueprint information model, in reality it will end up trying to catching up with real needs, and becomes irrelevant in the end. Two real practical difficulties make the goal state blueprint information model unrealistic, 1) It is hard to know all the possible use cases and scenarios upfront. 2) Business need is always evolving, new use case or scenario will arise. For more detail, you can refer to my earlier post about the fallacy of superset information model.
Having said the above, then shall we do not do any thing, just wait for things to happen and then passively react to it? No, we still need to create some level of goal state artifact, but bear in the mind things will change, and thus refine the architecture to manage the changes proactively and efficiently with the following steps
1) Think about the potential possibly changes that might be introduced in the future
2) Treat these changes as external stimulus, analyze the impact to the existing architecture
3) Within the architecture, different components will react to the changes with different level of sensitivity, some could be very fragile and subject to every minor changes, some might be relatively stable.
4) Based on the level of sensitivity, re-structure the design, group the components based on its sensitivity to external stimulus, and organize the component relationship and dependency so that the dependency is managed consistently
5) During re-structuring the component design, you may find some components react to changes inconsistently, fragile in one scenario, but rather stable in another scenario. If we encounter this situation, we may need to think about whether the component has too many responsibilities, so what we need to do is to separate the concerns.
6) During the refactoring the design, you may find that there are just too many permutations that the architecture can manage the future changes efficiently. That's when we should remember that architecture is things hard to change, you can further read Martin Folwer's article - Who Needs an Architect?
Hope the above useful.
Subscribe to:
Posts (Atom)