Real World Test Plan

Claimpower Real World Testing Plan - 2025 Results

Developer Name: Claimpower, Inc

Product Name: Claimpower Mobile EMR

Version Number: 6.1

Certified Health IT Product List (CHPL) ID(s): 15.04.04.1238.Clai.06.02.1.230109

Developer Real World Testing Page URL: https://claimpower.com/real-world-test-plan/

Test Server Endpoint
FHIR : https://fhirserver.claimpower.com
Authentication Server: https://oauth.claimpower.com

Note: these are non-deployed capabilities, tested with synthetic user data in an environment mirroring production. See sample responses below in each section.

Types of Smart-On-FHIR applications

  • Standalone App : SMART on FHIR confidential client with a patient context, refresh token, and OpenID Connect (OIDC) identity
    token.
  • EHR Embedded app: Demonstrate the ability to perform an EHR launch to a SMART on FHIR
  • Smart Backend Services App (Multi-patient authorization and API) : These are server-to-server backend applications e.g. Export clinical data for multiple patients in a group. This app is system level app without any UI.

Types of Authentications supported

  • Symmetric (“client secret”) authentication (HL7.FHIR.UV.SMART-APP-LAUNCH\Example App Launch for Symmetric Client Auth - FHIR
    v4.0.1)
  • Asymmetric (“private key JWT”) authentication (HL7.FHIR.UV.SMART-APP-LAUNCH\Example App Launch for Asymmetric Client Auth
  • FHIR v4.0.1)
  • Public Clients (HL7.FHIR.UV.SMART-APP-LAUNCH\Example App Launch for Public Client - FHIR v4.0.1)

Steps for Smart App Launch
1. Client App Registration
2. Retrieve .well-known/smart-configuration
3. Obtain authorization code
4. Obtain access token
5. Access FHIR API
6. Refresh Token to obtain new access token

Client App Registration
Before a SMART app can run against an EHR, the app must be registered with that EHR’s authorization service. We are using OAuth 2.0 Client
Registration.

  • Third-party application must sign the API Subscription Agreement with following details
  • The app name
  • The necessary APIs / Scopes
  • Any redirect URIs
  • Launch_URL (optional)
  • URL to JWK Set (Only for apps supporting asymmetric client authentication).
  • The application is created by the EHR admin after confirming the app’s registration parameters and communicates a client_id to the
    app.
  • Only reads data from FHIR server

Retrieve .well-known/smart-configuration
In order to obtain launch context and request authorization to access FHIR resources, the app discovers the EHR FHIR server’s SMART
configuration metadata, including OAuth authorization_endpoint and token_endpoint URLs.
FHIR server makes SMART configuration available from well-known endpoint. You can get Authorization end point and token endpoint.

Request
GET 200 https://fhirserver.claimpower.com/r4/.well-known/smart-configuration

Response

{
"capabilities": [
"launch-ehr",
"launch-standalone",
"client-public",
"client-confidential-symmetric",
"sso-openid-connect",
"context-banner",
"context-style",
"context-ehr-patient",
"context-ehr-encounter",
"context-standalone-patient",
"context-standalone-encounter",
"permission-offline",
"permission-patient",
"permission-user"
],
"revocation_endpoint": "https://oauth.claimpower.com/outh/token/revoke-token",
"authorization_endpoint": "https://oauth.claimpower.com/outh/authorization",
"token_endpoint": "https://oauth.claimpower.com/outh/token"
}

Error codes
JSON response is returned from the FHIR Server along with the code
200: Ok
401: Unauthorized
400: Bad Request
500: Internal Server Error
Obtain authorization code
The app supplies the following parameters to the EHR’s “authorize” endpoint.

Parameter Requirement Description
response_type required Fixed value: code.
client_id required The client's identifier.
redirect_uri required Must match one of the client's pre-registered redirect URIs.
launch conditional When using the EHR Launch flow, this must match the launch value received from the EHR. Omitted when using the Standalone Launch
scope required Must describe the access that the app needs, including scopes like patient/*.rs, openid and fhirUser (if app needs authenticated patient identity) and either:
• a launch value indicating that the app wants to receive already-established launch context details from the EHR
• a set of launch context requirements in the form launch/patient, which asks the EHR to establish context on your behalf.
Please refer to the scopes supported in the section below
state required An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHALL be used for preventing cross-site request forgery or session fixation attacks. The app SHALL use an unpredictable value for the state parameter with at least
122 bits of entropy (e.g., a properly configured random uuid is suitable).
aud required URL of the EHR resource server from which the app wishes to retrieve FHIR data. This parameter prevents leaking a genuine bearer token to a counterfeit resource server. (Note that in the case of an EHR launch flow, this aud value is the same as the launch's iss value.) Note that the aud parameter is semantically equivalent to the resource parameter defined in RFC8707.
SMART's aud parameter predates RFC8707 and we have decided not to rename it for reasons of backwards compatibility.
We might consider renaming SMART's aud parameter in the future if implementer feedback indicates that alignment would be valuable. For the current release, servers SHALL support the aud parameter and MAY support a resource parameter as a synonym for aud.

 

Scope Grants
patient/*.read Permission to read and search any resource for the current patient (see notes on wildcard scopes below).
user/*.read Permission to read and write all resources that the current user can access (see notes on wildcard scopes below).
openid, fhirUser Permission to retrieve information about the current logged-in user.
launch Permission to obtain launch context when app is launched from an EHR.
launch/patient When launching outside the EHR, ask for a patient to be selected at launch time.
offline_access Request a refresh_token that can be used to obtain a new access token to replace an expired one, even after the end-user no longer is online after the access token expires.

Here's an example of an authorization request using HTTP GET. You will replace the [redirect_uri], [client_id], [launch_token], [state], [code_challenge], and [audience] placeholders with your own values.

Request

https://ehr/authorize?
response_type=code&
client_id=app-client-id&
redirect_uri=https%3A%2F%2Fapp%2Fafter-auth&
launch=xyz123&
scope=launch+patient%2FObservation.rs+patient%2FPatient.rs+openid+fhirUser&
state=98wrghuwuogerg97&
aud=https://ehr/fhir

Response
The EHR's authorization server reviews the request from your application. If approved, the authorization server redirects the browser to the
redirect URL supplied in the initial request and appends the following querystring parameter.
• code: This parameter contains the authorization code generated by EHR, which will be exchanged for the access token in the next step.
• state: The exact value received from the client.

Example request URL:

https://oauth.claimpower.com/outh/authorization?response_type=code&client_id=SAMPLE_CONFIDENTIAL_CLIENT_ID&redirect_uri=https%3
A%2F%2Finferno.healthit.gov%2Finferno%2Foauth2%2Fstatic%2Fredirect&scope=launch%2Fpatient+openid+fhirUser+offline_access+patient%
2FMedication.read+patient%2FAllergyIntolerance.read+patient%2FCarePlan.read+patient%2FCareTeam.read+patient%2FCondition.read+patie
nt%2FDevice.read+patient%2FDiagnosticReport.read+patient%2FDocumentReference.read+patient%2FEncounter.read+patient%2FGoal.read+
patient%2FImmunization.read+patient%2FLocation.read+patient%2FMedicationRequest.read+patient%2FObservation.read+patient%2FOrgani
zation.read+patient%2FPatient.read+patient%2FPractitioner.read+patient%2FProcedure.read+patient%2FProvenance.read+patient%2FPractiti
onerRole.read&state=26a45e37-7445-4e4a-b8fb-24144eccbdc4&aud=https%3A%2F%2Finferno.healthit.gov%2Freference-server%2Fr4

Example response URL (Location: https://app/after-auth?code=123abc&state=98wrghuwuogerg97):

https://inferno.healthit.gov/inferno/oauth2/static/redirect?code=SAMPLE_CODE.bGF1bmNoL3BhdGllbnQgb3BlbmlkIGZoaXJVc2VyIG9mZmxpbmVfYWNjZXNzIHBhdGllbnQvTWVkaWNhdGlvbi5yZWFkIHBhdGllbnQvQWxsZXJneUludG9sZXJhbmNlLnJlYWQgcGF0aWVudC9DYXJlUGxhbi5yZWFkIHBhdGllbnQvQ2FyZVRlYW0ucmVhZCBwYXRpZW50L0NvbmRpdGlvbi5yZWFkIHBhdGllbnQvRGV2aWNlLnJlYWQgcGF0aWVudC9EaWFnbm9zdGljUmVwb3J0LnJlYWQgcGF0aWVudC9Eb2N1bWVudFJlZmVyZW5jZS5yZWFkIHBhdGllbnQvRW5jb3VudGVyLnJlYWQgcGF0aWVudC9Hb2FsLnJlYWQgcGF0aWVudC9JbW11bml6YXRpb24ucmVhZCBwYXRpZW50L0xvY2F0aW9uLnJlYWQgcGF0aWVudC9NZWRpY2F0aW9uUmVxdWVzdC5yZWFkIHBhdGllbnQvT2JzZXJ2YXRpb24ucmVhZCBwYXRpZW50L09yZ2FuaXphdGlvbi5yZWFkIHBhdGllbnQvUGF0aWVudC5yZWFkIHBhdGllbnQvUHJhY3RpdGlvbmVyLnJlYWQgcGF0aWVudC9Qcm9jZWR1cmUucmVhZCBwYXRpZW50L1Byb3ZlbmFuY2UucmVhZCBwYXRpZW50L1ByYWN0aXRpb25lclJvbGUucmVhZCA=.ODU=&state=26a45e37-7445-4e4a-b8fb-24144eccbdc4

After receiving the authorization code, your application trades the code for a JSON object containing an access token and contextual information by sending an HTTP POST to the token endpoint using a Content-Type header with value of "application/x-www-form-urlencoded".

Error codes

JSON response is returned from the FHIR Server along with the code
200: Ok
401: Unauthorized
400: Bad Request
500: Internal Server Error

Parameter Requirement Description
grant_type required Fixed value: authorization_code for symmetric and client_credentials for assymetric
Code required Code that the app received from the authorization server
redirect_uri required The same redirect_uri used in the initial authorization request
client_id conditional Required for public apps. Omit for confidential apps.
client_assertion_type conditional Required for asymmetric authentication. set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion conditional Required for asymmetric authentication. set to a JWT signed with your dynamic client's private key
Scope conditional system/*.read for backend services type of application (bulk operations)

Symmetric Authentication Request

https://oauth.claimpower.com/outh/token

Payload

grant_type=authorization_code&code=SAMPLE_CODE.bGF1bmNoL3BhdGllbnQgb3BlbmlkIGZoaXJVc2VyIG9mZmxpbmVfYWNjZXNzIHBhdGllbn
QvTWVkaWNhdGlvbi5yZWFkIHBhdGllbnQvQWxsZXJneUludG9sZXJhbmNlLnJlYWQgcGF0aWVudC9DYXJlUGxhbi5yZWFkIHBhdGllbnQvQ2FyZVRlY
W0ucmVhZCBwYXRpZW50L0NvbmRpdGlvbi5yZWFkIHBhdGllbnQvRGV2aWNlLnJlYWQgcGF0aWVudC9EaWFnbm9zdGljUmVwb3J0LnJlYWQgcGF
0aWVudC9Eb2N1bWVudFJlZmVyZW5jZS5yZWFkIHBhdGllbnQvRW5jb3VudGVyLnJlYWQgcGF0aWVudC9Hb2FsLnJlYWQgcGF0aWVudC9JbW11b
ml6YXRpb24ucmVhZCBwYXRpZW50L0xvY2F0aW9uLnJlYWQgcGF0aWVudC9NZWRpY2F0aW9uUmVxdWVzdC5yZWFkIHBhdGllbnQvT2JzZXJ2YXR
pb24ucmVhZCBwYXRpZW50L09yZ2FuaXphdGlvbi5yZWFkIHBhdGllbnQvUGF0aWVudC5yZWFkIHBhdGllbnQvUHJhY3RpdGlvbmVyLnJlYWQgcGF0
aWVudC9Qcm9jZWR1cmUucmVhZCBwYXRpZW50L1Byb3ZlbmFuY2UucmVhZCBwYXRpZW50L1ByYWN0aXRpb25lclJvbGUucmVhZCA%3D.ODU%
3D&redirect_uri=https%3A%2F%2Finferno.healthit.gov%2Finferno%2Foauth2%2Fstatic%2Fredirect

In case of Asymmetric authentication:

Request

client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzM4NCIsImtpZCI6IjRiNDlhNzM5ZDFlYjExNWIzMjI1ZjRjZjliZWI2ZDFiIn0.eyJpc3MiOiJleUpoYkdja
U9pSklVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXRwWkNJNkluSmxaMmx6ZEhKaGRHbHZiaTEwYjJ0bGJpSjkuZXlKcWQydHpYM1Z5YkNJNkltaDBk
SEE2THk4eE1DNHhOUzR5TlRJdU56TXZhVzVtWlhKdWJ5OHVkMlZzYkMxcmJtOTNiaTlxZDJ0ekxtcHpiMjRpTENKaFkyTmxjM05VYjJ0bGJuTkZlSEJwY
21WSmJpSTZNVFVzSW1saGRDSTZNVFU1TnpReE16RTVOWDAucTR2NE1zYzc0a041MDZLVFowcV9taW55YXBKdzBnd2xUNk1fdWlMNzNTNCIsInN
1YiI6ImV5SmhiR2NpT2lKSVV6STFOaUlzSW5SNWNDSTZJa3BYVkNJc0ltdHBaQ0k2SW5KbFoybHpkSEpoZEdsdmJpMTBiMnRsYmlKOS5leUpxZDJ0el
gzVnliQ0k2SW1oMGRIQTZMeTh4TUM0eE5TNHlOVEl1TnpNdmFXNW1aWEp1Ynk4dWQyVnNiQzFyYm05M2JpOXFkMnR6TG1wemIyNGlMQ0po
WTJObGMzTlViMnRsYm5ORmVIQnBjbVZKYmlJNk1UVXNJbWxoZENJNk1UVTVOelF4TXpFNU5YMC5xNHY0TXNjNzRrTjUwNktUWjBxX21pbnlhcEp
3MGd3bFQ2TV91aUw3M1M0IiwiYXVkIjoiaHR0cHM6Ly9pbmZlcm5vLmhlYWx0aGl0Lmdvdi9yZWZlcmVuY2Utc2VydmVyL29hdXRoL2J1bGstdG9r
ZW4iLCJleHAiOjE2NTMxMDY4ODgsImp0aSI6ImZmZjA5YjIxMjhiOWRmNmU3MGU5MWQ2ZDUwMGQxMmFmYmU2YWE4N2FhMjJlZjVhMjc5YjZ
hNTI0YzA0NmM1ZWEifQ.tlx7jIu9wn7QdHHdWyUMf9otY0r7eX62LuVF3kZOsjjw-CP-glqdbDtOKiuBQ9doduW4zyk3fs6k48XpAEQLsSXajfEJeDy9ujWdSmpAHEC0xYHQSzajekdwlDSBRA&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwtbearer&grant_type=client_credentials&scope=system%2F%2A.read

Response

The EHR authorization server SHALL return a JSON object that includes an access token or a message indicating that the authorization request
has been denied. The JSON structure includes the following parameters:

Parameter Requirement Description
access_token required The access token issued by the authorization server
token_type required Fixed value: Bearer
expires_in recommended Lifetime in seconds of the access token, after which the token SHALL NOT be accepted by the resource server
scope required Scope of access authorized. Note that this can be different from the scopes requested by the app.
id_token optional Authenticated user identity and user details, if requested
refresh_token optional Token that can be used to obtain a new access token, using the same or a subset of the original authorization grants

Sample response

{
"access_token": "3e934471-1dbf-4a69-8e1f-227f9fd65428",
"refresh_token": "31c4476d-6e9d-41a3-a272-065d05c3599d",
"patient": "85",
"scope": "launch/patient openid fhirUser offline_access patient/*.read ",
"need_patient_banner": false,
"id_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJkYjExNzk1Ny02MDU4LTRhODYtYTcxMi0yMDU2NDU5ZDUxMzgiLCJhdWQiOiJTQU1QTEVfQ
09ORklERU5USUFMX0NMSUVOVF9JRCIsImlzcyI6Imh0dHBzOi8vaW5mZXJuby5oZWFsdGhpdC5nb3YvcmVmZXJlbmNlLXNlcnZlci9yNCIsImV4cCI6
MTY4NDU3OTc5NywiaWF0IjoxNjUzMDQzNzk3LCJmaGlyVXNlciI6Imh0dHBzOi8vaW5mZXJuby5oZWFsdGhpdC5nb3YvcmVmZXJlbmNlLXNlcnZlci9
yNC9QYXRpZW50Lzg1In0.R1oMsXCTXMKiM1ohCxh3LkgXrgfBebNIaC_jam9sBOwYCCw7K4TLUBmVzKIGb3_-
5wZtqyTTqO6bRwsituXSefoS1QwI14wLGpk-fOsr6M4uSXW5An4WUy8858j3aa5Qkcf0pw4QP3-
rlmVJoHuN_In4ULn5bpRQJkllEQ2ySPj3pkoWWMwfij5p7nNfvwgkE2QOCM4Q-ounE6oLyYZJp_OGvVhkREu8jO77m3Tgsji_jbX7g4-
deuwB4F9EHUfpjfhM3TB1GIoQ7cgJFhHOs9mTCcpT0aYYQkmCJGRx1R5jI-I56p4_63IkU2BRau-INII3Zvcnsz5ajpvU46eIwg",
"smart_style_url": "https://oauth.claimpower.com/app/smart-style-url",
"token_type": "bearer",
"expires_in": 3600
}

Error codes

JSON response is returned from the FHIR Server along with the code
200: Ok
401: Unauthorized
400: Bad Request
500: Internal Server Error

At this point, the authorization flow is complete.


Request : Patient

Search Parameters

_id: GET [Base_URL]/Patient/_search?Patient=[id]
Identifier : GET [Base_URL]/Patient?identifier={system|}[code]
Name: GET [Base_URL]/Patient?name=[string]
birthdate + name :GET [Base_URL]/Patient?birthdate=[date]&name=[string]
gender + name : GET [Base_URL]/Patient?gender={system|}[code]&name=[string]

Response

US Core Patient Profile as specified in the US Core v3.1.1 Implementation Guide

Code: 200 (Success)

 {
"resourceType": "Bundle",
"id": "6f1d6f2d-c42b-453b-8f5a-8d74c24f6fb6",
"type": "searchset",
"total": 1,
"link": [
{
"relation": "self",
"url": "https://FHIR-Base-URL/api/v4/Patient?_count=10&_id=17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b&_page=1"
}
],
"entry": [
{
"id": "17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b",
"fullUrl": "https://FHIR-Base-URL/api/v4/Patient/17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b",
"resource": {
"resourceType": "Patient",
"id": "17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b",
"meta": {
"versionId": "3",
"lastUpdated": "2022-03-24T10:50:49.231Z",
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
]
},
"text": {
"status": "generated",
"div": "
Generated by Synthea.Version identifier: v2.6.1-3-g50f4f58f\n . Person seed:
4286870567281389426 Population seed: 3
"
},
"extension": [
{
"extension": [
{
"url": "ombCategory",
"valueCoding": {
"system": "urn:oid:2.16.840.1.113883.6.238",
"code": "2106-3",
"display": "White"
}
},
{
"url": "text",
"valueString": "White"
}
],
"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-race"
},
{
"extension": [
{
"url": "ombCategory",
"valueCoding": {
"system": "urn:oid:2.16.840.1.113883.6.238",
"code": "2186-5",
"display": "Non Hispanic or Latino"
}
},
{
"url": "text",
"valueString": "Non Hispanic or Latino"
}
],
"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity"
},
{
"url": "http://hl7.org/fhir/StructureDefinition/patient-mothersMaidenName",
"valueString": "Christen366 Murray856"
},
{
"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex",
"valueCode": "M"
},
{
"url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace",
"valueAddress": {
"city": "Springfield",
"state": "Massachusetts",
"country": "US"
}
}
],
"identifier": [
{
"system": "https://github.com/synthetichealth/synthea",
"value": "e91975f5-9445-c11f-cabf-c3c6dae161f2"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "MR",
"display": "Medical Record Number"
}
],
"text": "Medical Record Number"
},
"system": "http://hospital.smarthealthit.org",
"value": "e91975f5-9445-c11f-cabf-c3c6dae161f2"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "SS",
"display": "Social Security Number"
}
],
"text": "Social Security Number"
},
"system": "http://hl7.org/fhir/sid/us-ssn",
"value": "999-61-9798"
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "DL",
"display": "Driver's License"
}
],
"text": "Driver's License"
},
"system": "urn:oid:2.16.840.1.113883.4.3.25",
"value": "S99940282"
}
],
"name": [
{
"use": "official",
"family": "Harry",
"given": [
"Tom"
],
"prefix": [
"Mr."
],
"suffix": [
"Jr."
]
},
{
"use": "maiden",
"given": [
"Alex"
]
}
],
"telecom": [
{
"system": "phone",
"value": "555-770-2787",
"use": "home"
}
],
"gender": "male",
"birthDate": "1941-09-05",
"address": [
{
"extension": [
{
"extension": [
{
"url": "latitude",
"valueDecimal": 42.1343534042923
},
{
"url": "longitude",
"valueDecimal": -72.67217549422628
}
],
"url": "http://hl7.org/fhir/StructureDefinition/geolocation"
}
],
"line": [
"599 Schowalter Promenade"
],
"city": "West Springfield",
"state": "MA",
"postalCode": "01089",
"country": "US",
"period": {
"start": "1940-09-05"
}
}
],
"maritalStatus": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-MaritalStatus",
"code": "M",
"display": "M"
}
],
"text": "M"
},
"multipleBirthBoolean": false,
"communication": [
{
"language": {
"coding": [
{
"system": "urn:ietf:bcp:47",
"code": "en-US",
"display": "English"
}
],
"text": "English"
}
}
]
},
"search": {
"mode": "match",
"score": 1
}
}
]
}

Request : CarePlan

GET [Base_URL]/AllergyIntolerance?CarePlan=assess-plan&patient=[id]
e.g. https://[Base_URL]/CarePlan?category=assess-plan&patient=17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b

Response

Each resource returned from the first search is expected to conform to the US Core CarePlan Profile.
Code: 200 (Success)

{
"resourceType": "Bundle",
"id": "79d7a78e-de9b-4c5c-b51d-45b72963ae1f",
"type": "searchset",
"total": 1,
"link": [
{
"relation": "self",
"url": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/CarePlan?_count=10&category=assessplan&patient=Patient/17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b&_page=1"
}
],
"entry": [
{
"id": "17e776e13ff-1ea7505d-f475-4f49-adde-30e69df86734",
"fullUrl": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/CarePlan/17e776e13ff-1ea7505d-f475-4f49-adde-30e69df86734",
"resource": {
"resourceType": "CarePlan",
"id": "17e776e13ff-1ea7505d-f475-4f49-adde-30e69df86734",
"meta": {
"versionId": "2",
"lastUpdated": "2022-01-21T10:56:06.304Z",
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-careplan"
]
},
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Care Plan for Fracture care.<br/>Activities: <ul><li>Fracture care</li><li>Fracture
care</li></ul><br/>Care plan is meant to treat Fracture of clavicle.</div>"
},
"status": "active",
"intent": "order",
"category": [
{
"coding": [
{
"system": "http://hl7.org/fhir/us/core/CodeSystem/careplan-category",
"code": "assess-plan"
}
]
},
{
"coding": [
{
"system": "http://snomed.info/sct",
"code": "384758001",
"display": "Self-care interventions (procedure)"
}
],
"text": "Self-care interventions (procedure)"
}
],
"subject": {
"reference": "Patient/17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b"
},
"encounter": {
"reference": "Encounter/17e77566282-0c9c236b-f0bd-45e0-9c61-80991a376967"
},
"period": {
"start": "1941-10-02T18:33:18-05:00"
},
"careTeam": [
{
"reference": "CareTeam/17e775e7546-36e6a4cd-264e-4a94-92fa-cdf1b2fa30c1"
}
],
"activity": [
{
"detail": {
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "409002",
"display": "Food allergy diet"
}
],
"text": "Food allergy diet"
},
"status": "in-progress",
"location": {
"reference": "Location/17e7750e68f-6266aec8-0cd3-443e-adb9-be37f3bf25f2",
"display": "HOLYOKE MEDICAL CENTER"
}
}
},
{
"detail": {
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "58332002",
"display": "Allergy education"
}
],
"text": "Allergy education"
},
"status": "in-progress",
"location": {
"reference": "Location/17e7750e68f-6266aec8-0cd3-443e-adb9-be37f3bf25f2",
"display": "HOLYOKE MEDICAL CENTER"
}
}
},
{
"detail": {
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "58332002",
"display": "Allergy education"
}
],
"text": "Allergy education"
},
"status": "in-progress",
"location": {
"reference": "Location/17e7750e68f-6266aec8-0cd3-443e-adb9-be37f3bf25f2",
"display": "HOLYOKE MEDICAL CENTER"
}
}
}
]
},
"search": {
"mode": "match",
"score": 1
}
}
]
}

Request: Problems / Health Concern

Search Parameters

GET [base]/Condition?patient=[id]&category={system|}[code]
GET [base]/Condition?patient=[id]&category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item
GET [base]/Condition?patient=[id]&category=http://hl7.org/fhir/us/core/CodeSystem/condition-category|health-concern
GET [base]/Condition?patient=[id]&category=http://terminology.hl7.org/CodeSystem/condition-category|encounter-diagnosis
e.g [Base_URL]/Condition?patient=17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b&category=http://hl7.org/fhir/us/core/CodeSystem/condition-category|health-concern

Response
Each resource returned from the first search is expected to conform to the US Core Condition Profile
Code: 200 (Success)

{
"resourceType": "Bundle",
"id": "f537c30e-fab7-45f0-8167-4ab7a48386ec",
"type": "searchset",
"total": 2,
"link": [
{
"relation": "self",
"url": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/Condition?_count=10&patient=17e77411359-8837d878-ea1e-45b5-
bb89-882fdfb2be4b&_page=1"
}
],
"entry": [
{
"id": "17e7777ce8c-c66752fb-ee1b-40c2-ba5a-2e6ee89b3e1a",
"fullUrl": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/Condition/17e7777ce8c-c66752fb-ee1b-40c2-ba5a-2e6ee89b3e1a",
"resource": {
"resourceType": "Condition",
"id": "17e7777ce8c-c66752fb-ee1b-40c2-ba5a-2e6ee89b3e1a",
"meta": {
"versionId": "1",
"lastUpdated": "2022-01-20T12:30:47.436Z",
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition"
]
},
"clinicalStatus": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
"code": "resolved"
}
]
},
"verificationStatus": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
"code": "confirmed"
}
]
},
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/condition-category",
"code": "encounter-diagnosis",
"display": "Encounter Diagnosis"
}
]
}
],
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "444814009",
"display": "Viral sinusitis (disorder)"
}
],
"text": "Viral sinusitis (disorder)"
},
"subject": {
"reference": "Patient/17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b"
},
"encounter": {
"reference": "Encounter/17e77566282-0c9c236b-f0bd-45e0-9c61-80991a376967"
},
"onsetDateTime": "1940-11-09T18:33:18-05:00",
"abatementDateTime": "1940-11-30T18:33:18-05:00",
"recordedDate": "1940-11-09T18:33:18-05:00"
},
"search": {
"mode": "match",
"score": 1
}
},
{
"id": "17eb029f925-40603327-0ac3-48dd-972b-6c882b8751f5",
"fullUrl": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/Condition/17eb029f925-40603327-0ac3-48dd-972b-6c882b8751f5",
"resource": {
"resourceType": "Condition",
"id": "17eb029f925-40603327-0ac3-48dd-972b-6c882b8751f5",
"meta": {
"versionId": "1",
"lastUpdated": "2022-01-31T12:44:07.847Z",
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition"
]
},
"clinicalStatus": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
"code": "resolved"
}
]
},
"verificationStatus": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
"code": "confirmed"
}
]
},
"category": [
{
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
],
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "195662009",
"display": "Acute viral pharyngitis (disorder)"
}
],
"text": "Acute viral pharyngitis (disorder)"
},
"subject": {
"reference": "Patient/17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b"
},
"encounter": {
"reference": "Encounter/17e77566282-0c9c236b-f0bd-45e0-9c61-80991a376967"
},
"onsetDateTime": "1961-06-25T01:11:45-04:00",
"abatementDateTime": "1961-07-07T01:11:45-04:00",
"recordedDate": "1961-06-25T01:11:45-04:00"
},
"search": {
"mode": "match",
"score": 1
}
}
]
}

Request: Implantable Device

Search Parameters
GET [Base_URL]/Device?patient=[id] e.g. [Base_URL]/Device?patient=17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b

Response
Each resource returned from the first search is expected to conform to the US Core ImplantableDevice Profile
Code: 200 (Success)

{
 "resourceType": "Bundle",
 "id": "5804551e-120d-4164-b05b-9705fad44fa5",
 "type": "searchset",
 "total": 1,
 "link": [
 {
 "relation": "self",
 "url": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/Device?_count=10&patient=17e77411359-8837d878-ea1e-45b5-bb89-
882fdfb2be4b&_page=1"
 }
 ],
 "entry": [
 {
 "id": "17e777b3f34-04bc3627-92d3-43bb-92e7-35533110f750",
 "fullUrl": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/Device/17e777b3f34-04bc3627-92d3-43bb-92e7-35533110f750",
 "resource": {
 "resourceType": "Device",
 "id": "17e777b3f34-04bc3627-92d3-43bb-92e7-35533110f750",
 "meta": {
 "versionId": "1",
 "lastUpdated": "2022-01-20T12:34:32.884Z",
 "profile": [
 "http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device"
 ]
 },
 "udiCarrier": [
 {
 "deviceIdentifier": "43069338026389",
 "carrierHRF": "(01)43069338026389(11)000302(17)250317(10)1134(21)842026117977"
 }
 ],
 "status": "active",
 "distinctIdentifier": "43069338026389",
 "manufactureDate": "2000-03-02T18:33:18-05:00",
 "expirationDate": "2025-03-17T19:33:18-04:00",
 "lotNumber": "1134",
 "serialNumber": "842026117977",
 "deviceName": [
 {
 "name": "Implantable defibrillator, device (physical object)",
 "type": "user-friendly-name"
 }
 ],
 "type": {
 "coding": [
 {
 "system": "http://snomed.info/sct",
 "code": "72506001",
 "display": "Implantable defibrillator, device (physical object)"
 }
 ],
 "text": "Implantable defibrillator, device (physical object)"
 },
 "patient": {
 "reference": "Patient/17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b"
 }
 },
 "search": {
 "mode": "match",
 "score": 1
 }
 }
 ]
} 

Request: Goal

GET https://[Base_URL]/Goal?patient=[id]
e.g. https://[Base_URL]/Goal?patient=17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b

Response
Each resource returned from the first search is expected to conform to the US Core Goal Profile
Code: 200 (Success)

{
"resourceType": "Bundle",
"id": "6f2db230-b4f4-4447-856b-3f398377a95f",
"type": "searchset",
"total": 1,
"link": [
{
"relation": "self",
"url": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/Goal?_count=10&patient=17e77411359-8837d878-ea1e-45b5-bb89-
882fdfb2be4b&_page=1"
}
],
"entry": [
{
"id": "17e7b8b62f8-a4f77df6-b97e-4ece-82ff-36480c9cc38c",
"fullUrl": "https://fhirserver.claimpower.com:9443/fhir-server/api/v4/Goal/17e7b8b62f8-a4f77df6-b97e-4ece-82ff-36480c9cc38c",
"resource": {
"resourceType": "Goal",
"id": "17e7b8b62f8-a4f77df6-b97e-4ece-82ff-36480c9cc38c",
"meta": {
"versionId": "1",
"lastUpdated": "2022-01-21T07:30:39.48Z",
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-goal"
]
},
"lifecycleStatus": "active",
"description": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "281004",
"display": "Alcoholic dementia"
}
],
"text": "Alcoholic dementia"
},
"subject": {
"reference": "Patient/17e77411359-8837d878-ea1e-45b5-bb89-882fdfb2be4b"
},
"target": [
{
"dueDate": "2020-12-07"
}
]
},
"search": {
"mode": "match",
"score": 1
}
}
]
}

Error Handling

Error Description
200 - OK Everything worked as expected.
401 - Unauthorized No valid Bearer token provided.
404 - Not Found The requested resource doesn't exist.
5xx - Server Error Something went wrong on FHIR Server side.

OperationOutcome explains the error reported

Profile audience and scope
This profile is intended to be used by developers of apps that need to access user identity information or other FHIR resources by requesting authorization from OAuth 2.0 compliant authorization servers.
The profile defines a method through which an app requests authorization to access a FHIR resource, and then uses that authorization to retrieve the resource. Synchronization of patient context is not addressed; for use cases that require context synchronization (e.g., learning about when the in-context patient changes within an EHR session) In other words, if the patient chart is changed during the session, the application will not inherently be updated.

Security and Privacy Considerations

App Protection
The app is responsible for protecting itself from potential misbehaving or malicious values passed to its redirect URL (e.g., values injected with executable code, such as SQL) and for protecting authorization codes, access tokens, and refresh tokens from unauthorized access and use. The app developer must be aware of potential threats, such as malicious apps running on the same platform, counterfeit authorization servers, and counterfeit resource servers, and implement countermeasures to help protect both the app itself and any sensitive information it may hold. For background, see the OAuth 2.0 Threat Model and Security Considerations.

Specific requirements are:
• Apps shall ensure that sensitive information (authentication secrets, authorization codes, tokens) is transmitted ONLY to authenticated servers, over TLS-secured channels.
• Apps shall generate an unpredictable state parameter for each user session; shall include state with all authorization requests; and shall validate the state value for any request sent to its redirect URL.
• An app shall NOT execute untrusted user-supplied inputs as code.
• App shall NOT forward values passed back to its redirect URL to any other arbitrary or user-provided URL (a practice known as an “open redirector”).
• An app shall NOT store bearer tokens in cookies that are transmitted as clear text.
• Apps should persist tokens and other sensitive data in app-specific storage locations only, and should NOT persist them in system-wide-discoverable locations.

Claimpower Real World Testing Plan - 2025

General Information

Developer Name: Claimpower, Inc

Product Name: Claimpower Mobile EMR

Version Number: 6.1

Certified Health IT Product List (CHPL) ID(s): 15.04.04.1238.Clai.06.02.1.230109

Developer Real World Testing Page URL: https://claimpower.com/real-world-test-plan/

Standards Update

Question Answer
Standard (and Version) 1) USCDI v3 Standards
2) CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2021 (Available 3/12/2021)
Updated Certification Criteria and Associated Product Claimpower V 6.1
Updated Certification Criteria:
§ 170.315(c)(3) - Clinical quality measures (CQMs) — report
Health IT Module CHPL ID 15.04.04.1238.Clai.06.01.1.200427
Method Used for Standard Update SVAP, Drummond Attestation
Date of ONC ACB Notification September 15th, 2024 (Target Date)
Date of Customer Notification October  15th, 2024 (Target Date)
USCDI updated certification criteria (and USCDI version) USCDI v3
Updated Certification Criteria:
§ 170.315(b)(1) Transitions of care;
§ 170.315(b)(2) Clinical information reconciliation and incorporation;
§ 170.315(e)(1) View, download, and transmit to 3rd party;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(g)(9) Application access—all data request
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§170.315(b)(3) Electronic prescribing

 

TCM Management [CP-TCM]

Justification

One of our clients is scaling their Transitional Care Management Programs. We will support them with our Real World Testing plan. As part of this program, patients are tracked for a 30-day period post-discharge. This test plan will ensure we can import data from partner hospital Epic systems and streamline the administrative tasks necessary for this program.

 

User Stories

  • For each of their patients, we will send a Discharge Summary and C-CDA from their partner hospital’s Epic
  • We will import this data into our system. Both demographic details and medication lists will be reconciled
  • All medications a patient needs will be ePrescribed using DoseSpot.
  • When a patient completes their 30 days, we will export an updated C-CDA

 

Associated Certification Criteria

  • 170.315(b)(1) – Transitions of Care
  • 170.315(b)(2) – Clinical information reconciliation and incorporation
  • 170.315(b)(3) – Electronic Prescribing
  • 170.315(b)(10) – Electronic Health Information Export

Measures

  • Count of patients in TCM program we import data for in a 30-day period. This metric will give a total count of the discharge summaries and C-CDA’s we import data for
  • %Of patients in the TCM program we import data for in a 30-day period. This ratio will track how often this import is used. The denominator will be the count of patients enrolled in the TCM program, the numerator how many we import discharge summaries and C-CDA’s for.
  • Count of patients enrolled in the TCM programs that we send prescriptions for in a 30-day period.
  • % of patients in the TCM program we send ePrescriptions for in the measured 30-day period. This ratio will track the % of patients in the TCM program who had medications ePrescribed with Dosespot. The denominator will be a distinct count of patients enrolled in the program, the numerator a distinct count of patients who had an ePrescription sent
  • Count of patients enrolled in the TCM programs that we complete the data export for in a 30-day period.
  • %Of patients in the TCM program we export data for in a 30-day period.

Expected Outcomes

For each measure, we expect that we will have more than 10 qualifying patients in a 30-day period and that each of our ratios will be above 70%.

Schedule of Key Milestones

  • February 28, 2025. Finalize coordination with Epic to receive Discharge Summaries and C-CDA files
  • March 1st – March 31, 2025. Gather data
  • April 30th, 2025: Complete report summarizing data  

 

New Client - CQM Data Import [CP-CQM]

Justification

We are blessed to have gained a few EMR clients. We will use this Real World Test Plan to assist them with their quality reporting. We will accomplish this by:

  • Auditing the CQMs we already have setup for them and ensure we are generating compliant QRDAs for them by importing this data to the QPP portal
  • Conducting trainings for our new clients to ensure they are comfortable using our reporting website to track their CQM scores.
  • As some of our clients switched to our EMR in the middle of 2021, we will import the CQM data from their old EMR systems

Associated Certification Criteria

  • 170.315(c)(1) - Clinical quality measures (CQMs) — record and export
  • 170.315(c)(2) - Clinical quality measures (CQMs) — import and calculate
  • 170.315(c)(3) - Clinical quality measures (CQMs) — report

Metrics

  1. Count of how many QRDA files uploaded to the QPP portal
  2. Count of how many clients we import CQM data for

Expected Outcomes

Our target is to import at least one set of QRDA files to the QPP portal.

We received a lot of pushback from our clients’ previous EMR systems as we brought them into ours. So much so, we file an Information Blocking ONC complaint against CureMD, who requested an unreasonable amount of money ($14,000) to give us a data export. Unfortunately, after many follow ups, we still have not received a response from the ONC on our complaint. This behavior was consistent with our other EMR transitions. Given the challenges in working with other EMRs, our target is to complete the QRDA import for one client.

Schedule of Key Milestones

  • December 31st, 2025- Receive QRDA data files from our new clients’ old EMRs. Complete trainings to ensure clients are comfortable pulling reports
  • January 31st, 2026- Complete QRDA import
  • February 28th, 2026- Upload files to QPP portal

 

Patient Portal [CP-PP]

Justification

Many patients seen by our providers use our patient portal to gain access to their health information. We will track their usage with this Real-World Test plan. We will implement site tracking on our patient portal to see how many patients use the portal.

User Stories

  • We will track a count of how many patients log into the portal to see how many view their information
  • We will track a count of how many patients download their data
  • Finally, we will track a count of how many patients transmit their information to another party

Metrics

  1. %Of Patients who view their info = Count of unique patients logged in/ #of Patients who have patient portal enabled in a 30 day period
  2. Count of how many patients download their data in a 30-day period
  3. Count of patients who transmit their information to another party in a 30-day period

Expected Outcomes

Given the large patient population that already has access to the portal, we anticipate that 5% of them will login within a 30-day period. We expect that 10% of these patients will download and transmit their data.

Associated Certification Criteria

View, download, and transmit to 3rd party” criterion in § 170.315(e)(1)

Schedule of Key Milestones

  • September 1st, 2025- Begin collection of patient portal data
  • September 30th, 2025- Complete data collection

 

Immunization Registry [CP-IR]

Justification

We’ve enrolled one of our providers into the Texas Immunization Registry. We will track their usage with this Real World Test plan. We will track how many patients we successfully send information to the registry for. We will also track how many of these patients we are able to pull back the immunization history and forecast for. We will make our sample period during flu shot season so we can track maximum immunization data.

User Stories

  • As a user enters a vaccine into our system, we will automatically send this data to the registry
  • A user will have the option to pull immunization registry data back and have it display on their screen

Metrics

  1. Count of patients have their vaccine information sent to registry / patients vaccinated
  2. Count of patients who we successfully pull vaccine information for / patients vaccinated

Expected Outcomes

We expect at least 80% of patients vaccinated will have their information successfully transmitted to the registry and that at least 80% of the requests from the registry of vaccination information will be successful.

Schedule of Key Milestones

  • September 1st, 2025- Begin collection of vaccination data
  • September 30th, 2025- Complete data collection

Associated Certification Criteria

The public health criteria in § 170.315(f)

  • 170.315(f)(1) - Transmission to immunization registries

API Access

Justification

We ae working on an integration with Heidi, an AI-charting vendor to help our providers with documentation. We will do an API integration to push patient data over to them.

Metrics

  • Count of patients sent through API per month

Expected Outcomes

We expect the count of patients who are pushed through our API will increase month over month.

Schedule of Key Milestones

  • March 1st, 2025- Begin collection of Heidi API data

 

Associated Certification Criteria

  • The application programming interface criteria in § 170.315(g)(7) through (g)(9)
    • 170.315(g)(7) - Application access — patient selection
    • 170.315(g)(9) – Application access – all data request

Direct Project [CP-DPO]

Justification

A few of our clients are enrolled with EMR Direct to exchange information with other providers. For our Real-World Test plan, we will track their utilization of this for a 30 day period. Horizon recently started a program where they share ADT information via Direct.

User Stories

We will enroll our providers to receive Horizon ADTs via Direct.

Expected Outcomes

Our target is to complete this exchange for at least 1 patient using phiMail.

Metrics

Count of patients who have their information exchanged using EMR Direct.

Associated Certification Criteria

  • The transport methods and other protocols criteria in § 170.315(h)
    • 170.315(h)(1) – Direct Project

 

Intake Form [CP-IF]

Justification

At the request of one of our clients, we have partnered with another vendor to offer an intake form product. To avoid asking the patient to re-enter information we have already, we designed a process where we will exchange multiple FHIR objects, including: Patient, Organization, Condition, Activity Definition, Allergy Intolerance, Medication, Condition, and Document Reference via our API. This vendor is registered with our authorization server through tokenization. This token must be refreshed monthly and can be revoked at anytime.

User Stories

After consenting to the process, a patient should receive a copy of an intake form with historical information prepopulated. The patient must be able to make any edits to the intake form. The edits will then reflect in the EMR.

Expected Outcomes

This will become a standard process for all of our clients.

Metrics

  • The count of patients who receive a copy of the intake form. We expect this will increase overtime.
  • %of Patients who enter and submit data through the intake form.

Associated Certification Criteria

  • 170.315(g)(10) Standardized API for patient and population services

 

Care Settings

Our EMR is built and marketed to small individual practitioners. None of the offices we work with has more than 5-6 doctors using our EMR. Our client base is primarily internal medicine, with a few cardiologists, psychiatrists, and one infectious disease client. Given the commonality of their size, the needs of each practice are homogenous, so we are only testing for the “Small Individual Practitioner” ambulatory care setting.

This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.

Authorized Representative Name: Rohan Thadani

Authorized Representative Email: rohan@claimpower.com

Authorized Representative Phone: 201-982-3661

 

Claimpower Real World Testing Plan - 2024 Results 

General Information

Developer Name: Claimpower, Inc

Product Name: Claimpower Mobile EMR

Version Number: 6.1

Certified Health IT Product List (CHPL) ID(s): 15.04.04.1238.Clai.06.01.1.200427        

Developer Real World Testing Page URL: https://claimpower.com/real-world-test-plan/

Standards Update

Question Answer
Standard (and Version) 1) USCDI v3 Standards
2) CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2021 (Available 3/12/2021)
Updated Certification Criteria and Associated Product Claimpower V 6.1
Updated Certification Criteria:
§ 170.315(c)(3) - Clinical quality measures (CQMs) — report
Health IT Module CHPL ID 15.04.04.1238.Clai.06.01.1.200427
Method Used for Standard Update SVAP, Drummond Attestation
Date of ONC ACB Notification January 15th, 2024 (Target Date)
Date of Customer Notification February  15th, 2024 (Target Date)
USCDI updated certification criteria (and USCDI version) USCDI v3
Updated Certification Criteria:
§ 170.315(b)(1) Transitions of care;
§ 170.315(b)(2) Clinical information reconciliation and incorporation;
§ 170.315(e)(1) View, download, and transmit to 3rd party;
§ 170.315(f)(5) Transmission to public health agencies—electronic case reporting;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(g)(9) Application access—all data request
§ 170.315(b)(9) Care plan;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(b)(7) Security tags - summary of care - send and/ or
§170.315(b)(8) Security tags - summary of care - receive on access—all data request
§170.315(b)(3) Electronic prescribing

 

TCM Management [CP-TCM]

Justification

One of our clients is scaling their Transitional Care Management Programs. We will support them with our Real World Testing plan. As part of this program, patients are tracked for a 30-day period post-discharge. This test plan will ensure we can import data from partner hospital Epic systems and streamline the administrative tasks necessary for this program.

 

User Stories

  • For each of their patients, we will send a Discharge Summary and C-CDA from their partner hospital’s Epic
  • We will import this data into our system. Both demographic details and medication lists will be reconciled
  • All medications a patient needs will be ePrescribed using DoseSpot.
  • When a patient completes their 30 days, we will export an updated C-CDA

 

Associated Certification Criteria

  • 170.315(b)(1) – Transitions of Care
  • 170.315(b)(2) – Clinical information reconciliation and incorporation
  • 170.315(b)(3) – Electronic Prescribing
  • 170.315(b)(6) – Data Export*

Measures

  • Count of patients in TCM program we import data for in a 30-day period. This metric will give a total count of the discharge summaries and C-CDA’s we import data for
  • %Of patients in the TCM program we import data for in a 30-day period. This ratio will track how often this import is used. The denominator will be the count of patients enrolled in the TCM program, the numerator how many we import discharge summaries and C-CDA’s for.
  • Count of patients enrolled in the TCM programs that we send prescriptions for in a 30-day period.
  • % of patients in the TCM program we send ePrescriptions for in the measured 30-day period. This ratio will track the % of patients in the TCM program who had medications ePrescribed with Dosespot. The denominator will be a distinct count of patients enrolled in the program, the numerator a distinct count of patients who had an ePrescription sent
  • Count of patients enrolled in the TCM programs that we complete the data export for in a 30-day period.
  • %Of patients in the TCM program we export data for in a 30-day period.

Expected Outcomes

For each measure, we expect that we will have more than 10 qualifying patients in a 30-day period and that each of our ratios will be above 70%.

Schedule of Key Milestones

  • February 28, 2024. Finalize coordination with Epic to receive Discharge Summaries and C-CDA files
  • March 1st – March 31, 2024. Gather data
  • April 30th, 2024: Complete report summarizing data  

 

Changes to Original Plan

  • Despite many requests to varying levels of management at our partner hospital, we were not able to setup an automated C-CDA import. The option to export C-CDAs was also not exposed to the userid we were provided to access Epic. In spite of this, Houston Methodist is very excited about this program and we are working to roll it out across the hospital system.
  • We are now exploring a partnership with Carequality to connect us to the Great Houston Health Connect Network to exchange health information with the hospital.
  • The hospital did not want the C-CDA files back, however, we still tested our ability to export C-CDA files.

 

Summary of Key Testing Methods and Key Findings

As detailed in our milestones, we took a one-month sample of our work in this program for our Real-World Test Plan. Here is the data:

Measure Numerator Denominator Outcome%
Patients imported 3.1.24 – 3.31.24 0 via C-CDA 25 total patients 0%
Patients prescriptions sent for 3.1.24 – 3.31.24 37 patients with prescriptions sent 37 total patients 100%
Patients with C-CDAs exported 37 patients with C-CDAs exported 37 total patients 100%

 

While we were disappointed that we were not able to automate the data exchange with the hospital, we are excited to continue to support these Post-Acute programs. Our client is taking on more.

 

New Client - CQM Data Import [CP-CQM]

Justification

We are blessed to have gained a few EMR clients during the pandemic. We will use this Real World Test Plan to assist them with their quality reporting. We will accomplish this by:

  • Auditing the CQMs we already have setup for them and ensure we are generating compliant QRDAs for them by importing this data to the QPP portal
  • Conducting trainings for our new clients to ensure they are comfortable using our reporting website to track their CQM scores.
  • As some of our clients switched to our EMR in the middle of 2021, we will import the CQM data from their old EMR systems

Associated Certification Criteria

  • 170.315(c)(1) - Clinical quality measures (CQMs) — record and export
  • 170.315(c)(2) - Clinical quality measures (CQMs) — import and calculate
  • 170.315(c)(3) - Clinical quality measures (CQMs) — report

Metrics

  1. Count of how many QRDA files uploaded to the QPP portal
  2. Count of how many clients we import CQM data for

Expected Outcomes

Our target is to import at least one set of QRDA files to the QPP portal.

We received a lot of pushback from our clients’ previous EMR systems as we brought them into ours. So much so, we file an Information Blocking ONC complaint against CureMD, who requested an unreasonable amount of money ($14,000) to give us a data export. Unfortunately, after many follow ups, we still have not received a response from the ONC on our complaint. This behavior was consistent with our other EMR transitions. Given the challenges in working with other EMRs, our target is to complete the QRDA import for one client.

Schedule of Key Milestones

  • December 31st, 2024- Receive QRDA data files from our new clients’ old EMRs. Complete trainings to ensure clients are comfortable pulling reports
  • January 31st, 2025- Complete QRDA import
  • February 28th, 2025- Upload files to QPP portal

 

Changes to Original Plan

We brought in several clients within past year and completed EMR data imports for many of them. A consistent trend is tremendous difficulty in getting data exports from legacy EMR systems. As a result, we were not able to import any QRDA files from a legacy EMR system.

Summary of Key Testing Methods and Key Findings

We have two clients that are enrolled in Primary Care First who required us to upload their data to CMS via a QRDA file. We did this successfully. We will continue to ask for QRDA files as we bring on new clients. We succeeded in uploading QRDA files for both our clients to the QPP portal- giving us a 100% success rate for the QRDA file upload.

 

Patient Portal [CP-PP]

Justification

Many patients seen by our providers use our patient portal to gain access to their health information. We will track their usage with this Real-World Test plan. We will implement site tracking on our patient portal to see how many patients use the portal.

User Stories

  • We will track a count of how many patients log into the portal to see how many view their information
  • We will track a count of how many patients download their data
  • Finally, we will track a count of how many patients transmit their information to another party

Metrics

  1. %Of Patients who view their info = Count of unique patients logged in/ #of Patients who have patient portal enabled in a 30 day period
  2. Count of how many patients download their data in a 30-day period
  3. Count of patients who transmit their information to another party in a 30-day period

Expected Outcomes

Given the large patient population that already has access to the portal, we anticipate that 5% of them will login within a 30-day period. We expect that 10% of these patients will download and transmit their data.

Associated Certification Criteria

View, download, and transmit to 3rd party” criterion in § 170.315(e)(1)

Schedule of Key Milestones

  • September 1st, 2024- Begin collection of patient portal data
  • September 30th, 2024- Complete data collection
  • Summary of Key Testing Methods and Key Findings

As outlined in our plan, we completed data collection to track how many patients had access to the patient portal from 9/1/24 – 9/30/24. Here is a summary of the data:

Patients Logged-In Login% Data Downloaded/Transmitted Download/Transmit%
952 87 9.13% 9 10.34%
  • Our percentage of patients logged in was below our initial 10% projection, however significantly above last year! We continue to train our providers on workflows to sign patients up for the portal. We were pleased to see that of these patients who logged, 10.34% of them were able to download/ transmit their data. This was less than the year before, however, we feel this is primarily due to the large denominator of logged in patients.

 

Immunization Registry [CP-IR]

Justification

We’ve enrolled several of our providers with the New Jersey Immunization Registry. We will track their usage with this Real World Test plan. New Jersey automatically enrolls all patients born after January 1, 1998 into the Immunization Registry. Over a 30 day period, we will track how many of these patients we send immunizations to the registry for. We will also track how many of these patients we are able to pull back the immunization history and forecast for. We will make our sample period during flu shot season so we can track maximum immunization data.

User Stories

  • As a user enters a vaccine into our system, we will automatically send this data to the registry
  • A user will have the option to pull immunization registry data back and have it display on their screen

Metrics

  1. Count of patients born after 1/1/1998 who have their vaccine information sent to registry/ count of patients born after 1/1/1998 vaccinated over a 30-day period
  2. Count of patients born after 1/1/1998 who we successfully pull vaccine information for/ count of patients born after 1/1/1998 who information is requested for over a 30-day period

Expected Outcomes

We expect at least 80% of patients vaccinated will have their information successfully transmitted to the registry and that at least 80% of the requests from the registry of vaccination information will be successful.

Schedule of Key Milestones

  • August 30th, 2024- Complete registration of any remaining clients to the vaccination registry
  • September 1st, 2024- Begin collection of vaccination data
  • September 30th, 2024- Complete data collection

Associated Certification Criteria

The public health criteria in § 170.315(f)

  • 170.315(f)(1) - Transmission to immunization registries

Changes to Original Plan

  • There were no changes to the original plan.

 

Summary of Key Testing Methods and Key Findings

  • We succeeded in collecting data on registry transmissions during the measurement period. We exceeded our 80% target for successful transmissions.
Patients Vaccinated Patients Sent to Registry Transmission%
317 260 82.01%

 

API Access

Justification

We currently have many SFTP interfaces in place where we push and pull data to various entities. We have a few eligibility API interfaces in place where we pull data for patients, but none of our clients currently require us to push data to an outside party via API. We previously had an interface in place with Deepscribe, however, our clients decided they did not want to use Deepscribe anymore.

 

Our API is ready and we will happily put it to use when the client request comes up. However, for the purpose of our Real-World Test plan we are considering this a non-deployed capability.

Associated Certification Criteria

  • The application programming interface criteria in § 170.315(g)(7) through (g)(9)
    • 170.315(g)(7) - Application access — patient selection
    • 170.315(g)(9) – Application access – all data request

Direct Project [CP-DPO]

Justification

A few of our clients are enrolled with EMR Direct to exchange information with other providers. For our Real World Test plan, we will track their utilization of this for a 30 day period. Many of our clients have told us that they are unable to find direct email addresses for other providers they work with. We will assist them in creating a list of all the specialists they work with and reaching out to them for their secure email addresses.

User Stories

A user should be able to use EMR Direct to exchange a patient’s health information with another provider

Expected Outcomes

Given the troubles our clients have previously communicated to us with finding specialists Direct Email addresses, our target is to complete this exchange for at least 1 patient using phiMail.

Metrics

Count of patients who have their information exchanged using EMR Direct.

Associated Certification Criteria

  • The transport methods and other protocols criteria in § 170.315(h)
    • 170.315(h)(1) – Direct Project

Changes to Original Plan

  • There were no changes to the original test plan. Our clients continue to be disinterested in this technology.

Summary of Key Testing Methods and Key Findings

  • We completed this exchange for one patient.

 

Intake Form [CP-IF]

Justification

At the request of one of our clients, we have partnered with another vendor to offer an intake form product. To avoid asking the patient to re-enter information we have already, we designed a process where we will exchange multiple FHIR objects, including: Patient, Organization, Condition, Activity Definition, Allergy Intolerance, Medication, Condition, and Document Reference via our API. This vendor is registered with our authorization server through tokenization. This token must be refreshed monthly and can be revoked at anytime.

User Stories

After consenting to the process, a patient should receive a copy of an intake form with historical information prepopulated. The patient must be able to make any edits to the intake form. The edits will then reflect in the EMR.

Expected Outcomes

This will become a standard process for all of our clients.

Metrics

  • The count of patients who receive a copy of the intake form. We expect this will increase overtime.
  • %of Patients who enter and submit data through the intake form.

Associated Certification Criteria

  • 170.315(g)(10) Standardized API for patient and population services

 

Changes to Original Plan

There were no changes to the original test plan.

Summary of Key Testing Methods and Key Findings

We succeeded in building a basic version of the intake form. Here is our data from December 2024:

Patients Received Form Patients Completed Form Success%
111 95 85.56%

 

 

Care Settings

Our EMR is built and marketed to small individual practitioners. None of the offices we work with has more than 5-6 doctors using our EMR. Our client base is primarily internal medicine, with a few cardiologists, psychiatrists, and one infectious disease client. Given the commonality of their size, the needs of each practice are homogenous, so we are only testing for the “Small Individual Practitioner” ambulatory care setting.

This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.

Authorized Representative Name: Rohan Thadani

Authorized Representative Email: rohan@claimpower.org

Authorized Representative Phone: 201-982-3661

Claimpower Real World Testing Plan - 2024

General Information

Developer Name: Claimpower, Inc

Product Name: Claimpower Mobile EMR

Version Number: 6.1

Certified Health IT Product List (CHPL) ID(s): 15.04.04.1238.Clai.06.01.1.200427       

Developer Real World Testing Page URL: https://claimpower.com/real-world-test-plan/

Standards Update

Question Answer
Standard (and Version) 1) USCDI v3 Standards
2) CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2021 (Available 3/12/2021)
Updated Certification Criteria and Associated Product Claimpower V 6.1
Updated Certification Criteria:
§ 170.315(c)(3) - Clinical quality measures (CQMs) — report
Health IT Module CHPL ID 15.04.04.1238.Clai.06.01.1.200427
Method Used for Standard Update SVAP, Drummond Attestation
Date of ONC ACB Notification January 15th, 2024 (Target Date)
Date of Customer Notification February  15th, 2024 (Target Date)
USCDI updated certification criteria (and USCDI version) USCDI v3
Updated Certification Criteria:
§ 170.315(b)(1) Transitions of care;
§ 170.315(b)(2) Clinical information reconciliation and incorporation;
§ 170.315(e)(1) View, download, and transmit to 3rd party;
§ 170.315(f)(5) Transmission to public health agencies—electronic case reporting;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(g)(9) Application access—all data request
§ 170.315(b)(9) Care plan;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(b)(7) Security tags - summary of care - send and/ or
§170.315(b)(8) Security tags - summary of care - receive on access—all data request
§170.315(b)(3) Electronic prescribing

 

TCM Management [CP-TCM]

Justification

One of our clients is scaling their Transitional Care Management Programs. We will support them with our Real World Testing plan. As part of this program, patients are tracked for a 30-day period post-discharge. This test plan will ensure we can import data from partner hospital Epic systems and streamline the administrative tasks necessary for this program.

 

User Stories

  • For each of their patients, we will send a Discharge Summary and C-CDA from their partner hospital’s Epic
  • We will import this data into our system. Both demographic details and medication lists will be reconciled
  • All medications a patient needs will be ePrescribed using DoseSpot.
  • When a patient completes their 30 days, we will export an updated C-CDA

 

Associated Certification Criteria

  • 170.315(b)(1) – Transitions of Care
  • 170.315(b)(2) – Clinical information reconciliation and incorporation
  • 170.315(b)(3) – Electronic Prescribing
  • 170.315(b)(6) – Data Export*

Measures

  • Count of patients in TCM program we import data for in a 30-day period. This metric will give a total count of the discharge summaries and C-CDA’s we import data for
  • %Of patients in the TCM program we import data for in a 30-day period. This ratio will track how often this import is used. The denominator will be the count of patients enrolled in the TCM program, the numerator how many we import discharge summaries and C-CDA’s for.
  • Count of patients enrolled in the TCM programs that we send prescriptions for in a 30-day period.
  • % of patients in the TCM program we send ePrescriptions for in the measured 30-day period. This ratio will track the % of patients in the TCM program who had medications ePrescribed with Dosespot. The denominator will be a distinct count of patients enrolled in the program, the numerator a distinct count of patients who had an ePrescription sent
  • Count of patients enrolled in the TCM programs that we complete the data export for in a 30-day period.
  • %Of patients in the TCM program we export data for in a 30-day period.

Expected Outcomes

For each measure, we expect that we will have more than 10 qualifying patients in a 30-day period and that each of our ratios will be above 70%.

Schedule of Key Milestones

  • February 28, 2024. Finalize coordination with Epic to receive Discharge Summaries and C-CDA files
  • March 1st – March 31, 2024. Gather data
  • April 30th, 2024: Complete report summarizing data  

 

New Client - CQM Data Import [CP-CQM]

Justification

We are blessed to have gained a few EMR clients during the pandemic. We will use this Real World Test Plan to assist them with their quality reporting. We will accomplish this by:

  • Auditing the CQMs we already have setup for them and ensure we are generating compliant QRDAs for them by importing this data to the QPP portal
  • Conducting trainings for our new clients to ensure they are comfortable using our reporting website to track their CQM scores.
  • As some of our clients switched to our EMR in the middle of 2021, we will import the CQM data from their old EMR systems

Associated Certification Criteria

  • 170.315(c)(1) - Clinical quality measures (CQMs) — record and export
  • 170.315(c)(2) - Clinical quality measures (CQMs) — import and calculate
  • 170.315(c)(3) - Clinical quality measures (CQMs) — report

Metrics

  1. Count of how many QRDA files uploaded to the QPP portal
  2. Count of how many clients we import CQM data for

Expected Outcomes

Our target is to import at least one set of QRDA files to the QPP portal.

We received a lot of pushback from our clients’ previous EMR systems as we brought them into ours. So much so, we file an Information Blocking ONC complaint against CureMD, who requested an unreasonable amount of money ($14,000) to give us a data export. Unfortunately, after many follow ups, we still have not received a response from the ONC on our complaint. This behavior was consistent with our other EMR transitions. Given the challenges in working with other EMRs, our target is to complete the QRDA import for one client.

Schedule of Key Milestones

  • December 31st, 2024- Receive QRDA data files from our new clients’ old EMRs. Complete trainings to ensure clients are comfortable pulling reports
  • January 31st, 2025- Complete QRDA import
  • February 28th, 2025- Upload files to QPP portal

Patient Portal [CP-PP]

Justification

Many patients seen by our providers use our patient portal to gain access to their health information. We will track their usage with this Real-World Test plan. We will implement site tracking on our patient portal to see how many patients use the portal.

User Stories

  • We will track a count of how many patients log into the portal to see how many view their information
  • We will track a count of how many patients download their data
  • Finally, we will track a count of how many patients transmit their information to another party

Metrics

  1. %Of Patients who view their info = Count of unique patients logged in/ #of Patients who have patient portal enabled in a 30 day period
  2. Count of how many patients download their data in a 30-day period
  3. Count of patients who transmit their information to another party in a 30-day period

Expected Outcomes

Given the large patient population that already has access to the portal, we anticipate that 5% of them will login within a 30-day period. We expect that 10% of these patients will download and transmit their data.

Associated Certification Criteria

View, download, and transmit to 3rd party” criterion in § 170.315(e)(1)

Schedule of Key Milestones

  • September 1st, 2024- Begin collection of patient portal data
  • September 30th, 2024- Complete data collection

 

Immunization Registry [CP-IR]

Justification

We’ve enrolled several of our providers with the New Jersey Immunization Registry. We will track their usage with this Real World Test plan. New Jersey automatically enrolls all patients born after January 1, 1998 into the Immunization Registry. Over a 30 day period, we will track how many of these patients we send immunizations to the registry for. We will also track how many of these patients we are able to pull back the immunization history and forecast for. We will make our sample period during flu shot season so we can track maximum immunization data.

User Stories

  • As a user enters a vaccine into our system, we will automatically send this data to the registry
  • A user will have the option to pull immunization registry data back and have it display on their screen

Metrics

  1. Count of patients born after 1/1/1998 who have their vaccine information sent to registry/ count of patients born after 1/1/1998 vaccinated over a 30-day period
  2. Count of patients born after 1/1/1998 who we successfully pull vaccine information for/ count of patients born after 1/1/1998 who information is requested for over a 30-day period

Expected Outcomes

We expect at least 80% of patients vaccinated will have their information successfully transmitted to the registry and that at least 80% of the requests from the registry of vaccination information will be successful.

Schedule of Key Milestones

  • August 30th, 2024- Complete registration of any remaining clients to the vaccination registry
  • September 1st, 2024- Begin collection of vaccination data
  • September 30th, 2024- Complete data collection

Associated Certification Criteria

The public health criteria in § 170.315(f)

  • 170.315(f)(1) - Transmission to immunization registries
  • 170.315(f)(2) - Transmission to public health agencies — syndromic surveillance

API Access

Justification

We currently have many SFTP interfaces in place where we push and pull data to various entities. We have a few eligibility API interfaces in place where we pull data for patients, but none of our clients currently require us to push data to an outside party via API. We previously had an interface in place with Deepscribe, however, our clients decided they did not want to use Deepscribe anymore.

Our API is ready and we will happily put it to use when the client request comes up. However, for the purpose of our Real-World Test plan we are considering this a non-deployed capability.

Associated Certification Criteria

  • The application programming interface criteria in § 170.315(g)(7) through (g)(9)
    • 170.315(g)(7) - Application access — patient selection
    • 170.315(g)(8) - Application access — data category request
    • 170.315(g)(9) – Application access – all data request

Direct Project [CP-DPO]

Justification

A few of our clients are enrolled with EMR Direct to exchange information with other providers. For our Real World Test plan, we will track their utilization of this for a 30 day period. Many of our clients have told us that they are unable to find direct email addresses for other providers they work with. We will assist them in creating a list of all the specialists they work with and reaching out to them for their secure email addresses.

User Stories

A user should be able to use EMR Direct to exchange a patient’s health information with another provider

Expected Outcomes

Given the troubles our clients have previously communicated to us with finding specialists Direct Email addresses, our target is to complete this exchange for at least 1 patient using phiMail.

Metrics

Count of patients who have their information exchanged using EMR Direct.

  • The transport methods and other protocols criteria in § 170.315(h)
    • 170.315(h)(1) – Direct Project

Care Settings

Our EMR is built and marketed to small individual practitioners. None of the offices we work with has more than 5-6 doctors using our EMR. Our client base is primarily internal medicine, with a few cardiologists, psychiatrists, and one infectious disease client. Given the commonality of their size, the needs of each practice are homogenous, so we are only testing for the “Small Individual Practitioner” ambulatory care setting.

This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.

Authorized Representative Name: Rohan Thadani

Authorized Representative Email: rohan@claimpower.org

Authorized Representative Phone: 201-982-3661

Authorized Representative Signature:

 

Claimpower Real World Testing Plan - 2023 Results

General Information

Developer Name: Claimpower, Inc

Product Name: Claimpower Mobile EMR

Version Number: 6.1

Certified Health IT Product List (CHPL) ID(s): 15.04.04.1238.Clai.06.01.1.200427 

Developer Real World Testing Page URL: http://claimpower.com/real-world-test-plan/

Standards Update

Question Answer
Standard (and Version) 1) USCDI v3 Standards
2) CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2021 (Available 3/12/2021)
Updated Certification Criteria and Associated Product Claimpower V 6.1
Updated Certification Criteria:
§ 170.315(c)(3) - Clinical quality measures (CQMs) — report
Health IT Module CHPL ID 15.04.04.1238.Clai.06.01.1.200427
Method Used for Standard Update SVAP, Drummond Attestation
Date of ONC ACB Notification November 1st, 2023
Date of Customer Notification December 1st, 2023
USCDI updated certification criteria (and USCDI version) USCDI v3
Updated Certification Criteria:
§ 170.315(b)(1) Transitions of care;
§ 170.315(b)(2) Clinical information reconciliation and incorporation;
§ 170.315(e)(1) View, download, and transmit to 3rd party;
§ 170.315(f)(5) Transmission to public health agencies—electronic case reporting;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(g)(9) Application access—all data request
§ 170.315(b)(9) Care plan;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(b)(7) Security tags - summary of care - send and/ or
§170.315(b)(8) Security tags - summary of care - receive on access—all data request
§170.315(b)(3) Electronic prescribing

 

TCM Management [CP-TCM]

Justification

One of our clients is involved in several Transitional Care Management Programs. We will support them with our Real-World Testing plan. As part of this program, patients are tracked for a 30-day period post-discharge. This test plan will ensure we can import data from partner hospital Epic systems and streamline the administrative tasks necessary for this program.

 

User Stories

  • For each of their patients, we will send a Discharge Summary and C-CDA from their partner hospital’s Epic
  • We will import this data into our system. Both demographic details and medication lists will be reconciled
  • All medications a patient needs will be ePrescribed using DoseSpot.
  • When a patient completes their 30 days, we will export an updated C-CDA

 

Associated Certification Criteria

  • 170.315(b)(1) – Transitions of Care
  • 170.315(b)(2) – Clinical information reconciliation and incorporation
  • 170.315(b)(3) – Electronic Prescribing
  • 170.315(b)(6) – Data Export*

Measures

  • Count of patients in TCM program we import data for in a 30-day period. This metric will give a total count of the discharge summaries and C-CDA’s we import data for
  • %Of patients in the TCM program we import data for in a 30-day period. This ratio will track how often this import is used. The denominator will be the count of patients enrolled in the TCM program, the numerator how many we import discharge summaries and C-CDA’s for.
  • Count of patients enrolled in the TCM programs that we send prescriptions for in a 30-day period.
  • % of patients in the TCM program we send ePrescriptions for in the measured 30-day period. This ratio will track the % of patients in the TCM program who had medications ePrescribed with Dosespot. The denominator will be a distinct count of patients enrolled in the program, the numerator a distinct count of patients who had an ePrescription sent
  • Count of patients enrolled in the TCM programs that we complete the data export for in a 30-day period.
  • %Of patients in the TCM program we export data for in a 30-day period.

Expected Outcomes

For each measure, we expect that we will have more than 10 qualifying patients in a 30-day period and that each of our ratios will be above 70%.

Schedule of Key Milestones

  • February 28, 2023. Finalize coordination with Epic to receive Discharge Summaries and C-CDA files.
  • March 1st – March 31 2023. Gather data.
  • April 30th, 2023: Complete report summarizing data.  

 

Changes to Original Plan

  • Despite many requests to varying levels of management at our partner hospital, we were not able to setup an automated C-CDA import. The option to export C-CDAs was also not exposed to the userid we were provided to access Epic. In spite of this, Houston Methodist is very excited about this program and we are working to roll it out across the hospital system.
  • We are now exploring a partnership with Carequality to connect us to the Great Houston Health Connect Network to exchange health information with the hospital.
  • The hospital did not want the C-CDA files back, however, we still tested our ability to export C-CDA files.

 

Summary of Key Testing Methods and Key Findings

As detailed in our milestones, we took a one-month sample of our work in this program for our Real-World Test Plan. Here is the data:

Measure Numerator Denominator Outcome%
Patients imported 3.1.23 – 3.31.23 0 via C-CDA 25 total patients 0%
Patients prescriptions sent for 3.1.23 – 3.31.23 25 patients with prescriptions sent 25 total patients 100%
Patients with C-CDAs exported 25 patients with C-CDAs exported 25 total patients 100%

 

While we were disappointed that we were not able to automate the data exchange with the hospital, we are excited to continue to support these Post-Acute programs. We are hopeful that our conversations with Carequality will be fruitful and will yield big steps towards interoperability.

 

New Client - CQM Data Import [CP-CQM]

Justification

We are blessed to have gained a few EMR clients during the pandemic. We will use this Real-World Test Plan to assist them with their quality reporting. We will accomplish this by:

  • Auditing the CQMs we already have setup for them and ensure we are generating compliant QRDAs for them by importing this data to the QPP portal.
  • Conducting trainings for our new clients to ensure they are comfortable using our reporting website to track their CQM scores.
  • As some of our clients switched to our EMR in the middle of 2021, we will import the CQM data from their old EMR systems.

Associated Certification Criteria

  • 170.315(c)(1) - Clinical quality measures (CQMs) — record and export
  • 170.315(c)(2) - Clinical quality measures (CQMs) — import and calculate
  • 170.315(c)(3) - Clinical quality measures (CQMs) — report

Metrics

  1. Count of how many QRDA files uploaded to the QPP portal
  2. Count of how many clients we import CQM data for

Expected Outcomes

Our target is to import at least one set of QRDA files to the QPP portal.

Schedule of Key Milestones

  • December 31st, 2023- Receive QRDA data files from our new clients’ old EMRs. Complete trainings to ensure clients are comfortable pulling reports
  • January 31st, 2024- Complete QRDA import
  • February 28th, 2024- Upload files to QPP portal

Changes to Original Plan

We brought in several clients within past year and completed EMR data imports for many of them. A consistent trend is tremendous difficulty in getting data exports from legacy EMR systems. As a result, we were not able to import any QRDA files from a legacy EMR system.

Summary of Key Testing Methods and Key Findings

We have two clients that are enrolled in Primary Care First who required us to upload their data to CMS via a QRDA file. We did this successfully. We will continue to ask for QRDA files as we bring on new clients. We succeeded in uploading QRDA files for both our clients to the QPP portal- giving us a 100% success rate for the QRDA file upload.

 

Patient Portal [CP-PP]

Justification

Many patients seen by our providers use our patient portal to gain access to their health information. We will track their usage with this Real-World Test plan. We will implement site tracking on our patient portal to see how many patients use the portal.

 

User Stories

  • We will track a count of how many patients log into the portal to see how many view their information.
  • We will track a count of how many patients download their data.
  • Finally, we will track a count of how many patients transmit their information to another party.

Metrics

  1. %Of Patients who view their info = Count of unique patients logged in/ #of Patients who have patient portal enabled in a 30 day period
  2. Count of how many patients download their data in a 30-day period
  3. Count of patients who transmit their information to another party in a 30-day period

Expected Outcomes

Given the large patient population that already has access to the portal, we anticipate that 5% of them will login within a 30-day period. We expect that 10% of these patients will download and transmit their data.

Associated Certification Criteria

View, download, and transmit to 3rd party” criterion in § 170.315(e)(1)

Schedule of Key Milestones

  • August 30th, 2023- Complete the implementation of site tracking across the patient portal
  • September 1st, 2023- Begin collection of patient portal data
  • September 30th, 2023- Complete data collection

Changes to Original Plan

There were no changes to the Real-World Test Plan we created.

Summary of Key Testing Methods and Key Findings

As outlined in our plan, we completed data collection to track how many patients had access to the patient portal from 9/1/23 – 9/30/23. Here is a summary of the data:

Patients Logged-In Login% Data Downloaded/Transmitted Download/Transmit%
797 29 3.64% 4 13.79%

Our percentage of patients logged in was below our initial 10% projection. We continue to train our providers on workflows to sign patients up for the portal. We were pleased to see that of these patients who logged, 13.79% of them were able to download/ transmit their data.

 

Immunization Registry [CP-IR]

Justification

We’ve enrolled several of our providers with the New Jersey Immunization Registry. We will track their usage with this Real-World Test plan. New Jersey automatically enrolls all patients born after January 1, 1998 into the Immunization Registry. Over a 30-day period, we will track how many of these patients we send immunizations to the registry for. We will also track how many of these patients we are able to pull back the immunization history and forecast for. We will make our sample period during flu shot season so we can track maximum immunization data.

 

User Stories

  • As a user enters a vaccine into our system, we will automatically send this data to the registry
  • A user will have the option to pull immunization registry data back and have it display on their screen

Metrics

  1. Count of patients born after 1/1/1998 who have their vaccine information sent to registry/ count of patients born after 1/1/1998 vaccinated over a 30-day period
  2. Count of patients born after 1/1/1998 who we successfully pull vaccine information for/ count of patients born after 1/1/1998 who information is requested for over a 30-day period

Expected Outcomes

We expect at least 80% of patients vaccinated will have their information successfully transmitted to the registry and that at least 80% of the requests from the registry of vaccination information will be successful.

Schedule of Key Milestones

  • August 30th, 2023- Complete registration of any remaining clients to the vaccination registry
  • September 1st, 2023- Begin collection of vaccination data
  • September 30th, 2023- Complete data collection

Associated Certification Criteria

The public health criteria in § 170.315(f)

  • 170.315(f)(1) - Transmission to immunization registries
  • 170.315(f)(2) - Transmission to public health agencies — syndromic surveillance

Changes to Original Plan

There were no changes to the original plan.

Summary of Key Testing Methods and Key Findings

We succeeded in collecting data on registry transmissions during the measurement period. We exceeded our 80% target for successful transmissions.

Patients Vaccinated Patients Sent to Registry Transmission%
204 169 82.84%

 

API Access

Justification

We currently have many SFTP interfaces in place where we push and pull data to various entities. We have a few eligibility API interfaces in place where we pull data for patients, but none of our clients currently require us to push data to an outside party via API. We previously had an interface in place with Deepscribe, however, our clients decided they did not want to use Deepscribe anymore.

Associated Certification Criteria

  • The application programming interface criteria in § 170.315(g)(7) through (g)(9)
    • 170.315(g)(7) - Application access — patient selection
    • 170.315(g)(8) - Application access — data category request
    • 170.315(g)(9) – Application access – all data request

 

Changes to Original Plan

In late Q4, we created an API interface with an open-source EMR called Medplum to create intake forms that we can send to patients. Through it, we’ve started to exchange basic FHIR objects such as: Patient, Document Reference, and Organization. As a success rate, we are interested in measuring a count of how many forms are completed. To date, we’ve completed over 100.

Direct Project [CP-DPO]

Justification

A few of our clients are enrolled with EMR Direct to exchange information with other providers. For our Real-World Test plan, we will track their utilization of this for a 30-day period. Many of our clients have told us that they are unable to find direct email addresses for other providers they work with. We will assist them in creating a list of all the specialists they work with and reaching out to them for their secure email addresses.

 User Stories

A user should be able to use EMR Direct to exchange a patient’s health information with another provider.

Expected Outcomes

Given the troubles our clients have previously communicated to us with finding specialists Direct Email addresses, our target is to complete this exchange for at least 1 patient using phiMail.

Metrics

Count of patients who have their information exchanged using EMR Direct.

  • The transport methods and other protocols criteria in § 170.315(h)
    • 170.315(h)(1) – Direct Project

Changes to Original Plan

There were no changes to the original test plan. Our clients continue to be disinterested in this technology.

Summary of Key Testing Methods and Key Findings

We completed this exchange for one patient.

Care Settings

Our EMR is built and marketed to small individual practitioners. None of the offices we work with has more than 5-6 doctors using our EMR. Our client base is primarily internal medicine, with a few cardiologists, psychiatrists, and one infectious disease client. Given the commonality of their size, the needs of each practice are homogenous, so we are only testing for the “Small Individual Practitioner” ambulatory care setting.

This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.

Authorized Representative Name: Rohan Thadani

Authorized Representative Email: rohan@claimpower.org

Authorized Representative Phone: 201-982-3661

 

 

Claimpower Real World Testing Plan - 2023

General Information

Developer Name: Claimpower, Inc

Product Name:   Claimpower Mobile EMR

Version Number: 6.1

Certified Health IT Product List (CHPL) ID(s): 15.04.04.1238.Clai.06.01.1.200427           

Developer Real World Testing Page URL: https://claimpower.com/real-world-test-plan/

Standards Update

Question Answer
Standard (and Version) 1) USCDI v3 Standards
2) CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2021 (Available 3/12/2021)
Updated Certification Criteria and Associated Product Claimpower V 6.1
Updated Certification Criteria:
§ 170.315(c)(3) - Clinical quality measures (CQMs) — report
Health IT Module CHPL ID 15.04.04.1238.Clai.06.01.1.200427
Method Used for Standard Update SVAP, Drummond Attestation
Date of ONC ACB Notification November 1st, 2022 (Target Date)
Date of Customer Notification December 1st, 2022 (Target Date)
USCDI updated certification criteria (and USCDI version) USCDI v3
Updated Certification Criteria:
§ 170.315(b)(1) Transitions of care;
§ 170.315(b)(2) Clinical information reconciliation and incorporation;
§ 170.315(e)(1) View, download, and transmit to 3rd party;
§ 170.315(f)(5) Transmission to public health agencies—electronic case reporting;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(g)(9) Application access—all data request
§ 170.315(b)(9) Care plan;
§ 170.315(g)(6) Consolidated CDA creation performance; and/or
§ 170.315(b)(7) Security tags - summary of care - send and/ or
§170.315(b)(8) Security tags - summary of care - receive on access—all data request
§170.315(b)(3) Electronic prescribing

 

TCM Management [CP-TCM]

Justification

One of our clients is involved in several Transitional Care Management Programs. We will support them with our Real World Testing plan. As part of this program, patients are tracked for a 30-day period post-discharge. This test plan will ensure we can import data from partner hospital Epic systems and streamline the administrative tasks necessary for this program.

 

User Stories

  • For each of their patients, we will send a Discharge Summary and C-CDA from their partner hospital’s Epic
  • We will import this data into our system. Both demographic details and medication lists will be reconciled
  • All medications a patient needs will be ePrescribed using DoseSpot.
  • When a patient completes their 30 days, we will export an updated C-CDA

 

Associated Certification Criteria

  • 170.315(b)(1) – Transitions of Care
  • 170.315(b)(2) – Clinical information reconciliation and incorporation
  • 170.315(b)(3) – Electronic Prescribing
  • 170.315(b)(6) – Data Export*

Measures

  • Count of patients in TCM program we import data for in a 30-day period. This metric will give a total count of the discharge summaries and C-CDA’s we import data for
  • %Of patients in the TCM program we import data for in a 30-day period. This ratio will track how often this import is used. The denominator will be the count of patients enrolled in the TCM program, the numerator how many we import discharge summaries and C-CDA’s for.
  • Count of patients enrolled in the TCM programs that we send prescriptions for in a 30-day period.
  • % of patients in the TCM program we send ePrescriptions for in the measured 30-day period. This ratio will track the % of patients in the TCM program who had medications ePrescribed with Dosespot. The denominator will be a distinct count of patients enrolled in the program, the numerator a distinct count of patients who had an ePrescription sent
  • Count of patients enrolled in the TCM programs that we complete the data export for in a 30-day period.
  • %Of patients in the TCM program we export data for in a 30-day period.

Expected Outcomes

For each measure, we expect that we will have more than 10 qualifying patients in a 30-day period and that each of our ratios will be above 70%.

Schedule of Key Milestones

  • February 28, 2023. Finalize coordination with Epic to receive Discharge Summaries and C-CDA files
  • March 1st – March 31 2023. Gather data
  • April 30th, 2023: Complete report summarizing data  

 

New Client - CQM Data Import [CP-CQM]

Justification

We are blessed to have gained a few EMR clients during the pandemic. We will use this Real World Test Plan to assist them with their quality reporting. We will accomplish this by:

  • Auditing the CQMs we already have setup for them and ensure we are generating compliant QRDAs for them by importing this data to the QPP portal
  • Conducting trainings for our new clients to ensure they are comfortable using our reporting website to track their CQM scores.
  • As some of our clients switched to our EMR in the middle of 2021, we will import the CQM data from their old EMR systems

Associated Certification Criteria

  • 170.315(c)(1) - Clinical quality measures (CQMs) — record and export
  • 170.315(c)(2) - Clinical quality measures (CQMs) — import and calculate
  • 170.315(c)(3) - Clinical quality measures (CQMs) — report

Metrics

  1. Count of how many QRDA files uploaded to the QPP portal
  2. Count of how many clients we import CQM data for

Expected Outcomes

Our target is to import at least one set of QRDA files to the QPP portal.

We received a lot of pushback from our clients’ previous EMR systems as we brought them into ours. So much so, we file an Information Blocking ONC complaint against CureMD, who requested an unreasonable amount of money ($14,000) to give us a data export. Unfortunately, after many follow ups, we still have not received a response from the ONC on our complaint. This behavior was consistent with our other EMR transitions. Given the challenges in working with other EMRs, our target is to complete the QRDA import for one client.

Schedule of Key Milestones

  • December 31st, 2023- Receive QRDA data files from our new clients’ old EMRs. Complete trainings to ensure clients are comfortable pulling reports
  • January 31st, 2024- Complete QRDA import
  • February 28th, 2024- Upload files to QPP portal

 

Patient Portal [CP-PP]

Justification

Many patients seen by our providers use our patient portal to gain access to their health information. We will track their usage with this Real-World Test plan. We will implement site tracking on our patient portal to see how many patients use the portal.

User Stories

  • We will track a count of how many patients log into the portal to see how many view their information
  • We will track a count of how many patients download their data
  • Finally, we will track a count of how many patients transmit their information to another party

Metrics

  1. %Of Patients who view their info = Count of unique patients logged in/ #of Patients who have patient portal enabled in a 30 day period
  2. Count of how many patients download their data in a 30-day period
  3. Count of patients who transmit their information to another party in a 30-day period

Expected Outcomes

Given the large patient population that already has access to the portal, we anticipate that 5% of them will login within a 30-day period. We expect that 10% of these patients will download and transmit their data.

Associated Certification Criteria

View, download, and transmit to 3rd party” criterion in § 170.315(e)(1)

Schedule of Key Milestones

  • August 30th, 2023- Complete the implementation of site tracking across the patient portal
  • September 1st, 2023- Begin collection of patient portal data
  • September 30th, 2023- Complete data collection

 

Immunization Registry [CP-IR]

Justification

We’ve enrolled several of our providers with the New Jersey Immunization Registry. We will track their usage with this Real World Test plan. New Jersey automatically enrolls all patients born after January 1, 1998 into the Immunization Registry. Over a 30 day period, we will track how many of these patients we send immunizations to the registry for. We will also track how many of these patients we are able to pull back the immunization history and forecast for. We will make our sample period during flu shot season so we can track maximum immunization data.

 

User Stories

  • As a user enters a vaccine into our system, we will automatically send this data to the registry
  • A user will have the option to pull immunization registry data back and have it display on their screen

Metrics

  1. Count of patients born after 1/1/1998 who have their vaccine information sent to registry/ count of patients born after 1/1/1998 vaccinated over a 30-day period
  2. Count of patients born after 1/1/1998 who we successfully pull vaccine information for/ count of patients born after 1/1/1998 who information is requested for over a 30-day period

Expected Outcomes

We expect at least 80% of patients vaccinated will have their information successfully transmitted to the registry and that at least 80% of the requests from the registry of vaccination information will be successful.

Schedule of Key Milestones

  • August 30th, 2023- Complete registration of any remaining clients to the vaccination registry
  • September 1st, 2023- Begin collection of vaccination data
  • September 30th, 2023- Complete data collection

Associated Certification Criteria

The public health criteria in § 170.315(f)

  • 170.315(f)(1) - Transmission to immunization registries
  • 170.315(f)(2) - Transmission to public health agencies — syndromic surveillance

API Access

Justification

We currently have many SFTP interfaces in place where we push and pull data to various entities. We have a few eligibility API interfaces in place where we pull data for patients, but none of our clients currently require us to push data to an outside party via API. We previously had an interface in place with Deepscribe, however, our clients decided they did not want to use Deepscribe anymore.

 

Our API is ready and we will happily put it to use when the client request comes up. However, for the purpose of our Real-World Test plan we are considering this a non-deployed capability.

Associated Certification Criteria

  • The application programming interface criteria in § 170.315(g)(7) through (g)(9)
    • 170.315(g)(7) - Application access — patient selection
    • 170.315(g)(8) - Application access — data category request
    • 170.315(g)(9) – Application access – all data request

Direct Project [CP-DPO]

Justification

A few of our clients are enrolled with EMR Direct to exchange information with other providers. For our Real World Test plan, we will track their utilization of this for a 30 day period. Many of our clients have told us that they are unable to find direct email addresses for other providers they work with. We will assist them in creating a list of all the specialists they work with and reaching out to them for their secure email addresses.

User Stories

A user should be able to use EMR Direct to exchange a patient’s health information with another provider

Expected Outcomes

Given the troubles our clients have previously communicated to us with finding specialists Direct Email addresses, our target is to complete this exchange for at least 1 patient using phiMail.

Metrics

Count of patients who have their information exchanged using EMR Direct.

  • The transport methods and other protocols criteria in § 170.315(h)
    • 170.315(h)(1) – Direct Project

Care Settings

Our EMR is built and marketed to small individual practitioners. None of the offices we work with has more than 5-6 doctors using our EMR. Our client base is primarily internal medicine, with a few cardiologists, psychiatrists, and one infectious disease client. Given the commonality of their size, the needs of each practice are homogenous, so we are only testing for the “Small Individual Practitioner” ambulatory care setting.

This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.

 

Representative Name: Rohan Thadani

Authorized Representative Email: rohan@claimpower.org

Authorized Representative Phone: 201-982-3661

Claimpower Real World Testing Results- 2022

TCM Management [CP-TCM]

Justification

One of our clients is involved in several Transitional Care Management Programs. We will support them with our Real-World Testing plan. As part of this program, patients are tracked for a 30-day period post-discharge. This test plan will ensure we can import data from partner hospital Epic systems and streamline the administrative tasks necessary for this program.

 

User Stories

  • For each of their patients, we will send a Discharge Summary and C-CDA from their partner hospital’s Epic.
  • We will import this data into our system. Both demographic details and medication lists will be reconciled
  • All medications will be ePrescribed through our system
  • When a patient completes their 30 days, we will export an updated C-CDA

 

Associated Certification Criteria

  • 170.315(b)(1) – Transitions of Care
  • 170.315(b)(2) – Clinical information reconciliation and incorporation
  • 170.315(b)(3) – Electronic Prescribing
  • 170.315(b)(6) – Data Export*

Measures

  • Count of patients in TCM program we import data for in a 30-day period. This metric will give a total count of the discharge summaries and C-CDA’s we import data for
  • %Of patients in the TCM program we import data for in a 30-day period. This ratio will track how often this import is used. The denominator will be the count of patients enrolled in the TCM program, the numerator how many we import discharge summaries and C-CDA’s for.
  • Count of patients enrolled in the TCM programs that we send prescriptions for in a 30-day period.
  • % of patients in the TCM program we send ePrescriptions for in the measured 30-day period. This ratio will track the % of patients in the TCM program who had medications ePrescribed. The denominator will be a distinct count of patients enrolled in the program, the numerator a distinct count of patients who had an ePrescription sent
  • Count of patients enrolled in the TCM programs that we complete the data export for in a 30-day period.
  • %Of patients in the TCM program we export data for in a 30-day period.

Expected Outcomes

For each measure, we expect that we will have more than 10 qualifying patients in a 30 day period and that each of our ratios will be above 70%.

Schedule of Key Milestones

  • February 28, 2022. Finalize coordination with Epic to receive Discharge Summaries and C-CDA files
  • March 1st – March 31 2022. Gather data
  • April 30th, 2022: Complete report summarizing data  

Changes to Original Plan

  • Despite many requests to varying levels of management at our partner hospital, we were not able to setup an automated C-CDA import. The option to export C-CDAs was also not exposed to the userid we were provided to access Epic.
  • We attempted to work out a flat file exchange with the hospital so we could get basic patient demographic information in an automated manner. Our team built a utility to bulk import the provided data. The hospital was unable to provide us with an accurate select of patients that had an Ortho surgery and were referred to this program. This resulted in many irrelevant patients imported into our EMR, mass confusion. We worked with Epic to setup a custom order for patients that were referred to this program, however, the hospital was unable to send us patients that had this order.
  • After months of meetings and dead ends with the hospital IT, we reverted to a manual data entry process to create the patients in Claimpower.
  • The hospital did not want the C-CDA files back, however, we still tested our ability to export C-CDA files.

 

Summary of Key Testing Methods and Key Findings

As detailed in our milestones, we took a one-month sample of our work in this program for our Real-World Test Plan. Here is the data:

Measure Numerator Denominator Outcome%
Patients imported 3.1.22 – 3.31.22 0 via C-CDA 8 total patients 0%
Patients prescriptions sent for 3.1.22 – 3.31.22 8 patients with prescriptions sent 8 total patients 100%
Patients with C-CDAs exported 8 patients with C-CDAs exported 8 total patients 100%

 

While we were disappointed that we were not able to automate the data exchange with the hospital, we are excited to continue to support these Post-Acute programs. In the past year, we helped our client setup 4 other similar programs. Given the continued focus of these programs, we are hopeful we will one day get a C-CDA export from Epic. We shall not give up!

New Client - CQM Data Import [CP-CQM]

Justification

We are blessed to have gained a few EMR clients during the pandemic. We will use this Real World Test Plan to assist them with their quality reporting. We will accomplish this by:

  • Auditing the CQMs we already have setup for them and ensure we are generating compliant QRDAs for them by importing this data to the QPP portal.
  • Conducting trainings for our new clients to ensure they are comfortable using our reporting website to track their CQM scores.
  • As some of our clients switched to our EMR in the middle of 2021, we will import the CQM data from their old EMR systems.

Associated Certification Criteria

  • 170.315(c)(1) - Clinical quality measures (CQMs) — record and export
  • 170.315(c)(2) - Clinical quality measures (CQMs) — import and calculate
  • 170.315(c)(3) - Clinical quality measures (CQMs) — report

Metrics

  1. Count of how many QRDA files uploaded to the QPP portal
  2. Count of how many clients we import CQM data for

Expected Outcomes

Our target is to import at least one set of QRDA files to the QPP portal. Due to COVID-19, many of our clients have already requested we file MIPS reporting exclusions for them.

We received a lot of pushback from our clients’ previous EMR systems as we brought them into ours. So much so, we file an Information Blocking ONC complaint against CureMD, who requested an unreasonable amount of money ($14,000) to give us a data export. Unfortunately, after many follow ups, we still have not received a response from the ONC on our complaint. This behavior was consistent with our other EMR transitions. Given the challenges in working with other EMRs, our target is to complete the QRDA import for one client.

Schedule of Key Milestones

  • December 31st, 2021- Receive QRDA data files from our new clients’ old EMRs. Complete trainings to ensure clients are comfortable pulling reports
  • January 31st, 2022- Complete QRDA import
  • February 28th, 2022- Upload files to QPP portal

 

Changes to Original Plan

We brought 10+ clients in the past year and completed EMR data imports for many of them. A consistent trend is tremendous difficulty in getting data exports from legacy EMR systems. From unreasonable costs to data export “experts” who could only speak in Urdu, we battled many vendors for our clients’ data. As a result, we were not able to import any QRDA files from a legacy EMR system. We’ve adopted a policy of not charging our departing clients for their data exports.

Summary of Key Testing Methods and Key Findings

We have two clients that are enrolled in Primary Care First who required us to upload their data to CMS via a QRDA file. We did this successfully. We will continue to ask for QRDA files as we bring on new clients.

 

Patient Portal [CP-PP]

Justification

Many patients seen by our providers use our patient portal to gain access to their health information. We will track their usage with this Real-World Test plan. We will implement site tracking on our patient portal to see how many patients use the portal.

User Stories

  • We will track a count of how many patients log into the portal to see how many view their information.
  • We will track a count of how many patients download their data.
  • Finally, we will track a count of how many patients transmit their information to another party.

Metrics

  1. %Of Patients who view their info = Count of unique patients logged in/ #of Patients who have patient portal enabled in a 30 day period
  2. Count of how many patients download their data in a 30-day period
  3. Count of patients who transmit their information to another party in a 30-day period

Expected Outcomes

Given the large patient population that already has access to the portal, we anticipate that 5% of them will login within a 30-day period. We expect that 10% of these patients will download and transmit their data.

Associated Certification Criteria

View, download, and transmit to 3rd party” criterion in § 170.315(e)(1)

Schedule of Key Milestones

  • August 30th, 2022- Complete the implementation of site tracking across the patient portal
  • September 1st, 2022- Begin collection of patient portal data
  • September 30th, 2022- Complete data collection

Changes to Original Plan

There were no changes to the real-world test plan we created.

Summary of Key Testing Methods and Key Findings

As outlined in our plan, we completed data collection to track how many patients had access to the patient portal from 9/1/22 – 9/30/22. Here is a summary of the data:

Patients Logged-In Login% Data Downloaded/Transmitted Download/Transmit%
507 14 2.76% 3 21.43%

Our percentage of patients logged in was below our initial 10% projection. We will work with our providers to improve the workflows they use to refer patients over to the portal. We also plan to do more to optimize this site for mobile. We were pleased to see that of these patients who logged, 21.43% of them were able to download/ transmit their data.

 

Immunization Registry [CP-IR]

Justification

We’ve enrolled several of our providers with the New Jersey Immunization Registry. We will track their usage with this Real World Test plan. New Jersey automatically enrolls all patients born after January 1, 1998 into the Immunization Registry. Over a 30 day period, we will track how many of these patients we send immunizations to the registry for. We will also track how many of these patients we are able to pull back the immunization history and forecast for. We will make our sample period during flu shot season so we can track maximum immunization data.

 

User Stories

  • As a user enters a vaccine into our system, we will automatically send this data to the registry
  • A user will have the option to pull immunization registry data back and have it display on their screen

Metrics

  1. Count of patients born after 1/1/1998 who have their vaccine information sent to registry/ count of patients born after 1/1/1998 vaccinated over a 30-day period.
  2. Count of patients born after 1/1/1998 who we successfully pull vaccine information for/ count of patients born after 1/1/1998 who information is requested for over a 30-day period.

Expected Outcomes

We expect at least 80% of patients vaccinated will have their information successfully transmitted to the registry and that at least 80% of the requests from the registry of vaccination information will be successful.

Schedule of Key Milestones

  • August 30th, 2022- Complete registration of any remaining clients to the vaccination registry.
  • September 1st, 2022- Begin collection of vaccination data.
  • September 30th, 2022- Complete data collection

Associated Certification Criteria

The public health criteria in § 170.315(f)

  • 170.315(f)(1) - Transmission to immunization registries
  • 170.315(f)(2) - Transmission to public health agencies — syndromic surveillance

 

Changes to Original Plan

Bottlenecks in the registry sign-up process combined with complications arising from COVID-19 made it so only one of our clients were signed up with the immunization registry.

 

Summary of Key Testing Methods and Key Findings

We succeeded in collecting data on registry transmissions during he measurement period. We exceeded our 80% target for successful transmissions.

Patients Vaccinated Patients Sent to Registry Transmission%
172 141 81.98%

 

Deepscribe [CP-DPS]

Justification

At our client’s request, we completed an integration with an AI power charting vendor. This vendor connects to our API to pull relevant patient information and then pushes back documentation from the visit. Much of the information exchanged follows the data standards of 2015 Edition CCDS. The ability to exchange a subset of this data validates that we can meet this requirement. For our Real-World Test plan, we will gather data on this for a 30-day period.

User Stories

  • A user should be able to view all patients checked in under the Claimpower platform in the Deepscribe platform for a given date range.
  • Documentation from the patient’s visit should automatically come back into Claimpower.
  • The data exchange is logged.

Metrics

Number of patients data is transmitted for/ total number of patients checked in over a 30-day period.

Expected Outcomes

We expect that 100% of the patients checked in will successfully transmit to the Deepscribe platform and that 100% of the patients in the Deepscribe platform will have their chart data sent back to Claimpower.

Schedule of Key Milestones

  • January 1st, 2022- Begin data collection.
  • January 31st, 2022- Complete data collection.
  • The application programming interface criteria in § 170.315(g)(7) through (g)(9)
    • 170.315(g)(7) - Application access — patient selection
    • 170.315(g)(8) - Application access — data category request
    • 170.315(g)(9) – Application access – all data request

 

Changes to Original Plan

There were no changes to our original test plan.

 

Summary of Key Testing Methods and Key Findings

We collected the data below from 1/1/22 – 1/31/22:

Patients Checked-In Patients Sent to Deepscribe Transmission%
349 349 1

As predicted 100% of checked-in patients were transmitted to Deepscribe from 1/1/22 – 1/31/22.

Direct Project [CP-DPO]

Justification

A few of our clients are enrolled with EMR Direct to exchange information with other providers. For our Real-World Test plan, we will track their utilization of this for a 30 day period. Many of our clients have told us that they are unable to find direct email addresses for other providers they work with. We will assist them in creating a list of all the specialists they work with and reaching out to them for their secure email addresses.

User Stories

A user should be able to use EMR Direct to exchange a patient’s health information with another provider.

Expected Outcomes

Given the troubles our clients have previously communicated to us with finding specialists Direct Email addresses, our target is to complete this exchange for at least 1 patient.

Metrics

Count of patients who have their information exchanged using EMR Direct.

  • The transport methods and other protocols criteria in § 170.315(h)
    • 170.315(h)(1) – Direct Project

Changes to Original Plan

There were no changes to the original test plan. Our clients continue to be disinterested in this technology.

 

Summary of Key Testing Methods and Key Findings

We completed this exchange for one patient.

 

Care Settings

Our EMR is built and marketed to small individual practitioners. None of the offices we work with has more than 5-6 doctors using our EMR. Our client base is primarily internal medicine, with a few cardiologists, psychiatrists, and one infectious disease client. Given the commonality of their size, the needs of each practice are homogenous, so we are only testing for the “Small Individual Practitioner” care setting.

This Real World Testing plan is complete with all required elements, including measures that address all certification criteria and care settings. All information in this plan is up to date and fully addresses the health IT developer’s Real World Testing requirements.

Authorized Representative Name: Rohan Thadani

Authorized Representative Email: rohan@claimpower.org

Authorized Representative Phone: 201-982-3661

Date: 2/11/23