Please note: This post by the HIT Standards Committee’s Implementation Workgroup is now closed for comment. Monitor this blog for more posts from the FACA committees and its workgroups as issues develop. Also, please visit the Health IT Buzz Blog to join other Health IT related conversations.
As the HIT Standards Committee and its various Workgroups listen to the experience and advice of practitioners, standards experts, clinical system vendors and technological wizards and contemplate what recommendations to make to the Office of the National Coordinator, we often turn to look at what works in the real world as an anchor. One of the earliest principles the Committee embraced is that the standards being recommended should be in actual use – to be not only adoptable but adopted.
An example of one experience the HIT Standard’s Committee is looking at is my own experience at the Regenstrief Institute. My experiences at Regenstrief have included “lessons learned” applicable to the HIT Standards Committee, and I’ve been asked to share these lessons learned with you now.
The Regenstrief Institute has fostered clinical data standards development for more than three decades. Beginning with standards for electronic messages including ASTM [American Society for Testing and Materials] E1238, Dr. Clement McDonald then Director of the Regenstrief Institute (now director of the Lister Hill Center at the National Library of Medicine) championed the cause of clinical data standards leading to the establishment of the Health Level 7 [HL7] standards development organization which developed HL7 version 2.x which is probably the most widely used clinical message standard in the world. Another colleague of mine, Dr. Gunther Schadow, has been instrumental in designing the HL7 version 3.0 Reference Information Model (RIM). In the early 1990s, Dr. McDonald began to develop LOINC (Logical Observation Identifiers Names and Codes) in order to provide standardized codes for laboratory results, radiographic studies and other clinical observations. Finally, Drs. Schadow and McDonald led development of the Unified Code for Units of Measure (UCUM) which provides human-friendly codes for all units of measures with precise semantics to facilitate unambiguous and computable communication between computer systems used in science, engineering and business worldwide.
Good enough standards
The Regenstrief Institute began developing the Indiana Network for Patient Care almost 15 years ago, using a few simple clinical information standards – HL7 V2.x and DICOM for message formats and LOINC, ICD-9, CPT-4, and NDC for coding information. As the Indiana Health Information Exchange evolves, these same standards serve us well today with a few additions, including NCPDP message formats for prescriptions and medication histories, RxNORM for coding medications, SNOMED codes for results like “positive” and findings derived from pathology reports, and the Unified Codes and Units of Measures for units. Data were and continue to be protected in transit by using virtual private networks which were challenging to get to work in the early days and are now trivial. Of course we welcome the recent development of the National Provider Identifier (NPI), which is starting to simplify provider identification.
We have used standards permissively – applying them as rigorously as possible but adapting to what existing systems and data sources are capable of providing. Our rationale is simply that we can’t wait and the standards are good enough. Nearly every clinical system can send HL7 v2 messages, although we have begun to exchange some data in formats including the CCR. We have implemented and demonstrated our ability to generate and exchange CCDs following the NHIN implementation specifications with others, including federal agencies. However, when we tried to use these specifications to share data with some large, technologically sophisticated healthcare organizations for direct display and integration in their enterprise systems, they quickly asked for a simpler, less cumbersome approach and we returned to our tried and true suite of standards which is working well.
While we are permissive in using standards, we never “dumb down” the data. We work hard to make sure that we never lose information. It is too much work to create structured data but, again, we take data as we are able to get it.
Someone, someday has to do the “heavy lifting” to map local test identifiers and radiology study codes to LOINC codes. We do that work now in order to get the benefit now. No matter when a laboratory or radiology center switches to a new system or re-implements their existing system, this work will have to be done – there is no reason to wait. Even more important, this mapping can be accomplished in a reasonable time particularly if, as my colleague Dan Vreeman has demonstrated, we focus on the less than 10% of laboratory results that account for nearly all results.
Using these simple standards, we connect more than 70 hospitals and 12,000 physicians along with other providers, including laboratories, and process tens of millions of messages monthly. These standards are also good enough to share data between health information exchanges. Data are flowing daily between IHIE and Healthbridge, the first live exchange of information between Health Information Organizations in the country.
Of course there is more work we have to do, even in Indiana, but that is all the more reason that you should not wait for more or better standards.
Good enough tools
Providers who don’t have an EMR application can still benefit through functionality like our clinical messaging system called DOCS4DOCS® which Dr. Mike Barnes developed. Not only does it provide operational efficiencies, but it also serves as an evolving repository of clinical results with a long term archive of patients’ clinical data directed to the provider. The venerable Regenstrief Medical Records System INQuiry application and its newly deployed replacement that we call Patient Results Review, developed by Dr. Doug Martin, provides patient centric, longitudinal comprehensive access to a patient’s clinical results. Anecdotes and large randomized controlled trials have demonstrated that these simple tools are “good enough” to improve the quality and efficiency of care.
In addition to making these data available for care, we proactively monitor the state of Indiana for outbreaks of disease, ensure that reportable conditions and diagnoses are delivered to public health officials in a timely fashion, measure the quality of care that citizens throughout the state are receiving, and provide feedback to providers to help them improve the care they deliver; we monitor for adverse drug events, support clinical trials designed to new treatments, and use the data to develop new medical knowledge.
Good enough standards and good enough tools — improving care.
As the HIT Standards Committee looks to the real world, and share the types of stories we are looking for to inform our recommendations, we welcome your comments or feedback.
– Dr. Marc Overhage, Regenstrief Institute
Tags: FACA, Federal Advisory Committee Act, HIT Standards Committee, ONC
HL7 has proven very effective for GetWell as we’ve supported our 60+ hospital clients in leveraging their ADTs, EMRs (currently interfaced to most major Orders and Documentation systems), eMARs and other systems to create a meaningful connection to patients at the bedside. Our solution transforms the television in the patient room into an interactive tool. With the benefit of information coming through interfaces and read/write capability, Interactive Patient Care enables patients to become more involved in their care process. Further, our technology allows staff to prompt the patient to get involved in their care (e.g., communication regarding discharge planning, education on Joint Commission/CMS requirements, etc.).
Beyond the comment regarding HL7, I want to emphasize the importance of ensuring that standards and frameworks incorporate accessibility of information/process in the patient room (whether through the patient television or otherwise). In the absense of interactive tools at the bedside there are two alternatives (1) patients will continue in vacuum and removed from their care or (2) interaction will remain fully dependent upon human intervention (in a world of declining resources and increasing demands on inpatient staff).
Agree or Disagree:
13 
7 (+6)
There are still a bunch of “myths of the marketplace” concerning HL7 v3. I will arrange to have a presentation of mine from 2007 posted at a convenient website so folks can look at these, and my explanations of the mistakes and misperceptions about HL7 v3 that each ‘myth’ is based on.
Agree or Disagree:
12 
7 (+5)
Needed: HITECH Adoption Life Cycle Framework
“Perfection is the enemy of the Good.” A clear and reasonable assertion made during the HIT-SC discussions.
“Let’s start simple” is also a reasonable assertion, as long as it does not lead to starting from scratch when we already have many pieces of the puzzle in place. The challenge is not always whether we have enough pieces, but where we need to choose between pieces to reduce redundancy and variability to get the level of consistency desired. The HIT-SC and HITSP have done an admirable job to identify the pieces available to support MU goals, eliminate duplicates, and allow for a glide path that converges to less. All in support of “less is more”.
But then there is another saying we have to consider: “Practice Makes Perfect.” Applied to our problem that means we have to crawl before we walk before we run. While there are many puzzle pieces in play, it is a new journey to get all the stakeholders in lock-step across the US. Sure, everybody is using HL7, but as Wes Rishel pointed out, when you’ve seen one HL7 implementation you’ve seen one HL7 implementation. Due to a host of understandable dynamics, we do not all use V2.6 with the same vocabulary with the same mandatory/optional fields. So we all have to converge towards a common path and then start to travel the path together, while allowing for innovation and exploration along the way.
With all the best of intentions, the journey we’re embarking on is not yet based on a process that is well defined, well understood, fully bought-in, and predictable. We therefore see expressions of desired perfection where the pre-requisite processes and standards to get us there are under construction with limited experience and evidence to support their efficacy.
We’re starting to see the standards puzzle coming together, but the process puzzle remains murky and undefined. And if there is some level of definition, it is certainly not transparent to the typical stakeholder.
I therefore would like to urge the HIT-SC Implementation Workgroup to focus on establishing a HITECH Adoption Life Cycle framework that can orchestrate all the relevant activities and considerations from initial target objectives/use case through measurement of the actual attainment that can serve as feedback into enhancements (up or down) of the objectives. In other words, demonstrate that the standards are really working and delivering benefits, rather than mandating ever more standards before the initial set has been measured.
We have a long way to go, and in many ways the journey will never end. Therefore a strong Adoption Life Cycle framework is essential to manage to success and avoid stumbling into failure.
Agree or Disagree:
20 
7 (+13)
November 12, 2009
Aneesh Chopra, Ph.D.
Chief Technology Officer
Office of Science and Technology Policy
The White House
Washington, D.C.
Dear Dr. Chopra:
This letter represents the comments of the Medical Imaging & Technology Alliance (MITA) in response to the Notice in the Federal Register, 74 Federal Register 53505, October 19, 2009, with respect to soliciting stakeholder input for lowering the barriers to standards adoption, evaluating the degree to which proposed standards achieve policy objectives, and establishing an ongoing process to gather public input to inform future standards development, revisions to existing standards, or guidance or tools to minimize the cost of adoption. MITA appreciates the opportunity to share its views with you.
The Medical Imaging & Technology Alliance (MITA), the medical division of the National Electrical Manufacturers Association (NEMA), is the collective voice of medical imaging equipment manufacturers, innovators and product developers. It represents companies whose sales comprise more than 95% of the global market for medical imaging technology. These technologies include:
• Medical X-ray equipment
• Computed tomography (CT) scanners
• Ultrasound
• Nuclear imaging
• Radiation therapy equipment
• Magnetic resonance imaging (MRI)
• Imaging information systems
Our comments below will address the adoption and implementation of proposed standards.
Twenty-first century healthcare is effectively delivered due, in large measure, to the current state of medical imaging. Imaging drives much of the diagnosis and treatment of patients across the healthcare continuum. Over the last 25 years, we have improved diagnostic and treatment effectiveness by creating the ability to digitally move these images where they can best be employed in improving outcomes.
Digital Imaging and Communications in Medicine (DICOM) Standard
The DICOM Standard is indisputably the one standard which should be used for communication of imaging information. The DICOM format for the exchange of images is accepted worldwide with nearly 99% of medical imaging systems support the DICOM standard. In the U.S., digital imaging is the overwhelming choice for providers with 90% of all imaging supporting a digital format. DICOM is currently supported in more than 100,000 imaging products in the United States, representing an investment exceeding $57 billion dollars.
It should be noted also that the DICOM Standard is not static, but instead is a “living“ standard, in that it is continually undergoing changes and has the capability to evolve to meet future requirements. DICOM is also the essential building block for each network.
Digital imaging storage and transport at its core relies on the global DICOM standard. Medical devices in radiology, cardiology, dentistry, pathology, and other clinical applications around the world, rely on the DICOM standard. DICOM’s position as the foundation block in interoperability is a crucial component for the Integrating the Healthcare Enterprise (IHE) initiative. Caregivers have come to rely on medical image and diagnosis integration into the Electronic Health Record (EHR) thanks to other essential and DICOM-aligned standards such as HL7 and the workflow profiling of IHE.
Further, as reports are distributed from a local Picture Archiving and Communication Systems (PACS) to the electronic health record, if a certified EHR is built and implemented, interoperability of the digital system is already built in.
To support the smooth evolution of implementations and to allow the Committee to move forward with the much more difficult areas of basic data creation, it is critical that the HIT Policy Committee, HIT Standards Committee, and the HIT Standards Committee, Implementation Group, publicly declare that the DICOM Standard will be the image format to be used for medical images. With identification of DICOM as the recognized standard for use with medical images, the ongoing evolution of the DICOM Standard, as well as other standards, can begin the critical move to a successful implementation.
Challenges remain in moving forward with digital-based imaging. Some of these are being met by healthcare organizations adopting broad enterprise security standards found in ISO 27001-27006 and, as in ISO 27799, adapting them directly to the healthcare enterprise. The safety, effectiveness, and security of medical devices on computer networks need the risk management strategies afforded by the ISO/IEC80001-1 standard, which is currently in development. The development and application of these global standards are informed by national and organization guidance provided by groups like NIST and medical imaging groups like MITA. Bringing security standards into the interoperable DICOM world in a way that continues to emphasize safe, effective, and cost-conscious healthcare is a challenge being embraced by MITA and its partner organizations working on issues around the future of medical devices in modern network-connected healthcare delivery systems.
As stated above, MITA is uniquely positioned to assist the HIT Standards Committee, Implementation Work Group in assessing the current environment on the adoption and implementation of standards, and what will be required in the future to enhance implementation of the Nationwide Health Information Network (NHIN).
Based on MITA’s experience and expertise, among the areas where we can provide valuable advice to the Implementation Work Group are:
-Providing actual field examples of clinical facilities which have successfully implemented the DICOM standard;
-Conducting a feasibility analysis to demonstrate the benefits of implementation of DICOM; and
-Analyzing how providers are likely to receive various proposed solutions based on their individual health information technology capabilities.
MITA can provide in the future specific examples of successful image sharing using the DICOM Standard. MITA would be pleased to discuss with the Health Information Technology Standards Committee, Implementation Work Group, in greater detail how the DICOM Standard communicates imaging information.
MITA and its parent organization NEMA firmly support the Obama Administration’s goal to implement NHIN. We would like to partner with the HIT Standards Committee, Implementation Work Group and provide our expertise and experience to assist in achievement of this critical goal, through active participation in the standards adoption and implementation process.
Please contact me directly at (703) 841 – 3279 or dfisher@medicalimaging.org.
Respectfully,
David Fisher,
Vice President, National Electrical Manufacturers Association (NEMA)
Managing Director, Medical Imaging & Technology Alliance (MITA)
Agree or Disagree:
13 
8 (+5)
Taking a closer look at the large list of standards matrices and their dependencies, it seems pretty clear that no new innovator could enter into a health care project and hope to comply with the standards without a large amount of time and money. This is unfortunate. Most of the standards seem to be established to provide structured, semantic understanding of the information. This seems like a laudable goal, but as posted by the PDF Healthcare advocate, Deborah Kohn, and many providers, it is not clear that this is needed by very many individuals or groups. For most health care providers, those specifically mentioned by Aneesh Chopra in the goals of this dialog, simple exchange of image and textual data and markup seem to be more than adequate to help improve health care information and reduce costs. I also suspect that for any given group using these standards, only a small subset of the standards are applicable. So while any standard message could be of high value for a particular purpose, most are of lower value to the majority of the ecosystem.
The testimonies from the non-healthcare technology experts had a theme of keeping standards as simple as possible. A lesson of the web was that a simple protocol that allows for a wide variety of uses and for which the barrier to entry is low will result in widespread adoption and tremendous innovation. Conversely, if you look at other large and complex standards, you can see that they result in a small number of implementations. As an example, look at the low number of J2EE providers out there, the number of WS-* implementations, or the number of successful implementations of SAML which many of the health care standards depend on. If a small number of implementations is an acceptable outcome, what you are effectively saying is that you need standard software, not specifications. Considering the goals of getting more involvement of creative entrepreneurs, technology experts and companies, this does not seem be an acceptable outcome so early in the process of moving to EHR.
It really seems that the needs of the health care providers should drive the priorities of the standards setting process, and that in turn should lead to effective document exchange as its first goal.
Hot debate. What do you think?
16 
13 (+3)
The solution, as usual, depends on the definition of the goals. If our goal is to promote meaningful interoperability at very short order, then I agree with Dr. Overhage. There are “good enough” standards in wide use today. There is an abundance of experienced resources that can develop the critical mass of interfaces that will be required to make this exercise in interoperability move forward without delay. There is plenty of infrastructure in place as well.
A meaningful contribution of the committee at this point would be to further simplify and restrict the current standards to meaningful subsets (nobody uses all the available fields in HL7 v2) that will speed up implementation by ALL parties, and this includes small vendors and providers who have no prior experience at all.
Comprehensive standards like HL7 v3 are beyond our immediate capabilities due to the inherent complexity and lack of trained resources. However, I do believe that in good time, as more and more meaningful data comes to be exchanged, we will need to expand our standards, maybe towards v3, or maybe something else. In any case a backwards compatible transition path should be defined as well.
In summary, interoperability at the RIM level will not happen overnight just because it is mandated. Most technology companies will be unable to comply in one short year. We have to start somewhere, and as long as our path is clear, we can start with the “good enough” infrastructure that we have today.
As strange as this may sound, at this moment in time, the committee should further restrict and simplify the current standards in order to allow as many entities as possible to enter the data exchange community quickly and with low cost.
Any complexity added at this critical juncture will guarantee failure to achieve our goals.
Hot debate. What do you think?
16 
15 (+1)
Interoperability at the RIM level, either for CDA documents or V3 messages, is not terribly difficult. Any technology company should be able to write the basic infrastructure code for parsing, generating, and manipulating RIM content in less than a year. Within Axolotl Corp we’re building a Java library to do just that. The first version of that library took only a few person-months.
The hard part is putting together integration profiles and agreeing on terminologies. Someone has to decide which fields or XML elements will actually be populated for particular use cases. And will values be coded in SNOMED-CT / LOINC / ICD-9? Those issues are basically the same whether you use HL7 V2, V3, or something else.
Agree or Disagree:
20 
11 (+9)
Nick, that is exactly the point. We only have one year to do this. Creating libraries, testing and agreeing on terminologies and then testing on a large scale will take longer than a year.
There is an optimal size of company that could quickly adapt to new standards. Companies that are too small to have a few person-months available will fail to meet the deadlines. Companies that are too big and currently operate thousands of interfaces based on existing standards (like national labs), face different challenges and will most likely also be unable to convert in time.
Then there are the terminology issues that seem to also add unnecessary hoops. We have to switch from ICD-9 to ICD-10, knowing full well that we will need to move to SNOMED shortly thereafter. How efficient is that?
I just don’t see the need for constantly placing more and more hurdles in the road. As it is, most studies show that very few provider organizations will be able to meet the interoperability requirements in the allotted time.
Assuming we really want interoperability to be widespread and adoptable by big and small entities at short notice, there is no better way than using the current means and infrastructure to make a start.
If you want to get from point A to point B as fast as possible and the roads are narrow and rather old, you don’t blow up the old mountain road and build a 4 lane highway before you undertake any travel. You rent transportation that can move on the existing road, even if it means ridding donkeys for a while.
Hot debate. What do you think?
13 
10 (+3)
Discussion of this type seem to be increasing and to what point. Within a closed system, as the Indiana Network largely is, HL7 v2 works. If I know (control) both the sender and the receiver, then I can specify content, structure and messages. It works. But, if I want to go outside that environment, I loose interoperability. Even if I have a solution 80% of the time, I still have to deal with the remaining 20%. Ansd if I am one of the 20%, then that becomes important.
The UK NHS has implemented HL7 v3. Are they smarter than the US? Maybe but I’m not willing to give them the edge. They simply control the process from the message definition and creation, to implementation, to use. The same is true for Canada. Canada is creating a library of v3 messages that become available for use by others. Imprementing a v3 message that some one else has gone through the complex methodology is no more difficult that implementing v3. CDA – based on a model that has generality. In my opinion both v2, v3 and CDA have their place.
Agree or Disagree:
34 
8 (+26)
V3 can easily address a larger scope then V2. I am in this business since 1998 in TBS Group and we have integrated more than 130 different applications to our Hospital Information System, starting with point-to-point interfaces, then adding integration middleware, then adding hl7 V2 gateways and finally, since 2005, supporting V3. This new version gives us the possibility to run for new challanges. From my point of view it’s a matter of progress: we can compare latest versions with former mature and stable and popular versions, but everything has an end-of-life. Without V3, HL7 would probably become less popular in the near future, due to people moving towards newer standards like OpenEHR. The fact that an open standard becomes popular like HL7 is a sort of miracle, and moving (even slowly) towards V3 gives this standard a future, enlarging its scope and attracting more people, organizations and industries.
From this point of view I am optimistic because I see all big sw industries releasing hl7 v3 based middleware: Microsoft, IBM, Oracle, Intersystems, Progress. That means they are preparing the infrastructure for the next generation of sw appls for healthcare.
Agree or Disagree:
35 
8 (+27)
An open system architecture based on standard protocol like HL7 provides vendor independent flexible interface mechanism. Anybody can interface with an open system using appropriate protocols, independent of its vendor. When using HL7, the interface allows for numerous systems to be added to a single HL7 feed. New systems can be added without having to modify the original source system.
Alternatively proprietary interface model, can seem to be relatively simple to design and implement at first go but can be more complex to maintain and scale specially when integrating and exchange information for multiple applications and systems.
Agree or Disagree:
24 
7 (+17)
Pradeep, I agree that an open system architecture based on standard protocols are critical. I would also add that these standard protocols must be modular (i.e. not mix payload and transport, etc.). We have seen the explosion of the Internet based on open standards and appropriate architectures. You mention HL7, but HL7 is an SDO not a standard. Can you let us which HL7 standards you are recommending?
Best, Steven
Agree or Disagree:
20 
10 (+10)
Steve, to answer your question: just take CDA (CCD) at this moment to start with. For the kind of patient data exchange that Marc was mentioning, we don’t need to discuss much beyond this.
Regarding your mentioning “modular” and “mixing of payload and transport” issues, I have recently heard these pointed out on another blog, but those are really old considerations and the whole point of HL7 v3 has been to make that distinction.
regards,
-Gunther
Agree or Disagree:
17 
7 (+10)
Pradeep, I too would like to know which standards you are recommending. As I can not determine what the processable standard is for V3. As it was explained to me: XSD files are informative, MIF (instance files) are an expression of the normative content. The files themselves are not normative.
Hot debate. What do you think?
12 
9 (+3)
In theory the XSD files are not normative, but in practice that’s what everyone uses (at least as a starting point). In some cases the XSD files are slightly modified while still maintaining consistency with the underlying specification.
Hot debate. What do you think?
12 
9 (+3)
It would be a big mistake to go backwards and move away from CDA and HL7 RIM based standards. In this article you mention Gunther Schadow. He and I chaired the HL7 Java SIG working group, now called RIMBAA RIM Based Application Architectures. Using either the open source HL7 Java SIG or various commercial products, you can receive and parse any RIM based documents or messages. Using the CDA tools developed by the VA and IBM which is part of the Open Health Tools Alliance you can create any fully constrained CDA documents.
Semantic interoperability requires model based standards, which CCR and HL7 V2 are not.
KP and the VA are among many organizations that have successfully traded clinical data using NHIN CDA standards. Let’s not give up on all the progress that has been made and go for another poor simple solution that will never result in semantic interoperability.
Agree or Disagree:
81 
62 (+19)
The CCR is not in the same category with regard to RIM interoperability as HL7 V2. The CCR is mapped to the RIM via the CCD. The CCR contains the same clinical values as the CCD, mappable via XSLT. By definition.
In using a CCR for interoperability, one does not lose RIM based semantic interoperability. Only the requirement to process complex templates.
Agree or Disagree:
33 
23 (+10)
I don’t agree with George, CCR is only a small subset of all the data you need to interoperate. So the solution cannot be just CCR. CDA has numerous implementation guides for every imaginable domain from child health care to procedure notes.
To quote Albert Einstein: “Every thing should be made as simple as possible, but not to simple.”
We think CDA and RIMBAA are the simplest things possible.
Agree or Disagree:
32 
19 (+13)
CCR seems like kind of a dead end. It only addresses a single limited use case, and is still fairly complex. Why put effort into CCR when with just a little more work you can support CDA (including CCD) and have a solid foundation for the future? For most implementers it won’t even be necessary to support the complete CDA R2 specification, a large subset is enough for most use cases.
Agree or Disagree:
34 
17 (+17)
CCD contains the same basic data constructs and similar valuesets to CCR, but I disagree that this is completely mappable via XSLT. The idea of bi-directional lossless transforms was discussed in the development of CCD, but this was explicitly excluded from the scope. This was because there were fundamental differences in data models that could not be resolved. I don’t remember the explicit examples, but do recall that some values were structured in CDA, which were unstructured or precoordinated into the terminology in CCR and vice/versa. Also, CDA allows for a richer expression of null values as I recall. I have heard some say that they can map about 90%. But, don’t expect that you can move back and forth without data loss.
Agree or Disagree:
21 
17 (+4)
In the testimony of the implementation panelists to the Implementation Workgroup of the HITSC, I commented, as did many other panelists, that the biggest barrier to interoperability is not the data formats, but what Adam Bosworth called the encodings — the core medication, problem and lab terminology. If we have the encoding correctly defined, you can give me an active medication list. That active med list can be expressed in CDA, in HITPS 32 formatted CCDs, in a CCR, in an RDE HL7 V2 message, in a custom JSON format, in an NCPDP SCRIPT RXHRES, in a CSV data set, if you and I agree that this is an active medication list, and you and I agree on the encodings, we can do really interesting things to improve health care.
An active medication list is not a deep concept. If I have to understand the RIM to send and receive an active med list, we are placing large barriers to the developer community. My position on this is: let’s agree on the encodings, let’s agree on the simplest representation of the high value components (med list, medication allergies, problem list, clinical results), and build our systems on that. If we can routinely accomplish continuity of care with a unified, reconciled record containing medication, med allergy, clinical results and problems for most of the patients in the US, then we can move on to more interesting things that require a sophisticated model based approach.
Agree or Disagree:
16 
9 (+7)