The December HIT Standards Committee included a discussion of the work ahead for the next year based on the priorities we've heard from stakeholders. We'll have 10 in person and 2 telephonic meetings in 2012. Our topics by quarter will be as follows
January-February-March
1. Assuming that the Meaningful Use Stage 2 Standards and Certification Notice of Proposed Rulemaking will be published in early 2012, the HIT STandards Committee will need to review any comments submitted. In the meantime, we'll continue work on testing criteria and will ensure any test scripts are piloted before they are finalized.
2. Quality Measurement standards
As I've mentioned in other posts, there are three key elements of work needed to improve quality measure computation and submission. First, quality measures need to be simplified so they are based on data elements that exist in EHRs and are captured during normal workflow. Second there needs to be a simple mechanism for submitting numerators and denominators (or the de-identified records that make up numerators and denominators) to CMS. Finally, there needs to be a simple query language created so that new quality measures can be designed without have to write new code.
3. NwHIN Exchange refinement
Previous analysis by the NwHIN Power Team included recommendations for improving the NwHIN Implementation Guides especially the Patient Discovery Specification and ebXML metadata.
4. Value sets/vocabulary mapping
Ideally the National Library of Medicine will host all the necessary vocabularies and crosswalks needed for Meaningful Use Stage 2 including ICD9, ICD10, SNOMED-CT, LOINC, RxNorm, and value sets (language, gender, smoking status etc)
April-May-June
1. NwHIN portfolio - the Direct and Exchange projects require supporting components such as provider directories. We need to finalize specifications for these items.
2. Query Health review - in the December HIT Standards Committee meeting we heard about Query Health and sending questions to data rather than aggregating data centrally. We'll need to finalize the standards for defining medical concepts used in queries, the query language itself, and responses.
3, Radiology Standards - DICOM is a non-standard standard. Many manufacturers of image modalities, PACS, and viewing software extend the standard in proprietary ways. If we want HIEs to support image exchange, we'll need a single, constrained implementation guide for image content. Ideally we'll separate content standards from transport standards. At present DICOM mixes the two.
4. Governance - We need to ensure alignment between the S&I Framework, HIT Standards Committee and SDOs. Setting common priorities, aligning the work, and coordinating the products of multiple SDOs will take creative governance.
July-August-September
1. Detailed Clinical Models - as we consider simplified transition of care summaries such as GreenCDA, we also need to consider simplifications to the HL7 RIM such as Stan Huff's CIMI initiative.
2. Consumer-mediated information exchange - HIE needs to include provider to provider and provider to patient models so that we have a patient centered architecture that more easily supports privacy preferences for data exchange.
3. One-stop-shop for resources - HITSP specifications were challenging for implementers because they were based on indirection - a HITSP guide pointed to an IHE guide which pointed to a password protected SDO website. We need one stop shopping with all the intellectual property necessary for implementation in one place that developers can easily access. We need to finalize the plan and resources to do this.
4. GreenCDA - Simplified XML that eliminates any need for implementers to know the HL7 RIM significantly reducing barriers to writing HIE software. We need to finalize the standard tags for Green CDA.
October-November-December
1. Maintenance strategy for standards - Once we complete the implementation guides for Meaningful Use, there will need to be ongoing maintenance and improvement by SDOs and other organizations. We need to figure out how that will be done.
2. Public Health - As new approaches for public health evolve, such as Biosense 2.0 in the Amazon Cloud, we'll need to ensure the standards are available to support them.
3. Data/Practice Portability from EHR to EHR - To date, Meaningful Use has not included the complete export of data from one EHR and the complete import of data into another EHR needed for a clinician to change vendors. Enabling "EHR portability" would be a great service to the provider community.
4. APIs/tools such as conformance testing and HIE validation - to support implementers, we'll need tools that validate the correct implementation of content, vocabulary, and transport standards.
Every year, the national standards activities expand, refine, and constrain implementation specifications. Although there will always be work to do, we're on a great trajectory in 2012.
Hi John
ReplyDeleteI was a bit surprised by your comments about DICOM, especially in that:
- basic interoperability (e.g., display for viewing) and even more advanced functionality (3D rendering, CAD, quantitative analysis) are extremely well satisfied using standard DICOM images without the need to use any proprietary information, and for the HIE use cases I am aware of this would seem to be more than sufficient
- DICOM does clearly separate the content standards from the transport standards, and indeed the multi-part standard was written that way for that reason - for those use cases where the rigor of the DICOM network services, or their http equivalents like WADO and IHE XDS-I.b, or DICOM media services, are not needed, then indeed one can use any transport mechanism that one wants; lots of people email and ftp DICOM part 10 files around quite successfully, for example
So, in short, for the purposes of HIE exchange, it seems to me that an "implementation guide" would serve little if any purpose.
For very specific use-cases (for example digital mammography interchange, cardiac NM), the equivalent of an "implementation guide" is indeed a useful asset, not only for defining what must be sent, but also what the recipient must do with it (mandatory display features); the IHE Radiology domain has indeed defined several such "profiles" for these use-cases, and will happily define more on request.
Perhaps you could clarify more precisely what deficiencies you see in this respect that led to your comment, and also who you would suggest might have the expertise to rectify them ?
David