Announcements
- Click here to view the end-to-end pilots demonstration, which took place during our SDC Community Call on October 6th, 2016.
- We are in the process of collecting pilot metrics. You can download a copy of the SDC pilot report out template here.
- SDC Pilots: Attention SDC Pilot participants! For those of you who are interested in participating in an SDC Pilot, please review the following checklist below.
SDC Schemas in GitHub
The SDC schemas are in GitHub at https://github.com/esacinc/sdc-schema-package.
There are command-line git clients as well as GUIs. The command-line client in Windows that has been used is called Git Bash, and it comes with a basic GUI as well. https://git-scm.com/downloads
More advanced GUIs can be found at https://git-scm.com/download/gui/windows.
If you plan on making changes to the schema files and sharing those with the group, you'll want to fork (more info) the repository above into your own GitHub account, and then you'll clone it to get it locally. If you just want to view and/or use the files you can just clone the repository. A clone is basically equivalent to an SVN checkout:
git clone [project url, whether ESAC's or your fork]
git clone https://github.com/esacinc/sdc-schema-package
If you're already familiar with SVN, this page tries to translate similar ideas over to git. However, there is a big difference between the two. SVN uses a central repository as the source of truth. With git, there is no defined central repository. All git repositories are created equal. Even the GitHub repository. The only thing that makes the GitHub repository special is that we all decide that it is. This has implications on the workflow, as described below. "Cloning" a git repository really does clone it. You have the full, working git repository on your local machine, not just a copy of the files.
Let's imagine that you make code changes and are ready to share them. Here is the difference between SVN and git. A git "commit" command will only commit the files to the repository that is being used, which in this case is your local clone. Because the local clone is a complete, working git repository, commits at this point are still only local.
To get the changes to appear on GitHub (in a manner similar to a SVN commit), you'd use git push. This pushes your local commits to a remote repository. However, this is not what we want to do and would be wasting git's ability to facilitate distributed development. Git usually works differently, especially with commits coming from multiple sources. We will use what is known as a "pull request." A pull request is a request from someone with code changes to pull those code changes into another repository. In our case, a contributor would issue a pull request to the main GitHub project, asking that their code changes be reviewed and pulled into the project. Then every other person using the code can pull those changes to their own repositories.
When you've created a fork, at some point you'll want to update your fork with the original (ESAC-owned) repository. This link shows how to do that: https://help.github.com/articles/syncing-a-fork/
SDC Pilots Participation Checklist
- PLEASE READ the SDC overview found below.
- Determine which role accurately describes your organization and what you would like to pilot:
- Form Manager
- Form Filler
- Form Receiver
- Form / Data Element Repository
- Other
- Contact the team leads (Jenny Brush and Vijay Shah - contact information provided below) to schedule a pilot planning meeting.
- Review the IHE SDC Profile and/or the FHIR SDC Profile to determine which technology best suits your data sharing needs.
- If you plan to pilot the IHE SDC Profile, complete the IHE SDC Pilot Plan Template.
- If you plan to pilot the FHIR SDC Profile, complete the FHIR SDC Pilot Plan Template (under development).
- Work with the team leads to schedule a time to Present your Pilot Proposal to the community (All materials are provided in downloadable format below).
Structured Data Capture (SDC) Initiative Overview
With electronic health record (EHR) adoption rising across the U.S., the volume and detail of information captured by healthcare organizations and providers will grow exponentially. Although health care providers and others use various sources and methods to capture and synthesize patient-level data, EHRs have been recognized as the data source with the highest potential to provide timely and relevant data in a form that is quickly usable for quality and safety improvement, population health, and research (sometimes labeled "secondary" use or "reuse" ). EHR data obtained during episodes of care will become increasingly valuable to healthcare organizations striving to leverage electronic information to drive efficiency and quality. Of particular interest are efforts to leverage clinical data captured during episodes of care and link the clinical data to supplemental data collected for other purposes including: 1) clinical research, 2) patient-safety event reporting, 3) public health reporting, and 4) determination of coverage. Once captured, aggregated and analyzed, these combined data can be used to identify trends, predict outcomes and influence patient care, drug development and therapy choices.
The Structured Data Capture (SDC) Initiative aims to define the necessary requirements (including metadata) that will drive the identification and harmonization of standards to facilitate the collection of supplemental EHR-derived data. In 2014, the SDC Initiative published new Implementation Guidance to define how structured data can be accessed from EHRs and be stored for merger with comparable data for other relevant purposes to include:
- The electronic Case Report Form (eCRF) used for clinical research including Patient Centered Outcomes Research (PCOR)
- The Incident Report used for patient safety reporting leveraging AHRQ 'Common Formats' and FDA form 3500/3500a
- The Surveillance Case Report Form used for public health reporting of infectious diseases
- The collection of patient information used for determination of coverage, as resources permit
The structured standard for data elements in the IHE SDC Profile is based on ISO/IEC 11179-3; the FHIR SDC Profile includes a new DataElement Profile based on DataElement Resource. The structured standard for forms in the IHE SDC Profile is based on ISO/IEC 19763; the FHIR SDC Profile uses Questionaire/Answer Resource which are based on the same SDC conceptual model. The standard for how EHRs exchange information and how they pre-populate and auto-populate forms are in both the IHE and the FHIR profile.
Benefits of Participation as an SDC Pilot Site
The Steering Team is seeking broad participation-by providers, HIT vendors, research communities, patient safety organizations (PSOs), pharmaceutical firms, Public and Private Health Insurance Payers other interested parties-in SDC pilots. SDC pilot participants could realize several benefits, including but not limited to:
- Ability to leverage initiative resources. Build on the expertise, tools and any open-source code developed through the SDC Pilots SWG and SDC All-Hands to create a better, faster, and higher quality implementation.
- Demonstrate compliance and increase efficiency of development and maintenance. Use the SDC Implementation Guidance and/or IHE Profile to inform changes to existing HIT systems and the process by which structured data is captured, stored and shared. These specifications are being harmonized with a broad consortium of Standards Development Organizations (SDOs) including HL7, IHE, and CDISC.
- Contribute to the community. Each pilot has a high profile among Government agencies, ONC grantees, and within the community of volunteers that support the Nationwide Health Information Network.
- Be recognized as an early adopter. Use participation in this important national initiative to heighten your organization's name recognition.
Value Statement for Participating Entities
The implementation of consensus driven standards for structured data capture from EHRs is expected to improve efficiencies and promote collaboration by:
- Advancing the Stage 3 Meaningful Use of EHRs Learning Health System where patient information can flow securely from EHRs to other systems like research consortia, registries, bio repositories and public health systems
- Reducing the data collection burden on health care providers by enabling secure, single-point data entry that populates to multiple systems
- Improving the comparability of data to better inform research, quality reporting and ultimately, influence patient care
- Reducing the need for site-specific EHR enhancements so that disparate EHR systems can participate in important reporting and research activities
- Limiting barriers to volunteer adverse event reporting on medical products to public health agencies leading to improvements in population health