FHIR Chat · testing · implementers

Stream: implementers

Topic: testing

New auto user (Nov 20 2015 at 14:30):

Testing zulip email integration (body)

And some text here

{test: "ing"}

James Agnew (Nov 20 2015 at 14:37):

this seems like a recipe for spam....

Josh Mandel (Nov 20 2015 at 14:37):

Well, the incoming e-mail address is scoped to user + channel, and long (hard to guess).

Josh Mandel (Nov 20 2015 at 14:38):

The model is any user can create "bots" this way.

Josh Mandel (Nov 20 2015 at 14:38):

"New Auto User" was a poorly named e-mail gateway user. I've updated it to be clearer. But there's one gateway for the whole system.

Abdul Rauf (Dec 07 2016 at 13:03):

Hi,

Abdul Rauf (Dec 07 2016 at 13:04):

Any one please help me , I want to test metadata and Value Set ( $expand, $lookup and $ Validate-code )

Richard Ettema (Dec 07 2016 at 13:59):

@Abdul Rauf We currently have test definitions (TestScripts) available in Touchstone, http://touchstone.com, under the Connectathon groups that test the ValueSet extended operations.

Richard Ettema (Dec 07 2016 at 13:59):

For 'metadata', do you mean the $meta extended operations?

Abdul Rauf (Dec 08 2016 at 04:12):

No i mean conformance of server.

Grahame Grieve (Dec 08 2016 at 04:13):

we don't know what you mean. you'll haev to explain better

Vadim Peretokin (Dec 08 2016 at 04:18):

Do you mean test that what the server declares in it's conformance, it's able to actually do?

Abdul Rauf (Dec 08 2016 at 04:31):

Yes

Vadim Peretokin (Dec 08 2016 at 04:31):

Yeah try Touchstone, it'll help you do what you want.

Abdul Rauf (Dec 08 2016 at 04:38):

@Richard Ettema i m getting this error on touchstone.com
JSON Conformance statement could not be retrieved from 'URL'. Error: 'Connection reset'

Richard Ettema (Dec 08 2016 at 13:53):

@Abdul Rauf I'll take a look. Thanks.

Richard Ettema (Dec 08 2016 at 17:47):

@Abdul Rauf Touchstone supports secured https connections using the TLS v1.2 protocol and no client authentication. The most likely cause of the 'Connection reset' error is if your system is using a different (earlier) secured protocol like TLS v1.0, TLS v1.1 or SSLv3.

Touchstone does not support these earlier protocols due to the security vuneralibilities inherent in the older cipher suites that these protocols support.

Can you confirm what secured protocol your system supports/is using?

Richard Ettema (Dec 08 2016 at 19:21):

FHIR v1.8.0 is now being implemented into the Touchstone Testing Platform - http://touchstone.com. Once complete, will advise through this stream.

John Moehrke (Dec 08 2016 at 19:32):

@Richard Ettema That is an unfortunate misunderstanding. The cypher suites are mostly independent of TLS version. You can have just as poorly configured TLS 1.2 version as you can TLS 1.0. One can configure TLS 1.0 just as securely as TLS 1.2. And TLS 1.2 is not widely available yet. I would recommend touchstone re-evaluate this policy.

Grahame Grieve (Dec 08 2016 at 19:34):

why is the standard recommendation to not support TLS 1.0 then?

John Moehrke (Dec 08 2016 at 19:35):

which 'standard' recommends against TLS 1.0? IETF rules force some statements like this, for standards evolution sake.

Grahame Grieve (Dec 08 2016 at 19:36):

no standard that I know of, but I know that the security suites have been reporting server's ongoing use of TLS 1.0 as a vulnerability that we have to turn off

Grahame Grieve (Dec 08 2016 at 19:37):

and so I've had to figure out how to do that in my server, for instance

Richard Ettema (Dec 08 2016 at 19:38):

Please see https://tools.ietf.org/html/rfc7525

John Moehrke (Dec 08 2016 at 19:42):

RIchard. Please read it carefully... You seem to be missing the clause "the only exception is when no higher version is available in the
negotiation." This means that you START at TLS 1.2, but when the other side can't do that then you offer 1.1, but when the other ide can't do that then you offer 1.0. This is in the specification you site.

John Moehrke (Dec 08 2016 at 19:43):

AND.. those are "SHOULD NOT", not 'SHALL NOT".

John Moehrke (Dec 08 2016 at 19:45):

Grahame, as just stated with Richard; the newer protocols SHOULD be used when they can. And there are some configurations that you should not negotiate below. Such as SSL is a SHALL NOT.

Richard Ettema (Dec 08 2016 at 19:53):

John. Thanks for the clarification. Our current security architecture allows for TLS 1.2 only. Providing support for TLS 1.1, 1.0 will take some time and effort as our platform disables these older protocols by default based on the security vunerabilities that can occur with them.

Mario Hyland (Dec 08 2016 at 19:57):

John. Point received ... However, the practical side of supporting an open access global testing platform which aids developers implement (the highest levels of security) standards as they would be deployed (the conformance to the standard is our paramount concern), our approach currently leverages other industry technologies (aka Eclipse and Jetty) - which are in turn making choices. The Touchstone Project will evaluate and prioritize the FHIR Community demand to support TLS other than TLS v1.2, against current priorities like FHIR 1.8.0. We are not ruling it out, but at this time this is not a high priority.

John Moehrke (Dec 08 2016 at 20:29):

Mario, thanks for 'considering' it. this is all I asked. It is unfortunate choice, but a choice you are free to make.

Jason Walonoski (Dec 09 2016 at 13:53):

You can also try out the open-source https://projectcrucible.org for testing... we're in process of updating to v1.8.0.

John Moehrke (Dec 09 2016 at 16:14):

I summarized my perspective, realistic interoperability, on a blog post today https://healthcaresecprivacy.blogspot.com/2016/12/war-against-tls-10.html

Richard Ettema (Dec 14 2016 at 02:55):

The Touchstone Testing Platform v3.2.4 - http://touchstone.com - is now deployed with support for FHIR v1.8.0.

The AEGIS WildFHIR FHIR test client and server has also been deployed with support for FHIR v1.8.0 - http://wildfhir.aegis.net/fhir1-8-0.

Jim Steel (Dec 14 2016 at 04:52):

Nice! Are there plans to expand the FHIR 1.8.0 test definitions beyond the current set of Resources?

Richard Ettema (Dec 14 2016 at 13:48):

We're working on porting over all the 1.6.0 tests over the next few days as well as getting as much coverage of the Connectathon 14 test tracks as we can.

Vadim Peretokin (Dec 14 2016 at 23:28):

Great news, thanks Richard

Vadim Peretokin (Dec 15 2016 at 00:19):

@Jim Steel which resources are you looking at that're not covered?

Michael Lawley (Dec 15 2016 at 00:41):

@Jim Steel is looking for the terminology resources - CodeSystem, ValueSet, and ConceptMap

Richard Ettema (Dec 15 2016 at 06:15):

ConceptMap and ValueSet should be ported over in the next day or two. I'll work on CodeSystem after that.

Mario Hyland (Dec 20 2016 at 17:39):

HL7 FHIR Connectathon 14 - Patient Track Semi-Formal testing; for folks planning on attending the Connectathon 14 conducting Pre-Connectathon testing against the test scripts which will be part of the FHIR Semi-Formal Testing can be done prior to the event? Pracitce testing - is that correct?

Mario Hyland (Dec 20 2016 at 17:40):

Just checking - will Conformance/Compatibility Statements be required to be correct, are they part of the Semi-Formal testing for the patient track?

Richard Ettema (Dec 21 2016 at 01:58):

Everyone,
The initial Connectathon14 TestScripts and fixtures (test definitions) for PATCH (Unofficial Track ported from Connectathon13), Patient-01-Intro, Patient-02-Formal, ProviderDirectory, Scheduling, Terminology and USCore tracks have been committed to the FHIR SVN trunk at http://gforge.hl7.org/svn/fhir/trunk/connectathons/SanAntonioJan2017/Connectathon14. Additional folders for the other test tracks have been committed as place holders for their respective TestScrips and fixtures.

Richard Ettema (Dec 21 2016 at 01:59):

These same TestScripts and fixtures are now also available in the Touchstone testing platform, http://touchstone.com, along with our updated release of version 3.3.0.

Mario Hyland (Dec 25 2016 at 00:23):

FHIR Implementers: As we prepare for the next HL7 FHIR Connectathon - one of the areas we would like to focus our attention on is the FHIR Server public Conformance and Compatibility Statements; we are noting a few of the implemenation teams currently have invalid Conformance (or Compatibility) statements. I created a thread to open discussions around public conformance resources (after all it is ONE of the few FHIR Required elements). Thoughts? If you are interested join the Implementers FHIR Conformance thread - and we would like to work with you to improve your Conformance statement, and learn better techniques for testing conformance statements going forward.

Richard Ettema (Dec 27 2016 at 15:55):

Everyone,
Just wanted to let you know that a key new feature of Touchstone v3.3.x is the inclusion of support for fhirpath expression evaluation within TestScripts. The following TestScript fhirpath related elements, added for STU3, can now be defined and executed by Touchstone:

• variable.expression
• assert.expression
• assert.compareToSourceExpression

nicola (RIO/SS) (Dec 28 2016 at 06:00):

Awesome. Which implementation do you use? Your own?

Richard Ettema (Dec 28 2016 at 16:42):

We're using the FHIR v1.8.0 Java RI implementation.

Richard Ettema (Jan 04 2017 at 21:10):

@Jim Steel , @Michael Lawley @Vadim Peretokin - just coming up for air after the holiday season...
Just wanted to let you know that we have CodeSystem, ConceptMap and ValueSet test definitions deployed in Touchstone under the Basic-FHIR1-8-0 test group.

Richard Ettema (Jan 04 2017 at 21:10):

I have also deployed JSON versions of the Connectathon14/Terminology tests.

Richard Ettema (Jan 04 2017 at 21:32):

Everyone,
The Connectathon 14 - Patient Track - Definitions for FHIR Server Formal Testing scenarios are now available (deployed) to the Touchstone, http://touchstone.com, testing platform.
Connectathon14Touchstone.png
These TestSCripts and corresponding fixtures (test data) are also committed to the FHIR GForge SVN respository at http://gforge.hl7.org/svn/fhir/trunk/connectathons/SanAntonioJan2017/Connectathon14.

Richard Ettema (Jan 04 2017 at 21:48):

Updated definitions for the Connectathon 14 - Patient Track - FHIR Server Formal Testing scenarios are also available on the FHIR wiki at http://wiki.hl7.org/index.php?title=201701_Patient_Track_Proposal#Formal_Testing.

Mario Hyland (Jan 04 2017 at 23:49):

As a FHIR Server I am required by FHIR Specifications to publically publish a Capability (formerly Conformance) Statement - in accordance with the FHIR Specification the Capability Statement (http://hl7.org/fhir/2017Jan/capabilitystatement.html) includes an element fhirVersion (http://hl7.org/fhir/2017Jan/capabilitystatement-definitions.html#CapabilityStatement.fhirVersion) - valid published FHIR Version(s) are viewable here - http://hl7.org/fhir/directory.html

(#1) As a FHIR Server I would like any Test Platform to identify and ensure the Server published fhirVersion is actively part of the test cases chosen and are specific to the published version of FHIR being tested. Note: FHIR Version STU 3 Candidate or Ballot currently has available four valid published version(s) - with active systems running 1.4.0, 1.6.0 and now 1.8.0 coming online daily.

(#2) As a FHIR Server I would like any Test Platform to identify which version of FHIR test cases (suite) were used to test my server. e.g. Dec 6, 2016 build 1.8.0 FHIR STU3 Candidate + Connectathon 14 (San Antonio)

(#3) Please ensure any Test Platform does NOT publically publish test results where active public servers running a valid version of FHIR are being tested against none compatible published standards - that would represent erroneous reporting and could potentially introduce harm to an Organization being reported against.
Given our proximity to HIMSS 2017 - we know a high number of Organizations are planning very high profile FHIR announcements (accurate reporting by public test platforms will be critical to the healthcare marketplace, the industry and HL7).

This notes that there are known significant and breaking changes being published between the various STU3 versions.

Jim Steel (Jan 05 2017 at 03:13):

@Richard Ettema The test setups for the Connectacthon-14 Terminology track are setting up ValueSets, but not the underlying code systems

Mario Hyland (Jan 05 2017 at 05:37):

Q: What role does a FHIR Server Capability Statement (e.g. elements such as fhirVersion) play in any FHIR testing and reporting results?
A: In order to actively and accurately test any HL7 FHIR Implementations - an HL7 FHIR Test Platform would be required to successfully interrogate a FHIR Server Published Capability Statement - (e.g. fhirVersion element detail). Chiefly to match test scripts and FHIR Specification. However, the Test Platform also has a role to validate the capability statement, what if the fhirVersion published is found to be invalid (e.g. FHIR VERSION: 1.5.0) according to FHIR Specifications - any Testing Platform would need to be able to validate/verify the FHIR Server version/Implementation conformance or interoperability and report accordingly - do folks agree?
Recommendation/Suggestion: FHIR Server Capability Statement must be an active part of any testing such that they are validated prior to any test platform undertaking test execution - this to ensure the information available to a FHIR Client would not result in non-interoperable exchange of information.

Vadim Peretokin (Jan 05 2017 at 10:34):

Awesome, thanks @richard ettema

Richard Ettema (Jan 06 2017 at 01:10):

@Jim Steel I'll try to get the code systems into the setups over the next couple of days. Thanks.

Jim Steel (Jan 06 2017 at 01:11):

Cool. If I have other comments on the tests, would you prefer them here or by email?

Richard Ettema (Jan 06 2017 at 01:14):

Send your comments and questions via email to Touchstone_Support@aegis.net. That way everyone in our support group will see them.

Richard Ettema (Jan 06 2017 at 01:22):

Everyone,
I have just committed to the FHIR SVN trunk updates to the Connectathon14 TestScripts and fixtures (test definitions) for the following tracks:

• Patient-01-Intro - minor update to fhirpath expression assert for history Bundle.total; client assigned id assert for valid response code now checks for both 200(OK) or 201(Created)
• Patient-02-Formal - minor update to fhirpath expression assert for history Bundle.total; client assigned id assert for valid response code now checks for both 200(OK) or 201(Created)
• Terminology - New JSON versions of all tests now available
• USCore - Added TestScripts and fixtures for scenarios Patient, Allergies, Assessment, Goals, Immunization, UDI, Problems, Procedures and Smoking Status

These same updated TestScripts and fixtures have also been uploaded to Touchstone, http://touchstone.com.

Richard Ettema (Jan 06 2017 at 01:37):

@Jim Steel I just examined the Terminology tests against the CodeSystem resource type - $lookup and $subsumes ($compose is TBD). All of these tests use the resource type level call for the operations and all use either the LOINC or SNOMED-CT code systems. It would be impractical to attempt to create (load) either of these code systems in the setup of a TestScript due to their size. The basic assumption here is that the Terminology Server under test would already have these code systems (LOINC and SNOMED-CT) available.
The $subsumes and $compose operations do have a resource instance level definition and would be suitable for future test definitions where a reasonably sized CodeSystem resource could be created in the setup.
HTH

Jim Steel (Jan 06 2017 at 01:38):

Yeah. The one I was looking at was patient-contact-relationship

Jim Steel (Jan 06 2017 at 01:39):

Which was $expand tests IIRC

Jim Steel (Jan 06 2017 at 01:41):

In terms of type-level vs instance-level, the interesting operation is $translate, which doesn't actually specify what should happen between the two. There are some intuitive meanings (stronger for instance-level), but we are using quite different behaviour for type-level, so we are likely to fail those tests

Brian Postlethwaite (Jan 06 2017 at 01:41):

Should we anticipate that at least the spec defined valuesets (and underlying code systems) already be loaded?
And things will work if they are all there?

Richard Ettema (Jan 06 2017 at 01:42):

FYI - I'm always looking for new test definitions. If you can define the valid operation call and the input and output payloads, I can turn that into a TestScript. I'd also be happy to take any TestScripts you want to create.

Richard Ettema (Jan 06 2017 at 01:46):

@Brian Postlethwaite If you look at the Expand and Validate-code tests, you'll see that there are three flavors already defined:

• Client Assigned Id - creates the needed ValueSet(s) before test execution using the update operation
• Server Assigned Id - creates the needed ValueSet(s) before test execution using the create operation
• Existing ValueSets - just executions the tests with the expectation the Terminology Server already has them loaded

Richard Ettema (Jan 06 2017 at 01:47):

They all test the same operations and run the same asserts. The only difference is in the setup (or lack thereof).

Jim Steel (Jan 10 2017 at 05:00):

@Richard Ettema All the expand tests in the connectation 14 suite seem to be insisting on the order of the expanded concepts being the same as the expected. That seems problematic

Grahame Grieve (Jan 10 2017 at 06:24):

agree - expansion requirements are not specified that tightly; order doesn't matter

Richard Ettema (Jan 10 2017 at 18:36):

@Jim Steel, @Grahame Grieve Yes, I also agree. This is something I've known about for a while. I'll do my best to get this updated before Connectathon14 (this Saturday!)

Richard Ettema (Jan 11 2017 at 18:49):

@Jim Steel I have updated and deployed the Connectathon14/Terminology Expand tests to Touchstone where the asserts that check the minimum returned content now use fhirpath expressions to verify that minimal expanded codes are present. These asserts are set to 'warning only' to allow for manual inspection of the validation results.
Please let me know if you have any issues.

Jim Steel (Jan 11 2017 at 22:46):

Sweet!

Richard Ettema (Jan 12 2017 at 03:54):

@Jim Steel I noticed your recent Terminology test execution went pretty well with the exception of the $translate tests. Your server reported that it requires the 'source' parameter.

Jim Steel (Jan 12 2017 at 03:55):

Yeah, we're working on that.

Jim Steel (Jan 12 2017 at 03:55):

It will be interesting to see what happens after that, though. Is there a reason that the translates are done at the type-level rather than the instance-level?

Jim Steel (Jan 12 2017 at 03:56):

Type-level translates work very differently in ontoserver to instance-level translates

Richard Ettema (Jan 12 2017 at 03:57):

I created the $translate tests for the last Connectathon based on a simple scenario (no real guidance from anyone). I have to admit I'm not a Terminology expert so any help understanding the different behaviors will help me out.

Jim Steel (Jan 12 2017 at 03:58):

The instance-level translate, although its not made explicit by the spec, would seem to be just "return all mappings for this code"

Richard Ettema (Jan 12 2017 at 03:59):

Ok. That makes sense and is pretty much the intent of the tests I wrote.

Jim Steel (Jan 12 2017 at 03:59):

but type-level translate isn't quite so obvious (the spec doesn't make it clear what it should do). We use it for some "best-guess" style mappings (i.e. we don't use any specific pre-existing ConceptMap resources).

Jim Steel (Jan 12 2017 at 04:00):

For a testing scenario, the instance-level call might be a safer bet in terms of knowing what an implementation "should" do

Jim Steel (Jan 12 2017 at 04:01):

The spec also does say that the 'source' parameter should basically always be provided

Richard Ettema (Jan 12 2017 at 04:01):

So you would expect to have a ConceptMap instance in your server for the scenario I've written, right?

Richard Ettema (Jan 12 2017 at 04:02):

Yes, I re-read the $translate spec and saw that the 'source' parameter is a SHOULD. I'm adding that parameter to my tests.

Jim Steel (Jan 12 2017 at 04:05):

Yeah I guess we'd expect a ConceptMap instance

Jim Steel (Jan 12 2017 at 04:06):

although there is some chance that our "best guess" algorithm would suffice, in this specific case

Richard Ettema (Jan 12 2017 at 04:07):

If you give me minute, I can upload my updated $translate tests now with the 'source' parameter and you can give them try.

Jim Steel (Jan 12 2017 at 04:07):

The third case seems to be passing the target parameter as a string parameter
rather than a URI parameter, too

Jim Steel (Jan 12 2017 at 04:07):

Sure :)

Richard Ettema (Jan 12 2017 at 04:08):

Hmm. Let me look at the third test first.

Richard Ettema (Jan 12 2017 at 04:11):

The only differences in the tests are:

• 1 is a GET with all parameters on the request url
• 2 is a POST with a Parameters payload using the 'coding', 'source' and 'target' parameters
• 3 is a POST with a Parameters payload using the 'code', 'system', 'source' and 'target' parameters

Jim Steel (Jan 12 2017 at 04:12):

3 has valueString instead of valueUri

Richard Ettema (Jan 12 2017 at 04:12):

Ah. Thank you. Fixing that now...

Richard Ettema (Jan 12 2017 at 04:14):

Ok. Fixed and uploaded. Please give it a try.

Jim Steel (Jan 12 2017 at 04:16):

404 on the target ValueSet (http://hl7.org/fhir/v3/AddressUse)

Richard Ettema (Jan 12 2017 at 04:18):

Ok. Help me understand. Does that mean you don't have that ValueSet on your server?

Jim Steel (Jan 12 2017 at 04:18):

Exactly

Jim Steel (Jan 12 2017 at 04:20):

should it be "http://hl7.org/fhir/ValueSet/v3-AddressUse" ?

Jim Steel (Jan 12 2017 at 04:21):

That's the ValueSet.url property of the ValueSet I find at that physical URL

Richard Ettema (Jan 12 2017 at 04:22):

Yes. You are correct. I simply ported these test forward from an earlier version of the spec and I'm guessing that ValueSet name changed.

Richard Ettema (Jan 12 2017 at 04:23):

Give me a couple minutes and I'll update the tests with this ValueSet uri.

Richard Ettema (Jan 12 2017 at 04:25):

Done. Please try again.

Jim Steel (Jan 12 2017 at 04:51):

5/6

Richard Ettema (Jan 12 2017 at 04:52):

Looks like I missed updating the 1st test of the XML format. Taking care of that now.

Richard Ettema (Jan 12 2017 at 04:55):

Done. One more time please.

Richard Ettema (Jan 12 2017 at 04:59):

I see 6/6 now. Nice.

Jim Steel (Jan 12 2017 at 05:02):

I'll look forward to seeing how others go with it at the connectathon (we won't be there unfortunately)

Richard Ettema (Jan 12 2017 at 05:05):

Yes, indeed. Sorry I won't see you there.
Thanks for all your help.

Jim Steel (Jan 12 2017 at 05:05):

any time

Peter Jordan (Jan 12 2017 at 22:21):

@Richard Ettema. Just re-ran my $translate tests (in transit lounge) and they all still pass, but now have warnings that suggest they shouldn't! I'll take a closer look in SA tomorrow, but if you get a chance, could you look at my new results.
Updates...reason is that I'm hosting the testing Concept Map on my server, therefore require that as a testing option (as with the value sets).

Richard Ettema (Jan 12 2017 at 22:52):

@Peter Jordan The $translate tests got updated based on some help from @Jim Steel. The 'source' parameters is now being sent based the documentation for the $translate operation. I also updated the asserts to add a check for the expected returned parameters.
I should be in San Antonio between 5-6 pm local time. See you there.

Peter Jordan (Jan 13 2017 at 23:19):

@Richard Ettema. All good now, upgraded my server to use that source parameter and all $translate tests pass, without warnings, once again. Issue wasn't physical location of the Concept Map - easier to diagnose after some sleep!

Mario Hyland (Mar 04 2017 at 01:18):

A message to the FHIR Implementers who on occasion "test" their FHIR implementation(s) - at the most recent HL7 WGM in San Antonio, TX and during the FHIR side chat Monday evening we discussed to what LEVEL validation and testing should be done with respect to FHIR published Value-Sets. Our team works' to support the FHIR Test Platform Touchstone Project, and is creating "real world" integrated ecosystem(s) which exposes implementers to near "real world" scenarios to test against. We work hard to support both client-side, server-side, and peer-to-peer testing. One of the questions/concerns which was raised during the FHIR-side Chat was to what degree should "value-set" values be tested, e.g. also "value-set" display value(s). Example: system value="http://hl7.org/fhir/identifier-type"/ with a value of "FILL" - would have a display value "Filler Identifier". As discussed it is indeed valid for a FHIR Client/Server to reject messages in which the display value does not conform to the published value set. I want to confirm my accurate reporting of our discussion here - the group did concur (consensus) that this was a valid/correct action by the validator(s) and test platforms.

Grahame Grieve (Mar 04 2017 at 19:20):

yes, it is valid to reject a resource if the display is wrong. But it is not required to do so

Ravindra Kumar (Apr 18 2017 at 19:19):

Can anyone direct me to some documentation on how to test FHIR projects? wee are doing an implementation on DSTU3, and I have no idea what kind of test cases I need . (I am not a developer but a tester only)

Grahame Grieve (Apr 18 2017 at 21:02):

well, theres's this: http://hl7.org/fhir/testing.html

Grahame Grieve (Apr 18 2017 at 21:02):

not quite what you want, but it is there

Mario Hyland (Apr 18 2017 at 21:17):

Hello Ravindra - have you heard of the FHIR Testing Platform www.touchstone.com - it is a cloud based Test-Driven-Development (TDD) focused on Testing FHIR DSTU 2 thru R3. If you need more input reach out to me directly (private message).

Last updated: Apr 12 2022 at 19:14 UTC