Monday, October 31, 2011
NCPDP AND SAFE-BIOPHARMA TO COLLABORATE ON LIFE SCIENCE STANDARDS
Scottsdale, AZ and Fort Lee, NJ (October 24, 2011) -- The National Council for Prescription Drug Programs (NCPDP) and SAFE-BioPharma Association announced today a strategic alliance to advance use of their respective standards within the life sciences.
NCPDP is an ANSI-accredited standards development organization which has led transformation in the pharmacy services sector by creating and promoting standards for electronic healthcare transactions. Working closely with its 1600+ members, NCPDP has produced operational efficiencies that save more than $30 billion annually in healthcare costs, while increasing the safety and quality of patient care. NCPDP standards, such as the Telecommunication Standard for billing and reporting claims and services, and the SCRIPT Standard for electronic prescribing, have been named in federal legislation, including HIPAA, MMA, and HITECH.SAFE-BioPharma Association created and manages the SAFE-BioPharma® digital identity and signature standard for the pharmaceutical and healthcare industries. The SAFE-BioPharma standard provides a secure, legally enforceable, and regulatory compliant way to verify the identities of parties involved in business-to-business and business-to-regulator electronic transactions. The standard is compliant with HIPAA regulations and is recognized by the Drug Enforcement Agency (DEA) as compliant with its rules for ePrescribing of controlled substances.
The two organizations will collaborate in meetings, working groups, and a variety of other forums.
"We are dedicated to transforming the healthcare system by collaborating on business solutions. Collaborating with SAFE-BioPharma will benefit the advancement of standardized solutions throughout the pharmacy services industry," said Lee Ann Stember, president NCPDP. NCPDP members represent every segment of the pharmacy services sector, as well as other healthcare stakeholder groups.
SAFE-BioPharma facilitates interoperability and integration among researchers, vendors, regulators, clinicians, prescribers, healthcare providers and other pharmaceutical and healthcare stakeholders. SAFE-BioPharma digital signatures are widely accepted by global regulatory agencies.
"Our collaboration with NCPDP will lead to even greater process and cost improvements for healthcare and other sectors of the life sciences. The SAFE-BioPharma standard helps assure the secure transmission of confidential and regulated health-related information. We believe that both of our organizations will benefit," said Mollie Shields-Uehling, president and CEO, SAFE-BioPharma Association. The association's members include Abbott, Amgen, AstraZeneca, Forest Laboratories, GlaxoSmithKline, Johnson & Johnson, Lilly, Merck, Pfizer, Roche, and sanofi- aventis.
About NCPDPFounded in 1977, NCPDP is a not-for-profit, ANSI-accredited, Standards Development Organization with over 1600 members representing virtually every sector of the pharmacy services industry. Our diverse membership provides leadership and healthcare business solutions through education and standards, created using the consensus building process. NCPDP has been named in federal legislation, including HIPAA, MMA, and HITECH. NCPDP members have created standards such as the Telecommunication Standard and Batch Standard, the SCRIPT Standard for e-Prescribing, the Manufacturers Rebate Standard and more to improve communication within the pharmacy industry. Our data services include the NCPDP Provider Identification Number, a unique identifier of over 75,000 pharmacies, and HCIdea, "The Prescriber Identity Solution." For more information about NCPDP Standards, Data Services, Educational Programs and Work Group meetings, go online at http://www.ncpdp.org or call (480) 477-1000.
About SAFE-BioPharmaSAFE-BioPharma is the global industry standard for digital trust. It was developed by a non-profit consortium of biopharmaceutical and related companies to transition the biopharmaceutical and health care communities to paperless environments. For more information visit: http://www.safe-biopharma.orgSAFE-BioPharma® is a trademark of SAFE-BioPharma Association. Any use of this trademark requires approval from SAFE-BioPharma Association
Tuesday, October 25, 2011
- Using both Document Encryption and Document Signature
- Patient access to Radiology
- One Metadata Model - Many Deployment Architectures
- Can an HIE forbid copies?
- Stepping stones for Privacy Consent,
- Data Objects and the Policies that Control them,
- Consent Management using HITSP TP30
- Data Classification - a key vector enabling rich Security and Privacy controls.
- The Direct Project and IHE/HIMSS
- Signing CDA Documents
- ConfidentialityCode can't carry Obligations
- Directed Exchange vs Publish/Discover Exchange
Monday, October 24, 2011
- I would recommend signing first, as the signature is more likely to be a long-term signature; whereas the DEN encryption is more for a specific communication purpose (even though it is transport agnostic). The other reason is that logically one will unwrap the encryption protection then need to verify the authenticity of the content. One might also hang on to the signature within a protected system to prove authenticity long into the future.
- The fact that DEN produces a new document object, will make it obvious which document is being signed. Said another way the DSG signature identifies the document object that was signed. Thus the DSG signature could be across the original, unencrypted, document; or it could be across the encrypted document. The DSG would identify which of these objects was signed. If the signature is across the encrypted document then the DSG signature points at the new document object which is the encrypted document. If the signature is accross the original document, then the DSG signature points at the original document object, that is not encrypted.
- The DEN profile is providing ONLY for encryption. It is not proposing to take the place of DSG. The DEN profile does include an integrity check on the original document. This integrity check (Content Integrity) is there to assure that the decryption produced the document that was encrypted. The integrity check is not intended to replace a digital signature. For example this integrity check does not include a 'purpose' for the signature. This content integrity is there only to prove that the decryption 'worked ok'. It doesn't prove that the decrypted file is the one that you think the originator intended to send to you. It is likely that the decrypted document is the one intended, but the point I am trying to make is that DEN does not take the place of DSG.
- If you want both Authentication of the content and Encryption of the content then you should use both profiles. The main reason to keep these independent functions is to recognize the long-term needs of both are very different. Specifically the impact on long-term key management. In the case of a digital signature, one must maintain knowledge of certificate validity, but one does not need to maintain the private key. In the case of encryption, if one wants to keep things encrypted for a long time, one must maintain the private key. Organizations will also want access to encrypted content of their individuals and often will archive the encryption keys (aka Key Escrow). Surely getting the key back must be a protected action, but there are legitimate needs. This is the reason why Keys are created typically for one or the other purpose and rarely for both purposes. Usually if they are created for both, the use is for communications (e.g., TLS, SSL, S/MIME).
For more information:
IHE - Privacy and Security Profiles - Miscellaneous
Sunday, October 23, 2011
Here is my report on the work done in WG4 (Security/Privacy)
ISO 14441: Security & privacy requirements of EHR systems
- This is a new work item. The initial reaction by both Bernd and I, both co-chairs of the HL7 Security WG, was to question why this work was being done when HL7 was already working on this as a sub-component of the EHR Functional Model.
- The members then showed us the work, and it is very impressive. They have incorporated input from many sources including EHR Functional Model, CCHIT, and elsewhere. They have done a complete cross-walk with regulations in 5 countries including USA, Russia, Brazil, and Europe.
- They have a cross walk with the major IT Security standard, ISO 15408 Common Criteria.
- The result is a set of 18 categories of security and privacy functionality with less than 60 total requirements. Many of these carrying the original wording from the source material.
- The work item plan was to have a second part that focused on the needs of small EHR. The members concluded that on the scope of privacy and security functionality there was no difference between large or small. Thus the second part will not be worked on.
- I then observed that this work is more mature than the EHR Functional Model, and that we need to harmonize the two works together. The EHR Functional Model will ultimately be dual balloted with ISO, so the harmonization is critical. I worked with the co-chairs of the EHR Functional model that were also present at the meeting. The hard part is that both works are undergoing ballot at the same time. The plan that I worked out is to pull all of the ISO 14441 into the EHR Functional Model, replacing the criteria in the EHR Functional Model today. Make sure that the comments already registered with the EHR Functional Model are still handled. As part of this the criteria in ISO 14441 will need to be reworded as the format of the EHR Functional Model is specific to enable their profiling. Ballots on both works will be resolved in harmony, resulting in a single set of criteria. Where the EHR Functional Model points at the ISO 14441 for details and cross-walk.
- There was discussion of a new proposal to address Patient Consent.
- Bernd and I both commented regarding the good and existing work in HL7 on consent including the Privacy/Security DAM, CDA Consent Directive, confidentialityCode vocabulary, and the work on Ontology.
- There was much discussion of the role of IHE BPPC, the HL7 CDA Consent Directive, and future work. Many people don't understand that the HL7 work starts from the IHE BPPC and enhances it. I need to blog about this.
- The work item will focus mostly on the high level guidance and point at HL7 for the normative aspects. Although it is not clear that this is fully agreed to. This will require much monitoring to prevent overlap.
- The workgroup was significantly out of date regarding the concepts that have been learned regarding this space. It is not clear to me that the group contains subject matter expertise to support this item.
- I think this NWIP proposal will go forward. If it can be kept in harmony with HL7, then it can be a good thing
- There is a new work item proposed to address Healthcare needs for Digital Signature. The work is being added as a new part on the Digital Certificates family. The work needs to be kept specific to the healthcare needs. It should be focused on pointing at ETSI for the Digital Signature specifics (XaDES is the XML profile).
- I recommended that they look to harmonize with the IHE Digital Signature Profile. This profile recognized that there is only a few things that need to be profiled given the underlying standards of XML-Signature and XaDES; the format of the date/time and a mechanism to hold the signature purpose. With the signature purpose vocabulary being specific to healthcare.
- The work is now sourced out of Canada, where they are still struggling to get their regulators to recognize software as a medical device. This is in direct contrast to the FDA that has come out with specific guidance on software and even mobile applications.
- The work is trying to be more open to discussion and input. They do now recognize the problems that vendors would have if they were forced to use two different processes for developing health software.
- There is formal requests to make this a joint work with IEC 62A. Which is the group that normally deals with Safety.
- I would like this work to be risk based and recognize risks to Safety as well as Security and Effectivity. This is the scope that IEC 80001 took, and it works out good for things that need to be integrated at the operational level.
- There was not much discussion of this work item. It is attempting to take a high level view of the needs and the available standards to support those needs.
- The work item has failed ballot due to lack of subject matter experts. I think the problem is that the work item is simply too grandiose.
- The USA has and continues to ignore this work. We, at best, look to WEDI for a standard format for printed and magnetic stripe.
- Common is a desire to keep these health cards to mostly identifiers
- There continues to be some that think it would be useful to put data on these cards. The committee members are very much against this as it presents security and privacy concerns, and also raises the question of freshness of the data. As evidence of this, they are looking for experts to work on a new part that would define the data. No experts are coming forward.
- This work items started a long time ago, and has been moving very slowly. Presented this week was the struggle with defining what an EHR is. This struggle must recognize the various deployment models including classic client/server, n-tier, software as a service, etc.
- I have strong concerns with this work item. I don’t see there being a possible thing to abstract enough for ISO to write a good Technical Report on. The aspects of ‘migration’ are simply too specific to the instance.
- There is no clear defining line where something goes from a software upgrade to a ‘migration’. They have put out of scope the case of backup with recovery.
- Unfortunately this work is already underway so it now must conclude in something.
- This is the regular review of this existing specification. There have been significant updates that are considered positive changes. The essence of the specification is not changed. Most of the changes are editorial or to update the text to modern terminology.
- This is the regular review of this existing specification. The problem the committee has is that this work was originally written before IEC 27001 was final. Healthcare received a number in the 27000 family expecting this move. Now the work item needs to be reformatted and changed to reference the IEC 27000 family rather than the 17799.
- No significant changes beyond reformatting are expected.
- This work was up for review, and received very little requests to change it. There was indicated much support for it globally. This is also included in the IHE HPD, although not completely.
- This work was up for review, and received very little requests to change it. The main things were some issues around mandatory fields. Experience has shown that there is resistance to some of the items that were considered mandatory. The changes are all reasonable.
- This proposal was hard to understand what was being proposed as a work item. I think that it is well beyond the scope of a standards organization. There is plenty of this kind of education available. I think the request is to put together one set of training.
- I don’t see how this can be done on an international level and be successful.
- This is the work to formalize the ATNA use within EHR.
- It is awaiting going out for second DIS ballot
- The work item was not discussed.
I was very happy with the results of the 2 days I participated. This was far more productive than ISO meetings in the past. I would still like to see more participation from subject matter experts, the membership tends to be the same people from academia. This is mostly an effect of the way that ISO operates. It is so frustrating to have this country focused model, where all of the USA gets one vote equal to even the smallest and undeveloped country.
Friday, October 21, 2011
e-Patient Dave asks Is “Gimme my damn data” coming to radiology at last??
Radiology (all modalities of Imaging) have had many ways to provide patients with their Damn data. The CD that e-Patient Dave refer to is an example that is heavily used. It is not clear from e-Patient Dave's post if the CD he is given is "DICOM Compliant", if it was then the viewer on the CD is not the only viewer available. There are many DICOM viewers you could use. Further these are full DICOM objects so they can be imported into a PACS or even HealthVault. Where they can be fully manipulated by those tools.
IHE has profile of this Portable Data for Imaging (PDI) This profile is compatible for the wider profile for any Documents on media Cross-Enterprise Document Media Interchange (XDM)
Which is the profile recommended to be used to carry content by the Direct Project.
Thus, the whole space of Healthcare Information can be put on interoperable media and provided to the patient on removable media or e-Mail.
Note that there are equivilant and compatible solutions for a local Health Information Exchange (XDS), and NationWide Health Information Exchange (XCA).
All using the same document, and same metadata, and fully specified for Privacy and Security. What is lacking is the Mandate -- the "Damn" part of the story.
Friday, October 14, 2011
- Innovative implementation of the SAFE-BioPharma standard
- Innovative product compliance
- For a vendor partner compliant product
- Individual who has contributed to standard's use and advancement
- Regulatory advances
- New advances in regulatory acceptance
- Global expansion
- Use of standard globally or regionally
- Journalistic reporting
- For advancing understanding and use of the standard
SAFE-BioPharma is the global industry standard for digital trust. It was developed by a non-profit consortium of biopharmaceutical and related companies to transition the biopharmaceutical and health care communities to paperless environments. For more information visit: http://www.safe-biopharma.org
The background on the core IEC 80001 was the topic of two webinars about a year ago. These webinars were recorded and are still very good today. I highly recommend that you review them.
- Help is Just Around the Corner: Guidance on implementing IEC 80001
- Learn how to prepare for risk management of medical devices on an IT network, including where to find the standard and its supporting technical reports, what is in the 4 technical reports and how to use them. Learn also how to perform a risk assessment for a medical device using the technical reports as a guide.
- A World of Increasing Challenges: ISO 80001 and Medical Device Networking integration into Electronic Medical Records.
- Overview of the pending ISO/IEC 80001 standard requirements from one of the IEC committee members. Considerations for Medical Device Networking integration into Electronic Medical Records.
- IEC 80001 Guidance for Wireless Medical IT Networks - October 19, 2011 2pm-3pm EST
- This session will provide guidance regarding wireless networks for organizations just beginning to implement the risk management process required by IEC 80001-1. It will provide guidance on Planning & Design, Deployment & Configuration, Management & Support, and Risk Mitigation techniques.
- Step by Step Risk Management of Medical IT-Networks; Practical Applications and Examples - November 16, 2011 2pm-3pm EST
- This session will will provide step-by-step information for organizations just beginning to implement the risk management process required by IEC 80001-1. It will provide guidance in the form of a study of risk management terms, risk management steps, an explanation of each step, step-by-step examples, templates, and lists of hazards and causes to consider.
Thursday, October 13, 2011
The unfinished business is
- Completion of the De-Identification cookbook – This is instructions to other IHE domains on how to create profiles that use anonymization and pseudonymization tools.
- Create a Cross-Enterprise Workflow (XDW) training package and assist other domains with the creation of their specific workflow that uses this infrastructure profile.
- And the normal documentation maintenance including change proposals, wiki, and profile lifecycle management.
- Critical and Important Results – This is a white paper proposal to expand on the need to notify someone when something critical or important is uncovered. The idea is that when something critical or important is discovered, one needs to discover who should be told about this information and how should they be told. This seems to me to be something similar to how we expect PWP or HPD to be used, but with more deterministic results.
- Patient Encounter Tracking Query – This is a profile proposal to address the need to have a system where actors that know where a patient is can record the location, so that others that want to find the patient can discover their location. This might be automated with things like RFID, might be automated through registration desk activities, or might be manual. The profile proposal looks to leverage the PAM and PDQ profiles.
- Configuration Management for Small Devices – This is a white paper effort to explore the area of configuration management in a very broad way. The expectation is that this white paper could point at common solutions from general IT (like LDAP, DHCP, DNS) for some problems that are not healthcare specific, while identifying gaps that are specific to Healthcare. These gaps could then be proposed as work items next year.
- Fix XD* Technical Framework – This a project to fixup the current documentation around the XD* family of profiles. There are a well-known list of things that people who come at IHE for the first time can’t find. These things tend to be things that the long standing members simply assume are documented. This realization comes through Bill’s experience with the Connectathon test tools development and assisting individuals with their development efforts. This item seems to always be outstanding, but we must take it on as a top priority and get it done, well better. The result MUST not change any normative meaning. This is simply reforming the documentation so that it is more readable and understandable.
- Document Access for mHealth – This is the project that Keith (and I) submitted. The proposal today is mostly identifying the constrained environment that is most prevalent on mobile devices (phones, tablets, etc) but which exists in other places. This constrained environment has troubles with the SOAP stack used in the XDS/XCA environment, and also find the ebRIM encoded metadata harder to manipulate. The proposal is thus to come up with an interface (SOA like) that an organization can offer to their users that is more attractive to these developers and thus will drive for Apps that might be more reusable across organizations.
Critical & Important Results
Patient Encounter Tracking Query
Config Mgmt for Small Devices
Fix XD* Technical Framework
Document Access for mHealth
Workload Size Estimate
The significance and urgency of the interoperability problem in the business of healthcare?
low 1 - 5 high
Benefit to global community
low 1 - 5 high
Degree of expected adoption (for WP relates to use of the content)
low 1 - 5 high
Alignment with IHE development domains outside of ITI
low 1 - 5 high
Alignment with internal responsibilities of ITI
low 1 - 5 high
There was a priortization step, but it resulted in mostly the same outcome as the above evaluation.
The Technical Committee meets next month. Their task at that time is to determine the feasibility of these work items, dig deeper on the available standards, assess more strongly the size estimates, and make sure that resources are lined up and ready to execute. The result is a joint meeting of the Technical and Planning committee to decide on what actually will be worked on next year. The capacity estimate we guessed at during the start of the meeting seems like it might fit all this content. I worry about that as we always increase scope on work items, and then end up with poor quality and missed deadlines.
Between now and the next meeting, Keith and I must do a better job of explaining the scope of our mHealth proposal. For example does it support both query/retrieve and Create? Is it a Cross-Enterprise profile, or one that we only assess as a last-mile API that an organization hosts for their users? Of the XDS queries, which ones are needed and how constrained can those be? How much can we off-load to the Service as the Client really doesn't need to be bothered? What might the metadata encoding simplification look like? What technologies are in scope? What deployment scopes can be placed on profile? How will privacy and security be handled? Keith got a good start on this in an email.
The planning committee is responsible for other things, such as education and outreach. In this spacethere is some really good progress. The first white paper is critical, there isn't much to look at today but we are working hard to make it highly useful.
- White Paper on how to use the IHE Profiles to share documents
- Educational presentation content and webinars
- Wiki profile descriptions
- Preparation for meeting at HIMSS
- Assess other opportunities for communicating about ITI work