IPS Tooling Wish List

From IHE Wiki
Revision as of 09:52, 18 May 2021 by Smoore (talk | contribs)
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 and does not assume the document resides on a FHIR server.
    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. Coded values correspond to Value Sets in the IG.
    5. User Interface
      1. Must have some mechanism that allows the user to execute the validation without having to go through a Web UI. As part of my development and/or CI process, I want to create 50 documents and validate all of them. This wants to be a RESTful API and not SOAP based. For those old enough to remember CORBA, that is also a non-starter.
      2. Must have a Web UI to validate a single document.
      3. Must have a Web UI to allow me to upload a zip of documents. This one might be harder for a public system if you are concerned about zip bombs.
  2. I want to be able to validate individual resources.
    1. Same comments as above.
  3. Traditional validation tools give you errors when required elements are missing and warnings when optional elements are missing. That is understandable. I need additional tests where I can raise the bar and say "These optional elements are required for this test."
    1. Think of a national extension that requires additional items that were optional in the original specification.
  4. I need to be able to specify different Value Sets. There are tests where you want to augment the existing Value Sets and tests where you want to replace Value Set A with Value Set B. I want to support those scenarios in a way where a test case knows which Value Sets to use and does not assume that the tool has a collection of Value Sets that is always used for all tests.
    1. I understand the issue that the software itself cannot necessarily give out the Value Sets because of licensing issues. It is on the person who runs the tool to get the Value Sets.
  1. 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.
    1. 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.
  2. 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.
  3. 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