Historically they and have done what all hospitals do, that is, they have purchased “commercial off the shelf systems” (also known as COTS) to run their business, manage patient care, and even market their services on-line. This approach largely met their needs for years, but now after a series of acquisitions, recent and looming changes to their reimbursement model, and myriad technology challenges that result from the shift from “hospital” to “Health System” they are now at a crossroads.  These systems may have performed fairly well independently, but they were never designed or intended to function as one. Meanwhile, the vendors who originally supplied the systems have run out of answers, and Nirvana is suffering the consequences.

Nirvana has successfully standardized on Epic, one of the tier one vendors, as the primary electronic medical records (EMR) vendor at the main hospital, but what they desire is a single view across the entire patient experience. Patients in Nirvana receive services without consideration for Nirvana Health’s desire for a comprehensive patient record. Most will likely receive some health services beyond the reach of EPIC, often simply by receiving care at a nearby doctor’s office which is a different medical records platform.

So why doesn’t Nirvana just demand that EPIC integrate with other EMR systems? No doubt Nirvana and countless others have. But for EPIC to do so would in essence counter act their own commercial interest. To do so effectively makes the patient record portable, and by extension the EMR system as well. Machiavellian principles of self-interest have proven themselves in healthcare information technology (HIT). The only way out for today’s Health Care Systems is to for them to wean themselves from reliance on any one software vendor for any critically required systems.

One way we recommend that Nirvana and others who face similar challenges introduce effective portability and reduce vendor lock-in is through adoption of standards across an array of disciplines, one specific recommendation would likely be for them to adopt a Service Oriented Architecture (SOA).  Still, SOA is largely a foreign concept to them, not to mention the notion of web services (WS) and enterprise services buses (ESB). It is important to note that SOA is not a product, but a philosophy. As described in OASIS SOA Reference Model’s definition, SOA is a model for “organizing and utilizing distributed capabilities”, and especially “capabilities that may be under the control of different ownership domains”. Nirvana will likely never fully control all the patient access points, certainly not soon enough to reach their stated timelines, and the SOA approach places a layer between the applications they rely on and the user experience they desire.

Success with a SOA initiative will require strong support by executive leaders at Nirvana, but will put in place the foundation upon which Nirvana and others like them will be able to address the requirements of today and the unforeseen challenges of tomorrow.  When Nirvana and others like them realize the cure they seek does not come from a pill they can buy, but rather from a new approach that removes their reliance on any vendor, they will prevail.

The situation, the project was with one of the leading product safety regulators in the world.  The international arm of the organization was leading an initiative to create a global information pool for product safety recall information in an effort to make product safety efforts across the world more coordinated and effective.  This would be a one stop, one shop view to “any recall – any where – any time” product safety recall information.

Armedia was asked to perform an initial assessment of what it would take a build a global recall information pool, build a roadmap for the process and structure the approach for the global consortium.  This was a pure play Information Technology (IT) strategy project where the focus was on creating an IT approach to meet a complex business situation.

What I loved about the project was the challenge of a highly unstructured business situation where the project sponsors understood the pain and knew the desirable outcome, but they had little understanding of what needed to be done.

Building an approach for an IT system in the area of product safety was a challenge, as I soon discovered.   Several factors contributed to the challenge, they included,  (a) plethora of legacy IT deployments, (b) changing data structures and data definitions over time, (c) different data structures and definitions across countries, and (d) project execution headwinds (Note: Our team ran into a situation of competing for attention amongst different priorities both within the organization and with 3^rd parties outside, in this case the consortium of product safety organizations from other countries).

Sound familiar?

So we walk into the situation not knowing all the pieces of the puzzle and the Armedia team immediately began an assessment of the situation.  Quickly the team structured the analysis into the following topical areas:

1. Strategic
2. Governance and Oversight
3. Functional Scope Definition
4. Usability, Data Search, and Discovery
5. Architecture
6. Deployment and Execution
7. Operations

Next came a deep dive into each area to develop specific recommendations and a roadmap at a granular level. Data categorizations, normalization and data definitions were all important areas of focus given the complexity of handling these items across different jurisdictions. I believe that our team’s recommendations around this area were excellent and well received by the international community, especially because our approach required minimal impact to current product safety operations, which was a key requirement by the sponsors.

We brought value in terms of providing structure and simplification for execution to what seemed at the outset to be a complex problem.  The Armedia report on “Considerations for Pursuing Global IT Interoperability for Publicly Available Product Recalls ” was published by the OECD (Organization of Economic Development) and has been accepted as the strategic guidance document by the international product safety working party set-up for the purpose of creating the global recall pool. The execution work on report recommendations has started and is currently underway.

This complex business issue was in need of a technology execution plan that was intentionally kept simple, and yet met the unique requirements of the customer. My team and myself guided our efforts in order to meet these criteria, and in the end the Armedia team successfully developed recommendations that provided both strategic and efficient solutions to this international IT challenge.

So for those of you who may not have heard: The Andy Fastow Story is a far-fetched, weird and wonderful fantasy about a man who single-handedly (well almost…with a little help from a few close golfing buddies: Jeff, Ken, Michael, Rick, Ben and David, amongst others) brings down a giant company, nay, a whole industry, tailspins an entire country into recession, causes the loss of tens of thousands of job and billions of dollars of people’s savings, illegally bags tens of millions of dollars for himself and his best buddy Michael, etc… In this little tale, our hero Andy is magically transformed from an Ordinary Joe to Financial Genius with the help of his friend, and self-anointed god, Jeff. Andy then gets to make up “Andy’s World”, where everything is always wonderful for him and all bad things in the real world are shoved into a box called LJM and then a bigger box called LJM2 (and a couple of broken down pales called Chewco and Raptor). In Andy’s World, Andy and Michael get to make up all the rules. Everybody is invited to play in Andy’s World—at a fee. Everybody will win a participation prize. Everybody will lose a whole helluva lot. Errr, except for Andy and Michael of course—they always win. Until one day, when a nosy stranger starts asking questions like “Andy, how do you do it? …like, can you teach me how to stick really bad things into an ordinary box just like yours and have them just disappear and make me loads of money just like you?” Well, one thing leads to another and this nasty thing called the SEC starts poking and prodding Andy’s World, bugging Andy and asking him the same kinds of stuff; except this SEC thing is scary and has some gnarly militia working for it. The nerve of the SEC questioning whether Andy is on the up and up! Of course, just like all good fantasies, after a bout of the uglies (a little public humiliation and a few years outside the comfort of Andy’s World—chilling in an institution near Colorado), our hero rises at the end and gets to fight another day (presumably with some of those millions he bagged earlier). Unfortunately his friends, well except Michael again, didn’t do so well: poor Ken died, Ben and Rick went to jail, David became known as the world’s most infamous shredder, and Jeff was vilified around the world and got blamed for everything bad in Andy’s World. Oh, and, like millions of people’s lives’ got permanently messed up.

Pretty good story, eh?! I’ve even heard some rumors that it’s loosely based on real life…

Of course the moral of the Andy Fastow Story is that we don’t want another Andy Fastow story. Actually, no more stories at all of that genre. Sadly, it seems to be a trite plot prone to repeat. Who can forget the Bernie Ebbers or the Dennis Kozlowski Story? Or the Lehman and AIG Show? Don’t even start with Maddof! So many copycats, it’s hard to keep track.

The answer to stop these stories, one presumes, is to put in place some controls. Tools that support the controls. And, a scary, ugly and expensive editing process affectionately called the threat of eDiscovery. Oh, and a whole bunch of government type people, lawyers, accountants, bankers and consultants. Now, surely there will never be another Andy Fastow Story. There will never be another Arthur Andersen willing to edit another Andy Fastow Story. In fact, we won’t even need to have any more authors or heroes for these kinds of stories. Our tools will auto-document happy stories where everyone wins and everyone is treated fairly. So, that’s where ECM comes in!

Unfortunately, it seems, again, that reality is just not complying with our carefully thought out plot. Dang! In spite of noise to the contrary, and HUGE vendor propaganda promoting the discovery of gold reincarnated in the all signing, all dancing eDiscovery products tied to ECM solutions, it seems there is a “fiction gap” between is and would-like to be. In fact, records management en-masse (which one would presume to be a precursor to eDiscovery products) is seemingly not much more than email archival these days. All this seems to point to the obvious. What’s the subtext here?

Perhaps the subtext is in the incentives and disincentives. eDiscovery, empirically, seems to be a dance. The goal really is not full discovery or going to court—that would be insanely expensive for most organizations—but a happy settlement, which would be less insanely expensive. Of course to get to the settlement, you still need some level of eDiscovery…to know what is insane and what is less insane! Now, what if eDiscovery were easier? ECM, records management, search and eDiscovery tools all working in unison. A nirvana to be sure. But, would that not potentially lead to greater exposure of being discovered? Would the disincentive of the lengthy, costly and archaic discovery process now be replaced with the incentive of protecting yourself through the same lengthy, costly and archaic discovery process?! Certainly the US government (through the FRCP; Federal Rules of Civil Procedure) doesn’t hope so. In fact, since the December 1, 2006 amendments to the FRCP, effectively dealing with eDiscovery is very much supposed to be on the legal and corporate roadmap of most organizations; moreover they have the burden of responsibility for adequately managing discoverable information at their own cost.

So, where does that leave us? In the spirit of Mr. Fastow and company, I suspect somewhere between pay now or pay later…which is to say, little evidence of much competence at this time. In my opinion, effective and somewhat efficient eDiscovery is directly tied to successful deployment of ECM—properly indexing, managing, storing, retrieving and archiving information, and a streamlined implementation of Records Management—identifying, classifying, retaining and disposing of formal records based on corporate and regulatory compliance policies. I’m sure the eDiscovery vendors would not entirely, or possibly at all, agree with some of these assertions. But then again they may have incentives not to…

“What is a record?”     It is the fundamental question in records management. Without a clear answer to that question, one cannot determine record titles, develop and apply retention schedules, structure file plans or manage an “item” with software. The answer also makes the difference between establishing an “item” as a record, as opposed to being just a Word document, an email, a piece of paper in a file, or a map of a city.

The answer to the question begins with a definition. The primary definition for a “record” is stated in the ISO 15489: 2001 standard. It defines a record as

“…information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business.”

For the US federal government, the U.S. National Archives and Records Administration (NARA) is required by the Federal Records Act to use a slightly different and more explicit definition:

““records” include[s] all books, papers, maps, photographs, machine readable materials, or other documentary materials, regardless of physical form or characteristics, made or received by an agency of the United States Government under Federal law or in connection with the transaction of public business and preserved or appropriate for preservation by that agency or its legitimate successor as evidence of the organization, functions, policies, decisions, procedures, operations, or other activities of the Government or because of the informational value of data in them.”

Although this definition is slightly different than that in the ISO standard, NARA has incorporated the ISO definition into its regulatory guidance for federal agencies.

The result of these definitions is the segregation of items into “records” and “non-records” If an item does not meet the definition, it is not considered a record and, therefore, does not require any protection or preservation efforts – it may be disposed of when it usefulness for its owner ends.

If an item does meet the definition, it must also meet certain criteria to be considered a record. The criteria are designed to establish the trustworthiness of the potential record and are inherent to the definition. They are: authenticity, reliability, integrity, and usability. These criteria are defined as:

1. Authenticity: the record is a “true” item – an accurate representation of a transaction or activity, as purported by its creator at the time of creation

2. Reliability: the record can be relied upon to be a trusted source of the information it contains

3. Integrity: the record has not been and cannot be altered. It is complete in form and data

4. Usability: the record can be repeatedly retrieved throughout its lifecycle and used as an authoritative source of the information contained with in it.

If an item meets the definition, but fails to satisfy any one or more of the criterion of trustworthiness, the value of the item is suspect and cannot be considered a record. Thereafter, it is considered a non-record and can be disposed of at any time. Conversely, an item that meets all of the criteria of trustworthiness but does not meet the definition of a record, that item, too, is not a record. An example of this is a lunch menu for a nearby restaurant that is found in an employee’s desk. Although the menu may be a trustworthy representation of the restaurant’s bill of fare, if that restaurant is not connected to the employee’s organization, the menu is a non-record. (However, it could be a record for the restaurant.)

Often confusion arises in the application of the definition and criteria to an item when determining its records/non-record status. One major causes of this confusion surrounds the item’s media type. Another source of confusion is a failure to appreciate and evaluate the content and context of an item. Media type confusion arises from outdated perceptions of what a record have been. Until recently, many considered paper to be the only items that were records. The perception may have extended even to items preserved on microfilm or microfiche, but not much beyond that. The entire realm of electronic items was ignored. However, as ISO 15489 and the Federal Records Act make clear, any item, physical or electronic, can become a record if it is evidence of an entity’s business’ conduct and transactions. Therefore, potential record items include such things as paper documents, native electronic documents, scanned images of paper documents, structured data in a database, a chart, a photograph, a recording of voicemail, an instant message, a Twitter post, an email, or even, in the case of law enforcement, a gun, a knife, or DNA material. So long as the item meets the definition and satisfies the trustworthiness criteria, it becomes a record.

The confusion involving content and context is similar to that surrounding media type, as it concerns misinterpretations of how the definition and criteria are applied. One common misunderstanding is the assumption that all emails are records and should be preserved and protected as such. However, email itself is a media type, no different from a note, a letter, or a baseball bat. The factors that elevate an e-mail to record status are the content and the context of the email. At one end of the spectrum, an email between co-workers about where to have lunch, in most instances, would not be a record. At the other end, an email from a supervisor directing one of his/his employees to undertake certain job-related tasks clearly could be a record (assuming it also trustworthy). However, when context is applied with the content, it can change the status of the item. In the example of the email regarding lunch among co-workers, if business were conducted at the lunch, the email could become a record. If the is used by the organization to prove the time and date of the lunch for the Internal Revenue Service or other governmental entity, the email could become a record. Therefore, it is not the item itself that must be compared to the definition and criteria, but rather the content and context of the item in activity or transaction.

Any sound records management program is founded on the correct definition and trustworthiness criteria of a record. If the definition is absent, or is faulty, an organization’s entire records program can cause incorrect items to be treated as records. Every organization must, therefore, ensure that its record definition and the use of that definition are clear and unambiguous.

For more detail on this subject, please visit Armedia’s Resources page
and request the whitepaper entitled “Issues in Record Definition and Declaration.”

The case management system may not and probably should not be the evidence management system; however it should integrate with the evidence management system.  At a minimum, the case agent(s) need to understand the chain of custody of evidence associated with their case.  It would be better if it provided richer features like allowing the case agent to request evidence for charge out, reporting on state of evidence within case, electronic representation of evidence (i.e. picture) or etc.  The evidence administrator ensures that the evidence can be found when it is needed for whatever reason. 

The case management system should provide records management services. If deigned correctly, this will be transparent to the case agent.  As you clearly stated in “The People of Case Management”, the system has to make it easy for officers to document their investigation.  The records management system will ensure that the case adheres to the organization’s retention and disposition policies.  The records administrator maintains the file plan with its associated policies and enforces them during the lifecycle of the case. 

The evidence and records administrator supports the case agent by ensuring that physical and electronic material is tracked and available during the lifecycle of the case.

As my colleague has clearly stated in his blog, My name is NIEM, NIEM is not a silver bullet.  There are many issues to resolve:

1. Security of information once export from system.
2. Sharing of information between civilian and intelligence agencies – What if it contains data about US citizen?  How do we share with our international partners?
3. What if one system does not support all data elements and during the import data is lost?  Agency could be making decisions based on limited information.
4. When does the imported data become stale?  What if the case is active and new information contradicts the export data that has been shared?
5. Given the limited budgets of local and state law enforcements, how do they participate in collaborating to combat crime?
6. How do we combat data overload once data is being shared throughout the community?

These issues/concerns must and will be addressed because the alternative is not acceptable.  Our enemy wins when we allow distractions to take our eyes off accomplishing this goal of information sharing amongst the community.  As I review current and future procurements, I am glad to see the FBI, DHS and others make this a core element of their system.

NIEM which stands for the, inevitably, not so sexy sounding National Information Exchange Model is a formal information exchange schema developed by the US government (specifically DOJ and DHS) to further information sharing across Federal, and in time, State and Local government agencies and their business constituents. NIEM builds on from the much more bulky Global Justice XML Data Model (GJXDM) model; an off-shoot of post 9/11 information sharing initiatives. The idea of NIEM (currently in version 2.1) is to provide a consistent, non-redundant, open standards based XML schema that has some well defined entities and activities for improved inter-agency communication and information sharing.

All good…but what’s new, eh? Well, I think what is new is the fact that NIEM seems to be much more than just another academic exercise. Since its infancy in 2005, there have been multiple live and pilot projects (particularly around criminal investigation related content) at many Federal and State agencies, a set of open source tools have been developed and continue to grow, and the government (including Fed CIO, Vivek Kundra) seem more than ever to be pushing the standard and making it a part of the overall US government strategy for information sharing–see data.gov.

So, how does this apply to content management? Well, as with 21CFR11, 5015 2&4, SOX and most your other garden variety compliance oriented standards, there is an opportunity. An opportunity to become compliant (read: running afoul of the government is not a good thing if you want to work with them). And, an opportunity to be productive (read: information transparency and efficient content sharing can lead to some bottom line savings and possibly…and this is where you need to put your salesforce.com hat on…new revenue development channels).

As far as ECM goes, it seems to me that minimally NIEM would have an obvious play along the lines of Case Management (particularly for investigative records) and, in a larger context, Records Management. Empirically though it’s not there yet. Case Management is still quite immature as an offering. Though there are, of course, many solutions out there, most are heavily bespoke or still based on legacy structured data and structured data management systems. In a world of exploding DOC, PPT, PDF, MP3, FLV, et al content sources the days of pure structured content solutions are numbered. As for Records Management, despite hype to the contrary, it seems we are still very much focused on eDiscovery related records management–hail Email Archival!! I think there is change afoot though, with greater investment than ever–at least by the government–in Case Management, Records Management and information sharing initiatives.

NIEM, of course, is not nor will ever be a silver bullet. Ultimately, it’s a suggested structure for content storage and exchange. However, as with the neighbor’s grass, you could always bemoan the greener pastures…only to realize in time that with a little spade work your own grass aint half bad. NIEM can be that spade…

Careful consideration should be taken when creating an electronic retention policy design because trying to manage and control hundreds of retention policies that can have the tendency to change can become unmanageable very quickly.  The support and maintenance cost along with the compliance risk can eliminate your ROI and create a solution that fails to meet the goals for which it was designed.

One way to simplify and try to reduce the overhead associated with managing so many different policies is to group schedules together within your series according to their function or another applicable categorization scheme and their dispositions. 

The following basic strategy is an example of how this can be accomplished:

• Create “buckets” representing the high-level record series areas.
• Group record series members within the “bucket” into categories based on function and comparable disposition schedules.
• Define and assign a common disposition strategy to each functional area that is representative and compliant for all record series members.

This concept is probably better understood using a simple example, lets use the following scenario as an illustration:

• You have 5 different high-level record series groups.
• Each series group has 100 individual members.
• The schedule for each member ranges from temporary dispositions of 1 month to 10 years to permanent records with a duration of 25 years or more.
• Each of the record series contain members that share a common purpose or function.

Using this example some basic consolidation steps would be:

1. Define each high-level record series group as a separate “bucket”.
2. Within each bucket you can create categories based on function such as whether the members are administrative, case related, procedural, etc.
3. Within each of these sub-groups you would start to combine your applicable members based on corresponding disposition schedules.  For example, within a record series “bucket” if you have 25 members that are administrative records and they have temporary dispositions with durations ranging from 3 months to 5 years you can create a single retention policy with a disposition strategy of destroy/delete after 5 years and include each of these members under the policy.  By doing this you only need a single policy that can apply to 25 members instead of having 25 separate retention policies.
4. Follow a similar process for each high-level record series and you can turn, what was in the case of our example, 500 individual retention policies into a number that is much more manageable making it easier to control and disposition your formal records.

Some items to take into consideration when consolidating retention policies are:

• Work with your records managers and any outside agency, such as NARA, you archive records to before implementation, make sure you have their buy-in for the initiative.
• Identify the special record series members and handle them separately with their own policy as needed to help reduce compliance risk.
• When grouping record series members within a retention policy based on disposition schedules be wary of regulations that can be applied, it is generally best practice to only hold certain records for as long as necessary and no longer.
• Designing an automated process for declaring formal records which will reduce workload and provide a better user experience for your records contributors/managers.  If you have or choose to implement an automated formal records declaration process you can provide more flexibility and room for growth by using an XML file or table to map the individual record series members to their applicable location in the formal file plan where the retention policy has been applied.
• Consider structuring/restructuring your formal file plan after the consolidation strategy and apply your retention policies at the applicable level and allow the policy to be inherited by all formal records within that section of the file plan.

This information is an example of how retention policies can be simplified but in practice it is best to err on the side of caution.  Make sure you have the right people involved and do not put yourself at risk.  The goal is to reduce your overhead while minimizing risk and maintaining compliance.  You probably made a significant investment in your electronic records management solution and you need to be sure to keep the protection and savings that a solid design provides.

It’s simple.  The new Content I/O Suite.  Armedia’s Content I/O Suite allows users to collect information from all of those billions of sources, migrate it to the centralized repository in the company, and then, if needed, deliver that information to the different web portals that may need to view the information later.  In fact, it can even send the information to multiple repositories all from the same interface.  So what if Human Resources uses Documentum, and Accounting uses Laserfiche, and some departments have their own collaborative eRoom set up, but you just merged with another company who uses SharePoint and FileNet.  What if one user could capture the information coming in from the website, or through email, or through regular snail mail, and deliver it into the appropriate system, without that one user ever having to be trained in each of those systems?  Sounds too good to be true, doesn’t it?  Check it out at http://armedia.com/products/suite/.

-Kristin Evans

So why hasn’t there been more progress on this front?  Technology really has little to do with it, technology is actually the easier part of the total effort.  There are several answers and they can vary slightly but it really boils down to the same reasons so many enterprise content management initiatives fail - because there is a lack of analysis, requirements definition, and careful strategic planning up front.  Plus, once systems are deployed, there isn’t sufficient governance and it quickly becomes a support and maintenance headache so the benefits and your ROI disappear.  Something as complex as electronic health records can also be hampered by key stakeholders from different areas failing to agree on a core set of requirements and policies in order to move forward.  If there isn’t a commitment among these interested parties to work together towards a common set of goals and objectives producing a successful solution will be extremely difficult.  This has certainly happened in the past but hopefully with the current momentum this obstacle can be overcome.

One of the key things for organizations planning this type undertaking is to understand and accept that it is not a one time thing.  These aren’t single projects they are programs.  Many projects have failed because the scope becomes way too ambitious and requirements are never properly defined.  With something as complex as electronic health records getting to a refined, specific set of requirements that can be implemented is challenging at best.  Which is why these programs should be broken up into a series of smaller, more tangible projects with scope that can be properly defined and is obtainable during a reasonable period of time.  Taking on more, smaller projects allows you to set more realistic goals, minimize risk, and learn from each iteration so you deploy a more reliable system that meets expectations and yields positive results.  I can’t stress the importance of properly defining requirements down to a specific level, if the requirements are ambiguous and cannot be broken out into use cases you will not wind up with a sound design and the solution will more than likely fail to meet expectations.  I am going to leave this point here since I am starting to cross over into software development methodology and process areas and I have whole separate article planned for that subject.  It may take more than one if I really get on my soapbox!

There certainly have been some good examples, if you haven’t read about it check out the Delaware Health Information Network.  The DIHN (pronounced The Din) as it is lovingly called has been an ongoing program and has been pretty successful.  Will it be a model for other states and possibly more?  I can’t say for sure but having a new VP from the great state of Delaware certainly can’t hurt!

So what can be done to help ensure that an electronic health records system is successful?  For starters realize what I mentioned above, it isn’t a single project, it is a program made up of multiple projects driven towards a common goal.  Of course stakeholder support and resources are a given as with any program but having stakeholders involved that know the different parts of the industry (i.e. Physicians, research, clinical, etc.) and are committed to the common goals is vital.  As with any type of record, health records have compliance regulations that have to be met, the most notable of course is HIPAA.  This is a risky area for electronic health records systems, one that has stumped efforts in the past.  How do you ensure patient privacy when these records become digital, especially with so many potential access points?  This is a big reason key stakeholder input is critical and why there is a great need for governance of the solution once it is deployed.  Roles and permission levels can be established but it is the subject matter experts that need to define them in order to help ensure accuracy.

Once a system is deployed the Governance Committee should be the authoritative body that provides change management guidance and helps ensure the common goals of the solution are being met, including compliance.  As with any good program a road-map should be drawn so the team knows where they are and where they need to go.  The road-map should define key milestones for the program and basically layout the projects to be undertaken along with their high-level scope.  Earlier milestones will probably be more specific and it is OK if future milestones are more nebulous, this should be a living artifact that is revisited, and potentially revised, after each individual initiative at least.  The goal is to lay a solid foundation and build upon it with additional functionality while also factoring in changes in regulation and in the environment.

Although not as important as the aforementioned functional and human factors in ensuring success,  technology certainly has an important role to say the least.  Using content management platforms effectively with intelligent classification, metadata standards, and search applications to manage, relate, and access these records will be vital.  Usability is usually an after thought which is why new system adoption and sustainability can be difficult so it’s role in an initiative like this will be huge.  If the system is difficult to use and frustrating for the end user they simply won’t adopt.  You can build the best solution with all the functionality one could ever need but if nobody uses it the effort will still be an utter failure.  Using proven usability techniques and best practices will help facilitate positive results.  With any major industry shift towards technology, especially with as big as this movement is likely to be, the establishment of certain architectural standards will go a long way to help prevent data from being siloed and to make sure the information can be shared and can cross systems.  There has been success on this front as well that can be used as examples, the Global Justice XML Data Model is certainly one.  Another standard which is in a related area is Regulated Product Submission which is a standard that would allow regulated organizations such as those in the Medical Device, Pharmaceutical, and Veterinary Medicine industries for example to submit regulatory information to the applicable agencies using a single standard message format.

The potential benefits to electronic health records systems are there but what is debatable is whether or not it is realistic to think we can get there.  Eventhough there is strong support there are also those that feel that it is too grand a goal and that the benefit is simply not there.  I was just reading an editorial in the newspaper today where the authors basically said that the money for electronic health records technology would be better spent somewhere else, in fact these authors cited statistics that indicated that this type of technology may actually detrimental to health care.  Sorry, I just can’t buy that.  I just don’t believe we have been doing this long enough and effectively enough to gather accurate data on the subject.  Are there other areas of the health care industry that need funding, of course, this isn’t a silver bullet and to think so could possibly set unrealistic expectations and doom the effort before it ever really got going.

I for one believe that we should, can, and will get there.  Make no mistake, it will be a long complicated journey but one that is long overdue and it looks like it will have a great deal of Federal funding and support which will definitely help.  We really can’t afford not to take this step.  Many experts agree the current state of medical records contributes to rising health care costs.  Furthermore, there is a great deal of knowledge that is sitting there but isn’t being utilized simply because it can’t be found and linked together in context.  I mean, when you go into your Doctor’s office or into a lab to have a test performed do they pull up all your information digitally in a unified context?  No, I am sure they don’t, they walk back to those rolling file bins and pull your folder with hard copies of all your health records, once they find it that is, and only for what you have had done with that Doctor or by that clinic.  Now, think about it again, what if your Doctor is able to have all your records including x-rays, lab results, etc. from anywhere at her finger tips and can be referenced easily?  Or what if you move or are out of town and need to visit a Doctor or hospital and they can have all your records pulled up within seconds?   Once it starts to be put in perspective it becomes a very compelling argument.

What I think has the potential to be a tremendous benefit and improvement in overall health care but isn’t being talked about too much are the eDiscovery possibilities that begin to open up.  Think about it, if this information is digital, well attributed, and classified (content management professionals reading this are chuckling at this notion of ECM Zen but stay with me) this starts to not just be a system that manages discrete electronic health records it starts to become a knowledge warehouse.  For example, with all all of your health records stored this way your Doctors can cross reference past lab results and your history to make a better, more accurate diagnosis.  Intelligence can be built in to flag items if certain tolerances have been met and send alerts.  Reporting across geographical areas can be generated to identify potential outbreaks and if you have ever had the flu you certainly want Doctors and organizations like the CDC to have all the information they can at their disposal.  I genuinely believe that this will not only improve our economy and our health care system but that it will lead to more cures and better health in general.  Health records hold a great deal of valuable information and but they suffer from the same plight that a great deal of other content does, not that it doesn’t exist but that it can’t be found.