Noah Mobile API – Procedure
|
With Noah Mobile Apps the HIMSA certification process is mandatory for each App version. HIMSA will be involved with validation testing in some cases but not all.
As can be seen on the far left hand side of the flow chart the process for the first version of the App is process just as it is for modules (see flow chart above). This is called the Full Test Track. The major difference for apps is that after the first version the App will be eligible to participate in the fast track path. With the fast track the app is still required to complete and successfully pass the test as defined by HIMSA. The test results must be documented, test report signed, and the app must then be made available to HIMSA.
HIMSA will not plan on performing any test steps for this version but will simply review the test steps and report for proper completion.
If HIMSA is satisfied with the materials submitted HIMSA will grant certification and publicly list this version as certified. The test documents and signed report will also be available on himsa.com for any user wishing to review the details.
HIMSA will make the app available to other members for testing and troubleshooting purposes.
The fast track process then may continue as long as possible; see more details below. |
Q: Does the App developer need to complete a report and test steps for each version?
A: Yes. However, the number of test steps will be greatly reduced. For Fast Track testing the actual test steps performed will focus on critical items (e.g. how the app handled data). The fast track test will skip some test steps deemed by HIMSA to be lower in risk of breaking after verifying that they worked in a previous version, or if they did break they would be of a less critical nature. If the App developer takes advantage of not performing these steps then the developer is agreeing that they have not changed their interface code dealing with this feature. If an optional test was not performed in version 1.0 because the feature was not supported by the App and then version 1.1 did support the feature, the app developer must complete the test step during the Fast Track test.
Q: How will HIMSA make an App available to other companies if it is only available via an online store (e.g. iOS store)?
A: HIMSA will not in this case. Additionally there may be cases where the app is available only in an online type of system (e.g. a browser). In this case the App developer will need to create a test account that can be used by HIMSA and other member companies.
Q: How often can an App be eligible to use the fast track certification process?
A: As of October 2015 the current plan is as follows:
As long as HIMSA is not aware of any test reports that contain false or incorrect data that would result in a critical issue.
After a successful certification that HIMSA is involved with validation testing the app may utilize the fast track for 5 subsequent versions of the app.
Not eligible:
A critical issue was found in a previously certified version and reported to HIMSA after certification was granted (e.g. an unforeseen problem reported from the field).
Q: What constitutes a new version for an App?
A: Each new version (build) must be uniquely labeled and will be considered a new version in terms of the certification process requirements. It is acceptable for an app to update resource files (e.g. graphic, text) that do not affect the executing code. If only resource files are updated then the member company will need to alert HIMSA in writing as to the update.
Further, a version will also be considered separate if there are more than one other related product, such as a similar product but created for a different OS and which constitutes different code or processes to deliver the features. For example version 1 for iOS and Version 1 for Android would be considered two separate versions.
How “Version” is defined
HIMSA has received some feedback from some of the members of the certification committee in regards to tying this to a “version”. The main concern is that some Apps may be designed where much of the software exits not in the App but rather in another back end distributed system(s). In these cases the App would be more of a GUI front end and the “real work” would not be performed in the front end but rather the back end.
In these cases it seems unreasonable and unnecessary for HIMSA to become overly concerned with what occurs in the back end. As long as the front end integration code to Noah mobile is versioned then that is the most that HIMSA needs to be concerned with.
For example, in the Noah Mobile user story 1.03, a scenario is presented where a web browser based order site is used so that the order web site can obtain a patients audiogram and at the end of the order, save back an action to Noah indicating that an order has been placed. In the case of an order web site HIMSA is aware that the order backend system will most likely change almost every day as the manufacturer has to change option choices and current configuration changes. But, it is also fair to assume that the integration code to Noah will not need to change unless there is a bug to fix or a newer feature to incorporate.
To address this issue HIMSA will require that the web site make an appropriate choice where a typical HCP could have the ability to see what the version of the Noah Mobile integration code is. For example, using the example above, the web site might have a GUI choice “read patient data from Noah” or “Connect to my Noah”, when selecting this the HCP would be directed to functionality that shows Noah related functionality (e.g. GUI to select the correct patient in Noah). In this GUI area the version of the Noah integration software must be listed somewhere.
Q: Does HIMSA charge for verification testing time and for administration work related to the certification of Apps?
A: Yes. Each licensee receives 16 hours of HIMSA certification testing time that be used towards module or App certifications.
Q: Can a member company request HIMSA to perform app validation testing even if it is not required?
A: Yes.
Q: Can Noah compatible modules utilize the fast track process?
A: At this time HIMSA is not offering this choice but in the future will examine the possibility further. The reasons are as follows:
As certification is mandatory per app version HIMSA must be ready to have the policy documented and agreed by the time the first app is ready to be released. At this time HIMSA has not been informed when a member company will be ready but HIMSA will need to be ready at the release of Noah 4.5 as this is the first release of Noah supporting the Noah mobile API
The design of Noah mobile provides an environment where the risk of an App creating a critical issue, as compared to a Noah compatible module or business system, is greatly reduced. For example: If a fitting module crashes it may leave Noah in a state where Noah still thinks the module is open and Noah will not allow another fitting module to open. If a fitting App crashes it cannot effect Noah in a similar fashion as there are no rules with Noah mobile about how many fitting modules can be open.
Q: Can a member ask HIMSA to just perform a test for a company without a release to end users, such as a test run?
A: Yes.
Q: Today in the marketplace there are a lot of hardware solutions that run customized versions of Android OS that could create issues for a specific NOAH compatible app (e.g. the app runs fine on a Samsung Tablet but will hang on a “xyz” tablet). How is the certification done for a specific mobile hardware since there are so many mobile solutions (some hardware solutions are more expensive / more stable than others)? Is there going to be a specific set of mobile hardware/ form factor that will be used in the certification testing?
A: The HIMSA certification procedure will not be able to be involved with the hardware form factor. The main focus of the certification process is on how the app interacts with Noah.