IPS Tooling Wish List

From IHE Wiki
Revision as of 09:31, 18 May 2021 by Smoore (talk | contribs) (Created page with "These are my thoughts on what kind of software tool(s) I would like to have for testing the IPS Profile. = FHIR Content and Transactions = # I need a tool that validates an I...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

These are my thoughts on what kind of software tool(s) I would like to have for testing the IPS Profile.

FHIR Content and Transactions

  1. I need a tool that validates an IPS document as a complete document.
    1. Required elements are present
    2. Resources referenced in the composition are in the document and not somewhere else.
    3. Resources in the document are valid per IPS requirements.
    4. Cannot assume that the document resides on a FHIR server. Again, valid use case, but too restrictive for our testing.
    5. Document upload to a website is possible; I know you already have this infrastructure. CLI tool is also an option. As a developer, I actually prefer this because it is easy to script. If I can hit your website with a curl script to do validation, that satisfies my CLI request
  2. I want to be able to validate the Composition by itself. I want the Creator to know if the Composition has all required elements in it.
    1. Same comments apply as above. Cannot assume the Composition lives on a FHIR server.
  3. I want to be able to validate individual resources.
    1. Same comments as above.
  4. I am telling a Creator that it has to create a patient with specific clinical content. I want to able to validate that the specified content is present in the document. I will have a number of patients, so the tool needs to be able to manage content for multiple patients. I want to add new patients and new clinical content at runtime without having to write Ruby code or understand how to build your tool. I just want some kind of specification (say IPS XML or json with further annotations) to drive a test case.
  5. Traditional validation tools give you errors when required elements are missing and warnings when optional elements are missing. That is understandable.
    1. I need additional tests where I can raise the bar and say "These optional elements are required for this test."
    2. That will support things like a track that is focused on Immunizations. Rather than me wading through a bunch of warnings looking for the ones that are for Immunizations, I want to be able to elevate those items to the error level so I can point out to people: You are working in the Immunization Track. Because you are working here, missing Immunizations are errors and no longer warnings.
  6. These fall in the Nice to Have category.
    1. Assume the resource I want to question does exist on a FHIR server. I can tell some creators to "send your document over there", and we can use your existing infrastructure. I think I get this for free.
    2. Have Inferno publish an endpoint where I can push a resource and have you validate against one or more contexts. Contexts is not the right word; I want to use profile, but that means different things to different people. Maybe I should have said scenario. I want to be able to find the resource in Inferno after it is submitted and tell it to validate against A, B, C and E. This is for a Creator that is normally pushing a document to a FHIR server. I am purposely not including other metadata in the HTTP transaction that would specify the context because I do not want to require the client application to write extra code on top of their normal work.
    3. That being said, a URL that accepts a resource with extra context (test A, B, C, E) would be useful. Because I am a CLI guy, that simplifies things for me as a developer. If Epic wants to put this in their app, then can knock themselves out.
    4. As in 6.2., have Inferno publish an endpoint that accepts an IHE XDS Provide and Register transaction and then supports validation. I do not imagine this would ever be on your radar, but it does not hurt to ask.
    5. As in 6.2., have Inferno publish an endpoint that accepts an ITI-65 MHDS transaction. In brief, some IHE Creators will submit the document with an extra wrapper around it. If you took it natively, that simplifies things. Again, I don't see this as a priority for you.
  7. Integration with Gazelle: You have already been in discussion with the Kereval team about how to integrate Inferno and Gazelle. I should probably see the API you are workings towards rather than opining any further.


CDA Content and Transactions