| Literature DB >> 21603282 |
Robert Greenes1, Meryl Bloomrosen, Nancy E Brown-Connolly, Clayton Curtis, Don E Detmer, Robert Enberg, Douglas Fridsma, Emory Fry, Mary K Goldstein, Peter Haug, Nathan Hulse, Tonya Hongsermeier, Saverio Maviglia, Craig W Robbins, Hemant Shah.
Abstract
The Morningside Initiative is a public-private activity that has evolved from an August, 2007, meeting at the Morningside Inn, in Frederick, MD, sponsored by the Telemedicine and Advanced Technology Research Center (TATRC) of the US Army Medical Research Materiel Command. Participants were subject matter experts in clinical decision support (CDS) and included representatives from the Department of Defense, Veterans Health Administration, Kaiser Permanente, Partners Healthcare System, Henry Ford Health System, Arizona State University, and the American Medical Informatics Association (AMIA). The Morningside Initiative was convened in response to the AMIA Roadmap for National Action on Clinical Decision Support and on the basis of other considerations and experiences of the participants. Its formation was the unanimous recommendation of participants at the 2007 meeting which called for creating a shared repository of executable knowledge for diverse health care organizations and practices, as well as health care system vendors. The rationale is based on the recognition that sharing of clinical knowledge needed for CDS across organizations is currently virtually non-existent, and that, given the considerable investment needed for creating, maintaining and updating authoritative knowledge, which only larger organizations have been able to undertake, this is an impediment to widespread adoption and use of CDS. The Morningside Initiative intends to develop and refine (1) an organizational framework, (2) a technical approach, and (3) CDS content acquisition and management processes for sharing CDS knowledge content, tools, and experience that will scale with growing numbers of participants and can be expanded in scope of content and capabilities. Intermountain Healthcare joined the initial set of participants shortly after its formation. The efforts of the Morningside Initiative are intended to serve as the basis for a series of next steps in a national agenda for CDS. It is based on the belief that sharing of knowledge can be highly effective as is the case in other competitive domains such as genomics. Participants in the Morningside Initiative believe that a coordinated effort between the private and public sectors is needed to accomplish this goal and that a small number of highly visible and respected health care organizations in the public and private sector can lead by example. Ultimately, a future collaborative knowledge sharing organization must have a sustainable long-term business model for financial support.Entities:
Keywords: Clinical decision support; knowledge bases; knowledge sharing.
Year: 2010 PMID: 21603282 PMCID: PMC3097479 DOI: 10.2174/1874431101004010278
Source DB: PubMed Journal: Open Med Inform J ISSN: 1874-4311
Condensed Functional Requirements for a Knowledge Repository. Requirement Categories and Examples of Functional Requirements are Included. The Requirements Seek to Capture Elements of the Knowledge Model, the Knowledge Authoring Environment, the Knowledge Sharing Environment, and the Repository itself. An As-Yet-Unrealized Goal is to Specify Functional Requirements for a Knowledge Execution Component of this Environment
| Knowledge Delivery Model: Requirements | |
|---|---|
| Capability | Discussion |
| The system will function using Symbolic Variables | A goal is to separate the logical manipulation of symbolic variables from the mapping of those symbolic variables onto (local) clinical data. Identifiers for symbolic variables are selected to be consistent with the thought processes and language of clinicians (i.e., last serum_glucose). |
| The system will function using Objects (again symbolically) | |
| Time will be a Component of Variable/Object Collections. | All clinical data should retain its timestamp when rendered as a variable in decision logic. The timestamp is chosen to represent the point in time when the data value was current. (A discussion of time ranges and other, non-point time values will be postponed.) |
| Allows storage (upload) of decision modules. | Hopefully through a process that “normalizes” the chunks of logic. This could be accomplished by mapping onto a standard, interchange format. |
| Allows retrieval (download) of decision modules in a read-only mode. | This is for download of modules to test and perhaps use in a recipient system. |
| Supports check out of decision modules explicitly for either editing or edit-free reviewing. | The system would allow for checkout of logic or collections of logic for editing and other management functions. This would require an “author” level authorization. When decision logic is checked out for editing by one author, it cannot be checked out for editing by other authors. When altered logic is checked back in, it would receive a new version number. |
| Supports views of decision modules in the repository’s native (XML) markup. | The assumption is that, at least part of the decision modules will be stored in a XML-tagged data model. |
| Supports views of decision modules in "user friendly" text-based format. | Converters should be present that will display the decision logic and metadata in an easily read textual format |
| Supports views of decision modules in graphical format. | Trees or flow diagrams can show the relationship between parts of the decision logic (families of rules or modules) used to create more complex, decision output (guidelines). |
| Supports conversion from local knowledge models to a repository specific, medical rules interchange format (MRIF). | The goal is to find a robust "Interlingua" that will facilitate moving logical constructs from one executable form to another. |
| Supports conversion from the repository-specific, knowledge interchange format into forms executable in multiple knowledge execution environments. | Ideally, these knowledge execution environments would all have a local expression of the executable form in XML. This would allow most translations to be done using XSLTs. |
| Translators should accommodate rule models including all standard logical functions/structures. | A standard vocabulary of logical structures will need to be represented ( |
Examples of Metadata for Indexing Content in a Knowledge Repository. The Collection is Derived from Metadata Described in a Number of Categorization Schemes for Computable Medical Knowledge
| Metadata Title | Metadata Description | Orig. Metadata Source |
|---|---|---|
| Resource Title | Title of module of clinical logic. | In Arden In Morningside Template |
| File Identifier (URI) | Uniform Resource Locator(for storage); replaces filename (Arden) | In Arden In Morningside Template |
| UNID | Unique identifier for indexing through a terminology service for instance. | In Morningside Template |
| Version and Branch ID | A number indicating the version. In the context of a source repository, this might capture new branches as versioning generates alternate directions in the logic. | In Arden In Morningside Template |
| Submission/Revision Dates/Branching dates | The date associated with submission of this version. | In Arden In Morningside Template |
| Purpose | Statement of the goal of the logic (free text). May also provide tag references to a controlled taxonomy of purposes. | In Arden In Morningside Template |